From jdrosen@dynamicsoft.com Fri Jan 5 17:46:07 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03759 for ; Fri, 5 Jan 2001 17:46:07 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA14212 for ; Fri, 5 Jan 2001 17:48:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 17:43:16 -0500 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Fri, 5 Jan 2001 17:43:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 357 Subject: [Simple] test 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: test --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Fri Jan 5 17:47:37 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03781 for ; Fri, 5 Jan 2001 17:47:37 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA14239 for ; Fri, 5 Jan 2001 17:50:22 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 5 Jan 2001 17:44:46 -0500 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Fri, 5 Jan 2001 17:44:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 357 Subject: [Simple] test 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: test --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From john_rudolph@yahoo.com Fri Jan 5 18:02:28 2001 Received: from web612.mail.yahoo.com (web612.mail.yahoo.com [216.115.104.81]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA03828 for ; Fri, 5 Jan 2001 18:02:28 -0500 (EST) Message-ID: <20010105230227.6175.qmail@web612.mail.yahoo.com> Received: from [216.173.40.50] by web612.mail.yahoo.com; Fri, 05 Jan 2001 15:02:27 PST Date: Fri, 5 Jan 2001 15:02:27 -0800 (PST) From: John Rudolph To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 317 Subject: [Simple] test 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: This is a test to the 'simple' mail list sent from yahoo. If it works, it should be safe to let others know about it, although it might be wise to wait until tomorrow. John __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From jdrosen@dynamicsoft.com Mon Jan 8 01:31:23 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12100 for ; Mon, 8 Jan 2001 01:31:23 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01770; Mon, 8 Jan 2001 01:34:08 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 01:28:27 -0500 Message-ID: From: Jonathan Rosenberg To: "'simple@egroups.com'" Cc: "'simple@mailman.dynamicsoft.com'" Date: Mon, 8 Jan 2001 01:28:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1227 Subject: [Simple] IMPORTANT: LIST IS MOVING! 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: Folks, Unfortunately, it appears that egroups mailing lists are not acceptable for IETF working group usage. This has to do with their privacy policies and usage of cookies. There has been a discussion on this issue on the main impp list. Patrik has indicated that we cannot form a working group until a new list is used. So, I have set up a gnu mailmain list. You can send to the list at: simple@mailman.dynamicsoft.com information on the list, its archives, and subscribing, can be found at: http://mailman.dynamicsoft.com/mailman/listinfo/simple Unfortunately, I cannot move the current list of subscribers on this egroups list to the new mailman list. You will all need to manually resubscribe to the mailman list above. I apologize for the incovenience of this. But, it is necessary for us to get a working group going. Thanks for your understanding, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Mon Jan 8 01:32:56 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12112 for ; Mon, 8 Jan 2001 01:32:56 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01787; Mon, 8 Jan 2001 01:35:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 01:30:00 -0500 Message-ID: From: Jonathan Rosenberg To: "'ietf-simple@egroups.com'" Cc: "'simple@mailman.dynamicsoft.com'" Date: Mon, 8 Jan 2001 01:29:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1227 Subject: [Simple] IMPORTANT: LIST IS MOVING! 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: Folks, Unfortunately, it appears that egroups mailing lists are not acceptable for IETF working group usage. This has to do with their privacy policies and usage of cookies. There has been a discussion on this issue on the main impp list. Patrik has indicated that we cannot form a working group until a new list is used. So, I have set up a gnu mailmain list. You can send to the list at: simple@mailman.dynamicsoft.com information on the list, its archives, and subscribing, can be found at: http://mailman.dynamicsoft.com/mailman/listinfo/simple Unfortunately, I cannot move the current list of subscribers on this egroups list to the new mailman list. You will all need to manually resubscribe to the mailman list above. I apologize for the incovenience of this. But, it is necessary for us to get a working group going. Thanks for your understanding, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From Ron.Akers@motorola.com Mon Jan 8 06:31:35 2001 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00850 for ; Mon, 8 Jan 2001 06:31:35 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA22482 for ; Mon, 8 Jan 2001 04:31:35 -0700 (MST)] Received: [from il02exi02.comm.mot.com (il02exi02.comm.mot.com [145.1.204.41]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA19862 for ; Mon, 8 Jan 2001 04:31:34 -0700 (MST)] Received: by il02exi02.comm.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 8 Jan 2001 05:31:34 -0600 Message-ID: From: Akers Ron-WRA001 To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 8 Jan 2001 05:31:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 445 Subject: [Simple] Status of the WG 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: Could someone comment on the status of the WG? Is it officially a WG yet? Regards, Ron ------------------------------------------------------------ Ron Akers Voice :(847)576-7928 Neworks and Infrastructure Research FAX :(847)576-3240 Motorola Laboratories email:ron.akers@motorola.com 1301 Algonquin Rd, Rm 2246 Schaumburg, IL. 60196 ------------------------------------------------------------ From paf@cisco.com Mon Jan 8 07:38:22 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01072 for ; Mon, 8 Jan 2001 07:38:22 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id EAA22581; Mon, 8 Jan 2001 04:38:17 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f08CcJN20710; Mon, 8 Jan 2001 04:38:19 -0800 (PST) Received: from [192.168.124.81] (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id EAA28427; Mon, 8 Jan 2001 04:38:12 -0800 (PST) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 8 Jan 2001 13:35:12 +0100 To: Akers Ron-WRA001 , "'simple@mailman.dynamicsoft.com'" From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: [Simple] Status of the WG Cc: Ned Freed Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Content-Length: 437 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: At 05.31 -0600 01-01-08, Akers Ron-WRA001 wrote: >Could someone comment on the status of the WG? Is it officially a WG yet? It is NOT a wg yet. paf -- Patrik Fältström Internet Engineering Task Force Area Director, Applications Area http://www.ietf.org Phone: (Stockholm) +46-8-4494212 (San Jose) +1-408-525-0940 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC From Nadav_Ramati@icomverse.com Mon Jan 22 10:42:31 2001 Received: from dawn.barak.net.il (dawn.barak.net.il [212.150.150.43]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01185 for ; Mon, 22 Jan 2001 10:42:25 -0500 (EST) Received: from mail.barak.net.il (mail.barak.net.il [206.49.94.213]) by dawn.barak.net.il (8.11.1/8.11.1) with ESMTP id f0MFgfK23319 for ; Mon, 22 Jan 2001 17:42:41 +0200 (IST) Received: from ismailout1.icomverse.com ([209.88.197.162]) by mail.barak.net.il (8.11.2/8.9.1) with ESMTP id f0MFg7c09301 for ; Mon, 22 Jan 2001 17:42:08 +0200 (IST) Received: from ismail3.icomverse.com (ismail3.icomverse.com [190.190.110.4]) by ismailout1.icomverse.com (8.11.0/8.11.0.Beta3) with ESMTP id f0MFeF623945 for ; Mon, 22 Jan 2001 17:40:25 +0200 Received: by ismail3.icomverse.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Jan 2001 17:40:14 +0200 Message-ID: From: "Ramati, Nadav" To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 22 Jan 2001 17:41:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08489.C9C4AE70" Content-Length: 729 Subject: [Simple] (no subject) 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: 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_01C08489.C9C4AE70 Content-Type: text/plain; charset="windows-1255" subscribe ------_=_NextPart_001_01C08489.C9C4AE70 Content-Type: text/html; charset="windows-1255"
subscribe
 
------_=_NextPart_001_01C08489.C9C4AE70-- From roberto@Exchange.Microsoft.com Wed Jan 24 23:56:50 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA10410 for ; Wed, 24 Jan 2001 23:56:49 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 24 Jan 2001 20:10:49 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Jan 2001 20:11:33 -0800 (Pacific Standard Time) Received: from DF-SCRAPPY.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Wed, 24 Jan 2001 20:11:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08684.E6737DE5" Date: Wed, 24 Jan 2001 20:11:32 -0800 Message-ID: <766EFCAA12CB514CAC64D8C440F5A50E054ED2C1@DF-SCRAPPY.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-events] Multiparty IM Thread-Index: AcCFjxqoUviJumhsTVuwgf8DJ3zDiQA9ZhcA From: "Robert Osborne" To: X-OriginalArrivalTime: 25 Jan 2001 04:11:33.0057 (UTC) FILETIME=[E6B17B10:01C08684] Content-Length: 3709 Subject: [Simple] Multiparty IM 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C08684.E6737DE5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 just going through the draft draft-rosenberg-impp-im-00.txt, and started to think about how multiparty IM might work. By this I mean the common scenario, that most IM clients support, of A talking to B, and A or B inviting C into the session. =20 Looking through the draft this could be solved, by A sending a message to each participant. However B will not know that C has joined the session, and C will not know about B. Therefore any messages sent by them will only be sent to A.=20 =20 Another problem is that if B wishes to leave an IM session, there is no way for him/her to notify the other participants of the session. Therefore B could continue to receive messages, without wanting to. =20 Has anyone looked at this problem, and come up with a simple and effective solution? =20 Rob O=20 Rob Osborne=20 Program Manager=20 Microsoft=20 =20 ------_=_NextPart_001_01C08684.E6737DE5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
just = going through=20 the draft draft-rosenberg-impp-im-00.txt, and started to think about how = multiparty IM=20 might work. By this I mean the common scenario, that most IM clients = support, of=20 A talking to B, and A or B inviting C into the=20 session.
 
Looking through=20 the draft this could be solved, by A sending a message to each = participant. However B will not know that C has joined the session, and = C will=20 not know about B. Therefore any messages sent by them will only be sent = to=20 A. 
 
Another=20 problem is that if B wishes to leave an IM session, there is no way = for=20 him/her to notify the other participants of the session. = Therefore B could=20 continue to receive messages, without wanting = to.
 
Has = anyone=20 looked at this problem, and come up with a simple and = effective=20 solution?
 
Rob=20 O 

Rob Osborne
Program Manager

Microsoft 
 
------_=_NextPart_001_01C08684.E6737DE5-- From Harald@Alvestrand.no Fri Jan 26 10:47:56 2001 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15661 for ; Fri, 26 Jan 2001 10:47:54 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id QAA12275; Fri, 26 Jan 2001 16:47:43 +0100 Message-Id: <4.3.2.7.2.20010126074611.06dbf468@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jan 2001 07:47:27 -0800 To: "Robert Osborne" , From: Harald Alvestrand Subject: Re: [Simple] Multiparty IM In-Reply-To: <766EFCAA12CB514CAC64D8C440F5A50E054ED2C1@DF-SCRAPPY.platin um.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 1280 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: At 11:11 24/01/2001 -0800, Robert Osborne wrote: >ust going through the draft >draft-rosenberg-impp-im-00.txt, >and started to think about how multiparty IM might work. By this I mean >the common scenario, that most IM clients support, of A talking to B, and >A or B inviting C into the session. > >Looking through the draft this could be solved, by A sending a message to >each participant. However B will not know that C has joined the session, >and C will not know about B. Therefore any messages sent by them will only >be sent to A. > >Another problem is that if B wishes to leave an IM session, there is no >way for him/her to notify the other participants of the session. Therefore >B could continue to receive messages, without wanting to. > >Has anyone looked at this problem, and come up with a simple and effective >solution? > The IRC way is to give the session concept separate existence, and have all messages sent to the session instead of the participants. This is the essence of a "channel". Note: The IMPP requirements and CPIM documents do not have the concept of "session". -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From roberto@Exchange.Microsoft.com Fri Jan 26 12:25:46 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15959 for ; Fri, 26 Jan 2001 12:25:45 -0500 (EST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 26 Jan 2001 08:56:47 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 26 Jan 2001 08:57:32 -0800 (Pacific Standard Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Fri, 26 Jan 2001 08:57:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4633.0 content-class: urn:content-classes:message Subject: RE: [Simple] Multiparty IM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 26 Jan 2001 08:57:31 -0800 Message-ID: <766EFCAA12CB514CAC64D8C440F5A50E63221A@DF-SCRAPPY.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Multiparty IM Thread-Index: AcCHr9uskYdjjKOhSLqsD5FqqrLkFQAB7r0w From: "Robert Osborne" To: "Harald Alvestrand" , X-OriginalArrivalTime: 26 Jan 2001 16:57:32.0216 (UTC) FILETIME=[12E65B80:01C087B9] Content-Length: 2466 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA15959 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: >-----Original Message----- >From: Harald Alvestrand [mailto:Harald@Alvestrand.no] >Sent: Friday, January 26, 2001 7:47 AM >To: Robert Osborne; simple@mailman.dynamicsoft.com >Subject: Re: [Simple] Multiparty IM > > >At 11:11 24/01/2001 -0800, Robert Osborne wrote: >>ust going through the draft >>0.txt>draft-rosenberg-impp-im-00.txt, >>and started to think about how multiparty IM might work. By >this I mean >>the common scenario, that most IM clients support, of A >talking to B, and >>A or B inviting C into the session. >> >>Looking through the draft this could be solved, by A sending >a message to >>each participant. However B will not know that C has joined >the session, >>and C will not know about B. Therefore any messages sent by >them will only >>be sent to A. >> >>Another problem is that if B wishes to leave an IM session, >there is no >>way for him/her to notify the other participants of the >session. Therefore >>B could continue to receive messages, without wanting to. >> >>Has anyone looked at this problem, and come up with a simple >and effective >>solution? >> > >The IRC way is to give the session concept separate existence, >and have all >messages sent to the session instead of the participants. >This is the essence of a "channel". > I agree with you that there needs to be an independent session concept. With this session it would be possible to invite people, leave, and notify existing members of new members joining. In the initial implementation of RVP, we believed you could determine the members of a session by simply using some information included within the headers of an IM. Unfortunately we quickly discovered that due to error conditions, it was very easy to get the participant list out of step, and therefore had to resort to an Invite, Ack, Join, Leave command flow. I am hoping that someone has come up with a better solution, that fits within the current SIP IM proposal of just using a MESSAGE to send an IM. Is there something I am missing that allows for good participant management using just this method? >Note: The IMPP requirements and CPIM documents do not have the >concept of >"session". Is this something that will be changed, or will the CPIM assume that there will be no multi-party IM? Rob O > >-- >Harald Tveit Alvestrand, alvestrand@cisco.com >+47 41 44 29 94 >Personal email: Harald@Alvestrand.no > > From mhammer@cisco.com Fri Jan 26 14:47:32 2001 Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16330 for ; Fri, 26 Jan 2001 14:47:31 -0500 (EST) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA10396; Fri, 26 Jan 2001 14:47:10 -0500 (EST) Received: from mhammer-nt.cisco.com (herndon3-dhcp-44.cisco.com [161.44.193.44]) by cia.cisco.com (Mirapoint) with ESMTP id AJD06344; Fri, 26 Jan 2001 14:47:08 -0500 (EST) Message-Id: <4.3.2.7.2.20010126144939.00beddb0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jan 2001 14:54:20 -0800 To: "Robert Osborne" , "Harald Alvestrand" , From: hammer michael Subject: RE: [Simple] Multiparty IM In-Reply-To: <766EFCAA12CB514CAC64D8C440F5A50E63221A@DF-SCRAPPY.platinum .corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 3190 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: It seems like there are two concepts of session to consider: Connection-oriented: SIP signaling with separate media streams Connectionless: Message-oriented with content and signaling combined The prior is flow-oriented, the latter discrete. If SIP is to handle both, then some means of distinguishing between the two types of "session" establishment, modification, and release may be needed. Mike At 08:57 AM 01/26/2001 -0800, Robert Osborne wrote: > >-----Original Message----- > >From: Harald Alvestrand [mailto:Harald@Alvestrand.no] > >Sent: Friday, January 26, 2001 7:47 AM > >To: Robert Osborne; simple@mailman.dynamicsoft.com > >Subject: Re: [Simple] Multiparty IM > > > > > >At 11:11 24/01/2001 -0800, Robert Osborne wrote: > >>ust going through the draft > >>0.txt>dra > ft-rosenberg-impp-im-00.txt, > >>and started to think about how multiparty IM might work. By > >this I mean > >>the common scenario, that most IM clients support, of A > >talking to B, and > >>A or B inviting C into the session. > >> > >>Looking through the draft this could be solved, by A sending > >a message to > >>each participant. However B will not know that C has joined > >the session, > >>and C will not know about B. Therefore any messages sent by > >them will only > >>be sent to A. > >> > >>Another problem is that if B wishes to leave an IM session, > >there is no > >>way for him/her to notify the other participants of the > >session. Therefore > >>B could continue to receive messages, without wanting to. > >> > >>Has anyone looked at this problem, and come up with a simple > >and effective > >>solution? > >> > > > >The IRC way is to give the session concept separate existence, > >and have all > >messages sent to the session instead of the participants. > >This is the essence of a "channel". > > > >I agree with you that there needs to be an independent session >concept. With this session it would be possible to invite people, >leave, and notify existing members of new members joining. > >In the initial implementation of RVP, we believed you could >determine the members of a session by simply using some information >included within the headers of an IM. Unfortunately we quickly >discovered that due to error conditions, it was very easy to get >the participant list out of step, and therefore had to resort to >an Invite, Ack, Join, Leave command flow. > >I am hoping that someone has come up with a better solution, that >fits within the current SIP IM proposal of just using a MESSAGE >to send an IM. Is there something I am missing that allows for >good participant management using just this method? > > >Note: The IMPP requirements and CPIM documents do not have the > >concept of > >"session". > >Is this something that will be changed, or will the CPIM assume >that there will be no multi-party IM? > >Rob O > > > > >-- > >Harald Tveit Alvestrand, alvestrand@cisco.com > >+47 41 44 29 94 > >Personal email: Harald@Alvestrand.no > > > > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple From jdrosen@dynamicsoft.com Mon Jan 29 02:09:55 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25211 for ; Mon, 29 Jan 2001 02:09:55 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA02283; Mon, 29 Jan 2001 02:12:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 02:06:17 -0500 Message-ID: From: Jonathan Rosenberg To: "'Robert Osborne'" , Harald Alvestrand , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Multiparty IM Date: Mon, 29 Jan 2001 02:06:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3372 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: > -----Original Message----- > From: Robert Osborne [mailto:roberto@exchange.microsoft.com] > Sent: Friday, January 26, 2001 11:58 AM > To: Harald Alvestrand; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Multiparty IM > > > > > >-----Original Message----- > >From: Harald Alvestrand [mailto:Harald@Alvestrand.no] > >Sent: Friday, January 26, 2001 7:47 AM > >To: Robert Osborne; simple@mailman.dynamicsoft.com > >Subject: Re: [Simple] Multiparty IM > > > > > >At 11:11 24/01/2001 -0800, Robert Osborne wrote: > >>ust going through the draft > >> >0.txt>draft-rosenberg-impp-im-00.txt, > >>and started to think about how multiparty IM might work. By > >this I mean > >>the common scenario, that most IM clients support, of A > >talking to B, and > >>A or B inviting C into the session. > >> > >>Looking through the draft this could be solved, by A sending > >a message to > >>each participant. However B will not know that C has joined > >the session, > >>and C will not know about B. Therefore any messages sent by > >them will only > >>be sent to A. > >> > >>Another problem is that if B wishes to leave an IM session, > >there is no > >>way for him/her to notify the other participants of the > >session. Therefore > >>B could continue to receive messages, without wanting to. > >> > >>Has anyone looked at this problem, and come up with a simple > >and effective > >>solution? > >> > > > >The IRC way is to give the session concept separate existence, > >and have all > >messages sent to the session instead of the participants. > >This is the essence of a "channel". > > > > I agree with you that there needs to be an independent session > concept. With this session it would be possible to invite people, > leave, and notify existing members of new members joining. > > In the initial implementation of RVP, we believed you could > determine the members of a session by simply using some information > included within the headers of an IM. Unfortunately we quickly > discovered that due to error conditions, it was very easy to get > the participant list out of step, and therefore had to resort to > an Invite, Ack, Join, Leave command flow. > > I am hoping that someone has come up with a better solution, that > fits within the current SIP IM proposal of just using a MESSAGE > to send an IM. Is there something I am missing that allows for > good participant management using just this method? > > >Note: The IMPP requirements and CPIM documents do not have the > >concept of > >"session". > > Is this something that will be changed, or will the CPIM assume > that there will be no multi-party IM? --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > > Rob O > > > > >-- > >Harald Tveit Alvestrand, alvestrand@cisco.com > >+47 41 44 29 94 > >Personal email: Harald@Alvestrand.no > > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From jdrosen@dynamicsoft.com Mon Jan 29 02:15:50 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25253 for ; Mon, 29 Jan 2001 02:15:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA02326; Mon, 29 Jan 2001 02:18:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 02:12:21 -0500 Message-ID: From: Jonathan Rosenberg To: "'Robert Osborne'" , Harald Alvestrand , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Multiparty IM Date: Mon, 29 Jan 2001 02:12:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2786 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: (sorry for the previous empty response... outlook is "trigger happy") > -----Original Message----- > From: Robert Osborne [mailto:roberto@exchange.microsoft.com] > Sent: Friday, January 26, 2001 11:58 AM > To: Harald Alvestrand; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Multiparty IM > > > > > >The IRC way is to give the session concept separate existence, > >and have all > >messages sent to the session instead of the participants. > >This is the essence of a "channel". > > > > I agree with you that there needs to be an independent session > concept. With this session it would be possible to invite people, > leave, and notify existing members of new members joining. > > In the initial implementation of RVP, we believed you could > determine the members of a session by simply using some information > included within the headers of an IM. Unfortunately we quickly > discovered that due to error conditions, it was very easy to get > the participant list out of step, and therefore had to resort to > an Invite, Ack, Join, Leave command flow. > > I am hoping that someone has come up with a better solution, that > fits within the current SIP IM proposal of just using a MESSAGE > to send an IM. Is there something I am missing that allows for > good participant management using just this method? This problem has come up within traditional SIP applications for multiparty conferencing. The same requirements exist there - the ability to add/remove participants from a session (most likely using multi-unicast media) without a centralized server of any sort. The problems you describe - of tracking membership and maintaining consistent group state - exist there as well. We have the sketch of a solution which basically involves a flooding-like mechanism where each participant tells the other of its known members when there is a change. Any differences detected cause further exchanges with other peers. Effectively, its much like a link-state routing protocol, which is trying to solve a similar problem. Continued work on this topic is taking place at the sip interim meeting in Dallas next week. Of course, the easiest way byfar is to have the notion of a central server of some sorts, which can track membership and send messages out to all participants. There is a draft on this subject: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-mode ls-00.txt -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From leslie@thinkingcat.com Mon Jan 29 11:13:33 2001 Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01269 for ; Mon, 29 Jan 2001 11:13:33 -0500 (EST) Received: from thinkingcat.com ([64.229.192.124]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010129161331.VDYD27935.tomts5-srv.bellnexxia.net@thinkingcat.com>; Mon, 29 Jan 2001 11:13:31 -0500 Message-ID: <3A759654.2EA409B@thinkingcat.com> Date: Mon, 29 Jan 2001 11:12:04 -0500 From: Leslie Daigle Organization: Thinking Cat Enterprises X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Osborne CC: Harald Alvestrand , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Multiparty IM References: <766EFCAA12CB514CAC64D8C440F5A50E63221A@DF-SCRAPPY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 489 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: Howdy, Robert Osborne wrote: > Is this something that will be changed, or will the CPIM assume > that there will be no multi-party IM? The consensus of the IMPP working group has been to leave multi-party IM outside the scope of the common core (CPIM). Leslie. -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From bcampbell@dynamicsoft.com Mon Jan 29 15:17:57 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01972 for ; Mon, 29 Jan 2001 15:17:57 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA10212 for ; Mon, 29 Jan 2001 15:20:54 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 15:14:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F309A7@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Multiparty IM Date: Mon, 29 Jan 2001 15:14:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3985 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: The multiparty discussion makes me wonder: The current SIMPLE definition of IM treats IMs more like pages then conversations. The client can correlate the callID and make a best effort attempt to thread conversations, but that is about it. The multiparty conferencing approaches you mentioned in general SIP deal with explicit call legs, do they not? Would it make sense to also include the concept of text conferences with an explicit session, i.e. with an INVITE and a BYE? For example, yahoo allows one to send an instant message (much like in SIMPLE), and also to invite contacts to a conference. Only the conference mode supports multiparty messaging. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, January 29, 2001 1:12 AM > To: 'Robert Osborne'; Harald Alvestrand; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Multiparty IM > > > (sorry for the previous empty response... outlook is "trigger happy") > > > > > > -----Original Message----- > > From: Robert Osborne [mailto:roberto@exchange.microsoft.com] > > Sent: Friday, January 26, 2001 11:58 AM > > To: Harald Alvestrand; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Multiparty IM > > > > > > > > > >The IRC way is to give the session concept separate existence, > > >and have all > > >messages sent to the session instead of the participants. > > >This is the essence of a "channel". > > > > > > > I agree with you that there needs to be an independent session > > concept. With this session it would be possible to invite people, > > leave, and notify existing members of new members joining. > > > > In the initial implementation of RVP, we believed you could > > determine the members of a session by simply using some information > > included within the headers of an IM. Unfortunately we quickly > > discovered that due to error conditions, it was very easy to get > > the participant list out of step, and therefore had to resort to > > an Invite, Ack, Join, Leave command flow. > > > > I am hoping that someone has come up with a better solution, that > > fits within the current SIP IM proposal of just using a MESSAGE > > to send an IM. Is there something I am missing that allows for > > good participant management using just this method? > > This problem has come up within traditional SIP applications > for multiparty > conferencing. The same requirements exist there - the ability > to add/remove > participants from a session (most likely using multi-unicast > media) without > a centralized server of any sort. The problems you describe - > of tracking > membership and maintaining consistent group state - exist > there as well. We > have the sketch of a solution which basically involves a flooding-like > mechanism where each participant tells the other of its known > members when > there is a change. Any differences detected cause further > exchanges with > other peers. Effectively, its much like a link-state routing > protocol, which > is trying to solve a similar problem. Continued work on this > topic is taking > place at the sip interim meeting in Dallas next week. > > Of course, the easiest way byfar is to have the notion of a > central server > of some sorts, which can track membership and send messages out to all > participants. There is a draft on this subject: > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-con ferencing-mode ls-00.txt -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From huitema@exchange.microsoft.com Mon Jan 29 16:10:17 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02129 for ; Mon, 29 Jan 2001 16:10:17 -0500 (EST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 29 Jan 2001 12:45:00 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Jan 2001 12:45:44 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Mon, 29 Jan 2001 12:45:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4633.0 content-class: urn:content-classes:message Subject: RE: [Simple] Multiparty IM MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 29 Jan 2001 12:45:42 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Multiparty IM Thread-Index: AcCKMR1BbMbwNS3CQ3+l/KLsvnmunAAAl2zw From: "Christian Huitema" To: "Ben Campbell" , "Jonathan Rosenberg" , X-OriginalArrivalTime: 29 Jan 2001 20:45:42.0777 (UTC) FILETIME=[72596E90:01C08A34] Content-Length: 5486 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id QAA02129 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: A simple solution would be to negotiate a "chat" or "text" media, just like we negotiate audio or video. After all, the requirements of doing multiparty audio are about the same as the requirement of doing multiparty chat; this go for the signalling requirements, i.e. how to find conference members, and the transmission requirements, i.e. whether to use multicast groups, transmission server, or some form of ad hoc replication. We would thus have two separate solutions, simple "page like" messages using the "message" construct, and "message sessions" services. This solution would have the additional advantage of not overloading the signalling infrastructure with media traffic, even if that media is text. I always have this vision of the signalling server being dimemsioned based on the classic voice hypothesis, such as 100 second sessions and 10% busy users at peak hour, and then being congested because we forgot that text messaging can generate 10 times more messages than mere session signalling... In any case, if we keep messaging in the signalling channel, we should also keep it simple! -- Christian Huitema -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Monday, January 29, 2001 12:15 PM To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] Multiparty IM The multiparty discussion makes me wonder: The current SIMPLE definition of IM treats IMs more like pages then conversations. The client can correlate the callID and make a best effort attempt to thread conversations, but that is about it. The multiparty conferencing approaches you mentioned in general SIP deal with explicit call legs, do they not? Would it make sense to also include the concept of text conferences with an explicit session, i.e. with an INVITE and a BYE? For example, yahoo allows one to send an instant message (much like in SIMPLE), and also to invite contacts to a conference. Only the conference mode supports multiparty messaging. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, January 29, 2001 1:12 AM > To: 'Robert Osborne'; Harald Alvestrand; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Multiparty IM > > > (sorry for the previous empty response... outlook is "trigger happy") > > > > > > -----Original Message----- > > From: Robert Osborne [mailto:roberto@exchange.microsoft.com] > > Sent: Friday, January 26, 2001 11:58 AM > > To: Harald Alvestrand; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Multiparty IM > > > > > > > > > >The IRC way is to give the session concept separate existence, > > >and have all > > >messages sent to the session instead of the participants. > > >This is the essence of a "channel". > > > > > > > I agree with you that there needs to be an independent session > > concept. With this session it would be possible to invite people, > > leave, and notify existing members of new members joining. > > > > In the initial implementation of RVP, we believed you could > > determine the members of a session by simply using some information > > included within the headers of an IM. Unfortunately we quickly > > discovered that due to error conditions, it was very easy to get > > the participant list out of step, and therefore had to resort to > > an Invite, Ack, Join, Leave command flow. > > > > I am hoping that someone has come up with a better solution, that > > fits within the current SIP IM proposal of just using a MESSAGE to > > send an IM. Is there something I am missing that allows for good > > participant management using just this method? > > This problem has come up within traditional SIP applications > for multiparty > conferencing. The same requirements exist there - the ability > to add/remove > participants from a session (most likely using multi-unicast > media) without > a centralized server of any sort. The problems you describe - > of tracking > membership and maintaining consistent group state - exist > there as well. We > have the sketch of a solution which basically involves a flooding-like > mechanism where each participant tells the other of its known > members when > there is a change. Any differences detected cause further > exchanges with > other peers. Effectively, its much like a link-state routing > protocol, which > is trying to solve a similar problem. Continued work on this > topic is taking > place at the sip interim meeting in Dallas next week. > > Of course, the easiest way byfar is to have the notion of a > central server > of some sorts, which can track membership and send messages out to all > participants. There is a draft on this subject: > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-con ferencing-mode ls-00.txt -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen 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 Jon.Peterson@Level3.com Mon Jan 29 17:27:07 2001 Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02362 for ; Mon, 29 Jan 2001 17:27:06 -0500 (EST) From: Jon.Peterson@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id WAA28110 for ; Mon, 29 Jan 2001 22:26:56 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA22000 for ; Mon, 29 Jan 2001 22:26:55 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 15:29:02 -0700 Message-ID: <6384220893BCD411BDFE0008C791B79C232D4D@N0228IDC1.oss.level3.com> To: simple@mailman.dynamicsoft.com Date: Mon, 29 Jan 2001 15:25:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3217 Subject: [Simple] FW: WG Review: SIP for Instant Messaging and Presence Leveraging (simple) 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: FYI Jon Peterson Level(3) Communications -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Monday, January 29, 2001 12:06 PM Cc: new-work@ietf.org Subject: WG Review: SIP for Instant Messaging and Presence Leveraging (simple) A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following Description was submitted, and is provided for informational purposes only: SIP for Instant Messaging and Presence Leveraging (simple) ---------------------------------------------------------- Current Status: Proposed Working Group Mailing Lists: General Discussion:simple@mailman.dynamicsoft.com To Subscribe: http://mailman.dynamicsoft.com/mailman/listinfo/simple Archive: Archive: http://mailman.dynamicsoft.com/pipermail/simple Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 2543) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compatible with the requirements detailed in RFC 2779 and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. The primary work of this group will be to generate: 1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779 and in CPIM. The extension will document the mappings from its operations to CPIM. 2. One or more proposed standard SIP extensions documenting a subscription and notification service within SIP, used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM. The extension will document the mappings from its operations to CPIM. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that new security capabilities are needed from SIP, the group will seek to define such extensions within the SIP working group, and then use them here. The working group will operate in close cooperation with the IMPP working group, which will be completing CPIM in parallel. The working group will also cooperate with any other groups defined to standardize other presence and IM systems, to ensure maximum sharing of information and avoid reinvention of the wheel. The working group will cooperate with the SIP working group, soliciting reviews to ensure its extensions meet SIPs requirements. The working group will also collaborate with SIP and PINT to ensure consistent operation of the SUBSCRIBE and NOTIFY method across the other applications being defined for its use. From jdrosen@dynamicsoft.com Thu Feb 1 03:50:55 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11459 for ; Thu, 1 Feb 2001 03:50:55 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA11671; Thu, 1 Feb 2001 03:53:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 03:47:22 -0500 Message-ID: From: Jonathan Rosenberg To: "'Christian Huitema'" , Ben Campbell , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Multiparty IM Date: Thu, 1 Feb 2001 03:47:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2353 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: > -----Original Message----- > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > Sent: Monday, January 29, 2001 3:46 PM > To: Ben Campbell; Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Multiparty IM > > > A simple solution would be to negotiate a "chat" or "text" media, just > like we negotiate audio or video. After all, the requirements of doing > multiparty audio are about the same as the requirement of doing > multiparty chat; this go for the signalling requirements, i.e. how to > find conference members, and the transmission requirements, > i.e. whether > to use multicast groups, transmission server, or some form of ad hoc > replication. We would thus have two separate solutions, simple "page > like" messages using the "message" construct, and "message sessions" > services. That has always been the intention. You can do text based chat, in a "streaming" model, using rfc2793 (text over RTP) right now, with no extensions or additional work. THe existing conferencing mechanisms will all work for that as well. However, there is a difference between the text over RTP chat and the IM we are discussing here. One is "messaging", and the other is "streaming media". Messaging is characterized by self contained messages, each of which contains an atomic message which is usefully displayed by itself, and can live by itself without any other session context. Not so for streaming media; there, the packets will contain individual letters or groups thereof, sent based on latency requirements rather than based on some notion of an atomic message. One could imagine a multiparty message session being set up much like the centrzlied conference servers in SIP. Each participant INVITEs to the same URL on a conference server. Any MESSAGE method sent to that URL is replicated to all other users who have joined the session on the server. This would allow me to trivially add multiparty IM to an existing SIP conference. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From ndramais@indigosw.com Tue Feb 6 04:38:18 2001 Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01808 for ; Tue, 6 Feb 2001 04:38:10 -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 BAA00647 for ; Tue, 6 Feb 2001 01:38:30 -0800 (PST) Message-ID: <3A7FC5F6.A5F08BF6@indigosw.com> Date: Tue, 06 Feb 2001 10:37:58 +0100 From: Nicolas Dramais Organization: Indigo Software X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SIMPLE LIST Content-Type: multipart/alternative; boundary="------------2ADB838492522EBEA05446ED" Content-Length: 6843 Subject: [Simple] Hand over of subscriptions handling from server to PUA 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: --------------2ADB838492522EBEA05446ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just a question for my good understanding of the draft-rosenberg-impp-presence-00.txt : imagine the following scenario: 1)Principal A registers and uploads to his/her proxy/presence server a list of pre-granted watchers to his/her presentity's presence service. 2)A's registration expires. (A went off-line). 3)Principal B sends a SUBSCRIBE to sip:A@presence.proxyA.com proxyA knows that A is not currently registered and decides to act as A's Presence Agent. proxyA checks the list of pre-granted watchers for A and finds in it B's sip uri. B's subscription request is directly accepted by the server in the name of A and a subscription is instantiated at server level for a duration specified in the header field of the 200 OK response sent by the server to B. 4)Principal C sends a SUBSCRIBE to sip:A@presence.proxyA.com proxyA knows that A is not currently registered and decides to act as A's Presence Agent. proxyA checks the list of pre-granted watchers for A but doesn't find C's sip uri. C's subscription request is temporarily accepted (202 OK) and the subscription request is stored at server level as 'pending authorization' to be submitted (with a QAUTH method) to Principal A's approval as soon as A becomes available. 5)Principal A registers again and is available for communications. Via his/her REGISTER request, the server is signified that A is willing to handle SUBSCRIBE and QAUTH methods (along with INVITE and MESSAGE methods). C's pending subscription request is submitted (with a QAUTH method) by the server to principal A and A approves it. A's presentity sends a 200 OK directly to C and a subscription for C is instantiated at PUA level. At this current time, there are thus 2 subscriptions active for A's presentity presence service : one granted for B and instantiated at server level and one granted for C and instantiated at PUA level. Suppose principal A changes his/her communications status (description="open" for INVITE methods changes to description="inuse"). Question: Q1)Does the draft imply that A has to send two NOTIFY : one directly to C (subscription handled at PUA level) and one to proxyA which relays it to B (subscription handled at server level) ? This statement implies thus that proxyA has to subscribe to principal A's presentity presence service. Q2)Or is it so that when principal A becomes available again, a kind of subscription transfer mechanism has to take place between the server and A's PUA so that A's PUA repatriates all subscriptions instantiated at server level. That case would mean that if principal A changes its communications status, his/her presentity would know all of the subscribed watchers and would be capable of sending all NOTIFY directly to every watcher. It might be interesting to clarify this issue in the draft. Thanks in advance for your review, N.D. -- Nicolas DRAMAIS Communications Software Engineering Indigo Software "We join the dots" ~~~~~~~~~~~~~~~~~~~~~~ 50, rue Wiertz 1050 Brussels Belgium tel.: +3222350952 fax: +3222802676 mailto:ndramais@indigosw.com ~~~~~~~~~~~~~~~~~~~~~~ http://www.indigosw.com --------------2ADB838492522EBEA05446ED Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Just a question for my good understanding of the draft-rosenberg-impp-presence-00.txt :
imagine the following scenario:
1)Principal A registers and uploads to his/her proxy/presence server a list of pre-granted watchers to his/her presentity's presence service.
2)A's registration expires. (A went off-line).
3)Principal B sends a SUBSCRIBE to sip:A@presence.proxyA.com
proxyA knows that A is not currently registered and decides to act as A's Presence Agent.
proxyA checks the list of pre-granted watchers for A and finds in it B's sip uri.
B's subscription request is directly accepted by the server in the name of A and a subscription is instantiated at server level for a duration specified in the header field of the 200 OK response sent by the server to B.
4)Principal C sends a SUBSCRIBE to sip:A@presence.proxyA.com
proxyA knows that A is not currently registered and decides to act as A's Presence Agent.
proxyA checks the list of pre-granted watchers for A but doesn't find C's sip uri.
C's subscription request is temporarily accepted (202 OK) and the subscription request is stored at server level as 'pending authorization' to be submitted (with a QAUTH method) to Principal A's approval as soon as A becomes available.
5)Principal A registers again and is available for communications. Via his/her REGISTER request, the server is signified that A is willing to handle SUBSCRIBE and QAUTH methods (along with INVITE and MESSAGE methods).
C's pending subscription request is submitted (with a QAUTH method) by the server to principal A and A approves it.
A's presentity sends a 200 OK directly to C and a subscription for C is instantiated at PUA level.

At this current time, there are thus 2 subscriptions active for A's presentity presence service :
one granted for B and instantiated at server level and one granted for C and instantiated at PUA level.
Suppose principal A changes his/her communications status (description="open" for INVITE methods changes to description="inuse").

Question:
Q1)Does the draft imply that A has to send two NOTIFY : one directly to C (subscription handled at PUA level) and one to proxyA which relays it to B (subscription handled at server level) ?
This statement implies thus that proxyA has to subscribe to principal A's presentity presence service.
Q2)Or is it so that when principal A becomes available again, a kind of subscription transfer mechanism has to take place between the server and A's PUA so that A's PUA repatriates all subscriptions instantiated at server level.
That case would mean that if principal A changes its communications status, his/her presentity would know all of the subscribed watchers and would be capable of sending all NOTIFY directly to every watcher.

It might be interesting to clarify this issue in the draft.

Thanks in advance for your review,
N.D.
--
Nicolas DRAMAIS
Communications Software Engineering
Indigo Software
"We join the dots"
~~~~~~~~~~~~~~~~~~~~~~
50, rue Wiertz
1050 Brussels
Belgium
tel.: +3222350952
fax:  +3222802676
mailto:ndramais@indigosw.com
~~~~~~~~~~~~~~~~~~~~~~
http://www.indigosw.com
  --------------2ADB838492522EBEA05446ED-- From jdrosen@dynamicsoft.com Tue Feb 13 00:18:44 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03215 for ; Tue, 13 Feb 2001 00:18:44 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA17907 for ; Tue, 13 Feb 2001 00:21:48 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR9GWT>; Tue, 13 Feb 2001 00:14:56 -0500 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Tue, 13 Feb 2001 00:14:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1084 Subject: [Simple] firewall traversal 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: Folks, Right now, the presence and IM documents are fairly silent on firewall/NAT traversal. I don't think its that hard, in fact. I wrote a draft recently on traversal for SIP for media, which is worth a look: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-00.txt Much of this is NOT needed for IM and presence, particularly, all the stuff relating to RTP. What is needed from this draft is: 1. usage of persistent TCP or TLS connections between clients and servers, initiated by the clients 2. The magic cookie contact header hack (a very generally useful feature) No special forwarders or content rewriting. Should we include some text on this in the presence and IM documents themselves? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From hgs@cs.columbia.edu Tue Feb 13 09:43:45 2001 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 JAA04664 for ; Tue, 13 Feb 2001 09:43:45 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA25144; Tue, 13 Feb 2001 09:43:44 -0500 (EST) Message-ID: <3A89481F.479A5568@cs.columbia.edu> Date: Tue, 13 Feb 2001 09:43:43 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] firewall traversal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1014 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: Jonathan Rosenberg wrote: > > Folks, > > Right now, the presence and IM documents are fairly silent on firewall/NAT > traversal. I don't think its that hard, in fact. I wrote a draft recently on > traversal for SIP for media, which is worth a look: > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-00.txt > > Much of this is NOT needed for IM and presence, particularly, all the stuff > relating to RTP. > > What is needed from this draft is: > > 1. usage of persistent TCP or TLS connections between clients and servers, > initiated by the clients > 2. The magic cookie contact header hack (a very generally useful feature) > > No special forwarders or content rewriting. > > Should we include some text on this in the presence and IM documents > themselves? Might be helpful. Also, I found that ssh port forwarding works pretty well for TCP, without (for SIP) requiring anything but a default outbound proxy configuration. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From Jon.Peterson@Level3.com Wed Feb 21 15:16:06 2001 Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09454 for ; Wed, 21 Feb 2001 15:16:05 -0500 (EST) From: Jon.Peterson@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id UAA27887 for ; Wed, 21 Feb 2001 20:15:53 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id UAA20538 for ; Wed, 21 Feb 2001 20:15:53 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Feb 2001 13:18:03 -0700 Message-ID: <6384220893BCD411BDFE0008C791B79C232DCC@N0228IDC1.oss.level3.com> To: simple@mailman.dynamicsoft.com Date: Wed, 21 Feb 2001 13:14:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1621 Subject: [Simple] SIMPLE BoF agenda 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: Enclosed find the proposed agenda for the SIMPLE BoF at 50th IETF in Minneapolis - as the WG charter is still under review, SIMPLE will meet as a BoF. The cut-off for agenda submissions is Monday the 26th, so please provide any feedback by Friday if possible. Jon Peterson Level(3) Communications ------- SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) BoF Day, Date and Time ================================================================= Chair(s): Jon Peterson (jon.peterson@level3.com) The SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) BoF session will investigate ongoing work towards the standardization of SIP for presence as a transfer protocol supported within the Common Format for Presence and Instant Messaging (CPIM) framework. Suggested reading: SIP for presence: --------------- http://search.ietf.org/internet-drafts/draft-rosenberg-impp-im-00.txt http://search.ietf.org/internet-drafts/draft-rosenberg-impp-presence-00.txt http://search.ietf.org/internet-drafts/draft-rosenberg-impp-qauth-00.txt CPIM: ----- http://www.ietf.org/rfc/rfc2779.txt http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-00.txt http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-msgfmt-00.txt SIP Events: ---------- http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-03.t xt Proposed agenda: 1. SIP for IM&P overview 2. Updates on SIP for presence drafts 3. Ongoing CPIM work (including msgfmt) and its relevance to SIP for IM&P 4. Update on working group status & charter 5. Open issues discussion - QAUTH - Firewall traversal From jundery@ubiquity.net Thu Feb 22 04:01:49 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA11407 for ; Thu, 22 Feb 2001 04:01:48 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 22 Feb 2001 09:01:48 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA03895; Thu, 22 Feb 2001 09:00:37 GMT Message-ID: <3A94D538.1A69B2FB@ubiquity.net> Date: Thu, 22 Feb 2001 09:00:40 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIMPLE BoF agenda References: <6384220893BCD411BDFE0008C791B79C232DCC@N0228IDC1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1007 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: Jon.Peterson@Level3.com wrote: > The SIP for Instant Messaging and Presence Leveraging Extensions > (SIMPLE) BoF session will investigate ongoing work towards the > standardization of SIP for presence as a transfer protocol supported > within the Common Format for Presence and Instant Messaging (CPIM) > framework. > > Suggested reading: > > SIP for presence: > --------------- > http://search.ietf.org/internet-drafts/draft-rosenberg-impp-im-00.txt > http://search.ietf.org/internet-drafts/draft-rosenberg-impp-presence-00.txt > http://search.ietf.org/internet-drafts/draft-rosenberg-impp-qauth-00.txt > Are these drafts going to be updated, to reflect previous discussions in San Deigo, like disallowing multiple contacts, no presence info in the 200 and an immediate NOTIFY with the info. As well as mistakes in the examples of the drafts using the "method" parameter instead of the "methods" parameter and the presence draft also describes SIP registration wrong in section 5.1 etc. James Undery From eusadam@exu.ericsson.se Thu Feb 22 10:36:16 2001 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 KAA12403 for ; Thu, 22 Feb 2001 10:36:15 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1MFaEr22515; Thu, 22 Feb 2001 09:36:14 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f1MFaEb24571; Thu, 22 Feb 2001 09:36:14 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA27820; Thu, 22 Feb 2001 09:36:10 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA07392; Thu, 22 Feb 2001 09:36:54 -0600 (CST) Message-Id: <200102221536.JAA07392@b04a24.exu.ericsson.se> Subject: Re: [Simple] SIMPLE BoF agenda To: jundery@ubiquity.net (James Undery) Date: Thu, 22 Feb 2001 09:36:54 -0600 (CST) Cc: simple@mailman.dynamicsoft.com In-Reply-To: <3A94D538.1A69B2FB@ubiquity.net> from "James Undery" at Feb 22, 2001 09:00:40 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 677 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: >Are these drafts going to be updated, to reflect previous discussions in San >Deigo, like disallowing multiple contacts, no presence info in the 200 and an >immediate NOTIFY with the info. As well as mistakes in the examples of the >drafts using the "method" parameter instead of the "methods" parameter and the >presence draft also describes SIP registration wrong in section 5.1 etc. Nope. You're to first to figure it out: we're done. (In case your sarcasm circuits aren't tuned up: of course they'll be updated.) -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From jundery@ubiquity.net Thu Feb 22 10:56:21 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA12473 for ; Thu, 22 Feb 2001 10:56:20 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 22 Feb 2001 15:56:20 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA11325; Thu, 22 Feb 2001 15:55:09 GMT Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id PAA03912; Thu, 22 Feb 2001 15:55:09 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Thu, 22 Feb 2001 15:55:09 +0000 (GMT) From: James Undery To: "Adam B. Roach" cc: simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIMPLE BoF agenda In-Reply-To: <200102221536.JAA07392@b04a24.exu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1213 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: On Thu, 22 Feb 2001, Adam B. Roach wrote: > >Are these drafts going to be updated, to reflect previous discussions in San > >Deigo, like disallowing multiple contacts, no presence info in the 200 and an > >immediate NOTIFY with the info. As well as mistakes in the examples of the > >drafts using the "method" parameter instead of the "methods" parameter and the > >presence draft also describes SIP registration wrong in section 5.1 etc. > > Nope. You're to first to figure it out: we're done. > > (In case your sarcasm circuits aren't tuned up: of course they'll be > updated.) Thanks I am quite good at spotting low wit. Will they also address the information leakage in section 4 of the presence draft, The bizare accept rule in section 5.5.1, reference where a 202 Subscription Pending in 5.5.2 comes from. Solve the cut and paste mismatch later in that section, Swap the will for a MAY in 5.6 so it is consistent with SIP (and 7.2 and examples), loosen the CSeq requirements in line with SIP. In time to read through it in a meaningful manner as the drafts expired in December, and I feel I may be wasting my time and yours pointing out mistakes that have been corrected months ago. James Undery From jdrosen@dynamicsoft.com Thu Feb 22 18:48:18 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13729 for ; Thu, 22 Feb 2001 18:48:17 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA18895; Thu, 22 Feb 2001 18:51:08 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Feb 2001 18:43:57 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , "Adam B. Roach" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] SIMPLE BoF agenda Date: Thu, 22 Feb 2001 18:43:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2500 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: > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Thursday, February 22, 2001 10:55 AM > To: Adam B. Roach > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] SIMPLE BoF agenda > > > > Thanks I am quite good at spotting low wit. > > Will they also address the information leakage in section 4 of the > presence draft, The bizare accept rule in section 5.5.1, > reference where a > 202 Subscription Pending in 5.5.2 comes from. Solve the cut and paste > mismatch later in that section, Swap the will for a MAY in > 5.6 so it is > consistent with SIP (and 7.2 and examples), loosen the CSeq > requirements > in line with SIP. > > In time to read through it in a meaningful manner as the > drafts expired in > December, and I feel I may be wasting my time and yours pointing out > mistakes that have been corrected months ago. Please, lets all be civil. I will do an update on the presence and IM specs before the deadline. I'll incorporate whatever comments I get. I am also going to pare down the draft a lot, since it was written largely to sell the concept. I will not update the others, since the work is being picked up by IMPP (the presence data format), or its not relevant, or significant discussion is needed. That is the case for the QAUTH spec. Frankly, QAUTH makes me queasy. Its nothing more than an authorization mechanism. The difference between it and others of that sort are that this one is between a network server and an end system. However, it has not a lot to do with SIP per se. There is a lot more that one might want from an authorization protocol of this sort (for how long are they authorized, for what kind of presence data, etc.), and none of this is in SIP now. There are no sessions here, nor does the protocol run between domains (two things that might make using SIP more appealing). One of the open issues, then, is whether this is the right approach to use. The questions to ask are: 1. do we need a presence server to client authorization protocol at all, 2. if so, what do we want it to do (requirements), 2. should it be based on SIP -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From hgs@cs.columbia.edu Fri Feb 23 04:01:17 2001 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 EAA15173 for ; Fri, 23 Feb 2001 04:01:17 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id EAA18260; Fri, 23 Feb 2001 04:01:16 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id EAA01951; Fri, 23 Feb 2001 04:01:11 -0500 (EST) Message-ID: <3A965203.10F69560@cs.columbia.edu> Date: Fri, 23 Feb 2001 04:05:23 -0800 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'James Undery'" , "Adam B. Roach" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIMPLE BoF agenda References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1164 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: > Frankly, QAUTH makes me queasy. Its nothing more than an authorization > mechanism. The difference between it and others of that sort are that this > one is between a network server and an end system. However, it has not a lot > to do with SIP per se. There is a lot more that one might want from an > authorization protocol of this sort (for how long are they authorized, for > what kind of presence data, etc.), and none of this is in SIP now. There are > no sessions here, nor does the protocol run between domains (two things that > might make using SIP more appealing). One of the open issues, then, is > whether this is the right approach to use. > > The questions to ask are: > > 1. do we need a presence server to client authorization protocol at all, > 2. if so, what do we want it to do (requirements), > 2. should it be based on SIP > Given the wide variety of things one might want to express, I suspect that a form of program, such as an extended version of CPL, is much more appropriate for the cases where the subscription arrives while no user agent is available. If a user agent is available, normal SUBSCRIBE processing would seem to work. From jundery@ubiquity.net Fri Feb 23 05:02:20 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA15354 for ; Fri, 23 Feb 2001 05:02:19 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 23 Feb 2001 10:02:18 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA22617; Fri, 23 Feb 2001 10:01:07 GMT Message-ID: <3A9634E5.4E8E69E6@ubiquity.net> Date: Fri, 23 Feb 2001 10:01:09 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Adam B. Roach" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIMPLE BoF agenda References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3291 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: Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Sent: Thursday, February 22, 2001 10:55 AM > > To: Adam B. Roach > > Cc: simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] SIMPLE BoF agenda > > > > > > > > Thanks I am quite good at spotting low wit. > > > > Will they also address the information leakage in section 4 of the > > presence draft, The bizare accept rule in section 5.5.1, > > reference where a > > 202 Subscription Pending in 5.5.2 comes from. Solve the cut and paste > > mismatch later in that section, Swap the will for a MAY in > > 5.6 so it is > > consistent with SIP (and 7.2 and examples), loosen the CSeq > > requirements > > in line with SIP. > > > > Please, lets all be civil. Sorry, I was obliquely referencing Oscar Wilde ("Sarcasm is the lowest form of wit") and any attribution of wit is a compliment if you check the dictionary. The unhelpful nature of the response to my first posting of known issues made the second of ones that I don't know if anyone is aware of terse, if you'd like more info on any of them I'd be glad to detail them. > > > I will do an update on the presence and IM specs before the deadline. I'll > incorporate whatever comments I get. I am also going to pare down the draft > a lot, since it was written largely to sell the concept. I will not update > the others, since the work is being picked up by IMPP (the presence data > format), or its not relevant, or significant discussion is needed. That is > the case for the QAUTH spec. > > Frankly, QAUTH makes me queasy. Its nothing more than an authorization > mechanism. The difference between it and others of that sort are that this > one is between a network server and an end system. However, it has not a lot > to do with SIP per se. There is a lot more that one might want from an > authorization protocol of this sort (for how long are they authorized, for > what kind of presence data, etc.), and none of this is in SIP now. There are > no sessions here, nor does the protocol run between domains (two things that > might make using SIP more appealing). One of the open issues, then, is > whether this is the right approach to use. > > The questions to ask are: > > 1. do we need a presence server to client authorization protocol at all, I think this has to be yes. > > 2. if so, what do we want it to do (requirements), My preference would be to have an additional 'simple' mechanism for describing accept and ban lists with what to do with unknowns. I'd also suggest that headers were taken on trust (Oh dear) or a single presence server had to be able to authenticate all the parties involved, with the user able to specify which policy to use. This would simplify the implementation greatly by avoiding many of the harder authentication problems that could be solved by a more complete mechanism. It also prevents people using Subscribe and watching when 202s become a 600 response to guess when people are online. > > 2. should it be based on SIP I wouldn't be competent to say, although if it is used I'd look at draft-nystrom-http-sasl-00.txt as a potential basis of an extension to SIP to help with the inter domain problem. My gut feeling is something else would be James Undery From jdrosen@dynamicsoft.com Fri Feb 23 11:58:19 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16425 for ; Fri, 23 Feb 2001 11:58:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA25162; Fri, 23 Feb 2001 12:01:26 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 11:54:14 -0500 Message-ID: From: Jonathan Rosenberg To: Nicolas Dramais , SIMPLE LIST Subject: RE: [Simple] Hand over of subscriptions handling from server to P UA Date: Fri, 23 Feb 2001 11:54:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 4390 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: Sorry for the delayed response... I just cannot keep up with email volumes any longer. >-----Original Message----- >From: Nicolas Dramais [mailto:ndramais@indigosw.com] >Sent: Tuesday, February 06, 2001 4:38 AM >To: SIMPLE LIST >Subject: [Simple] Hand over of subscriptions handling from server to PUA > > > >Just a question for my good understanding of the draft-rosenberg-impp-presence-00.txt : >imagine the following scenario: >1)Principal A registers and uploads to his/her proxy/presence server a list of pre-granted >watchers to his/her presentity's presence service. >2)A's registration expires. (A went off-line). >3)Principal B sends a SUBSCRIBE to sip:A@presence.proxyA.com >proxyA knows that A is not currently registered and decides to act as A's Presence Agent. >proxyA checks the list of pre-granted watchers for A and finds in it B's sip uri. >B's subscription request is directly accepted by the server in the name of A and a >subscription is instantiated at server level for a duration specified in the header field >of the 200 OK response sent by the server to B. >4)Principal C sends a SUBSCRIBE to sip:A@presence.proxyA.com >proxyA knows that A is not currently registered and decides to act as A's Presence Agent. >proxyA checks the list of pre-granted watchers for A but doesn't find C's sip uri. >C's subscription request is temporarily accepted (202 OK) and the subscription request is >stored at server level as 'pending authorization' to be submitted (with a QAUTH method) to >Principal A's approval as soon as A becomes available. >5)Principal A registers again and is available for communications. Via his/her REGISTER >request, the server is signified that A is willing to handle SUBSCRIBE and QAUTH methods >(along with INVITE and MESSAGE methods). >C's pending subscription request is submitted (with a QAUTH method) by the server to >principal A and A approves it. >A's presentity sends a 200 OK directly to C and a subscription for C is instantiated at PUA >level. This is the problem. It wouldn't do that. The QAUTH request is not from C to A; its from the server to A. The response, therefore, goes only to the server. So, at this point, both B and C's subscription to A are active AT THE SERVER. >At this current time, there are thus 2 subscriptions active for A's presentity presence >service : >one granted for B and instantiated at server level and one granted for C and instantiated >at PUA level. See above; they are both at the server. >Suppose principal A changes his/her communications status (description="open" for INVITE >methods changes to description="inuse"). >Question: >Q1)Does the draft imply that A has to send two NOTIFY : one directly to C (subscription >handled at PUA level) and one to proxyA which relays it to B (subscription handled at >server level) ? >This statement implies thus that proxyA has to subscribe to principal A's presentity >presence service. This inconsistency is resolved by my explanation above. >Q2)Or is it so that when principal A becomes available again, a kind of subscription >transfer mechanism has to take place between the server and A's PUA so that A's PUA >repatriates all subscriptions instantiated at server level. The transfer of subscriptions happens during refresh. The best way to think about it is as follows. At any time, the presence server can simply discard the subscription completely, so that it knows nothing about it any longer. Furthermore, the presence server can act as a proxy for a SUBSCRIBE request, forwarding it to the user rather than terminating. The process of "transferring" a subscription from the server to the PUA by the server dropping its active subscription AND acting as a proxy at the instant a subscription refresh message arrives. In essence, the transfer of control is not a protocol issue, but rather an implementation behavior that is possible because of the soft-state nature of subscriptions, and because of the routing capabilities of SIP. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Fri Feb 23 16:54:50 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17204 for ; Fri, 23 Feb 2001 16:54:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA29843; Fri, 23 Feb 2001 16:57:55 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 16:50:42 -0500 Message-ID: From: Jonathan Rosenberg To: James Undery Cc: "Adam B. Roach" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] SIMPLE BoF agenda Date: Fri, 23 Feb 2001 16:50:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 6527 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: Henning wrote: > > The questions to ask are: > > > > 1. do we need a presence server to client authorization > protocol at all, > > 2. if so, what do we want it to do (requirements), > > 2. should it be based on SIP > > > > Given the wide variety of things one might want to express, I suspect > that a form of program, such as an extended version of CPL, > is much more > appropriate for the cases where the subscription arrives while no user > agent is available. If a user agent is available, normal SUBSCRIBE > processing would seem to work. Well, not really. The semantics of subscribe mean something very specific. If you accept a subscribe (ie., send 200 OK), that means you are the presence agent for that subscription. So, we cannot just proxy the subscribe to the PUA, and if it says 200 OK, then the subscription is authorized. It may be authorized, but it also creates subscription state in the PUA, and thats not what we want here. > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Friday, February 23, 2001 5:01 AM > To: Jonathan Rosenberg > Cc: Adam B. Roach; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] SIMPLE BoF agenda > > The unhelpful nature of the response to my first posting of > known issues made > the second of ones that I don't know if anyone is aware of > terse, if you'd like > more info on any of them I'd be glad to detail them. Please. > > 1. do we need a presence server to client authorization > protocol at all, > > I think this has to be yes. I also think this is probably true. If our minimal goal is to be able to emulate existing systems, we need this, as they do it. > > > > > 2. if so, what do we want it to do (requirements), > > My preference would be to have an additional 'simple' > mechanism for describing > accept and ban lists with what to do with unknowns. Thats different. There are two different authorization things going on here, which can be referred to as a push and a pull. In the pull model, the PUA tells the server, AHEAD OF TIME, about ban lists, accept lists, etc. I think web will probably be the predominant mechanism for this, and I don't feel that we need a formal protocol for it. Pull is different. In this case, a subscription has arrived, and the server wants to explicitly ask (i.e., pull info from the PUA), if its allowed. This does require a protocol, and it is what we are talking about with QAUTH. > I'd also > suggest that > headers were taken on trust (Oh dear) or a single presence > server had to be able > to authenticate all the parties involved, with the user able > to specify which > policy to use. Not sure I follow this. Can you rephrase? > > This would simplify the implementation greatly by avoiding > many of the harder > authentication problems that could be solved by a more > complete mechanism. It > also prevents people using Subscribe and watching when 202s > become a 600 > response to guess when people are online. No, no. You wouldn't do this. I think 202, plus the 4xx and 5xx, are pretty much the only response codes that one should ever send. So, the call flow would be: SUB PA PUA SUB ---------------> QUATH 202 --------------> <--------------- 200 <-------------- NOTIFY <--------------- 200 OK ----------------> That is, every subscription generates a 202 right away. THen, if the PUA is around for a QAUTH, one is sent. If not, none is sent. If the PUA comes on at a later time, it sends a QAUTH at that point. If the QAUTH results in a negative response, no notify is ever sent. This really completely decouples the subscription processing from the authorization, which is, IMHO, highly desirable. So, what are some of the requirements for such a QAUTH mechanism: 1. indicate the subscriber 2. indicate the presentity 3. indicate the requested duration of the subscription 4. indicate any parameters of the subscription (like filters and the like) 5. allow for a response that rejects the subscription 6. allow for a response that accepts the subscription 7. allow for a response that indicates a duration for the acceptance 8. allow for a response which indicates that the subscriber should be rejected for a duration of X (this is needed, else refreshes will always trigger a new QAUTH) 9. indicate that the PA authenticated the identity of the originator One of the nastier problems is this: what if we want the PUA to authenticate the subscriber using a shared secret? It would be a handy feature. In this case, we couldn't easily use HTTP digest, since the exchange is actually between the subscriber and the presence agent. We might be able to get around that by having the PA shuttle the challenge and the credentials back and forth between the subscriber and PUA (so that a challenge in the QAUTH response is passed to the subscriber, and the credentials in the re-subscription are passed to the PUA in the QAUTH). But, the response to the challenge in the QAUTH is wrong, since the hash covers the method, which is QAUTH here, not SUBSCRIBE. S/MIME might work better, since we could include in the QAUTH the original SUBSCRIBE and the signature over it. > > > > 2. should it be based on SIP > > I wouldn't be competent to say, although if it is used I'd look at > draft-nystrom-http-sasl-00.txt as a potential basis of an > extension to SIP to > help with the inter domain problem. My gut feeling is > something else would be would be....? Not sure what you mean by interdomain problem. As a general thing, adding some SASL support to sip would be a good idea. It would buy us authentication using a few additional mechanisms; of course, we still wouldn't be able to do e2e confidentiality or integrity, since in sasl, these work only over point to point connections. The SIP SASL draft would probably look identical to draft-nystrom-http-sasl. For QAUTH, I suppose sasl would help in that we would have a few options at our disposal that would allow the presence agent to authenticate itself to the PUA, and vice a versa (of course, http digest already allows this). -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From paf@cisco.com Sun Feb 25 22:03:58 2001 Received: from cisco.com (nordic.cisco.com [144.254.116.47]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25247 for ; Sun, 25 Feb 2001 22:03:57 -0500 (EST) Received: from [10.21.51.77] (herbst-isdn4.cisco.com [10.21.51.77]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id EAA28312; Mon, 26 Feb 2001 04:03:07 +0100 (MET) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com (Unverified) Message-Id: Date: Sun, 25 Feb 2001 19:01:32 -0800 To: Robert Sparks , Jon Peterson , simple@mailman.dynamicsoft.com From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Cc: impp@iastate.edu, Ned Freed Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Content-Length: 4906 Subject: [Simple] SIMPLE Charter 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: The IESG has reviewed the SIMPLE charter and found it to be OK overall. As chairs, the IESG had a choice between four people, and did choose: Robert Sparks Jon Peterson However, there was some concern that congestion issues might need to be addressed. In order to deal with this the following wording change was suggested: Old: 1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779 and in CPIM. The extension will document the mappings from its operations to CPIM. New: 1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779 and in CPIM and in BCP 41 (so that the transport implications of the extension with respect to network congestion are considered in the design). The extension will document the mappings from its operations to CPIM. The IESG also felt that the SIP WG owns the protocol robustness issue rather than PINT (especially since PINT has been closed down), so in the text The working group will also collaborate with SIP and PINT to ensure consistent operation of the SUBSCRIBE and NOTIFY method across the other applications being defined for its use. s/SIP and PINT/the SIP WG/ As a result, the charter being accepted by the IESG is the following. Comments and questions to myself. paf SIP for Instant Messaging and Presence Leveraging (simple) ---------------------------------------------------------- Charter Last Modified: 30-Jan-01 Current Status: Proposed Working Group Chair(s): Robert Sparks Jon Peterson Applications Area Director(s): Ned Freed Patrik Faltstrom Applications Area Advisor: Patrik Faltstrom Mailing Lists: General Discussion:simple@mailman.dynamicsoft.com To Subscribe: http://mailman.dynamicsoft.com/mailman/listinfo/simple Archive: Archive: http://mailman.dynamicsoft.com/pipermail/simple Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 2543) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compatible with the requirements detailed in RFC 2779 and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. The primary work of this group will be to generate: 1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779 and in CPIM and in BCP 41 (so that the transport implications of the extension with respect to network congestion are considered in the design). The extension will document the mappings from its operations to CPIM. 2. One or more proposed standard SIP extensions documenting a subscription and notification service within SIP, used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM. The extension will document the mappings from its operations to CPIM. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that new security capabilities are needed from SIP, the group will seek to define such extensions within the SIP working group, and then use them here. The working group will operate in close cooperation with the IMPP working group, which will be completing CPIM in parallel. The working group will also cooperate with any other groups defined to standardize other presence and IM systems, to ensure maximum sharing of information and avoid reinvention of the wheel. The working group will cooperate with the SIP working group, soliciting reviews to ensure its extensions meet SIPs requirements. The working group will also collaborate with the SIP WG to ensure consistent operation of the SUBSCRIBE and NOTIFY method across the other applications being defined for its use. Goals and Milestones: Mar 01 Submission of Extensions for Instant Messaging to IESG May 01 Submission of Extensions for Presence to IESG From jundery@ubiquity.net Mon Feb 26 05:15:02 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA00447 for ; Mon, 26 Feb 2001 05:15:01 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 26 Feb 2001 10:15:00 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA12041; Mon, 26 Feb 2001 10:13:47 GMT Message-ID: <3A9A2C64.132C1976@ubiquity.net> Date: Mon, 26 Feb 2001 10:13:57 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIMPLE BoF agenda References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 7529 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: Jonathan Rosenberg wrote: > Henning wrote: > > > The questions to ask are: > > > > > > 1. do we need a presence server to client authorization > > protocol at all, > > > 2. if so, what do we want it to do (requirements), > > > 2. should it be based on SIP > > > > > > > Given the wide variety of things one might want to express, I suspect > > that a form of program, such as an extended version of CPL, > > is much more > > appropriate for the cases where the subscription arrives while no user > > agent is available. If a user agent is available, normal SUBSCRIBE > > processing would seem to work. > > Well, not really. The semantics of subscribe mean something very specific. > If you accept a subscribe (ie., send 200 OK), that means you are the > presence agent for that subscription. So, we cannot just proxy the subscribe > to the PUA, and if it says 200 OK, then the subscription is authorized. It > may be authorized, but it also creates subscription state in the PUA, and > thats not what we want here. I think Henning was thinking of something similar to what I was suggesting. (Comments below) > > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > > 2. if so, what do we want it to do (requirements), > > > > My preference would be to have an additional 'simple' > > mechanism for describing > > accept and ban lists with what to do with unknowns. > > Thats different. There are two different authorization things going on here, > which can be referred to as a push and a pull. In the pull model, the PUA > tells the server, AHEAD OF TIME, about ban lists, accept lists, etc. I think > web will probably be the predominant mechanism for this, and I don't feel > that we need a formal protocol for it. But I do think a common format for describing this would be useful so PUA from one vendor can use Presence servers from other vendors. Hennings suggestion of a modified version of CPL could be applied here e.g. I don't want anyone from domain.com to subscribe to me but if they come from myorganisation.com let them. Filtering on the event they are subscribing to would be useful as well. I'd second this as a good idea. > > > Pull is different. In this case, a subscription has arrived, and the server > wants to explicitly ask (i.e., pull info from the PUA), if its allowed. This > does require a protocol, and it is what we are talking about with QAUTH. Yes, however, I was thinking about authentication generally. Apart from issues of trust and authentication QAUTH suffers from transaction timeouts i.e. a PUA comes online and is sent a QAUTH the user has to respond before the transaction times out. (I now this issue was raised before!) This is why I thinking about push mechanisms, beacause QAUTH gets messy and really requires a second new method to work. (The server sends a QAUTH and gets a 202 back, when the user allows or disallows the subscription the new method is used to communicate the result. This is very ugly.) > > > I'd also > > suggest that > > headers were taken on trust (Oh dear) or a single presence > > server had to be able > > to authenticate all the parties involved, with the user able > > to specify which > > policy to use. > > Not sure I follow this. Can you rephrase? For example with CPL the To and From headers are taken as trusted, if authentication is required it is assumed to have happened elsewhere, it is difficult to see with out PKI how arbitrary subscribers can be authenticated. The simplicication I'd consider follows the current system where a single entity (ICQ, MSN etc) handles all the authentication. A user of the presenceservice.com can assume jo@presenceservice.com is jo@presenceservice.com because they have both authenticated them selves with one server. For personal use I'd be happy to take headers on trust when issuing my presence info, however at work I only want authenticated users to access the info. (But this is back in push policies). > If the QAUTH results in a negative response, no notify is ever sent. > > This really completely decouples the subscription processing from the > authorization, which is, IMHO, highly desirable. > > So, what are some of the requirements for such a QAUTH mechanism: > > 1. indicate the subscriber > 2. indicate the presentity > 3. indicate the requested duration of the subscription > 4. indicate any parameters of the subscription (like filters and the like) > 5. allow for a response that rejects the subscription > 6. allow for a response that accepts the subscription > 7. allow for a response that indicates a duration for the acceptance > 8. allow for a response which indicates that the subscriber should be > rejected for a duration of X (this is needed, else refreshes will always > trigger a new QAUTH) > 9. indicate that the PA authenticated the identity of the originator > > One of the nastier problems is this: what if we want the PUA to authenticate > the subscriber using a shared secret? It would be a handy feature. In this > case, we couldn't easily use HTTP digest, since the exchange is actually > between the subscriber and the presence agent. We might be able to get > around that by having the PA shuttle the challenge and the credentials back > and forth between the subscriber and PUA (so that a challenge in the QAUTH > response is passed to the subscriber, and the credentials in the > re-subscription are passed to the PUA in the QAUTH). But, the response to > the challenge in the QAUTH is wrong, since the hash covers the method, which > is QAUTH here, not SUBSCRIBE. > > S/MIME might work better, since we could include in the QAUTH the original > SUBSCRIBE and the signature over it. You still have the problem of how to request the credentials as the subscriber will have seen the 202. > > > > > > > > 2. should it be based on SIP > > > > I wouldn't be competent to say, although if it is used I'd look at > > draft-nystrom-http-sasl-00.txt as a potential basis of an > > extension to SIP to > > help with the inter domain problem. My gut feeling is > > something else would be > > would be....? In an ideal world PKI would solve this, the subscriber signing the contact and a timestamp (or something similar that verifies the user, location to send the NOTIFYs to and prevents replay). Unfortunately SIP appears to be a bad choice, certainly with the currently proposed QAUTH mechanism. An almost tongue in cheek response would be for the server to SUBSCRIBE to the PUA to get Authentication results in a NOTIFY to solve all but the shared secret (between the PUA and subscriber) problem. > > Not sure what you mean by interdomain problem. It is what you are discussing above when the server can't authenticate a subscriber for a PUA (or they wished to use a shared secret outside of knowledge of the server). > > > As a general thing, adding some SASL support to sip would be a good idea. It > would buy us authentication using a few additional mechanisms; of course, we > still wouldn't be able to do e2e confidentiality or integrity, since in > sasl, these work only over point to point connections. The SIP SASL draft > would probably look identical to draft-nystrom-http-sasl. > > For QAUTH, I suppose sasl would help in that we would have a few options at > our disposal that would allow the presence agent to authenticate itself to > the PUA, and vice a versa (of course, http digest already allows this). Although HTTP digest does rely on shared secret, which is its biggest problem for me. James Undery From jdrosen@dynamicsoft.com Tue Feb 27 02:27:37 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03779 for ; Tue, 27 Feb 2001 02:27:37 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA21279; Tue, 27 Feb 2001 02:30:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 02:30:07 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] SIMPLE BoF agenda Date: Tue, 27 Feb 2001 02:30:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 6207 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: > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Monday, February 26, 2001 5:14 AM > To: Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] SIMPLE BoF agenda > > > My preference would be to have an additional 'simple' > > > mechanism for describing > > > accept and ban lists with what to do with unknowns. > > > > Thats different. There are two different authorization > things going on here, > > which can be referred to as a push and a pull. In the pull > model, the PUA > > tells the server, AHEAD OF TIME, about ban lists, accept > lists, etc. I think > > web will probably be the predominant mechanism for this, > and I don't feel > > that we need a formal protocol for it. > > But I do think a common format for describing this would be > useful so PUA from > one vendor can use Presence servers from other vendors. > Hennings suggestion of a > modified version of CPL could be applied here e.g. I don't > want anyone from > domain.com to subscribe to me but if they come from > myorganisation.com let them. > Filtering on the event they are subscribing to would be > useful as well. I'd > second this as a good idea. I agree that we may want a policy language for presence. The motivations for this are similar to CPL, but not as strong. We are not talking about end users creating presence services; we are talking about end users defining access controls (I appreciate that the difference is small). This could be done through a web page, requiring no standards. As the definition of access controls become more complex, a standardized middleware, perhaps even as a CPL extension, is probably a good idea. That still remains a different issue than what we are talking about here, which is the presence server explicitly asking if a particular user can subscribe at the time of subscription. > > Pull is different. In this case, a subscription has > arrived, and the server > > wants to explicitly ask (i.e., pull info from the PUA), if > its allowed. This > > does require a protocol, and it is what we are talking > about with QAUTH. > > Yes, however, I was thinking about authentication generally. > Apart from issues > of trust and authentication QAUTH suffers from transaction > timeouts i.e. a PUA > comes online and is sent a QAUTH the user has to respond > before the transaction > times out. (I now this issue was raised before!) This is why > I thinking about > push mechanisms, beacause QAUTH gets messy and really > requires a second new > method to work. (The server sends a QAUTH and gets a 202 > back, when the user > allows or disallows the subscription the new method is used > to communicate the > result. This is very ugly.) So, are you saying some kind of pull mechanism, sip or not, isn't needed? Or, are you saying that the pull mecahnism shouldn't be sip? > > > > > > I'd also > > > suggest that > > > headers were taken on trust (Oh dear) or a single presence > > > server had to be able > > > to authenticate all the parties involved, with the user able > > > to specify which > > > policy to use. > > > > Not sure I follow this. Can you rephrase? > > For example with CPL the To and From headers are taken as trusted, if > authentication is required it is assumed to have happened > elsewhere, it is > difficult to see with out PKI how arbitrary subscribers can > be authenticated. > The simplicication I'd consider follows the current system > where a single entity > (ICQ, MSN etc) handles all the authentication. A user of the > presenceservice.com > can assume jo@presenceservice.com is jo@presenceservice.com > because they have > both authenticated them selves with one server. We are not designing a monolothic system. We are designing a distributed one. We cannot take this for granted. > > For personal use I'd be happy to take headers on trust when > issuing my presence > info, however at work I only want authenticated users to > access the info. (But > this is back in push policies). There are two things here. FIrst, is defining access controls based on authentication levels, and the second, is how authentication is done. The first can be addressed through a policy language (and indeed, Jiri Kuthan had proposed CPL extensions for exactly this). In the second, the PGP stuff allows for the request to be signed on behalf of a third party, so that the originating presence domain could sign the subscription, validating that it believes the subscriber is who they say they are. > > > If the QAUTH results in a negative response, no notify is ever sent. That is not clear. I am going to send a separate note on this issue. > > One of the nastier problems is this: what if we want the > PUA to authenticate > > the subscriber using a shared secret? It would be a handy > feature. In this > > case, we couldn't easily use HTTP digest, since the > exchange is actually > > between the subscriber and the presence agent. We might be > able to get > > around that by having the PA shuttle the challenge and the > credentials back > > and forth between the subscriber and PUA (so that a > challenge in the QAUTH > > response is passed to the subscriber, and the credentials in the > > re-subscription are passed to the PUA in the QAUTH). But, > the response to > > the challenge in the QAUTH is wrong, since the hash covers > the method, which > > is QAUTH here, not SUBSCRIBE. > > > > S/MIME might work better, since we could include in the > QAUTH the original > > SUBSCRIBE and the signature over it. > > You still have the problem of how to request the credentials > as the subscriber > will have seen the 202. Well, in the case of S/MIME, the presence server would have responded with a 401 first, and then only sent a 202 after an authenticated request was sent. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Tue Feb 27 02:33:46 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03814 for ; Tue, 27 Feb 2001 02:33:46 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA21345 for ; Tue, 27 Feb 2001 02:36:56 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 02:36:18 -0500 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Tue, 27 Feb 2001 02:36:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1922 Subject: [Simple] immediate notify issue 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: Folks, I've encountered a privacy issue surrounding the current methodology of immediately generating a NOTIFY on a successful subscription. We have agreed that a SUBSCRIBE will pretty much always result in a 202 whether its accepted or not. This way, the subscriber cannot obtain any information about whether the presentity is online or offline, based on the response code or delays in receiving the response. We have also agreed that the presence data is not included in the response to subscribe, and rather, in an immediate notify. This was for aligment with CPIM. However, there is now a problem with the notify. A client could determine whether the PUA was online, or whether its subscription was accepted, based on when a NOTIFY arrives (a slightly delayed one indicates they are online and authorized the subscription; one that never arrives likely means they are offline or the subscription was rejected). To handle this, we may need to mandate that the presence agent generate an immediate NOTIFY, containing the current state of the presentity. In all cases, the presence document in this message contain a valid state for the presentity. If a subscription was pending or rejected, the state would indicate that the presentity was unavailable. If a subscription was accepted, it would indicate the actual state, which could also be unavailable. The key is that the presence document returned in the case of a pending subscription be a valid one that can't be distinguished from one I might get if my subscription were accepted. Thoughts? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From ndramais@indigosw.com Tue Feb 27 05:14:52 2001 Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04248 for ; Tue, 27 Feb 2001 05:14:52 -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 CAA29464 for ; Tue, 27 Feb 2001 02:15:14 -0800 (PST) Message-ID: <3A9B7E0E.FFDBF785@indigosw.com> Date: Tue, 27 Feb 2001 11:14:38 +0100 From: Nicolas Dramais Organization: Indigo Software X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] immediate notify issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3186 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: Jonathan Rosenberg wrote: > Folks, > > I've encountered a privacy issue surrounding the current methodology of > immediately generating a NOTIFY on a successful subscription. > > We have agreed that a SUBSCRIBE will pretty much always result in a 202 > whether its accepted or not. This way, the subscriber cannot obtain any > information about whether the presentity is online or offline, based on the > response code or delays in receiving the response. We have also agreed that > the presence data is not included in the response to subscribe, and rather, > in an immediate notify. This was for aligment with CPIM. My thought is that a NOTIFY shall be used only to signify a *change* in a presentity's communication status. I find it somehow misleading to use it to transport a current, unmodified communications status as answer to a SUBSCRIBE. I'd rather prefer to specify in CPIM that setting the current presence info in a response to a SUBSCRIBE is optional and that when done (e.g. for IM independent Presence service) it eliminates the need for an immediate NOTIFY. > > > However, there is now a problem with the notify. A client could determine > whether the PUA was online, or whether its subscription was accepted, based > on when a NOTIFY arrives (a slightly delayed one indicates they are online > and authorized the subscription; one that never arrives likely means they > are offline or the subscription was rejected). > > To handle this, we may need to mandate that the presence agent generate an > immediate NOTIFY, containing the current state of the presentity. In all > cases, the presence document in this message contain a valid state for the > presentity. If a subscription was pending or rejected, the state would > indicate that the presentity was unavailable. My thought is if a subscription is rejected or pending, no presence info at all should be provided and no NOTIFY should be wasted just to say so. This is again somehow misleading. Again, it could be solved in the CPIM by specifying presence info in responses as optional. > If a subscription was > accepted, it would indicate the actual state, which could also be > unavailable. The key is that the presence document returned in the case of a > pending subscription be a valid one that can't be distinguished from one I > might get if my subscription were accepted. > > Thoughts? > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple -- Nicolas DRAMAIS Communications Software Engineering Indigo Software "We join the dots" ~~~~~~~~~~~~~~~~~~~~~~ 50, rue Wiertz 1050 Brussels Belgium tel.: +3222350952 fax: +3222802676 mailto:ndramais@indigosw.com ~~~~~~~~~~~~~~~~~~~~~~ http://www.indigosw.com From jundery@ubiquity.net Tue Feb 27 07:23:25 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id HAA04588 for ; Tue, 27 Feb 2001 07:23:24 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 27 Feb 2001 12:23:22 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA10380; Tue, 27 Feb 2001 12:22:17 GMT Message-ID: <3A9B9BFC.F949C270@ubiquity.net> Date: Tue, 27 Feb 2001 12:22:20 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIMPLE BoF agenda References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4505 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: Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > But I do think a common format for describing this would be > > useful so PUA from > > one vendor can use Presence servers from other vendors. > > Hennings suggestion of a > > modified version of CPL could be applied here e.g. I don't > > want anyone from > > domain.com to subscribe to me but if they come from > > myorganisation.com let them. > > Filtering on the event they are subscribing to would be > > useful as well. I'd > > second this as a good idea. > > I agree that we may want a policy language for presence. The motivations for > this are similar to CPL, but not as strong. We are not talking about end > users creating presence services; we are talking about end users defining > access controls (I appreciate that the difference is small). This could be > done through a web page, requiring no standards. As the definition of access > controls become more complex, a standardized middleware, perhaps even as a > CPL extension, is probably a good idea. Definitely. > > Yes, however, I was thinking about authentication generally. > > Apart from issues > > of trust and authentication QAUTH suffers from transaction > > timeouts i.e. a PUA > > comes online and is sent a QAUTH the user has to respond > > before the transaction > > times out. (I now this issue was raised before!) This is why > > I thinking about > > push mechanisms, beacause QAUTH gets messy and really > > requires a second new > > method to work. (The server sends a QAUTH and gets a 202 > > back, when the user > > allows or disallows the subscription the new method is used > > to communicate the > > result. This is very ugly.) > > So, are you saying some kind of pull mechanism, sip or not, isn't needed? > Or, are you saying that the pull mecahnism shouldn't be sip? I really think using the current QAUTH proposition is far from ideal and if it can't be improved something else (non SIP based) should be considered. The transaction time-out issue is a real killer, I'd be interested in comments on using Subscribe and Notify for pull mechanism (my only concern at the moment is horrendous recursion) > > > > For example with CPL the To and From headers are taken as trusted, if > > authentication is required it is assumed to have happened > > elsewhere, it is > > difficult to see with out PKI how arbitrary subscribers can > > be authenticated. > > The simplicication I'd consider follows the current system > > where a single entity > > (ICQ, MSN etc) handles all the authentication. A user of the > > presenceservice.com > > can assume jo@presenceservice.com is jo@presenceservice.com > > because they have > > both authenticated them selves with one server. > > We are not designing a monolothic system. We are designing a distributed > one. We cannot take this for granted. I was trying to propose a simple trust model (trivial) authentication could be designed for as the fully distributed strongly authenticated model is a frightening prospect to design and implement. (And may be overkill for some peoples needs.) I do realise the full proposal is a far harder prospect. > > For personal use I'd be happy to take headers on trust when > > issuing my presence > > info, however at work I only want authenticated users to > > access the info. (But > > this is back in push policies). > > There are two things here. FIrst, is defining access controls based on > authentication levels, and the second, is how authentication is done. The > first can be addressed through a policy language (and indeed, Jiri Kuthan > had proposed CPL extensions for exactly this). Which IIRC involved the scripts authenticating calls something that scared me at the time. > In the second, the PGP stuff > allows for the request to be signed on behalf of a third party, so that the > originating presence domain could sign the subscription, validating that it > believes the subscriber is who they say they are. I don't understand "originating presence domain" in terms of it signing a subscription, do you mean a outbound proxy for the subscribers PUA. > > > > You still have the problem of how to request the credentials > > as the subscriber > > will have seen the 202. > > Well, in the case of S/MIME, the presence server would have responded with a > 401 first, and then only sent a 202 after an authenticated request was sent. Which again suggests the need for a CPL style policy language. From jundery@ubiquity.net Tue Feb 27 08:08:34 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id IAA04721 for ; Tue, 27 Feb 2001 08:08:33 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 27 Feb 2001 13:08:31 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA29031; Tue, 27 Feb 2001 13:07:21 GMT Message-ID: <3A9BA68C.10D44846@ubiquity.net> Date: Tue, 27 Feb 2001 13:07:24 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicolas Dramais CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] immediate notify issue References: <3A9B7E0E.FFDBF785@indigosw.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2908 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: Nicolas Dramais wrote: > Jonathan Rosenberg wrote: > > > Folks, > > > > I've encountered a privacy issue surrounding the current methodology of > > immediately generating a NOTIFY on a successful subscription. > > > > We have agreed that a SUBSCRIBE will pretty much always result in a 202 > > whether its accepted or not. This way, the subscriber cannot obtain any > > information about whether the presentity is online or offline, based on the > > response code or delays in receiving the response. We have also agreed that > > the presence data is not included in the response to subscribe, and rather, > > in an immediate notify. This was for aligment with CPIM. > > My thought is that a NOTIFY shall be used only to signify a *change* in a > presentity's communication status. > I find it somehow misleading to use it to transport a current, unmodified > communications status as answer to a SUBSCRIBE. > I'd rather prefer to specify in CPIM that setting the current presence info in a > response to a SUBSCRIBE is optional and that when done (e.g. for IM independent > Presence service) it eliminates the need for an immediate NOTIFY. The CPIM document doesn't say that a response must contain any info, but it does specify that an immediate notify follows a successful response to a subscription. > > However, there is now a problem with the notify. A client could determine > > whether the PUA was online, or whether its subscription was accepted, based > > on when a NOTIFY arrives (a slightly delayed one indicates they are online > > and authorized the subscription; one that never arrives likely means they > > are offline or the subscription was rejected). > > > > To handle this, we may need to mandate that the presence agent generate an > > immediate NOTIFY, containing the current state of the presentity. In all > > cases, the presence document in this message contain a valid state for the > > presentity. If a subscription was pending or rejected, the state would > > indicate that the presentity was unavailable. > > My thought is if a subscription is rejected or pending, no presence info at all > should be provided and no NOTIFY should be wasted just to say so. > This is again somehow misleading. > Again, it could be solved in the CPIM by specifying presence info in responses > as optional. > > > If a subscription was > > accepted, it would indicate the actual state, which could also be > > unavailable. The key is that the presence document returned in the case of a > > pending subscription be a valid one that can't be distinguished from one I > > might get if my subscription were accepted. > > > > Thoughts? I agree with Jonathan here, although I think the IMPP WG should be informed of this problem as it will affect any WGs that comply with CPIM.. (I haven't cross posted as I'll have to check the IMPP mail achive to see if this has been mentioned). James Undery From eusadam@exu.ericsson.se Tue Feb 27 10:49:30 2001 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 KAA05160 for ; Tue, 27 Feb 2001 10:49:29 -0500 (EST) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1RFnQi20889; Tue, 27 Feb 2001 09:49:26 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f1RFj5116869; Tue, 27 Feb 2001 09:45:05 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA00380; Tue, 27 Feb 2001 09:49:26 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA13159; Tue, 27 Feb 2001 09:50:10 -0600 (CST) Message-Id: <200102271550.JAA13159@b04a24.exu.ericsson.se> Subject: Re: [Simple] immediate notify issue To: jdrosen@dynamicsoft.com (Jonathan Rosenberg) Date: Tue, 27 Feb 2001 09:50:10 -0600 (CST) Cc: simple@mailman.dynamicsoft.com ('simple@mailman.dynamicsoft.com') In-Reply-To: from "Jonathan Rosenberg" at Feb 27, 2001 02:36:17 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 969 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: >To handle this, we may need to mandate that the presence agent generate an >immediate NOTIFY, containing the current state of the presentity. In all >cases, the presence document in this message contain a valid state for the >presentity. If a subscription was pending or rejected, the state would >indicate that the presentity was unavailable. If a subscription was >accepted, it would indicate the actual state, which could also be >unavailable. The key is that the presence document returned in the case of a >pending subscription be a valid one that can't be distinguished from one I >might get if my subscription were accepted. > >Thoughts? This seems like a sound solution to me. And it's applicable to events in general, not just presence... I'll include a discussion of this in the next SUB/NOT draft. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From huitema@exchange.microsoft.com Tue Feb 27 12:20:40 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05427 for ; Tue, 27 Feb 2001 12:20:39 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 27 Feb 2001 09:00:45 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 Feb 2001 08:59:51 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Tue, 27 Feb 2001 08:59:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4653.0 content-class: urn:content-classes:message Subject: RE: [Simple] immediate notify issue MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Feb 2001 08:59:50 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] immediate notify issue Thread-Index: AcCgkU85ksnPpIADQ9WIDbtoQiP2wQATJHAw From: "Christian Huitema" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 27 Feb 2001 16:59:51.0068 (UTC) FILETIME=[B2E17DC0:01C0A0DE] Content-Length: 1100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA05427 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: > However, there is now a problem with the notify. A client > could determine whether the PUA was online, or whether its > subscription was accepted, based on when a NOTIFY arrives (a > slightly delayed one indicates they are online and authorized > the subscription; one that never arrives likely means they > are offline or the subscription was rejected). Uh, why is this a problem, exactly? The privacy property we aimed for was that there is no difference between "being offline" and "rejecting the subscription." Arguably, we have achieved that with the decoupling of subscribe and notify. There is indeed a way to build up more byzantine protections, e.g. providing partial information to some parties, even providing false information when you really want to hide. But you don't want to modify the protocol to achieve that -- it looks to me as an implementation choice. Come to think of it, a protocol modification would be somewhat comical; think of a Notify parameter that mentions that "how, by the way, the information in the message may or may not be true..." -- Christian Huitema From jundery@ubiquity.net Tue Feb 27 12:48:05 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA05516 for ; Tue, 27 Feb 2001 12:48:04 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 27 Feb 2001 17:48:02 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA17634; Tue, 27 Feb 2001 17:46:50 GMT Message-ID: <3A9BE80D.9A84D4B@ubiquity.net> Date: Tue, 27 Feb 2001 17:46:53 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] immediate notify issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1345 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: Christian Huitema wrote: > > However, there is now a problem with the notify. A client > > could determine whether the PUA was online, or whether its > > subscription was accepted, based on when a NOTIFY arrives (a > > slightly delayed one indicates they are online and authorized > > the subscription; one that never arrives likely means they > > are offline or the subscription was rejected). > > Uh, why is this a problem, exactly? The privacy property we aimed for > was that there is no difference between "being offline" and "rejecting > the subscription." Well there is a difference, a notify is required immediately by the CPIM draft if the subscribe is successful, a 202 I'd consider success of a kind. If you consider the three cases 1 I subscribe get a 202 and no notify for the presentity 2 I subscribe get a 202 and a notify that they are offline 3 I subscribe get a 202 and a notify that they are online case 3 my subscription was accepted. case 2 my subscription may not be accepted but I know the presentity is offline. case 1 my subscription was rejected and I know the presentity is online. In both cases the presentity did not want me to have presence info I know its presence state. Jonathan's suggestion fixes this so "being offline" and being rejected are identical as cases 1 and 2 become identical. James Undery From mhammer@cisco.com Tue Feb 27 13:01:57 2001 Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05570 for ; Tue, 27 Feb 2001 13:01:55 -0500 (EST) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA24114; Tue, 27 Feb 2001 13:01:47 -0500 (EST) Received: from mhammer-nt.cisco.com (hrn3-dhcp-161-44-93-108.cisco.com [161.44.93.108]) by cia.cisco.com (Mirapoint) with ESMTP id ABM01869; Tue, 27 Feb 2001 13:01:45 -0500 (EST) Message-Id: <4.3.2.7.2.20010227125349.00ad8ee0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Feb 2001 13:01:13 -0800 To: Nicolas Dramais , "'simple@mailman.dynamicsoft.com'" From: hammer michael Subject: Re: [Simple] immediate notify issue In-Reply-To: <3A9B7E0E.FFDBF785@indigosw.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 4030 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: What is the primary purpose of the Subscribe and Notify? Is the intent to make information available to the subscriber, or are you trying to create some gray area in between? Also, if there is an always-on terminal, is the semantic to indicate the presence of the terminal or the user? Likewise, if the user is always there, but does or does not want to communicate? I would assume that the event being subscribed would be specific and either accepted or rejected, no gray areas. Mike At 11:14 AM 02/27/2001 +0100, Nicolas Dramais wrote: >Jonathan Rosenberg wrote: > > > Folks, > > > > I've encountered a privacy issue surrounding the current methodology of > > immediately generating a NOTIFY on a successful subscription. > > > > We have agreed that a SUBSCRIBE will pretty much always result in a 202 > > whether its accepted or not. This way, the subscriber cannot obtain any > > information about whether the presentity is online or offline, based on the > > response code or delays in receiving the response. We have also agreed that > > the presence data is not included in the response to subscribe, and rather, > > in an immediate notify. This was for aligment with CPIM. > >My thought is that a NOTIFY shall be used only to signify a *change* in a >presentity's communication status. >I find it somehow misleading to use it to transport a current, unmodified >communications status as answer to a SUBSCRIBE. >I'd rather prefer to specify in CPIM that setting the current presence >info in a >response to a SUBSCRIBE is optional and that when done (e.g. for IM >independent >Presence service) it eliminates the need for an immediate NOTIFY. > > > > > > > However, there is now a problem with the notify. A client could determine > > whether the PUA was online, or whether its subscription was accepted, based > > on when a NOTIFY arrives (a slightly delayed one indicates they are online > > and authorized the subscription; one that never arrives likely means they > > are offline or the subscription was rejected). > > > > To handle this, we may need to mandate that the presence agent generate an > > immediate NOTIFY, containing the current state of the presentity. In all > > cases, the presence document in this message contain a valid state for the > > presentity. If a subscription was pending or rejected, the state would > > indicate that the presentity was unavailable. > >My thought is if a subscription is rejected or pending, no presence info >at all >should be provided and no NOTIFY should be wasted just to say so. >This is again somehow misleading. >Again, it could be solved in the CPIM by specifying presence info in responses >as optional. > > > If a subscription was > > accepted, it would indicate the actual state, which could also be > > unavailable. The key is that the presence document returned in the case > of a > > pending subscription be a valid one that can't be distinguished from one I > > might get if my subscription were accepted. > > > > Thoughts? > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > >-- >Nicolas DRAMAIS >Communications Software Engineering >Indigo Software >"We join the dots" >~~~~~~~~~~~~~~~~~~~~~~ >50, rue Wiertz >1050 Brussels >Belgium >tel.: +3222350952 >fax: +3222802676 >mailto:ndramais@indigosw.com >~~~~~~~~~~~~~~~~~~~~~~ >http://www.indigosw.com > > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple From rohan@cisco.com Tue Feb 27 13:25:31 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05651 for ; Tue, 27 Feb 2001 13:25:30 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA21302; Tue, 27 Feb 2001 10:25:47 -0800 (PST) Received: from buckthorn-nt.cisco.com (dhcp-128-107-142-89.cisco.com [128.107.142.89]) by imop.cisco.com (Mirapoint) with ESMTP id AAL79868 (AUTH rmahy); Tue, 27 Feb 2001 10:25:28 -0800 (PST) Message-Id: <5.0.0.25.2.20010227102001.01cc73c0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 27 Feb 2001 10:23:11 -0800 To: James Undery From: Rohan Mahy Subject: Re: [Simple] immediate notify issue Cc: Christian Huitema , Jonathan Rosenberg , simple@mailman.dynamicsoft.com In-Reply-To: <3A9BE80D.9A84D4B@ubiquity.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 1814 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: If I don't care about this property, is it still legal for me to configure my client to 403 the SUBSCRIBE? (say my client will only accept subscribes from folks that have ever sent me a message or invite) thanks, -rohan At 09:46 AM 2/27/01, James Undery wrote: >Christian Huitema wrote: > > > > However, there is now a problem with the notify. A client > > > could determine whether the PUA was online, or whether its > > > subscription was accepted, based on when a NOTIFY arrives (a > > > slightly delayed one indicates they are online and authorized > > > the subscription; one that never arrives likely means they > > > are offline or the subscription was rejected). > > > > Uh, why is this a problem, exactly? The privacy property we aimed for > > was that there is no difference between "being offline" and "rejecting > > the subscription." > >Well there is a difference, a notify is required immediately by the CPIM >draft if the subscribe is successful, a 202 I'd consider success of a kind. >If you consider the three cases > >1 I subscribe get a 202 and no notify for the presentity >2 I subscribe get a 202 and a notify that they are offline >3 I subscribe get a 202 and a notify that they are online > >case 3 my subscription was accepted. >case 2 my subscription may not be accepted but I know the presentity is >offline. >case 1 my subscription was rejected and I know the presentity is online. > >In both cases the presentity did not want me to have presence info I know >its presence state. Jonathan's suggestion fixes this so "being offline" and >being rejected are identical as cases 1 and 2 become identical. > >James Undery > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple From jdrosen@dynamicsoft.com Wed Feb 28 06:26:48 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08278 for ; Wed, 28 Feb 2001 06:26:47 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA06847; Wed, 28 Feb 2001 06:29:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 06:29:14 -0500 Message-ID: From: Jonathan Rosenberg To: "'Rohan Mahy'" , James Undery Cc: Christian Huitema , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] immediate notify issue Date: Wed, 28 Feb 2001 06:29:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2829 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: > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Tuesday, February 27, 2001 1:23 PM > To: James Undery > Cc: Christian Huitema; Jonathan Rosenberg; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] immediate notify issue > > > If I don't care about this property, is it still legal for me > to configure > my client to 403 the SUBSCRIBE? (say my client will only > accept subscribes > from folks that have ever sent me a message or invite) Yes. I think this is fine, but be warned that the client will know you have rejected the subscription. Probably 600 is better than 403, but I have to think about that. James wrote: > >Well there is a difference, a notify is required immediately > by the CPIM > >draft if the subscribe is successful, a 202 I'd consider > success of a kind. > >If you consider the three cases > > > >1 I subscribe get a 202 and no notify for the presentity > >2 I subscribe get a 202 and a notify that they are offline > >3 I subscribe get a 202 and a notify that they are online > > > >case 3 my subscription was accepted. > >case 2 my subscription may not be accepted but I know the > presentity is > >offline. > >case 1 my subscription was rejected and I know the > presentity is online. > > > >In both cases the presentity did not want me to have > presence info I know > >its presence state. Jonathan's suggestion fixes this so > "being offline" and > >being rejected are identical as cases 1 and 2 become identical. Thats it, exactly. The key is that the immediate notify contains presence data which reveals little yet is also a valid piece of presence data that they might get if the subscription was accepted. Nicolas wrote: > My thought is that a NOTIFY shall be used only to signify a > *change* in a > presentity's communication status. > I find it somehow misleading to use it to transport a > current, unmodified > communications status as answer to a SUBSCRIBE. > I'd rather prefer to specify in CPIM that setting the current > presence info in a > response to a SUBSCRIBE is optional and that when done (e.g. > for IM independent > Presence service) it eliminates the need for an immediate NOTIFY. This is incorrect. The whole reason that notify's contain a full view of state is that they make sense at any point in time. Its important to tell the subscriber the state when the subscription is accepted. This is a standard feature on existing presence systems. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From Harald@Alvestrand.no Wed Feb 28 06:34:10 2001 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08317 for ; Wed, 28 Feb 2001 06:34:09 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id MAA24269; Wed, 28 Feb 2001 12:33:58 +0100 Message-Id: <4.3.2.7.2.20010228122958.0ec132d0@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Feb 2001 12:33:56 +0100 To: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" From: Harald Alvestrand Subject: Re: [Simple] immediate notify issue In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 862 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: What the discussion seems to boil down to is that the model of having subscriptions' fate being decided by the client whose presence is being reported is not workable. A more workable model seems to be: - Presence service decides on the fate of a subscription, and either responds with a failure to the subscribe, or sends an OK and a NOTIFY. - Presence service informs presentity of subscription as soon as the presentity is available (or when it asks for the info). Note: it should probably also be informed of unsuccessful subscriptions. - Presentity can order the presence service to cancel a subscription at any time. No special cases. But a CPL might be desirable for the presentity to inform the presence service about its desires. -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From jdrosen@dynamicsoft.com Wed Feb 28 06:50:44 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08415 for ; Wed, 28 Feb 2001 06:50:44 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA07082; Wed, 28 Feb 2001 06:53:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 06:53:13 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] SIMPLE BoF agenda Date: Wed, 28 Feb 2001 06:53:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 3591 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: > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, February 27, 2001 7:22 AM > To: Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] SIMPLE BoF agenda > > > > Yes, however, I was thinking about authentication generally. > > > Apart from issues > > > of trust and authentication QAUTH suffers from transaction > > > timeouts i.e. a PUA > > > comes online and is sent a QAUTH the user has to respond > > > before the transaction > > > times out. (I now this issue was raised before!) This is why > > > I thinking about > > > push mechanisms, beacause QAUTH gets messy and really > > > requires a second new > > > method to work. (The server sends a QAUTH and gets a 202 > > > back, when the user > > > allows or disallows the subscription the new method is used > > > to communicate the > > > result. This is very ugly.) > > > > So, are you saying some kind of pull mechanism, sip or not, > isn't needed? > > Or, are you saying that the pull mecahnism shouldn't be sip? > > I really think using the current QAUTH proposition is far > from ideal and if it > can't be improved something else (non SIP based) should be > considered. The > transaction time-out issue is a real killer, I'd be > interested in comments on > using Subscribe and Notify for pull mechanism (my only > concern at the moment is > horrendous recursion). Well, there is a way to use SUB/NOT that would allow us to converge the push/pull mechanisms. Consider the set of subscribers to a presentity as a piece of dynamically changing state. Call this state the "subscription list for presentity A". I can easily imagine that it is possible for entities (typically, presentity A) to subscribe to this state. So, when it changes (such as when a new subscriber X asks for a subscription to A), this causes a NOTIFY to be sent to anyone watching "subscription list for presentity A" - probably A. Now, at this time, A can choose to push a new policy list to the server. This new policy list is one which blocks X. Whenever a presence server receives a new policy, it automatically runs that policy against existing subscriptions. Note that we even proposed a data format for representing the state of "subscription lists". See http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-watcherinfo- 00.txt. So, lets assume that we use a CPL variant to express policy. Assume http is used to push these policies into the server. The flow would look like this: subscriber presence server presentity SUB ------------------------------> 202 OK <------------------------------ NOTIFY w/ subscription state ----------------------------------> 200 OK <---------------------------------- http POST w/ CPL <---------------------------------- 200 OK -----------------------------------> In this way, policy information is always passed using a single mechanism, but it is triggered using a NOTIFY. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From ndramais@indigosw.com Wed Feb 28 08:09:14 2001 Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08712 for ; Wed, 28 Feb 2001 08:09:14 -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 FAA27319; Wed, 28 Feb 2001 05:09:39 -0800 (PST) Message-ID: <3A9CF865.BAA5005C@indigosw.com> Date: Wed, 28 Feb 2001 14:08:53 +0100 From: Nicolas Dramais Organization: Indigo Software X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: SIMPLE LIST Subject: Re: [Simple] immediate notify issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3805 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: Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Tuesday, February 27, 2001 1:23 PM > > To: James Undery > > Cc: Christian Huitema; Jonathan Rosenberg; > > simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] immediate notify issue > > > > > > If I don't care about this property, is it still legal for me > > to configure > > my client to 403 the SUBSCRIBE? (say my client will only > > accept subscribes > > from folks that have ever sent me a message or invite) > > Yes. I think this is fine, but be warned that the client will know you have > rejected the subscription. Probably 600 is better than 403, but I have to > think about that. > > James wrote: > > >Well there is a difference, a notify is required immediately > > by the CPIM > > >draft if the subscribe is successful, a 202 I'd consider > > success of a kind. > > >If you consider the three cases > > > > > >1 I subscribe get a 202 and no notify for the presentity > > >2 I subscribe get a 202 and a notify that they are offline > > >3 I subscribe get a 202 and a notify that they are online > > > > > >case 3 my subscription was accepted. > > >case 2 my subscription may not be accepted but I know the > > presentity is > > >offline. > > >case 1 my subscription was rejected and I know the > > presentity is online. > > > > > >In both cases the presentity did not want me to have > > presence info I know > > >its presence state. Jonathan's suggestion fixes this so > > "being offline" and > > >being rejected are identical as cases 1 and 2 become identical. > > Thats it, exactly. The key is that the immediate notify contains presence > data which reveals little yet is also a valid piece of presence data that > they might get if the subscription was accepted. > > Nicolas wrote: > > My thought is that a NOTIFY shall be used only to signify a > > *change* in a > > presentity's communication status. > > I find it somehow misleading to use it to transport a > > current, unmodified > > communications status as answer to a SUBSCRIBE. > > I'd rather prefer to specify in CPIM that setting the current > > presence info in a > > response to a SUBSCRIBE is optional and that when done (e.g. > > for IM independent > > Presence service) it eliminates the need for an immediate NOTIFY. > > This is incorrect. The whole reason that notify's contain a full view of > state is that they make sense at any point in time. Its important to tell > the subscriber the state when the subscription is accepted. Well, of course. This is not under question but what I really meant was : what is the reason why, in the CPIM draft, we cannot use the body of the 200 OK to insert the current state of the presentity when the subscription is accepted (like was done in the draft-rosenberg-impp-presence-00.txt) instead of mandating the use of immediate notify's for doing so ? In the latter draft, a 6xx response with no body is returned in case the subscription is rejected and when a change occurs in the state, notify's are used to convey a full view of the new state. What makes things different for the CPIM draft ? Thanks in advance for your explanation, Nicolas. > This is a > standard feature on existing presence systems. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From jundery@ubiquity.net Wed Feb 28 09:20:58 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA08910 for ; Wed, 28 Feb 2001 09:20:57 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 28 Feb 2001 14:20:55 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA11014; Wed, 28 Feb 2001 14:19:51 GMT Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id OAA02593; Wed, 28 Feb 2001 14:19:52 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Wed, 28 Feb 2001 14:19:52 +0000 (GMT) From: James Undery To: Nicolas Dramais cc: Jonathan Rosenberg , SIMPLE LIST Subject: Re: [Simple] immediate notify issue In-Reply-To: <3A9CF865.BAA5005C@indigosw.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1337 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: On Wed, 28 Feb 2001, Nicolas Dramais wrote: > > > Jonathan Rosenberg wrote: > > > > > This is incorrect. The whole reason that notify's contain a full view of > > state is that they make sense at any point in time. Its important to tell > > the subscriber the state when the subscription is accepted. > > Well, of course. This is not under question but what I really meant was : what > is the reason why, in the CPIM draft, we cannot use the body of the 200 OK to > insert the current state of the presentity when the subscription is accepted > (like was done in the draft-rosenberg-impp-presence-00.txt) instead of > mandating the use of immediate notify's for doing so ? > In the latter draft, a 6xx response with no body is returned in case the > subscription is rejected and when a change occurs in the state, notify's are > used to convey a full view of the new state. > What makes things different for the CPIM draft ? There are all sorts of problems with the response containing the state info. Firstly what if the contact in the subscribe is a different PUA, it won't get the state. Secondly what if the subscription forks to multiple presence servers, the subscribing client will only see the state from one location. (There are probably other reasons I can't remember offhand butthis should be enough.) James Undery From jdrosen@dynamicsoft.com Wed Feb 28 09:25:40 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08955 for ; Wed, 28 Feb 2001 09:25:40 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA08570; Wed, 28 Feb 2001 09:28:47 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 09:28:07 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Nicolas Dramais Cc: Jonathan Rosenberg , SIMPLE LIST Subject: RE: [Simple] immediate notify issue Date: Wed, 28 Feb 2001 09:28:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2503 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: > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Wednesday, February 28, 2001 9:20 AM > To: Nicolas Dramais > Cc: Jonathan Rosenberg; SIMPLE LIST > Subject: Re: [Simple] immediate notify issue > > > > > On Wed, 28 Feb 2001, Nicolas Dramais wrote: > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > This is incorrect. The whole reason that notify's contain > a full view of > > > state is that they make sense at any point in time. Its > important to tell > > > the subscriber the state when the subscription is accepted. > > > > Well, of course. This is not under question but what I > really meant was : what > > is the reason why, in the CPIM draft, we cannot use the > body of the 200 OK to > > insert the current state of the presentity when the > subscription is accepted > > (like was done in the draft-rosenberg-impp-presence-00.txt) > instead of > > mandating the use of immediate notify's for doing so ? > > In the latter draft, a 6xx response with no body is > returned in case the > > subscription is rejected and when a change occurs in the > state, notify's are > > used to convey a full view of the new state. > > What makes things different for the CPIM draft ? > > There are all sorts of problems with the response containing the state > info. Firstly what if the contact in the subscribe is a > different PUA, it > won't get the state. Secondly what if the subscription forks > to multiple > presence servers, the subscribing client will only see the > state from one > location. (There are probably other reasons I can't remember offhand > butthis should be enough.) I also think it provides a nice clean separation between different functions. Point one above that James makes is a benefit of this separation. The biggie is that this is how CPIM works. CPIM was a compromise abstract protocol, which all the camps agreed to adhere to. As a working group, we are required by our charter to develop a protocol compliant to CPIM. I am not about to go and question that consensus on CPIM, especially since there are technical advantages in any case. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jundery@ubiquity.net Wed Feb 28 10:44:03 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA09169 for ; Wed, 28 Feb 2001 10:44:02 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 28 Feb 2001 15:44:00 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA15016; Wed, 28 Feb 2001 15:42:56 GMT Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id PAA03113; Wed, 28 Feb 2001 15:42:57 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Wed, 28 Feb 2001 15:42:57 +0000 (GMT) From: James Undery To: Harald Alvestrand cc: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] immediate notify issue In-Reply-To: <4.3.2.7.2.20010228122958.0ec132d0@127.0.0.1> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2201 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: On Wed, 28 Feb 2001, Harald Alvestrand wrote: > What the discussion seems to boil down to is that the model of having > subscriptions' fate being decided by the client whose presence is being > reported is not workable. > > A more workable model seems to be: > > - Presence service decides on the fate of a subscription, and either responds > with a failure to the subscribe, or sends an OK and a NOTIFY. > > - Presence service informs presentity of subscription as soon as the > presentity is available (or when it asks for the info). > Note: it should probably also be informed of unsuccessful subscriptions. > > - Presentity can order the presence service to cancel a subscription at > any time. I don't really follow how this is different, if anything it is worse as it specifically tells you the state of the presentity rather than making you deduce it. If the presentity is offline you also get to know when they come online without doing any further work. The third point does raise a related issue about how to display current subscriptions to a subscriber without exposing presence info. (If you think I am wandering in a paranoid fantasy land here's where to turn off it's getting worse.) If subscriber can get the present list of their subscriptions and the presentity can remove them the subscriber will be able to see this, and subscribe again. I still think maintaining the facade of the user being offline and the subscription intact best protects the presentity, ideally you'd also never respond with anything other than a 200 or 202 to refreshes of existing subscriptions. As this then forces an attacker to let the subscription lapse so they can get a 600 class response indicating sometime during the life of the subscription the presentity was on line and rejected them, this could be limited by allowing the mandating of a minimum expiry time returning a 488 Not Acceptable Here be returned if the expiry on a subscription was too short. (This last bit is poorly thought out and I don't like it myself.) > > But a CPL might be desirable for the presentity to inform > the presence service about its desires. This I certainly agree with. James Undery From rohan@cisco.com Wed Feb 28 11:08:15 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09250 for ; Wed, 28 Feb 2001 11:08:14 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA07453; Wed, 28 Feb 2001 08:08:30 -0800 (PST) Received: from buckthorn-nt.cisco.com (dhcp-128-107-142-89.cisco.com [128.107.142.89]) by imop.cisco.com (Mirapoint) with ESMTP id AAL90496 (AUTH rmahy); Wed, 28 Feb 2001 08:08:12 -0800 (PST) Message-Id: <5.0.0.25.2.20010228075710.01cb16e0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 28 Feb 2001 08:06:10 -0800 To: Jonathan Rosenberg From: Rohan Mahy Subject: RE: [Simple] immediate notify issue Cc: "'Rohan Mahy'" , James Undery , Christian Huitema , Jonathan Rosenberg , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 3489 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: An immediate 403 is exactly the meaning I want to convey. I *want* the other end to know that they have hit a brick wall. There is another problem with a refected SUBSCRIBE spawning a 200 and a NOTIFY, is that this invites a clasic denial of service attack (where one message spawns multiple messages and consumes state, etc. etc.). If I just blast out SUBSCRIBEs and don't respond to the NOTIFYs, the other agent will have to retransmit the NOTIFY many times before giving up. thanks, -rohan At 03:29 AM 2/28/01, Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Rohan Mahy [mailto:rohan@cisco.com] > > Sent: Tuesday, February 27, 2001 1:23 PM > > To: James Undery > > Cc: Christian Huitema; Jonathan Rosenberg; > > simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] immediate notify issue > > > > > > If I don't care about this property, is it still legal for me > > to configure > > my client to 403 the SUBSCRIBE? (say my client will only > > accept subscribes > > from folks that have ever sent me a message or invite) > >Yes. I think this is fine, but be warned that the client will know you have >rejected the subscription. Probably 600 is better than 403, but I have to >think about that. > >James wrote: > > >Well there is a difference, a notify is required immediately > > by the CPIM > > >draft if the subscribe is successful, a 202 I'd consider > > success of a kind. > > >If you consider the three cases > > > > > >1 I subscribe get a 202 and no notify for the presentity > > >2 I subscribe get a 202 and a notify that they are offline > > >3 I subscribe get a 202 and a notify that they are online > > > > > >case 3 my subscription was accepted. > > >case 2 my subscription may not be accepted but I know the > > presentity is > > >offline. > > >case 1 my subscription was rejected and I know the > > presentity is online. > > > > > >In both cases the presentity did not want me to have > > presence info I know > > >its presence state. Jonathan's suggestion fixes this so > > "being offline" and > > >being rejected are identical as cases 1 and 2 become identical. > >Thats it, exactly. The key is that the immediate notify contains presence >data which reveals little yet is also a valid piece of presence data that >they might get if the subscription was accepted. > >Nicolas wrote: > > My thought is that a NOTIFY shall be used only to signify a > > *change* in a > > presentity's communication status. > > I find it somehow misleading to use it to transport a > > current, unmodified > > communications status as answer to a SUBSCRIBE. > > I'd rather prefer to specify in CPIM that setting the current > > presence info in a > > response to a SUBSCRIBE is optional and that when done (e.g. > > for IM independent > > Presence service) it eliminates the need for an immediate NOTIFY. > >This is incorrect. The whole reason that notify's contain a full view of >state is that they make sense at any point in time. Its important to tell >the subscriber the state when the subscription is accepted. This is a >standard feature on existing presence systems. > >-Jonathan R. >--- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 >http://www.dynamicsoft.com From jundery@ubiquity.net Wed Feb 28 11:19:22 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA09297 for ; Wed, 28 Feb 2001 11:19:21 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 28 Feb 2001 16:19:19 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA02978; Wed, 28 Feb 2001 16:18:17 GMT Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id QAA03328; Wed, 28 Feb 2001 16:18:16 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Wed, 28 Feb 2001 16:18:16 +0000 (GMT) From: James Undery To: Jonathan Rosenberg cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] SIMPLE BoF agenda In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2669 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: On Wed, 28 Feb 2001, Jonathan Rosenberg wrote: > > > > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > I really think using the current QAUTH proposition is far > > from ideal and if it > > can't be improved something else (non SIP based) should be > > considered. The > > transaction time-out issue is a real killer, I'd be > > interested in comments on > > using Subscribe and Notify for pull mechanism (my only > > concern at the moment is > > horrendous recursion). > > Well, there is a way to use SUB/NOT that would allow us to converge the > push/pull mechanisms. > > Consider the set of subscribers to a presentity as a piece of dynamically > changing state. Call this state the "subscription list for presentity A". I > can easily imagine that it is possible for entities (typically, presentity > A) to subscribe to this state. So, when it changes (such as when a new > subscriber X asks for a subscription to A), this causes a NOTIFY to be sent > to anyone watching "subscription list for presentity A" - probably A. Now, > at this time, A can choose to push a new policy list to the server. This new > policy list is one which blocks X. Whenever a presence server receives a new > policy, it automatically runs that policy against existing subscriptions. > > Note that we even proposed a data format for representing the state of > "subscription lists". See > http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-watcherinfo- > 00.txt. > > So, lets assume that we use a CPL variant to express policy. Assume http is > used to push these policies into the server. The flow would look like this: > > > subscriber presence server presentity > > SUB > ------------------------------> > > 202 OK > <------------------------------ NOTIFY w/ subscription state > ----------------------------------> > 200 OK > <---------------------------------- > http POST w/ CPL > <---------------------------------- > 200 OK > -----------------------------------> > > In this way, policy information is always passed using a single mechanism, > but it is triggered using a NOTIFY. > I think this is a better solution as with a properly configured policy list/script it would address info leakages (for those concerned with that sort of thing) by defaulting to display offline until the subscriber was accepted. James Undery From jundery@ubiquity.net Wed Feb 28 11:35:16 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA09360 for ; Wed, 28 Feb 2001 11:35:16 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 28 Feb 2001 16:35:13 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA08426; Wed, 28 Feb 2001 16:34:11 GMT Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id QAA03432; Wed, 28 Feb 2001 16:34:11 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Wed, 28 Feb 2001 16:34:11 +0000 (GMT) From: James Undery To: Rohan Mahy cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] immediate notify issue In-Reply-To: <5.0.0.25.2.20010228075710.01cb16e0@imop.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 946 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: On Wed, 28 Feb 2001, Rohan Mahy wrote: > An immediate 403 is exactly the meaning I want to convey. I *want* the > other end to know that they have hit a brick wall. Yes but this doesn't allow your friend you haven't spoken to in years to contact you. Once they're on the banned list fine it works, but how do friends get off the banned list. > > There is another problem with a refected SUBSCRIBE spawning a 200 and a > NOTIFY, is that this invites a clasic denial of service attack (where one > message spawns multiple messages and consumes state, etc. etc.). If I just > blast out SUBSCRIBEs and don't respond to the NOTIFYs, the other agent will > have to retransmit the NOTIFY many times before giving up. > This is something that could be tackled by returning 401s to the subscription (I am loathed to mention authentication as it is SIP authentication rather than the authentication surrounding subscription). James Undery From huitema@exchange.microsoft.com Wed Feb 28 12:07:13 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09485 for ; Wed, 28 Feb 2001 12:07:13 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 28 Feb 2001 09:05:12 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 28 Feb 2001 09:04:19 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 28 Feb 2001 09:04:18 -0800 content-class: urn:content-classes:message Subject: RE: [Simple] immediate notify issue MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Feb 2001 09:04:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] immediate notify issue Thread-Index: AcChfgXSkyg9wnnNRrKKuzSYsC7OPQAJ8GXw From: "Christian Huitema" To: "Harald Alvestrand" , "Jonathan Rosenberg" , X-OriginalArrivalTime: 28 Feb 2001 17:04:18.0805 (UTC) FILETIME=[7CE0AA50:01C0A1A8] Content-Length: 2774 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA09485 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: > What the discussion seems to boil down to is that the model of having > subscriptions' fate being decided by the client whose > presence is being reported is not workable. I beg to differ. There is working code today, used by millions of people that proves that this model is workable -- an example being MSN Messenger. It is in fact a major requirement of any IM system, that user have the option to explicitly approve subscriptions on a case by case basis. So, we have to reconcile several requirements: 1) Allow fine grain control by the user -- this means that, even if we were to load a program on a server, that program would not be able to conclude without an explicit interaction with the user. 2) Be able to do this in such a way that there is no difference being refusing a subscription and being offline, so as to not raise any suspicion. 3) If possible, do this without creating an opening for a DoS attack. 4) Be compatible with CPIM. Combining requirements 1 and 2 implies that there must be an immediate response from the presence manager, and that this response should be the same whether the subscription is "on hold" or "blocked", or whether the user is offline. The requirements, however, leave us the choice between two solutions: either just sending a 202 (no information provided), or sending a message state with some fake information, e.g. responding "offline" whether that is true or not. If we take the DoS attack into consideration, we get a further design requirement: that a single subscribe generates a single automatic response. This means that we should not send both a 202 and a Notify, because this is a "traffic multiplier." This means that only two solutions would be acceptable, just sending a 202, or sending a 200 that contains an embedded notification. CPIM implies that simple agents must be ready to receive a subscription acknowledgement that is essentially an empty 202, and that they will receive a Notify some time after. Some read the CPIM requirement as saying that we should send a Notify in all cases, whatever we know of the state of the user. I read it differently. The CPIM requirement apply to the CPIM gateway, not to the end system. So, if we were to just send a 202, we could very simply have the gateway send a fake Notify to the other party upon receipt of the 202, or maybe on some timer after the 202, if no notification was received before that. Alternatively, if we were to send a 200, the gateway could extract the notify informationfrom inside the 200 and carry that as a Notify. Now, if CPIM is creating the problem, it is possibly something we want to fix in CPIM. After all, the privacy requirements of APEX or PRIM should not be very different from those of SIMPLE... -- Christian Huitema From jdrosen@dynamicsoft.com Wed Feb 28 23:21:52 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11202 for ; Wed, 28 Feb 2001 23:21:52 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA19331; Wed, 28 Feb 2001 23:25:00 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 23:24:19 -0500 Message-ID: From: Jonathan Rosenberg To: "'Christian Huitema'" , Harald Alvestrand , simple@mailman.dynamicsoft.com Subject: RE: [Simple] immediate notify issue Date: Wed, 28 Feb 2001 23:24:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 3893 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: > -----Original Message----- > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > Sent: Wednesday, February 28, 2001 12:04 PM > To: Harald Alvestrand; Jonathan Rosenberg; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] immediate notify issue > > > So, we have to reconcile several requirements: > > 1) Allow fine grain control by the user -- this means that, even if we > were to load a program on a server, that program would not be able to > conclude without an explicit interaction with the user. > > 2) Be able to do this in such a way that there is no difference being > refusing a subscription and being offline, so as to not raise any > suspicion. > > 3) If possible, do this without creating an opening for a DoS attack. > > 4) Be compatible with CPIM. > > Combining requirements 1 and 2 implies that there must be an immediate > response from the presence manager, and that this response > should be the > same whether the subscription is "on hold" or "blocked", or > whether the > user is offline. The requirements, however, leave us the > choice between > two solutions: either just sending a 202 (no information provided), or > sending a message state with some fake information, e.g. responding > "offline" whether that is true or not. No, there is only one choice. If a sucessful subscription generates a NOTIFY with presence state, then a subscription that JUST generates a 202 is known to be not successful or pending. This reveals information to the subscriber. > > If we take the DoS attack into consideration, we get a further design > requirement: that a single subscribe generates a single automatic > response. This means that we should not send both a 202 and a Notify, > because this is a "traffic multiplier." This means that only two > solutions would be acceptable, just sending a 202, or sending > a 200 that > contains an embedded notification. No, what you would do is the standard sip solution for this. A presence server should be stateless for any unauthenticated requests. An authenticated subscribe would generated the 202 and then the NOTIFY. An unauthenticated subscribe generates only a 401, and no state is generated in the system. > > CPIM implies that simple agents must be ready to receive a > subscription > acknowledgement that is essentially an empty 202, and that they will > receive a Notify some time after. Some read the CPIM requirement as > saying that we should send a Notify in all cases, whatever we know of > the state of the user. I read it differently. The CPIM > requirement apply > to the CPIM gateway, not to the end system. So, if we were to > just send > a 202, we could very simply have the gateway send a fake Notify to the > other party upon receipt of the 202, or maybe on some timer after the > 202, if no notification was received before that. Alternatively, if we > were to send a 200, the gateway could extract the notify > informationfrom > inside the 200 and carry that as a Notify. The requirement to send a NOTIFY with state of the user upon successful subscription is not motivated by CPIM. Its a functional requirement of the system. In current presence systems, if I subscribe and am accepted, I get to know right away what the state of the presentity is. I shouldn't have to wait for that state to change in order to get a notify. Basically, I believe it is a functional requirement that a successful subscription cause the current state of the presentity to be sent immediately to the subscriber. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From krishna@ecrio.com Thu Mar 1 00:18:18 2001 Received: from sbserver.ecritek.com (dsl-20919168137.internetconnect.net [209.191.68.137] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11371 for ; Thu, 1 Mar 2001 00:18:17 -0500 (EST) Received: by sbserver.ecritek.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 21:33:29 -0800 Received: from krishna (64.0.163.99 [64.0.163.99]) by sbserver.ecritek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GB68J5LC; Wed, 28 Feb 2001 21:33:28 -0800 From: "Krishna (External)" To: Christian Huitema , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Message-ID: <000801c0a20e$cf494020$800a0a0a@cnchost.com> References: Subject: Re: [Simple] immediate notify issue Date: Wed, 28 Feb 2001 21:16:40 -0800 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Length: 1553 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: ----- Original Message ----- From: Christian Huitema To: Jonathan Rosenberg ; Sent: Tuesday, February 27, 2001 8:59 AM Subject: RE: [Simple] immediate notify issue > > However, there is now a problem with the notify. A client > > could determine whether the PUA was online, or whether its > > subscription was accepted, based on when a NOTIFY arrives (a > > slightly delayed one indicates they are online and authorized > > the subscription; one that never arrives likely means they > > are offline or the subscription was rejected). > > Uh, why is this a problem, exactly? The privacy property we aimed for > was that there is no difference between "being offline" and "rejecting > the subscription." Arguably, we have achieved that with the decoupling > of subscribe and notify. There is indeed a way to build up more > byzantine protections, e.g. providing partial information to some > parties, even providing false information when you really want to hide. > But you don't want to modify the protocol to achieve that -- it looks to > me as an implementation choice. Come to think of it, a protocol > modification would be somewhat comical; think of a Notify parameter that > mentions that "how, by the way, the information in the message may or > may not be true..." > > -- Christian Huitema > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From Harald@Alvestrand.no Mon Mar 5 07:27:00 2001 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00712 for ; Mon, 5 Mar 2001 07:26:59 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id NAA31102; Mon, 5 Mar 2001 13:26:47 +0100 Message-Id: <4.3.2.7.2.20010305132601.01f8b9d8@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Mar 2001 13:26:11 +0100 To: Jonathan Rosenberg , "'Christian Huitema'" , simple@mailman.dynamicsoft.com From: Harald Alvestrand Subject: RE: [Simple] immediate notify issue In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 395 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: At 23:24 28/02/2001 -0500, Jonathan Rosenberg wrote: >No, what you would do is the standard sip solution for this. A presence >server should be stateless for any unauthenticated requests. An >authenticated subscribe would generated the 202 and then the NOTIFY. authenticated or authorized? -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From Harald@Alvestrand.no Mon Mar 5 07:26:54 2001 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00707 for ; Mon, 5 Mar 2001 07:26:53 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id NAA31096; Mon, 5 Mar 2001 13:26:38 +0100 Message-Id: <4.3.2.7.2.20010305132127.023e2f50@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Mar 2001 13:25:07 +0100 To: "Christian Huitema" , "Jonathan Rosenberg" , From: Harald Alvestrand Subject: RE: [Simple] immediate notify issue In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 1286 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: At 09:04 28/02/2001 -0800, Christian Huitema wrote: > > What the discussion seems to boil down to is that the model of having > > subscriptions' fate being decided by the client whose > > presence is being reported is not workable. > >I beg to differ. There is working code today, used by millions of people >that proves that this model is workable -- an example being MSN >Messenger. It is in fact a major requirement of any IM system, that user >have the option to explicitly approve subscriptions on a case by case >basis. Christian, you obviously know more than I about this example. I would love to see you describe MSN Messenger's responses in the following cases where a WATCHER subscribes to a PRESENTITY: 1) PRESENTITY is offline, and has said that anyone can watch him 2) PRESENTITY is offline, and has said that only a limited list, which does not include WATCHER, can watch him 3) PRESENTITY is online, and answers NO to a request for subscription 4) PRESENTITY is online, and answers YES to a request for subscription 5) PRESENTITY is online, but has left terminal unattended for an hour. In particular, what does the WATCHER know, and when does he know it? -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From huitema@exchange.microsoft.com Mon Mar 5 11:50:11 2001 Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01419 for ; Mon, 5 Mar 2001 11:50:10 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 08:50:38 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 05 Mar 2001 08:50:35 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 5 Mar 2001 08:50:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4658.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] immediate notify issue Date: Mon, 5 Mar 2001 08:50:32 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] immediate notify issue Thread-Index: AcClcJ3v1y8T0e3QQSOHP3GzIl4IbgAIP8lw From: "Christian Huitema" To: "Harald Alvestrand" , "Jonathan Rosenberg" , X-OriginalArrivalTime: 05 Mar 2001 16:50:35.0363 (UTC) FILETIME=[66222330:01C0A594] Content-Length: 1635 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA01419 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: > you obviously know more than I about this example. > I would love to see you describe MSN Messenger's responses in > the following cases where a WATCHER subscribes to a PRESENTITY: > > 1) PRESENTITY is offline, and has said that anyone can watch him > > 2) PRESENTITY is offline, and has said that only a limited > list, which does > not include WATCHER, can watch him > > 3) PRESENTITY is online, and answers NO to a request for subscription > > 4) PRESENTITY is online, and answers YES to a request for subscription > > 5) PRESENTITY is online, but has left terminal unattended for an hour. > > In particular, what does the WATCHER know, and when does he know it? If you run Messenger, you can check several privacy options (click on the Tools menu, then options, then selecte the Privacy tab.) The options are organized with two lists and a checkbox: 1) the "allow" list of people who "can see my online status, can send me messages." 2) the "block" list of people who cannot see my status and cannot send me messages. 3) the checkbox that tells whether I should be alerted when someone tries to contact me. If you click this checkbox, those who try to contact you will not receive any response until you come on line and make a decision. The existence of this feature is a serious proff that "just having a piece of CPL in the server" is not good enough. Messenger also has an "appear offline" option, that let you appear off line, even if you are actually loged on. Basically, Privacy is one of the most important feature of any serious IM system -- you shall not compromise it in any way. -- Christian Huitema From jdrosen@dynamicsoft.com Mon Mar 5 12:39:46 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01581 for ; Mon, 5 Mar 2001 12:39:46 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA08510; Mon, 5 Mar 2001 12:42:56 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Mar 2001 12:42:06 -0500 Message-ID: From: Jonathan Rosenberg To: "'Harald Alvestrand'" , Jonathan Rosenberg , "'Christian Huitema'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] immediate notify issue Date: Mon, 5 Mar 2001 12:41:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1107 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: > -----Original Message----- > From: Harald Alvestrand [mailto:Harald@Alvestrand.no] > Sent: Monday, March 05, 2001 7:26 AM > To: Jonathan Rosenberg; 'Christian Huitema'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] immediate notify issue > > > At 23:24 28/02/2001 -0500, Jonathan Rosenberg wrote: > >No, what you would do is the standard sip solution for this. > A presence > >server should be stateless for any unauthenticated requests. An > >authenticated subscribe would generated the 202 and then the NOTIFY. > > authenticated or authorized? Sorry, let me try again: The server should be stateless for UNAUTHENTICATED requests. An authenticated, but UNAUTHORIZED subscribe would generate the 202 and then a NOTIFY. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From Harald@Alvestrand.no Mon Mar 5 13:58:52 2001 Received: from dokka.maxware.no (dokka.maxware.no [195.139.236.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01818 for ; Mon, 5 Mar 2001 13:58:50 -0500 (EST) Received: from HALVESTR-8KCDT.alvestrand.no (localhost [127.0.0.1]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id TAA01300; Mon, 5 Mar 2001 19:58:43 +0100 Message-Id: <4.3.2.7.2.20010305193335.05256b68@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Mar 2001 19:52:56 +0100 To: "Christian Huitema" , "Jonathan Rosenberg" , From: Harald Alvestrand Subject: RE: [Simple] immediate notify issue In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 2788 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: At 08:50 05/03/2001 -0800, Christian Huitema wrote: >If you run Messenger, you can check several privacy options (click on >the Tools menu, then options, then selecte the Privacy tab.) I don't run Messenger, so I have to guess... > The options >are organized with two lists and a checkbox: > >1) the "allow" list of people who "can see my online status, can send me >messages." >2) the "block" list of people who cannot see my status and cannot send >me messages. >3) the checkbox that tells whether I should be alerted when someone >tries to contact me. I see here that there is no real separation between the concepts of a WATCHER and a SENDER (in RFC 2778 terms). I guess that "when someone tries to contact me" also includes "when someone tries to subscribe or poll my PRESENCE INFORMATION". >If you click this checkbox, those who try to contact you will not >receive any response until you come on line and make a decision. The >existence of this feature is a serious proff that "just having a piece >of CPL in the server" is not good enough. it depends on what the CPL is allowed to do.... trying to answer my own question based on your info: > 1) PRESENTITY is offline, and has said that anyone can watch him if checkbox unmarked: subscription accepted < 1 second if checkbox marked: no response > > 2) PRESENTITY is offline, and has said that only a limited > list, which does > not include WATCHER, can watch him if checkbox unmarked: subscription rejected < 1 second if checkbox marked: no response > > 3) PRESENTITY is online, and answers NO to a request for subscription subscription rejected > 1 second > > 4) PRESENTITY is online, and answers YES to a request for subscription subscription accepted > 1 second > > 5) PRESENTITY is online, but has left terminal unattended for an hour. no response > if this is correct, a WATCHER can know in all cases whether or not the checkbox is marked (by the speed of response), if he knows a time when the PRESENTITY is certainly offline. A WATCHER can also detect (by polling) roughly when a PRESENTITY comes online, by noticing when his requests get rejected instead of disappearing in a black hole. if there is no response in 3), the situation is more ambiguous. >Messenger also has an "appear offline" option, that let you appear off >line, even if you are actually loged on. Basically, Privacy is one of >the most important feature of any serious IM system -- you shall not >compromise it in any way. I would implement this as controlling what the PRESENTITY tells the PRESENCE SERVICE....this is simpler than telling the PRESENCE SERVICE that you are online, but want to appear offline... -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From jdrosen@dynamicsoft.com Fri Mar 9 16:17:46 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16702 for ; Fri, 9 Mar 2001 16:17:45 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA05467 for ; Fri, 9 Mar 2001 16:21:01 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Mar 2001 16:20:03 -0500 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Fri, 9 Mar 2001 16:19:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A8DE.B3A8C4CE" Content-Length: 3994 Subject: [Simple] FW: I-D ACTION:draft-rosenberg-impp-presence-01.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: 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_01C0A8DE.B3A8C4CE Content-Type: text/plain; charset="iso-8859-1" Folks, As you can see, I've updated the presence draft. Next rev will be draft-ietf-simple-presence-00.txt. This is a major rewrite, to reflect alignment with the sip events stuff and cpim. There are a bunch of open issues in there, listed at the end. Comments solicited on these issues. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, March 08, 2001 6:56 AM Subject: I-D ACTION:draft-rosenberg-impp-presence-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Extensions for Presence Author(s) : J. Rosenberg Filename : draft-rosenberg-impp-presence-01.txt Pages : 39 Date : 07-Mar-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-impp-presence-01.txt 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-rosenberg-impp-presence-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-impp-presence-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C0A8DE.B3A8C4CE Content-Type: message/rfc822 To: Subject: Date: Fri, 9 Mar 2001 16:20:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0A8DE.B3A8C4CE" ------_=_NextPart_002_01C0A8DE.B3A8C4CE Content-Type: text/plain ------_=_NextPart_002_01C0A8DE.B3A8C4CE Content-Type: application/octet-stream; name="ATT31338.txt" Content-Disposition: attachment; filename="ATT31338.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010307142021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-impp-presence-01.txt ------_=_NextPart_002_01C0A8DE.B3A8C4CE Content-Type: message/external-body; site="internet-drafts"; dir="draft-rosenberg-impp-presence-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0A8DE.B3A8C4CE-- ------_=_NextPart_000_01C0A8DE.B3A8C4CE-- From rsparks@dynamicsoft.com Sun Mar 11 22:16:45 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24807 for ; Sun, 11 Mar 2001 22:16:45 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA02711 for ; Sun, 11 Mar 2001 22:20:02 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 11 Mar 2001 22:18:59 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A61A@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" Date: Sun, 11 Mar 2001 22:18:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0AAA3.2D920AE3" Content-Length: 3567 Subject: [Simple] FW: I-D ACTION:draft-rosenberg-impp-im-01.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: 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_01C0AAA3.2D920AE3 Content-Type: text/plain; charset="iso-8859-1" The IM draft has also been reworked to incorporate cpim and call out the issues we need to begin addressing. The next instance of this draft will be draft-ietf-simple-im-00. The open issues in this draft and the presence draft that Jonathan forwarded are what we will be addressing in Minneapolis. If you see any missing, post them asap. RjS -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, March 07, 2001 6:45 AM Subject: I-D ACTION:draft-rosenberg-impp-im-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Extensions for Instant Messaging Author(s) : J. Rosenberg, D. Willis, R. Sparks, B. Campbell, H. Schulzrinne, J. Lennox, B. Aboba, C. Huitema, D. Gurle, D. Oran Filename : draft-rosenberg-impp-im-01.txt Pages : 26 Date : 06-Mar-01 This document defines a SIP extension (a single new method) that supports Instant Messaging (IM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-impp-im-01.txt 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-rosenberg-impp-im-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-impp-im-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C0AAA3.2D920AE3 Content-Type: message/rfc822 To: Subject: Date: Sun, 11 Mar 2001 22:18:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0AAA3.2D920AE3" ------_=_NextPart_002_01C0AAA3.2D920AE3 Content-Type: text/plain ------_=_NextPart_002_01C0AAA3.2D920AE3 Content-Type: application/octet-stream; name="ATT28854.txt" Content-Disposition: attachment; filename="ATT28854.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010306125628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-impp-im-01.txt ------_=_NextPart_002_01C0AAA3.2D920AE3 Content-Type: message/external-body; site="internet-drafts"; dir="draft-rosenberg-impp-im-01.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0AAA3.2D920AE3-- ------_=_NextPart_000_01C0AAA3.2D920AE3-- From Jon.Peterson@Level3.com Mon Mar 12 16:10:20 2001 Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02146 for ; Mon, 12 Mar 2001 16:10:19 -0500 (EST) From: Jon.Peterson@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id VAA11139 for ; Mon, 12 Mar 2001 21:10:08 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id VAA24503 for ; Mon, 12 Mar 2001 21:10:07 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Mar 2001 14:12:21 -0700 Message-ID: <6384220893BCD411BDFE0008C791B79C232E4B@N0228IDC1.oss.level3.com> To: simple@mailman.dynamicsoft.com Date: Mon, 12 Mar 2001 14:08:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3693 Subject: [Simple] FW: WG ACTION: SIP for Instant Messaging and Presence Leveraging Extensions (simple) 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: FYI -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Monday, March 12, 2001 12:17 PM Subject: WG ACTION: SIP for Instant Messaging and Presence Leveraging Extensions (simple) A new working group has been formed in the Applications Area of the IETF. For additional information, contact the Area Directors or the WG Chair. SIP for Instant Messaging and Presence Leveraging (simple) ---------------------------------------------------------- Current Status: Active Working Group Chair(s): Robert Sparks Jon Peterson Applications Area Director(s): Ned Freed Patrik Faltstrom Applications Area Advisor: Patrik Faltstrom Mailing Lists: General Discussion:simple@mailman.dynamicsoft.com To Subscribe: http://mailman.dynamicsoft.com/mailman/listinfo/simple Archive: Archive: http://mailman.dynamicsoft.com/pipermail/simple Description of Working Group: This working group focuses on the application of the Session Initiation Protocol (SIP, RFC 2543) to the suite of services collectively known as instant messaging and presence (IMP). The IETF has committed to producing an interoperable standard for these services compatible with the requirements detailed in RFC 2779 and in the Common Presence and Instant Messaging (CPIM) specification, developed within the IMPP working group. As the most common services for which SIP is used share quite a bit in common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for (and relative maturity of) the SIP standard. The primary work of this group will be to generate: 1. A proposed standard SIP extension documenting the transport of Instant Messages in SIP, compliant to the requirements for IM outlined in RFC 2779 and in CPIM and in BCP 41 (so that the transport implications of the extension with respect to network congestion are considered in the design). The extension will document the mappings from its operations to CPIM. 2. One or more proposed standard SIP extensions documenting a subscription and notification service within SIP, used to support presence, compliant to the requirements for presence outlined in RFC 2779 and CPIM. The extension will document the mappings from its operations to CPIM. The working group will work within the framework for presence and IM described in RFC 2778. The extensions it defines must also be compliant with the SIP processes for extensions. The group cannot modify baseline SIP behavior or define a new version of SIP for IM and presence. If the group determines that new security capabilities are needed from SIP, the group will seek to define such extensions within the SIP working group, and then use them here. The working group will operate in close cooperation with the IMPP working group, which will be completing CPIM in parallel. The working group will also cooperate with any other groups defined to standardize other presence and IM systems, to ensure maximum sharing of information and avoid reinvention of the wheel. The working group will cooperate with the SIP working group, soliciting reviews to ensure its extensions meet SIPs requirements. The working group will also collaborate with the SIP WG to ensure consistent operation of the SUBSCRIBE and NOTIFY method across the other applications being defined for its use. Goals and Milestones: Mar 01 Submission of Extensions for Instant Messaging to IESG May 01 Submission of Extensions for Presence to IESG From rsparks@dynamicsoft.com Wed Mar 14 16:44:59 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09744 for ; Wed, 14 Mar 2001 16:44:59 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA11251 for ; Wed, 14 Mar 2001 16:48:15 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Mar 2001 16:47:08 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A638@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: simple@mailman.dynamicsoft.com Date: Wed, 14 Mar 2001 16:47:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5365 Subject: [Simple] gathering open items 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: Here are the open items copied from the -presence-01 and -im-01 drafts. What's known open items are missing? List discussion on any of these items this week is strongly encouraged. -------------- Presence: 1) This draft recommends that the To and From field are populated with presence URLs rather than sip URLs. Is that reasonable? Will this lead to incompatibilities in proxies? Is there any issues with CPIM if the SIP URL format is used? This depends on what components of a message are signed in CPIM. 2) Rate limitations on NOTIFY: do we want that? How do we pick a value? 5 seconds is arbitrary. 3) Merging of presence data from multiple PA has been removed. Is that OK? 4) Placing IM URLs in the Contact header of a REGISTER: is that OK? What does it mean? 5) The process of migrating subscriptions from a presence server to PUA is not likely to work in the case where subscription refreshes use tags and Route headers. So, we have a choice. Either migration is disallowed, and we keep with leg oriented subscriptions, or migration is allowed, and there is no tags or Route's associated with subscriptions. 6) Converting SIP URLs back to pres URLs. 7) The SIP to CPIM and CPIM to SIP gateways are not stateless, because of the need to maintain Route, Call-ID, CSeq, and other parameters. Perhaps we can ask CPIM to define a token value which is sent in a CPIM request and returned in a CPIM response. Would that help? 8) Need to specify how to take Contacts from REGISTER and build a presence document. One obvious thing is that the contact addresses don't go in there directly; you probably want to put the address of record, otherwise calls might not go through the proxy. IM: 1) Must a MESSAGE actually include a message? Section 5 specifies that a MESSAGE MAY contain a MIME body. Should this be MUST? Does it make sense to have a MESSAGE with no body? 2) Should support for message/cpim be mandatory in all UAs? Section 5 requires that UAs implementing MESSAGE support text/plain bodies as the lowest common denominator. Should this be message/cpim instead? Any UA wishing to support end-end signing or encryption of messages passing across simple/apex/prim boundaries MUST support message/cpim. If, however, end-end security is not desired, clients and messaging can be made a little lighter by not including the message/cpim wrapper. An unsigned message/cpim body can be created from messages from those clients when crossing a boundary that requires one. 3) message/cpim and the Accept header - Do we need text to make it clear that a UA should indicate the mime types it supports _inside_ a message/cpim body as well as supporting message/cpim? 4) Message Sessions - Several implementations of the -00 version of this draft grouped messages in a common thread by placing them in a "call-leg" (common To, From, and Call-ID). The first message sent or received in a thread established the leg. This has provided enough information to allow user interfaces to present separate threads in separate dialogs. There is some concern that there is no way to formally terminate this "call-leg". The -00 version noded that there is state at the UA associated with this notion of session, encapsulated in the Call-ID, Route headers, and CSeq numbers. A UA MAY terminate this session at any time, including after each MESSAGE. No messaging is required to terminate it. Any associated state with the session is simply discarded. The idempotency of SIP requests will ensure that if one side (side A) discards session state, and the other (side B) does not, a message from side B will appear as a new IM, and standard processing will reconstitute the session on side A. o Should we define a way to use INVITE/BYE to surround a group of MESSAGE requests that are part of a logical session? 5) What would a body in a 200 OK to a MESSAGE mean? Section 5.5 states "A 200 class response to a MESSAGE request MAY contain a body, but this will often not be the case, since these responses are generated automatically." If one were to appear, what would it mean? 6) The im: URL and RFC2543 proxies and registrars What are the implications of an im: URL showing up in the request URI in a MESSAGE request received by an RFC2543 proxy, or the To: header of a REGISTER request received by an RFC2543 registrar? 7) Providing im: URL in Contact headers - What are the ramifications of a UA providing an im: URL in a Contact: header for a REGISTER method, or a MESSAGE method? For the forseeable future, most SIP endpoints aren't going to have SRV records of the form _im._sip.host or even _sip.host pointing to them. Falling back to A records in that case seems to preclude the use of non-UDP transports. 8) Congestion control - Per the amendments made to the SIMPLE charter by the IESG prior to approval, congestion control needs attention. In particular the requirements of BCP 41 must be met by this extension. Specifying the use of transport protocols with congestion control built in, particularly with the recommendation of reuse of connections, is an option. The question is when can we use those that don't (UDP) and what needs to be done in addition to what SIP already does in that case. Among other things, this interacts with Section 8.7 9) Mapping to CPIM - This document needs to detail the mapping of this extension onto CPIM. From rsparks@dynamicsoft.com Wed Mar 14 17:13:14 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09839 for ; Wed, 14 Mar 2001 17:13:14 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA11968 for ; Wed, 14 Mar 2001 17:16:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Mar 2001 17:15:23 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A639@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Cc: simple@mailman.dynamicsoft.com Subject: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Wed, 14 Mar 2001 17:15:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 3818 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: The consensus at the end of this sub-thread, as I understand it, was to abandon the idea of QAUTH as specified in qauth-00 and look for other mechanisms (Jonathan has proposed subscribing to subscription attempts as an alternative)to obtain authentication. So, QAUTH is abandoned and new implementors should not pursue it. Where/when should work on replacing its functionality take place? I don't see that it fits under the current SIMPLE charter (feel free to argue with me). Should we table the concept for possible future consideration then, or formally boot it to the sip-events arena? (A generalized solution there would be valuable). RjS > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Wednesday, February 28, 2001 10:18 AM > To: Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] SIMPLE BoF agenda > > > > > On Wed, 28 Feb 2001, Jonathan Rosenberg wrote: > > > > > > > > > > > > -----Original Message----- > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > I really think using the current QAUTH proposition is far > > > from ideal and if it > > > can't be improved something else (non SIP based) should be > > > considered. The > > > transaction time-out issue is a real killer, I'd be > > > interested in comments on > > > using Subscribe and Notify for pull mechanism (my only > > > concern at the moment is > > > horrendous recursion). > > > > Well, there is a way to use SUB/NOT that would allow us to > converge the > > push/pull mechanisms. > > > > Consider the set of subscribers to a presentity as a piece > of dynamically > > changing state. Call this state the "subscription list for > presentity A". I > > can easily imagine that it is possible for entities > (typically, presentity > > A) to subscribe to this state. So, when it changes (such as > when a new > > subscriber X asks for a subscription to A), this causes a > NOTIFY to be sent > > to anyone watching "subscription list for presentity A" - > probably A. Now, > > at this time, A can choose to push a new policy list to the > server. This new > > policy list is one which blocks X. Whenever a presence > server receives a new > > policy, it automatically runs that policy against existing > subscriptions. > > > > Note that we even proposed a data format for representing > the state of > > "subscription lists". See > > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-imp p-watcherinfo- > 00.txt. > > So, lets assume that we use a CPL variant to express policy. Assume http is > used to push these policies into the server. The flow would look like this: > > > subscriber presence server presentity > > SUB > ------------------------------> > > 202 OK > <------------------------------ NOTIFY w/ subscription state > ----------------------------------> > 200 OK > <---------------------------------- > http POST w/ CPL > <---------------------------------- > 200 OK > -----------------------------------> > > In this way, policy information is always passed using a single mechanism, > but it is triggered using a NOTIFY. > I think this is a better solution as with a properly configured policy list/script it would address info leakages (for those concerned with that sort of thing) by defaulting to display offline until the subscriber was accepted. James Undery _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From huitema@exchange.microsoft.com Wed Mar 14 17:26:45 2001 Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09893 for ; Wed, 14 Mar 2001 17:26:44 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Wed, 14 Mar 2001 14:27:31 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 14 Mar 2001 14:27:33 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 14 Mar 2001 14:27:33 -0800 content-class: urn:content-classes:message Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Mar 2001 14:27:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Thread-Index: AcCs1MeBl8LHv6ELTiCwec6QsHHDiQAAPuSQ From: "Christian Huitema" To: "Robert Sparks" Cc: X-OriginalArrivalTime: 14 Mar 2001 22:27:33.0750 (UTC) FILETIME=[F6F2E960:01C0ACD5] Content-Length: 4496 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA09893 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: Uh, I do not recall any such consensus. We find that QAUTH is actually quite useful. > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, March 14, 2001 2:15 PM > Cc: simple@mailman.dynamicsoft.com > Subject: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) > > The consensus at the end of this sub-thread, as I understand > it, was to abandon the idea of QAUTH as specified in qauth-00 > and look for other mechanisms (Jonathan has proposed subscribing > to subscription attempts as an alternative)to obtain authentication. > > So, QAUTH is abandoned and new implementors should not pursue it. > > Where/when should work on replacing its functionality take place? > > I don't see that it fits under the current SIMPLE charter (feel free > to argue with me). Should we table the concept for possible future > consideration then, or formally boot it to the sip-events arena? (A > generalized solution there would be valuable). > > RjS > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Sent: Wednesday, February 28, 2001 10:18 AM > > To: Jonathan Rosenberg > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] SIMPLE BoF agenda > > > > > > > > > > On Wed, 28 Feb 2001, Jonathan Rosenberg wrote: > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > > > I really think using the current QAUTH proposition is far > > > > from ideal and if it > > > > can't be improved something else (non SIP based) should be > > > > considered. The > > > > transaction time-out issue is a real killer, I'd be > > > > interested in comments on > > > > using Subscribe and Notify for pull mechanism (my only > > > > concern at the moment is > > > > horrendous recursion). > > > > > > Well, there is a way to use SUB/NOT that would allow us to > > converge the > > > push/pull mechanisms. > > > > > > Consider the set of subscribers to a presentity as a piece > > of dynamically > > > changing state. Call this state the "subscription list for > > presentity A". I > > > can easily imagine that it is possible for entities > > (typically, presentity > > > A) to subscribe to this state. So, when it changes (such as > > when a new > > > subscriber X asks for a subscription to A), this causes a > > NOTIFY to be sent > > > to anyone watching "subscription list for presentity A" - > > probably A. Now, > > > at this time, A can choose to push a new policy list to the > > server. This new > > > policy list is one which blocks X. Whenever a presence > > server receives a new > > > policy, it automatically runs that policy against existing > > subscriptions. > > > > > > Note that we even proposed a data format for representing > > the state of > > > "subscription lists". See > > > > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-imp > p-watcherinfo- > > 00.txt. > > > > So, lets assume that we use a CPL variant to express policy. Assume http > is > > used to push these policies into the server. The flow would look like > this: > > > > > > subscriber presence server presentity > > > > SUB > > ------------------------------> > > > > 202 OK > > <------------------------------ NOTIFY w/ subscription state > > ----------------------------------> > > 200 OK > > <---------------------------------- > > http POST w/ CPL > > <---------------------------------- > > 200 OK > > -----------------------------------> > > > > In this way, policy information is always passed using a single > mechanism, > > but it is triggered using a NOTIFY. > > > > I think this is a better solution as with a properly configured policy > list/script it would address info leakages (for those concerned with > that sort of thing) by defaulting to display offline until the subscriber > was accepted. > > James Undery > > > > _______________________________________________ > 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 bcampbell@dynamicsoft.com Wed Mar 14 17:40:05 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09949 for ; Wed, 14 Mar 2001 17:40:05 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA12673 for ; Wed, 14 Mar 2001 17:43:22 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Mar 2001 17:42:14 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30A73@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: Robert Sparks Cc: simple@mailman.dynamicsoft.com Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Wed, 14 Mar 2001 17:42:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1317 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: > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, March 14, 2001 4:15 PM > Cc: simple@mailman.dynamicsoft.com > Subject: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) > > > The consensus at the end of this sub-thread, as I understand > it, was to abandon the idea of QAUTH as specified in qauth-00 > and look for other mechanisms (Jonathan has proposed subscribing > to subscription attempts as an alternative)to obtain authentication. > > So, QAUTH is abandoned and new implementors should not pursue it. > > Where/when should work on replacing its functionality take place? > > I don't see that it fits under the current SIMPLE charter (feel free > to argue with me). Should we table the concept for possible future > consideration then, or formally boot it to the sip-events arena? (A > generalized solution there would be valuable). > Do you think there is a need for a generic event agent to be able to delegate authorization decisions? If so, then it would belong in sip-events. I'm not sure I see that to be the case. Presence has the fairly unique requirement to allow a human to make the authorization decision on demand, a feature for which delegated authorization is very useful. I am not sure the concept generalizes very well. From rsparks@dynamicsoft.com Wed Mar 14 18:10:19 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10044 for ; Wed, 14 Mar 2001 18:10:18 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA13339; Wed, 14 Mar 2001 18:13:34 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Mar 2001 18:12:26 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A63E@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Christian Huitema'" , Robert Sparks Cc: simple@mailman.dynamicsoft.com Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Wed, 14 Mar 2001 18:12:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 5317 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: Good - meat for the discussion in Minnesota then. Please comment on the thread when you can. James/Jonathan - did I summarize your conclusion correctly? The questions in my last paragraph still stand, and should be addressed before we dive on the topic. RjS > -----Original Message----- > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > Sent: Wednesday, March 14, 2001 4:28 PM > To: Robert Sparks > Cc: simple@mailman.dynamicsoft.com > Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > Uh, I do not recall any such consensus. We find that QAUTH is actually > quite useful. > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Wednesday, March 14, 2001 2:15 PM > > Cc: simple@mailman.dynamicsoft.com > > Subject: Replacing the QAUTH concept (was [Simple] SIMPLE > BoF agenda) > > > > The consensus at the end of this sub-thread, as I understand > > it, was to abandon the idea of QAUTH as specified in qauth-00 > > and look for other mechanisms (Jonathan has proposed subscribing > > to subscription attempts as an alternative)to obtain authentication. > > > > So, QAUTH is abandoned and new implementors should not pursue it. > > > > Where/when should work on replacing its functionality take place? > > > > I don't see that it fits under the current SIMPLE charter (feel free > > to argue with me). Should we table the concept for possible future > > consideration then, or formally boot it to the sip-events arena? (A > > generalized solution there would be valuable). > > > > RjS > > > > > -----Original Message----- > > > From: James Undery [mailto:jundery@ubiquity.net] > > > Sent: Wednesday, February 28, 2001 10:18 AM > > > To: Jonathan Rosenberg > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] SIMPLE BoF agenda > > > > > > > > > > > > > > > On Wed, 28 Feb 2001, Jonathan Rosenberg wrote: > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > > > > > I really think using the current QAUTH proposition is far > > > > > from ideal and if it > > > > > can't be improved something else (non SIP based) should be > > > > > considered. The > > > > > transaction time-out issue is a real killer, I'd be > > > > > interested in comments on > > > > > using Subscribe and Notify for pull mechanism (my only > > > > > concern at the moment is > > > > > horrendous recursion). > > > > > > > > Well, there is a way to use SUB/NOT that would allow us to > > > converge the > > > > push/pull mechanisms. > > > > > > > > Consider the set of subscribers to a presentity as a piece > > > of dynamically > > > > changing state. Call this state the "subscription list for > > > presentity A". I > > > > can easily imagine that it is possible for entities > > > (typically, presentity > > > > A) to subscribe to this state. So, when it changes (such as > > > when a new > > > > subscriber X asks for a subscription to A), this causes a > > > NOTIFY to be sent > > > > to anyone watching "subscription list for presentity A" - > > > probably A. Now, > > > > at this time, A can choose to push a new policy list to the > > > server. This new > > > > policy list is one which blocks X. Whenever a presence > > > server receives a new > > > > policy, it automatically runs that policy against existing > > > subscriptions. > > > > > > > > Note that we even proposed a data format for representing > > > the state of > > > > "subscription lists". See > > > > > > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-imp > > p-watcherinfo- > > > 00.txt. > > > > > > So, lets assume that we use a CPL variant to express > policy. Assume > http > > is > > > used to push these policies into the server. The flow would look > like > > this: > > > > > > > > > subscriber presence server > presentity > > > > > > SUB > > > ------------------------------> > > > > > > 202 OK > > > <------------------------------ NOTIFY w/ subscription > state > > > ----------------------------------> > > > 200 OK > > > <---------------------------------- > > > http POST w/ CPL > > > <---------------------------------- > > > 200 OK > > > -----------------------------------> > > > > > > In this way, policy information is always passed using a single > > mechanism, > > > but it is triggered using a NOTIFY. > > > > > > > I think this is a better solution as with a properly > configured policy > > list/script it would address info leakages (for those concerned with > > that sort of thing) by defaulting to display offline until the > subscriber > > was accepted. > > > > James Undery > > > > > > > > _______________________________________________ > > 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 rsparks@dynamicsoft.com Wed Mar 14 18:17:50 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10081 for ; Wed, 14 Mar 2001 18:17:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA13489 for ; Wed, 14 Mar 2001 18:21:07 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Mar 2001 18:19:59 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A63F@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Ben Campbell , Robert Sparks Cc: simple@mailman.dynamicsoft.com Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Wed, 14 Mar 2001 18:19:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1944 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: If the idea were good for two or more event packages, not necessarily all, then the problem should be solved there. RjS > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, March 14, 2001 4:42 PM > To: Robert Sparks > Cc: simple@mailman.dynamicsoft.com > Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Wednesday, March 14, 2001 4:15 PM > > Cc: simple@mailman.dynamicsoft.com > > Subject: Replacing the QAUTH concept (was [Simple] SIMPLE > BoF agenda) > > > > > > The consensus at the end of this sub-thread, as I understand > > it, was to abandon the idea of QAUTH as specified in qauth-00 > > and look for other mechanisms (Jonathan has proposed subscribing > > to subscription attempts as an alternative)to obtain authentication. > > > > So, QAUTH is abandoned and new implementors should not pursue it. > > > > Where/when should work on replacing its functionality take place? > > > > I don't see that it fits under the current SIMPLE charter (feel free > > to argue with me). Should we table the concept for possible future > > consideration then, or formally boot it to the sip-events arena? (A > > generalized solution there would be valuable). > > > > Do you think there is a need for a generic event agent to be able to > delegate authorization decisions? If so, then it would belong > in sip-events. > I'm not sure I see that to be the case. Presence has the fairly unique > requirement to allow a human to make the authorization > decision on demand, a > feature for which delegated authorization is very useful. I > am not sure the > concept generalizes very well. > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From jundery@ubiquity.net Thu Mar 15 04:13:24 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA11625 for ; Thu, 15 Mar 2001 04:13:23 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 15 Mar 2001 09:13:22 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA27206; Thu, 15 Mar 2001 09:13:04 GMT Message-ID: <3AB087A3.6AC1D26C@ubiquity.net> Date: Thu, 15 Mar 2001 09:13:07 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: "'Christian Huitema'" , simple@mailman.dynamicsoft.com Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: <9BF66EBF6BEFD942915B4D4D45C051F314A63E@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2129 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: Comments inline. Robert Sparks wrote: > Good - meat for the discussion in Minnesota then. > > Please comment on the thread when you can. > James/Jonathan - did I summarize your conclusion correctly? > > The questions in my last paragraph still stand, and should > be addressed before we dive on the topic. > > RjS > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > > Sent: Wednesday, March 14, 2001 4:28 PM > > To: Robert Sparks > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > > agenda) > > > > > > Uh, I do not recall any such consensus. We find that QAUTH is actually > > quite useful. I'd agree there was no definite consensus, however, I'd disagree QAUTH is useful. > > > > > > -----Original Message----- > > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > Sent: Wednesday, March 14, 2001 2:15 PM > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: Replacing the QAUTH concept (was [Simple] SIMPLE > > BoF agenda) > > > > > > The consensus at the end of this sub-thread, as I understand > > > it, was to abandon the idea of QAUTH as specified in qauth-00 > > > and look for other mechanisms (Jonathan has proposed subscribing > > > to subscription attempts as an alternative)to obtain authentication. The only thing I'd add is when the presentity is notified of a change in the subscriptions to itself it may then supply a new document describing its authentication policy to the presence server. > > > > > > > So, QAUTH is abandoned and new implementors should not pursue it. > > > > > > Where/when should work on replacing its functionality take place? > > > > > > I don't see that it fits under the current SIMPLE charter (feel free > > > to argue with me). Should we table the concept for possible future > > > consideration then, or formally boot it to the sip-events arena? (A > > > generalized solution there would be valuable). I am all for a CPL style language to control generic sip event subscriptions and also agree this should be done outside the SIMPLE WG. James Undery From bcampbell@dynamicsoft.com Thu Mar 15 09:34:32 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12449 for ; Thu, 15 Mar 2001 09:34:32 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA19459; Thu, 15 Mar 2001 09:37:46 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 09:36:37 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30A76@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: "'James Undery'" , Robert Sparks Cc: "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 09:36:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1061 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: > I am all for a CPL style language to control generic sip > event subscriptions > and also agree this should be done outside the SIMPLE WG. > First off, I do like the elegance of a CPL style mechanism plus a subscription to the list-of-subscribers as opposed to QAUTH, at least as currently specificed. But their are two scenarios that make me a little queasy. The first I think is fairly severe, the second is more of an inconvenience: 1. X subscribes, and my rules allows the subscription. I am notified that X has subscribed and realize that I do not want X to see my presence state. I publish new rules to prevent X from re-subscribing. But it is too late, X already has my presence information. Also, would the new rules apply immediately, or would X keep his subscription until it expires, and merely be prohibited from re-subscribing? 2. Y attempts to subscribe, but is rejected by my rules. If I knew that Y wanted to subscribe I would allow it. But since I never get a notification that Y wants to subscribe, I have no reason to update my rules. From jundery@ubiquity.net Thu Mar 15 09:55:51 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA12528 for ; Thu, 15 Mar 2001 09:55:51 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 15 Mar 2001 14:55:51 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA14821; Thu, 15 Mar 2001 14:55:48 GMT Message-ID: <3AB0D7F3.D968E8EA@ubiquity.net> Date: Thu, 15 Mar 2001 14:55:47 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: <9BF66EBF6BEFD942915B4D4D45C051F30A76@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1616 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: Ben Campbell wrote: > > I am all for a CPL style language to control generic sip > > event subscriptions > > and also agree this should be done outside the SIMPLE WG. > > > > First off, I do like the elegance of a CPL style mechanism plus a > subscription to the list-of-subscribers as opposed to QAUTH, at least as > currently specificed. But their are two scenarios that make me a little > queasy. The first I think is fairly severe, the second is more of an > inconvenience: > > 1. X subscribes, and my rules allows the subscription. I am notified that X > has subscribed and realize that I do not want X to see my presence state. I > publish new rules to prevent X from re-subscribing. But it is too late, X > already has my presence information. Also, would the new rules apply > immediately, or would X keep his subscription until it expires, and merely > be prohibited from re-subscribing? > > 2. Y attempts to subscribe, but is rejected by my rules. If I knew that Y > wanted to subscribe I would allow it. But since I never get a notification > that Y wants to subscribe, I have no reason to update my rules. The first point was also discussed in the Thread, where authorisation is required the immediate NOTIFY returns offline, when and if authorisation is granted a new NOTIFY is generated with the correct presence info. This means you can't tell if the user is online and rejected your subscription or offline, so your privacy is intact. Also in example 2 your friend Y has not been rejected. (This is described better in sections 5.5 and 5.6 of draft-rosenberg-impp-presence-01.txt) James Undery From bcampbell@dynamicsoft.com Thu Mar 15 10:38:02 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12655 for ; Thu, 15 Mar 2001 10:38:01 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA20690; Thu, 15 Mar 2001 10:41:16 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 10:40:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30A78@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: "'James Undery'" , Ben Campbell Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 10:40:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2638 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: > > > 1. X subscribes, and my rules allows the subscription. I am > notified that X > > has subscribed and realize that I do not want X to see my > presence state. I > > publish new rules to prevent X from re-subscribing. But it > is too late, X > > already has my presence information. Also, would the new rules apply > > immediately, or would X keep his subscription until it > expires, and merely > > be prohibited from re-subscribing? > > > > 2. Y attempts to subscribe, but is rejected by my rules. If > I knew that Y > > wanted to subscribe I would allow it. But since I never get > a notification > > that Y wants to subscribe, I have no reason to update my rules. > > The first point was also discussed in the Thread, where > authorisation is > required the immediate NOTIFY returns offline, when and if > authorisation is > granted a new NOTIFY is generated with the correct presence > info. This means > you can't tell if the user is online and rejected your > subscription or offline, > so your privacy is intact. Also in example 2 your friend Y > has not been > rejected. (This is described better in sections 5.5 and 5.6 of > draft-rosenberg-impp-presence-01.txt) As I re-read the thread I see that it does answer my question about whether my new policy list gets applied to existing subscriptions--the answer is yes. But unless I am missing something, the information you refer me to does not address my scenarios. If we use a rule based (i.e. CPL like) mechanism along with the concept of subscribing to my list of subscribers, then in my first scenario the authorization has already occured before I get notification that my list of subscribers has changed. It doesn't matter if I 202 X or 200 X. He will most likely have already received a NOTIFY with my real presence data long before I can get a new rule set pushed into the server. In my scenario 2, Y has not been rejected in the sense that he did not get a 400 or 600 class response. Still, I assume if my rules reject him, he never gets added to my list of subscribers even if we respond with a 202, and I am never notified that he tried. Are you suggesting that I would receive a notification for each _unauthorized_ subscription request? The base problem in both scenarios is the mechanism makes an authorization decision first, then notifies me (or doesn't). I can tell the server to not do it again, but it is too late for this particular subscription. Now if my subscription to the list of subscribers for my presentity got notified of subscription _attempts_ it would somewhat mitigate scenario 2, but it would not help much for scenario 1. From jundery@ubiquity.net Thu Mar 15 11:06:06 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA12746 for ; Thu, 15 Mar 2001 11:06:04 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 15 Mar 2001 16:06:04 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA25287; Thu, 15 Mar 2001 16:05:57 GMT Message-ID: <3AB0E866.A86DB3A@ubiquity.net> Date: Thu, 15 Mar 2001 16:05:58 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: <9BF66EBF6BEFD942915B4D4D45C051F30A78@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3888 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: Ben Campbell wrote: > > > > > 1. X subscribes, and my rules allows the subscription. I am > > notified that X > > > has subscribed and realize that I do not want X to see my > > presence state. I > > > publish new rules to prevent X from re-subscribing. But it > > is too late, X > > > already has my presence information. Also, would the new rules apply > > > immediately, or would X keep his subscription until it > > expires, and merely > > > be prohibited from re-subscribing? > > > > > > 2. Y attempts to subscribe, but is rejected by my rules. If > > I knew that Y > > > wanted to subscribe I would allow it. But since I never get > > a notification > > > that Y wants to subscribe, I have no reason to update my rules. > > > > The first point was also discussed in the Thread, where > > authorisation is > > required the immediate NOTIFY returns offline, when and if > > authorisation is > > granted a new NOTIFY is generated with the correct presence > > info. This means > > you can't tell if the user is online and rejected your > > subscription or offline, > > so your privacy is intact. Also in example 2 your friend Y > > has not been > > rejected. (This is described better in sections 5.5 and 5.6 of > > draft-rosenberg-impp-presence-01.txt) > > As I re-read the thread I see that it does answer my question about whether > my new policy list gets applied to existing subscriptions--the answer is > yes. > > But unless I am missing something, the information you refer me to does not > address my scenarios. If we use a rule based (i.e. CPL like) mechanism along > with the concept of subscribing to my list of subscribers, then in my first > scenario the authorization has already occured before I get notification > that my list of subscribers has changed. It doesn't matter if I 202 X or 200 > X. He will most likely have already received a NOTIFY with my real presence > data long before I can get a new rule set pushed into the server. This was discussed in the "immediate notify issue" thread, basically the first NOTIFY contains the presentity is offline is the subscription is rejected or requires authentication, when a new policy is uploaded if only authorised subscribers recieve the real presence info, unauthorised subscribers will see nothing and can't tell if you really are offline, rejecting them or just not issued authorisation yet. > > > In my scenario 2, Y has not been rejected in the sense that he did not get a > 400 or 600 class response. Still, I assume if my rules reject him, he never > gets added to my list of subscribers even if we respond with a 202, and I am > never notified that he tried. Are you suggesting that I would receive a > notification for each _unauthorized_ subscription request? My preference is to have a "ban list", an "allow list" and a default action. The lists could either be constructed directly or via a CPL script (similar to how the location list is constructed). In scenario 2 I'd set the default action as "ask me". The "ban list" would contain the people I wanted rejected (202 and offline presence) without me being asked, the "allow list" would be to everyone who was to get the (200 and true presence), every other subscription would generate a NOTIFY. > > > The base problem in both scenarios is the mechanism makes an authorization > decision first, then notifies me (or doesn't). I can tell the server to not > do it again, but it is too late for this particular subscription. Now if my > subscription to the list of subscribers for my presentity got notified of > subscription _attempts_ it would somewhat mitigate scenario 2, but it would > not help much for scenario 1. The authorisation decision may be to say we are offline until "real authorisation" arrives from the user. This means it isn't too late as the subscriber doesn't know if we are offline or not authorising them. James Undery From huitema@exchange.microsoft.com Thu Mar 15 11:32:45 2001 Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12830 for ; Thu, 15 Mar 2001 11:32:45 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 15 Mar 2001 08:33:31 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Mar 2001 08:33:34 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 15 Mar 2001 08:33:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0 content-class: urn:content-classes:message Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Mar 2001 08:33:34 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Thread-Index: AcCtXS3CirGZrtFuRSaSMIpHzNa+EQAD+8tg From: "Christian Huitema" To: "Ben Campbell" , "James Undery" , "Robert Sparks" Cc: X-OriginalArrivalTime: 15 Mar 2001 16:33:34.0578 (UTC) FILETIME=[ADD43520:01C0AD6D] Content-Length: 1918 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA12830 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: Bottom line, whatever programming you do in the server, there has to be an escape clause that say "well, can't tell in general whether I want to accept or block this , so ask me before you publish anything!" This is when you need something like QAUTH -- and since we have QAUTH, we may as well keep it. Indeed, this begs the question of what to do when the user is offline -- the simple solution is to not provide information until the user had a chance to approve or disapprove the subscription. > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thursday, March 15, 2001 6:37 AM > To: 'James Undery'; Robert Sparks > Cc: Christian Huitema; 'simple@mailman.dynamicsoft.com' > Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) > > > I am all for a CPL style language to control generic sip > > event subscriptions > > and also agree this should be done outside the SIMPLE WG. > > > > First off, I do like the elegance of a CPL style mechanism plus a > subscription to the list-of-subscribers as opposed to QAUTH, at least as > currently specificed. But their are two scenarios that make me a little > queasy. The first I think is fairly severe, the second is more of an > inconvenience: > > 1. X subscribes, and my rules allows the subscription. I am notified that > X > has subscribed and realize that I do not want X to see my presence state. > I > publish new rules to prevent X from re-subscribing. But it is too late, X > already has my presence information. Also, would the new rules apply > immediately, or would X keep his subscription until it expires, and merely > be prohibited from re-subscribing? > > 2. Y attempts to subscribe, but is rejected by my rules. If I knew that Y > wanted to subscribe I would allow it. But since I never get a notification > that Y wants to subscribe, I have no reason to update my rules. From jundery@ubiquity.net Thu Mar 15 11:46:46 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA12892 for ; Thu, 15 Mar 2001 11:46:45 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 15 Mar 2001 16:46:45 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA12405; Thu, 15 Mar 2001 16:46:41 GMT Message-ID: <3AB0F1F2.88575860@ubiquity.net> Date: Thu, 15 Mar 2001 16:46:42 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: simple@mailman.dynamicsoft.com Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 956 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: Christian Huitema wrote: > Bottom line, whatever programming you do in the server, there has to be > an escape clause that say "well, can't tell in general whether I want to > accept or block this , so ask me before you publish > anything!" You publish "The presentity is offline". > This is when you need something like QAUTH -- and since we > have QAUTH, we may as well keep it. Indeed, this begs the question of > what to do when the user is offline -- the simple solution is to not > provide information until the user had a chance to approve or disapprove > the subscription. If the presentity is really offline how does QUATH work? (CPIM is required by this WGs charter so an immediate NOTIFY MUST be issued.) Does the presentities PUA return 180 Asking until the user responds, what happens if the request timesout waiting for the user, if it doesn't time out how do you stop people DOSing the presence server? James Undery From huitema@exchange.microsoft.com Thu Mar 15 11:58:20 2001 Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12946 for ; Thu, 15 Mar 2001 11:58:19 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 15 Mar 2001 08:59:06 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Mar 2001 08:59:08 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 15 Mar 2001 08:59:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0 content-class: urn:content-classes:message Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Mar 2001 08:59:08 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Thread-Index: AcCtb6X9bArSZsfAS2mZB856BXkZ6gAAFe+A From: "Christian Huitema" To: "James Undery" Cc: X-OriginalArrivalTime: 15 Mar 2001 16:59:08.0719 (UTC) FILETIME=[403F8BF0:01C0AD71] Content-Length: 1291 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA12946 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: > From: James Undery [mailto:jundery@ubiquity.net] > Christian Huitema wrote: > > > Bottom line, whatever programming you do in the server, there has to be > > an escape clause that say "well, can't tell in general whether I want to > > accept or block this , so ask me before you publish > > anything!" > > You publish "The presentity is offline". Sure. You take whatever default action you want. But this does not alleviate the need for asking the presentity, as soon as they come on line. At this stage, the server can issue a QAUTH, and, if the answer is OK, start publishing actual information. We can presumably come with another mechanism, but you have a couple of design considerations: 1) We must have an acknowledged exchange, in which the query describes the requested subscription and the reply provides a yes/no answer. 2) We must be able to fork the request so as to reach the user at their current location. It seems to me that QAUTH solves the two requirements. A simple NOTIFY does not. Indeed, if the subscription expires before the presentity ever comes on line, the server will just forget it. As for DoS attacks, it is clear that some protection is required. An obvious possibility is to have the server simply reject un-authenticated subscribes. From jundery@ubiquity.net Thu Mar 15 12:10:58 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA13012 for ; Thu, 15 Mar 2001 12:10:57 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 15 Mar 2001 17:10:57 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA23173; Thu, 15 Mar 2001 17:10:53 GMT Message-ID: <3AB0F79E.FFC8786A@ubiquity.net> Date: Thu, 15 Mar 2001 17:10:54 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: simple@mailman.dynamicsoft.com Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1867 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: Christian Huitema wrote: > > From: James Undery [mailto:jundery@ubiquity.net] > > Christian Huitema wrote: > > > > > Bottom line, whatever programming you do in the server, there has to > be > > > an escape clause that say "well, can't tell in general whether I > want to > > > accept or block this , so ask me before you publish > > > anything!" > > > > You publish "The presentity is offline". > > Sure. You take whatever default action you want. But this does not > alleviate the need for asking the presentity, as soon as they come on > line. At this stage, the server can issue a QAUTH, and, if the answer is > OK, start publishing actual information. We can presumably come with > another mechanism, but you have a couple of design considerations: > > 1) We must have an acknowledged exchange, in which the query describes > the requested subscription and the reply provides a yes/no answer. > > 2) We must be able to fork the request so as to reach the user at their > current location. > > It seems to me that QAUTH solves the two requirements. A simple NOTIFY > does not. 1) The NOTIFY solution acknowledges the PUA has seen the subscription request why does a yes / no answer need to be provided, I might just want them to never hear rather than get rejection when they refresh the subscription (I hope I explained why in our previous correspondence on the list about info leakage). 2) The NOTIFY doesn't fork no it goes directly to the place I have registered as wanting it to go to. (Actually I could make it fork if that was what I really wanted.) > > > Indeed, if the subscription expires before the presentity ever comes on > line, the server will just forget it I think you misunderstood me I meant what if the QUATH transaction times out while the user is deciding if they want to allow the subscription or not. James Undery From jdrosen@dynamicsoft.com Thu Mar 15 12:13:58 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13039 for ; Thu, 15 Mar 2001 12:13:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA23068; Thu, 15 Mar 2001 12:17:12 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 12:16:03 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Christian Huitema Cc: simple@mailman.dynamicsoft.com Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 12:16:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 6034 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: > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Thursday, March 15, 2001 11:47 AM > To: Christian Huitema > Cc: simple@mailman.dynamicsoft.com > Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > > > Christian Huitema wrote: > > > Bottom line, whatever programming you do in the server, > there has to be > > an escape clause that say "well, can't tell in general > whether I want to > > accept or block this , so ask me before you publish > > anything!" > > You publish "The presentity is offline". > > > This is when you need something like QAUTH -- and since we > > have QAUTH, we may as well keep it. Indeed, this begs the > question of > > what to do when the user is offline -- the simple solution is to not > > provide information until the user had a chance to approve > or disapprove > > the subscription. Christian - there is no debate that a mechanism to ask the subscriber is needed. What is being debated is how this is done. > > If the presentity is really offline how does QUATH work? > (CPIM is required > by this WGs charter so an immediate NOTIFY MUST be issued.) > > Does the presentities PUA return 180 Asking until the user > responds, what > happens if the request timesout waiting for the user, if it > doesn't time out > how do you stop people DOSing the presence server? If the user is offline (i.e., not even registered to receive QAUTH), then the presence server would need to 202 the subscription, and wait for the presentity to come back online. It would know this by registrations; when the PUA came online, it would register support for QAUTH, and then the server initiates a QAUTH transaction for the pending subscriptions. If the registration for QAUTH is there, but the user is not answering, the presence server is in a bind. It will need to 202 the subscription, as always, and then periodicaly retry the QAUTH, cancelling each after a timeout. Very, very ugly. I prefer the NOTIFY, followed by push of policy, for a LOT of reasons: 1. The issue for QAUTH is *what entities are allowed to make authorization decisions for this presentity*. With QAUTH, we associate this data with the entities that can register QAUTH method handling at a registrar for that presentity. This is, IMHO, really overloading the meaning of registrations. Registrations establish location and presence state in the network, they are not about establishing authorization policies. 2. what happens if multiple entities are allowed to make authorization decisions? So, each would presumably register QAUTH contact addresses for that presentity. This results in forking of QAUTH. Well, we know that this is not going to work. What if one recipient of the QAUTH rejects the subscription, and the other accepts it? Only the 200 OK is forwarded upstream, which means that the subscription is accepted so long as any one of the recipients accepts. Yikes. Not what you want. In general, if there is a notion of multiple entities that can grant authorization (and I think its a good idea), the rules for combining the authorization decisions from each of the entities need to be at the discretion of the proxy. This cannot ever work with QAUTH. At the core, forking is ideal for session establishment functions, NOT for policy functions! 3. The timeout issue with QAUTH, as described by James above, makes handling of the case when the PUA is registered to receive QAUTH, but the user is not at their desk, very problematic. 4. QAUTH will require authentication of the *response* to QAUTH, which is something we have weak support for right now in SIP. So, my proposal, of using notifications to alert authorizers of the subscription, followed by a push of policy, solves all of these problems. Lets consider them in turn: 1. With this proposal, there can be separate policies about who gets notified when subscriptions are requested, and who is allowed to push policy decisions into the server. Thats because we use different mechanisms for the two. No overloading at all. 2. Multiple entities making authorization decisions works great. each will subscribe to get notified when subscriptions for the presentity are requested. Each can then push policy into the server independently, probably with http carrying a CPL kind of thing. This means that the presence server has access to everyones policy decision, and can be programmed to combine them in any way. 3. what if the PUA is offline? Easy! When the user starts their client, first thing it does is resubscribe to the "subscription listing for the presentity". THis will generate a notification, with a list of all the active, denied, and pending subscriptions. The PUA can then query the user on all pending ones, and then use HTTP to push a new set of policies for those users. What if the PUA is active (meaning, receiving notifications of changes in presence state), but the user is not at their desk? Easy! The PUA software always responds 200 OK to every notify, and pops a window to ask for authorization. This window can sit idle forever. There are no pending SIP transactions. When the user accepts, the PUA software pushes the policy in a new HTTP request. 4. No need for response authentication. Policy is pushed using something like HTTP + CPL. Client authentication mecahnisms in HTTP are well understood, and lots of means are at aour disposal. Note also how this approach unifies things; there is one, and only one way policy gets into the server. Sometimes the policy is triggered as a result of a subscription, and sometimes, its not. But, the mechanism is the same. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Thu Mar 15 12:19:55 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13074 for ; Thu, 15 Mar 2001 12:19:55 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA23213; Thu, 15 Mar 2001 12:23:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 12:22:00 -0500 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , "'James Undery'" , Robert Sparks Cc: "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 12:21:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2873 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: > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thursday, March 15, 2001 9:37 AM > To: 'James Undery'; Robert Sparks > Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > > I am all for a CPL style language to control generic sip > > event subscriptions > > and also agree this should be done outside the SIMPLE WG. > > > > First off, I do like the elegance of a CPL style mechanism plus a > subscription to the list-of-subscribers as opposed to QAUTH, > at least as > currently specificed. But their are two scenarios that make > me a little > queasy. The first I think is fairly severe, the second is more of an > inconvenience: > > 1. X subscribes, and my rules allows the subscription. I am > notified that X > has subscribed and realize that I do not want X to see my > presence state. I > publish new rules to prevent X from re-subscribing. But it is > too late, X > already has my presence information. Well, that seems reasonable. You did, after all, explicitly allow the user to subscribe. Even with the old QAUTH mechanism, if authorization data already existed for a subscriber, the QAUTH wasn't sent. Think about it. If QAUTH was needed even for subscriptions where authorization data was already present, the system could never provide presence services for you when you were offline. With the notify approach, you at least get told that someone has subscribed to you, and been accepted. You can, at that point, push new policy and tell the server to discard the subscription. With QAUTH, you wouldn't even get the QAUTH, so you'd have no way of knowing that they subscribed! Also, would the new rules apply > immediately, or would X keep his subscription until it > expires, and merely > be prohibited from re-subscribing? Immediately. The subscription would be deleted (meaning no more NOTIFYs are sent), and the policy database would be updated to reject future subscriptions (of course, reject may still mean 202 + NOTIFY w/ bogus data) > > 2. Y attempts to subscribe, but is rejected by my rules. If I > knew that Y > wanted to subscribe I would allow it. But since I never get a > notification > that Y wants to subscribe, I have no reason to update my rules. Same as above. You explicitly TOLD the server to disallow the user. If you believe that authorization data can never actually be used, what is the point of having it? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From huitema@exchange.microsoft.com Thu Mar 15 12:31:55 2001 Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13126 for ; Thu, 15 Mar 2001 12:31:54 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Thu, 15 Mar 2001 09:32:42 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 15 Mar 2001 09:32:44 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 15 Mar 2001 09:32:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4668.0 content-class: urn:content-classes:message Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Mar 2001 09:32:44 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Thread-Index: AcCtc4EaOWqAXk5vTAGV2VoquAEOfgAAEPCQ From: "Christian Huitema" To: "Jonathan Rosenberg" Cc: X-OriginalArrivalTime: 15 Mar 2001 17:32:44.0766 (UTC) FILETIME=[F1E7E7E0:01C0AD75] Content-Length: 1103 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA13126 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: Jonathan, At the core of the debate is whether the authorization of subscription is specified in the protocol, or is left to a side channel. I agree that the side channel model can work: the user receives a notification that some action is requested; the client pushes state in the server; the state can be either temporary or permanent; the server uses the new state for the current subscription and possibly for the subscriptions to come. When you say that "Policy is pushed using something like HTTP + CPL," you are really saying that the server decisions are based on parameters that are exchanged through a client/server protocol that is either proprietary or specified in another standard. In fact, the net result will be a set of proprietary configuration interfaces, based on your preferred combination of HTTP, CPL, XML, HTML Forms and SOAP, with various degrees of integration between the presence UI and the management UI. Now, it may well be that this is what the group wants, that we don't feel confident that we can make this part of the standard now. Is this true? -- Christian Huitema From hgs@cs.columbia.edu Thu Mar 15 12:53:42 2001 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 MAA13201 for ; Thu, 15 Mar 2001 12:53:42 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA10202; Thu, 15 Mar 2001 12:53:34 -0500 (EST) Message-ID: <3AB1019E.2FA86A16@cs.columbia.edu> Date: Thu, 15 Mar 2001 12:53:34 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'James Undery'" , Christian Huitema , simple@mailman.dynamicsoft.com Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 729 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: If we use something like CPL, this would in all likelihood be uploaded as part of the generic request handling mechanism. (This makes sense, I believe, since in many cases, the filtering rules are similar. If I don't want to hear from user X, I probably don't want to have him subscribe to me, either. The converse isn't true, obviously.) Thus, one such mechanism could be REGISTER. It would indeed be nice if we could agree on one mechanism, as otherwise a crucial piece will be missing and be different for every single service provider. Just relying on form + HTTP is, in my opinion, a bad idea, as it doesn't work well with devices with limited screen resolution. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From bcampbell@dynamicsoft.com Thu Mar 15 13:11:28 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13267 for ; Thu, 15 Mar 2001 13:11:28 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA24369; Thu, 15 Mar 2001 13:14:43 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 13:13:34 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30A79@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: "'James Undery'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 13:13:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2061 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: > > > But unless I am missing something, the information you > refer me to does not > > address my scenarios. If we use a rule based (i.e. CPL > like) mechanism along > > with the concept of subscribing to my list of subscribers, > then in my first > > scenario the authorization has already occured before I get > notification > > that my list of subscribers has changed. It doesn't matter > if I 202 X or 200 > > X. He will most likely have already received a NOTIFY with > my real presence > > data long before I can get a new rule set pushed into the server. > > This was discussed in the "immediate notify issue" thread, > basically the first > NOTIFY contains the presentity is offline is the subscription > is rejected or > requires authentication, when a new policy is uploaded if > only authorised > subscribers recieve the real presence info, unauthorised > subscribers will see > nothing and can't tell if you really are offline, rejecting > them or just not > issued authorisation yet. > I think you miss the point of my first scenario. It was not concerned with what happens when a subscriber is not authorized. My concern was with the model that says "follow the rule, then inform the presentity if you accepted a new subscription so that they can push new policy to remove the authorization." This becomes a case of closing the barn door after the horse has left. I might can keep X from receiving future information about me, but the server has _already_ given X my current data. Perhaps we need to think in term of how the mechanism gets used by a real application. A number of presence services use rule based authorizations, and a CPL like approach would work fine for them. But what if I want to build a service that behaves like Yahoo, where the service asked me for permission _before_ allowing the subscription. (I don't mean before sending a 202 and/or a dummy notify, but before starting to send NOTIFYs with real data in them). Can I do that with policy rules and a subscription to the list of subscribers? If so, how? From bcampbell@dynamicsoft.com Thu Mar 15 13:51:52 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13403 for ; Thu, 15 Mar 2001 13:51:52 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA25090; Thu, 15 Mar 2001 13:55:06 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 13:53:56 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30A7E@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: Jonathan Rosenberg , "'James Undery'" , Robert Sparks Cc: "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 13:53:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 4249 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: First, please don't take my argument to be a defence of QAUTH. I am merely questioning whether the policy-rules plus notification of changes to my list of subscribers meets the requirements. Should it be possible for me to write policy that says: 1. Accept anyone in my domain 2. Accept anyone in my buddy list 3. Reject foo@example.com (assume foo is a known stalker) 4. Any one else, _ask_me_first. It seems to me that rule 4 is not possible. I could make a rule that says "accept anyone else, then tell me you did it" and then push new policy if someone I didn't think about subscribes. I can prevent them from getting future presence information, but I cannot take back the fact that the server already gave them my current information. Now, maybe we do not have a requirement to handle rule 4. If that is our consensus, I am okay with it. But I want to make sure we explicitly make that decision. > -----Original Message----- > From: Jonathan Rosenberg > Sent: Thursday, March 15, 2001 11:22 AM > To: Ben Campbell; 'James Undery'; Robert Sparks > Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > > > > > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Thursday, March 15, 2001 9:37 AM > > To: 'James Undery'; Robert Sparks > > Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > > Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > > agenda) > > > > > > > I am all for a CPL style language to control generic sip > > > event subscriptions > > > and also agree this should be done outside the SIMPLE WG. > > > > > > > First off, I do like the elegance of a CPL style mechanism plus a > > subscription to the list-of-subscribers as opposed to QAUTH, > > at least as > > currently specificed. But their are two scenarios that make > > me a little > > queasy. The first I think is fairly severe, the second is more of an > > inconvenience: > > > > 1. X subscribes, and my rules allows the subscription. I am > > notified that X > > has subscribed and realize that I do not want X to see my > > presence state. I > > publish new rules to prevent X from re-subscribing. But it is > > too late, X > > already has my presence information. > > Well, that seems reasonable. You did, after all, explicitly > allow the user to subscribe. Even with the old QAUTH > mechanism, if authorization data already existed for a > subscriber, the QAUTH wasn't sent. Think about it. If QAUTH > was needed even for subscriptions where authorization data > was already present, the system could never provide presence > services for you when you were offline. > > With the notify approach, you at least get told that someone > has subscribed to you, and been accepted. You can, at that > point, push new policy and tell the server to discard the > subscription. With QAUTH, you wouldn't even get the QAUTH, so > you'd have no way of knowing that they subscribed! > > > Also, would the new rules apply > > immediately, or would X keep his subscription until it > > expires, and merely > > be prohibited from re-subscribing? > > Immediately. The subscription would be deleted (meaning no > more NOTIFYs are sent), and the policy database would be > updated to reject future subscriptions (of course, reject may > still mean 202 + NOTIFY w/ bogus data) > > > > > 2. Y attempts to subscribe, but is rejected by my rules. If I > > knew that Y > > wanted to subscribe I would allow it. But since I never get a > > notification > > that Y wants to subscribe, I have no reason to update my rules. > > Same as above. You explicitly TOLD the server to disallow the > user. If you believe that authorization data can never > actually be used, what is the point of having it? > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > From jdrosen@dynamicsoft.com Thu Mar 15 15:07:54 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13611 for ; Thu, 15 Mar 2001 15:07:54 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA26692; Thu, 15 Mar 2001 15:11:07 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 15:09:58 -0500 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Jonathan Rosenberg , "'James Undery'" , Robert Sparks Cc: "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 15:09:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1874 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: > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thursday, March 15, 2001 1:54 PM > To: Jonathan Rosenberg; 'James Undery'; Robert Sparks > Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > First, please don't take my argument to be a defence of > QAUTH. I am merely > questioning whether the policy-rules plus notification of > changes to my list > of subscribers meets the requirements. > > Should it be possible for me to write policy that says: > > 1. Accept anyone in my domain > 2. Accept anyone in my buddy list > 3. Reject foo@example.com (assume foo is a known stalker) > 4. Any one else, _ask_me_first. > It is absolutely a requirement. > It seems to me that rule 4 is not possible. No, not true at all. The whole idea is that if the presence server has no explicit accept/reject authorization, it marks the subscription as pending and waits to be told what to do. In all cases, when there is a change in the set of subscriptions (either accepted, rejected, or pending), a notification is sent to subscribers of the "watcher list". So, it is easy to do what you want. Note that a pending subscription will generate a 202+NOTIFY, but the content of the NOTIFY is made up and not useful. What you cannot do is: 1. accept anyone in my domain 2. for anyone, ask me first since these are inconsistent. This is what I thought you were talking about. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Thu Mar 15 15:13:58 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13646 for ; Thu, 15 Mar 2001 15:13:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA26924; Thu, 15 Mar 2001 15:17:08 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 15:15:58 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" , Jonathan Rosenberg Cc: "'James Undery'" , Christian Huitema , simple@mailman.dynamicsoft.com Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 15:15:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2450 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: > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, March 15, 2001 12:54 PM > To: Jonathan Rosenberg > Cc: 'James Undery'; Christian Huitema; simple@mailman.dynamicsoft.com > Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > If we use something like CPL, this would in all likelihood be uploaded > as part of the generic request handling mechanism. (This > makes sense, I > believe, since in many cases, the filtering rules are similar. If I > don't want to hear from user X, I probably don't want to have him > subscribe to me, either. The converse isn't true, obviously.) > > Thus, one such mechanism could be REGISTER. > > It would indeed be nice if we could agree on one mechanism, > as otherwise > a crucial piece will be missing and be different for every single > service provider. Just relying on form + HTTP is, in my opinion, a bad > idea, as it doesn't work well with devices with limited screen > resolution. I agree. I wasn't advocating forms for everything. I was advocating something like http+CPLng. REGISTER is also a possibility, although I think http is more appropriate. I think its just fine to have more than one policy mechanism. After all, its a key concept in sip that things like policy, routing, AAA and location service are orthogonal to sip itself. All I am advocating is the same; lets keep the authorization mechanisms totally orthogonal, and allow there to be more than one. I see no reason why forms couldn't be used, nor why a DIAMETER dip into a back end enterprise wide policy server couldn't be used. So, I think we do need to standardize some kind of simple policy mechanism, ala CPL. Where it gets done is a good question. One might argue that its in scope here, or perhaps in iptel. Some of the other presence protocols include authorization within the protocol. Whilst I think thats a bad idea, its precedent that treatment of authorization is within the scope of the group doing that presence protocol. Any inputs from our ADs on this one? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From bcampbell@dynamicsoft.com Thu Mar 15 15:54:26 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13829 for ; Thu, 15 Mar 2001 15:54:26 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA27726; Thu, 15 Mar 2001 15:57:39 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 15:56:29 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30A81@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: Jonathan Rosenberg , "'James Undery'" , Robert Sparks Cc: "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 15:56:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1475 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: > > > > First, please don't take my argument to be a defence of > > QAUTH. I am merely > > questioning whether the policy-rules plus notification of > > changes to my list > > of subscribers meets the requirements. > > > > Should it be possible for me to write policy that says: > > > > 1. Accept anyone in my domain > > 2. Accept anyone in my buddy list > > 3. Reject foo@example.com (assume foo is a known stalker) > > 4. Any one else, _ask_me_first. > > > > It is absolutely a requirement. > > > It seems to me that rule 4 is not possible. > > No, not true at all. The whole idea is that if the presence > server has no explicit accept/reject authorization, it marks > the subscription as pending and waits to be told what to do. > In all cases, when there is a change in the set of > subscriptions (either accepted, rejected, or pending), a > notification is sent to subscribers of the "watcher list". > So, it is easy to do what you want. Note that a pending > subscription will generate a 202+NOTIFY, but the content of > the NOTIFY is made up and not useful. > > What you cannot do is: Ah, I had not grokked that the list of subscriptions included "pending" subscription. Therefore the user can push new policy, and the entire list of subscriptions, including pending ones, gets re-checked against the new policy. I would be somewhat concerned about a server keeping state for rejected subscriptions. That sounds like an opening for a DoS attack. From jdrosen@dynamicsoft.com Thu Mar 15 16:27:55 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13965 for ; Thu, 15 Mar 2001 16:27:55 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA02584; Thu, 15 Mar 2001 16:31:08 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 16:29:58 -0500 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , "'James Undery'" , Robert Sparks Cc: "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 16:29:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2653 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: > -----Original Message----- > From: Ben Campbell > Sent: Thursday, March 15, 2001 3:56 PM > To: Jonathan Rosenberg; 'James Undery'; Robert Sparks > Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > > > > > > First, please don't take my argument to be a defence of > > > QAUTH. I am merely > > > questioning whether the policy-rules plus notification of > > > changes to my list > > > of subscribers meets the requirements. > > > > > > Should it be possible for me to write policy that says: > > > > > > 1. Accept anyone in my domain > > > 2. Accept anyone in my buddy list > > > 3. Reject foo@example.com (assume foo is a known stalker) > > > 4. Any one else, _ask_me_first. > > > > > > > It is absolutely a requirement. > > > > > It seems to me that rule 4 is not possible. > > > > No, not true at all. The whole idea is that if the presence > > server has no explicit accept/reject authorization, it marks > > the subscription as pending and waits to be told what to do. > > In all cases, when there is a change in the set of > > subscriptions (either accepted, rejected, or pending), a > > notification is sent to subscribers of the "watcher list". > > So, it is easy to do what you want. Note that a pending > > subscription will generate a 202+NOTIFY, but the content of > > the NOTIFY is made up and not useful. > > > > What you cannot do is: > > Ah, I had not grokked that the list of subscriptions included > "pending" subscription. Therefore the user can push new > policy, and the entire list of subscriptions, including > pending ones, gets re-checked against the new policy. > > I would be somewhat concerned about a server keeping state > for rejected subscriptions. That sounds like an opening for a > DoS attack. > Well, pending transaction state is even worse, if you think about it. I don't see any way around keeping pending transaction state. I suppose you could introduce restrictions like, no more than 50 pending subscriptions for one presentity at a time. This should cover the majority of normal use cases, and allow the server to drop pending subscriptions associated with attacks. The presence document should probably mention this. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From Adam.Roach@am1.ericsson.se Thu Mar 15 19:22:32 2001 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 TAA15141 for ; Thu, 15 Mar 2001 19:22:32 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2G0MUi12375 for ; Thu, 15 Mar 2001 18:22:30 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2G0MUS10288 for ; Thu, 15 Mar 2001 18:22:30 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Mar 15 18:22:29 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Mar 2001 18:24:14 -0600 Message-ID: <61D824C63B99D311975E00508B0CC9850E8676@eamrcnt717.exu.ericsson.se> From: "Adam Roach (EUS)" To: "'Jonathan Rosenberg'" , Ben Campbell , "'James Undery'" , Robert Sparks Cc: "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 18:19:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ADAE.C83D7700" Content-Length: 3357 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: 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_01C0ADAE.C83D7700 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > From: Ben Campbell > > > > I would be somewhat concerned about a server keeping state > > for rejected subscriptions. That sounds like an opening for a > > DoS attack. > > > > Well, pending transaction state is even worse, if you think > about it. I > don't see any way around keeping pending transaction state. I > suppose you > could introduce restrictions like, no more than 50 pending > subscriptions for > one presentity at a time. This should cover the majority of normal use > cases, and allow the server to drop pending subscriptions > associated with > attacks. Couldn't we retain only *one* "pending" or "rejected" transaction per each authenticated user (subscriber) per presentity? (and, of course, *no* state for unauthenticated users). Or is it too much to ask that the subscribing entity have a relationship with the server? /a ------_=_NextPart_001_01C0ADAE.C83D7700 Content-Type: text/html; charset="iso-8859-1" RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda)

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>
> > From: Ben Campbell
> >
> > I would be somewhat concerned about a server keeping state
> > for rejected subscriptions. That sounds like an opening for a
> > DoS attack.
> >
>
> Well, pending transaction state is even worse, if you think
> about it. I
> don't see any way around keeping pending transaction state. I
> suppose you
> could introduce restrictions like, no more than 50 pending
> subscriptions for
> one presentity at a time. This should cover the majority of normal use
> cases, and allow the server to drop pending subscriptions
> associated with
> attacks.

Couldn't we retain only *one* "pending" or "rejected" transaction
per each authenticated user (subscriber) per presentity? (and, of
course, *no* state for unauthenticated users). Or is it too much
to ask that the subscribing entity have a relationship with the
server?

/a

------_=_NextPart_001_01C0ADAE.C83D7700-- From jdrosen@dynamicsoft.com Thu Mar 15 23:54:31 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15841 for ; Thu, 15 Mar 2001 23:54:30 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA07038; Thu, 15 Mar 2001 23:56:05 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 23:54:54 -0500 Message-ID: From: Jonathan Rosenberg To: "'Adam Roach (EUS)'" , Jonathan Rosenberg , Ben Campbell , "'James Undery'" , Robert Sparks Cc: "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Thu, 15 Mar 2001 23:54:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1889 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: -----Original Message----- >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsson.se] >Sent: Thursday, March 15, 2001 7:20 PM >To: 'Jonathan Rosenberg'; Ben Campbell; 'James Undery'; Robert Sparks >Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' >Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) > > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> >> > From: Ben Campbell >> > >> > I would be somewhat concerned about a server keeping state >> > for rejected subscriptions. That sounds like an opening for a >> > DoS attack. >> > >> >> Well, pending transaction state is even worse, if you think >> about it. I >> don't see any way around keeping pending transaction state. I >> suppose you >> could introduce restrictions like, no more than 50 pending >> subscriptions for >> one presentity at a time. This should cover the majority of normal use >> cases, and allow the server to drop pending subscriptions >> associated with >> attacks. >Couldn't we retain only *one* "pending" or "rejected" transaction >per each authenticated user (subscriber) per presentity? (and, of >course, *no* state for unauthenticated users). Or is it too much >to ask that the subscribing entity have a relationship with the >server? No, I don't think thats sufficient. THe problem is that an attacker might be able to obtain a large number of authentic (but anonymous) accounts (think yahoo mail), and use those to launch attacks. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jundery@ubiquity.net Fri Mar 16 04:06:51 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA16496 for ; Fri, 16 Mar 2001 04:06:50 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 16 Mar 2001 09:06:50 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA27921; Fri, 16 Mar 2001 09:06:27 GMT Message-ID: <3AB1D797.F462661D@ubiquity.net> Date: Fri, 16 Mar 2001 09:06:31 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Adam Roach (EUS)'" , Ben Campbell , Robert Sparks , "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2022 Subject: [Simple] DoS from rejected subscriptions (was Replacing the QAUTH concept) 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: I've changed the subject as this is an important, separate issue. Jonathan Rosenberg wrote: > > -----Original Message----- > >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsson.se] > >Sent: Thursday, March 15, 2001 7:20 PM > >To: 'Jonathan Rosenberg'; Ben Campbell; 'James Undery'; Robert Sparks > >Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > >Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) > > > > > >> -----Original Message----- > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >> > >> > From: Ben Campbell > >> > > >> > I would be somewhat concerned about a server keeping state > >> > for rejected subscriptions. That sounds like an opening for a > >> > DoS attack. > >> > > >> > >> Well, pending transaction state is even worse, if you think > >> about it. I > >> don't see any way around keeping pending transaction state. I > >> suppose you > >> could introduce restrictions like, no more than 50 pending > >> subscriptions for > >> one presentity at a time. This should cover the majority of normal use > >> cases, and allow the server to drop pending subscriptions > >> associated with > >> attacks. > >Couldn't we retain only *one* "pending" or "rejected" transaction > >per each authenticated user (subscriber) per presentity? (and, of > >course, *no* state for unauthenticated users). Or is it too much > >to ask that the subscribing entity have a relationship with the > >server? > > No, I don't think thats sufficient. THe problem is that an attacker might be > able to obtain a large number of authentic (but anonymous) accounts (think > yahoo mail), and use those to launch attacks. This can be solved with a change to the way SUBSCRIBE works, basically the 202 response only returns contacts present in the SUBSCRIBE. That way the presence server only needs to use the SUBSCRIBE to generate the response and the NOTIFY and doesn't need to store state about the SUBSCRIBE. (200s are unaffected) Comments gratefully received James Undery From jundery@ubiquity.net Fri Mar 16 04:09:27 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA16523 for ; Fri, 16 Mar 2001 04:09:26 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 16 Mar 2001 09:09:26 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA29503; Fri, 16 Mar 2001 09:09:22 GMT Message-ID: <3AB1D846.86B995A8@ubiquity.net> Date: Fri, 16 Mar 2001 09:09:26 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: <9BF66EBF6BEFD942915B4D4D45C051F30A79@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 669 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: Ben Campbell wrote: > > I think you miss the point of my first scenario. It was not concerned with > what happens when a subscriber is not authorized. My concern was with the > model that says "follow the rule, then inform the presentity if you accepted > a new subscription so that they can push new policy to remove the > authorization." This becomes a case of closing the barn door after the horse > has left. I might can keep X from receiving future information about me, but > the server has _already_ given X my current data. No X has been told you are offline regardless of your status, until authorisation is given when X will get the truth! James Undery From jundery@ubiquity.net Fri Mar 16 04:20:39 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA16573 for ; Fri, 16 Mar 2001 04:20:38 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 16 Mar 2001 09:20:38 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA05029; Fri, 16 Mar 2001 09:20:01 GMT Message-ID: <3AB1DAC5.A4F28C3B@ubiquity.net> Date: Fri, 16 Mar 2001 09:20:05 +0000 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Henning G. Schulzrinne'" , Christian Huitema , simple@mailman.dynamicsoft.com Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2639 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: Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Thursday, March 15, 2001 12:54 PM > > To: Jonathan Rosenberg > > Cc: 'James Undery'; Christian Huitema; simple@mailman.dynamicsoft.com > > Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > > agenda) > > > > > > If we use something like CPL, this would in all likelihood be uploaded > > as part of the generic request handling mechanism. (This > > makes sense, I > > believe, since in many cases, the filtering rules are similar. If I > > don't want to hear from user X, I probably don't want to have him > > subscribe to me, either. The converse isn't true, obviously.) > > > > Thus, one such mechanism could be REGISTER. > > > > It would indeed be nice if we could agree on one mechanism, > > as otherwise > > a crucial piece will be missing and be different for every single > > service provider. Just relying on form + HTTP is, in my opinion, a bad > > idea, as it doesn't work well with devices with limited screen > > resolution. > > I agree. I wasn't advocating forms for everything. I was advocating > something like http+CPLng. REGISTER is also a possibility, although I think > http is more appropriate. I agree with Jonathan here, I really don't like using REGISTER to upload CPL scripts as it allows the REGISTER to do two independent things either of which could fail, firstly update location information (could fail with 409) and secondly store a script which could be illegal. Reporting these two separate results in a single response is ugly. > > > I think its just fine to have more than one policy mechanism. After all, its > a key concept in sip that things like policy, routing, AAA and location > service are orthogonal to sip itself. All I am advocating is the same; lets > keep the authorization mechanisms totally orthogonal, and allow there to be > more than one. I see no reason why forms couldn't be used, nor why a > DIAMETER dip into a back end enterprise wide policy server couldn't be used. > > So, I think we do need to standardize some kind of simple policy mechanism, > ala CPL. Where it gets done is a good question. One might argue that its in > scope here, or perhaps in iptel. Some of the other presence protocols > include authorization within the protocol. Whilst I think thats a bad idea, > its precedent that treatment of authorization is within the scope of the > group doing that presence protocol. I think any simple/SIMPLE policy mechanism has to be done in conjunction with the Sun/Not work Adam is doing in sip-events. James Undery From hisham.khartabil@hotsip.com Fri Mar 16 08:01:40 2001 Received: from mail.speedventures.com ([212.75.74.99]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17143 for ; Fri, 16 Mar 2001 08:01:39 -0500 (EST) Received: from Hash (195.238.204.173 [195.238.204.173]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HAP3YJFF; Fri, 16 Mar 2001 13:54:20 +0100 From: "Hisham Khartabil" To: "Jonathan Rosenberg" , Subject: RE: [Simple] immediate notify issue Date: Fri, 16 Mar 2001 15:01:18 +0200 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 Importance: Normal In-Reply-To: Content-Length: 2824 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: Hi, What about when the Presence Agent is located at the client (ie: Presence Client). If I subscribe directly to that presence client, and that client is off line, then I know because I don't even get a response to my subscribe. I guess nothing could be done about that besides motivate the need for a presence server (Is that what we are trying to motivate, or are we trying to motivate pushing login to peripherals?) Regards, Hisham Khartabil Hotsip Finland www.hotsip.com -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan Rosenberg Sent: Tuesday, 27 February 2001 9:36 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] immediate notify issue Folks, I've encountered a privacy issue surrounding the current methodology of immediately generating a NOTIFY on a successful subscription. We have agreed that a SUBSCRIBE will pretty much always result in a 202 whether its accepted or not. This way, the subscriber cannot obtain any information about whether the presentity is online or offline, based on the response code or delays in receiving the response. We have also agreed that the presence data is not included in the response to subscribe, and rather, in an immediate notify. This was for aligment with CPIM. However, there is now a problem with the notify. A client could determine whether the PUA was online, or whether its subscription was accepted, based on when a NOTIFY arrives (a slightly delayed one indicates they are online and authorized the subscription; one that never arrives likely means they are offline or the subscription was rejected). To handle this, we may need to mandate that the presence agent generate an immediate NOTIFY, containing the current state of the presentity. In all cases, the presence document in this message contain a valid state for the presentity. If a subscription was pending or rejected, the state would indicate that the presentity was unavailable. If a subscription was accepted, it would indicate the actual state, which could also be unavailable. The key is that the presence document returned in the case of a pending subscription be a valid one that can't be distinguished from one I might get if my subscription were accepted. Thoughts? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From hgs@cs.columbia.edu Fri Mar 16 09:38:20 2001 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 JAA17411 for ; Fri, 16 Mar 2001 09:38:19 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA22409; Fri, 16 Mar 2001 09:38:15 -0500 (EST) Message-ID: <3AB22557.A91DCA90@cs.columbia.edu> Date: Fri, 16 Mar 2001 09:38:15 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: Jonathan Rosenberg , Christian Huitema , simple@mailman.dynamicsoft.com Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: <3AB1DAC5.A4F28C3B@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 678 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: James Undery wrote: > > I agree with Jonathan here, I really don't like using REGISTER to upload CPL > scripts as it allows the REGISTER to do two independent things either of which > could fail, firstly update location information (could fail with 409) and > secondly store a script which could be illegal. Reporting these two separate > results in a single response is ugly. Whether this is done via REGISTER or a new method (which may well be preferable), using SIP hasa the advantage that the addressing and authentication is consistent and that the number of protocols that need to be supported stays finite. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From bcampbell@dynamicsoft.com Fri Mar 16 12:28:49 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17887 for ; Fri, 16 Mar 2001 12:28:49 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA13454 for ; Fri, 16 Mar 2001 12:32:06 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 16 Mar 2001 12:30:55 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30A83@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: Jonathan Rosenberg Cc: "'simple@mailman.dynamicsoft.com'" Date: Fri, 16 Mar 2001 12:30:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 514 Subject: [Simple] Really minor nit in draft-rosenberg-impp-presence-01.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: Section 4, paragraph 1 characterises a pres URL to be like unto a URN, in that it is an abstract name. Based on recent discussions on the IMPP list, I think this is a misleading characterization. A pres URL has internal semantics, to the degree that the host part would be used to scope whatever resolution we do (be it SRV, NAPTR, whatever.) It seems to me that this is exactly what distinguishes a URL from a URN. Of course as always, I could be completely wrong. (See, I told you it was a really minor nit) From jdrosen@dynamicsoft.com Sun Mar 18 23:50:46 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26879 for ; Sun, 18 Mar 2001 23:50:46 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02443 for ; Sun, 18 Mar 2001 23:54:04 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 18 Mar 2001 23:52:48 -0500 Message-ID: From: Jonathan Rosenberg To: Ben Campbell Cc: "'simple@mailman.dynamicsoft.com'" Date: Sun, 18 Mar 2001 23:52:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1231 Subject: [Simple] RE: Really minor nit in draft-rosenberg-impp-presence-01.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: > -----Original Message----- > From: Ben Campbell > Sent: Friday, March 16, 2001 12:31 PM > To: Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Really minor nit in draft-rosenberg-impp-presence-01.txt > > > Section 4, paragraph 1 characterises a pres URL to be like > unto a URN, in that it is an abstract name. Based on recent > discussions on the IMPP list, I think this is a misleading > characterization. A pres URL has internal semantics, to the > degree that the host part would be used to scope whatever > resolution we do (be it SRV, NAPTR, whatever.) It seems to me > that this is exactly what distinguishes a URL from a URN. I wrote this while IMPP was still figuring out what the URI was. I'm not sure its resolved still. Once the decision is made, I'll be able to update this to be completely consistent with it. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Sun Mar 18 23:51:06 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26896 for ; Sun, 18 Mar 2001 23:51:06 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02455; Sun, 18 Mar 2001 23:54:16 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 18 Mar 2001 23:53:00 -0500 Message-ID: From: Jonathan Rosenberg To: "Henning G. Schulzrinne" , James Undery Cc: Jonathan Rosenberg , Christian Huitema , simple@mailman.dynamicsoft.com Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Sun, 18 Mar 2001 23:52:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2859 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: > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, March 16, 2001 9:38 AM > To: James Undery > Cc: Jonathan Rosenberg; Christian Huitema; > simple@mailman.dynamicsoft.com > Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > James Undery wrote: > > > > > I agree with Jonathan here, I really don't like using > REGISTER to upload CPL > > scripts as it allows the REGISTER to do two independent > things either of which > > could fail, firstly update location information (could fail > with 409) and > > secondly store a script which could be illegal. Reporting > these two separate > > results in a single response is ugly. > > Whether this is done via REGISTER or a new method (which may well be > preferable), using SIP hasa the advantage that the addressing and > authentication is consistent and that the number of protocols > that need > to be supported stays finite. There are a few issues here: 1. addressing If we use some other mechanism to push policy, how do we know for whom the policy is targeted? One way is that this information is obtained by a mapping of the http URL. Something like: http://www.mydomain.com/presence/users/sip:joe@mydomain.com would get mapped to sip:joe@mydomain.com. Kind of a pain, and it will vary from site to site, meaning yet another thing to administer. Another possibility is that the SIP URL of the presentity is embedded within the policy document itself: ... This is at odds with how CPL works, and would make sharing of policy documents across multiple presentities more complex. 2. authentication Since http and sip share authentication mechanisms (for basic and digest at least), and these are probably stored in some backend database in most systems (or at least in a file on disk), seems like they could be shared across http and sip servers. 3. protocol reduction count I am not generally fond of this argument in devices, since you would argue that everything on a phone (which right now includes sip, rtp, dhcp, ip, udp, possibly tcp, snmp, http, ...) should be one protocol. draft-ietf-sip-guidelines explicitly talks about this argument. Another issue is the bulk transport issue, since these policy languages could be quite large. As such, http, or sip over tcp, seem like more or less a requirement. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Sun Mar 18 23:51:07 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26901 for ; Sun, 18 Mar 2001 23:51:07 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02460; Sun, 18 Mar 2001 23:54:18 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 18 Mar 2001 23:53:02 -0500 Message-ID: From: Jonathan Rosenberg To: Hisham Khartabil , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] immediate notify issue Date: Sun, 18 Mar 2001 23:53:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1308 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: > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > Sent: Friday, March 16, 2001 8:01 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] immediate notify issue > > > Hi, > > What about when the Presence Agent is located at the client > (ie: Presence > Client). If I subscribe directly to that presence client, > and that client > is off line, then I know because I don't even get a response to my > subscribe. I guess nothing could be done about that besides > motivate the > need for a presence server (Is that what we are trying to > motivate, or are > we trying to motivate pushing login to peripherals?) In general, you will need a server to handle the cases when the client is offline. Pushing the PA functionality to the end devices only works when those devices are available, and have knowledge of all the communications means of the presentity. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From hgs@cs.columbia.edu Mon Mar 19 10:37:22 2001 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 KAA01191 for ; Mon, 19 Mar 2001 10:37:22 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA27467; Mon, 19 Mar 2001 10:37:20 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA10594; Mon, 19 Mar 2001 10:37:20 -0500 (EST) Message-ID: <3AB652DD.2876BB7E@cs.columbia.edu> Date: Mon, 19 Mar 2001 10:41:33 -0800 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: James Undery , Christian Huitema , simple@mailman.dynamicsoft.com Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1439 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: > > 2. authentication > > Since http and sip share authentication mechanisms (for basic and digest at > least), and these are probably stored in some backend database in most > systems (or at least in a file on disk), seems like they could be shared > across http and sip servers. In practice, this is difficult, since many web servers use just plain passwd or similar files, while many SIP servers use some form of database (since the number of users tends to be much larger). Thus, you will have to use a special-purpose, custom-written web server or be forced to use the Apache mechanism in your SIP server. Neither seems ideal, to put it mildly. (I have no ambition to re-write Apache, but it's current user database mechanism is not very suitable for SIP.) > > 3. protocol reduction count > > I am not generally fond of this argument in devices, since you would argue > that everything on a phone (which right now includes sip, rtp, dhcp, ip, > udp, possibly tcp, snmp, http, ...) should be one protocol. > draft-ietf-sip-guidelines explicitly talks about this argument. Just because it's more than one protocol doesn't imply that we should be adding protocols with abandon. > > Another issue is the bulk transport issue, since these policy languages > could be quite large. As such, http, or sip over tcp, seem like more or less > a requirement. > If this is policy for pending subscriptions, this is likely to be small. From jdrosen@dynamicsoft.com Mon Mar 19 22:05:53 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02973 for ; Mon, 19 Mar 2001 22:05:53 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA15472; Mon, 19 Mar 2001 22:06:25 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Mar 2001 22:05:07 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: James Undery , Christian Huitema , simple@mailman.dynamicsoft.com Subject: RE: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) Date: Mon, 19 Mar 2001 22:05:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2197 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: > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, March 19, 2001 1:42 PM > To: Jonathan Rosenberg > Cc: James Undery; Christian Huitema; simple@mailman.dynamicsoft.com > Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF > agenda) > > > > > > 2. authentication > > > > Since http and sip share authentication mechanisms (for > basic and digest at > > least), and these are probably stored in some backend > database in most > > systems (or at least in a file on disk), seems like they > could be shared > > across http and sip servers. > > In practice, this is difficult, since many web servers use just plain > passwd or similar files, while many SIP servers use some form of > database (since the number of users tends to be much larger). > Thus, you > will have to use a special-purpose, custom-written web server or be > forced to use the Apache mechanism in your SIP server. Neither seems > ideal, to put it mildly. (I have no ambition to re-write Apache, but > it's current user database mechanism is not very suitable for SIP.) I think most real web applications do client authorization using EJB or some other backend database access ontop of a web application server, but I could be wrong (i.e., they are not using http authentication mechanisms at all, but rather form posts within an ssl connection). If that is the case, then you would access the same password database for both http and sip. > > > > Another issue is the bulk transport issue, since these > policy languages > > could be quite large. As such, http, or sip over tcp, seem > like more or less > > a requirement. > > > > If this is policy for pending subscriptions, this is likely > to be small. > We need to work through what such policy looks like, and then see. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From hgs@cs.columbia.edu Mon Mar 19 22:42:58 2001 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 WAA03084 for ; Mon, 19 Mar 2001 22:42:57 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA21306; Mon, 19 Mar 2001 22:42:57 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id WAA13099; Mon, 19 Mar 2001 22:42:56 -0500 (EST) Message-ID: <3AB6FCED.97D103F9@cs.columbia.edu> Date: Mon, 19 Mar 2001 22:47:09 -0800 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: James Undery , Christian Huitema , simple@mailman.dynamicsoft.com Subject: Re: Replacing the QAUTH concept (was [Simple] SIMPLE BoF agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1002 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: > > I think most real web applications do client authorization using EJB or some Those applications do not use HTTP authentication, so this is only slightly comparable. If they do not use HTTP authentication, but web forms instead, it's rather difficult to automate the whole process without the user being aware that policy is being uploaded. Cookies (with SSL) help, but still require a user interface interaction with the password for first-time use. > other backend database access ontop of a web application server, but I could > be wrong (i.e., they are not using http authentication mechanisms at all, > but rather form posts within an ssl connection). If that is the case, then > you would access the same password database for both http and sip. As I said, not likely. If it's using a backend database (I doubt that it's EJB in most cases, since most web pages seem to be .asp these days...), you might be able to use the same backend, assuming you don't mind storing plaintext passwords. From jdrosen@dynamicsoft.com Tue Mar 20 00:19:43 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03355 for ; Tue, 20 Mar 2001 00:19:43 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA16238; Tue, 20 Mar 2001 00:22:58 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Mar 2001 00:21:40 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Jonathan Rosenberg Cc: "'Adam Roach (EUS)'" , Ben Campbell , Robert Sparks , "'Christian Huitema'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) Date: Tue, 20 Mar 2001 00:21:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 3043 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: > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Friday, March 16, 2001 4:07 AM > To: Jonathan Rosenberg > Cc: 'Adam Roach (EUS)'; Ben Campbell; Robert Sparks; 'Christian > Huitema'; 'simple@mailman.dynamicsoft.com' > Subject: [Simple] DoS from rejected subscriptions (was Replacing the > QAUTH concept) > > > I've changed the subject as this is an important, separate issue. > > Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsson.se] > > >Sent: Thursday, March 15, 2001 7:20 PM > > >To: 'Jonathan Rosenberg'; Ben Campbell; 'James Undery'; > Robert Sparks > > >Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > > >Subject: RE: Replacing the QAUTH concept (was [Simple] > SIMPLE BoF agenda) > > > > > > > > >> -----Original Message----- > > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > >> > > >> > From: Ben Campbell > > >> > > > >> > I would be somewhat concerned about a server keeping state > > >> > for rejected subscriptions. That sounds like an opening for a > > >> > DoS attack. > > >> > > > >> > > >> Well, pending transaction state is even worse, if you think > > >> about it. I > > >> don't see any way around keeping pending transaction state. I > > >> suppose you > > >> could introduce restrictions like, no more than 50 pending > > >> subscriptions for > > >> one presentity at a time. This should cover the majority > of normal use > > >> cases, and allow the server to drop pending subscriptions > > >> associated with > > >> attacks. > > >Couldn't we retain only *one* "pending" or "rejected" transaction > > >per each authenticated user (subscriber) per presentity? (and, of > > >course, *no* state for unauthenticated users). Or is it too much > > >to ask that the subscribing entity have a relationship with the > > >server? > > > > No, I don't think thats sufficient. THe problem is that an > attacker might be > > able to obtain a large number of authentic (but anonymous) > accounts (think > > yahoo mail), and use those to launch attacks. > > This can be solved with a change to the way SUBSCRIBE works, > basically the 202 > response only returns contacts present in the SUBSCRIBE. That > way the presence > server only needs to use the SUBSCRIBE to generate the > response and the NOTIFY > and doesn't need to store state about the SUBSCRIBE. (200s > are unaffected) > > Comments gratefully received I'm not following you. What has contacts in the SUBSCRIBE got to do with it? How do you avoid the need to store pending subscription state in the case where this is a legitimate subscription? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jundery@hotmail.com Tue Mar 20 09:32:13 2001 Received: from hotmail.com (law2-f65.hotmail.com [216.32.181.65]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04784 for ; Tue, 20 Mar 2001 09:32:12 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Mar 2001 06:32:11 -0800 Received: from 135.222.65.19 by lw2fd.hotmail.msn.com with HTTP; Tue, 20 Mar 2001 14:32:11 GMT X-Originating-IP: [135.222.65.19] Reply-To: jundery@ubiquity.net From: "James Undery" To: jdrosen@dynamicsoft.com, jundery@ubiquity.net Cc: Adam.Roach@am1.ericsson.se, bcampbell@dynamicsoft.com, rsparks@dynamicsoft.com, huitema@exchange.microsoft.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) Date: Tue, 20 Mar 2001 14:32:11 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Mar 2001 14:32:11.0432 (UTC) FILETIME=[8CCD1280:01C0B14A] Content-Length: 4926 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: >From: Jonathan Rosenberg >To: "'James Undery'" , Jonathan Rosenberg > >CC: "'Adam Roach (EUS)'" , Ben Campbell >, Robert Sparks >, "'Christian Huitema'" >, "'simple@mailman.dynamicsoft.com'" > >Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q >AUTH concept) >Date: Tue, 20 Mar 2001 00:21:31 -0500 >MIME-Version: 1.0 >Received: from [194.202.146.92] by hotmail.com (3.2) with ESMTP id >MHotMailBC80337D009340043722C2CA925CCB5A0; Mon Mar 19 21:19:59 2001 >Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd >(for [64.4.55.7]) with SMTP; 20 Mar 2001 05:19:42 UT >Received: from dragon.ubiquity.net by ubiquity.net with SMTP >(8.8.8+Sun/25-eef)id FAA01018; Tue, 20 Mar 2001 05:19:39 GMT >Received: from redball.dynamicsoft.com ([216.173.40.51]) by >dragon.ubiquity.net via smtpd (for gecko.ubiquity.net >[193.195.52.22]) with SMTP; 20 Mar 2001 05:19:40 UT >Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])by >redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id >AAA16238;Tue, 20 Mar 2001 00:22:58 -0500 (EST) >Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service >(5.5.2650.21)id ; Tue, 20 Mar 2001 00:21:40 -0500 >From jdrosen@dynamicsoft.com Mon Mar 19 21:20:42 2001 >Message-ID: > >X-Mailer: Internet Mail Service (5.5.2650.21) > > > > > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Sent: Friday, March 16, 2001 4:07 AM > > To: Jonathan Rosenberg > > Cc: 'Adam Roach (EUS)'; Ben Campbell; Robert Sparks; 'Christian > > Huitema'; 'simple@mailman.dynamicsoft.com' > > Subject: [Simple] DoS from rejected subscriptions (was Replacing the > > QAUTH concept) > > > > > > I've changed the subject as this is an important, separate issue. > > > > Jonathan Rosenberg wrote: > > > > > > > > -----Original Message----- > > > >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsson.se] > > > >Sent: Thursday, March 15, 2001 7:20 PM > > > >To: 'Jonathan Rosenberg'; Ben Campbell; 'James Undery'; > > Robert Sparks > > > >Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > > > >Subject: RE: Replacing the QAUTH concept (was [Simple] > > SIMPLE BoF agenda) > > > > > > > > > > > >> -----Original Message----- > > > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > >> > > > >> > From: Ben Campbell > > > >> > > > > >> > I would be somewhat concerned about a server keeping state > > > >> > for rejected subscriptions. That sounds like an opening for a > > > >> > DoS attack. > > > >> > > > > >> > > > >> Well, pending transaction state is even worse, if you think > > > >> about it. I > > > >> don't see any way around keeping pending transaction state. I > > > >> suppose you > > > >> could introduce restrictions like, no more than 50 pending > > > >> subscriptions for > > > >> one presentity at a time. This should cover the majority > > of normal use > > > >> cases, and allow the server to drop pending subscriptions > > > >> associated with > > > >> attacks. > > > >Couldn't we retain only *one* "pending" or "rejected" transaction > > > >per each authenticated user (subscriber) per presentity? (and, of > > > >course, *no* state for unauthenticated users). Or is it too much > > > >to ask that the subscribing entity have a relationship with the > > > >server? > > > > > > No, I don't think thats sufficient. THe problem is that an > > attacker might be > > > able to obtain a large number of authentic (but anonymous) > > accounts (think > > > yahoo mail), and use those to launch attacks. > > > > This can be solved with a change to the way SUBSCRIBE works, > > basically the 202 > > response only returns contacts present in the SUBSCRIBE. That > > way the presence > > server only needs to use the SUBSCRIBE to generate the > > response and the NOTIFY > > and doesn't need to store state about the SUBSCRIBE. (200s > > are unaffected) > > > > Comments gratefully received > >I'm not following you. What has contacts in the SUBSCRIBE got to do with >it? >How do you avoid the need to store pending subscription state in the case >where this is a legitimate subscription? > I envisaged this as a solution to the case where the subscriber has been rejected with the policy document but the presentity doesn't want them to know that. When the subscription is awaiting authorisation the subscription will have to be stored as you point out. James Undery _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From jdrosen@dynamicsoft.com Wed Mar 21 11:09:01 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08719 for ; Wed, 21 Mar 2001 11:09:01 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA04884; Wed, 21 Mar 2001 11:12:15 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Mar 2001 11:10:54 -0500 Message-ID: From: Jonathan Rosenberg To: "'jundery@ubiquity.net'" , Jonathan Rosenberg Cc: Adam.Roach@am1.ericsson.se, Ben Campbell , Robert Sparks , huitema@exchange.microsoft.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) Date: Wed, 21 Mar 2001 11:10:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 5839 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: > -----Original Message----- > From: James Undery [mailto:jundery@hotmail.com] > Sent: Tuesday, March 20, 2001 9:32 AM > To: jdrosen@dynamicsoft.com; jundery@ubiquity.net > Cc: Adam.Roach@am1.ericsson.se; bcampbell@dynamicsoft.com; > rsparks@dynamicsoft.com; huitema@exchange.microsoft.com; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] DoS from rejected subscriptions (was > Replacing the > Q AUTH concept) > > > > > > >From: Jonathan Rosenberg > >To: "'James Undery'" , Jonathan > Rosenberg > > > >CC: "'Adam Roach (EUS)'" , > Ben Campbell > >, Robert Sparks > >, "'Christian Huitema'" > >, > "'simple@mailman.dynamicsoft.com'" > > > >Subject: RE: [Simple] DoS from rejected subscriptions (was > Replacing the Q > >AUTH concept) > >Date: Tue, 20 Mar 2001 00:21:31 -0500 > >MIME-Version: 1.0 > >Received: from [194.202.146.92] by hotmail.com (3.2) with ESMTP id > >MHotMailBC80337D009340043722C2CA925CCB5A0; Mon Mar 19 21:19:59 2001 > >Received: from gecko.ubiquity.net by drago1.ubiquity.net > via smtpd > >(for [64.4.55.7]) with SMTP; 20 Mar 2001 05:19:42 UT > >Received: from dragon.ubiquity.net by ubiquity.net with SMTP > >(8.8.8+Sun/25-eef)id FAA01018; Tue, 20 Mar 2001 05:19:39 GMT > >Received: from redball.dynamicsoft.com ([216.173.40.51]) by > >dragon.ubiquity.net via smtpd (for gecko.ubiquity.net > >[193.195.52.22]) with SMTP; 20 Mar 2001 05:19:40 UT > >Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])by > >redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id > >AAA16238;Tue, 20 Mar 2001 00:22:58 -0500 (EST) > >Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service > >(5.5.2650.21)id ; Tue, 20 Mar 2001 00:21:40 -0500 > >From jdrosen@dynamicsoft.com Mon Mar 19 21:20:42 2001 > >Message-ID: > > csoft.com> > >X-Mailer: Internet Mail Service (5.5.2650.21) > > > > > > > > > > > > > -----Original Message----- > > > From: James Undery [mailto:jundery@ubiquity.net] > > > Sent: Friday, March 16, 2001 4:07 AM > > > To: Jonathan Rosenberg > > > Cc: 'Adam Roach (EUS)'; Ben Campbell; Robert Sparks; 'Christian > > > Huitema'; 'simple@mailman.dynamicsoft.com' > > > Subject: [Simple] DoS from rejected subscriptions (was > Replacing the > > > QAUTH concept) > > > > > > > > > I've changed the subject as this is an important, separate issue. > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > -----Original Message----- > > > > >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsson.se] > > > > >Sent: Thursday, March 15, 2001 7:20 PM > > > > >To: 'Jonathan Rosenberg'; Ben Campbell; 'James Undery'; > > > Robert Sparks > > > > >Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > > > > >Subject: RE: Replacing the QAUTH concept (was [Simple] > > > SIMPLE BoF agenda) > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > >> > > > > >> > From: Ben Campbell > > > > >> > > > > > >> > I would be somewhat concerned about a server keeping state > > > > >> > for rejected subscriptions. That sounds like an > opening for a > > > > >> > DoS attack. > > > > >> > > > > > >> > > > > >> Well, pending transaction state is even worse, if you think > > > > >> about it. I > > > > >> don't see any way around keeping pending transaction state. I > > > > >> suppose you > > > > >> could introduce restrictions like, no more than 50 pending > > > > >> subscriptions for > > > > >> one presentity at a time. This should cover the majority > > > of normal use > > > > >> cases, and allow the server to drop pending subscriptions > > > > >> associated with > > > > >> attacks. > > > > >Couldn't we retain only *one* "pending" or "rejected" > transaction > > > > >per each authenticated user (subscriber) per > presentity? (and, of > > > > >course, *no* state for unauthenticated users). Or is > it too much > > > > >to ask that the subscribing entity have a relationship with the > > > > >server? > > > > > > > > No, I don't think thats sufficient. THe problem is that an > > > attacker might be > > > > able to obtain a large number of authentic (but anonymous) > > > accounts (think > > > > yahoo mail), and use those to launch attacks. > > > > > > This can be solved with a change to the way SUBSCRIBE works, > > > basically the 202 > > > response only returns contacts present in the SUBSCRIBE. That > > > way the presence > > > server only needs to use the SUBSCRIBE to generate the > > > response and the NOTIFY > > > and doesn't need to store state about the SUBSCRIBE. (200s > > > are unaffected) > > > > > > Comments gratefully received > > > >I'm not following you. What has contacts in the SUBSCRIBE > got to do with > >it? > >How do you avoid the need to store pending subscription > state in the case > >where this is a legitimate subscription? > > > I envisaged this as a solution to the case where the > subscriber has been > rejected with the policy document but the presentity doesn't > want them to > know that. What is "this" in your sentence above? My question still remains on what you mean by "contacts in the SUBSCRIBE"? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From jundery@hotmail.com Wed Mar 21 12:15:12 2001 Received: from hotmail.com (law2-f93.hotmail.com [216.32.181.93]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08924 for ; Wed, 21 Mar 2001 12:15:11 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Mar 2001 09:14:55 -0800 Received: from 135.222.65.19 by lw2fd.hotmail.msn.com with HTTP; Wed, 21 Mar 2001 17:14:55 GMT X-Originating-IP: [135.222.65.19] Reply-To: jundery@ubiquity.net From: "James Undery" To: jdrosen@dynamicsoft.com, jundery@ubiquity.net Cc: Adam.Roach@am1.ericsson.se, bcampbell@dynamicsoft.com, rsparks@dynamicsoft.com, huitema@exchange.microsoft.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) Date: Wed, 21 Mar 2001 17:14:55 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2001 17:14:55.0548 (UTC) FILETIME=[7314AFC0:01C0B22A] Content-Length: 5545 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: >From: Jonathan Rosenberg >To: "'jundery@ubiquity.net'" , Jonathan >Rosenberg > > > -----Original Message----- > > From: James Undery [mailto:jundery@hotmail.com] > > Sent: Tuesday, March 20, 2001 9:32 AM > > To: jdrosen@dynamicsoft.com; jundery@ubiquity.net > > Cc: Adam.Roach@am1.ericsson.se; bcampbell@dynamicsoft.com; > > rsparks@dynamicsoft.com; huitema@exchange.microsoft.com; > > simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] DoS from rejected subscriptions (was > > Replacing the > > Q AUTH concept) > > > > > > > > > > > > >From: Jonathan Rosenberg > > > > > > > -----Original Message----- > > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > Sent: Friday, March 16, 2001 4:07 AM > > > > To: Jonathan Rosenberg > > > > Cc: 'Adam Roach (EUS)'; Ben Campbell; Robert Sparks; 'Christian > > > > Huitema'; 'simple@mailman.dynamicsoft.com' > > > > Subject: [Simple] DoS from rejected subscriptions (was > > Replacing the > > > > QAUTH concept) > > > > > > > > > > > > I've changed the subject as this is an important, separate issue. > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > > > -----Original Message----- > > > > > >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsson.se] > > > > > >Sent: Thursday, March 15, 2001 7:20 PM > > > > > >To: 'Jonathan Rosenberg'; Ben Campbell; 'James Undery'; > > > > Robert Sparks > > > > > >Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > > > > > >Subject: RE: Replacing the QAUTH concept (was [Simple] > > > > SIMPLE BoF agenda) > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > >> > > > > > >> > From: Ben Campbell > > > > > >> > > > > > > >> > I would be somewhat concerned about a server keeping state > > > > > >> > for rejected subscriptions. That sounds like an > > opening for a > > > > > >> > DoS attack. > > > > > >> > > > > > > >> > > > > > >> Well, pending transaction state is even worse, if you think > > > > > >> about it. I > > > > > >> don't see any way around keeping pending transaction state. I > > > > > >> suppose you > > > > > >> could introduce restrictions like, no more than 50 pending > > > > > >> subscriptions for > > > > > >> one presentity at a time. This should cover the majority > > > > of normal use > > > > > >> cases, and allow the server to drop pending subscriptions > > > > > >> associated with > > > > > >> attacks. > > > > > >Couldn't we retain only *one* "pending" or "rejected" > > transaction > > > > > >per each authenticated user (subscriber) per > > presentity? (and, of > > > > > >course, *no* state for unauthenticated users). Or is > > it too much > > > > > >to ask that the subscribing entity have a relationship with the > > > > > >server? > > > > > > > > > > No, I don't think thats sufficient. THe problem is that an > > > > attacker might be > > > > > able to obtain a large number of authentic (but anonymous) > > > > accounts (think > > > > > yahoo mail), and use those to launch attacks. > > > > > > > > This can be solved with a change to the way SUBSCRIBE works, > > > > basically the 202 > > > > response only returns contacts present in the SUBSCRIBE. That > > > > way the presence > > > > server only needs to use the SUBSCRIBE to generate the > > > > response and the NOTIFY > > > > and doesn't need to store state about the SUBSCRIBE. (200s > > > > are unaffected) > > > > > > > > Comments gratefully received > > > > > >I'm not following you. What has contacts in the SUBSCRIBE > > got to do with > > >it? > > >How do you avoid the need to store pending subscription > > state in the case > > >where this is a legitimate subscription? > > > > > I envisaged this as a solution to the case where the > > subscriber has been > > rejected with the policy document but the presentity doesn't > > want them to > > know that. > >What is "this" in your sentence above? My question still remains on what >you >mean by "contacts in the SUBSCRIBE"? When a SUBSCRIBE is sent to a Presence Server (PS) it contains Contact headers, where the NOTIFYs will be sent. I believe (but have been unable to confirm in the 01 draft yet) That a 2xx response should contain a list of Contact headers relevent to the subscription, this is fine for 200s as the user has been authenticated and authorised, however, for 202 that might have been rejected as unauthorised, you don't want to maintain enough state to return all the Contact headers that they believe should be attached to the subscription (based on To, From and Call-ID). It may be better to mandate that 202 responses only contain Contact headers present in the SUBSCRIBE that generated the response. This allows a PS which knows this subscription is rejected as unauthorised to respond without storing state about the Contact headers the rejected subscription may have previously supplied. Where the status of the subscription's authorisation is unknown the Contact headers will have to be stored, but DoS from rejected subscriptions will be prevented without leaking presence info. I realise this might not make sense as I haven't really expanded my thinking of how a presence authorisation policy processing language might look, but I hope it helps. James Undery _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From rsparks@dynamicsoft.com Wed Mar 21 13:21:00 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09114 for ; Wed, 21 Mar 2001 13:21:00 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA07182; Wed, 21 Mar 2001 13:24:16 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Mar 2001 13:22:55 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A66C@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'jundery@ubiquity.net'" , Jonathan Rosenberg Cc: Adam.Roach@am1.ericsson.se, Ben Campbell , Robert Sparks , huitema@exchange.microsoft.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) Date: Wed, 21 Mar 2001 13:22:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 6709 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: Actually, with -01 we're tracking sip-events, so the subscribe provides only one contact to be notified, and the final response contains the contact of the responding UAS (like INVITE), so that record-route can work. RjS > -----Original Message----- > From: James Undery [mailto:jundery@hotmail.com] > Sent: Wednesday, March 21, 2001 11:15 AM > To: jdrosen@dynamicsoft.com; jundery@ubiquity.net > Cc: Adam.Roach@am1.ericsson.se; bcampbell@dynamicsoft.com; > rsparks@dynamicsoft.com; huitema@exchange.microsoft.com; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] DoS from rejected subscriptions (was > Replacing the > Q AUTH concept) > > > > > > >From: Jonathan Rosenberg > >To: "'jundery@ubiquity.net'" , Jonathan > >Rosenberg > > > > > > -----Original Message----- > > > From: James Undery [mailto:jundery@hotmail.com] > > > Sent: Tuesday, March 20, 2001 9:32 AM > > > To: jdrosen@dynamicsoft.com; jundery@ubiquity.net > > > Cc: Adam.Roach@am1.ericsson.se; bcampbell@dynamicsoft.com; > > > rsparks@dynamicsoft.com; huitema@exchange.microsoft.com; > > > simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] DoS from rejected subscriptions (was > > > Replacing the > > > Q AUTH concept) > > > > > > > > > > > > > > > > > > >From: Jonathan Rosenberg > > > > > > > > > > -----Original Message----- > > > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > > Sent: Friday, March 16, 2001 4:07 AM > > > > > To: Jonathan Rosenberg > > > > > Cc: 'Adam Roach (EUS)'; Ben Campbell; Robert Sparks; > 'Christian > > > > > Huitema'; 'simple@mailman.dynamicsoft.com' > > > > > Subject: [Simple] DoS from rejected subscriptions (was > > > Replacing the > > > > > QAUTH concept) > > > > > > > > > > > > > > > I've changed the subject as this is an important, > separate issue. > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsson.se] > > > > > > >Sent: Thursday, March 15, 2001 7:20 PM > > > > > > >To: 'Jonathan Rosenberg'; Ben Campbell; 'James Undery'; > > > > > Robert Sparks > > > > > > >Cc: 'Christian Huitema'; 'simple@mailman.dynamicsoft.com' > > > > > > >Subject: RE: Replacing the QAUTH concept (was [Simple] > > > > > SIMPLE BoF agenda) > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > >> > > > > > > >> > From: Ben Campbell > > > > > > >> > > > > > > > >> > I would be somewhat concerned about a server > keeping state > > > > > > >> > for rejected subscriptions. That sounds like an > > > opening for a > > > > > > >> > DoS attack. > > > > > > >> > > > > > > > >> > > > > > > >> Well, pending transaction state is even worse, > if you think > > > > > > >> about it. I > > > > > > >> don't see any way around keeping pending > transaction state. I > > > > > > >> suppose you > > > > > > >> could introduce restrictions like, no more than > 50 pending > > > > > > >> subscriptions for > > > > > > >> one presentity at a time. This should cover the majority > > > > > of normal use > > > > > > >> cases, and allow the server to drop pending subscriptions > > > > > > >> associated with > > > > > > >> attacks. > > > > > > >Couldn't we retain only *one* "pending" or "rejected" > > > transaction > > > > > > >per each authenticated user (subscriber) per > > > presentity? (and, of > > > > > > >course, *no* state for unauthenticated users). Or is > > > it too much > > > > > > >to ask that the subscribing entity have a > relationship with the > > > > > > >server? > > > > > > > > > > > > No, I don't think thats sufficient. THe problem is that an > > > > > attacker might be > > > > > > able to obtain a large number of authentic (but anonymous) > > > > > accounts (think > > > > > > yahoo mail), and use those to launch attacks. > > > > > > > > > > This can be solved with a change to the way SUBSCRIBE works, > > > > > basically the 202 > > > > > response only returns contacts present in the SUBSCRIBE. That > > > > > way the presence > > > > > server only needs to use the SUBSCRIBE to generate the > > > > > response and the NOTIFY > > > > > and doesn't need to store state about the SUBSCRIBE. (200s > > > > > are unaffected) > > > > > > > > > > Comments gratefully received > > > > > > > >I'm not following you. What has contacts in the SUBSCRIBE > > > got to do with > > > >it? > > > >How do you avoid the need to store pending subscription > > > state in the case > > > >where this is a legitimate subscription? > > > > > > > I envisaged this as a solution to the case where the > > > subscriber has been > > > rejected with the policy document but the presentity doesn't > > > want them to > > > know that. > > > >What is "this" in your sentence above? My question still > remains on what > >you > >mean by "contacts in the SUBSCRIBE"? > > When a SUBSCRIBE is sent to a Presence Server (PS) it > contains Contact > headers, where the NOTIFYs will be sent. I believe (but have > been unable to > confirm in the 01 draft yet) That a 2xx response should > contain a list of > Contact headers relevent to the subscription, this is fine > for 200s as the > user has been authenticated and authorised, however, for 202 > that might have > been rejected as unauthorised, you don't want to maintain > enough state to > return all the Contact headers that they believe should be > attached to the > subscription (based on To, From and Call-ID). It may be > better to mandate > that 202 responses only contain Contact headers present in > the SUBSCRIBE > that generated the response. This allows a PS which knows > this subscription > is rejected as unauthorised to respond without storing state > about the > Contact headers the rejected subscription may have previously > supplied. > Where the status of the subscription's authorisation is > unknown the Contact > headers will have to be stored, but DoS from rejected > subscriptions will be > prevented without leaking presence info. > > I realise this might not make sense as I haven't really > expanded my thinking > of how a presence authorisation policy processing language > might look, but I > hope it helps. > > James Undery > > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From jundery@hotmail.com Wed Mar 21 15:49:06 2001 Received: from hotmail.com (law2-f36.hotmail.com [216.32.181.36]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09498 for ; Wed, 21 Mar 2001 15:49:05 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 21 Mar 2001 12:49:00 -0800 Received: from 135.222.65.19 by lw2fd.hotmail.msn.com with HTTP; Wed, 21 Mar 2001 20:49:00 GMT X-Originating-IP: [135.222.65.19] Reply-To: jundery@ubiquity.net From: "James Undery" To: rsparks@dynamicsoft.com, jundery@ubiquity.net, jdrosen@dynamicsoft.com Cc: Adam.Roach@am1.ericsson.se, simple@mailman.dynamicsoft.com Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) Date: Wed, 21 Mar 2001 20:49:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2001 20:49:00.0825 (UTC) FILETIME=[5B766890:01C0B248] Content-Length: 1346 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: >Actually, with -01 we're tracking sip-events, so the subscribe >provides only one contact to be notified, and the final >response contains the contact of the responding UAS (like >INVITE), so that record-route can work. This would account for the lack of info I found, the sip-events draft is a little confused about contacts and the relationship of SUBSCRIBE to REGISTER. i.e. it requires a Contact Header in 1xx responses and claims a similarity to REGISTER in at least two places where it differs! In this case DoS by flooding the PS with state isn't a worry as my suggestion still stands for all rejected subscriptions where authorisation has been refused, without the presentity wishing this disclosed. Is it sensible to suggest that 2xx responses to a SUBSCRIBE don't contain either a Record-Route or a contact and both these elements be potentially present only in the accompanying NOTIFY which solves some forking issues with RR. (I think, Record-Route isn't my strength and Jo isn't here to help, but any partially constructed Record-Route could be placed and used in the NOTIFYs I assume or else Adam's previous suggestion for the RR problem wouldn't work) James Undery _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From Adam.Roach@am1.ericsson.se Wed Mar 21 18:19:12 2001 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 SAA09893 for ; Wed, 21 Mar 2001 18:19:12 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2LNJB924671 for ; Wed, 21 Mar 2001 17:19:11 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2LNJBm11625 for ; Wed, 21 Mar 2001 17:19:11 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Mar 21 17:19:10 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Mar 2001 17:21:00 -0600 Message-ID: <61D824C63B99D311975E00508B0CC98501E624CC@eamrcnt717.exu.ericsson.se> From: "Adam Roach (EUS)" To: jundery@ubiquity.net, rsparks@dynamicsoft.com, jdrosen@dynamicsoft.com Cc: Adam.Roach@am1.ericsson.se, simple@mailman.dynamicsoft.com Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) Date: Wed, 21 Mar 2001 17:20:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B25D.95DC9DA0" Content-Length: 7152 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: 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_01C0B25D.95DC9DA0 Content-Type: text/plain; charset="iso-8859-1" Thanks. I'll try to find the inconsistencies you cite (although section numbers on your part would help considerably) and clean them up for the next release. The confusion stems from the fact that -00 actually *did* allow multiple contacts (like REGISTER), but we later decided to take that behavour out (for a variety of reasons). We'll probably leave the "Contact" and "Record-Route" behaviour in the SUBSCRIBE responses just for the purpose of generality (fewer exceptions = simpler code), although the route will (in some forking cases) be derived from the NOTIFY response. /a > -----Original Message----- > From: James Undery [mailto:jundery@hotmail.com] > Sent: Wednesday, March 21, 2001 2:49 PM > To: rsparks@dynamicsoft.com; jundery@ubiquity.net; > jdrosen@dynamicsoft.com > Cc: Adam.Roach@am1.ericsson.se; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] DoS from rejected subscriptions (was > Replacing the > Q AUTH concept) > > > >Actually, with -01 we're tracking sip-events, so the subscribe > >provides only one contact to be notified, and the final > >response contains the contact of the responding UAS (like > >INVITE), so that record-route can work. > > This would account for the lack of info I found, the > sip-events draft is a > little confused about contacts and the relationship of SUBSCRIBE to > REGISTER. i.e. it requires a Contact Header in 1xx responses > and claims a > similarity to REGISTER in at least two places where it differs! > > In this case DoS by flooding the PS with state isn't a worry as my > suggestion still stands for all rejected subscriptions where > authorisation > has been refused, without the presentity wishing this disclosed. > > Is it sensible to suggest that 2xx responses to a SUBSCRIBE > don't contain > either a Record-Route or a contact and both these elements be > potentially > present only in the accompanying NOTIFY which solves some > forking issues > with RR. (I think, Record-Route isn't my strength and Jo > isn't here to help, > but any partially constructed Record-Route could be placed > and used in the > NOTIFYs I assume or else Adam's previous suggestion for the > RR problem > wouldn't work) > > James Undery > > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. ------_=_NextPart_001_01C0B25D.95DC9DA0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept)

Thanks. I'll try to find the inconsistencies you cite (although
section numbers on your part would help considerably) and clean
them up for the next release.

The confusion stems from the fact that -00 actually *did* allow
multiple contacts (like REGISTER), but we later decided to take
that behavour out (for a variety of reasons). We'll probably leave
the "Contact" and "Record-Route" behaviour in the SUBSCRIBE
responses just for the purpose of generality (fewer exceptions =
simpler code), although the route will (in some forking cases) be
derived from the NOTIFY response.

/a

> -----Original Message-----
> From: James Undery [mailto:jundery@hotmail.com]
> Sent: Wednesday, March 21, 2001 2:49 PM
> To: rsparks@dynamicsoft.com; jundery@ubiquity.net;
> jdrosen@dynamicsoft.com
> Cc: Adam.Roach@am1.ericsson.se; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] DoS from rejected subscriptions (was
> Replacing the
> Q AUTH concept)
>
>
> >Actually, with -01 we're tracking sip-events, so the subscribe
> >provides only one contact to be notified, and the final
> >response contains the contact of the responding UAS (like
> >INVITE), so that record-route can work.
>
> This would account for the lack of info I found, the
> sip-events draft is a
> little confused about contacts and the relationship of SUBSCRIBE to
> REGISTER. i.e. it requires a Contact Header in 1xx responses
> and claims a
> similarity to REGISTER in at least two places where it differs!
>
> In this case DoS by flooding the PS with state isn't a worry as my
> suggestion still stands for all rejected subscriptions where
> authorisation
> has been refused, without the presentity wishing this disclosed.
>
> Is it sensible to suggest that 2xx responses to a SUBSCRIBE
> don't contain
> either a Record-Route or a contact and both these elements be
> potentially
> present only in the accompanying NOTIFY which solves some
> forking issues
> with RR. (I think, Record-Route isn't my strength and Jo
> isn't here to help,
> but any partially constructed Record-Route could be placed
> and used in the
> NOTIFYs I assume or else Adam's previous suggestion for the
> RR problem
> wouldn't work)
>
> James Undery
>
> ______________________________________________________________
> ___________
> Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com.

------_=_NextPart_001_01C0B25D.95DC9DA0-- From jdrosen@dynamicsoft.com Wed Mar 21 21:42:54 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA10417 for ; Wed, 21 Mar 2001 21:42:53 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA13748; Wed, 21 Mar 2001 21:46:11 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Mar 2001 21:44:49 -0500 Message-ID: From: Jonathan Rosenberg To: "'Adam Roach (EUS)'" , jundery@ubiquity.net, Robert Sparks , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) Date: Wed, 21 Mar 2001 21:44:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3837 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: -----Original Message----- >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsson.se] >Sent: Wednesday, March 21, 2001 6:21 PM >To: jundery@ubiquity.net; rsparks@dynamicsoft.com; jdrosen@dynamicsoft.com >Cc: Adam.Roach@am1.ericsson.se; simple@mailman.dynamicsoft.com >Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) > > >Thanks. I'll try to find the inconsistencies you cite (although >section numbers on your part would help considerably) and clean >them up for the next release. > >The confusion stems from the fact that -00 actually *did* allow >multiple contacts (like REGISTER), but we later decided to take >that behavour out (for a variety of reasons). We'll probably leave >the "Contact" and "Record-Route" behaviour in the SUBSCRIBE >responses just for the purpose of generality (fewer exceptions = >simpler code), although the route will (in some forking cases) be >derived from the NOTIFY response. We haven't agreed to that one yet. At the moment, SUBSCRIBE has INVITE semantics in terms of Contact, REcord-Route and Route processing, and thats it. I still remain hesitant about getting notifications from multiple independent devices. I think the complexity will lie in the reconstitution of a single presence document from the notifications. It also reintroduces the annoyance of parallel forking, that you can never know when you are finished getting 200 OK. Here, I may keep getting notifies for additional new call legs. Its kind of nice that once the 200 OK to subscribe comes, I know the one and only place notifies will come from. Might be useful to discuss this tomorrow. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com /a > -----Original Message----- > From: James Undery [mailto:jundery@hotmail.com] > Sent: Wednesday, March 21, 2001 2:49 PM > To: rsparks@dynamicsoft.com; jundery@ubiquity.net; > jdrosen@dynamicsoft.com > Cc: Adam.Roach@am1.ericsson.se; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] DoS from rejected subscriptions (was > Replacing the > Q AUTH concept) > > > >Actually, with -01 we're tracking sip-events, so the subscribe > >provides only one contact to be notified, and the final > >response contains the contact of the responding UAS (like > >INVITE), so that record-route can work. > > This would account for the lack of info I found, the > sip-events draft is a > little confused about contacts and the relationship of SUBSCRIBE to > REGISTER. i.e. it requires a Contact Header in 1xx responses > and claims a > similarity to REGISTER in at least two places where it differs! > > In this case DoS by flooding the PS with state isn't a worry as my > suggestion still stands for all rejected subscriptions where > authorisation > has been refused, without the presentity wishing this disclosed. > > Is it sensible to suggest that 2xx responses to a SUBSCRIBE > don't contain > either a Record-Route or a contact and both these elements be > potentially > present only in the accompanying NOTIFY which solves some > forking issues > with RR. (I think, Record-Route isn't my strength and Jo > isn't here to help, > but any partially constructed Record-Route could be placed > and used in the > NOTIFYs I assume or else Adam's previous suggestion for the > RR problem > wouldn't work) > > James Undery > > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From Romeo.Zwart@att.com Fri Mar 23 09:59:43 2001 Received: from mushroom.icoe.net (mushroom.icoe.net [194.242.71.50]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16103 for ; Fri, 23 Mar 2001 09:59:42 -0500 (EST) Received: by mushroom.icoe.net; id QAA20612; Fri, 23 Mar 2001 16:00:25 +0100 (CET) Received: from unknown(135.76.170.11) by mushroom.icoe.net via smap (4.0a) id xma020395; Fri, 23 Mar 01 15:59:41 +0100 Received: from romeo-home.icoe.att.com (mikan.icoe.att.com [135.76.170.4]) by watermelon.icoe.att.com (Postfix) with ESMTP id B106B11592; Fri, 23 Mar 2001 16:58:00 +0100 (MET) Message-Id: <5.0.0.25.0.20010323154457.01faf008@watermelon.icoe.att.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 23 Mar 2001 15:58:10 +0100 To: simple@mailman.dynamicsoft.com From: Romeo Zwart Cc: dean.willis@softarmor.com, sriramp@nortelnetworks.com, Uri.Baniel@motorola.com, ISlepchin@dynamicsoft.com, wtm@research.att.com, jdrosen@dynamicsoft.com, romeo.zwart@att.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 8734 Subject: [Simple] Questions on draft-rosenberg-impp-presence-01 (was: RE: [SIP] Informing UA after network initated deregistration?) 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: A recent thread on the SIP list discussed the need to notify a UA of the (network initiated) revocation of its registration. According to the attached message from Jonathan, the general view is that this could be handled by the mechanisms described in the sip-for-presence events package. My understanding is that the Registrar maintains the registration state for the UA and thus could keep the Presence Agent (PA) role for the UA. The UA then SUBSCRIBEs to its own presence information at the PA (Registrar). In the case of a network initiated (or any other) change in the Registration state, the PA provides this information to the UA by sending a NOTIFY with the new state information. This allows the UA and Registrar to keep the same view of the Registration state of the user and possibly also allows for providing other service related information to the UA. I'd be interested to hear your comments on this view. Related I have a few questions on draft-rosenberg-impp-presence-01: - In section 5.4, the presence data format is listed as TBD. Examples later in the document seem to focus on XML. Has there been any progress on this issue? Could someone point me to the relevant discussion (could not find anything in the archives)? - In the last paragraph of section 3, the statement is being made that a NOTIFY is being treated in the same way as a re-INVITE, whereas the SUBSCRIBE is handled similar to an INVITE. I am not sure understand the reasoning behind that. In case this has been discussed on the list, could someone provide me with a pointer to the related thread? Otherwise, could someone explain the rationale behind it? - The SIP event framework document mentions the possible use of implicit subscription, where a UA may receive NOTIFY's without having explicitly SUBSCRIBED to the related events. Implicit subscription is not mentioned in the ipmm draft. Is this because it was not considered appropriate or because it was considered an implementation detail? Thanks, Romeo ------------------------ >From: Jonathan Rosenberg >To: "'Dean Willis'" , > Sriram Parameswar , > "'Baniel Uri-CUB001'" , > Igor Slepchin , > "'William Marshall'" , sip@lists.bell-labs.com >Subject: RE: [SIP] Informing UA after network initated deregistration? >Date: Wed, 21 Mar 2001 02:15:02 -0500 > >For those not at IETF: > >We discussed this open issue. The conclusion is that there already exists >a general purpose mechanism for learning about network de-registrations. >In fact, the mechanism allows you to learn about any changes in the >registration state of a user. That mechanism is the sip for presence >specifications, draft-rosenberg-impp-presence-01.txt, which are now work >items of the simple working group. > >Whether this is useful for dealing with thieves stealing phones is an >application issue. THe mechanisms exists and is being standardized. They >require no changes to bis. Thus, the open issue is closed. > >-Jonathan R. > > >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen >PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >-----Original Message----- >From: Dean Willis [mailto:dean.willis@softarmor.com] >Sent: Tuesday, March 20, 2001 10:39 AM >To: Sriram Parameswar; 'Baniel Uri-CUB001'; 'Igor Slepchin'; 'William >Marshall'; sip@lists.bell-labs.com >Subject: Re: [SIP] Informing UA after network initated deregistration? > > >here's the problem -- cancelling the registration neither prevents the >phone from sending or receiving calls. It merely prevents any proxy >associated with the cancelling registrar from correctly proxying calls to >the deregistered identity. So, the thief just tells his buddies to call >him by IP address and not by phone number -- so the registration is never >even accessed. Or the "thief" loads a DNS A record for the phone into >another domain (maybe an A record for "myphone" into domain >"phonethief.com"), again bypassing registration. > >-- >Dean >----- Original Message ----- >From: Sriram Parameswar >To: 'Baniel Uri-CUB001' ; >'Igor Slepchin' ; >'William Marshall' ; >sip@lists.bell-labs.com >Sent: Friday, March 16, 2001 4:09 PM >Subject: RE: [SIP] Informing UA after network initated deregistration? > >Hi All, > >One scenario which was not discussed for network initiated >de-registration. In the cellular world - fraud/lost or stolen mobiles >present a problem. >In the case that your subscriber loses his mobile and reports it, the >operator may choose to de-register the mobile thus disallowing Mobile >Originated and Mobile Terminated calls. I see this as a perfectly >legitimate use of Network initiated de-registration. >Just to add a little bit more to the discussion - there are contributions >in 3GPP that talk of 'NOTIFY'ing the subscriber when such de-registrations >happen. >Regards, > >Sriram > >__________________________________________ >Sriram Parameswar Phone: 972-685-8540 >Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 >Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > >-----Original Message----- >From: Baniel Uri-CUB001 >[mailto:Uri.Baniel@motorola.com] >Sent: Saturday, March 10, 2001 7:42 AM >To: 'Igor Slepchin'; 'William Marshall'; sip@lists.bell-labs.com >Subject: RE: [SIP] Informing UA after network initated deregistration? > >Igor > >Network initiated deregistration may happen for various reasons. >Ironically I do not see 'registrar crashing' as one of them... (Hot backup >etc is just as you say far beyond SIP and shall not concern us in this >regard). It could be for instance: temporarily suspension of services for >a specific subscriber, because his/her pre paid billing ticket is empty... >I think it is expected by a subscriber to be notified when the system can >not serve him/her. >He/she may be a bit cranky if he/she was expecting a very important call, >and only after 20 minutes has realized the phone was out of service.. >(These are exactly the things that distinguish between real systems and >kids/hackers toys) >(again just like the cellular analogy). If your system crashed in such a >way that your hot backup did not work, of course you can not do anything >about it. >If I sink in the see, I would probably not have enough time to instruct my >secretary how to pay my last phone bill.. > >It is true though, that we may want to leave it as an implementation offer >to a SIP operator. Still we need to offer him the way to do it, so as to >keep it standardized. >Uri > >-----Original Message----- >From: Igor Slepchin >[mailto:ISlepchin@dynamicsoft.com] >Sent: Friday, March 09, 2001 5:15 PM >To: 'William Marshall'; sip@lists.bell-labs.com >Subject: RE: [SIP] Informing UA after network initated deregistration? > > > -----Original Message----- > > From: William Marshall > [mailto:wtm@research.att.com] > > > > I think rather than debating the various situations in which > > a network operator may delete a registration (and prevent further > > service to that subscriber), the more appropriate question for > > this group is how to inform the UA that it has happened. > >I haven't yet seen a good argument about why it's necessary. If the problem >is taking the registrar down for maintenance, it's well beyond SIP realm - >there are lots of highly available database solution on the market that >allow this. > >The example with GUI notification is rather far-fetched in my opinion. The >reachability of a SIP phone is by no means limited by its registrar. What >happens if the access proxy dies? or the router, the ether switch, Internet >backbone goes down etc? > >Thank you, >Igor Slepchin > >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementor's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > From mwatson@nortelnetworks.com Fri Mar 23 10:39:41 2001 Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16224 for ; Fri, 23 Mar 2001 10:39:31 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Fri, 23 Mar 2001 15:20:18 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Mar 2001 15:20:16 -0000 Message-ID: From: "Mark Watson" To: "'simple@mailman.dynamicsoft.com'" Date: Fri, 23 Mar 2001 15:20:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B3AC.C3D22590" Content-Length: 6349 Subject: [Simple] IM support in SIP 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: 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_01C0B3AC.C3D22590 Content-Type: text/plain; charset="iso-8859-1" All, Sorry to be arriving at this debate late. I was interested in why the choice was made to implement IM as a new SIP method rather than as a new kind of media, indicated in the SDP and transparent to the SIP layer. I read through the thread on 'Multiparty IM', in which this proposal was made. The answer given there was that the existing text support in RTP is for 'streaming', rather than support of discrete messages. This only answers why the existing RTP text support is different from Instant Messaging, not why treating IM as a new type of media is wrong. Perhaps this has been resolved at a meeting - if so I'd be very grateful if someone could indulge me with an explanation. There seems to be a confusion as to whether IM is 'session-oriented' - like a conversation - or atomic with individual messages being independent of each other. In the latter case (which seems to be how it is described in the CPIM RFCs) I can see why a simple MESSAGE method does the job. In the former case (which seems to be how people think of using IM) it would seem more sensible to incorporate the 'session' concept from the start. It does seem to me that IM is just another media type - sure it is not a 'streamed' media, but consists of a series of discrete messages, but nevertheless there is no reason to place additional requirements on the SIP layer to support this new media type. Also, suppose an average IM 'session' consists of 12 messages (this is a guess), then the real-time requirements at a proxy for this IM session will be 4 times (12 transactions vs. 3) as great as for a normal SIP session - it will be strange for proxy capacity for IM sessions to be so much less than for streaming media sessions. Equally, looking forward to other media types which may or may not be streamed, the QoS requirements for the media will generally be different from those of the control signalling. Further it makes no sense to route media via the signalling path, instead of directly between the participants. Remember the signalling path will often be non-optimal in terms of RTT, since it may be necessary to route the signalling via a users home proxy in order to find them. Apologies if I'm missing something here. I thought the idea of SIP was that it would be a generic protocol for establishment of many types of session-based real-time communication applications, and yet the proposal here is to invent an application-specific SIP mechanism. Regards, Mark Watson Nortel Networks ------_=_NextPart_001_01C0B3AC.C3D22590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IM support in SIP

All,

Sorry to be arriving at this debate = late. I was interested in why the choice was made to implement IM as a = new SIP method rather than as a new kind of media, indicated in the SDP = and transparent to the SIP layer.

I read through the thread on = 'Multiparty IM', in which this proposal was made. The answer given = there was that the existing text support in RTP is for 'streaming', = rather than support of discrete messages.

This only answers why the existing = RTP text support is different from Instant Messaging, not why treating = IM as a new type of media is wrong.

Perhaps this has been resolved at a = meeting - if so I'd be very grateful if someone could indulge me with = an explanation.

There seems to be a confusion as to = whether IM is 'session-oriented' - like a conversation - or atomic with = individual messages being independent of each other. In the latter case = (which seems to be how it is described in the CPIM RFCs) I can see why = a simple MESSAGE method does the job. In the former case (which seems = to be how people think of using IM) it would seem more sensible to = incorporate the 'session' concept from the start.

It does seem to me that IM is just = another media type - sure it is not a 'streamed' media, but consists of = a series of discrete messages, but nevertheless there is no reason to = place additional requirements on the SIP layer to support this new = media type.

Also, suppose an average IM = 'session' consists of 12 messages (this is a guess), then the real-time = requirements at a proxy for this IM session will be 4 times (12 = transactions vs. 3) as great as for a normal SIP session - it will be = strange for proxy capacity for IM sessions to be so much less than for = streaming media sessions.

Equally, looking forward to other = media types which may or may not be streamed, the QoS requirements for = the media will generally be different from those of the control = signalling. Further it makes no sense to route media via the signalling = path, instead of directly between the participants. Remember the = signalling path will often be non-optimal in terms of RTT, since it may = be necessary to route the signalling via a users home proxy in order to = find them.

Apologies if I'm missing something = here. I thought the idea of SIP was that it would be a generic protocol = for establishment of many types of session-based real-time = communication applications, and yet the proposal here is to invent an = application-specific SIP mechanism.

Regards,

Mark Watson
Nortel Networks

------_=_NextPart_001_01C0B3AC.C3D22590-- From jdrosen@dynamicsoft.com Fri Mar 23 13:18:59 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16655 for ; Fri, 23 Mar 2001 13:18:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA01657; Fri, 23 Mar 2001 12:56:06 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Mar 2001 12:54:41 -0500 Message-ID: From: Jonathan Rosenberg To: "'Mark Watson'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] IM support in SIP Date: Fri, 23 Mar 2001 12:54:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5056 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: -----Original Message----- >From: Mark Watson [mailto:mwatson@nortelnetworks.com] >Sent: Friday, March 23, 2001 10:20 AM >To: 'simple@mailman.dynamicsoft.com' >Subject: [Simple] IM support in SIP > > >All, >Sorry to be arriving at this debate late. I was interested in why the choice was made to >implement IM as a new SIP method rather than as a new kind of media, indicated in the SDP >and transparent to the SIP layer. Indeed, this was the primary subject of discussion at the simple meeting. > >I read through the thread on 'Multiparty IM', in which this proposal was made. The answer >given there was that the existing text support in RTP is for 'streaming', rather than >support of discrete messages. > >This only answers why the existing RTP text support is different from Instant Messaging, >not why treating IM as a new type of media is wrong. > >Perhaps this has been resolved at a meeting - if so I'd be very grateful if someone could >indulge me with an explanation. The reason we went for the solution documented in -01 is the "dual" nature of messaging. In many systems today, there is no setup or establishment - you send a message, and thats it. Whether to treat it as "media" or a mesasge on the sip path was debated in the beginning, with myself, primarily, arguing for the asynchronous messaging model rather than a session model. I've come to realize since then that this is probably not the right view, for both the service and its usage in SIP. So, during simple, I proposed making messaging a "media service", signaled in SDP. Its not over RTP, and in fact, as a "media service", it itself uses SIP and the current MESSAGE method between endpoints directly. This has many advantages. > >There seems to be a confusion as to whether IM is 'session-oriented' - like a conversation >- or atomic with individual messages being independent of each other. In the latter case >(which seems to be how it is described in the CPIM RFCs) I can see why a simple MESSAGE >method does the job. In the former case (which seems to be how people think of using IM) it >would seem more sensible to incorporate the 'session' concept from the start. Right. So, the current proposal is that to set up a messaging session, you send an INVITE, indicate a message session in SDP, and then send messages directly between end systems (exception is case of nat... see slides on the subject from the meeting). When done, send BYE. Another approach is if you want messaging, you can send sip MESSAGE through the sip network, but this does NOT setup a session. Its just like any other non-INVITE message, such as OPTIONS. No session, no record-routing, no nothing. > >It does seem to me that IM is just another media type - sure it is not a 'streamed' media, >but consists of a series of discrete messages, but nevertheless there is no reason to place >additional requirements on the SIP layer to support this new media type. Correct. > >Also, suppose an average IM 'session' consists of 12 messages (this is a guess), then the >real-time requirements at a proxy for this IM session will be 4 times (12 transactions vs. >3) as great as for a normal SIP session - it will be strange for proxy capacity for IM >sessions to be so much less than for streaming media sessions. Again, correct. Its also really troublesome for messages with large payloads. > >Equally, looking forward to other media types which may or may not be streamed, the QoS >requirements for the media will generally be different from those of the control >signalling. Further it makes no sense to route media via the signalling path, instead of >directly between the participants. Remember the signalling path will often be non-optimal >in terms of RTT, since it may be necessary to route the signalling via a users home proxy >in order to find them. Yes, also a good point. > >Apologies if I'm missing something here. I thought the idea of SIP was that it would be a >generic protocol for establishment of many types of session-based real-time communication >applications, and yet the proposal here is to invent an application-specific SIP mechanism. So, there was not really consensus on the protocol to use the session oriented approach, although I think the concerns centered mostly on whether that meant we would or would not offer a "page" type of service where the messages went through the sip network, without any sessions. This is the most important issue we need to resolve for simple, and I think we should focus list discussion on this. The slides on the proposal will be available shortly, and I'll also post a note quickly summarizing the proposal to kick off discussions. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From rrroy@att.com Fri Mar 23 14:08:06 2001 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 OAA16805 for ; Fri, 23 Mar 2001 14:08:02 -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 f2NJ80Z28891; Fri, 23 Mar 2001 14:08:00 -0500 (EST) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id OAA02948; Fri, 23 Mar 2001 14:07:15 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Mar 2001 14:07:59 -0500 Message-ID: From: "Roy, Radhika R, ALCOO" To: Jonathan Rosenberg , "'Mark Watson'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] IM support in SIP Date: Fri, 23 Mar 2001 14:07:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2169 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: -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, March 23, 2001 12:55 PM To: 'Mark Watson'; 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] IM support in SIP > >Apologies if I'm missing something here. I thought the idea of SIP was that it would be a >generic protocol for establishment of many types of session-based real-time communication >applications, and yet the proposal here is to invent an application-specific SIP mechanism. So, there was not really consensus on the protocol to use the session oriented approach, although I think the concerns centered mostly on whether that meant we would or would not offer a "page" type of service where the messages went through the sip network, without any sessions. This is the most important issue we need to resolve for simple, and I think we should focus list discussion on this. The slides on the proposal will be available shortly, and I'll also post a note quickly summarizing the proposal to kick off discussions. [RRR/] It appears that it would be good to make the IM-related method specific to the following characteristics: 1. Minimum delay with real-time response and 2. Only one-way transmission of the message. The important point is that IM-like application (or something similar to this [may be paging who knows] in the future) has a special characteristics that is NOT equivalent to the sharing of text and/graphics establishing among the conference participants after establishing the session. So, the establishment of the real-time session may NOT be applicable in the IM-like environment. - Radhika R. Roy [/RRR]. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From m_mhurtubise@yahoo.com Sun Mar 25 00:42:01 2001 Received: from mail.serv.com (HSE-Ottawa-ppp160981.sympatico.ca [64.229.144.96]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id AAA21975 for ; Sun, 25 Mar 2001 00:41:57 -0500 (EST) From: To: Date: Sun, 25 Mar 2001 02:53:59 Message-Id: <651.199961.781551@mail.serv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Length: 14389 Subject: [Simple] That Little Extra 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: AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months right from your home !! THANK'S TO THE COMPUTER AGE AND THE INTERNET ! ================================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can -follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so gladI finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $610,470.00 in 21 weeks, with money still coming in." Pam Hedland, Fort Lee, New Jersey. =================================================== Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, ===== PRINT THIS NOW FOR YOUR FUTUREREFERENCE ====== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: =====Order all 5 reports shown on the list below ===== For each report, send $5 CASH (US FUNDS ONLY), THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. === When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work !!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ========================================================== **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1: BY SENDING BULK E-MAIL LEGALLY ========================================================== Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGUREOUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ========================================================= REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET ======================================================= Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and dd METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receivethe report. =========== AVAILABLE REPORTS ==================== ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY ONLY!!) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ==================================================== REPORT # 1: "The Insider's Guide to Advertising for Free on the Net" Order Report #1 from: B. McDonald Suite 409 1500 Bank St Ottawa, ON K1H 1B8 Canada ___________________________________________________________ REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the Net" Order Report # 2 from: T. Richardson P.O. Box 753 Richland, MO. 65556 USA ____________________________________________________________ REPORT # 3: "Secret to Multilevel Marketing on the Net" Order Report # 3 from : C.J. Kalata P.O. Box 130157 Roseville, MN 55113 USA ____________________________________________________________ REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" Order Report # 4 from: R. B. Box. 21115, Grande Prairie Alberta, T8V-6W7 Canada ____________________________________________________________ REPORT #5: "How to Send Out 0ne Million e-mails for Free" Order Report # 5 from: B. Taylor P.O.Box 26001 Fredericton, N.B. E3A 5V8 Canada _____________________________________________________________ $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. === Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ====================================================== FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ..........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ============ MORE TESTIMONIALS ================ "My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jodyaboutreceiving ''junk mail''. I made fun of the whole thing,spoutingmy knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ====================================================== ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ======================================================= ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks." Susan De Suza, New York, N.Y. ======================================================= ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thanx to internet.". Fred Dellaca, Westport, New Zealand ======================================================= ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR' ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. From theodore.havinis@openwave.com Sun Mar 25 19:25:24 2001 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 TAA24955 for ; Sun, 25 Mar 2001 19:25:24 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010326002514.VJDI3399.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net> for ; Sun, 25 Mar 2001 18:25:14 -0600 Received: from harviniT ([198.78.34.47]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with SMTP id <20010326002523.NXVP2907.oe-ismta1.bizmailsrvcs.net@harviniT> for ; Sun, 25 Mar 2001 18:25:23 -0600 From: "Theodore Havinis" To: Date: Sun, 25 Mar 2001 16:25:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 188 Subject: [Simple] Testing - Pls ignore Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: -------------------------------------------- T Havinis email: theodore.havinis@openwave.com mobile: (650) 776-7249 fixed : (650) 817-1535 -------------------------------------------- From Adam.Roach@am1.ericsson.se Tue Mar 27 13:16:43 2001 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 NAA05318 for ; Tue, 27 Mar 2001 13:16:43 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2RIGbm20113 for ; Tue, 27 Mar 2001 12:16:37 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f2RIGbL01428 for ; Tue, 27 Mar 2001 12:16:37 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Mar 27 12:16:36 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Mar 2001 12:16:36 -0600 Message-ID: <61D824C63B99D311975E00508B0CC9850E869E@eamrcnt717.exu.ericsson.se> From: "Adam Roach (EUS)" To: "'Jonathan Rosenberg'" , "Adam Roach (EUS)" , jundery@ubiquity.net, Robert Sparks Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] DoS from rejected subscriptions (was Replacing the Q AUTH concept) Date: Tue, 27 Mar 2001 12:16:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0B6EA.0F213190" Content-Length: 6662 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: 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_01C0B6EA.0F213190 Content-Type: text/plain; charset="iso-8859-1" > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsson.se] > > > >The confusion stems from the fact that -00 actually *did* allow > >multiple contacts (like REGISTER), but we later decided to take > >that behavour out (for a variety of reasons). We'll probably leave > >the "Contact" and "Record-Route" behaviour in the SUBSCRIBE > >responses just for the purpose of generality (fewer exceptions = > >simpler code), although the route will (in some forking cases) be > >derived from the NOTIFY response. > > We haven't agreed to that one yet. At the moment, SUBSCRIBE has INVITE > semantics in terms of Contact, REcord-Route and Route > processing, and thats > it. Sorry; I didn't mean to imply that we had formed a consensus on this topic yet. > I still remain hesitant about getting notifications from multiple > independent devices. I think the complexity will lie in the > reconstitution > of a single presence document from the notifications. It also > reintroduces > the annoyance of parallel forking, that you can never know > when you are > finished getting 200 OK. Here, I may keep getting notifies > for additional > new call legs. Its kind of nice that once the 200 OK to > subscribe comes, I > know the one and only place notifies will come from. I think you made a telling slip in your phrasing there: "reconstitution of a single **PRESENCE** document." In the general case, SUB/NOT is about more than presence. (Yes, I know that we're on the SIMPLE list, but the question seemed aimes at general SUB/NOT behaviour). I encourage SIP presence to define nominal behavior as rejecting all but the single "winning" notification. However, if I am just querying for something simple like terminal free/busy state, a merge isn't that difficult -- and makes buckets of sense. The same holds for a large set of interesting states which may be described in event packages. So, as a base, I beleive SUB/NOT should allow this sort of structure, so that event packages can use it if it makes sense. When it doesn't, like in presence, the event packages may discourage or forbid it. /a ------_=_NextPart_001_01C0B6EA.0F213190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] DoS from rejected subscriptions (was Replacing the = Q AUTH concept)

> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>
> >From: Adam Roach (EUS) [mailto:Adam.Roach@am1.ericsso= n.se]
> >
> >The confusion stems from the fact that -00 = actually *did* allow
> >multiple contacts (like REGISTER), but we = later decided to take
> >that behavour out (for a variety of = reasons). We'll probably leave
> >the "Contact" and = "Record-Route" behaviour in the SUBSCRIBE
> >responses just for the purpose of = generality (fewer exceptions =3D
> >simpler code), although the route will (in = some forking cases) be
> >derived from the NOTIFY response.
>
> We haven't agreed to that one yet. At the = moment, SUBSCRIBE has INVITE
> semantics in terms of Contact, REcord-Route and = Route
> processing, and thats
> it.

Sorry; I didn't mean to imply that we had formed a = consensus on this
topic yet.
 
> I still remain hesitant about getting = notifications from multiple
> independent devices. I think the complexity = will lie in the
> reconstitution
> of a single presence document from the = notifications. It also
> reintroduces
> the annoyance of parallel forking, that you can = never know
> when you are
> finished getting 200 OK. Here, I may keep = getting notifies
> for additional
> new call legs. Its kind of nice that once the = 200 OK to
> subscribe comes, I
> know the one and only place notifies will come = from.

I think you made a telling slip in your phrasing = there:
"reconstitution of a single **PRESENCE** = document." In the
general case, SUB/NOT is about more than presence. = (Yes, I
know that we're on the SIMPLE list, but the question = seemed
aimes at general SUB/NOT behaviour). I encourage SIP = presence
to define nominal behavior as rejecting all but the = single
"winning" notification.

However, if I am just querying for something simple = like
terminal free/busy state, a merge isn't that = difficult --
and makes buckets of sense. The same holds for a = large set
of interesting states which may be described in = event
packages. So, as a base, I beleive SUB/NOT should = allow
this sort of structure, so that event packages can = use
it if it makes sense. When it doesn't, like in = presence,
the event packages may discourage or forbid = it.

/a

------_=_NextPart_001_01C0B6EA.0F213190-- From eusadam@exu.ericsson.se Tue Mar 27 19:50:01 2001 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 TAA06332 for ; Tue, 27 Mar 2001 19:50:00 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f2S0nxm08117; Tue, 27 Mar 2001 18:49:59 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f2S0nxB21552; Tue, 27 Mar 2001 18:49:59 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA23269; Tue, 27 Mar 2001 18:49:58 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id SAA16165; Tue, 27 Mar 2001 18:50:47 -0600 (CST) Message-Id: <200103280050.SAA16165@b04a24.exu.ericsson.se> To: sip-events@standards.ericsson.net Date: Tue, 27 Mar 2001 18:50:46 -0600 (CST) From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 904 Subject: [Simple] SIP Events list has moved. 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: At the request of the area directors, we will discontinue using the sip-events mailing list on Yahoo as of now. A new mailing list has been created to replace it. To subscribe, send a message to "sip-events-request@standards.ericsson.net" with the word "SUBSCRIBE" in the body. NOTE: That's "ericsson.net," not "ericsson.com." Crossposts between sip-events and the sip, sip-implementors, or simple mailing lists will be automatically blocked from sip-events. I am working on setting up an archive, hopefully incorporating the messages sent to the egroups/yahoo list. I will post to the sip-events list when this is available. If anyone has all previous sip-events e-mail messages (preferably in an RFC822 mailbox format), please contact me. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From jdrosen@dynamicsoft.com Fri Mar 30 16:23:25 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16848 for ; Fri, 30 Mar 2001 16:23:25 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA08766 for ; Fri, 30 Mar 2001 16:26:49 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Mar 2001 16:23:25 -0500 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Fri, 30 Mar 2001 16:23:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1775 Subject: [Simple] IM: A session or not 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: Folks, At the IETF meeting, we discussed the main open issue surrounding the IM draft: whether or not to view IM as a session, as a signaling path message, or both. I presented some slides that discussed this, which you can obtain at: http://www.cs.columbia.edu/~jdrosen/papers/simple_open_mar01.ppt We need to resolve this issue asap. I'd like to work from the following proposal: 1. We support the ability to establish IM as a session. This is accomplished through some SDP parameter registrations to signal whatever is needed to set it up, which we need to think about. 2. the messaging session is actually done using SIP, using the current MESSAGE method, as specified. The SDP would include things like the URL to use. Generally, these messages would then go directly between the participants. 3. A MESSAGE method can also be sent as a "page", over the SIP proxies, without having established a session. In this way, it works identially to OPTIONS. This supports SMS type of functionality, and makes more sense on one way devices. 4. A MESSAGE method can be sent over the proxy network, as part of an active session, rather than direct. As far as the end systems are concerned, it still appears as a session level media stream; it just happened to come in through an intermediary. This is actually a critical piece for nat. Is there consensus on this approach? Questions? Concerns? Flames? Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From rohan@cisco.com Fri Mar 30 19:31:05 2001 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17342 for ; Fri, 30 Mar 2001 19:31:05 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id QAA00254; Fri, 30 Mar 2001 16:29:48 -0800 (PST) Received: from buckthorn-nt.cisco.com (dhcp-128-107-141-224.cisco.com [128.107.141.224]) by imop.cisco.com (Mirapoint) with ESMTP id AAP98491 (AUTH rmahy); Fri, 30 Mar 2001 16:31:01 -0800 (PST) Message-Id: <5.0.0.25.2.20010330143507.02672680@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 30 Mar 2001 16:28:21 -0800 To: Jonathan Rosenberg From: Rohan Mahy Subject: Re: [Simple] IM: A session or not Cc: "'simple@mailman.dynamicsoft.com'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 2199 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: At 01:23 PM 3/30/01, Jonathan Rosenberg wrote: >Folks, > >At the IETF meeting, we discussed the main open issue surrounding the IM >draft: whether or not to view IM as a session, as a signaling path message, >or both. I presented some slides that discussed this, which you can obtain >at: > >http://www.cs.columbia.edu/~jdrosen/papers/simple_open_mar01.ppt > >We need to resolve this issue asap. > >I'd like to work from the following proposal: > >1. We support the ability to establish IM as a session. This is accomplished >through some SDP parameter registrations to signal whatever is needed to set >it up, which we need to think about. YUK! Why is this needed? Why not just REGISTER a Contact with a methods paramater (as below)? Contact: ;methods=MESSAGE thanks, -rohan >2. the messaging session is actually done using SIP, using the current >MESSAGE method, as specified. The SDP would include things like the URL to >use. Generally, these messages would then go directly between the >participants. >3. A MESSAGE method can also be sent as a "page", over the SIP proxies, >without having established a session. In this way, it works identially to >OPTIONS. This supports SMS type of functionality, and makes more sense on >one way devices. >4. A MESSAGE method can be sent over the proxy network, as part of an active >session, rather than direct. As far as the end systems are concerned, it >still appears as a session level media stream; it just happened to come in >through an intermediary. This is actually a critical piece for nat. > >Is there consensus on this approach? Questions? Concerns? Flames? > >Thanks, >Jonathan R. > > >--- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple From jdrosen@dynamicsoft.com Fri Mar 30 22:14:40 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA17784 for ; Fri, 30 Mar 2001 22:14:39 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA11767; Fri, 30 Mar 2001 22:18:02 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Mar 2001 22:14:37 -0500 Message-ID: From: Jonathan Rosenberg To: "'Rohan Mahy'" , Jonathan Rosenberg Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] IM: A session or not Date: Fri, 30 Mar 2001 22:14:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2163 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: > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Friday, March 30, 2001 7:28 PM > To: Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] IM: A session or not > > > At 01:23 PM 3/30/01, Jonathan Rosenberg wrote: > >Folks, > > > >At the IETF meeting, we discussed the main open issue > surrounding the IM > >draft: whether or not to view IM as a session, as a > signaling path message, > >or both. I presented some slides that discussed this, which > you can obtain > >at: > > > >http://www.cs.columbia.edu/~jdrosen/papers/simple_open_mar01.ppt > > > >We need to resolve this issue asap. > > > >I'd like to work from the following proposal: > > > >1. We support the ability to establish IM as a session. This > is accomplished > >through some SDP parameter registrations to signal whatever > is needed to set > >it up, which we need to think about. > > YUK! A truly compelling technical argument. > > Why is this needed? > Why not just REGISTER a Contact with a methods paramater (as below)? > Contact: ;methods=MESSAGE Because, we don't want to be sending IMs across the proxy network. The above approach would allow MESSAGE to go someplace different than INVITE, but it still goes over the proxy network. Furthermore, there is a lot of value in viewing IM as a session set up with SIP. Many of the reasons are outlined in the slides. To summarize: 1. forking actually works 2. you can actually clean up state in end systems which are automata (like an IM conference server, which you cannot build without this!) 3. you can avoid sending 5meg MP3 "IMs" over proxies 4. you can reuse alot of the sip tools we have constructed for sessions - transfers, multiparty conferencing, etc. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From hgs@cs.columbia.edu Fri Mar 30 22:22:12 2001 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 WAA17831 for ; Fri, 30 Mar 2001 22:22:11 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA14925; Fri, 30 Mar 2001 22:22:09 -0500 (EST) Message-ID: <3AC54D61.4AE42EA7@cs.columbia.edu> Date: Fri, 30 Mar 2001 22:22:09 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Rohan Mahy'" , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] IM: A session or not References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1675 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: Jonathan Rosenberg wrote: > > Because, we don't want to be sending IMs across the proxy network. The above > approach would allow MESSAGE to go someplace different than INVITE, but it > still goes over the proxy network. If we treat MESSAGE as being part of an INVITE session, but not as a media stream, such MESSAGES would also go directly to the Contact address, bypassing proxies (unless they insist on record-routing). I guess this is another variation. (I still prefer the messages-as-media, since it makes it easier to have text and audio chat at the same time.) > > Furthermore, there is a lot of value in viewing IM as a session set up with > SIP. Many of the reasons are outlined in the slides. To summarize: > > 1. forking actually works > 2. you can actually clean up state in end systems which are automata (like > an IM conference server, which you cannot build without this!) > 3. you can avoid sending 5meg MP3 "IMs" over proxies > 4. you can reuse alot of the sip tools we have constructed for sessions - > transfers, multiparty conferencing, etc. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From jdrosen@dynamicsoft.com Fri Mar 30 22:41:58 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA17904 for ; Fri, 30 Mar 2001 22:41:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA11939; Fri, 30 Mar 2001 22:45:19 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Mar 2001 22:41:55 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" Cc: "'Rohan Mahy'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] IM: A session or not Date: Fri, 30 Mar 2001 22:41:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 3554 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: > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, March 30, 2001 10:22 PM > To: Jonathan Rosenberg > Cc: 'Rohan Mahy'; 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] IM: A session or not > > > Jonathan Rosenberg wrote: > > > > > Because, we don't want to be sending IMs across the proxy > network. The above > > approach would allow MESSAGE to go someplace different than > INVITE, but it > > still goes over the proxy network. > > If we treat MESSAGE as being part of an INVITE session, but not as a > media stream, such MESSAGES would also go directly to the Contact > address, bypassing proxies (unless they insist on record-routing). Assuming they don't record route, yes. However, since we are using INVITE to set this up, and since we see record-routing today, and most proxies ignore the media when determining whether to record-route, I would expect there to be intermediate proxies. > guess this is another variation. (I still prefer the > messages-as-media, > since it makes it easier to have text and audio chat at the > same time.) Correct. In fact, having messages-as-media is a REQUIREMENT if you want to do any kind of conferencing applications, and you want to think about cases where there the server performing video mixing is different from the one doing IM mixing. We don't assume that audio and video go to the same address as signaling, and this characteristic has been a tremedously important component of many applications that can be built with SIP. In fact, it is one of the foundations of the application component architecture. Making that assumption for messaging (that messages should follow signaling) would be a big mistake, IMHO. Let me give an example. Lets say I want to build a service whereby a user calls an automated customer care system. The system is an IVR type of thing, and the user can provide input via dtmf or speech reco. Now, wouldn't it be cool to add messaging to this. The system could attempt to re-invite the user with a messaging stream. If the user accepts, the system can ask the user to type things at certain points in time, and then parse the response with some kind of natural language processing. Now, I don't want the natural language processing system be the same server than is running the application itself, just as I don't want the IVR to be the same as the server running the application itself. I'd like a *natural language component*, ala the application component architecture, which receives the messages from the user, and can look for certain things, and then feed back the results to the application server itself. Same idea as why I want the IVR separate, so it can feed back the results to the application server. While Rohans suggetion does allow the messages and signaling to go different places, they can only go different places registered to the same user, not to different users. Furthermore, the approach would completely fail for cases where the user is in more than one call at a time, and needs messaging for each call to go someplace different. This will be a common case for the types of systems I describe above. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From schulzrinne@cs.columbia.edu Sat Mar 31 20:07:50 2001 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 UAA21137 for ; Sat, 31 Mar 2001 20:07:50 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA02237; Sat, 31 Mar 2001 20:07:50 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id UAA04309; Sat, 31 Mar 2001 20:07:49 -0500 (EST) Message-ID: <3AC67F3C.31FABF9C@cs.columbia.edu> Date: Sat, 31 Mar 2001 20:07:08 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Henning G. Schulzrinne'" , "'Rohan Mahy'" , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] IM: A session or not References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 768 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: > Assuming they don't record route, yes. However, since we are using INVITE to > set this up, and since we see record-routing today, and most proxies ignore > the media when determining whether to record-route, I would expect there to > be intermediate proxies. I seem to remember that you said that proxies shouldn't record-route unless they have a really good reason to. The whole point of the SIP architecture is to allow direct communications between end systems as the normal case, with proxy-routing as the exception. Another question is whether systems could be smart enough to respect the Contact in a MESSAGE for subsequent messages with the same Call-ID. I'm trying to see what SIP-level things we can do, as an additional option for occasional messages. From jdrosen@dynamicsoft.com Sun Apr 1 23:07:26 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03849 for ; Sun, 1 Apr 2001 23:07:26 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA10328; Sun, 1 Apr 2001 23:10:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 1 Apr 2001 23:07:14 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: "'Henning G. Schulzrinne'" , "'Rohan Mahy'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] IM: A session or not Date: Sun, 1 Apr 2001 23:07:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2087 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: > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Saturday, March 31, 2001 8:07 PM > To: Jonathan Rosenberg > Cc: 'Henning G. Schulzrinne'; 'Rohan Mahy'; > 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] IM: A session or not > > > > Assuming they don't record route, yes. However, since we > are using INVITE to > > set this up, and since we see record-routing today, and > most proxies ignore > > the media when determining whether to record-route, I would > expect there to > > be intermediate proxies. > > I seem to remember that you said that proxies shouldn't record-route > unless they have a really good reason to. The whole point of the SIP > architecture is to allow direct communications between end systems as > the normal case, with proxy-routing as the exception. True. However, I still think its very helpful to allow media streams (video, audio, messaging) to all go to separate addresses. Rohan's suggestion to use registrations to route IM separately will require the proxy holding the registrations to record-route. So, if you want end to end communications, and you want IM's to go elsewhere, you really need to have the address for messaging signaled in SDP as other media are. As to what it looks like, I think we basically need one parameter, which is the URI. The URI itself can represent anything else we might need. m=message 5060 SIP sip:jdrosen@dynamicsoft.com > > Another question is whether systems could be smart enough to > respect the > Contact in a MESSAGE for subsequent messages with the same Call-ID. Well, then we get partly down the road towards invite semantics. It is in this space that lies confusion. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From mwatson@nortelnetworks.com Mon Apr 2 10:05:24 2001 Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01174 for ; Mon, 2 Apr 2001 10:05:19 -0400 (EDT) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Mon, 2 Apr 2001 15:04:46 +0100 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 15:04:04 +0100 Message-ID: From: "Mark Watson" To: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] IM: A session or not Date: Mon, 2 Apr 2001 15:04:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0BB7D.C5C9D9A0" Content-Length: 11577 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: 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_01C0BB7D.C5C9D9A0 Content-Type: text/plain; charset="iso-8859-1" All, To my mind there are two distinct services which are in common use today, both under the heading 'Instant Messaging'. First 'chat' systems are characterised by long-lived sessions, which 2 or more users participating in real-time interactive information exchange. The information happens to be discrete text strings, but other than this the similarity with an audio or video conference is pretty compelling. Second 'paging' systems are characterised by individual point-to-point real-time or near real-time text messages e.g. SMS. These services are sufficiently different to contenance different implementations. It is also easy to envisage applications where text messaging is just one of a number of media available for a session (e.g. a video broad/narrow cast with a choice of subtitles in different languages, videoconferencing with text instead of audio) I think there would be great value in having text chat treated as just another media type, so it can be offered along with audio, video, whiteboard etc. media in the SDP. This would also allow any future SIP extensions for management of conferences - floor control is an example which comes to mind - to apply to 'chat' session as well. I don't have a strong opinion on the protocol used for the messages themselves - I think something lighter than a SIP method could be considered as, for this part of the application, we are not really re-using any SIP capabilities. Regards, Mark Watson Nortel Networks > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 30 March 2001 22:23 > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] IM: A session or not > > > Folks, > > At the IETF meeting, we discussed the main open issue > surrounding the IM > draft: whether or not to view IM as a session, as a signaling > path message, > or both. I presented some slides that discussed this, which > you can obtain > at: > > http://www.cs.columbia.edu/~jdrosen/papers/simple_open_mar01.ppt > > We need to resolve this issue asap. > > I'd like to work from the following proposal: > > 1. We support the ability to establish IM as a session. This > is accomplished > through some SDP parameter registrations to signal whatever > is needed to set > it up, which we need to think about. > 2. the messaging session is actually done using SIP, using the current > MESSAGE method, as specified. The SDP would include things > like the URL to > use. Generally, these messages would then go directly between the > participants. > 3. A MESSAGE method can also be sent as a "page", over the > SIP proxies, > without having established a session. In this way, it works > identially to > OPTIONS. This supports SMS type of functionality, and makes > more sense on > one way devices. > 4. A MESSAGE method can be sent over the proxy network, as > part of an active > session, rather than direct. As far as the end systems are > concerned, it > still appears as a session level media stream; it just > happened to come in > through an intermediary. This is actually a critical piece for nat. > > Is there consensus on this approach? Questions? Concerns? Flames? > > Thanks, > Jonathan R. > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C0BB7D.C5C9D9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] IM: A session or not

All,

To my mind there are two distinct services which are = in common use today, both under the heading 'Instant Messaging'.

First 'chat' systems are characterised by long-lived = sessions, which 2 or more users participating in real-time interactive = information exchange. The information happens to be discrete text = strings, but other than this the similarity with an audio or video = conference is pretty compelling.

Second 'paging' systems are characterised by = individual point-to-point real-time or near real-time text messages = e.g. SMS.

These services are sufficiently different to = contenance different implementations.

It is also easy to envisage applications where text = messaging is just one of a number of media available for a session = (e.g. a video broad/narrow cast with a choice of subtitles in different = languages, videoconferencing with text instead of audio)

I think there would be great value in having text = chat treated as just another media type, so it can be offered along = with audio, video, whiteboard etc. media in the SDP. This would also = allow any future SIP extensions for management of conferences - floor = control is an example which comes to mind - to apply to 'chat' session = as well.

I don't have a strong opinion on the protocol used = for the messages themselves - I think something lighter than a SIP = method could be considered as, for this part of the application, we are = not really re-using any SIP capabilities.

Regards,

Mark Watson
Nortel Networks

 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 30 March 2001 22:23
> To: 'simple@mailman.dynamicsoft.com'
> Subject: [Simple] IM: A session or not
>
>
> Folks,
>
> At the IETF meeting, we discussed the main open = issue
> surrounding the IM
> draft: whether or not to view IM as a session, = as a signaling
> path message,
> or both. I presented some slides that discussed = this, which
> you can obtain
> at:
>
> http://www.cs.columbia.edu/~jdrosen/papers/simple_open= _mar01.ppt
>
> We need to resolve this issue asap.
>
> I'd like to work from the following = proposal:
>
> 1. We support the ability to establish IM as a = session. This
> is accomplished
> through some SDP parameter registrations to = signal whatever
> is needed to set
> it up, which we need to think about.
> 2. the messaging session is actually done using = SIP, using the current
> MESSAGE method, as specified. The SDP would = include things
> like the URL to
> use. Generally, these messages would then go = directly between the
> participants.
> 3. A MESSAGE method can also be sent as a = "page", over the
> SIP proxies,
> without having established a session. In this = way, it works
> identially to
> OPTIONS. This supports SMS type of = functionality, and makes
> more sense on
> one way devices.
> 4. A MESSAGE method can be sent over the proxy = network, as
> part of an active
> session, rather than direct. As far as the end = systems are
> concerned, it
> still appears as a session level media stream; = it just
> happened to come in
> through an intermediary. This is actually a = critical piece for nat.
>
> Is there consensus on this approach? Questions? = Concerns? Flames?
>
> Thanks,
> Jonathan R.
>
>
> ---
> Jonathan D. = Rosenberg          &nb= sp;            = 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.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> = _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=
>

------_=_NextPart_001_01C0BB7D.C5C9D9A0-- From huitema@exchange.microsoft.com Mon Apr 2 12:02:57 2001 Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01542 for ; Mon, 2 Apr 2001 12:02:57 -0400 (EDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 2 Apr 2001 09:03:13 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Apr 2001 08:03:28 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 2 Apr 2001 09:03:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4678.0 content-class: urn:content-classes:message Subject: RE: [Simple] IM: A session or not MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Apr 2001 09:03:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] IM: A session or not Thread-Index: AcC7IupVxdm4WAoNRAGWm8Yq/firEQAalyEg From: "Christian Huitema" To: "Jonathan Rosenberg" , "Henning Schulzrinne" Cc: "Henning G. Schulzrinne" , "Rohan Mahy" , X-OriginalArrivalTime: 02 Apr 2001 16:03:28.0687 (UTC) FILETIME=[74DE9BF0:01C0BB8E] Content-Length: 595 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA01542 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: There are indeed many benefits in having actual messaging sessions, but we should not loose the potential benefits of sending messages through the "signaling channel" when appropriate: firewall traversal, support of mobility, immediate page, etc. So, if we go forward with the plan of documenting an "m=message" media in SDP, we will need to specify at least three options: 1) Send messages to a specified TCP-IP (or UDP-IP) address, 2) Send messages to a SIP URL, 3) Send messages "on this channel", i.e. using the same route as other signaling messages in this session. -- Christian Huitema From rrroy@att.com Mon Apr 2 12:30:27 2001 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 MAA01649 for ; Mon, 2 Apr 2001 12:30:27 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f32GUK713980; Mon, 2 Apr 2001 12:30:20 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id MAA05359; Mon, 2 Apr 2001 12:29:11 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Apr 2001 12:30:20 -0400 Message-ID: From: "Roy, Radhika R, ALCOO" To: Christian Huitema Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Mon, 2 Apr 2001 12:30:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1293 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: 3) Send messages "on this channel", i.e. using the same route as other signaling messages in this session. [RRR] Whether it will contain the TCP-IP (or UDP-IP) address of the "Signaling Channel" or the "path" of the "Signaling channel?" Radhika R. Roy -----Original Message----- From: Christian Huitema [mailto:huitema@exchange.microsoft.com] Sent: Monday, April 02, 2001 12:03 PM To: Jonathan Rosenberg; Henning Schulzrinne Cc: Henning G. Schulzrinne; Rohan Mahy; simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not There are indeed many benefits in having actual messaging sessions, but we should not loose the potential benefits of sending messages through the "signaling channel" when appropriate: firewall traversal, support of mobility, immediate page, etc. So, if we go forward with the plan of documenting an "m=message" media in SDP, we will need to specify at least three options: 1) Send messages to a specified TCP-IP (or UDP-IP) address, 2) Send messages to a SIP URL, 3) Send messages "on this channel", i.e. using the same route as other signaling messages in this session. -- Christian Huitema _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From adam.roach@ericsson.com Mon Apr 2 12:35:48 2001 Received: from imr2.ericy.com ([12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01683 for ; Mon, 2 Apr 2001 12:35:47 -0400 (EDT) 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 f32GZ1807562; Mon, 2 Apr 2001 11:35:01 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f32GYUY12604; Mon, 2 Apr 2001 11:34:30 -0500 (CDT) Received: from eusadam (pc050194.exu.ericsson.se [138.85.50.194]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA02331; Mon, 2 Apr 2001 11:34:54 -0500 (CDT) Reply-To: To: "'Christian Huitema'" , "Jonathan Rosenberg" , "Henning Schulzrinne" Cc: "Henning G. Schulzrinne" , "Rohan Mahy" , Subject: RE: [Simple] IM: A session or not Date: Mon, 2 Apr 2001 11:34:52 -0500 Message-ID: <61D824C63B99D311975E00508B0CC9850E86E3@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 V5.00.2314.1300 Content-Length: 676 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: > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > >...if we go forward with the plan of > documenting an "m=message" media in SDP, we will need to specify at > least three options: > > 1) Send messages to a specified TCP-IP (or UDP-IP) address, > 2) Send messages to a SIP URL, > 3) Send messages "on this channel", i.e. using the same route as other > signaling messages in this session. I think (1) and (2) are basically the same situation, and are covered by Jonathan's proposal. Situation (3) -- an instant messaging session with a distinct beginning and end, but using the proxy network -- is a new case that needs to have syntax defined for it. /a From hgs@cs.columbia.edu Mon Apr 2 14:13:38 2001 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 OAA01965 for ; Mon, 2 Apr 2001 14:13:37 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA13881; Mon, 2 Apr 2001 14:13:34 -0400 (EDT) Message-ID: <3AC8C14E.B0038B40@cs.columbia.edu> Date: Mon, 02 Apr 2001 14:13:34 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com CC: "'Christian Huitema'" , Jonathan Rosenberg , Rohan Mahy , simple@mailman.dynamicsoft.com Subject: Re: [Simple] IM: A session or not References: <61D824C63B99D311975E00508B0CC9850E86E3@eamrcnt717.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 916 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: adam.roach@ericsson.com wrote: > > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > > > >...if we go forward with the plan of > > documenting an "m=message" media in SDP, we will need to specify at > > least three options: > > > > 1) Send messages to a specified TCP-IP (or UDP-IP) address, > > 2) Send messages to a SIP URL, > > 3) Send messages "on this channel", i.e. using the same route as other > > signaling messages in this session. > > I think (1) and (2) are basically the same situation, and are covered > by Jonathan's proposal. Situation (3) -- an instant messaging session > with a distinct beginning and end, but using the proxy network -- is > a new case that needs to have syntax defined for it. This is basically one or more MESSAGE within the call-id/call-leg context of an INVITE. Or am I missing something here? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From huitema@exchange.microsoft.com Mon Apr 2 15:08:55 2001 Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02145 for ; Mon, 2 Apr 2001 15:08:54 -0400 (EDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Mon, 2 Apr 2001 12:07:11 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Apr 2001 11:07:27 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 2 Apr 2001 12:07:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4678.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] IM: A session or not Date: Mon, 2 Apr 2001 12:07:25 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] IM: A session or not Thread-Index: AcC7o9VrpZuOXSFuT4+Ym54vDNHqygABBEdA From: "Christian Huitema" To: "Henning G. Schulzrinne" , Cc: "Christian Huitema" , "Jonathan Rosenberg" , "Rohan Mahy" , X-OriginalArrivalTime: 02 Apr 2001 19:07:27.0156 (UTC) FILETIME=[284F4F40:01C0BBA8] Content-Length: 1283 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA02145 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: > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, April 02, 2001 11:14 AM > To: adam.roach@ericsson.com > Cc: 'Christian Huitema'; Jonathan Rosenberg; Rohan Mahy; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] IM: A session or not > > adam.roach@ericsson.com wrote: > > > > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > > > > > >...if we go forward with the plan of > > > documenting an "m=message" media in SDP, we will need to specify at > > > least three options: > > > > > > 1) Send messages to a specified TCP-IP (or UDP-IP) address, > > > 2) Send messages to a SIP URL, > > > 3) Send messages "on this channel", i.e. using the same route as other > > > signaling messages in this session. > > > > I think (1) and (2) are basically the same situation, and are covered > > by Jonathan's proposal. Situation (3) -- an instant messaging session > > with a distinct beginning and end, but using the proxy network -- is > > a new case that needs to have syntax defined for it. > > This is basically one or more MESSAGE within the call-id/call-leg > context of an INVITE. Or am I missing something here? Yes. In fact, having this construct might be useful for several media, not just text... From jdrosen@dynamicsoft.com Mon Apr 2 22:33:21 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03290 for ; Mon, 2 Apr 2001 22:33:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA24466; Mon, 2 Apr 2001 22:36:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Apr 2001 22:33:16 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" , adam.roach@ericsson.com Cc: "'Christian Huitema'" , Jonathan Rosenberg , Rohan Mahy , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Mon, 2 Apr 2001 22:33:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2005 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: > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, April 02, 2001 2:14 PM > To: adam.roach@ericsson.com > Cc: 'Christian Huitema'; Jonathan Rosenberg; Rohan Mahy; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] IM: A session or not > > > adam.roach@ericsson.com wrote: > > > > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > > > > > >...if we go forward with the plan of > > > documenting an "m=message" media in SDP, we will need to > specify at > > > least three options: > > > > > > 1) Send messages to a specified TCP-IP (or UDP-IP) address, > > > 2) Send messages to a SIP URL, > > > 3) Send messages "on this channel", i.e. using the same > route as other > > > signaling messages in this session. > > > > I think (1) and (2) are basically the same situation, and > are covered > > by Jonathan's proposal. Situation (3) -- an instant > messaging session > > with a distinct beginning and end, but using the proxy network -- is > > a new case that needs to have syntax defined for it. > > This is basically one or more MESSAGE within the call-id/call-leg > context of an INVITE. Or am I missing something here? No, thats exactly it. The question is how (and if!) the SDP can convey that "you should send the MESSAGE in the sip signaling path, not directly". One could argue that a client can always send the MESSAGE through the proxy network; do we actually need a way for the called party, for example, to tell the caller that they have to use the proxy network? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > From hgs@cs.columbia.edu Mon Apr 2 22:35:44 2001 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 WAA03318 for ; Mon, 2 Apr 2001 22:35:44 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA16752; Mon, 2 Apr 2001 22:35:40 -0400 (EDT) Message-ID: <3AC936FC.797EF301@cs.columbia.edu> Date: Mon, 02 Apr 2001 22:35:40 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: adam.roach@ericsson.com, "'Christian Huitema'" , Rohan Mahy , simple@mailman.dynamicsoft.com Subject: Re: [Simple] IM: A session or not References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 887 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: Jonathan Rosenberg wrote: > > > > > This is basically one or more MESSAGE within the call-id/call-leg > > context of an INVITE. Or am I missing something here? > > No, thats exactly it. The question is how (and if!) the SDP can convey that > "you should send the MESSAGE in the sip signaling path, not directly". One > could argue that a client can always send the MESSAGE through the proxy > network; do we actually need a way for the called party, for example, to > tell the caller that they have to use the proxy network? It would seem to be sufficient to deduce that if there's no entry for m=message in the caller/callee SDP and either feels the urge to send a message, it can do this. Obviously, either side can also re-INVITE if it wants to add a streaming message media session, rather than a proxy-routed message. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From nsyracus@cnri.reston.va.us Tue Apr 3 07:53:37 2001 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 HAA04757 for ; Tue, 3 Apr 2001 07:53:36 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27362; Tue, 3 Apr 2001 07:53:26 -0400 (EDT) Message-Id: <200104031153.HAA27362@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 Date: Tue, 03 Apr 2001 07:53:26 -0400 Content-Length: 2859 Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg et al. Filename : draft-ietf-simple-presence-00.txt Pages : 39 Date : 02-Apr-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-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: <20010402124855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124855.I-D@ietf.org> --OtherAccess-- --NextPart-- From jdrosen@dynamicsoft.com Wed Apr 4 00:19:57 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07288 for ; Wed, 4 Apr 2001 00:19:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA07486 for ; Wed, 4 Apr 2001 00:23:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 00:19:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Subject: FW: [Simple] I-D ACTION:draft-ietf-simple-presence-00.txt Date: Wed, 4 Apr 2001 00:19:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0BCBE.82C835DA" Content-Length: 4230 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: 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_01C0BCBE.82C835DA Content-Type: text/plain; charset="iso-8859-1" Folks, I've resubmitted the presence spec, with no changes except the filename. THis is just to get it linked from the simple page at IETF. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, April 03, 2001 7:53 AM Cc: simple@mailman.dynamicsoft.com Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg et al. Filename : draft-ietf-simple-presence-00.txt Pages : 39 Date : 02-Apr-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-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_01C0BCBE.82C835DA Content-Type: message/rfc822 To: Subject: Date: Wed, 4 Apr 2001 00:19:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C0BCBE.82C835DA" ------_=_NextPart_002_01C0BCBE.82C835DA Content-Type: text/plain ------_=_NextPart_002_01C0BCBE.82C835DA Content-Type: application/octet-stream; name="ATT19148.txt" Content-Disposition: attachment; filename="ATT19148.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010402124855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-00.txt ------_=_NextPart_002_01C0BCBE.82C835DA Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-simple-presence-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C0BCBE.82C835DA-- ------_=_NextPart_000_01C0BCBE.82C835DA-- From jdrosen@dynamicsoft.com Wed Apr 4 01:38:27 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07510 for ; Wed, 4 Apr 2001 01:38:27 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA07853; Wed, 4 Apr 2001 01:41:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 01:38:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" Cc: adam.roach@ericsson.com, "'Christian Huitema'" , Rohan Mahy , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Wed, 4 Apr 2001 01:38:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1938 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: > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, April 02, 2001 10:36 PM > To: Jonathan Rosenberg > Cc: adam.roach@ericsson.com; 'Christian Huitema'; Rohan Mahy; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] IM: A session or not > > > Jonathan Rosenberg wrote: > > > > > > > > > This is basically one or more MESSAGE within the call-id/call-leg > > > context of an INVITE. Or am I missing something here? > > > > No, thats exactly it. The question is how (and if!) the SDP > can convey that > > "you should send the MESSAGE in the sip signaling path, not > directly". One > > could argue that a client can always send the MESSAGE > through the proxy > > network; do we actually need a way for the called party, > for example, to > > tell the caller that they have to use the proxy network? > > It would seem to be sufficient to deduce that if there's no entry for > m=message in the caller/callee SDP and either feels the urge to send a > message, it can do this. Obviously, either side can also > re-INVITE if it > wants to add a streaming message media session, rather than a > proxy-routed message. The case I am thinking about is where A invites B to a messaging session. A wishes to receive messages, and wants them to come over the SIP proxy chain. With your proposal, A would not indicate a message session at all in its SDP. I think its useful for A to be able to signal to B that it would like to start a messaging session, yet have the messages delivered over the proxy network. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com From schulzrinne@cs.columbia.edu Wed Apr 4 09:18:00 2001 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 JAA08705 for ; Wed, 4 Apr 2001 09:18:00 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA22332; Wed, 4 Apr 2001 09:18:02 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id JAA28609; Wed, 4 Apr 2001 09:18:01 -0400 (EDT) Message-ID: <3ACB1EE8.23AAA751@cs.columbia.edu> Date: Wed, 04 Apr 2001 09:17:28 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Henning G. Schulzrinne'" , adam.roach@ericsson.com, "'Christian Huitema'" , Rohan Mahy , simple@mailman.dynamicsoft.com Subject: Re: [Simple] IM: A session or not References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1295 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: > The case I am thinking about is where A invites B to a messaging session. A > wishes to receive messages, and wants them to come over the SIP proxy chain. > With your proposal, A would not indicate a message session at all in its > SDP. I think its useful for A to be able to signal to B that it would like > to start a messaging session, yet have the messages delivered over the proxy > network. If I understand you correctly, you want to be able to start a messaging-only session using proxy delivery (I'm not sure I like the term "proxy-based", given that this applies also to direct, normal SIP delivery, without a proxy server in the middle, using Contact-based delivery). I'm assuming that a regular session with other media would allow messages at any time, assuming the parties indicate their ability to receive messages using the "Allow" header. It would be nice, it seems, to avoid complicated negotiated mechanisms if the basic capability indication is good enough. After all, messages are meant to be spontaneous and the base assumption should be that most systems will be able to receive at least plain-text messages. (Given the success of SMS and the simplicity of adding MESSAGE, it would seem silly for a vendor not to do that.) Does SMS have an explicit negotiation mode? From mhammer@cisco.com Wed Apr 4 10:47:19 2001 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 KAA08951 for ; Wed, 4 Apr 2001 10:47:18 -0400 (EDT) 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 KAA15490; Wed, 4 Apr 2001 10:47:16 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn3-dhcp-161-44-93-152.cisco.com [161.44.93.152]) by cia.cisco.com (Mirapoint) with ESMTP id ABE12495; Wed, 4 Apr 2001 10:47:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20010404104348.02b0ae80@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Apr 2001 10:47:28 -0400 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Simple] IM: A session or not Cc: Jonathan Rosenberg , "'Henning G. Schulzrinne'" , adam.roach@ericsson.com, "'Christian Huitema'" , Rohan Mahy , simple@mailman.dynamicsoft.com In-Reply-To: <3ACB1EE8.23AAA751@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 1988 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: From what I have seen of SMS (at least in ANSI-41) it is a connectionless service. By definition, there is no setup phase of this communication, it is fire and forget, like email, therefore no negotiation is involved. It would seem that to have an SMS-like service here, the "MESSAGE" should be sent and routed like an INVITE, end of story, no 200 OK, no ACK. Anything more and you are defining a connection-oriented service. Mike At 09:17 AM 4/4/2001 -0400, Henning Schulzrinne wrote: > > The case I am thinking about is where A invites B to a messaging session. A > > wishes to receive messages, and wants them to come over the SIP proxy > chain. > > With your proposal, A would not indicate a message session at all in its > > SDP. I think its useful for A to be able to signal to B that it would like > > to start a messaging session, yet have the messages delivered over the > proxy > > network. > >If I understand you correctly, you want to be able to start a >messaging-only session using proxy delivery (I'm not sure I like the >term "proxy-based", given that this applies also to direct, normal SIP >delivery, without a proxy server in the middle, using Contact-based >delivery). > >I'm assuming that a regular session with other media would allow >messages at any time, assuming the parties indicate their ability to >receive messages using the "Allow" header. > >It would be nice, it seems, to avoid complicated negotiated mechanisms >if the basic capability indication is good enough. After all, messages >are meant to be spontaneous and the base assumption should be that most >systems will be able to receive at least plain-text messages. (Given the >success of SMS and the simplicity of adding MESSAGE, it would seem silly >for a vendor not to do that.) > >Does SMS have an explicit negotiation mode? >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple From rsparks@dynamicsoft.com Wed Apr 4 11:05:22 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09018 for ; Wed, 4 Apr 2001 11:05:22 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA11854 for ; Wed, 4 Apr 2001 11:08:50 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Apr 2001 11:05:24 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A6B0@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" Date: Wed, 4 Apr 2001 11:05:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0BD18.AC86CDFA" Content-Length: 31323 Subject: [Simple] Draft minutes - SIMPLE - IETF50 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: 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_01C0BD18.AC86CDFA Content-Type: text/plain; charset="iso-8859-1" A draft of the minutes of our meeting in Minneapolis is attached. Please provide any comments/corrections quickly - the final version needs to be in this Friday. My apologies for the short turnaround. Many thanks to Jonathan Lennox for taking such complete notes! RjS <> ------_=_NextPart_000_01C0BD18.AC86CDFA Content-Type: text/plain; name="minutes-simple-ietf50.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="minutes-simple-ietf50.txt" SIMPLE - SIP for Instant Messaging and Presence Leveraging = Extensions=0A= =0A= IETF 50, Mar 22 2001, Minneapolis Min=0A= =0A= Jon Peterson:=0A= =0A= Agenda:=0A= Agenda bashing=0A= Blue Sheets / Minute taker=0A= WG Status and Deliverables=0A= Open issues discussion=0A= =0A= =0A= Jonathan Lennox volunteered to take minutes=0A= =0A= WG Status:=0A= SIMPLE is now a WG=0A= We have deliverables=0A= They're coming up soon (Mar/May '01)=0A= =0A= JR: These weren't insane dates when the charter was submitted, but = the=0A= process took five months=0A= =0A= Two deliverables: IM, Presence=0A= Neither draft is a WG draft currently (WG wasn't a group until after=0A= the deadline)=0A= =0A= =0A= Robert Sparks: Open issues=0A= =0A= Summary of Discussions (details of each discussion are later in this = text)=0A= =0A= * Discussed issues concerning where pres: and im: URLs can appear=0A= in SIP messages. =0A= Result : More discussion needed on list.=0A= =0A= * Should Message sessions be bounded with INVITE/BYE?=0A= Result : Need seen for both "chat"-like sessions and sessionless=0A= "pages". Rough agreement that we should work towards a =0A= session of messages, since a character stream session is=0A= already defined by plain SIP. Discussion moved to list=0A= with highest priority.=0A= =0A= * Is REGISTER the right mechanism for publishing presence = documents?=0A= Result : Rough agreement that there were problems with using=0A= REGISTER. A mechanism with well defined semantics is=0A= needed. Discussion of the details of that mechanism=0A= was sent to the list.=0A= =0A= * How do we obtain Authorizations for subscriptions?=0A= Result : QAUTH has fatal flaws. An alternative involving = subscribing=0A= to subscription state, using a separate event package, = was=0A= proposed. Rough agreement to pursue the proposal. = Identified=0A= a distinction between publishing full authorization policy = vs=0A= a single decision. Problem identified with authorizing = Fetch=0A= requests. Discussion moved to list.=0A= =0A= * Should we Rate limit notify in the presence package?=0A= Result : Consensus - We will not attempt to solve this now. This=0A= doesn't prevent us adding the feature in the future.=0A= =0A= * Is the lowest common denominator for a Message body text/plain or=0A= message/cpim?=0A= Result : Consensus - An implementaion MUST be able to receive=0A= message/cpim, and MAY send only text/plain.=0A= =0A= * Can a Message response contain a body?=0A= Result : Consensus - No. This will break cpim.=0A= =0A= * How does migration of notify responsibility interact with = Record-Route?=0A= Result : More list discussion needed.=0A= =0A= * Other issues discussed briefly - more list discussion needed=0A= - Addressing congestion control: Using TCP may satisfy = requirement=0A= - Spec should clarify use of Accept=0A= - Can we reduce the state a cpim boundary/gateway must maintain?=0A= - Does it make sense to have a message with no body?=0A= =0A= =0A= Details of discussion=0A= =0A= =0A= What are the ramificaitons of mixing pres:, im: and sip: URLs?=0A= Request-URI, To: and From:, To: in REGISTER, Contact: in general=0A= (R/RR), Contact: in REGISTER=0A= =0A= JR: IMPP is also still sorting this out, hard to figure out. The=0A= right way to use these things is abstract names that sit above a SIP=0A= system. Most things that need SIP urls in a proxy network will = still=0A= have sip: URLs. In SUBSCRIBE, To and From may have pres: URLs.=0A= Request-URI will almost always be SIP, To: in REGISTER, Contact...=0A= =0A= Henning: As much as we can, keep other URLs out of it. Like tel: = and=0A= h323:, not clear who finds translater, where it's found, etc. Not=0A= clear what address format is behind pres: and im:, it'd be unhelpful=0A= if two entities which were different, had same thing behind URL. If = a=0A= provider offers services, make sure don't have different databases = for=0A= different ones, assign same ID for different identifiers.=0A= =0A= JR: Even in IMPP, most people not tracking these issues.=0A= pres:jdrosen@dynamicsoft.com, im:jdrosen@dynamicsoft.com. Even = easier=0A= to identify than tel URLs. If I'm a client tool, I click on a pres:=0A= URL, I convert to a SIP URL locally. I'm not sure you see a pres: = URL=0A= in a Request-URI.=0A= =0A= Christian: You're suggesting it's purely a UI issue, in system it's=0A= purely SIP. I'm not so sure, what about gateways. I believe we'll=0A= see many URL schemes. I think there will be innovation in this=0A= domain. Companies have this function proposed in five different=0A= ways. Question is: what does a SIP device do when it encounters a = URL=0A= it doesn't understand? That's the question we need to solve.=0A= =0A= JR: Spec already says what to do.=0A= =0A= Henning: My concern is for registration. There, we get into the=0A= special-case scenario. Registrar has to recognize that sip:foo@bar,=0A= pres:foo@bar are the same, but other URLs (like tel) are different;=0A= can't just do string comparisons, or strip schemes. Nightmare. We=0A= should get out of doing this -- it just won't work.=0A= =0A= Sean: I disagree, I see no reason to limit it in this case. If = someone=0A= registers with a pres:, that's what they're known as, I wouldn't do=0A= anything more complex. Either you say in the spec that pres->sip is=0A= just change the scheme, or it's more complicated to this.=0A= =0A= Henning: as soon as you say it's a semantic difference, it gets=0A= complex.=0A= =0A= Sean: it could be semanticaly different.=0A= =0A= Robert Sparks: I think we've framed the discussion so we can make = that=0A= distinction=0A= =0A= Vasilis: I want to make a point, pres: can be more general than sip:=0A= URI, it can collect presence from several sources (e.g. SS7 = networks)=0A= =0A= Robert: this is one of the first discussions I'd like to have on the=0A= list. What we do when we hit a gateway, in particular.=0A= =0A= =0A= Robert: (new slide)=0A= Should we have a message session bounded with INVITE/BYE?=0A= =0A= We could set up a session that uses RTP, we can set up a session = that=0A= uses SIP MESSAGE outside RTP, whatever we do we need to make it=0A= possible to cross a CPIM boundary. =0A= =0A= Hand over to JR.=0A= =0A= =0A= JR: messaging: session or not?=0A= Messaging has a dual nature. To some degree it's asynchronous. I=0A= send a message into the blue, it gets there, nothing more -- like=0A= e-mail. But for a lot of messages, there is a context, a thread -- = UI=0A= collects all the messages. Duality to the service. I think there's = a=0A= lot of benefit toward the session view of messaging.=0A= =0A= Example: here's an example with the current MESSAGE method. I send = a=0A= message to a user, it shows up at three PCs, there's no way to carry=0A= out separate conversations with the three users. But with INVITE, = we=0A= can just do this, forking works fine.=0A= =0A= This model would allow us to have messages not cross proxies. SIP=0A= proxies are signalling devices, they weren't designed to carry big=0A= messages. Vasilis has accused me of setting SIP back twenty years.=0A= We don't do this with RTP, why with SIP?=0A= =0A= With this model we can do a lot of things supported by SIP --=0A= multiparty converencing, call controls, add messaging to voice call;=0A= more consistent with SIP.=0A= =0A= Pushback from IESG -- large messages WILL be an issue. No sending=0A= large messages through proxies.=0A= =0A= =0A= Existing sessions don't have a notion of a session -- can we emulate=0A= the existing GUI? Yes. I send an IM, my UI sends INVITE, recipient=0A= tool sends OK, my tool sends ACK, my tool sends message, remote tool=0A= displays message.=0A= =0A= ??: Some UIs *are* session-oriented.=0A= =0A= JR: yes. You could do either.=0A= =0A= Drawbacks: overhead for a single message. I think common case is=0A= multiple. Latency to set up (not as big a deal as voice). Not=0A= consistent with current implementations. Gatewaying harder? I = think=0A= it's actually easier.=0A= =0A= JL: if you hide session from a user, when do you send BYE?=0A= =0A= JR: when user closes window, or timeout, or whatever.=0A= =0A= Lawrence: This works for text chat, but what about SMS? Works for=0A= that, but not clear for SMS.=0A= =0A= JR: I'll deal with this.=0A= =0A= How is messaging session done?=0A= =0A= Approach I: SIP stream. Treat SIP as a stream also, like RTP. SDP=0A= has an m line with a mime type message. Port is 5060 or whateverk=0A= "payload type" is SIP, send SIP messages directly beween end points.=0A= Issue: NAT/FW=0A= =0A= Approach II: New messaging format: CPIM over TCP? Wouldn't need=0A= MESSAGE method=0A= =0A= Approach III: RFC 2793 (text over RTP), I don't think it's the same=0A= user experience, I don't think it's the right answer.=0A= =0A= Robert: can't get through CPIM boundary.=0A= =0A= Hgs: for low-speed devices, where entry is slow, it's nice to be = able=0A= to see what people type as they type=0A= =0A= JR: we already have this, don't need to tell people not to do it.=0A= =0A= Adam Roach: not a solution to this problem, but it's a different = nice=0A= thing you can do.=0A= =0A= JR: What about session-less? We can still have this, no INVITE=0A= semantics, no session much more like what things like SMS are today.=0A= Like OPTIONS.=0A= =0A= ??: GSM MAP or IS-41 MAP to transfer messgaes doesn't work, = commercial=0A= success, but overburdened signalling network, needed to create=0A= separate message network.=0A= =0A= JR: Here, you can have your cake and eat it too. We can send short=0A= messages over signalling network, or not, clean transition between = to=0A= if you like.=0A= =0A= Vasilis: Yes, but if you start with bad practice, difficult for = carriers to=0A= move from one to the other.=0A= =0A= JR: yes. You need to have guidelines in the document for when you=0A= move from one to the other, but I think it's useful to have both.=0A= =0A= Christian: MESSAGE as it's defined right now is an INVITE without an=0A= SDP payload. One of the things you can do with an INVITE right now = is=0A= to put a Subject in the message. There is a risk of people=0A= overloading the infrastructure, but if we don't allow it people will=0A= do it anyway, in a dirtier way.=0A= =0A= JR: It's all about documenting the best practice.=0A= =0A= Christian: I've been advocating this for six months.=0A= =0A= JR: Yes, I've been a luddite.=0A= =0A= Christian: Two kinds of push-back. Using signalling infrastructure=0A= helps with firewall traversal; and it doesn't actually overload the=0A= infrastructure since you can use redirect and contact addresses.=0A= =0A= JR: Yes, see my next slides.=0A= =0A= Pete: I've got one model that doesn't fit into either of these ways = of=0A= approaching it. E.g. getting pages of stock prices. If you do=0A= sessions, it's not clear when teardown occurs. If you do it=0A= sessionless, you get into overload. It's not clear this addresses=0A= this model.=0A= =0A= Christian: other point -- there's way more than one messaging model.=0A= With INVITE model, you get an explosion of various ways of doing=0A= things. Application-dependent -- can be good, but hurts=0A= interoperability.=0A= =0A= JR: trade-off between flexibility and interoperability. SIP walks=0A= this line very finely.=0A= =0A= Christian: possible to say this is a message, part of a session.=0A= =0A= Pete: I think Christian's stated my worry.=0A= =0A= JR: another option is to send content through URLs, if you don't = know=0A= whether the client can make use of the content.=0A= =0A= Vasilis: In my opinion instant messaging is a separate type of = protocol, I=0A= think what you're describing is a PUSH/notification service, which = is=0A= different. I would like to make the distinction between IM and = push.=0A= =0A= Pete: if you give people a hammer, they'll whack themselves in the=0A= head with it. If you create this, people will use this for things = we=0A= didn't expect it.=0A= =0A= JR: everything's a push protocol if you look at it at a high enough=0A= level. I don't see the difference between sending someone a = message,=0A= and inviting them to a call.=0A= =0A= Vasilis: yes, but you have to negotiate screen sizes.=0A= =0A= JR: comparisons. SIP stream has greatest flexibility; you don't = have=0A= to have two different ways to represent same data; makes it easy to = do=0A= all the things we want. Second choice is new stream protocol, not=0A= terribly appealing.=0A= =0A= Henning: since you're sending a complete message, does allow=0A= forwarding/aggregation. Not sure this is good or bad. Confusing if=0A= we copy from one or the other, message in message stream is = different=0A= from signalling stream. =0A= =0A= JR: can just offer SIP port on recieve side, bin to 5060, don't need=0A= to be able to tell the difference.=0A= =0A= I don't think RTP approach is really viable.=0A= =0A= Advantage of using SIP network: deals with NAT/FW.=0A= Message stream: NAT on one side, solves problem, just let TCP=0A= connection flow.=0A= =0A= Use of SIP MESSAGE method as stream can solve other cases; send to=0A= bottom Route set, etc. Another possibility is route set in SDP.=0A= [General hum: no, no, yuck.]=0A= =0A= I think this is the biggest issue, everything else depends on this.=0A= =0A= Vasilis: question: You're saying initiate the session, and then use=0A= SIP as the streaming. Does it go through the proxy again?=0A= =0A= JR: no, except for NAT/FW. =0A= =0A= Vasilis: why not just use TCP or HTTP.=0A= =0A= JR: I am suggesting TCP. I don't think HTTP is a good idea, this is = a=0A= more peer-like protocol.=0A= =0A= Vasilis: there are already mobile clients with HTTP clients/servers.=0A= =0A= Jon Peterson: one possibility you raised is to invent something from=0A= scratch.=0A= =0A= JR: advantage to using SIP -- we already have relays, they're called=0A= proxies.=0A= =0A= Sean: I'm happy to have stream approach, but we should also have=0A= one-shot method as well, for small sessions/clients.=0A= =0A= Jon P.: does that suggest that MUST support message, MAY support=0A= stream?=0A= =0A= Sean: no.=0A= =0A= Vasilis: I don't like the use of the word 'streaming'; but also be=0A= careful because IESG already said we don't want large messages = through=0A= proxies.=0A= =0A= Robert: take this to the ML. I think this is appropriately flamed = --=0A= framed! [Laughter]=0A= =0A= What about CPIM boundary?=0A= =0A= JR: Is there a CPIM instant messaging map? In doing the presence=0A= one, the difficulties is to know when to get rid of it, when to have=0A= it. If you just wrap this thing in INVITE. As long as you have=0A= frame-bounded thing, its easy.=0A= =0A= We need to resolve this *fast*. Everything else depends on this.=0A= =0A= =0A= Robert Sparks: Question in both drafts: is REGISTER the right = PUBLISH=0A= mechanism? Can derive a presence document from registration...is=0A= REGISTER the right way to get it into the system from an endpoint?=0A= =0A= JR: let me provide clarification. We've been saying all along that = my=0A= presence is composed of information from lots of different sources,=0A= composed in backends. REGISTER is one source, not the only one. = Plug=0A= in other sources, not necessarily SIP. Question: if I want to = upload=0A= a document that describes my presence, is REGISTER the right way to = do=0A= this? Similar to uploading CPL. I've become sketchy on using=0A= REGISTER for this. Problem: there are two things that can fail=0A= independently -- upload a CPL, can fail either because the contacts=0A= have a problem, or because the CPL does. I think there should be a=0A= separate mechanism -- similar to how BYE/Also was split into = REFER/BYE=0A= so they can fail independently. =0A= =0A= Henning: the problem is it's another special-purpose method -- it = has=0A= REGISTER semantics, addressed to registrar rather than delivered to=0A= end system.=0A= =0A= Sean: SERVICE mechanism?=0A= =0A= JR: No, no, not a good idea. YOu have to have an explicit model for=0A= what this means. Mechanism for sending subscriber data to database=0A= that proxy can access. Can't just be a general "stuff" mechanism,=0A= need semantics.=0A= =0A= Robert Sparks: have to separate providing routing information with=0A= REGISTER with other mechanisms, need to distinguish failure=0A= mechanisms.=0A= =0A= Vasilis: when you power on, you do two methods instead of one.=0A= =0A= Henning: you could define REGISTER without contacts.=0A= =0A= JR: then it's not REGISTER anymore. We have guidelines.=0A= =0A= =0A= Robert: new issue: Authorization. (This will probably take all = day.)=0A= How do we get authorization from an entity, not in machine-time. = Hand=0A= over to Jonathan.=0A= =0A= JR: We know for presence we MUST be able to authorize subscriber by=0A= finding out from presentity whether it's okay. You can always have=0A= ACLs for specific people, but if we don't have it you need to be = able=0A= to ask the user. First version of presence draft had QAUTH -- it=0A= always made me queasy. Review how it works. When I turn on, I send = a=0A= registration with a parameter that says "this supports QAUTH". When = a=0A= subscription comes in, it sends 202 and sends QAUTH and asks, "is = this=0A= okay, or not"? Problem is it's an overload: uses registrations to=0A= imply ability to make authorization decisions - dangerous to=0A= overload. E.g. you have a generic registrations.=0A= =0A= Also, want to support multiple users that can set policy. Because = we=0A= use QAUTH, QAUTH can fork. Problem is that for non-INVITE, only one=0A= 200 response is delivered. Badly broken! Need to collect all=0A= responses.=0A= =0A= Another problem -- transaction in process while waiting for user.=0A= What if user is away? Transaction will time out.=0A= =0A= New proposal: my subscription state is itself a subscribable entity.=0A= Watcherinfo -- I can subscribe to it. A presentity like any other.=0A= Watcherinfo maintains state for users with active or pending=0A= subscriptions.=0A= =0A= Dave Oran: what about infinite recursion?=0A= =0A= JR: policy for who's allowed to subscribe to watcherinfo is static = --=0A= only presentity themselves or administrator.=0A= =0A= Robert Sparks: this could be a separate event package.=0A= =0A= JR: when the subscriber of watcherinfo sees subscription state has=0A= changed, they can push a new policy document to the server. = Notified=0A= PUSH.=0A= =0A= flow: SUBUBSCRIBE -> 202, generates NOTIFY watcherinfo, upload = policy.=0A= =0A= Advantages: who can upload policy has nothing to do with=0A= registrations. Determined by who can send upload messages.=0A= =0A= I can receive notifications about subscriptions without sending = poicy.=0A= =0A= Multiple entities can authorize.=0A= =0A= Dave Oran: this doesn't work for any arbitrary policy merge. If=0A= multiple users upload policies, can't me merged in consistent = fashion=0A= (e.g. classic ACLs). Does anyone find out there was an error, and = how=0A= are errors of upload handled? Is it just first one wins?=0A= =0A= JR: it's flexible.=0A= =0A= Dave: that's the problem.=0A= =0A= JR: only one user can upload policy -- presentity. Just replaces.=0A= =0A= Henning: not fundamentally different from forking problem with = QAUTH.=0A= I subscribe to watcherinfo from two different places (have to, or = bad=0A= things can happen). I get two notifications for change of=0A= watcherinfo. This means that one can say yes, and one say no.=0A= There are half-a-dozen policies you can do.=0A= =0A= Dave: Is what you send a decision, or a policy map? Get = notification=0A= 'Bob wants to subscribe'. I can respond with 'Bob's allowed, Sue's=0A= allowed, Joe's allowed.' QAUTH doesn't have merge problem.=0A= =0A= JR: problem exists anyway. Have to reconcile with offline policy.=0A= =0A= Henning: You have to be very careful what policy document is. = Several=0A= notifications happen in sequence; if you believe in complete state,=0A= what happens.=0A= =0A= JR: I don't think complete state is a good idea.=0A= =0A= Henning: do you want to be notified for renewals?=0A= =0A= JR: no. No change to watcherinfo.=0A= =0A= (Continuing with slide) multiple entites can upload policy -- server=0A= can reconcile (but we need to figure out how). Unifies triggered = and=0A= untriggered policy -- cleanness if we have one way to do this rather=0A= than two.=0A= =0A= Vasilis: [question I didn't entirely understand...] What's you=0A= definition of policy?=0A= =0A= JR: it's a list, "allow bob, don't allow joe". Or pieces.=0A= =0A= Vasilis: where is reconciliation?=0A= =0A= JR: in the server.=0A= =0A= Vasilis: in the device, or in the presence server?=0A= =0A= JR: doesn't matter. It's a logical role.=0A= =0A= Vasilis: can you have multiple PAs?=0A= =0A= JR: no.=0A= =0A= Dave: in the QAUTH scheme there's transactional state, here there=0A= isn't. But if you want to maintain causal ordering, the server has = to=0A= maintain the equivalent of transaction state. Joe tries to = subscribe,=0A= Sue tries to subscribe, notifications cross. Decision as to what to=0A= push back is causally depentant on what other transactions = completed.=0A= First one says "allow bob, not sue". Second one says "allow bob,=0A= disallow dave".=0A= =0A= JR: I don't see why it matters. As long as I can go to a webpage = and=0A= do it, it doesn't make any difference.=0A= =0A= Dave: I'll take it off line. I'm just pointing out there are=0A= complicated merge issues that aren't addressed here.=0A= =0A= JR: I'd like to know what they are.=0A= =0A= Henning: we haven't specified policy mechanisms, but it's clear = there=0A= are some mechanisms that don't fit here without careful thought. It=0A= has to be composable at a syntactic level with reasonable action.=0A= Also, policies have to have time associated -- "this person can't=0A= subscribe right now, but can a minute from now" up to "this person = can=0A= never subscribe." E.g. work vs. home subscriptions.=0A= =0A= JR: we can separate this -- keep it simple at first, then update=0A= independently of subscription stuff.=0A= =0A= Henning: Also, anything we don't say about remains in pending state=0A= =0A= Eric Hauper: I don't think this will work, I don't think any = automated=0A= query is at all reasonable. I think that subscription is a special=0A= message sent to the user -- will you allow me to subscribe to you?=0A= =0A= JR: you're mixing implementation and service. What is it you want=0A= from a service perspective?=0A= =0A= Eric: I think the server shouldn't get involved in this at all, = other=0A= than queueing up messages. The server shouldn't get involve in = people=0A= trying to subscribe to a presence that doesn't exist in the ACL.=0A= =0A= JR: this model would allow that approach.=0A= =0A= Eric: I don't think it should be triggered on a subscription at all.=0A= =0A= JR: that's how it works now with existing systems. I know at least=0A= Yahoo works this way.=0A= =0A= Eric: I don't think the server should have a concept of this.=0A= =0A= JR: send something to the list that explains this problem. I'm=0A= hesitant to understand the problem.=0A= =0A= Theo Kalvinis(sp?): I agree with this proposal. I also note the=0A= presence server is hiding the subscription. Always give back answer=0A= "Noted".=0A= =0A= JR: yes, -01 does this: Always generates 202, fake notify, you can't=0A= tell this is happening.=0A= =0A= Theo: what happens on fetch?=0A= =0A= JR: if I have an ACL that allows you, it works...have to think about=0A= other case.=0A= =0A= Robert Sparks: there's a problem there, need to take it to the list.=0A= =0A= Point in general: when I made a call for open issues, I wish that = had=0A= been raised then. Raise open issues to the list when they occur to=0A= you.=0A= =0A= Vasilis: big issue, how do you handle pending subscriptions, CPIM=0A= doesn't say anything about this. I think we can resolve this in = IMPP,=0A= not here.=0A= =0A= JR: problem isn't what subscribers say, it's how it relates to=0A= authorization. If you never know someone try to subscribe.=0A= =0A= Theo(?): one more potential issue, if entity A and entity B have=0A= distinct domains/servers. If I'm B and I want to subscribe to A,=0A= whose presence server do I go to?=0A= =0A= JR: A's.=0A= =0A= Theo: what if two people want to be bob@domain-A.com?=0A= =0A= JR: don't do that.=0A= =0A= JL: I think policy info should be subscribable.=0A= =0A= JR: too complicated.=0A= =0A= (Continuing with slide)=0A= =0A= What if someone subscribes when I'm offline?=0A= =0A= I log in, fetch watcherinfo, approve pending subscription sif we = want.=0A= =0A= How do we do it?=0A= Need:=0A= * event package for watcherinfo (Patrick says okay to do in SIMPLE,=0A= needed for presence)=0A= * watcher info data format (in NOTIFY of watcherinfo) (had one in=0A= original June 2000 drafts)=0A= * policy document - document is a good idea - can share it, store = it,=0A= generate it by servlets, universal intermediate usage like CPL=0A= * How do we upload it?=0A= =0A= Proposal: define something new, update JL's register upload for new=0A= method (setdata?). Not done in SIMPLE.=0A= =0A= I think this is the second-biggest issue. If you have better idea,=0A= mention it, I'm not wedded to this, but we need something, and I = think=0A= it's better than QAUTH.=0A= =0A= =0A= Robert Sparks:=0A= Should we rate-limit NOTIFY? Sip-events punted, sent it off to = event=0A= packages. We have an event package, what do we want to do?=0A= =0A= JR: I don't think so, let's keep it simple, it's not like this = happens=0A= frequently.=0A= =0A= Robert: for presence for people, some people are trying to do this.=0A= GEOLOC.=0A= =0A= Henning: it's probably not that effective. What you worry about is=0A= total inbound sender rate, you can only limit one. Hard to do = client=0A= control on server side. Server side is probably more substantial=0A= load, e.g. sending info to thousands of subscribers.=0A= =0A= Robert: agree that for first pass, we may not need to solve it. But=0A= if we don't solve it, are we closing the door to solving it later?=0A= =0A= Henning: I don't think so, it's just a parameter. More general=0A= problem: subscriptions are unqualified -- "I want to hear from you" = or=0A= "I don't want to hear from you". Can't do something more=0A= finer-grained. I think rate limitations are just a part of this,=0A= which we want to do later.=0A= =0A= Robert Sparks: so I propose that unless someone says something, = let's=0A= just leave it undefined for now.=0A= =0A= JR: current subscription document says that subscription body can=0A= contain TBD subscription filter.=0A= =0A= =0A= Robert Sparks: next issue:=0A= is lowest common denominator message/cpim or text/plain?=0A= For e-e across cpim boundary need to do message/cpim.=0A= Some agents may not care.=0A= =0A= JR: careful. For sending, can say don't care. For recieving, what = if=0A= APEX user wants to send message/cpim? I think MUST receive m/cpim,=0A= MAY send it.=0A= =0A= Ben Campbell: do we want to say that all our devices must be CPIM=0A= compliant? Is it okay to have a simple end system that can't cross=0A= CPIM?=0A= =0A= Henning: you can rule it out all you want, it won't matter. It's a=0A= complicated spec, people will do subsets.=0A= =0A= JR: that's always the case. I think the answer from the ADs is that=0A= the spec has to be CPIM-compliant. I can't control implementations.=0A= =0A= Henning: if it's an authenticated message, the gateway could convert=0A= it, losing authentication. In general, we can't verify that end=0A= system can verify authentication anyway. Need PKI, need common root=0A= certificate.=0A= =0A= JR: I don't think that's an excuse not to allow for interoperable=0A= authentication end-to-end.=0A= =0A= Henning: could specify in caller preferences.=0A= =0A= JR: gateway isn't necessarily your registrar.=0A= =0A= JL: could say that just require multipart/alternative, gateways=0A= provide both text/plain and message/cpim.=0A= =0A= Vasilis: How do we make this decision?=0A= =0A= Robert: on the list.=0A= =0A= Ben: don't take this as a criticism of interoperability.=0A= =0A= Robert: I think we have consensus for MUST receive message/cpim, MAY=0A= send text/plain.=0A= =0A= =0A= (skip some slides, then:) =0A= Question: what does a body in a 200 OK to a MESSAGE mean? Is it a=0A= reply?=0A= =0A= JR: it's broken to do this, can't maintain ordering.=0A= =0A= Robert: so say MUST NOT include body in response.=0A= =0A= Henning: raises issue -- if you do streaming of SIP MESSAGES, do you=0A= still do 200?=0A= =0A= JR: yes.=0A= =0A= Robert: (new issue)=0A= How do you synthesize presence document from reigstered data?=0A= =0A= JR: this is dependent on CPIM presence format.=0A= =0A= Robert: (new issue)=0A= How do you interact route/record-route and migration of notify=0A= responsibility?=0A= =0A= JR: Migration only on new subscriptions. Special-casing=0A= route/record-route is very bad.=0A= =0A= Christian: It's not clear that R/RR makes sense for non-INVITE=0A= messages anyway. Why do you want to record-route subscription?=0A= =0A= JR: various services, e.g. firewall traversal=0A= =0A= Christian: I want to disallow r-r in subscribe.=0A= =0A= Robert: this will require more list chewing.=0A= =0A= (new issue)=0A= Can we reduce state that gateway must maintain? cpim doesn't = reflect=0A= call-leg semantic.=0A= Point out: no such thing as cpim-on-the-wire, maybe can translate=0A= state into state in other people.=0A= =0A= JL: can we do the opposite, provide state for other protocols?=0A= =0A= Robert: it'd be nice.=0A= =0A= (new issue)=0A= Does it make sense to have MESSAGE with no body?=0A= [general muttering]=0A= =0A= (new issue)=0A= Should we say that accept means mime type inside message/cpim=0A= =0A= JR: yes.=0A= =0A= RS:=0A= Other issues:=0A= Congestion control, map to CPIM=0A= =0A= JR: If we do streaming over TCP, problem goes away.=0A= =0A= Christian: no it doesn't. If I'm in conference mode, maybe many TCP=0A= sessions.=0A= =0A= JonP: I think it's sufficient.=0A= =0A= RS: we made it through slides, one minute over, take remaining = issues=0A= to list!=0A= =0A= =0A= =0A= =0A= ------_=_NextPart_000_01C0BD18.AC86CDFA-- From rob.redmon@voyanttech.com Wed Apr 4 11:10:32 2001 Received: from voyanttech.com ([63.89.131.5]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09072 for ; Wed, 4 Apr 2001 11:10:32 -0400 (EDT) Received: from [192.168.59.80] (HELO RobRpc) by voyanttech.com (CommuniGate Pro SMTP 3.4b3) with SMTP id 570032 for simple@mailman.dynamicsoft.com; Wed, 04 Apr 2001 09:09:58 -0600 Reply-To: From: "Rob Redmon" To: Date: Wed, 4 Apr 2001 09:10:11 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C0BCE7.0D3E7C40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 3976 Subject: [Simple] 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: This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C0BCE7.0D3E7C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit subscribe end ________________________ Rob Redmon rob.redmon@voyanttech.com ------=_NextPart_000_0028_01C0BCE7.0D3E7C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

subscribe

end

 

________________________

Rob Redmon

rob.redmon@voyanttech.com<= /span>

 

------=_NextPart_000_0028_01C0BCE7.0D3E7C40-- From rob.redmon@voyanttech.com Wed Apr 4 11:12:00 2001 Received: from voyanttech.com ([63.89.131.5]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09095 for ; Wed, 4 Apr 2001 11:11:59 -0400 (EDT) Received: from [192.168.59.80] (HELO RobRpc) by voyanttech.com (CommuniGate Pro SMTP 3.4b3) with SMTP id 570038 for simple@mailman.dynamicsoft.com; Wed, 04 Apr 2001 09:11:21 -0600 Reply-To: From: "Rob Redmon" To: Date: Wed, 4 Apr 2001 09:11:33 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C0BCE7.3E87D350" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 3976 Subject: [Simple] 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: This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C0BCE7.3E87D350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit subscribe end ________________________ Rob Redmon rob.redmon@voyanttech.com ------=_NextPart_000_002C_01C0BCE7.3E87D350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

subscribe

end

 

________________________

Rob Redmon

rob.redmon@voyanttech.com<= /span>

 

------=_NextPart_000_002C_01C0BCE7.3E87D350-- From R.deGroot@hetnet.nl Thu Apr 5 06:40:12 2001 Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12082 for ; Thu, 5 Apr 2001 06:39:58 -0400 (EDT) Message-Id: <200104051039.GAA12082@mailman.dynamicsoft.com> Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with SMTP id pl for ; Thu, 5 Apr 2001 08:01:20 -0100 From: "Rita de Groot" To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:58:51 +0200 Content-Transfer-Encoding: 8bit Content-Length: 275 Subject: [Simple] huidziekte 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: Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From morehits@webmktplace.com Thu Apr 5 20:14:37 2001 Received: from mail.webmktplace.com (webmktplace.com [207.0.63.9]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14269 for ; Thu, 5 Apr 2001 20:14:37 -0400 (EDT) From: morehits@webmktplace.com Received: from web-script(nobody).webmktplace.com (207.0.63.9) by mail.webmktplace.com (8.9.3/8.9.3) with SMTP id f360E1x07911 for ; Thu, 5 Apr 2001 20:14:01 -0400 To: simple@mailman.dynamicsoft.com Date: Thu, 5 Apr 2001 17:07:12 Message-Id: <563.545419.440237@unknown> Reply-To: morehits@webmktplace.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 1260 Subject: [Simple] ADV:NEED MORE WEBSITE TRAFFIC? 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: **************************************************** To be removed from further mailings please respond with Remove in the subject line **************************************************** Dear Friend, Discover a new revolutionary way of promoting your website and generating insane amounts of traffic in as little as 48 hours. This brand new program takes one of the worlds oldest methods of promoting a business and applies it to the Internet. Now you can have more traffic, sell more products and generate more income in less time than it takes to even get your presence online. This new program is one of the strongest and most effective ways to generate targeted traffic to your site. If your one of those websites that has all the tools necessary to make money, but just doesn't have the traffic, we can help. If you have an interest in learning more about generate a large amount of traffic to your website in a short period of time please respond to this email with: YOUR NAME, PHONE# AND BEST TIME TO CALL TO: mailto:morehits@webmktplace.com A representative will return your call within 12 hours P.S. BE SURE TO ASK ABOUT OUR FREE REVOLUTIONARY PAY-PER-CLICK AFFILIATE PROGRAM. GS,INC 7657 Winnetka Ave Canoga Park Ca 91306 From rsparks@dynamicsoft.com Mon Apr 9 16:22:16 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02071 for ; Mon, 9 Apr 2001 16:22:15 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA11495 for ; Mon, 9 Apr 2001 16:25:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Apr 2001 16:22:14 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A6D4@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 9 Apr 2001 16:22:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0C132.C376C9A1" Content-Length: 206758 Subject: [Simple] Final minutes - SIMPLE - IETF50 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: 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_01C0C132.C376C9A1 Content-Type: text/plain; charset="iso-8859-1" Attached are the minutes and slides from the IETF50 meeting of the SIMPLE WG. RjS ------_=_NextPart_000_01C0C132.C376C9A1 Content-Type: text/plain; name="minutes-simple-ietf50.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="minutes-simple-ietf50.txt" SIMPLE - SIP for Instant Messaging and Presence Leveraging = Extensions=0A= =0A= IETF 50, Mar 22 2001, Minneapolis Min=0A= =0A= Jon Peterson:=0A= =0A= Agenda:=0A= Agenda bashing=0A= Blue Sheets / Minute taker=0A= WG Status and Deliverables=0A= Open issues discussion=0A= =0A= =0A= Jonathan Lennox volunteered to take minutes=0A= =0A= WG Status:=0A= SIMPLE is now a WG=0A= We have deliverables=0A= They're coming up soon (Mar/May '01)=0A= =0A= JR: These weren't insane dates when the charter was submitted, but = the=0A= process took five months=0A= =0A= Two deliverables: IM, Presence=0A= Neither draft is a WG draft currently (WG wasn't a group until after=0A= the deadline)=0A= =0A= =0A= Robert Sparks: Open issues=0A= =0A= Summary of Discussions (details of each discussion are later in this = text)=0A= =0A= * Discussed issues concerning where pres: and im: URLs can appear=0A= in SIP messages. =0A= Result : More discussion needed on list.=0A= =0A= * Should Message sessions be bounded with INVITE/BYE?=0A= Result : Need seen for both "chat"-like sessions and sessionless=0A= "pages". Rough agreement that we should work towards a =0A= session of messages, since a character stream session is=0A= already defined by plain SIP. Discussion moved to list=0A= with highest priority.=0A= =0A= * Is REGISTER the right mechanism for publishing presence = documents?=0A= Result : Rough agreement that there were problems with using=0A= REGISTER. A mechanism with well defined semantics is=0A= needed. Discussion of the details of that mechanism=0A= was sent to the list.=0A= =0A= * How do we obtain Authorizations for subscriptions?=0A= Result : QAUTH has fatal flaws. An alternative involving = subscribing=0A= to subscription state, using a separate event package, = was=0A= proposed. Rough agreement to pursue the proposal. = Identified=0A= a distinction between publishing full authorization policy = vs=0A= a single decision. Problem identified with authorizing = Fetch=0A= requests. Discussion moved to list.=0A= =0A= * Should we Rate limit notify in the presence package?=0A= Result : Consensus - We will not attempt to solve this now. This=0A= doesn't prevent us adding the feature in the future.=0A= =0A= * Is the lowest common denominator for a Message body text/plain or=0A= message/cpim?=0A= Result : Consensus - An implementaion MUST be able to receive=0A= message/cpim, and MAY send only text/plain.=0A= =0A= * Can a Message response contain a body?=0A= Result : Consensus - No. This will break cpim.=0A= =0A= * How does migration of notify responsibility interact with = Record-Route?=0A= Result : More list discussion needed.=0A= =0A= * Other issues discussed briefly - more list discussion needed=0A= - Addressing congestion control: Using TCP may satisfy = requirement=0A= - Spec should clarify use of Accept=0A= - Can we reduce the state a cpim boundary/gateway must maintain?=0A= - Does it make sense to have a message with no body?=0A= =0A= =0A= Details of discussion=0A= =0A= =0A= What are the ramificaitons of mixing pres:, im: and sip: URLs?=0A= Request-URI, To: and From:, To: in REGISTER, Contact: in general=0A= (R/RR), Contact: in REGISTER=0A= =0A= JR: IMPP is also still sorting this out, hard to figure out. The=0A= right way to use these things is abstract names that sit above a SIP=0A= system. Most things that need SIP urls in a proxy network will = still=0A= have sip: URLs. In SUBSCRIBE, To and From may have pres: URLs.=0A= Request-URI will almost always be SIP, To: in REGISTER, Contact...=0A= =0A= Henning: As much as we can, keep other URLs out of it. Like tel: = and=0A= h323:, not clear who finds translater, where it's found, etc. Not=0A= clear what address format is behind pres: and im:, it'd be unhelpful=0A= if two entities which were different, had same thing behind URL. If = a=0A= provider offers services, make sure don't have different databases = for=0A= different ones, assign same ID for different identifiers.=0A= =0A= JR: Even in IMPP, most people not tracking these issues.=0A= pres:jdrosen@dynamicsoft.com, im:jdrosen@dynamicsoft.com. Even = easier=0A= to identify than tel URLs. If I'm a client tool, I click on a pres:=0A= URL, I convert to a SIP URL locally. I'm not sure you see a pres: = URL=0A= in a Request-URI.=0A= =0A= Christian: You're suggesting it's purely a UI issue, in system it's=0A= purely SIP. I'm not so sure, what about gateways. I believe we'll=0A= see many URL schemes. I think there will be innovation in this=0A= domain. Companies have this function proposed in five different=0A= ways. Question is: what does a SIP device do when it encounters a = URL=0A= it doesn't understand? That's the question we need to solve.=0A= =0A= JR: Spec already says what to do.=0A= =0A= Henning: My concern is for registration. There, we get into the=0A= special-case scenario. Registrar has to recognize that sip:foo@bar,=0A= pres:foo@bar are the same, but other URLs (like tel) are different;=0A= can't just do string comparisons, or strip schemes. Nightmare. We=0A= should get out of doing this -- it just won't work.=0A= =0A= Sean: I disagree, I see no reason to limit it in this case. If = someone=0A= registers with a pres:, that's what they're known as, I wouldn't do=0A= anything more complex. Either you say in the spec that pres->sip is=0A= just change the scheme, or it's more complicated to this.=0A= =0A= Henning: as soon as you say it's a semantic difference, it gets=0A= complex.=0A= =0A= Sean: it could be semanticaly different.=0A= =0A= Robert Sparks: I think we've framed the discussion so we can make = that=0A= distinction=0A= =0A= Vasilis: I want to make a point, pres: can be more general than sip:=0A= URI, it can collect presence from several sources (e.g. SS7 = networks)=0A= =0A= Robert: this is one of the first discussions I'd like to have on the=0A= list. What we do when we hit a gateway, in particular.=0A= =0A= =0A= Robert: (new slide)=0A= Should we have a message session bounded with INVITE/BYE?=0A= =0A= We could set up a session that uses RTP, we can set up a session = that=0A= uses SIP MESSAGE outside RTP, whatever we do we need to make it=0A= possible to cross a CPIM boundary. =0A= =0A= Hand over to JR.=0A= =0A= =0A= JR: messaging: session or not?=0A= Messaging has a dual nature. To some degree it's asynchronous. I=0A= send a message into the blue, it gets there, nothing more -- like=0A= e-mail. But for a lot of messages, there is a context, a thread -- = UI=0A= collects all the messages. Duality to the service. I think there's = a=0A= lot of benefit toward the session view of messaging.=0A= =0A= Example: here's an example with the current MESSAGE method. I send = a=0A= message to a user, it shows up at three PCs, there's no way to carry=0A= out separate conversations with the three users. But with INVITE, = we=0A= can just do this, forking works fine.=0A= =0A= This model would allow us to have messages not cross proxies. SIP=0A= proxies are signalling devices, they weren't designed to carry big=0A= messages. Vasilis has accused me of setting SIP back twenty years.=0A= We don't do this with RTP, why with IM?=0A= =0A= With this model we can do a lot of things supported by SIP --=0A= multiparty converencing, call controls, add messaging to voice call;=0A= more consistent with SIP.=0A= =0A= Pushback from IESG -- large messages WILL be an issue. No sending=0A= large messages through proxies.=0A= =0A= =0A= Existing sessions don't have a notion of a session -- can we emulate=0A= the existing GUI? Yes. I send an IM, my UI sends INVITE, recipient=0A= tool sends OK, my tool sends ACK, my tool sends message, remote tool=0A= displays message.=0A= =0A= ??: Some UIs *are* session-oriented.=0A= =0A= JR: yes. You could do either.=0A= =0A= Drawbacks: overhead for a single message. I think common case is=0A= multiple. Latency to set up (not as big a deal as voice). Not=0A= consistent with current implementations. Gatewaying harder? I = think=0A= it's actually easier.=0A= =0A= JL: if you hide session from a user, when do you send BYE?=0A= =0A= JR: when user closes window, or timeout, or whatever.=0A= =0A= Lawrence: This works for text chat, but what about SMS? Works for=0A= that, but not clear for SMS.=0A= =0A= JR: I'll deal with this.=0A= =0A= How is messaging session done?=0A= =0A= Approach I: SIP stream. Treat SIP as a stream also, like RTP. SDP=0A= has an m line with a mime type message. Port is 5060 or whateverk=0A= "payload type" is SIP, send SIP messages directly beween end points.=0A= Issue: NAT/FW=0A= =0A= Approach II: New messaging format: CPIM over TCP? Wouldn't need=0A= MESSAGE method=0A= =0A= Approach III: RFC 2793 (text over RTP), I don't think it's the same=0A= user experience, I don't think it's the right answer.=0A= =0A= Robert: can't get through CPIM boundary.=0A= =0A= Hgs: for low-speed devices, where entry is slow, it's nice to be = able=0A= to see what people type as they type=0A= =0A= JR: we already have this, don't need to tell people not to do it.=0A= =0A= Adam Roach: not a solution to this problem, but it's a different = nice=0A= thing you can do.=0A= =0A= JR: What about session-less? We can still have this, no INVITE=0A= semantics, no session much more like what things like SMS are today.=0A= Like OPTIONS.=0A= =0A= ??: GSM MAP or IS-41 MAP to transfer messgaes doesn't work, = commercial=0A= success, but overburdened signalling network, needed to create=0A= separate message network.=0A= =0A= JR: Here, you can have your cake and eat it too. We can send short=0A= messages over signalling network, or not, clean transition between = to=0A= if you like.=0A= =0A= Vasilis: Yes, but if you start with bad practice, difficult for = carriers to=0A= move from one to the other.=0A= =0A= JR: yes. You need to have guidelines in the document for when you=0A= move from one to the other, but I think it's useful to have both.=0A= =0A= Christian: MESSAGE as it's defined right now is an INVITE without an=0A= SDP payload. One of the things you can do with an INVITE right now = is=0A= to put a Subject in the message. There is a risk of people=0A= overloading the infrastructure, but if we don't allow it people will=0A= do it anyway, in a dirtier way.=0A= =0A= JR: It's all about documenting the best practice.=0A= =0A= Christian: I've been advocating this for six months.=0A= =0A= JR: Yes, I've been a luddite.=0A= =0A= Christian: Two kinds of push-back. Using signalling infrastructure=0A= helps with firewall traversal; and it doesn't actually overload the=0A= infrastructure since you can use redirect and contact addresses.=0A= =0A= JR: Yes, see my next slides.=0A= =0A= Pete: I've got one model that doesn't fit into either of these ways = of=0A= approaching it. E.g. getting pages of stock prices. If you do=0A= sessions, it's not clear when teardown occurs. If you do it=0A= sessionless, you get into overload. It's not clear this addresses=0A= this model.=0A= =0A= Christian: other point -- there's way more than one messaging model.=0A= With INVITE model, you get an explosion of various ways of doing=0A= things. Application-dependent -- can be good, but hurts=0A= interoperability.=0A= =0A= JR: trade-off between flexibility and interoperability. SIP walks=0A= this line very finely.=0A= =0A= Christian: possible to say this is a message, part of a session.=0A= =0A= Pete: I think Christian's stated my worry.=0A= =0A= JR: another option is to send content through URLs, if you don't = know=0A= whether the client can make use of the content.=0A= =0A= Vasilis: In my opinion instant messaging is a separate type of = protocol, I=0A= think what you're describing is a PUSH/notification service, which = is=0A= different. I would like to make the distinction between IM and = push.=0A= =0A= Pete: if you give people a hammer, they'll whack themselves in the=0A= head with it. If you create this, people will use this for things = we=0A= didn't expect it.=0A= =0A= JR: everything's a push protocol if you look at it at a high enough=0A= level. I don't see the difference between sending someone a = message,=0A= and inviting them to a call.=0A= =0A= Vasilis: yes, but you have to negotiate screen sizes.=0A= =0A= JR: comparisons. SIP stream has greatest flexibility; you don't = have=0A= to have two different ways to represent same data; makes it easy to = do=0A= all the things we want. Second choice is new stream protocol, not=0A= terribly appealing.=0A= =0A= Henning: since you're sending a complete message, does allow=0A= forwarding/aggregation. Not sure this is good or bad. Confusing if=0A= we copy from one or the other, message in message stream is = different=0A= from signalling stream. =0A= =0A= JR: can just offer SIP port on recieve side, bind to 5060, don't = need=0A= to be able to tell the difference.=0A= =0A= I don't think RTP approach is really viable.=0A= =0A= Advantage of using SIP network: deals with NAT/FW.=0A= Message stream: NAT on one side, solves problem, just let TCP=0A= connection flow.=0A= =0A= Use of SIP MESSAGE method as stream can solve other cases; send to=0A= bottom Route set, etc. Another possibility is route set in SDP.=0A= [General hum: no, no, yuck.]=0A= =0A= I think this is the biggest issue, everything else depends on this.=0A= =0A= Vasilis: question: You're saying initiate the session, and then use=0A= SIP as the streaming. Does it go through the proxy again?=0A= =0A= JR: no, except for NAT/FW. =0A= =0A= Vasilis: why not just use TCP or HTTP.=0A= =0A= JR: I am suggesting TCP. I don't think HTTP is a good idea, this is = a=0A= more peer-like protocol.=0A= =0A= Vasilis: there are already mobile clients with HTTP clients/servers.=0A= =0A= Jon Peterson: one possibility you raised is to invent something from=0A= scratch.=0A= =0A= JR: advantage to using SIP -- we already have relays, they're called=0A= proxies.=0A= =0A= Sean: I'm happy to have stream approach, but we should also have=0A= one-shot method as well, for small sessions/clients.=0A= =0A= Jon P.: does that suggest that MUST support message, MAY support=0A= stream?=0A= =0A= Sean: no.=0A= =0A= Vasilis: I don't like the use of the word 'streaming'; but also be=0A= careful because IESG already said we don't want large messages = through=0A= proxies.=0A= =0A= Robert: take this to the ML. I think this is appropriately flamed = --=0A= framed! [Laughter]=0A= =0A= What about CPIM boundary?=0A= =0A= JR: Is there a CPIM instant messaging map? In doing the presence=0A= one, the difficulties is to know when to get rid of it, when to have=0A= it. If you just wrap this thing in INVITE. As long as you have=0A= frame-bounded thing, its easy.=0A= =0A= We need to resolve this *fast*. Everything else depends on this.=0A= =0A= =0A= Robert Sparks: Question in both drafts: is REGISTER the right = PUBLISH=0A= mechanism? Can derive a presence document from registration...is=0A= REGISTER the right way to get it into the system from an endpoint?=0A= =0A= JR: let me provide clarification. We've been saying all along that = my=0A= presence is composed of information from lots of different sources,=0A= composed in backends. REGISTER is one source, not the only one. = Plug=0A= in other sources, not necessarily SIP. Question: if I want to = upload=0A= a document that describes my presence, is REGISTER the right way to = do=0A= this? Similar to uploading CPL. I've become sketchy on using=0A= REGISTER for this. Problem: there are two things that can fail=0A= independently -- upload a CPL, can fail either because the contacts=0A= have a problem, or because the CPL does. I think there should be a=0A= separate mechanism -- similar to how BYE/Also was split into = REFER/BYE=0A= so they can fail independently. =0A= =0A= Henning: the problem is it's another special-purpose method -- it = has=0A= REGISTER semantics, addressed to registrar rather than delivered to=0A= end system.=0A= =0A= Sean: SERVICE mechanism?=0A= =0A= JR: No, no, not a good idea. YOu have to have an explicit model for=0A= what this means. Mechanism for sending subscriber data to database=0A= that proxy can access. Can't just be a general "stuff" mechanism,=0A= need semantics.=0A= =0A= Robert Sparks: have to separate providing routing information with=0A= REGISTER with other mechanisms, need to distinguish failure=0A= mechanisms.=0A= =0A= Vasilis: when you power on, you do two methods instead of one.=0A= =0A= Henning: you could define REGISTER without contacts.=0A= =0A= JR: then it's not REGISTER anymore. We have guidelines.=0A= =0A= =0A= Robert: new issue: Authorization. (This will probably take all = day.)=0A= How do we get authorization from an entity, not in machine-time. = Hand=0A= over to Jonathan.=0A= =0A= JR: We know for presence we MUST be able to authorize subscriber by=0A= finding out from presentity whether it's okay. You can always have=0A= ACLs for specific people, but if we don't have it you need to be = able=0A= to ask the user. First version of presence draft had QAUTH -- it=0A= always made me queasy. Review how it works. When I turn on, I send = a=0A= registration with a parameter that says "this supports QAUTH". When = a=0A= subscription comes in, it sends 202 and sends QAUTH and asks, "is = this=0A= okay, or not"? Problem is it's an overload: uses registrations to=0A= imply ability to make authorization decisions - dangerous to=0A= overload. E.g. you have a generic registrations.=0A= =0A= Also, want to support multiple users that can set policy. Because = we=0A= use QAUTH, QAUTH can fork. Problem is that for non-INVITE, only one=0A= 200 response is delivered. Badly broken! Need to collect all=0A= responses.=0A= =0A= Another problem -- transaction in process while waiting for user.=0A= What if user is away? Transaction will time out.=0A= =0A= New proposal: my subscription state is itself a subscribable entity.=0A= Watcherinfo -- I can subscribe to it. A presentity like any other.=0A= Watcherinfo maintains state for users with active or pending=0A= subscriptions.=0A= =0A= Dave Oran: what about infinite recursion?=0A= =0A= JR: policy for who's allowed to subscribe to watcherinfo is static = --=0A= only presentity themselves or administrator.=0A= =0A= Robert Sparks: this could be a separate event package.=0A= =0A= JR: when the subscriber of watcherinfo sees subscription state has=0A= changed, they can push a new policy document to the server. = Notified=0A= PUSH.=0A= =0A= flow: SUBUBSCRIBE -> 202, generates NOTIFY watcherinfo, upload = policy.=0A= =0A= Advantages: who can upload policy has nothing to do with=0A= registrations. Determined by who can send upload messages.=0A= =0A= I can receive notifications about subscriptions without sending = poicy.=0A= =0A= Multiple entities can authorize.=0A= =0A= Dave Oran: this doesn't work for any arbitrary policy merge. If=0A= multiple users upload policies, can't me merged in consistent = fashion=0A= (e.g. classic ACLs). Does anyone find out there was an error, and = how=0A= are errors of upload handled? Is it just first one wins?=0A= =0A= JR: it's flexible.=0A= =0A= Dave: that's the problem.=0A= =0A= JR: only one user can upload policy -- presentity. Just replaces.=0A= =0A= Henning: not fundamentally different from forking problem with = QAUTH.=0A= I subscribe to watcherinfo from two different places (have to, or = bad=0A= things can happen). I get two notifications for change of=0A= watcherinfo. This means that one can say yes, and one say no.=0A= There are half-a-dozen policies you can do.=0A= =0A= Dave: Is what you send a decision, or a policy map? Get = notification=0A= 'Bob wants to subscribe'. I can respond with 'Bob's allowed, Sue's=0A= allowed, Joe's allowed.' QAUTH doesn't have merge problem.=0A= =0A= JR: problem exists anyway. Have to reconcile with offline policy.=0A= =0A= Henning: You have to be very careful what policy document is. = Several=0A= notifications happen in sequence; if you believe in complete state,=0A= what happens.=0A= =0A= JR: I don't think complete state is a good idea.=0A= =0A= Henning: do you want to be notified for renewals?=0A= =0A= JR: no. No change to watcherinfo.=0A= =0A= (Continuing with slide) multiple entites can upload policy -- server=0A= can reconcile (but we need to figure out how). Unifies triggered = and=0A= untriggered policy -- cleanness if we have one way to do this rather=0A= than two.=0A= =0A= Vasilis: [question I didn't entirely understand...] What's you=0A= definition of policy?=0A= =0A= JR: it's a list, "allow bob, don't allow joe". Or pieces.=0A= =0A= Vasilis: where is reconciliation?=0A= =0A= JR: in the server.=0A= =0A= Vasilis: in the device, or in the presence server?=0A= =0A= JR: doesn't matter. It's a logical role.=0A= =0A= Vasilis: can you have multiple PAs?=0A= =0A= JR: no.=0A= =0A= Dave: in the QAUTH scheme there's transactional state, here there=0A= isn't. But if you want to maintain causal ordering, the server has = to=0A= maintain the equivalent of transaction state. Joe tries to = subscribe,=0A= Sue tries to subscribe, notifications cross. Decision as to what to=0A= push back is causally depentant on what other transactions = completed.=0A= First one says "allow bob, not sue". Second one says "allow bob,=0A= disallow dave".=0A= =0A= JR: I don't see why it matters. As long as I can go to a webpage = and=0A= do it, it doesn't make any difference.=0A= =0A= Dave: I'll take it off line. I'm just pointing out there are=0A= complicated merge issues that aren't addressed here.=0A= =0A= JR: I'd like to know what they are.=0A= =0A= Henning: we haven't specified policy mechanisms, but it's clear = there=0A= are some mechanisms that don't fit here without careful thought. It=0A= has to be composable at a syntactic level with reasonable action.=0A= Also, policies have to have time associated -- "this person can't=0A= subscribe right now, but can a minute from now" up to "this person = can=0A= never subscribe." E.g. work vs. home subscriptions.=0A= =0A= JR: we can separate this -- keep it simple at first, then update=0A= independently of subscription stuff.=0A= =0A= Henning: Also, anything we don't say about remains in pending state=0A= =0A= Eric Hauper: I don't think this will work, I don't think any = automated=0A= query is at all reasonable. I think that subscription is a special=0A= message sent to the user -- will you allow me to subscribe to you?=0A= =0A= JR: you're mixing implementation and service. What is it you want=0A= from a service perspective?=0A= =0A= Eric: I think the server shouldn't get involved in this at all, = other=0A= than queueing up messages. The server shouldn't get involve in = people=0A= trying to subscribe to a presence that doesn't exist in the ACL.=0A= =0A= JR: this model would allow that approach.=0A= =0A= Eric: I don't think it should be triggered on a subscription at all.=0A= =0A= JR: that's how it works now with existing systems. I know at least=0A= Yahoo works this way.=0A= =0A= Eric: I don't think the server should have a concept of this.=0A= =0A= JR: send something to the list that explains this problem. I'm=0A= hesitant to understand the problem.=0A= =0A= Theo Kalvinis(sp?): I agree with this proposal. I also note the=0A= presence server is hiding the subscription. Always give back answer=0A= "Noted".=0A= =0A= JR: yes, -01 does this: Always generates 202, fake notify, you can't=0A= tell this is happening.=0A= =0A= Theo: what happens on fetch?=0A= =0A= JR: if I have an ACL that allows you, it works...have to think about=0A= other case.=0A= =0A= Robert Sparks: there's a problem there, need to take it to the list.=0A= =0A= Point in general: when I made a call for open issues, I wish that = had=0A= been raised then. Raise open issues to the list when they occur to=0A= you.=0A= =0A= Vasilis: big issue, how do you handle pending subscriptions, CPIM=0A= doesn't say anything about this. I think we can resolve this in = IMPP,=0A= not here.=0A= =0A= JR: problem isn't what subscribers say, it's how it relates to=0A= authorization. If you never know someone try to subscribe.=0A= =0A= Theo(?): one more potential issue, if entity A and entity B have=0A= distinct domains/servers. If I'm B and I want to subscribe to A,=0A= whose presence server do I go to?=0A= =0A= JR: A's.=0A= =0A= Theo: what if two people want to be bob@domain-A.com?=0A= =0A= JR: don't do that.=0A= =0A= JL: I think policy info should be subscribable.=0A= =0A= JR: too complicated.=0A= =0A= (Continuing with slide)=0A= =0A= What if someone subscribes when I'm offline?=0A= =0A= I log in, fetch watcherinfo, approve pending subscription sif we = want.=0A= =0A= How do we do it?=0A= Need:=0A= * event package for watcherinfo (Patrick says okay to do in SIMPLE,=0A= needed for presence)=0A= * watcher info data format (in NOTIFY of watcherinfo) (had one in=0A= original June 2000 drafts)=0A= * policy document - document is a good idea - can share it, store = it,=0A= generate it by servlets, universal intermediate usage like CPL=0A= * How do we upload it?=0A= =0A= Proposal: define something new, update JL's register upload for new=0A= method (setdata?). Not done in SIMPLE.=0A= =0A= I think this is the second-biggest issue. If you have better idea,=0A= mention it, I'm not wedded to this, but we need something, and I = think=0A= it's better than QAUTH.=0A= =0A= =0A= Robert Sparks:=0A= Should we rate-limit NOTIFY? Sip-events punted, sent it off to = event=0A= packages. We have an event package, what do we want to do?=0A= =0A= JR: I don't think so, let's keep it simple, it's not like this = happens=0A= frequently.=0A= =0A= Robert: for presence for people, some people are trying to do this.=0A= GEOLOC.=0A= =0A= Henning: it's probably not that effective. What you worry about is=0A= total inbound sender rate, you can only limit one. Hard to do = client=0A= control on server side. Server side is probably more substantial=0A= load, e.g. sending info to thousands of subscribers.=0A= =0A= Robert: agree that for first pass, we may not need to solve it. But=0A= if we don't solve it, are we closing the door to solving it later?=0A= =0A= Henning: I don't think so, it's just a parameter. More general=0A= problem: subscriptions are unqualified -- "I want to hear from you" = or=0A= "I don't want to hear from you". Can't do something more=0A= finer-grained. I think rate limitations are just a part of this,=0A= which we want to do later.=0A= =0A= Robert Sparks: so I propose that unless someone says something, = let's=0A= just leave it undefined for now.=0A= =0A= JR: current subscription document says that subscription body can=0A= contain TBD subscription filter.=0A= =0A= =0A= Robert Sparks: next issue:=0A= is lowest common denominator message/cpim or text/plain?=0A= For e-e across cpim boundary need to do message/cpim.=0A= Some agents may not care.=0A= =0A= JR: careful. For sending, can say don't care. For recieving, what = if=0A= APEX user wants to send message/cpim? I think MUST receive m/cpim,=0A= MAY send it.=0A= =0A= Ben Campbell: do we want to say that all our devices must be CPIM=0A= compliant? Is it okay to have a simple end system that can't cross=0A= CPIM?=0A= =0A= Henning: you can rule it out all you want, it won't matter. It's a=0A= complicated spec, people will do subsets.=0A= =0A= JR: that's always the case. I think the answer from the ADs is that=0A= the spec has to be CPIM-compliant. I can't control implementations.=0A= =0A= Henning: if it's an authenticated message, the gateway could convert=0A= it, losing authentication. In general, we can't verify that end=0A= system can verify authentication anyway. Need PKI, need common root=0A= certificate.=0A= =0A= JR: I don't think that's an excuse not to allow for interoperable=0A= authentication end-to-end.=0A= =0A= Henning: could specify in caller preferences.=0A= =0A= JR: gateway isn't necessarily your registrar.=0A= =0A= JL: could say that just require multipart/alternative, gateways=0A= provide both text/plain and message/cpim.=0A= =0A= Vasilis: How do we make this decision?=0A= =0A= Robert: on the list.=0A= =0A= Ben: don't take this as a criticism of interoperability.=0A= =0A= Robert: I think we have consensus for MUST receive message/cpim, MAY=0A= send text/plain.=0A= =0A= =0A= (skip some slides, then:) =0A= Question: what does a body in a 200 OK to a MESSAGE mean? Is it a=0A= reply?=0A= =0A= JR: it's broken to do this, can't maintain ordering.=0A= =0A= Robert: so say MUST NOT include body in response.=0A= =0A= Henning: raises issue -- if you do streaming of SIP MESSAGES, do you=0A= still do 200?=0A= =0A= JR: yes.=0A= =0A= Robert: (new issue)=0A= How do you synthesize presence document from reigstered data?=0A= =0A= JR: this is dependent on CPIM presence format.=0A= =0A= Robert: (new issue)=0A= How do you interact route/record-route and migration of notify=0A= responsibility?=0A= =0A= JR: Migration only on new subscriptions. Special-casing=0A= route/record-route is very bad.=0A= =0A= Christian: It's not clear that R/RR makes sense for non-INVITE=0A= messages anyway. Why do you want to record-route subscription?=0A= =0A= JR: various services, e.g. firewall traversal=0A= =0A= Christian: I want to disallow r-r in subscribe.=0A= =0A= Robert: this will require more list chewing.=0A= =0A= (new issue)=0A= Can we reduce state that gateway must maintain? cpim doesn't = reflect=0A= call-leg semantic.=0A= Point out: no such thing as cpim-on-the-wire, maybe can translate=0A= state into state in other people.=0A= =0A= JL: can we do the opposite, provide state for other protocols?=0A= =0A= Robert: it'd be nice.=0A= =0A= (new issue)=0A= Does it make sense to have MESSAGE with no body?=0A= [general muttering]=0A= =0A= (new issue)=0A= Should we say that accept means mime type inside message/cpim=0A= =0A= JR: yes.=0A= =0A= RS:=0A= Other issues:=0A= Congestion control, map to CPIM=0A= =0A= JR: If we do streaming over TCP, problem goes away.=0A= =0A= Christian: no it doesn't. If I'm in conference mode, maybe many TCP=0A= sessions.=0A= =0A= JonP: I think it's sufficient.=0A= =0A= RS: we made it through slides, one minute over, take remaining = issues=0A= to list!=0A= =0A= =0A= =0A= =0A= ------_=_NextPart_000_01C0C132.C376C9A1 Content-Type: application/vnd.ms-powerpoint; name="SIMPLEopenIssues.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SIMPLEopenIssues.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOQAAAAAAAAAA EAAASwAAAAEAAAD+////AAAAADgAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8P AOgD9BQAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A 8gMWAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUHTAAAAAAAtw9EAAAAQQByAGkAYQBsAAAAAAAA AJDaEgBw2hIAuDi5AEzeEgD0QbkAnNoSAITaEgB2xwswCAAAAAAAAACc2hIAKN0NMABYBiIAAKQP CgAAAIAAYAAAAP////8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9u AAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA//////// GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAP AAsEJAEAAA8AAPAcAQAAAAAG8NAAAAAEYAAAGQAAADkAAAASAAAAAQAAAAcAAAACAAAABAAAAAMA AAAEAAAABAAAAAQAAAAAAAAABAAAAAYAAAAEAAAABwAAAAQAAAAIAAAABAAAAAkAAAAEAAAACgAA AAQAAAALAAAABAAAAAwAAAAEAAAAAAAAAAQAAAAOAAAABAAAAA8AAAAEAAAAEAAAAAQAAAARAAAA BAAAABIAAAAEAAAAEwAAAAQAAAAAAAAABAAAABUAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAAAAQA AAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHewEA AB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaOzJOzckAypo7AQEAAQ8A+gNnAAAAAAD+AwMAAAAAAQAA AP0DNAAAAEEAAABkAAAAQQAAAGQAAAB2xwswCAAAAAAAAACQ2hIAAAAAAAAAAACm////4P7//wEA AABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAA ACEAAABkAAAAYPMNMEzeEgAAAAAA4EK5AAAAAAAAAAAAAAAAAAAAAAAAARIAHwATBDwAAAAAAP0D NAAAAGQAAABkAAAAZAAAAGQAAABg8w0wTN4SAAAAAADgQrkAAAAAAAAAAAAAAAAAAAAAAAABEgAf AP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAIBDwAAAAAAP0DNAAAAEIAAABkAAAAQgAAAGQA AAC82hIA2fQNMEzeEgABAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAPAPAPwxAAAAAA8wMUAAAAAwAA AAAAAAAAAAAAAAEAAAAAAAAAAPMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAA AACoDyAAAABEbyB3ZSB3YW50IHRvIHJhdGUgbGltaXQgTk9USUZZPxAAnw8EAAAAAQAAAAAAqA96 AAAAc2lwLWV2ZW50cyBwdXNoZWQgdGhpcyBvdXQgdG8gaW5kaXZpZHVhbCBwYWNrYWdlcw1IZWxw cyB3aXRoIGNvbmdlc3Rpb24gY29udHJvbA1EbyB3ZSBuZWdvdGlhdGUgdGhlIHJhdGUgZHVyaW5n IHN1YnNjcmliZT8AAPMDFAAAAAcAAAAAAAAAAgAAAAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDyMA AABNaWdyYXRpb24gaW50ZXJhY3RzIGJhZGx5IHdpdGggUlIvUgAAqg8SAAAAIwAAAAAAAAABAAAA AQAAAAAAEACfDwQAAAABAAAAAACoD/kAAABNaWdyYXRpb24gaXMgdGhlIHRyYW5zZmVyIG9mIE5P VElGWSByZXNwb25zaWJpbGl0eSBmcm9tIGEgcHJlc2VuY2Ugc2VydmVyIHRvIGEgUEEgd2l0aG91 dCBzcGVjaWFsIGJlaGF2aW9yIG9uIHRoZSBwYXJ0IG9mIHRoZSBTdWJzY3JpYmVyLg1EbyB3ZSBk aXNhbGxvdyBNaWdyYXRpb24gb3IgZG8gd2UgbWFrZSBSUi9Db250YWN0IGJlaGF2aW9yIHNwZWNp YWwgZm9yIFNVQlNDUklCRT8NQXJlIHRoZXJlIG90aGVyIGFsdGVybmF0aXZlcz8AAKEPFAAAAPoA AAAAAAAQAABaAPoAAAAAAAAAAACqDxIAAAD5AAAAAAAAAAEAAAABAAAAAAAAAPMDFAAAAAgAAAAA AAAAAgAAAAUBAAAAAAAAAACfDwQAAAAAAAAAAACoDyUAAABDYW4gd2UgY29udmVydCBzaXAgVVJM cyB0byBwcmVzOiBVUkxzAACqDxIAAAAlAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgP lwAAAElmIHdlIGhhdmUgc3BlY2lhbGl6ZWQgYSBwcmVzOiBVUkwgdG8gYSBzaXA6IFVSTCBiZWZv cmUgcmVhY2hpbmcgYSBjcGltIGdhdGV3YXksIGNhbiB3ZSByZWxpYWJseSBjb252ZXJ0IGJhY2sg dG8gYSBtZWFuaW5nZnVsIHByZXM6IFVSTCBhdCB0aGUgZ2F0ZXdheT8AAKoPGgAAAEMAAAAAAAAA BQAAAAEAAAADAFAAAAAAAAAAAADzAxQAAAAJAAAAAAAAAAIAAAAGAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA85AAAAQ2FuIHdlIHJlZHVjZSB0aGUgc3RhdGUgYSBzaXAvY3BpbSBnYXRld2F5IG11c3Qg bWFpbnRhaW4/AACqDyQAAAAeAAAAAAAAAAUAAAABAAAAAwAWAAAAAAAAAAEAAAABAAAAAAAQAJ8P BAAAAAEAAAAAAKAPDgEAAGMAcABpAG0AIABkAG8AZQBzAG4AGSB0ACAAcgBlAGYAbABlAGMAdAAg AHQAaABlACAAYwBhAGwAbAAtAGwAZQBnACAAcwBlAG0AYQBuAHQAaQBjAC4ADQBOAG8AIABzAHUA YwBoACAAdABoAGkAbgBnACAAYQBzACAAYwBwAGkAbQAgAG8AbgAgAHQAaABlACAAdwBpAHIAZQAg ABMgIABtAGEAeQAgAGIAZQAgAGEAYgBsAGUAIAB0AG8AIAB0AHIAYQBuAHMAbABhAHQAZQAgAHMA dABhAHQAZQAgAHQAbwAgAHQAaABlACAAbwB0AGgAZQByACAAcAByAG8AdABvAGMAbwBsAHMALgAg AAAAqg8kAAAABAAAAAEAAAADADkAAAAAAAAABQAAAAEAAAADAEYAAAAAAAAAAADzAxQAAAAKAAAA AAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8/AAAASG93IGRvIHlvdSBzeW50aGVzaXpl IGEgcHJlc2VuY2UgZG9jdW1lbnQgZnJvbSByZWdpc3RlcmVkIGRhdGE/AACqDxIAAAA/AAAAAAAA AAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPWAAAAFRoaXMgaXMgb25seSBvbmUgd2F5IHRvIGNy ZWF0ZSBhIHByZXNlbmNlIGRvY3VtZW50LCBidXQgaXQgaXMgaW1wb3J0YW50IGFuZCBub3QgdHJp dmlhbC4AAPMDFAAAAAsAAAAAAAAAAgAAAAcBAAAAAAAAAACfDwQAAAAAAAAAAACoDzIAAABEb2Vz IGl0IG1ha2Ugc2Vuc2UgdG8gaGF2ZSBhIE1FU1NBR0Ugd2l0aCBubyBib2R5PwAAqg8SAAAAMgAA AAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAAMAAAA AAAAAAIAAAAJAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA88AAAASXMgdGhlIGxvd2VzdCBjb21tb24g ZGVub21pbmF0b3IgbWVzc2FnZS9jcGltIG9yIHRleHQvcGxhaW4/AACqDyQAAAApAAAAAAAAAAUA AAABAAAAAwAOAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPaAAAAG1lc3NhZ2UvY3Bp bSBpcyByZXF1aXJlZCBmb3IgZS1lIGFjcm9zcyBhIGNwaW0gYm91bmRhcnkNU29tZSBhZ2VudHMg bWF5IG5vdCBjYXJlIGFib3V0IGVuZC1lbmQgc2VjdXJpdHkgAACqDywAAAAIAAAAAAAAAAUAAAAB AAAAAwAdAAAAAAAAAAUAAAABAAAAAwA6AAAAAAAAAAAA8wMUAAAADQAAAAAAAAACAAAACgEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPNAAAAElzIHVzZSBvZiB0aGUgQWNjZXB0IGhlYWRlciB3aXRoIG1l c3NhZ2UvY3BpbSBjbGVhcj8AAKoPJAAAACkAAAAAAAAABQAAAAEAAAADAAYAAAAAAAAAAQAAAAEA AAAAABAAnw8EAAAAAQAAAAAAqA9HAAAAQWNjZXB0IGhlYWRlciBuZWVkcyB0byBsaXN0IHRoZSBl bWJlZGRlZCBtaW1lIHR5cGVzIHRoYXQgYXJlIGFjY2VwdGFibGUAAPMDFAAAAA4AAAAAAAAAAgAA AAsBAAAAAAAAAACfDwQAAAAAAAAAAACgD3oAAABNACAAEyAgAFMAaABvAHUAbABkACAAdwBlACAA aABhAHYAZQAgAGEAIABtAGUAcwBzAGEAZwBlACAAcwBlAHMAcwBpAG8AbgAgAGIAbwB1AG4AZABl AGQAIAB3AGkAdABoACAASQBOAFYASQBUAEUALwBCAFkARQA/AAAAqg8SAAAAPQAAAAAAAAABAAAA AQAAAAAAEACfDwQAAAABAAAAAACoDw4AAABQYWdlcyB2cyBjaGF0cwAAqg8kAAAABgAAAAAAAAAD AAAAAQAAAAMABQAAAAAAAAABAAAAAQAAAAAAAADzAxQAAAAPAAAAAAAAAAIAAAAMAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8tAAAAV2hhdCBkb2VzIGEgYm9keSBpbiBhIDIwMCBPSyB0byBNRVNTQUdF IG1lYW4/AACqDxIAAAAtAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPVwAAAEN1cnJl bnQgc3BlYyBhbGxvd3MgaXQNSXMgdGhpcyBhIHJlcGx5IG1lc3NhZ2U/IFdvdWxkIGl0IGhhdmUg dG8gY3Jvc3MgYSBDUElNIGJvdW5kYXJ5PwAAqg8SAAAAVwAAAAAAAAABAAAAAQAAAAAAAADzAxQA AAAQAAAAAAAAAAIAAAANAQAAAAAAAAAAnw8EAAAAAAAAAAAAoA94AAAATQAgABMgIABpAG0AOgAg AGEAbgBkACAAcAByAGUAcwA6ACAAaQBuACAAVABvADoAIABoAGUAYQBkAGUAcgBzACAAbwBmACAA UgBFAEcASQBTAFQARQBSACAAbwByACAAcgBlAHEAdQBlAHMAdAAgAFUAUgBJAHMAAACqDy4AAAAE AAAAAAAAAAIAAAABAAAAAwAyAAAAAAAAAAQAAAABAAAAAwABAAAAAQAAAAEAEACfDwQAAAABAAAA AACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAARAAAAAAAAAAIAAAAQAQAAAAAAAAAAnw8EAAAAAAAA AAAAoA8sAAAATQAgABMgIABDAG8AbgBnAGUAcwB0AGkAbwBuACAAYwBvAG4AdAByAG8AbAAAAKoP EgAAABYAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqg8KAAAAAQAAAAEAAAAAAAAA8wMU AAAAEgAAAAAAAAACAAAAEQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKAPHgAAAE0AIAATICAATQBhAHAA IAB0AG8AIABDAFAASQBNAAAAqg8SAAAADwAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACq DwoAAAABAAAAAQAAAAAAAADzAxQAAAATAAAAAAAAAAIAAAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAA oA8yAAAAUAAgABMgIABuAGUAZQBkACAAYQAgAHcAYQB5ACAAdABvACAAUABVAEIATABJAFMASAAA AKoPEgAAABkAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqg8KAAAAAQAAAAEAAAAAAAAA 8wMUAAAAFAAAAAAAAAACAAAADwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKAPSAAAAFAAIAATICAAQQB1 AHQAaABvAHIAaQB6AGEAdABpAG8AbgAgACgAcAB1AHMAaAAvAHMAdQBiACAAdABvACAAcwB1AGIA cwApAAAAqg8SAAAAJAAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAA AAAAAADzAxQAAAAFAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8YAAAATWVyZ2lu ZyBvZiBQcmVzZW5jZSBEYXRhAACqDxIAAAAYAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAA AKAPMgEAAEQAaQBzAGMAdQBzAHMAaQBvAG4AIABvAGYAIABtAGUAcgBnAGkAbgBnACAAcAByAGUA cwBlAG4AYwBlACAAZABhAHQAYQAgAGYAcgBvAG0AIABtAHUAbAB0AGkAcABsAGUAIABVAEEAcwAg AGgAYQBzACAAYgBlAGUAbgAgAHIAZQBtAG8AdgBlAGQAIABmAHIAbwBtACAAdABoAGUAIABkAHIA YQBmAHQALgAgAFAAcgBvAGIAbABlAG0APwANAFAAcgBvAHAAbwBzAGEAbAA6ACAARABvAG4AGSB0 ACAAbgBlAGUAZAAgAHQAbwAgAGEAZABkAHIAZQBzAHMAIAB0AGgAaQBzACAAcAByAG8AYgBsAGUA bQAgAGkAbQBtAGUAZABpAGEAdABlAGwAeQAuAAAAqg8aAAAAMgAAAAAAAAAEAAAAAQAAAAMAZAAA AAAAAAAAAOoDAAAAAA8A+AOcCAAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAAAABgAPAH IAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYAYADwByAAAAD///8AAAAAAICAgAAA AAAAAMyZADMzzADMzP8AsrKyAGAA8AcgAAAA////AAAAAAAzMzMAAAAAAN3d3QCAgIAATU1NAOrq 6gBgAPAHIAAAAP//zAAAAAAAZmYzAICAAAAzmTMAgAAAAAAzzAD/zGYAYADwByAAAAD///8AAAAA AICAgAAAAAAA/8xmAAAA/wDMAMwAwMDAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAMDAwAAAZv8A /wAAAACZAABgAPAHIAAAAP///wAAAAAAgICAAAAAAAAzmf8Amf/MAMwAzACysrIAAACjDz4AAAAB AP/9PwAAACIgAABkAAAAAAABAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8sAAAA AAMAABAAow98AAAABQD//T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAABwAAAP//7wAA AAAA////////IAAAAAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPAD YAMAAAIAFACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAB4AAAAA AAAAQAIAAAAABwAAAP//7wAAAAAA////////DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAA AAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEAAQkA AAAAAQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCABAAA AABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIAGAAC AAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABgA AQAAAAAAAAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBNYEAAAP AALwzgQAABAACPAIAAAABgAAAAYEAAAPAAPwZgQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMAC/A2AAAAfwAB AAUAgABIbbkAhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgA AACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAAAQC5AA8ADfBUAAAAAACfDwQAAAAAAAAAAACo DyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoA AAAhAAAAAQAAAAAADwAE8BYBAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEABQCAAFiSuQCB AQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAOAEsAHQFAAPDwAR8BAA AAAAAMMLCAAAAAEAAAACALkADwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVk aXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2 ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8K AAAAUwAAAAEAAAAAAA8ABPC2AAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAUAgAAMmrkA gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7ABYAaAEA8AEfAQ AAAAAADDCwgAAAACAAAABwG5AA8ADfA+AAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAA AgAAAAAAAAAAAAIAAAAAAAIADgAAAPgPBAAAAAAAAAAPAATwuAAAABIACvAIAAAABQQAAAAKAACD AAvwMAAAAH8AAQAFAIAAlJm5AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAAYA+wB9AOgBAPABHwEAAAAAAAwwsIAAAAAwAAAAkCuQAPAA3wQAAAAAAAnw8EAAAABAAA AAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAABAAIAAAAAAAIADgAAAPoPBAAAAAAAAAAPAATw uAAAABIACvAIAAAABgQAAAAKAACDAAvwMAAAAH8AAQAFAIAA2Km5AIEBBAAACIMBAAAACL8BAQAR AMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAYA8gENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgC uQAPAA3wQAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAA AAIADgAAANgPBAAAAAAAAAAPAATwSAAAABIACvAIAAAAAQQAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACA gIAAAAAAAADMmQAzM8wAzMz/ALKysgAgALoPHAAAAEQAZQBmAGEAdQBsAHQAIABEAGUAcwBpAGcA bgAPAO4D0wIAAAIA7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAAAAAAHAAAADwAMBIMCAAAPAALwewIA ACAACPAIAAAAAwAAAAMIAAAPAAPwEwIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAACAAABQAAAA8ABPDbAAAAEgAK8AgAAAACCAAAIAIAAFMAC/AeAAAAfwAAAAQAgAAY geMBvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAD///// DQDjAQ8ADfB1AAAAAACfDwQAAAAAAAAAAACoDz8AAABXaGF0IGFyZSB0aGUgcmFtaWZpY2F0aW9u cyBvZiBtaXhpbmcgcHJlczosIGltOiwgYW5kIHNpcDogVVJMcz8AAKoPGgAAACwAAAAAAAAAAgAA AAEAAAADABIAAAAAAAAADwAE8PgAAAASAArwCAAAAAMIAAAgAgAAUwAL8B4AAAB/AAAABACAACDc 4wG/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAP////8O AJ8CDwAN8JIAAAAAAJ8PBAAAAAEAAAAAAKgPZAAAAFJlcXVlc3QtVVJJDVRvOiBhbmQgRnJvbTog aW4gZ2VuZXJhbA1UbzogaW4gUkVHSVNURVINQ29udGFjdDogaW4gZ2VuZXJhbCAoUi9SUikNQ29u dGFjdDogaW4gUkVHSVNURVIAAKoPEgAAAGQAAAAAAAAAAQAAAAEAAAAAAA8ABPBIAAAAEgAK8AgA AAABCAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ AAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAA AgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAMAAI8AgAAAAD AAAAAwwAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAM AAAFAAAADwAE8HIAAAASAArwCAAAAAIMAAAgAgAAUwAL8B4AAAB/AAAABACAAIyS4wG/AQAAAQD/ AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAOMBDwAN8AwA AAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAwwAACACAABTAAvwHgAAAH8AAAAEAIAAoH3j Ab8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A 4wEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABDAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAA AACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAYAAI8AgAAAADAAAAAxgAAA8AA/AkAQAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAYAAAFAAAADwAE8HIAAAASAArwCAAA AAIYAAAgAgAAUwAL8B4AAAB/AAAABACAALjf4wG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIAB sAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGgCDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAA ABIACvAIAAAAAxgAACACAABTAAvwHgAAAH8AAAAEAIAAAPrjAb8BAAABAP8BAAABAAEDAwQAAAAA EPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A4wEPAA3wDAAAAAAAng8EAAAAAQAA AA8ABPBIAAAAEgAK8AgAAAABGAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADM zP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8A AvCMAQAAcAAI8AgAAAADAAAAAxwAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA AAAAAAACAArwCAAAAAAcAAAFAAAADwAE8HIAAAASAArwCAAAAAIcAAAgAgAAUwAL8B4AAAB/AAAA BACAAKAcaAK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAA AAAAAAANAGgCDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAxwAACACAABTAAvw HgAAAH8AAAAEAIAAsIzjAb8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAA AAAAwwsIAAAAAQAAAA4AaAIPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABHAAA AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMB AAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgA AAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAgAAI8AgAAAADAAAAAyAA AA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAgAAAFAAAA DwAE8HIAAAASAArwCAAAAAIgAAAgAgAAUwAL8B4AAAB/AAAABACAAIgkaAK/AQAAAQD/AQAAAQAB AwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGgCDwAN8AwAAAAAAJ4P BAAAAAAAAAAPAATwcgAAABIACvAIAAAAAyAAACACAABTAAvwHgAAAH8AAAAEAIAA5A9oAr8BAAAB AP8BAAABAAEDAwQAAAAAEPAIAAAAcAWwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AaAIPAA3w DAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABIAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICA gAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAA AAcAAAAPAAwElAEAAA8AAvCMAQAAoAAI8AgAAAADAAAAAygAAA8AA/AkAQAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAoAAAFAAAADwAE8HIAAAASAArwCAAAAAIoAAAg AgAAUwAL8B4AAAB/AAAABACAAEh3aAK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAE DwAR8BAAAAAAAMMLCAAAAAAAAAANAGgCDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAI AAAAAygAACACAABTAAvwHgAAAH8AAAAEAIAAqHtoAr8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA MAawAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AaAIPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBI AAAAEgAK8AgAAAABKAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKy AA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAA kAAI8AgAAAADAAAAAyQAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAAAkAAAFAAAADwAE8HIAAAASAArwCAAAAAIkAAAgAgAAUwAL8B4AAAB/AAAABACAAORp aAK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAAN AGgCDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAyQAACACAABTAAvwHgAAAH8A AAAEAIAARG5oAr8BAQABAP8BAQABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsI AAAAAQAAAA4AaAIPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABJAAAAAwAAIMA C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAA DQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAsAAI8AgAAAADAAAAAywAAA8AA/Ak AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAsAAAFAAAADwAE8HIA AAASAArwCAAAAAIsAAAgAgAAUwAL8B4AAAB/AAAABACAAFwyaAK/AQAAAQD/AQAAAQABAwIEAAAA ABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGgCDwAN8AwAAAAAAJ4PBAAAAAAA AAAPAATwcgAAABIACvAIAAAAAywAACACAABTAAvwHgAAAH8AAAAEAIAAVNDjAb8BAAABAP8BAAAB AAEDAwQAAAAAEPAIAAAAoAWwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A4wEPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABLAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAA AMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAP AAwElAEAAA8AAvCMAQAAwAAI8AgAAAADAAAAAzAAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAAAwAAAFAAAADwAE8HIAAAASAArwCAAAAAIwAAAgAgAAUwAL 8B4AAAB/AAAABACAABiYaAK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAA AAAAAMMLCAAAAAAAAAANAGgCDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAzAA ACACAABTAAvwHgAAAH8AAAAEAIAAuIDjAb8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAU AA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A4wEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK 8AgAAAABMAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPk AQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAA4AAI8AgA AAADAAAAAzgAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAA AAA4AAAFAAAADwAE8HIAAAASAArwCAAAAAI4AAAgAgAAUwAL8B4AAAB/AAAABACAACjuaAK/AQAA AQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGgCDwAN 8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAzgAACACAABTAAvwHgAAAH8AAAAEAIAA bN5oAr8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAA AA4AaAIPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABOAAAAAwAAIMAC/AwAAAA gQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAA AAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAA8AAI8AgAAAADAAAAAzwAAA8AA/AkAQAADwAE 8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAA8AAAFAAAADwAE8HIAAAASAArw CAAAAAI8AAAgAgAAUwAL8B4AAAB/AAAABACAANwKnwK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAA AIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAJ8CDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATw cgAAABIACvAIAAAAAzwAACACAABTAAvwHgAAAH8AAAAEAIAAgBafAr8BAAABAP8BAAABAAEDAwQA AAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AnwIPAA3wDAAAAAAAng8EAAAA AQAAAA8ABPBIAAAAEgAK8AgAAAABPAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHe vWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMz zADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEA AA8AAvCMAQAAAAEI8AgAAAADAAAAA0AAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA AAAAAAAAAAACAArwCAAAAABAAAAFAAAADwAE8HIAAAASAArwCAAAAAJAAAAgAgAAUwAL8B4AAAB/ AAAABACAAMQ5nwK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMML CAAAAAAAAAANAJ8CDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAA0AAACACAABT AAvwHgAAAH8AAAAEAIAAoACfAr8BAQABAP8BAQABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHw EAAAAAAAwwsIAAAAAQAAAA4AnwIPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAAB QAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDv AxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAMAEI8AgAAAADAAAA A0wAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABMAAAF AAAADwAE8HIAAAASAArwCAAAAAJMAAAgAgAAUwAL8B4AAAB/AAAABACAAICTnwK/AQAAAQD/AQAA AQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAJ8CDwAN8AwAAAAA AJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAA0wAACACAABTAAvwHgAAAH8AAAAEAIAAmIOfAr8B AQABAP8BAQABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AnwIP AA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABTAAAAAwAAIMAC/AwAAAAgQEAAAAI gwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAA AICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACA AAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAUAEI8AgAAAADAAAAA1QAAA8AA/AkAQAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABUAAAFAAAADwAE8HIAAAASAArwCAAAAAJU AAAgAgAAUwAL8B4AAAB/AAAABACAAESBaAK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQ FFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAGgCDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIA CvAIAAAAA1QAACACAABTAAvwHgAAAH8AAAAEAIAAQLNoAr8BAQABAP8BAQABAAEDAwQAAAAAEPAI AAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AaAIPAA3wDAAAAAAAng8EAAAAAQAAAA8A BPBIAAAAEgAK8AgAAAABVAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8A srKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCM AQAAEAEI8AgAAAADAAAAA0QAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAABEAAAFAAAADwAE8HIAAAASAArwCAAAAAJEAAAgAgAAUwAL8B4AAAB/AAAABACA AEB9nwK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAA AAANAJ8CDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAA0QAACACAABTAAvwHgAA AH8AAAAEAIAAEHCfAr8BAQABAP8BAQABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAA wwsIAAAAAQAAAA4AnwIPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABRAAAAAwA AIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEA EADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAAB AAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAIAEI8AgAAAADAAAAA0gAAA8A A/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABIAAAFAAAADwAE 8HIAAAASAArwCAAAAAJIAAAgAgAAUwAL8B4AAAB/AAAABACAALiOnwK/AQAAAQD/AQAAAQABAwIE AAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAJ8CDwAN8AwAAAAAAJ4PBAAA AAAAAAAPAATwcgAAABIACvAIAAAAA0gAACACAABTAAvwHgAAAH8AAAAEAIAAIKGfAr8BAQABAP8B AQABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AnwIPAA3wDAAA AAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABSAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI kwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAA AAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcA AAAPAAwElAEAAA8AAvCMAQAAQAAI8AgAAAADAAAAAxAAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAA AAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAQAAAFAAAADwAE8HIAAAASAArwCAAAAAIQAAAgAgAA UwAL8B4AAAB/AAAABACAAHR44wG/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR 8BAAAAAAAMMLCAAAAAAAAAANAOMBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAA AxAAACACAABTAAvwHgAAAH8AAAAEAIAAMOi5AL8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASw AdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AuQAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAA EgAK8AgAAAABEAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEA AAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAAAA chdUAAAAAQBQAAAAAAD8FAAAoB0AAHsgAABPPQAABwDgAGciAABTJAAAPyYAACsoAAAXKgAAAywA AO8tAADbLwAAxzEAALMzAACfNQAAizcAAHc5AABjOwAAAAD1DxwAAAAMAQAAnAoAAwAAAAA7PwAA AQAAABQAAAAHAHMADwDoA8cUAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAA AAAAAQAAAAAAAAEPAPIDFgEAAC8AyA8MUExFIE9wZW4gSXNzdWVzAEAAAABXaGF0IGFyZSB0aGUg cmFtaWZpY2F0aW9ucyBvZiBtaXhpbmcgcHJlczosIGltOiwgYW5kIHNpcDogVVJMcz8AOgAAAFNo b3VsZCB3ZSBoYXZlIGEgbWVzc2FnZSBzZXNzaW9uIGJvdW5kZWQgd2l0aCBJTlZJVEUvQllFPwAp AAAASXMgUkVHSVNURVIgdGhlIHJpZ2h0IFBVQkxJU0ggbWVjaGFuaXNtPwAOAAAAQXV0aG9yaXph dGlvbgAhAAAARG8gd2Ugd2FudCB0byByYXRlIGxpbWl0IE5PVElGWT8APQAAAElzIHRoZSBsb3dl c3QgY29tbW9uIGRlbm9taW5hdG9yIG1lc3NhZ2UvY3BpbSBvciB0ZXh0L3BsYWluPwAmAAAAQ2Fu IHdlIGNvbnZlcnQgc2lwIFVSTHMgdG8gcHJlczogVVJMcwBKAAAARG8gd2UgYWNjZXB0IGFsbCBO T1RJRllzIG9yIGp1c3QgdGhlIG9uZSBtYXRjaGluZyB0aGUgMnh4IHRvIGEgU1VCU0NSSUJFPwAu AAAAV2hhdCBkb2VzIGEgYm9keSBpbiBhIDIwMCBPSyB0byBNRVNTQUdFIG1lYW4/AEAAAABIb3cg ZG8geW91IHN5bnRoZXNpemUgYSBwcmVzZW5jZSBkb2N1bWVudCBmcm9tIHJlZ2lzdGVyZWQgZGF0 YT8AJAAAAE1pZ3JhdGlvbiBpbnRlcmFjdHMgYmFkbHkgd2l0aCBSUi9SADoAAABDYW4gd2UgcmVk dWNlIHRoZSBzdGF0ZSBhIHNpcC9jcGltIGdhdGV3YXkgbXVzdCBtYWludGFpbj8AMwAAAERvZXMg aXQgbWFrZSBzZW5zZSB0byBoYXZlIGEgTUVTU0FHRSB3aXRoIG5vIGJvZHk/ADUAAABJcyB1c2Ug b2YgdGhlIEFjY2VwdCBoZWFkZXIgd2l0aCBtZXNzYWdlL2NwaW0gY2xlYXI/ABkAAABNZXJnaW5n IG9mIFByZXNlbmNlIERhdGEAFgAAAE90aGVyIElNIGRyYWZ0IGlzc3VlcwAMEAAABgAAAB4AAAAL AAAA9g8gAAAAFAAAAF/AkePrugAACAD0AwMAuQByanNwYXJrcwgAAAByAGoAcwBwAGEAcgBrAHMA AAB5AgAAwQIAAEZvbnRzIFVzZWQAAwAAAAEAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAA AQAAAB4AAAANAAAAU2xpAAAtAQQABAAAAC0BAQAHAAAAGwS5AHkDQABIAAQAAAAtAQIABAAAAC0B AAAFAAAACQIAAAACBQAAABQCAAAAAAcAAAACAAAABAAAAAMAAAAEAAAABAAAAAQAAAAAAAAABAAA AAYAAAAEAAAABwAAAAQAAAAIAAAABAAAAAkAAAAEAAAACgAAAAQAAAALAAAABAAAAAwAAAAEAAAA AAAAAAQAAAAOAAAABAAAAA8AAAAEAAAAAAAAAAQAAAARAAAABAAAABIAAAAEAAAAEwAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAYwAL8CQAAACBAQQAAAiDAQAA AAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAA AAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHewEAAB8AFAQcAAAAAAAVBBQAAAC6HXXs AMqaOzJOzckAypo7AQEAAQ8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEEAAABkAAAAQQAAAGQA AAB2xwswCAAAAAAAAABw2hIAAAAAAAAAAACm////4P7//wEAAABwAPsDCAAAAAAAAABwCAAAcAD7 AwgAAAABAAAAQAsAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAAYPMNMCzeEgAAAAAA 4EK5AAAAAAAAAAAAAAAAAAAAAAAAARIAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAABg 8w0wLN4SAAAAAADgQrkAAAAAAAAAAAAAAAAAAAAAAAABEgAfAP8DFAAAAAIAAAQMAAAAAAAAAAAA AAACAAAAHwAIBDwAAAAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAACc2hIA2fQNMCzeEgABAAAAAAAA AAAAAAAAAAAAAAAAAAAAEgA/ANkPDAAAAAAA2g8EAAAAAAAlAA8A8A8MEQAAAADzAxQAAAADAAAA AAAAAAAAAAAAAQAAAAAAAAAA8wMUAAAADgAAAAAAAAACAAAACwEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPOQAAAFNob3VsZCB3ZSBoYXZlIGEgbWVzc2FnZSBzZXNzaW9uIGJvdW5kZWQgd2l0aCBJTlZJ VEUvQllFPwAAqg8SAAAAOQAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACgD0gBAABVAHMA ZQBmAHUAbAAgAGYAbwByACAAYwBoAGEAdAAgABMgIAByAGUAdQBzAGUAcwAgAGYAaQBuAGQALQBt AGUAIABvAGYAIABJAE4AVgBJAFQARQANAEQAbwBlAHMAbgAZIHQAIABuAGUAYwBlAHMAcwBhAHIA aQBsAHkAIABoAGEAdgBlACAAdABvACAAYgBlACAAYQBuACAAUgBUAFAAIABzAGUAcwBzAGkAbwBu AA0ATQB1AHMAdAAgAHMAdABpAGwAbAAgAHQAcgBhAG4AcwBpAHQAIABDAFAASQBNACAAYgBvAHUA bgBkAGEAcgB5AA0AUwBoAG8AdQBsAGQAIABzAHQAaQBsAGwAIABiAGUAIABhAGIAbABlACAAdABv ACAAcwBlAG4AZAAgAGIAYQByAGUAIABNAEUAUwBTAEEARwBFAHMAAACqDxoAAACcAAAAAAAAAAgA AAABAAAAAwABAAAAAAAAAAAA8wMUAAAAEwAAAAAAAAACAAAADgEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPKAAAAElzIFJFR0lTVEVSIHRoZSByaWdodCBQVUJMSVNIIG1lY2hhbmlzbT8AAKoPEgAAACgA AAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA9kAAAARGlzcG9zaXRpb24gb2YgYm9kaWVz IGluIFJFR0lTVEVSIGlzIHByb2JsZW1hdGljLg1NYXkgYWxzbyBuZWVkIHB1Ymxpc2ggbWVjaGFu aXNtIGZvciBhdXRob3JpemF0aW9uLgAAoQ8UAAAAZQAAAAAAAAAAAGUAAAAAAAIAHAAAAPMDFAAA ABQAAAAAAAAAAgAAAA8BAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABBdXRob3JpemF0aW9uEACf DwQAAAABAAAAAACoD7QAAABDYW4gYmUgYWRkcmVzc2VkIHNlcGFyYXRlbHkgZnJvbSByZXN0IG9m IHdvcmsNQ291bGQgYmUgYXBwbGljYWJsZSB0byBtb3JlIHRoYW4gU0lNUExFDVByb2JsZW1zIHdp dGggUUFVVEgNQ291bGQgdXNlIHN1YnNjcmlwdGlvbiB0byBzdWJzY3JpcHRpb24gc3RhdGUgKGFz IGEgc2VwYXJhdGUgZXZlbnQgcGFja2FnZSkAAKEPFAAAALUAAAAAAAAAAAC1AAAAAAACABwAAADz AxQAAAAEAAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAARG8gd2Ugd2FudCB0 byByYXRlIGxpbWl0IE5PVElGWT8QAJ8PBAAAAAEAAAAAAKgPegAAAHNpcC1ldmVudHMgcHVzaGVk IHRoaXMgb3V0IHRvIGluZGl2aWR1YWwgcGFja2FnZXMNSGVscHMgd2l0aCBjb25nZXN0aW9uIGNv bnRyb2wNRG8gd2UgbmVnb3RpYXRlIHRoZSByYXRlIGR1cmluZyBzdWJzY3JpYmU/AADzAxQAAAAM AAAAAAAAAAIAAAAJAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA88AAAASXMgdGhlIGxvd2VzdCBjb21t b24gZGVub21pbmF0b3IgbWVzc2FnZS9jcGltIG9yIHRleHQvcGxhaW4/AACqDyQAAAApAAAAAAAA AAUAAAABAAAAAwAOAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPaAAAAG1lc3NhZ2Uv Y3BpbSBpcyByZXF1aXJlZCBmb3IgZS1lIGFjcm9zcyBhIGNwaW0gYm91bmRhcnkNU29tZSBhZ2Vu dHMgbWF5IG5vdCBjYXJlIGFib3V0IGVuZC1lbmQgc2VjdXJpdHkgAACqDywAAAAIAAAAAAAAAAUA AAABAAAAAwAdAAAAAAAAAAUAAAABAAAAAwA6AAAAAAAAAAAA8wMUAAAACAAAAAAAAAACAAAABQEA AAAAAAAAAJ8PBAAAAAAAAAAAAKgPJQAAAENhbiB3ZSBjb252ZXJ0IHNpcCBVUkxzIHRvIHByZXM6 IFVSTHMAAKoPEgAAACUAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA+XAAAASWYgd2Ug aGF2ZSBzcGVjaWFsaXplZCBhIHByZXM6IFVSTCB0byBhIHNpcDogVVJMIGJlZm9yZSByZWFjaGlu ZyBhIGNwaW0gZ2F0ZXdheSwgY2FuIHdlIHJlbGlhYmx5IGNvbnZlcnQgYmFjayB0byBhIG1lYW5p bmdmdWwgcHJlczogVVJMIGF0IHRoZSBnYXRld2F5PwAAqg8aAAAAQwAAAAAAAAAFAAAAAQAAAAMA UAAAAAAAAAAAAPMDFAAAAAcAAAAAAAAAAgAAAAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDyMAAABN aWdyYXRpb24gaW50ZXJhY3RzIGJhZGx5IHdpdGggUlIvUgAAqg8SAAAAIwAAAAAAAAABAAAAAQAA AAAAEACfDwQAAAABAAAAAACoD/kAAABNaWdyYXRpb24gaXMgdGhlIHRyYW5zZmVyIG9mIE5PVElG WSByZXNwb25zaWJpbGl0eSBmcm9tIGEgcHJlc2VuY2Ugc2VydmVyIHRvIGEgUEEgd2l0aG91dCBz cGVjaWFsIGJlaGF2aW9yIG9uIHRoZSBwYXJ0IG9mIHRoZSBTdWJzY3JpYmVyLg1EbyB3ZSBkaXNh bGxvdyBNaWdyYXRpb24gb3IgZG8gd2UgbWFrZSBSUi9Db250YWN0IGJlaGF2aW9yIHNwZWNpYWwg Zm9yIFNVQlNDUklCRT8NQXJlIHRoZXJlIG90aGVyIGFsdGVybmF0aXZlcz8AAKEPFAAAAPoAAAAA AAAQAABaAPoAAAAAAAAAAACqDxIAAAD5AAAAAAAAAAEAAAABAAAAAAAAAPMDFAAAAAkAAAAAAAAA AgAAAAYBAAAAAAAAAACfDwQAAAAAAAAAAACoDzkAAABDYW4gd2UgcmVkdWNlIHRoZSBzdGF0ZSBh IHNpcC9jcGltIGdhdGV3YXkgbXVzdCBtYWludGFpbj8AAKoPJAAAAB4AAAAAAAAABQAAAAEAAAAD ABYAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAoA8OAQAAYwBwAGkAbQAgAGQAbwBlAHMA bgAZIHQAIAByAGUAZgBsAGUAYwB0ACAAdABoAGUAIABjAGEAbABsAC0AbABlAGcAIABzAGUAbQBh AG4AdABpAGMALgANAE4AbwAgAHMAdQBjAGgAIAB0AGgAaQBuAGcAIABhAHMAIABjAHAAaQBtACAA bwBuACAAdABoAGUAIAB3AGkAcgBlACAAEyAgAG0AYQB5ACAAYgBlACAAYQBiAGwAZQAgAHQAbwAg AHQAcgBhAG4AcwBsAGEAdABlACAAcwB0AGEAdABlACAAdABvACAAdABoAGUAIABvAHQAaABlAHIA IABwAHIAbwB0AG8AYwBvAGwAcwAuACAAAACqDyQAAAAEAAAAAQAAAAMAOQAAAAAAAAAFAAAAAQAA AAMARgAAAAAAAAAAAPMDFAAAAAoAAAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDz8A AABIb3cgZG8geW91IHN5bnRoZXNpemUgYSBwcmVzZW5jZSBkb2N1bWVudCBmcm9tIHJlZ2lzdGVy ZWQgZGF0YT8AAKoPEgAAAD8AAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA9YAAAAVGhp cyBpcyBvbmx5IG9uZSB3YXkgdG8gY3JlYXRlIGEgcHJlc2VuY2UgZG9jdW1lbnQsIGJ1dCBpdCBp cyBpbXBvcnRhbnQgYW5kIG5vdCB0cml2aWFsLgAA8wMUAAAACwAAAAAAAAACAAAABwEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPMgAAAERvZXMgaXQgbWFrZSBzZW5zZSB0byBoYXZlIGEgTUVTU0FHRSB3 aXRoIG5vIGJvZHk/AACqDxIAAAAyAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPJgAA AEN1cnJlbnQgdGV4dCBhbGxvd3MgYSBib2RpbGVzcyBtZXNzYWdlAADzAxQAAAANAAAAAAAAAAIA AAAKAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA80AAAASXMgdXNlIG9mIHRoZSBBY2NlcHQgaGVhZGVy IHdpdGggbWVzc2FnZS9jcGltIGNsZWFyPwAAqg8kAAAAKQAAAAAAAAAFAAAAAQAAAAMABgAAAAAA AAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD0cAAABBY2NlcHQgaGVhZGVyIG5lZWRzIHRvIGxp c3QgdGhlIGVtYmVkZGVkIG1pbWUgdHlwZXMgdGhhdCBhcmUgYWNjZXB0YWJsZQAA8wMUAAAADwAA AAAAAAACAAAADAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPLQAAAFdoYXQgZG9lcyBhIGJvZHkgaW4g YSAyMDAgT0sgdG8gTUVTU0FHRSBtZWFuPwAAqg8SAAAALQAAAAAAAAABAAAAAQAAAAAAEACfDwQA AAABAAAAAACoD1cAAABDdXJyZW50IHNwZWMgYWxsb3dzIGl0DUlzIHRoaXMgYSByZXBseSBtZXNz YWdlPyBXb3VsZCBpdCBoYXZlIHRvIGNyb3NzIGEgQ1BJTSBib3VuZGFyeT8AAKoPEgAAAFcAAAAA AAAAAQAAAAEAAAAAAAAA8wMUAAAABQAAAAAAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgP GAAAAE1lcmdpbmcgb2YgUHJlc2VuY2UgRGF0YQAAqg8SAAAAGAAAAAAAAAABAAAAAQAAAAAAEACf DwQAAAABAAAAAACgDzIBAABEAGkAcwBjAHUAcwBzAGkAbwBuACAAbwBmACAAbQBlAHIAZwBpAG4A ZwAgAHAAcgBlAHMAZQBuAGMAZQAgAGQAYQB0AGEAIABmAHIAbwBtACAAbQB1AGwAdABpAHAAbABl ACAAVQBBAHMAIABoAGEAcwAgAGIAZQBlAG4AIAByAGUAbQBvAHYAZQBkACAAZgByAG8AbQAgAHQA aABlACAAZAByAGEAZgB0AC4AIABQAHIAbwBiAGwAZQBtAD8ADQBQAHIAbwBwAG8AcwBhAGwAOgAg AEQAbwBuABkgdAAgAG4AZQBlAGQAIAB0AG8AIABhAGQAZAByAGUAcwBzACAAdABoAGkAcwAgAHAA cgBvAGIAbABlAG0AIABpAG0AbQBlAGQAaQBhAHQAZQBsAHkALgAAAKoPGgAAADIAAAAAAAAABAAA AAEAAAADAGQAAAAAAAAAAADzAxQAAAARAAAAAAAAAAIAAAAQAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8VAAAAT3RoZXIgSU0gZHJhZnQgaXNzdWVzEACfDwQAAAABAAAAAACoDx4AAABDb25nZXN0aW9u IGNvbnRyb2wNTWFwIHRvIENQSU0AAOoDAAAAAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAA AACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAEAEI8AgAAAADAAAAA0QAAA8AA/AkAQAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABEAAAFAAAADwAE8HIAAAASAArwCAAA AAJEAAAgAgAAUwAL8B4AAAB/AAAABACAAEB9nwK/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIAB sAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAJ8CDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAA ABIACvAIAAAAA0QAACACAABTAAvwHgAAAH8AAAAEAIAAEHCfAr8BAAABAP8BAAABAAEDAwQAAAAA EPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AnwIPAA3wDAAAAAAAng8EAAAAAQAA AA8ABPBIAAAAEgAK8AgAAAABRAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADM zP8AsrKyAAAAchcQAAAAAQAQAH5eAAATABAA13MAAAAA9Q8cAAAADgEAAJwKAANaXgAAw3UAAAEA AAAUAAAAAQBzAA8A6ANRFQAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAA AAEAAAAAAAABDwDyAxYBAAAvAMgPDAAAADAA0g8EAAAAAQAAAA8A1QdMAAAAAAC3D0QAAABBAHIA aQBhAGwAAAAAAAAAcNoSAFDaEgC4OLkALN4SAPRBuQB82hIAZNoSAHbHCzAIAAAAAAAAAHzaEgAo 3Q0wAFgGIgAApA8KAAAAgABgAAAA/////wAApQ8MAAAAAAAACC4AAAAHAAAAAACpDwoAAAAHAAAA AgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAAHAAAA///v AAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAF AACABIAEAAAAAA8ACwQkAQAADwAA8BwBAAAAAAbw0AAAAARgAAAZAAAAMwAAABAAAAABAAAABwAA AAIAAAAEAAAAAwAAAAQAAAAEAAAABAAAAAAAAAAEAAAABgAAAAQAAAAHAAAABAAAAAgAAAAEAAAA CQAAAAQAAAAKAAAABAAAAAsAAAAEAAAADAAAAAQAAAAAAAAABAAAAA4AAAAEAAAADwAAAAQAAAAA AAAABAAAABEAAAAEAAAAEgAAAAQAAAATAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAABjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAA CEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACA AAAAAA8A0Ad7AQAAHwAUBBwAAAAAABUEFAAAALoddewAypo7Mk7NyQDKmjsBAQABDwD6A2cAAAAA AP4DAwAAAAABAAAA/QM0AAAAQQAAAGQAAABBAAAAZAAAAHbHCzAIAAAAAAAAAHDaEgAAAAAAAAAA AKb////g/v//AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwAHBDwAAAAAAP0D NAAAACEAAABkAAAAIQAAAGQAAABg8w0wLN4SAAAAAADgQrkAAAAAAAAAAAAAAAAAAAAAAAABEgAf ABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAGDzDTAs3hIAAAAAAOBCuQAAAAAAAAAAAAAA AAAAAAAAAAESAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfAAgEPAAAAAAA/QM0AAAAQgAA AGQAAABCAAAAZAAAAJzaEgDZ9A0wLN4SAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAASAD8A2Q8MAAAA AADaDwQAAAAAACUADwDwDwwRAAAAAPMDFAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAADzAxQAAAAO AAAAAAAAAAIAAAALAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA85AAAAU2hvdWxkIHdlIGhhdmUgYSBt ZXNzYWdlIHNlc3Npb24gYm91bmRlZCB3aXRoIElOVklURS9CWUU/AACqDxIAAAA5AAAAAAAAAAEA AAABAAAAAAAQAJ8PBAAAAAEAAAAAAKAPSAEAAFUAcwBlAGYAdQBsACAAZgBvAHIAIABjAGgAYQB0 ACAAEyAgAHIAZQB1AHMAZQBzACAAZgBpAG4AZAAtAG0AZQAgAG8AZgAgAEkATgBWAEkAVABFAA0A RABvAGUAcwBuABkgdAAgAG4AZQBjAGUAcwBzAGEAcgBpAGwAeQAgAGgAYQB2AGUAIAB0AG8AIABi AGUAIABhAG4AIABSAFQAUAAgAHMAZQBzAHMAaQBvAG4ADQBNAHUAcwB0ACAAcwB0AGkAbABsACAA dAByAGEAbgBzAGkAdAAgAEMAUABJAE0AIABiAG8AdQBuAGQAYQByAHkADQBTAGgAbwB1AGwAZAAg AHMAdABpAGwAbAAgAGIAZQAgAGEAYgBsAGUAIAB0AG8AIABzAGUAbgBkACAAYgBhAHIAZQAgAE0A RQBTAFMAQQBHAEUAcwAAAKoPGgAAAJwAAAAAAAAACAAAAAEAAAADAAEAAAAAAAAAAADzAxQAAAAT AAAAAAAAAAIAAAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8oAAAASXMgUkVHSVNURVIgdGhlIHJp Z2h0IFBVQkxJU0ggbWVjaGFuaXNtPwAAqg8SAAAAKAAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAAB AAAAAACoD2QAAABEaXNwb3NpdGlvbiBvZiBib2RpZXMgaW4gUkVHSVNURVIgaXMgcHJvYmxlbWF0 aWMuDU1heSBhbHNvIG5lZWQgcHVibGlzaCBtZWNoYW5pc20gZm9yIGF1dGhvcml6YXRpb24uAACh DxQAAABlAAAAAAAAAAAAZQAAAAAAAgAcAAAA8wMUAAAAFAAAAAAAAAACAAAADwEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPDQAAAEF1dGhvcml6YXRpb24QAJ8PBAAAAAEAAAAAAKgPtAAAAENhbiBiZSBh ZGRyZXNzZWQgc2VwYXJhdGVseSBmcm9tIHJlc3Qgb2Ygd29yaw1Db3VsZCBiZSBhcHBsaWNhYmxl IHRvIG1vcmUgdGhhbiBTSU1QTEUNUHJvYmxlbXMgd2l0aCBRQVVUSA1Db3VsZCB1c2Ugc3Vic2Ny aXB0aW9uIHRvIHN1YnNjcmlwdGlvbiBzdGF0ZSAoYXMgYSBzZXBhcmF0ZSBldmVudCBwYWNrYWdl KQAAoQ8UAAAAtQAAAAAAAAAAALUAAAAAAAIAHAAAAPMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAA AACfDwQAAAAAAAAAAACoDyAAAABEbyB3ZSB3YW50IHRvIHJhdGUgbGltaXQgTk9USUZZPxAAnw8E AAAAAQAAAAAAqA96AAAAc2lwLWV2ZW50cyBwdXNoZWQgdGhpcyBvdXQgdG8gaW5kaXZpZHVhbCBw YWNrYWdlcw1IZWxwcyB3aXRoIGNvbmdlc3Rpb24gY29udHJvbA1EbyB3ZSBuZWdvdGlhdGUgdGhl IHJhdGUgZHVyaW5nIHN1YnNjcmliZT8AAPMDFAAAAAwAAAAAAAAAAgAAAAkBAAAAAAAAAACfDwQA AAAAAAAAAACoDzwAAABJcyB0aGUgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBtZXNzYWdlL2Nw aW0gb3IgdGV4dC9wbGFpbj8AAKoPJAAAACkAAAAAAAAABQAAAAEAAAADAA4AAAAAAAAAAQAAAAEA AAAAABAAnw8EAAAAAQAAAAAAqA9oAAAAbWVzc2FnZS9jcGltIGlzIHJlcXVpcmVkIGZvciBlLWUg YWNyb3NzIGEgY3BpbSBib3VuZGFyeQ1Tb21lIGFnZW50cyBtYXkgbm90IGNhcmUgYWJvdXQgZW5k LWVuZCBzZWN1cml0eSAAAKoPLAAAAAgAAAAAAAAABQAAAAEAAAADAB0AAAAAAAAABQAAAAEAAAAD ADoAAAAAAAAAAADzAxQAAAAIAAAAAAAAAAIAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8lAAAA Q2FuIHdlIGNvbnZlcnQgc2lwIFVSTHMgdG8gcHJlczogVVJMcwAAqg8SAAAAJQAAAAAAAAABAAAA AQAAAAAAEACfDwQAAAABAAAAAACoD5cAAABJZiB3ZSBoYXZlIHNwZWNpYWxpemVkIGEgcHJlczog VVJMIHRvIGEgc2lwOiBVUkwgYmVmb3JlIHJlYWNoaW5nIGEgY3BpbSBnYXRld2F5LCBjYW4gd2Ug cmVsaWFibHkgY29udmVydCBiYWNrIHRvIGEgbWVhbmluZ2Z1bCBwcmVzOiBVUkwgYXQgdGhlIGdh dGV3YXk/AACqDxoAAABDAAAAAAAAAAUAAAABAAAAAwBQAAAAAAAAAAAA8wMUAAAADwAAAAAAAAAC AAAADAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPLQAAAFdoYXQgZG9lcyBhIGJvZHkgaW4gYSAyMDAg T0sgdG8gTUVTU0FHRSBtZWFuPwAAqg8SAAAALQAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAA AACoD1cAAABDdXJyZW50IHNwZWMgYWxsb3dzIGl0DUlzIHRoaXMgYSByZXBseSBtZXNzYWdlPyBX b3VsZCBpdCBoYXZlIHRvIGNyb3NzIGEgQ1BJTSBib3VuZGFyeT8AAKoPEgAAAFcAAAAAAAAAAQAA AAEAAAAAAAAA8wMUAAAACgAAAAAAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPPwAAAEhv dyBkbyB5b3Ugc3ludGhlc2l6ZSBhIHByZXNlbmNlIGRvY3VtZW50IGZyb20gcmVnaXN0ZXJlZCBk YXRhPwAAqg8SAAAAPwAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD1gAAABUaGlzIGlz IG9ubHkgb25lIHdheSB0byBjcmVhdGUgYSBwcmVzZW5jZSBkb2N1bWVudCwgYnV0IGl0IGlzIGlt cG9ydGFudCBhbmQgbm90IHRyaXZpYWwuAADzAxQAAAAHAAAAAAAAAAIAAAAEAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8jAAAATWlncmF0aW9uIGludGVyYWN0cyBiYWRseSB3aXRoIFJSL1IAAKoPEgAA ACMAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA/5AAAATWlncmF0aW9uIGlzIHRoZSB0 cmFuc2ZlciBvZiBOT1RJRlkgcmVzcG9uc2liaWxpdHkgZnJvbSBhIHByZXNlbmNlIHNlcnZlciB0 byBhIFBBIHdpdGhvdXQgc3BlY2lhbCBiZWhhdmlvciBvbiB0aGUgcGFydCBvZiB0aGUgU3Vic2Ny aWJlci4NRG8gd2UgZGlzYWxsb3cgTWlncmF0aW9uIG9yIGRvIHdlIG1ha2UgUlIvQ29udGFjdCBi ZWhhdmlvciBzcGVjaWFsIGZvciBTVUJTQ1JJQkU/DUFyZSB0aGVyZSBvdGhlciBhbHRlcm5hdGl2 ZXM/AAChDxQAAAD6AAAAAAAAEAAAWgD6AAAAAAAAAAAAqg8SAAAA+QAAAAAAAAABAAAAAQAAAAAA AADzAxQAAAAJAAAAAAAAAAIAAAAGAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA85AAAAQ2FuIHdlIHJl ZHVjZSB0aGUgc3RhdGUgYSBzaXAvY3BpbSBnYXRld2F5IG11c3QgbWFpbnRhaW4/AACqDyQAAAAe AAAAAAAAAAUAAAABAAAAAwAWAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKAPDgEAAGMA cABpAG0AIABkAG8AZQBzAG4AGSB0ACAAcgBlAGYAbABlAGMAdAAgAHQAaABlACAAYwBhAGwAbAAt AGwAZQBnACAAcwBlAG0AYQBuAHQAaQBjAC4ADQBOAG8AIABzAHUAYwBoACAAdABoAGkAbgBnACAA YQBzACAAYwBwAGkAbQAgAG8AbgAgAHQAaABlACAAdwBpAHIAZQAgABMgIABtAGEAeQAgAGIAZQAg AGEAYgBsAGUAIAB0AG8AIAB0AHIAYQBuAHMAbABhAHQAZQAgAHMAdABhAHQAZQAgAHQAbwAgAHQA aABlACAAbwB0AGgAZQByACAAcAByAG8AdABvAGMAbwBsAHMALgAgAAAAqg8kAAAABAAAAAEAAAAD ADkAAAAAAAAABQAAAAEAAAADAEYAAAAAAAAAAADzAxQAAAALAAAAAAAAAAIAAAAHAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8yAAAARG9lcyBpdCBtYWtlIHNlbnNlIHRvIGhhdmUgYSBNRVNTQUdFIHdp dGggbm8gYm9keT8AAKoPEgAAADIAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA8mAAAA Q3VycmVudCB0ZXh0IGFsbG93cyBhIGJvZGlsZXNzIG1lc3NhZ2UAAPMDFAAAAA0AAAAAAAAAAgAA AAoBAAAAAAAAAACfDwQAAAAAAAAAAACoDzQAAABJcyB1c2Ugb2YgdGhlIEFjY2VwdCBoZWFkZXIg d2l0aCBtZXNzYWdlL2NwaW0gY2xlYXI/AACqDyQAAAApAAAAAAAAAAUAAAABAAAAAwAGAAAAAAAA AAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPRwAAAEFjY2VwdCBoZWFkZXIgbmVlZHMgdG8gbGlz dCB0aGUgZW1iZWRkZWQgbWltZSB0eXBlcyB0aGF0IGFyZSBhY2NlcHRhYmxlAADzAxQAAAAFAAAA AAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8YAAAATWVyZ2luZyBvZiBQcmVzZW5jZSBE YXRhAACqDxIAAAAYAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKAPMgEAAEQAaQBzAGMA dQBzAHMAaQBvAG4AIABvAGYAIABtAGUAcgBnAGkAbgBnACAAcAByAGUAcwBlAG4AYwBlACAAZABh AHQAYQAgAGYAcgBvAG0AIABtAHUAbAB0AGkAcABsAGUAIABVAEEAcwAgAGgAYQBzACAAYgBlAGUA bgAgAHIAZQBtAG8AdgBlAGQAIABmAHIAbwBtACAAdABoAGUAIABkAHIAYQBmAHQALgAgAFAAcgBv AGIAbABlAG0APwANAFAAcgBvAHAAbwBzAGEAbAA6ACAARABvAG4AGSB0ACAAbgBlAGUAZAAgAHQA bwAgAGEAZABkAHIAZQBzAHMAIAB0AGgAaQBzACAAcAByAG8AYgBsAGUAbQAgAGkAbQBtAGUAZABp AGEAdABlAGwAeQAuAAAAqg8aAAAAMgAAAAAAAAAEAAAAAQAAAAMAZAAAAAAAAAAAAPMDFAAAABEA AAAAAAAAAgAAABABAAAAAAAAAACfDwQAAAAAAAAAAACoDxUAAABPdGhlciBJTSBkcmFmdCBpc3N1 ZXMQAJ8PBAAAAAEAAAAAAKgPHgAAAENvbmdlc3Rpb24gY29udHJvbA1NYXAgdG8gQ1BJTQAA6gMA AAAAAAByFwgAAAABABAA/3UAAAAA9Q8cAAAACAEAAJwKAAPbdQAAWIsAAAEAAAAUAAAACABzAA8A 6AN1FQAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDy AxYBAAAvAMgPDAAAADAA0g8EAAAAAQAAAA8A1QdMAAAAAAC3D0QAAABBAHIAaQBhAGwAAAAAAAAA AQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAP AAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0A AAAeAAAAHwAAADsAAAAhAAAA/v///yMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAA ACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAAFMAAAD9//// OgAAAP7///88AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABI AAAASQAAAEoAAAAiAAAA/v///00AAABOAAAATwAAAFAAAABRAAAAUgAAACAAAABUAAAAVQAAAFYA AABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAA AGUAAABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAA cwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAA/v////////////////////////////////////////9S AG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFgAFAf//////////AwAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAAAA0HfY+7LA AUwAAADAEQAAAAAAAEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFwAAADgAAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEBAAAA//////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAUAAAAAAABQAG8AdwBlAHIAUABvAGkA bgB0ACAARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAE AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ1gAAAAAAAAUA RABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAA AAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MgAAABQFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA MADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAEEAcgBpAGEAbAAAAAAAAABw2hIAUNoSALg4uQAs 3hIA9EG5AHzaEgBk2hIAdscLMAgAAAAAAAAAfNoSACjdDTAAWAYiAACkDwoAAACAAGAAAAD///// AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAA AGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACAB IAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBCQBAAAPAADwHAEA AAAABvDQAAAABGAAABkAAAAzAAAAEAAAAAEAAAAHAAAAAgAAAAQAAAADAAAABAAAAAQAAAAEAAAA AAAAAAQAAAAGAAAABAAAAAcAAAAEAAAACAAAAAQAAAAJAAAABAAAAAoAAAAEAAAACwAAAAQAAAAM AAAABAAAAAAAAAAEAAAADgAAAAQAAAAPAAAABAAAAAAAAAAEAAAAEQAAAAQAAAASAAAABAAAABMA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAGMAC/AkAAAAgQEE AAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQ HwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQB3sBAAAfABQEHAAAAAAAFQQU AAAAuh117ADKmjsyTs3JAMqaOwEBAAEPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABBAAAAZAAA AEEAAABkAAAAdscLMAgAAAAAAAAAcNoSAAAAAAAAAAAApv///+D+//8BAAAAcAD7AwgAAAAAAAAA cAgAAHAA+wMIAAAAAQAAAEALAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAGDzDTAs 3hIAAAAAAOBCuQAAAAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQA AABkAAAAYPMNMCzeEgAAAAAA4EK5AAAAAAAAAAAAAAAAAAAAAAAAARIAHwD/AxQAAAACAAAEDAAA AAAAAAAAAAAAAgAAAB8ACAQ8AAAAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAnNoSANn0DTAs3hIA AQAAAAAAAAAAAAAAAAAAAAAAAAAAABIADwDwD5YQAAAAAPMDFAAAAAMAAAAAAAAAAAAAAAABAAAA AAAAAADzAxQAAAAOAAAAAAAAAAIAAAALAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA85AAAAU2hvdWxk IHdlIGhhdmUgYSBtZXNzYWdlIHNlc3Npb24gYm91bmRlZCB3aXRoIElOVklURS9CWUU/AACqDxIA AAA5AAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKAPSAEAAFUAcwBlAGYAdQBsACAAZgBv AHIAIABjAGgAYQB0ACAAEyAgAHIAZQB1AHMAZQBzACAAZgBpAG4AZAAtAG0AZQAgAG8AZgAgAEkA TgBWAEkAVABFAA0ARABvAGUAcwBuABkgdAAgAG4AZQBjAGUAcwBzAGEAcgBpAGwAeQAgAGgAYQB2 AGUAIAB0AG8AIABiAGUAIABhAG4AIABSAFQAUAAgAHMAZQBzAHMAaQBvAG4ADQBNAHUAcwB0ACAA cwB0AGkAbABsACAAdAByAGEAbgBzAGkAdAAgAEMAUABJAE0AIABiAG8AdQBuAGQAYQByAHkADQBT AGgAbwB1AGwAZAAgAHMAdABpAGwAbAAgAGIAZQAgAGEAYgBsAGUAIAB0AG8AIABzAGUAbgBkACAA YgBhAHIAZQAgAE0ARQBTAFMAQQBHAEUAcwAAAKoPGgAAAJwAAAAAAAAACAAAAAEAAAADAAEAAAAA AAAAAADzAxQAAAAUAAAAAAAAAAIAAAAPAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8NAAAAQXV0aG9y aXphdGlvbhAAnw8EAAAAAQAAAAAAqA+0AAAAQ2FuIGJlIGFkZHJlc3NlZCBzZXBhcmF0ZWx5IGZy b20gcmVzdCBvZiB3b3JrDUNvdWxkIGJlIGFwcGxpY2FibGUgdG8gbW9yZSB0aGFuIFNJTVBMRQ1Q cm9ibGVtcyB3aXRoIFFBVVRIDUNvdWxkIHVzZSBzdWJzY3JpcHRpb24gdG8gc3Vic2NyaXB0aW9u IHN0YXRlIChhcyBhIHNlcGFyYXRlIGV2ZW50IHBhY2thZ2UpAAChDxQAAAC1AAAAAAAAAAAAtQAA AAAAAgAcAAAA8wMUAAAAEwAAAAAAAAACAAAADgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPKAAAAElz IFJFR0lTVEVSIHRoZSByaWdodCBQVUJMSVNIIG1lY2hhbmlzbT8AAKoPEgAAACgAAAAAAAAAAQAA AAEAAAAAABAAnw8EAAAAAQAAAAAAqg8KAAAAAQAAAAEAAAAAAAAA8wMUAAAABAAAAAAAAAACAAAA AQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAERvIHdlIHdhbnQgdG8gcmF0ZSBsaW1pdCBOT1RJ Rlk/EACfDwQAAAABAAAAAACoD3oAAABzaXAtZXZlbnRzIHB1c2hlZCB0aGlzIG91dCB0byBpbmRp dmlkdWFsIHBhY2thZ2VzDUhlbHBzIHdpdGggY29uZ2VzdGlvbiBjb250cm9sDURvIHdlIG5lZ290 aWF0ZSB0aGUgcmF0ZSBkdXJpbmcgc3Vic2NyaWJlPwAA8wMUAAAADAAAAAAAAAACAAAACQEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPPAAAAElzIHRoZSBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9yIG1l c3NhZ2UvY3BpbSBvciB0ZXh0L3BsYWluPwAAqg8kAAAAKQAAAAAAAAAFAAAAAQAAAAMADgAAAAAA AAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD2gAAABtZXNzYWdlL2NwaW0gaXMgcmVxdWlyZWQg Zm9yIGUtZSBhY3Jvc3MgYSBjcGltIGJvdW5kYXJ5DVNvbWUgYWdlbnRzIG1heSBub3QgY2FyZSBh Ym91dCBlbmQtZW5kIHNlY3VyaXR5IAAAqg8sAAAACAAAAAAAAAAFAAAAAQAAAAMAHQAAAAAAAAAF AAAAAQAAAAMAOgAAAAAAAAAAAPMDFAAAAAgAAAAAAAAAAgAAAAUBAAAAAAAAAACfDwQAAAAAAAAA AACoDyUAAABDYW4gd2UgY29udmVydCBzaXAgVVJMcyB0byBwcmVzOiBVUkxzAACqDxIAAAAlAAAA AAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPlwAAAElmIHdlIGhhdmUgc3BlY2lhbGl6ZWQg YSBwcmVzOiBVUkwgdG8gYSBzaXA6IFVSTCBiZWZvcmUgcmVhY2hpbmcgYSBjcGltIGdhdGV3YXks IGNhbiB3ZSByZWxpYWJseSBjb252ZXJ0IGJhY2sgdG8gYSBtZWFuaW5nZnVsIHByZXM6IFVSTCBh dCB0aGUgZ2F0ZXdheT8AAKoPGgAAAEMAAAAAAAAABQAAAAEAAAADAFAAAAAAAAAAAADzAxQAAAAH AAAAAAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8jAAAATWlncmF0aW9uIGludGVyYWN0 cyBiYWRseSB3aXRoIFJSL1IAAKoPEgAAACMAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAA qA/5AAAATWlncmF0aW9uIGlzIHRoZSB0cmFuc2ZlciBvZiBOT1RJRlkgcmVzcG9uc2liaWxpdHkg ZnJvbSBhIHByZXNlbmNlIHNlcnZlciB0byBhIFBBIHdpdGhvdXQgc3BlY2lhbCBiZWhhdmlvciBv biB0aGUgcGFydCBvZiB0aGUgU3Vic2NyaWJlci4NRG8gd2UgZGlzYWxsb3cgTWlncmF0aW9uIG9y IGRvIHdlIG1ha2UgUlIvQ29udGFjdCBiZWhhdmlvciBzcGVjaWFsIGZvciBTVUJTQ1JJQkU/DUFy ZSB0aGVyZSBvdGhlciBhbHRlcm5hdGl2ZXM/AAChDxQAAAD6AAAAAAAAEAAAWgD6AAAAAAAAAAAA qg8SAAAA+QAAAAAAAAABAAAAAQAAAAAAAADzAxQAAAAJAAAAAAAAAAIAAAAGAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA85AAAAQ2FuIHdlIHJlZHVjZSB0aGUgc3RhdGUgYSBzaXAvY3BpbSBnYXRld2F5 IG11c3QgbWFpbnRhaW4/AACqDyQAAAAeAAAAAAAAAAUAAAABAAAAAwAWAAAAAAAAAAEAAAABAAAA AAAQAJ8PBAAAAAEAAAAAAKAPDgEAAGMAcABpAG0AIABkAG8AZQBzAG4AGSB0ACAAcgBlAGYAbABl AGMAdAAgAHQAaABlACAAYwBhAGwAbAAtAGwAZQBnACAAcwBlAG0AYQBuAHQAaQBjAC4ADQBOAG8A IABzAHUAYwBoACAAdABoAGkAbgBnACAAYQBzACAAYwBwAGkAbQAgAG8AbgAgAHQAaABlACAAdwBp AHIAZQAgABMgIABtAGEAeQAgAGIAZQAgAGEAYgBsAGUAIAB0AG8AIAB0AHIAYQBuAHMAbABhAHQA ZQAgAHMAdABhAHQAZQAgAHQAbwAgAHQAaABlACAAbwB0AGgAZQByACAAcAByAG8AdABvAGMAbwBs AHMALgAgAAAAqg8kAAAABAAAAAEAAAADADkAAAAAAAAABQAAAAEAAAADAEYAAAAAAAAAAADzAxQA AAAKAAAAAAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8/AAAASG93IGRvIHlvdSBzeW50 aGVzaXplIGEgcHJlc2VuY2UgZG9jdW1lbnQgZnJvbSByZWdpc3RlcmVkIGRhdGE/AACqDxIAAAA/ AAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPWAAAAFRoaXMgaXMgb25seSBvbmUgd2F5 IHRvIGNyZWF0ZSBhIHByZXNlbmNlIGRvY3VtZW50LCBidXQgaXQgaXMgaW1wb3J0YW50IGFuZCBu b3QgdHJpdmlhbC4AAPMDFAAAAAsAAAAAAAAAAgAAAAcBAAAAAAAAAACfDwQAAAAAAAAAAACoDzIA AABEb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gaGF2ZSBhIE1FU1NBR0Ugd2l0aCBubyBib2R5PwAAqg8S AAAAMgAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoDyYAAABDdXJyZW50IHRleHQgYWxs b3dzIGEgYm9kaWxlc3MgbWVzc2FnZQAA8wMUAAAADQAAAAAAAAACAAAACgEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPNAAAAElzIHVzZSBvZiB0aGUgQWNjZXB0IGhlYWRlciB3aXRoIG1lc3NhZ2UvY3Bp bSBjbGVhcj8AAKoPJAAAACkAAAAAAAAABQAAAAEAAAADAAYAAAAAAAAAAQAAAAEAAAAAABAAnw8E AAAAAQAAAAAAqA9HAAAAQWNjZXB0IGhlYWRlciBuZWVkcyB0byBsaXN0IHRoZSBlbWJlZGRlZCBt aW1lIHR5cGVzIHRoYXQgYXJlIGFjY2VwdGFibGUAAPMDFAAAAA8AAAAAAAAAAgAAAAwBAAAAAAAA AACfDwQAAAAAAAAAAACoDy0AAABXaGF0IGRvZXMgYSBib2R5IGluIGEgMjAwIE9LIHRvIE1FU1NB R0UgbWVhbj8AAKoPEgAAAC0AAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA9XAAAAQ3Vy cmVudCBzcGVjIGFsbG93cyBpdA1JcyB0aGlzIGEgcmVwbHkgbWVzc2FnZT8gV291bGQgaXQgaGF2 ZSB0byBjcm9zcyBhIENQSU0gYm91bmRhcnk/AACqDxIAAABXAAAAAAAAAAEAAAABAAAAAAAAAPMD FAAAAAUAAAAAAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDxgAAABNZXJnaW5nIG9mIFBy ZXNlbmNlIERhdGEAAKoPEgAAABgAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAoA8yAQAA RABpAHMAYwB1AHMAcwBpAG8AbgAgAG8AZgAgAG0AZQByAGcAaQBuAGcAIABwAHIAZQBzAGUAbgBj AGUAIABkAGEAdABhACAAZgByAG8AbQAgAG0AdQBsAHQAaQBwAGwAZQAgAFUAQQBzACAAaABhAHMA IABiAGUAZQBuACAAcgBlAG0AbwB2AGUAZAAgAGYAcgBvAG0AIAB0AGgAZQAgAGQAcgBhAGYAdAAu ACAAUAByAG8AYgBsAGUAbQA/AA0AUAByAG8AcABvAHMAYQBsADoAIABEAG8AbgAZIHQAIABuAGUA ZQBkACAAdABvACAAYQBkAGQAcgBlAHMAcwAgAHQAaABpAHMAIABwAHIAbwBiAGwAZQBtACAAaQBt AG0AZQBkAGkAYQB0AGUAbAB5AC4AAACqDxoAAAAyAAAAAAAAAAQAAAABAAAAAwBkAAAAAAAAAAAA 8wMUAAAAEQAAAAAAAAACAAAAEAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFQAAAE90aGVyIElNIGRy YWZ0IGlzc3VlcxAAnw8EAAAAAQAAAAAAqA8eAAAAQ29uZ2VzdGlvbiBjb250cm9sDU1hcCB0byBD UElNAADqAwAAAAAPAO4D5AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAADwAMBJQB AAAPAALwjAEAAOAACPAIAAAAAwAAAAM4AAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAA AAAAAAAAAAAAAgAK8AgAAAAAOAAABQAAAA8ABPByAAAAEgAK8AgAAAACOAAAIAIAAFMAC/AeAAAA fwAAAAQAgAAo7mgCvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADD CwgAAAAAAAAADQBoAg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAM4AAAgAgAA UwAL8B4AAAB/AAAABACAAGzeaAK/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAHAFsAHQFAAPDwAR 8BAAAAAAAMMLCAAAAAEAAAAOAGgCDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAA ATgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAA AD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D5AEAAAIA 7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAADwAMBJQBAAAPAALwjAEAACABCPAIAAAAAwAA AANIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAASAAA BQAAAA8ABPByAAAAEgAK8AgAAAACSAAAIAIAAFMAC/AeAAAAfwAAAAQAgAC4jp8CvwEAAAEA/wEA AAEAAQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQCfAg8ADfAMAAAA AACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAANIAAAgAgAAUwAL8B4AAAB/AAAABACAACChnwK/ AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJ8C DwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAUgAAAAMAACDAAvwMAAAAIEBAAAA CIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAA AACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D5AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAA gAAAAAAHAAAADwAMBJQBAAAPAALwjAEAABABCPAIAAAAAwAAAANEAAAPAAPwJAEAAA8ABPAoAAAA AQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAARAAABQAAAA8ABPByAAAAEgAK8AgAAAAC RAAAIAIAAFMAC/AeAAAAfwAAAAQAgABAfZ8CvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACAAbAB 0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQCfAg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAAS AArwCAAAAANEAAAgAgAAUwAL8B4AAAB/AAAABACAABBwnwK/AQEAAQD/AQEAAQABAwMEAAAAABDw CAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJ8CDwAN8AwAAAAAAJ4PBAAAAAEAAAAP AATwSAAAABIACvAIAAAAAUQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ ALKysgAPAO4D5AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAADwAMBJQBAAAPAALw jAEAAJAACPAIAAAAAwAAAAMkAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAA AAAAAgAK8AgAAAAAJAAABQAAAA8ABPByAAAAEgAK8AgAAAACJAAAIAIAAFMAC/AeAAAAfwAAAAQA gADkaWgCvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAA AAAADQBoAg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMkAAAgAgAAUwAL8B4A AAB/AAAABACAAERuaAK/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAA AMMLCAAAAAEAAAAOAGgCDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAASQAAAAM AACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQAB ABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D5AEAAAIA7wMYAAAA AQAAAA0OAAAAAAAAAAAAgAAAAAAHAAAADwAMBJQBAAAPAALwjAEAADABCPAIAAAAAwAAAANMAAAP AAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAATAAABQAAAA8A BPByAAAAEgAK8AgAAAACTAAAIAIAAFMAC/AeAAAAfwAAAAQAgACAk58CvwEAAAEA/wEAAAEAAQMC BAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQCfAg8ADfAMAAAAAACeDwQA AAAAAAAADwAE8HIAAAASAArwCAAAAANMAAAgAgAAUwAL8B4AAAB/AAAABACAAJiDnwK/AQAAAQD/ AQAAAQABAwMEAAAAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAJ8CDwAN8AwA AAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAUwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAA CJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAA AAAAAADMmQAzM8wAzMz/ALKysgAAAHIXLAAAAAEAEAC7PwAACwAQAE5aAAAOABAAilQAABEAEAA6 XAAAEwAgAGJYAAB2VgAAAAD1DxwAAAAPAQAAnAoAA5c/AAAmXgAAAQAAABQAAAABAHMADwDoA1EV AAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPIDFgEA AC8AyA8MAAAAMADSDwQAAAABAAAADwDVB0wAAAAAALcPRAAAAEEAcgBpAGEAbAAAAAAAAABw2hIA UNoSALg4uQAs3hIA9EG5AHzaEgBk2hIAdscLMAgAAAAAAAAAfNoSACjdDTAAWAYiAACkDwoAAACA AGAAAAD/////AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA //0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xgAAAAA AQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBCQB AAAPAADwHAEAAAAABvDQAAAABGAAABkAAAAzAAAAEAAAAAEAAAABAAAAAgAAAAMAAAAEAAAABQAA AAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA FAAAABUAAAD+/////v////7///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////zMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAA AD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEYAAAD/////FgAAAP////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////7/AAAFAAIAAAAAAAAAAAAAAAAA AAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAADAFAAALAAAAAQAAAGAAAAACAAAAaAAAAAQAAACw AAAACAAAAMQAAAAJAAAA2AAAABIAAADkAAAACgAAAAQBAAAMAAAAEAEAAA0AAAAcAQAADwAAACgB AAARAAAAMAEAAAIAAADkBAAAHgAAAEAAAABXaGF0IGFyZSB0aGUgcmFtaWZpY2F0aW9ucyBvZiBt aXhpbmcgcHJlczosIGltOiwgYW5kIHNpcDogVVJMcz8AHgAAAAkAAAByanNwYXJrcwB0aGUeAAAA CQAAAHJqc3BhcmtzAHRoZR4AAAACAAAANgBzcB4AAAAVAAAATWljcm9zb2Z0IFBvd2VyUG9pbnQA dGlvQAAAAADLKT2bAAAAQAAAALBzdoGOscABQAAAAMCNaNj7ssABAwAAANwBAABHAAAA+AMAAP// //8DAAAACACJEGcMAAABAAkAAAP0AQAABgAiAAAAAAARAAAAJgYPABgA/////wAAEAAAAAAAAAAA AMADAADQAgAACQAAACYGDwAIAP////8CAAAAFwAAACYGDwAjAP////8EABsAVE5QUBQAWAG3ADIA AAD//08AFAAAAE0AaQBhAAoAAAAmBg8ACgBUTlBQAAACAPQDCQAAACYGDwAIAP////8DAAAADwAA ACYGDwAUAFROUFAEAAwAAQAAAAEAAAAAAAAABQAAAAsCAAAAAAUAAAAMAtACwAMFAAAABAENAAAA BwAAAPwCAAD///8AAAAEAAAALQEAAAgAAAD6AgUAAQAAAAAAAAAEAAAALQEBAAQAAAAtAQAACQAA AB0GIQDwANACwAMAAAAABAAAAC0BAAAHAAAA/AIAAP///wAAAAQAAAAtAQIABAAAAPABAAAIAAAA +gIAAAAAAAAAAAAABAAAAC0BAAAQAAAAJgYPABYA/////wAARwAAAI8CAAARAQAAwQIAAAgAAAAm Bg8ABgD/////AQAcAAAA+wIAAAAAAAAAAAAAAAAAAAAAAAAAzRIAkXL1d0AAAAAvBQp0DVX1dxZV 9XcBAAAAAAAwAAQAAAAtAQMABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAAAgECAAAAEAAAACYGDwAW AP////8AAEcBAACPAgAAeQIAAMECAAAIAAAAJgYPAAYA/////wEABQAAAAkCAAAAAgUAAAAUAgAA AAAFAAAAAgECAAAABwAAAPwCAQAAAAAAAAAEAAAALQEEAAQAAAAtAQEABwAAABsEaQF5A/AASAAE AAAALQECAAQAAAAtAQAABQAAAAkCAAAAAgUAAAAUAgAAAAAcAAAA+wLF/wAAAAAAAJABAAAAAABA ACJBcmlhbAD1d0AAAADdBgp7DVX1dxZV9XcBAAAAAAAwAAQAAAAtAQUABAAAAPABAwAFAAAACQIA AAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAIgAAADIKQgHHABIAAABTSU1QTEUgT3Bl biBJc3N1ZXMnAA8AMQAnACEAKAAQAC4AIQAhACEAEAAPAB4AHgAhACAAHgAFAAAALgEBAAAABQAA AAIBAgAAAAUAAAACAQIAAAAEAAAALQEBAAQAAAAtAQQAHAAAAPsCEAAHAAAAAAC8AgAAAAABAgIi U3lzdGVtAAAAAAoAAAAEAAAAAAADAAAAAQAAAAAAMAAEAAAALQEDAAQAAADwAQUADwAAACYGDwAU AFROUFAEAAwAAAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAABQAAAAkCAAAAAgUA AAAUAgAAAAAFAAAALgEYAAAABQBkZSBUaXRsZXMAAwAAABEAAAAAAAAAaW0NADEABQAAAC4BAQAA AAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAD2DyAAAAAUAAAAX8CR4/XVAAAIAPQDAwDfA3Jq c3BhcmtzCAAAAHIAagBzAHAAYQByAGsAcwAhACEAIQAQAB4ADQAhABAAEAAFAAAALgEBAAAABQAA AAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAPAAAAMgrZAIYB BQAAAFVSTHM/ACsAKgAhAB0AIQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAACAQIAAAAEAAAALQEE AAQAAAAtAQEABwAAABsEgQJ5A9AASAAEAAAALQECAAQAAAAtAQAABQAAAAkCAAAAAgUAAAAUAgAA AAAcAAAA+wLV/wAAAAAAAJABAAAAAABAACJBcmlhbAD1d0AAAAB0BAr2DVX1dxZV9XcBAAAAAAAw AAQAAAAtAQMABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAA CQAAADIK/gBSAAEAAACVbQ8ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAA AAUAAAAuARgAAAAFAAAAAgEBAAAAEgAAADIK/gB2AAcAAABSZXF1ZXN0Ah8AGAAYABcAGAAWAAwA BQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEB AAAACQAAADIK/gAWAQEAAAAtbQ4ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQC AAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADAAAADIK/gAkAQMAAABVUkklHgAfAAwABQAAAC4BAQAA AAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIK OwFSAAEAAACVbQ8ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAu ARgAAAAFAAAAAgEBAAAAKwAAADIKOwF2ABgAAABUbzogYW5kIEZyb206IGluIGdlbmVyYWwaABgA DAAMABgAFwAYAAwAGgAOABcAJAAMAAwACQAYAAwAFwAYABgAGAAOABcACgAFAAAALgEBAAAABQAA AAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAAMgp5AVIA AQAAAJVtDwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAA AAUAAAACAQEAAAAeAAAAMgp5AXYADwAAAFRvOiBpbiBSRUdJU1RFUgAaABgADAAMAAkAGAAMAB8A HQAhAAsAHQAaABwAHwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAA AC4BGAAAAAUAAAACAQEAAAAJAAAAMgq2AVIAAQAAAJVtDwAFAAAALgEBAAAABQAAAAIBAgAAAAUA AAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAuAAAAMgq2AXYAGgAAAENvbnRh Y3Q6IGluIGdlbmVyYWwgKFIvUlIpHwAYABgADAAXABYADAALAAwACgAXAAwAGAAXABgAGAAOABcA CgAMAA4AHwAMAB8AHwAOAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAF AAAALgEYAAAABQAAAAIBAQAAAAkAAAAyCvMBUgABAAAAlW0PAAUAAAAuAQEAAAAFAAAAAgECAAAA BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAACUAAAAyCvMBdgAUAAAAQ29u dGFjdDogaW4gUkVHSVNURVIfABgAGAAMABcAFgAMAAsADAAKABcADAAfAB0AIQALAB0AGgAdAB8A BQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0BAQAEAAAALQEEABwAAAD7AhAABwAA AAAAvAIAAAAAAQICIlN5c3RlbQAAAAAKAAAABAAAAAAABQAAAAEAAAAAADAABAAAAC0BBQAEAAAA 8AEDAA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD/////AQAAAAMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAA AAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA5AQAABAAAAABAAAAiAAAAAMAAACQ AAAADwAAAKgAAAAEAAAAzAAAAAYAAADUAAAABwAAANwAAAAIAAAA5AAAAAkAAADsAAAACgAAAPQA AAAXAAAA/AAAAAsAAAAEAQAAEAAAAAwBAAATAAAAFAEAABYAAAAcAQAADQAAACQBAAAMAAAAggQA AAIAAADkBAAAHgAAAA8AAABPbi1zY3JlZW4gU2hvdwAAHgAAABoAAABEZWxsIENvbXB1dGVyIENv cnBvcmF0aW9uAHMAAwAAABnWAAADAAAANwAAAAMAAAARAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAA AAAAAwAAAO0OCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAATAAAABgAAAEFy aWFsAA8AAABEZWZhdWx0IERlc2lnbgATAAAAU0lNcNoSAFDaEgB0ObkALN4SAIg2uQB82hIAZNoS AHbHCzAIAAAAAAAAAHzaEgAo3Q0wAFgGIgAApA8KAAAAgABgAAAA/////wAApQ8MAAAAAAAACC4A AAAHAAAAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAA AAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkAC AAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwQsAQAADwAA8CQBAAAAAAbw2AAAAARkAAAa AAAANgAAABEAAAABAAAABwAAAAMAAAAEAAAABwAAAAQAAAAPAAAABAAAAAAAAAAEAAAACwAAAAQA AAAJAAAABAAAAAwAAAAEAAAADQAAAAQAAAACAAAABAAAAAgAAAAEAAAADgAAAAQAAAAAAAAABAAA AAQAAAAEAAAACgAAAAQAAAAAAAAABAAAAAUAAAAEAAAABgAAAAQAAAAQAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAARAAAABAAAAGMAC/AkAAAAgQEEAAAIgwEA AAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwA AAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQB3sBAAAfABQEHAAAAAAAFQQUAAAAuh11 7ADKmjsyTs3JAMqaOwEBAAEPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABBAAAAZAAAAEEAAABk AAAAdscLMAgAAAAAAAAAcNoSAAAAAAAAAAAApv///+D+//8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA +wMIAAAAAQAAAEALAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAGDzDTAs3hIAAAAA AHQ3uQAAAAAAAAAAAAAAAAAAAAAAAAESAB8AEwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAA YPMNMCzeEgAAAAAAdDe5AAAAAAAAAAAAAAAAAAAAAAAAARIAHwD/AxQAAAACAAAEDAAAAAAAAAAA AAAAAgAAAB8ACAQ8AAAAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAnNoSANn0DTAs3hIAAQAAAAAA AAAAAAAAAAAAAAAAAAAAABIAPwDZDwwAAAAAANoPBAAAAAAAJQAPAPAPKBEAAAAA8wMUAAAAAwAA AAAAAAAAAAAAAAEAAAAAAAAAAPMDFAAAAA4AAAAAAAAAAgAAAAsBAAAAAAAAAACfDwQAAAAAAAAA AACoDzkAAABTaG91bGQgd2UgaGF2ZSBhIG1lc3NhZ2Ugc2Vzc2lvbiBib3VuZGVkIHdpdGggSU5W SVRFL0JZRT8AAKoPEgAAADkAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAoA9IAQAAVQBz AGUAZgB1AGwAIABmAG8AcgAgAGMAaABhAHQAIAATICAAcgBlAHUAcwBlAHMAIABmAGkAbgBkAC0A bQBlACAAbwBmACAASQBOAFYASQBUAEUADQBEAG8AZQBzAG4AGSB0ACAAbgBlAGMAZQBzAHMAYQBy AGkAbAB5ACAAaABhAHYAZQAgAHQAbwAgAGIAZQAgAGEAbgAgAFIAVABQACAAcwBlAHMAcwBpAG8A bgANAE0AdQBzAHQAIABzAHQAaQBsAGwAIAB0AHIAYQBuAHMAaQB0ACAAQwBQAEkATQAgAGIAbwB1 AG4AZABhAHIAeQANAFMAaABvAHUAbABkACAAcwB0AGkAbABsACAAYgBlACAAYQBiAGwAZQAgAHQA bwAgAHMAZQBuAGQAIABiAGEAcgBlACAATQBFAFMAUwBBAEcARQBzAAAAqg8aAAAAnAAAAAAAAAAI AAAAAQAAAAMAAQAAAAAAAAAAAPMDFAAAABMAAAAAAAAAAgAAAA4BAAAAAAAAAACfDwQAAAAAAAAA AACoDygAAABJcyBSRUdJU1RFUiB0aGUgcmlnaHQgUFVCTElTSCBtZWNoYW5pc20/AACqDxIAAAAo AAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPZAAAAERpc3Bvc2l0aW9uIG9mIGJvZGll cyBpbiBSRUdJU1RFUiBpcyBwcm9ibGVtYXRpYy4NTWF5IGFsc28gbmVlZCBwdWJsaXNoIG1lY2hh bmlzbSBmb3IgYXV0aG9yaXphdGlvbi4AAKEPFAAAAGUAAAAAAAAAAABlAAAAAAACABwAAADzAxQA AAAUAAAAAAAAAAIAAAAPAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8NAAAAQXV0aG9yaXphdGlvbhAA nw8EAAAAAQAAAAAAqA+0AAAAQ2FuIGJlIGFkZHJlc3NlZCBzZXBhcmF0ZWx5IGZyb20gcmVzdCBv ZiB3b3JrDUNvdWxkIGJlIGFwcGxpY2FibGUgdG8gbW9yZSB0aGFuIFNJTVBMRQ1Qcm9ibGVtcyB3 aXRoIFFBVVRIDUNvdWxkIHVzZSBzdWJzY3JpcHRpb24gdG8gc3Vic2NyaXB0aW9uIHN0YXRlIChh cyBhIHNlcGFyYXRlIGV2ZW50IHBhY2thZ2UpAAChDxQAAAC1AAAAAAAAAAAAtQAAAAAAAgAcAAAA 8wMUAAAABAAAAAAAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAERvIHdlIHdhbnQg dG8gcmF0ZSBsaW1pdCBOT1RJRlk/EACfDwQAAAABAAAAAACoD3oAAABzaXAtZXZlbnRzIHB1c2hl ZCB0aGlzIG91dCB0byBpbmRpdmlkdWFsIHBhY2thZ2VzDUhlbHBzIHdpdGggY29uZ2VzdGlvbiBj b250cm9sDURvIHdlIG5lZ290aWF0ZSB0aGUgcmF0ZSBkdXJpbmcgc3Vic2NyaWJlPwAA8wMUAAAA DAAAAAAAAAACAAAACQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPPAAAAElzIHRoZSBsb3dlc3QgY29t bW9uIGRlbm9taW5hdG9yIG1lc3NhZ2UvY3BpbSBvciB0ZXh0L3BsYWluPwAAqg8kAAAAKQAAAAAA AAAFAAAAAQAAAAMADgAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD2gAAABtZXNzYWdl L2NwaW0gaXMgcmVxdWlyZWQgZm9yIGUtZSBhY3Jvc3MgYSBjcGltIGJvdW5kYXJ5DVNvbWUgYWdl bnRzIG1heSBub3QgY2FyZSBhYm91dCBlbmQtZW5kIHNlY3VyaXR5IAAAqg8sAAAACAAAAAAAAAAF AAAAAQAAAAMAHQAAAAAAAAAFAAAAAQAAAAMAOgAAAAAAAAAAAPMDFAAAAAgAAAAAAAAAAgAAAAUB AAAAAAAAAACfDwQAAAAAAAAAAACoDyUAAABDYW4gd2UgY29udmVydCBzaXAgVVJMcyB0byBwcmVz OiBVUkxzAACqDxIAAAAlAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPlwAAAElmIHdl IGhhdmUgc3BlY2lhbGl6ZWQgYSBwcmVzOiBVUkwgdG8gYSBzaXA6IFVSTCBiZWZvcmUgcmVhY2hp bmcgYSBjcGltIGdhdGV3YXksIGNhbiB3ZSByZWxpYWJseSBjb252ZXJ0IGJhY2sgdG8gYSBtZWFu aW5nZnVsIHByZXM6IFVSTCBhdCB0aGUgZ2F0ZXdheT8AAKoPGgAAAEMAAAAAAAAABQAAAAEAAAAD AFAAAAAAAAAAAADzAxQAAAAVAAAAAAAAAAAAAAARAQAAAAAAAAAA8wMUAAAADwAAAAAAAAACAAAA DAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPLQAAAFdoYXQgZG9lcyBhIGJvZHkgaW4gYSAyMDAgT0sg dG8gTUVTU0FHRSBtZWFuPwAAqg8SAAAALQAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACo D1cAAABDdXJyZW50IHNwZWMgYWxsb3dzIGl0DUlzIHRoaXMgYSByZXBseSBtZXNzYWdlPyBXb3Vs ZCBpdCBoYXZlIHRvIGNyb3NzIGEgQ1BJTSBib3VuZGFyeT8AAKoPEgAAAFcAAAAAAAAAAQAAAAEA AAAAAAAA8wMUAAAACgAAAAAAAAACAAAACAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPPwAAAEhvdyBk byB5b3Ugc3ludGhlc2l6ZSBhIHByZXNlbmNlIGRvY3VtZW50IGZyb20gcmVnaXN0ZXJlZCBkYXRh PwAAqg8SAAAAPwAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD1gAAABUaGlzIGlzIG9u bHkgb25lIHdheSB0byBjcmVhdGUgYSBwcmVzZW5jZSBkb2N1bWVudCwgYnV0IGl0IGlzIGltcG9y dGFudCBhbmQgbm90IHRyaXZpYWwuAADzAxQAAAAHAAAAAAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8jAAAATWlncmF0aW9uIGludGVyYWN0cyBiYWRseSB3aXRoIFJSL1IAAKoPEgAAACMA AAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA/5AAAATWlncmF0aW9uIGlzIHRoZSB0cmFu c2ZlciBvZiBOT1RJRlkgcmVzcG9uc2liaWxpdHkgZnJvbSBhIHByZXNlbmNlIHNlcnZlciB0byBh IFBBIHdpdGhvdXQgc3BlY2lhbCBiZWhhdmlvciBvbiB0aGUgcGFydCBvZiB0aGUgU3Vic2NyaWJl ci4NRG8gd2UgZGlzYWxsb3cgTWlncmF0aW9uIG9yIGRvIHdlIG1ha2UgUlIvQ29udGFjdCBiZWhh dmlvciBzcGVjaWFsIGZvciBTVUJTQ1JJQkU/DUFyZSB0aGVyZSBvdGhlciBhbHRlcm5hdGl2ZXM/ AAChDxQAAAD6AAAAAAAAEAAAWgD6AAAAAAAAAAAAqg8SAAAA+QAAAAAAAAABAAAAAQAAAAAAAADz AxQAAAAJAAAAAAAAAAIAAAAGAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA85AAAAQ2FuIHdlIHJlZHVj ZSB0aGUgc3RhdGUgYSBzaXAvY3BpbSBnYXRld2F5IG11c3QgbWFpbnRhaW4/AACqDyQAAAAeAAAA AAAAAAUAAAABAAAAAwAWAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKAPDgEAAGMAcABp AG0AIABkAG8AZQBzAG4AGSB0ACAAcgBlAGYAbABlAGMAdAAgAHQAaABlACAAYwBhAGwAbAAtAGwA ZQBnACAAcwBlAG0AYQBuAHQAaQBjAC4ADQBOAG8AIABzAHUAYwBoACAAdABoAGkAbgBnACAAYQBz ACAAYwBwAGkAbQAgAG8AbgAgAHQAaABlACAAdwBpAHIAZQAgABMgIABtAGEAeQAgAGIAZQAgAGEA YgBsAGUAIAB0AG8AIAB0AHIAYQBuAHMAbABhAHQAZQAgAHMAdABhAHQAZQAgAHQAbwAgAHQAaABl ACAAbwB0AGgAZQByACAAcAByAG8AdABvAGMAbwBsAHMALgAgAAAAqg8kAAAABAAAAAEAAAADADkA AAAAAAAABQAAAAEAAAADAEYAAAAAAAAAAADzAxQAAAALAAAAAAAAAAIAAAAHAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8yAAAARG9lcyBpdCBtYWtlIHNlbnNlIHRvIGhhdmUgYSBNRVNTQUdFIHdpdGgg bm8gYm9keT8AAKoPEgAAADIAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA8mAAAAQ3Vy cmVudCB0ZXh0IGFsbG93cyBhIGJvZGlsZXNzIG1lc3NhZ2UAAPMDFAAAAA0AAAAAAAAAAgAAAAoB AAAAAAAAAACfDwQAAAAAAAAAAACoDzQAAABJcyB1c2Ugb2YgdGhlIEFjY2VwdCBoZWFkZXIgd2l0 aCBtZXNzYWdlL2NwaW0gY2xlYXI/AACqDyQAAAApAAAAAAAAAAUAAAABAAAAAwAGAAAAAAAAAAEA AAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPRwAAAEFjY2VwdCBoZWFkZXIgbmVlZHMgdG8gbGlzdCB0 aGUgZW1iZWRkZWQgbWltZSB0eXBlcyB0aGF0IGFyZSBhY2NlcHRhYmxlAADzAxQAAAAFAAAAAAAA AAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8YAAAATWVyZ2luZyBvZiBQcmVzZW5jZSBEYXRh AACqDxIAAAAYAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKAPMgEAAEQAaQBzAGMAdQBz AHMAaQBvAG4AIABvAGYAIABtAGUAcgBnAGkAbgBnACAAcAByAGUAcwBlAG4AYwBlACAAZABhAHQA YQAgAGYAcgBvAG0AIABtAHUAbAB0AGkAcABsAGUAIABVAEEAcwAgAGgAYQBzACAAYgBlAGUAbgAg AHIAZQBtAG8AdgBlAGQAIABmAHIAbwBtACAAdABoAGUAIABkAHIAYQBmAHQALgAgAFAAcgBvAGIA bABlAG0APwANAFAAcgBvAHAAbwBzAGEAbAA6ACAARABvAG4AGSB0ACAAbgBlAGUAZAAgAHQAbwAg AGEAZABkAHIAZQBzAHMAIAB0AGgAaQBzACAAcAByAG8AYgBsAGUAbQAgAGkAbQBtAGUAZABpAGEA dABlAGwAeQAuAAAAqg8aAAAAMgAAAAAAAAAEAAAAAQAAAAMAZAAAAAAAAAAAAPMDFAAAABEAAAAA AAAAAgAAABABAAAAAAAAAACfDwQAAAAAAAAAAACoDxUAAABPdGhlciBJTSBkcmFmdCBpc3N1ZXMQ AJ8PBAAAAAEAAAAAAKgPHgAAAENvbmdlc3Rpb24gY29udHJvbA1NYXAgdG8gQ1BJTQAA6gMAAAAA DwDuAxEEAAACAO8DGAAAABAAAAAAAAAAAAAAAAAAAIAAAAAABwAAAA8ADATBAwAADwAC8LkDAAAQ AQjwCAAAAAMAAAADZAAADwAD8FEDAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIA CvAIAAAAAGQAAAUAAAAPAATw7wAAABIACvAIAAAAAmQAACACAABTAAvwHgAAAH8AAAAEAIAA6AV2 BL8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAgAGwAdAUUAQPABHwEAAAAAAAwwsIAAAA/////w0A dgQPAA3wiQAAAAAAnw8EAAAAAAAAAAAAqA9JAAAARG8gd2UgYWNjZXB0IGFsbCBOT1RJRllzIG9y IGp1c3QgdGhlIG9uZSBtYXRjaGluZyB0aGUgMnh4IHRvIGEgU1VCU0NSSUJFPwAAqg8kAAAAEQAA AAAAAAAIAAAAAQAAAAMAMAAAAAAAAAABAAAAAQAAAAAADwAE8CICAAASAArwCAAAAANkAAAgAgAA UwAL8B4AAAB/AAAABACAABAOdgS/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAKAFsAHQFAAPDwAR 8BAAAAAAAMMLCAAAAP////8OAHYEDwAN8LwBAAAAAJ8PBAAAAAEAAAAAAKAPqAEAAEQAbwBuABkg dAAgAGsAbgBvAHcAIAB3AGgAZQBuACAAdABvACAAcwB0AG8AcAAgAHcAYQB0AGMAaABpAG4AZwAg AGYAbwByACAAHCBuAGUAdwAgAGwAZQBnAHMAHSAuAA0AQwBvAG0AcABvAHMAaQBuAGcAIABzAHQA YQB0AGUAIABmAHIAbwBtACAAbQB1AGwAdABpAHAAbABlACAAcwBvAHUAcgBjAGUAcwAgAG0AYQB5 ACAAYgBlACAAZABpAGYAZgBpAGMAdQBsAHQALgANAEMAbwB1AGwAZAAgAGIAZQAgAGMAbwBuAHMA aQBkAGUAcgBlAGQAIABhAG4AbwB0AGgAZQByACAAZgBvAHIAbQAgAG8AZgAgAGkAbQBwAGwAaQBj AGkAdAAgAHMAdQBiAHMAYwByAGkAcAB0AGkAbwBuACAAZgBvAHIAIAB0AGgAbwBzAGUAIABjAGwA aQBlAG4AdABzACAAdwBpAGwAbABpAG4AZwAgAHQAbwAgAGQAZQBhAGwAIAB3AGkAdABoACAAdABo AGUAIABhAGIAbwB2AGUALgAPAATwSAAAABIACvAIAAAAAWQAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACA gIAAAAAAAADMmQAzM8wAzMz/ALKysgAAAHIXEAAAAAEAEACMiwAAFQAQAAmhAAAAAPUPHAAAABEB AACcCgADaIsAACKlAAABAAAAFQAAAAEAcwAPAOgDdRUAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYA AAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A8gMWAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUH TAAAAAAAtw9EAAAAQQByAGkAYQBsAAAAAAAAAHDaEgBQ2hIAdDm5ACzeEgCINrkAfNoSAGTaEgB2 xwswCAAAAAAAAAB82hIAKN0NMABYBiIAAKQPCgAAAIAAYAAAAP////8AAKUPDAAAAAAAAAguAAAA BwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAA AAAAQAIAAAAABwAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAA AAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsELAEAAA8AAPAkAQAAAAAG8NgAAAAEZAAAGgAA ADYAAAARAAAAAQAAAAcAAAADAAAABAAAAAcAAAAEAAAADwAAAAQAAAAAAAAABAAAAAsAAAAEAAAA CQAAAAQAAAAMAAAABAAAAA0AAAAEAAAAAgAAAAQAAAAIAAAABAAAAA4AAAAEAAAAAAAAAAQAAAAE AAAABAAAAAoAAAAEAAAAAAAAAAQAAAAFAAAABAAAAAYAAAAEAAAAEAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAEQAAAAQAAABjAAvwJAAAAIEBBAAACIMBAAAA CL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAA AADzAxQAAAACAAAAAAAAAAAAAAAAAACAAAAAAA8A0Ad7AQAAHwAUBBwAAAAAABUEFAAAALoddewA ypo7Mk7NyQDKmjsBAQABDwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAQQAAAGQAAABBAAAAZAAA AHbHCzAIAAAAAAAAAHDaEgAAAAAAAAAAAKb////g/v//AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsD CAAAAAEAAABACwAAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAABg8w0wLN4SAAAAAAB0 N7kAAAAAAAAAAAAAAAAAAAAAAAABEgAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAGDz DTAs3hIAAAAAAHQ3uQAAAAAAAAAAAAAAAAAAAAAAAAESAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAA AAIAAAAfAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAJzaEgDZ9A0wLN4SAAEAAAAAAAAA AAAAAAAAAAAAAAAAAAASAD8A2Q8MAAAAAADaDwQAAAAAACUADwDwDygRAAAAAPMDFAAAAAMAAAAA AAAAAAAAAAABAAAAAAAAAADzAxQAAAAOAAAAAAAAAAIAAAALAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA85AAAAU2hvdWxkIHdlIGhhdmUgYSBtZXNzYWdlIHNlc3Npb24gYm91bmRlZCB3aXRoIElOVklU RS9CWUU/AACqDxIAAAA5AAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKAPSAEAAFUAcwBl AGYAdQBsACAAZgBvAHIAIABjAGgAYQB0ACAAEyAgAHIAZQB1AHMAZQBzACAAZgBpAG4AZAAtAG0A ZQAgAG8AZgAgAEkATgBWAEkAVABFAA0ARABvAGUAcwBuABkgdAAgAG4AZQBjAGUAcwBzAGEAcgBp AGwAeQAgAGgAYQB2AGUAIAB0AG8AIABiAGUAIABhAG4AIABSAFQAUAAgAHMAZQBzAHMAaQBvAG4A DQBNAHUAcwB0ACAAcwB0AGkAbABsACAAdAByAGEAbgBzAGkAdAAgAEMAUABJAE0AIABiAG8AdQBu AGQAYQByAHkADQBTAGgAbwB1AGwAZAAgAHMAdABpAGwAbAAgAGIAZQAgAGEAYgBsAGUAIAB0AG8A IABzAGUAbgBkACAAYgBhAHIAZQAgAE0ARQBTAFMAQQBHAEUAcwAAAKoPGgAAAJwAAAAAAAAACAAA AAEAAAADAAEAAAAAAAAAAADzAxQAAAATAAAAAAAAAAIAAAAOAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8oAAAASXMgUkVHSVNURVIgdGhlIHJpZ2h0IFBVQkxJU0ggbWVjaGFuaXNtPwAAqg8SAAAAKAAA AAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD2QAAABEaXNwb3NpdGlvbiBvZiBib2RpZXMg aW4gUkVHSVNURVIgaXMgcHJvYmxlbWF0aWMuDU1heSBhbHNvIG5lZWQgcHVibGlzaCBtZWNoYW5p c20gZm9yIGF1dGhvcml6YXRpb24uAAChDxQAAABlAAAAAAAAAAAAZQAAAAAAAgAcAAAA8wMUAAAA FAAAAAAAAAACAAAADwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDQAAAEF1dGhvcml6YXRpb24QAJ8P BAAAAAEAAAAAAKgPtAAAAENhbiBiZSBhZGRyZXNzZWQgc2VwYXJhdGVseSBmcm9tIHJlc3Qgb2Yg d29yaw1Db3VsZCBiZSBhcHBsaWNhYmxlIHRvIG1vcmUgdGhhbiBTSU1QTEUNUHJvYmxlbXMgd2l0 aCBRQVVUSA1Db3VsZCB1c2Ugc3Vic2NyaXB0aW9uIHRvIHN1YnNjcmlwdGlvbiBzdGF0ZSAoYXMg YSBzZXBhcmF0ZSBldmVudCBwYWNrYWdlKQAAoQ8UAAAAtQAAAAAAAAAAALUAAAAAAAIAHAAAAPMD FAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDyAAAABEbyB3ZSB3YW50IHRv IHJhdGUgbGltaXQgTk9USUZZPxAAnw8EAAAAAQAAAAAAqA96AAAAc2lwLWV2ZW50cyBwdXNoZWQg dGhpcyBvdXQgdG8gaW5kaXZpZHVhbCBwYWNrYWdlcw1IZWxwcyB3aXRoIGNvbmdlc3Rpb24gY29u dHJvbA1EbyB3ZSBuZWdvdGlhdGUgdGhlIHJhdGUgZHVyaW5nIHN1YnNjcmliZT8AAPMDFAAAAAwA AAAAAAAAAgAAAAkBAAAAAAAAAACfDwQAAAAAAAAAAACoDzwAAABJcyB0aGUgbG93ZXN0IGNvbW1v biBkZW5vbWluYXRvciBtZXNzYWdlL2NwaW0gb3IgdGV4dC9wbGFpbj8AAKoPJAAAACkAAAAAAAAA BQAAAAEAAAADAA4AAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA9oAAAAbWVzc2FnZS9j cGltIGlzIHJlcXVpcmVkIGZvciBlLWUgYWNyb3NzIGEgY3BpbSBib3VuZGFyeQ1Tb21lIGFnZW50 cyBtYXkgbm90IGNhcmUgYWJvdXQgZW5kLWVuZCBzZWN1cml0eSAAAKoPLAAAAAgAAAAAAAAABQAA AAEAAAADAB0AAAAAAAAABQAAAAEAAAADADoAAAAAAAAAAADzAxQAAAAIAAAAAAAAAAIAAAAFAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8lAAAAQ2FuIHdlIGNvbnZlcnQgc2lwIFVSTHMgdG8gcHJlczog VVJMcwAAqg8SAAAAJQAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD5cAAABJZiB3ZSBo YXZlIHNwZWNpYWxpemVkIGEgcHJlczogVVJMIHRvIGEgc2lwOiBVUkwgYmVmb3JlIHJlYWNoaW5n IGEgY3BpbSBnYXRld2F5LCBjYW4gd2UgcmVsaWFibHkgY29udmVydCBiYWNrIHRvIGEgbWVhbmlu Z2Z1bCBwcmVzOiBVUkwgYXQgdGhlIGdhdGV3YXk/AACqDxoAAABDAAAAAAAAAAUAAAABAAAAAwBQ AAAAAAAAAAAA8wMUAAAAFQAAAAAAAAAAAAAAEQEAAAAAAAAAAPMDFAAAAA8AAAAAAAAAAgAAAAwB AAAAAAAAAACfDwQAAAAAAAAAAACoDy0AAABXaGF0IGRvZXMgYSBib2R5IGluIGEgMjAwIE9LIHRv IE1FU1NBR0UgbWVhbj8AAKoPEgAAAC0AAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA9X AAAAQ3VycmVudCBzcGVjIGFsbG93cyBpdA1JcyB0aGlzIGEgcmVwbHkgbWVzc2FnZT8gV291bGQg aXQgaGF2ZSB0byBjcm9zcyBhIENQSU0gYm91bmRhcnk/AACqDxIAAABXAAAAAAAAAAEAAAABAAAA AAAAAPMDFAAAAAoAAAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACoDz8AAABIb3cgZG8g eW91IHN5bnRoZXNpemUgYSBwcmVzZW5jZSBkb2N1bWVudCBmcm9tIHJlZ2lzdGVyZWQgZGF0YT8A AKoPEgAAAD8AAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA9YAAAAVGhpcyBpcyBvbmx5 IG9uZSB3YXkgdG8gY3JlYXRlIGEgcHJlc2VuY2UgZG9jdW1lbnQsIGJ1dCBpdCBpcyBpbXBvcnRh bnQgYW5kIG5vdCB0cml2aWFsLgAA8wMUAAAABwAAAAAAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAA AAAAAKgPIwAAAE1pZ3JhdGlvbiBpbnRlcmFjdHMgYmFkbHkgd2l0aCBSUi9SAACqDxIAAAAjAAAA AAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgP+QAAAE1pZ3JhdGlvbiBpcyB0aGUgdHJhbnNm ZXIgb2YgTk9USUZZIHJlc3BvbnNpYmlsaXR5IGZyb20gYSBwcmVzZW5jZSBzZXJ2ZXIgdG8gYSBQ QSB3aXRob3V0IHNwZWNpYWwgYmVoYXZpb3Igb24gdGhlIHBhcnQgb2YgdGhlIFN1YnNjcmliZXIu DURvIHdlIGRpc2FsbG93IE1pZ3JhdGlvbiBvciBkbyB3ZSBtYWtlIFJSL0NvbnRhY3QgYmVoYXZp b3Igc3BlY2lhbCBmb3IgU1VCU0NSSUJFPw1BcmUgdGhlcmUgb3RoZXIgYWx0ZXJuYXRpdmVzPwAA oQ8UAAAA+gAAAAAAABAAAFoA+gAAAAAAAAAAAKoPEgAAAPkAAAAAAAAAAQAAAAEAAAAAAAAA8wMU AAAACQAAAAAAAAACAAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPOQAAAENhbiB3ZSByZWR1Y2Ug dGhlIHN0YXRlIGEgc2lwL2NwaW0gZ2F0ZXdheSBtdXN0IG1haW50YWluPwAAqg8kAAAAHgAAAAAA AAAFAAAAAQAAAAMAFgAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACgDw4BAABjAHAAaQBt ACAAZABvAGUAcwBuABkgdAAgAHIAZQBmAGwAZQBjAHQAIAB0AGgAZQAgAGMAYQBsAGwALQBsAGUA ZwAgAHMAZQBtAGEAbgB0AGkAYwAuAA0ATgBvACAAcwB1AGMAaAAgAHQAaABpAG4AZwAgAGEAcwAg AGMAcABpAG0AIABvAG4AIAB0AGgAZQAgAHcAaQByAGUAIAATICAAbQBhAHkAIABiAGUAIABhAGIA bABlACAAdABvACAAdAByAGEAbgBzAGwAYQB0AGUAIABzAHQAYQB0AGUAIAB0AG8AIAB0AGgAZQAg AG8AdABoAGUAcgAgAHAAcgBvAHQAbwBjAG8AbABzAC4AIAAAAKoPJAAAAAQAAAABAAAAAwA5AAAA AAAAAAUAAAABAAAAAwBGAAAAAAAAAAAA8wMUAAAACwAAAAAAAAACAAAABwEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPMgAAAERvZXMgaXQgbWFrZSBzZW5zZSB0byBoYXZlIGEgTUVTU0FHRSB3aXRoIG5v IGJvZHk/AACqDxIAAAAyAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPJgAAAEN1cnJl bnQgdGV4dCBhbGxvd3MgYSBib2RpbGVzcyBtZXNzYWdlAADzAxQAAAANAAAAAAAAAAIAAAAKAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA80AAAASXMgdXNlIG9mIHRoZSBBY2NlcHQgaGVhZGVyIHdpdGgg bWVzc2FnZS9jcGltIGNsZWFyPwAAqg8kAAAAKQAAAAAAAAAFAAAAAQAAAAMABgAAAAAAAAABAAAA AQAAAAAAEACfDwQAAAABAAAAAACoD0cAAABBY2NlcHQgaGVhZGVyIG5lZWRzIHRvIGxpc3QgdGhl IGVtYmVkZGVkIG1pbWUgdHlwZXMgdGhhdCBhcmUgYWNjZXB0YWJsZQAA8wMUAAAABQAAAAAAAAAC AAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGAAAAE1lcmdpbmcgb2YgUHJlc2VuY2UgRGF0YQAA qg8SAAAAGAAAAAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACgDzIBAABEAGkAcwBjAHUAcwBz AGkAbwBuACAAbwBmACAAbQBlAHIAZwBpAG4AZwAgAHAAcgBlAHMAZQBuAGMAZQAgAGQAYQB0AGEA IABmAHIAbwBtACAAbQB1AGwAdABpAHAAbABlACAAVQBBAHMAIABoAGEAcwAgAGIAZQBlAG4AIABy AGUAbQBvAHYAZQBkACAAZgByAG8AbQAgAHQAaABlACAAZAByAGEAZgB0AC4AIABQAHIAbwBiAGwA ZQBtAD8ADQBQAHIAbwBwAG8AcwBhAGwAOgAgAEQAbwBuABkgdAAgAG4AZQBlAGQAIAB0AG8AIABh AGQAZAByAGUAcwBzACAAdABoAGkAcwAgAHAAcgBvAGIAbABlAG0AIABpAG0AbQBlAGQAaQBhAHQA ZQBsAHkALgAAAKoPGgAAADIAAAAAAAAABAAAAAEAAAADAGQAAAAAAAAAAADzAxQAAAARAAAAAAAA AAIAAAAQAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8VAAAAT3RoZXIgSU0gZHJhZnQgaXNzdWVzEACf DwQAAAABAAAAAACoDx4AAABDb25nZXN0aW9uIGNvbnRyb2wNTWFwIHRvIENQSU0AAOoDAAAAAAAA chcIAAAAAQAQAF6lAAAAAPUPHAAAAAABAACcCgADOqUAANu6AAABAAAAFQAAAAEAcwAPAOgD9xUA AAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A8gMWAQAA LwDIDwwAAAAwANIPBAAAAAEAAAAPANUHTAAAAAAAtw9EAAAAQQByAGkAYQBsAAAAAAAAAHDaEgBQ 2hIA5ALfAyzeEgAsAN8DfNoSAGTaEgB2xwswCAAAAAAAAAB82hIAKN0NMABYBiIAAKQPCgAAAIAA YAAAAP////8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////GAAAAAAB AAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsENAEA AA8AAPAsAQAAAAAG8OAAAAACbAAAGwAAADkAAAASAAAAAQAAAAcAAAACAAAABAAAAA0AAAAEAAAA BgAAAAQAAAAAAAAABAAAAAoAAAAEAAAACAAAAAQAAAAHAAAABAAAAAgAAAAEAAAAAgAAAAQAAAAJ AAAABAAAAAcAAAAEAAAAAAAAAAQAAAAGAAAABAAAAAsAAAAEAAAAAAAAAAQAAAARAAAABAAAAAoA AAAEAAAABQAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAwAA AAQAAAAEAAAABAAAAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAI QAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAA AAAADwDQB3sBAAAfABQEHAAAAAAAFQQUAAAAuh117ADKmjsyTs3JAMqaOwEBAAEPAPoDZwAAAAAA /gMDAAAAAAEAAAD9AzQAAABBAAAAZAAAAEEAAABkAAAAdscLMAgAAAAAAAAAcNoSAAAAAAAAAAAA pv///+D+//8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAAcEPAAAAAAA/QM0 AAAAIQAAAGQAAAAhAAAAZAAAAGDzDTAs3hIAAAAAABgB3wMAAAAAAAAAAAAAAAAAAAAAAAESAB8A EwQ8AAAAAAD9AzQAAABkAAAAZAAAAGQAAABkAAAAYPMNMCzeEgAAAAAAGAHfAwAAAAAAAAAAAAAA AAAAAAAAARIAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ACAQ8AAAAAAD9AzQAAABCAAAA ZAAAAEIAAABkAAAAnNoSANn0DTAs3hIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAABIAPwDZDwwAAAAA ANoPBAAAAAAAJQAPAPAPohEAAAAA8wMUAAAAFgAAAAAAAAACAAAAEgEAAAAAAAAAAJ8PBAAAAAYA AAAAAKgPEgAAAFNJTVBMRSBPcGVuIElzc3VlcwAAqg8SAAAAEgAAAAAAAAABAAAAAQAAAAAAEACf DwQAAAAFAAAAAACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAADAAAAAAAAAAAAAAAAAQAAAAAAAAAA 8wMUAAAADgAAAAAAAAACAAAACwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPOQAAAFNob3VsZCB3ZSBo YXZlIGEgbWVzc2FnZSBzZXNzaW9uIGJvdW5kZWQgd2l0aCBJTlZJVEUvQllFPwAAqg8SAAAAOQAA AAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACgD0gBAABVAHMAZQBmAHUAbAAgAGYAbwByACAA YwBoAGEAdAAgABMgIAByAGUAdQBzAGUAcwAgAGYAaQBuAGQALQBtAGUAIABvAGYAIABJAE4AVgBJ AFQARQANAEQAbwBlAHMAbgAZIHQAIABuAGUAYwBlAHMAcwBhAHIAaQBsAHkAIABoAGEAdgBlACAA dABvACAAYgBlACAAYQBuACAAUgBUAFAAIABzAGUAcwBzAGkAbwBuAA0ATQB1AHMAdAAgAHMAdABp AGwAbAAgAHQAcgBhAG4AcwBpAHQAIABDAFAASQBNACAAYgBvAHUAbgBkAGEAcgB5AA0AUwBoAG8A dQBsAGQAIABzAHQAaQBsAGwAIABiAGUAIABhAGIAbABlACAAdABvACAAcwBlAG4AZAAgAGIAYQBy AGUAIABNAEUAUwBTAEEARwBFAHMAAACqDxoAAACcAAAAAAAAAAgAAAABAAAAAwABAAAAAAAAAAAA 8wMUAAAAEwAAAAAAAAACAAAADgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPKAAAAElzIFJFR0lTVEVS IHRoZSByaWdodCBQVUJMSVNIIG1lY2hhbmlzbT8AAKoPEgAAACgAAAAAAAAAAQAAAAEAAAAAABAA nw8EAAAAAQAAAAAAqA9kAAAARGlzcG9zaXRpb24gb2YgYm9kaWVzIGluIFJFR0lTVEVSIGlzIHBy b2JsZW1hdGljLg1NYXkgYWxzbyBuZWVkIHB1Ymxpc2ggbWVjaGFuaXNtIGZvciBhdXRob3JpemF0 aW9uLgAAoQ8UAAAAZQAAAAAAAAAAAGUAAAAAAAIAHAAAAPMDFAAAABQAAAAAAAAAAgAAAA8BAAAA AAAAAACfDwQAAAAAAAAAAACoDw0AAABBdXRob3JpemF0aW9uEACfDwQAAAABAAAAAACoD7QAAABD YW4gYmUgYWRkcmVzc2VkIHNlcGFyYXRlbHkgZnJvbSByZXN0IG9mIHdvcmsNQ291bGQgYmUgYXBw bGljYWJsZSB0byBtb3JlIHRoYW4gU0lNUExFDVByb2JsZW1zIHdpdGggUUFVVEgNQ291bGQgdXNl IHN1YnNjcmlwdGlvbiB0byBzdWJzY3JpcHRpb24gc3RhdGUgKGFzIGEgc2VwYXJhdGUgZXZlbnQg cGFja2FnZSkAAKEPFAAAALUAAAAAAAAAAAC1AAAAAAACABwAAADzAxQAAAAEAAAAAAAAAAIAAAAB AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAARG8gd2Ugd2FudCB0byByYXRlIGxpbWl0IE5PVElG WT8QAJ8PBAAAAAEAAAAAAKgPegAAAHNpcC1ldmVudHMgcHVzaGVkIHRoaXMgb3V0IHRvIGluZGl2 aWR1YWwgcGFja2FnZXMNSGVscHMgd2l0aCBjb25nZXN0aW9uIGNvbnRyb2wNRG8gd2UgbmVnb3Rp YXRlIHRoZSByYXRlIGR1cmluZyBzdWJzY3JpYmU/AADzAxQAAAAMAAAAAAAAAAIAAAAJAQAAAAAA AAAAnw8EAAAAAAAAAAAAqA88AAAASXMgdGhlIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3IgbWVz c2FnZS9jcGltIG9yIHRleHQvcGxhaW4/AACqDyQAAAApAAAAAAAAAAUAAAABAAAAAwAOAAAAAAAA AAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPaAAAAG1lc3NhZ2UvY3BpbSBpcyByZXF1aXJlZCBm b3IgZS1lIGFjcm9zcyBhIGNwaW0gYm91bmRhcnkNU29tZSBhZ2VudHMgbWF5IG5vdCBjYXJlIGFi b3V0IGVuZC1lbmQgc2VjdXJpdHkgAACqDywAAAAIAAAAAAAAAAUAAAABAAAAAwAdAAAAAAAAAAUA AAABAAAAAwA6AAAAAAAAAAAA8wMUAAAACAAAAAAAAAACAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPJQAAAENhbiB3ZSBjb252ZXJ0IHNpcCBVUkxzIHRvIHByZXM6IFVSTHMAAKoPEgAAACUAAAAA AAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqA+XAAAASWYgd2UgaGF2ZSBzcGVjaWFsaXplZCBh IHByZXM6IFVSTCB0byBhIHNpcDogVVJMIGJlZm9yZSByZWFjaGluZyBhIGNwaW0gZ2F0ZXdheSwg Y2FuIHdlIHJlbGlhYmx5IGNvbnZlcnQgYmFjayB0byBhIG1lYW5pbmdmdWwgcHJlczogVVJMIGF0 IHRoZSBnYXRld2F5PwAAqg8aAAAAQwAAAAAAAAAFAAAAAQAAAAMAUAAAAAAAAAAAAPMDFAAAABUA AAAAAAAAAAAAABEBAAAAAAAAAADzAxQAAAAPAAAAAAAAAAIAAAAMAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8tAAAAV2hhdCBkb2VzIGEgYm9keSBpbiBhIDIwMCBPSyB0byBNRVNTQUdFIG1lYW4/AACq DxIAAAAtAAAAAAAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPVwAAAEN1cnJlbnQgc3BlYyBh bGxvd3MgaXQNSXMgdGhpcyBhIHJlcGx5IG1lc3NhZ2U/IFdvdWxkIGl0IGhhdmUgdG8gY3Jvc3Mg YSBDUElNIGJvdW5kYXJ5PwAAqg8SAAAAVwAAAAAAAAABAAAAAQAAAAAAAADzAxQAAAAKAAAAAAAA AAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8/AAAASG93IGRvIHlvdSBzeW50aGVzaXplIGEg cHJlc2VuY2UgZG9jdW1lbnQgZnJvbSByZWdpc3RlcmVkIGRhdGE/AACqDxIAAAA/AAAAAAAAAAEA AAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPWAAAAFRoaXMgaXMgb25seSBvbmUgd2F5IHRvIGNyZWF0 ZSBhIHByZXNlbmNlIGRvY3VtZW50LCBidXQgaXQgaXMgaW1wb3J0YW50IGFuZCBub3QgdHJpdmlh bC4AAPMDFAAAAAcAAAAAAAAAAgAAAAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDyMAAABNaWdyYXRp b24gaW50ZXJhY3RzIGJhZGx5IHdpdGggUlIvUgAAqg8SAAAAIwAAAAAAAAABAAAAAQAAAAAAEACf DwQAAAABAAAAAACoD/kAAABNaWdyYXRpb24gaXMgdGhlIHRyYW5zZmVyIG9mIE5PVElGWSByZXNw b25zaWJpbGl0eSBmcm9tIGEgcHJlc2VuY2Ugc2VydmVyIHRvIGEgUEEgd2l0aG91dCBzcGVjaWFs IGJlaGF2aW9yIG9uIHRoZSBwYXJ0IG9mIHRoZSBTdWJzY3JpYmVyLg1EbyB3ZSBkaXNhbGxvdyBN aWdyYXRpb24gb3IgZG8gd2UgbWFrZSBSUi9Db250YWN0IGJlaGF2aW9yIHNwZWNpYWwgZm9yIFNV QlNDUklCRT8NQXJlIHRoZXJlIG90aGVyIGFsdGVybmF0aXZlcz8AAKEPFAAAAPoAAAAAAAAQAABa APoAAAAAAAAAAACqDxIAAAD5AAAAAAAAAAEAAAABAAAAAAAAAPMDFAAAAAkAAAAAAAAAAgAAAAYB AAAAAAAAAACfDwQAAAAAAAAAAACoDzkAAABDYW4gd2UgcmVkdWNlIHRoZSBzdGF0ZSBhIHNpcC9j cGltIGdhdGV3YXkgbXVzdCBtYWludGFpbj8AAKoPJAAAAB4AAAAAAAAABQAAAAEAAAADABYAAAAA AAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAoA8OAQAAYwBwAGkAbQAgAGQAbwBlAHMAbgAZIHQA IAByAGUAZgBsAGUAYwB0ACAAdABoAGUAIABjAGEAbABsAC0AbABlAGcAIABzAGUAbQBhAG4AdABp AGMALgANAE4AbwAgAHMAdQBjAGgAIAB0AGgAaQBuAGcAIABhAHMAIABjAHAAaQBtACAAbwBuACAA dABoAGUAIAB3AGkAcgBlACAAEyAgAG0AYQB5ACAAYgBlACAAYQBiAGwAZQAgAHQAbwAgAHQAcgBh AG4AcwBsAGEAdABlACAAcwB0AGEAdABlACAAdABvACAAdABoAGUAIABvAHQAaABlAHIAIABwAHIA bwB0AG8AYwBvAGwAcwAuACAAAACqDyQAAAAEAAAAAQAAAAMAOQAAAAAAAAAFAAAAAQAAAAMARgAA AAAAAAAAAPMDFAAAAAsAAAAAAAAAAgAAAAcBAAAAAAAAAACfDwQAAAAAAAAAAACoDzIAAABEb2Vz IGl0IG1ha2Ugc2Vuc2UgdG8gaGF2ZSBhIE1FU1NBR0Ugd2l0aCBubyBib2R5PwAAqg8SAAAAMgAA AAAAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACoDyYAAABDdXJyZW50IHRleHQgYWxsb3dzIGEg Ym9kaWxlc3MgbWVzc2FnZQAA8wMUAAAADQAAAAAAAAACAAAACgEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPNAAAAElzIHVzZSBvZiB0aGUgQWNjZXB0IGhlYWRlciB3aXRoIG1lc3NhZ2UvY3BpbSBjbGVh cj8AAKoPJAAAACkAAAAAAAAABQAAAAEAAAADAAYAAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAA AAAAqA9HAAAAQWNjZXB0IGhlYWRlciBuZWVkcyB0byBsaXN0IHRoZSBlbWJlZGRlZCBtaW1lIHR5 cGVzIHRoYXQgYXJlIGFjY2VwdGFibGUAAPMDFAAAAAUAAAAAAAAAAgAAAAIBAAAAAAAAAACfDwQA AAAAAAAAAACoDxgAAABNZXJnaW5nIG9mIFByZXNlbmNlIERhdGEAAKoPEgAAABgAAAAAAAAAAQAA AAEAAAAAABAAnw8EAAAAAQAAAAAAoA8yAQAARABpAHMAYwB1AHMAcwBpAG8AbgAgAG8AZgAgAG0A ZQByAGcAaQBuAGcAIABwAHIAZQBzAGUAbgBjAGUAIABkAGEAdABhACAAZgByAG8AbQAgAG0AdQBs AHQAaQBwAGwAZQAgAFUAQQBzACAAaABhAHMAIABiAGUAZQBuACAAcgBlAG0AbwB2AGUAZAAgAGYA cgBvAG0AIAB0AGgAZQAgAGQAcgBhAGYAdAAuACAAUAByAG8AYgBsAGUAbQA/AA0AUAByAG8AcABv AHMAYQBsADoAIABEAG8AbgAZIHQAIABuAGUAZQBkACAAdABvACAAYQBkAGQAcgBlAHMAcwAgAHQA aABpAHMAIABwAHIAbwBiAGwAZQBtACAAaQBtAG0AZQBkAGkAYQB0AGUAbAB5AC4AAACqDxoAAAAy AAAAAAAAAAQAAAABAAAAAwBkAAAAAAAAAAAA8wMUAAAAEQAAAAAAAAACAAAAEAEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPFQAAAE90aGVyIElNIGRyYWZ0IGlzc3VlcxAAnw8EAAAAAQAAAAAAqA8eAAAA Q29uZ2VzdGlvbiBjb250cm9sDU1hcCB0byBDUElNAADqAwAAAAAPAO4D5AEAAAIA7wMYAAAAAAAA AA8QAAAAAAAAAAAAgAAAAAAHAAAADwAMBJQBAAAPAALwjAEAAEAACPAIAAAAAwAAAANoAAAPAAPw JAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAaAAABQAAAA8ABPBy AAAAEgAK8AgAAAACaAAAIAIAAFMAC/AeAAAAfwAAAAQAgABg9N8DvwEAAAEA/wEAAAEAAQMCBAAA AAAQ8AgAAACgBbAB0BRwCA8AEfAQAAAAAADDCwgAAAAAAAAADwDfAw8ADfAMAAAAAACeDwQAAAAA AAAADwAE8HIAAAASAArwCAAAAANoAAAgAgAAUwAL8B4AAAB/AAAABACAAHT/3wO/AQEAAQD/AQEA AQABAwMEAAAAABDwCAAAAJAJYAMgE+ANDwAR8BAAAAAAAMMLCAAAAAEAAAAQAN8DDwAN8AwAAAAA AJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAWgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB jp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAA AADMmQAzM8wAzMz/ALKysgAPAO4D0wIAAAIA7wMYAAAAEAAAAAAAAAAAAAAAAAAAgAAAAAAHAAAA DwAMBIMCAAAPAALwewIAACAACPAIAAAAAwAAAAMIAAAPAAPwEwIAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPDbAAAAEgAK8AgAAAACCAAAIAIAAFMA C/AeAAAAfwAAAAQAgADcmN8DvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQ AAAAAADDCwgAAAD/////DQDfAw8ADfB1AAAAAACfDwQAAAAAAAAAAACoDz8AAABXaGF0IGFyZSB0 aGUgcmFtaWZpY2F0aW9ucyBvZiBtaXhpbmcgcHJlczosIGltOiwgYW5kIHNpcDogVVJMcz8AAKoP GgAAACwAAAAAAAAAAgAAAAEAAAADABIAAAAAAAAADwAE8PgAAAASAArwCAAAAAMIAAAgAgAAUwAL 8B4AAAB/AAAABACAAMyb3wO/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAOAEsAHQFAAPDwAR8BAA AAAAAMMLCAAAAP////8OAN8DDwAN8JIAAAAAAJ8PBAAAAAEAAAAAAKgPZAAAAFJlcXVlc3QtVVJJ DVRvOiBhbmQgRnJvbTogaW4gZ2VuZXJhbA1UbzogaW4gUkVHSVNURVINQ29udGFjdDogaW4gZ2Vu ZXJhbCAoUi9SUikNQ29udGFjdDogaW4gUkVHSVNURVIAAKoPEgAAAGQAAAAAAAAAAQAAAAEAAAAA AA8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADM zP8AsrKyAAAAchcYAAAAAQAQAA+7AAADABAA+tIAABYAEAAO0QAAAAD1DxwAAAASAQAAnAoAA+u6 AADV1QAAAQAAABYAAAABAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_000_01C0C132.C376C9A1 Content-Type: application/vnd.ms-powerpoint; name="rosenberg-simple_open_mar01.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rosenberg-simple_open_mar01.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAATAAAAAAAAAAA EAAA/v///wAAAAD+////AAAAAEsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8P AOgDDzAAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A 8gMWAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUHTAAAAAAAtw9EAAAAVABpAG0AZQBzACAATgBl AHcAIABSAG8AbQBhAG4AAACgNbkAnNoSAITaEgB2xwswCAAAAAAAAACc2hIAKN0NMAAABAAAAKQP CgAAAIAAYAAAAP////8AAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9u AAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA//////// GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAP AAsE9AAAAA8AAPDsAAAAAAAG8KAAAAACTAAAEwAAAE4AAAAQAAAAAQAAAAcAAAADAAAABAAAAAUA AAAGAAAABAAAAAUAAAAAAAAACAAAAAUAAAAFAAAABwAAAAUAAAADAAAABQAAAAgAAAAFAAAAAAAA AAYAAAAIAAAABQAAAAsAAAAFAAAADAAAAAUAAAANAAAAFQAAAA4AAAAGAAAADwAAAAUAAAAQAAAA BQAAAAIAAAAFAAAAYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhA AB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAA AAAPANAHNwEAAB8AFAQcAAAAAAAVBBQAAAC6HXXsAMqaOzJOzckAypo7AQEAAQ8A+gNnAAAAAAD+ AwMAAAAAAQAAAP0DNAAAAEEAAABkAAAAQQAAAGQAAAB2xwswCAAAAAAAAACQ2hIAAAAAAAAAAACm ////4P7//wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8ABwQ8AAAAAAD9AzQA AAAhAAAAZAAAACEAAABkAAAAYPMNMEzeEgAAAAAAjDa5AAAAAAAAAAAAAAAAAAAAAAAAARIAHwAT BDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAABg8w0wTN4SAAAAAACMNrkAAAAAAAAAAAAAAAAA AAAAAAABEgAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwDwD1IsAAAAAPMDFAAAAAMAAAAA AAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoDxcAAABJTSBhbmQgUFJFUyBvcGVuIGlzc3Vl cxAAnw8EAAAABQAAAAAAqA8SAAAASm9uYXRoYW4gUm9zZW5iZXJnAADzAxQAAAAEAAAAAAAAAAMA AAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8ZAAAATWVzc2FnaW5nOiBzZXNzaW9uIG9yIG5vdBAA nw8EAAAABwAAAAAAoA+UAgAATQBlAHMAcwBhAGcAaQBuAGcAIABoAGEAcwAgAGQAdQBhAGwAIABu AGEAdAB1AHIAZQANAEEAcwB5AG4AYwByAGgAbwBuAG8AdQBzACwAIABuAG8AIABwAHIAZQAtAGUA cwB0AGEAYgBsAGkAcwBoAG0AZQBuAHQADQBUAGgAZQByAGUAIABpAHMAIABhACAAcABlAHIAcwBp AHMAdABlAG4AdAAgAGMAbwBuAHYAZQByAHMAYQB0AGkAbwBuACAAYgBlAHQAdwBlAGUAbgAgAGUA bgB0AGkAdABpAGUAcwAgAHQAaABhAHQAIAByAGUAYQBsAGwAeQAgAHIAZQBwAHIAZQBzAGUAbgB0 AHMAIABhACAAcwBlAHMAcwBpAG8AbgANAEIAZQBuAGUAZgBpAHQAcwAgAG8AZgAgAHMAZQBzAHMA aQBvAG4AIAB2AGkAZQB3AA0ARQBhAHMAaQBsAHkAIABoAGEAbgBkAGwAZQBzACAAbQB1AGwAdABp AHAAbABlACAAUABDAHMAIABhAGwAbAAgAGwAbwBnAGcAZQBkACAAaQBuACAAEyAgAGUAYQBjAGgA IABnAGUAdAAgAG0AZQBzAHMAYQBnAGUALAAgAGEAbgBkACAAZQBhAGMAaAAgAGMAYQBuACAAYwBh AHIAcgB5ACAAYwBvAG4AdgBlAHIAcwBhAHQAaQBvAG4AIAB3AGkAdABoACAAaQBuAGkAdABpAGEA dABvAHIADQBBAGwAbABvAHcAcwAgAG0AZQBzAHMAYQBnAGUAcwAgAG4AbwB0ACAAdABvACAAdABy AGEAdgBlAHIAcwBlACAAcAByAG8AeABpAGUAcwAgACgAcwBlAGUAIABuAGUAeAB0ACkAAAChD1wA AAAaAAAAAAAAEAAAWgB4AAAAAQAAEAAAWgAZAAAAAAAAEAAAWgCgAAAAAQAAEAAAWgAaAAAAAAAC ABgAeAAAAAAAAgAUABkAAAAABAIAAAQYAKAAAAAACAIAAAgUAAAAqg8aAAAAGgAAAAAAAAAMAAAA AQAAAAEAJQEAAAAAAAAgAJ8PBAAAAAcAAAAAAKAPnAIAAEEAbABsAG8AdwBzACAAdQBzACAAdABv ACAAYQBwAHAAbAB5ACAAYQBsAGwAIABzAGkAcAAgAHQAbwBvAGwAcwAgAGEAdAAgAG8AdQByACAA ZABpAHMAcABvAHMAYQBsAA0ATQB1AGwAdABpAHAAYQByAHQAeQAgAGMAbwBuAGYAZQByAGUAbgBj AGkAbgBnAA0AQwBhAGwAbAAgAGMAbwBuAHQAcgBvAGwAIAATICAAdAByAGEAbgBzAGYAZQByAHMA DQBBAGQAZAAgAG0AZQBzAHMAYQBnAGkAbgBnACAAcwBlAHMAcwBpAG8AbgAgAHQAbwAgAHYAbwBp AGMAZQAgAGMAYQBsAGwADQBNAG8AcgBlACAAYwBvAG4AcwBpAHMAdABlAG4AdAAgAHcAaQB0AGgA IABTAEkAUAAgAG8AcABlAHIAYQB0AGkAbwBuAA0ATABhAHIAZwBlACAAbQBlAHMAcwBhAGcAZQBz ACAAVwBJAEwATAAgAGIAZQAgAGEAbgAgAGkAcwBzAHUAZQANAEEAbABsAGkAcwBvAG4AIABoAGEA cwAgAGkAbgBkAGkAYwBhAHQAZQBkACAAcwBoAGUALwBJAEUAUwBHACAAdwBpAGwAbAAgAHAAdQBz AGgAIABiAGEAYwBrACAAbwBuACAAcwBlAG4AZABpAG4AZwAgAGwAYQByAGcAZQAgAGMAbwBuAHQA ZQBuAHQAIAB0AGgAcgBvAHUAZwBoACAAcAByAG8AeABpAGUAcwANAFcAZQAgAGgAYQB2AGUAIAB0 AGgAZQAgAHQAbwBvAGwAcwAgAHQAbwAgAG4AbwB0ACAAZABvACAAaQB0ACwAIABsAGUAdABzACAA dQBzAGUAIAB0AGgAZQBtACEAAAChD3QAAAAxAAAAAQAAEAAAWgBVAAAAAgAAEAAAWgAjAAAAAQAA EAAAWgAgAAAAAAAAEAAAWgCGAAAAAQAAEAAAWgAxAAAAAAACABQAVQAAAAAAAgASACMAAAAABAIA AAQUACAAAAAABAIAAAQYAIYAAAAABAIAAAQUAAAA8wMUAAAABQAAAAAAAAADAAAAAwEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPGQAAAE1lc3NhZ2luZzogc2Vzc2lvbiBvciBub3QQAJ8PBAAAAAcAAAAA AKgPzwAAAENhbiBtaW1pY2sgZXhpc3RpbmcgR1VJLCBzbyB0aGF0IGVzdGFibGlzaG1lbnQgaXMg aGlkZGVuDUkgdHlwZSBJTQ1NeSBVSSB0b29sIHNlbmRzIElOVklURQ1SZWNpcGllbnQgdG9vbCBp bW1lZGlhdGVseSByZXNwb25kcyB3aXRoIDIwMCBPSw1NeSB0b29sIHNlbmRzIEFDSw1NeSB0b29s IHNlbmRzIG1lc3NhZ2UNUmVtb3RlIHRvb2wgZGlzcGxheXMgbWVzc2FnZQAAoQ8qAAAAOQAAAAAA AAAAAJcAAAABAAAAAAA5AAAAAAACABgAlwAAAAAEAgAABBQAAACqDxoAAAAEAAAAAAAAAAcAAAAB AAAAAQDFAAAAAAAAACAAnw8EAAAABwAAAAAAqA/GAAAARHJhd2JhY2tzIHRvIHNlc3Npb24gbW9k ZWwNQmlnIG92ZXJoZWFkIGZvciBvbmUtc2hvdHMNQ29tbW9uIGNhc2UgaXMgcHJvYmFibHkgbXVs dGlwbGUgbWVzc2FnZXMNTGF0ZW5jeSB0byBzZXR1cA1Ob3QgY29uc2lzdGVudCB3aXRoIGN1cnJl bnQgaW1wbGVtZW50YXRpb25zDUdhdGV3YXlpbmcgaGFyZGVyPyAoc3RpbGwgcG9zc2libGUgdG8g ZG8pAAChD2wAAAAbAAAAAAAAAAAAGwAAAAEAAAAAACoAAAACAAAAAAA9AAAAAQAAAAAAKgAAAAIA AAAAABsAAAAAAAIAGAAbAAAAAAQCAAAEFAAqAAAAAAQCAAAEEgA9AAAAAAgCAAAIFAAqAAAAAAwC AAAMEgAAAKoPGgAAAJ0AAAAAAAAACwAAAAEAAAABAB8AAAAAAAAAAADzAxQAAAAGAAAABAAAAAMA AAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8cAAAASG93IGlzIG1lc3NhZ2Ugc2Vzc2lvbiBkb25l PxAAnw8EAAAABwAAAAAAoA8MAgAAQQBwAHAAcgBvAGEAYwBoACAASQA6ACAAUwBJAFAAIABTAHQA cgBlAGEAbQANAFQAcgBlAGEAdAAgAFMASQBQACAAYQBzACAAYQAgAHMAdAByAGUAYQBtACAAYQBs AHMAbwAsACAAYQBrAGkAbgAgAHQAbwAgAFIAVABQAA0AUwBEAFAAIABoAGEAcwAgAGEAbgAgAG0A IABsAGkAbgBlACAAdwBpAHQAaAAgAG0AaQBtAGUAIAB0AHkAcABlACAAbQBlAHMAcwBhAGcAZQAN AFQAcgBhAG4AcwBwAG8AcgB0ACAAaQBzACAAVQBEAFAALAAgAFQAQwBQACwAIABUAEwAUwANAFAA bwByAHQAIABpAHMAIAA1ADAANgAwACAAbwByACAAdwBoAGEAdABlAHYAZQByAA0AHCBwAGEAeQBs AG8AYQBkACAAdAB5AHAAZQAdICAAaQBzACAAUwBJAFAADQBTAGUAbgBkACAAUwBJAFAAIABtAGUA cwBzAGEAZwBlAHMAIABkAGkAcgBlAGMAdABsAHkAIABiAGUAdAB3AGUAZQBuACAAaQBuAGkAdABp AGEAdABvAHIAIABhAG4AZAAgAHIAZQBjAGkAcABpAGUAbgB0AA0ATQBhAGkAbgAgAGkAcwBzAHUA ZQAgAGEAZwBhAGkAbgA6ACAATgBBAFQALwBGAFcADQAAAKEPLgAAABcAAAAAAAAQAABaAPAAAAAB AAAQAABaABcAAAAAAAIAGADwAAAAAAQCAAAEFAAAAPMDFAAAAAcAAAAAAAAAAwAAAAQBAAAAAAAA AACfDwQAAAAAAAAAAACoDxwAAABIb3cgaXMgbWVzc2FnZSBzZXNzaW9uIGRvbmU/EACfDwQAAAAH AAAAAACoD4IAAABBcHByb2FjaCBJSTogTmV3DURlZmluZSBhIG5ldyBtZXNzYWdpbmcgdHJhbnNw b3J0DVBlcmhhcHMgQ1BJTSBvdmVyIFRDUA1NZWFucyB0aGF0IE1FU1NBR0UgbWV0aG9kIG5vdCBu ZWVkZWQgZm9yIG1lc3NhZ2Ugc2Vzc2lvbnMhAAChDyYAAAARAAAAAAAAAAAAcgAAAAEAAAAAABEA AAAAAAAAcgAAAAAEAAAABCAAnw8EAAAABwAAAAAAoA9GAQAAQQBwAHAAcgBvAGEAYwBoACAASQBJ AEkAOgAgAFIAVABQAA0AVQBzAGUAIAByAGYAYwAyADcAOQAzACAAKAB0AGUAeAB0ACAAbwB2AGUA cgAgAFIAVABQACkADQBFAHgAaQBzAHQAcwAsACAAbgBvACAAYwBoAGEAbgBnAGUAcwAgACgAdwBl ABkgcgBlACAAZABvAG4AZQAhACkADQBOAG8AdAAgAHIAZQBhAGwAbAB5ACAAbQBlAHMAcwBhAGcA aQBuAGcAIABhAHMAIAB3AGUAIABrAG4AbwB3ACAAaQB0ACAAdABvAGQAYQB5AA0ATQBvAHIAZQAg AGwAaQBrAGUAIABjAGgAYQByAGEAYwB0AGUAcgAgAGMAaABhAHQAcwANAEMAYQBuACAAZABvACAA bQB1AGwAdABpAGMAYQBzAHQADQAAAKEPUAAAABIAAAAAAAAAAABmAAAAAQAAAAAAKwAAAAIAAAAA AAEAAAABAAEAAAAAABIAAAAAAAAAZgAAAAAEAAAABCsAAAAABAAAAAQBAAAAAAQAAAAEAADzAxQA AAAIAAAAAAAAAAIAAAAGAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8YAAAAV2hhdCBhYm91dCBzZXNz aW9uLWxlc3M/EACfDwQAAAABAAAAAACoD/gAAABXZSBjYW4gc3RpbGwgaGF2ZSBzZXNzaW9uLWxl c3MgbWVzc2FnZXMNS2VlcCBleGlzdGluZyBNRVNTQUdFLCBidXQgaXQgZG9lcyBub3QgaGF2ZSBJ TlZJVEUgc2VtYW50aWNzIQ1MaWtlIE9QVElPTlMNTm8gUlIvQ29udGFjdCBwcm9jZXNzaW5nDUNh biBiZSBpbiBjYWxsIChlc3RhYmxpc2hlZCBieSBJTlZJVEUpIG9yIG91dCBvZiBjYWxsDU5vIGd1 YXJhbnRlZXMgYWJvdXQgZGVsaXZlcnkgdG8gc2FtZSBob3N0IGZvciBuZXh0IG9uZQAAoQ8qAAAA ZgAAAAAAAAAAAJMAAAABAAAAAABmAAAAAAACABwAkwAAAAAEAgAABBgAAADzAxQAAAAJAAAAAAAA AAMAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8LAAAAQ29tcGFyaXNvbnMQAJ8PBAAAAAcAAAAA AKgPkwAAAFNJUCBTdHJlYW0gbW9zdCBmbGV4aWJsZQ1DYW4gc3RpbGwgc2VuZCBzbWFsbCBNRVNT QUdFIG92ZXIgU0lQIHNpZ25hbGluZw1MYXJnZXIgb25lcyBkaXJlY3QNV2UgY2FuIHN0aWxsIGRl ZmluZSBvbmUtc2hvdCBtZXNzYWdlcyB3aXRob3V0IHNlc3Npb25zDQAAoQ8yAAAAGQAAAAAAAAAA AHoAAAABAAAAAAABAAAAAQABAAAAAAAZAAAAAAAAAHsAAAAABAAAAAQgAJ8PBAAAAAcAAAAAAKgP 9wAAAE5ldyBzdHJlYW0gc2Vjb25kIGNob2ljZQ1Vc2luZyBDUElNIG92ZXIgVENQIGlzIHNvbWV3 aGF0IGFwcGVhbGluZw1JbiBwcmFjdGljZSwgd2lsbCBuZWVkIHRvIGFkZCBtYW55IGhlYWRlcnMg dG8gYWxsb3cgZm9yIGZyYW1pbmcsIGV0Yy4NQ2FuIHN0aWxsIGhhdmUgTUVTU0FHRSBtZXRob2Qg Zm9yIG9uZS1zaG90cywgd291bGQgdGhlbiBtYWtlIHNlbnNlIHRvIGNhcnJ5IENQSU0gYWx3YXlz Pw1SVFAgbm90IHJlYWxseSB2aWFibGUAAKEPbAAAABkAAAAAAAAAAAAqAAAAAQAAAAAARgAAAAIA AAAAAFkAAAABAAAAAAAWAAAAAAAAAAAAGQAAAAAAAgAYACoAAAAABAIAAAQUAEYAAAAABAIAAAQS AFkAAAAACAIAAAgUABYAAAAADAIAAAwYAAAA8wMUAAAACgAAAAAAAAADAAAABwEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPEwAAAERlYWxpbmcgd2l0aCBOQVQvRlcQAJ8PBAAAAAcAAAAAAKgPDQEAAElm IG1lc3NhZ2Ugc3RyZWFtIGlzIGJpZGlyZWN0aW9uYWwsIHNvbHZlcyBOQVQtb24tb25lLXNpZGUg cHJvYmxlbQ1Vc2FnZSBvZiBhY3R1YWwgU0lQIE1FU1NBR0UgbWV0aG9kIGFzIHN0cmVhbSBoZWxw cyBzb2x2ZSBvdGhlciBjYXNlcw1UcnkgZGlyZWN0DUlmIG5vIHJlc3BvbnNlLCBzZW5kIHRvIGJv dHRvbSByb3V0ZSBzZXQgVVJJDUlmIG5vIHJlc3BvbnNlLCBzZW5kIHRvIG5leHQgcm91dGUgc2V0 IFVSSQ1Xb3JzdCBjYXNlLCBmb2xsb3dzIHNpZ25hbGluZyBwYXRoAAChDy4AAACIAAAAAAAAEAAA WgCGAAAAAQAAEAAAWgCIAAAAAAACABgAhgAAAAAEAgAABBQAAACqDxoAAAAVAAAAAAAAAA0AAAAB AAAAAQDsAAAAAAAAACAAnw8EAAAABwAAAAAAoA8YAQAAQQBuAG8AdABoAGUAcgAgAHAAbwBzAHMA aQBiAGkAbABpAHQAeQAgAGkAcwAgAHQAaABhAHQAIABwAHIAbwB4AGkAZQBzACAAYwBhAG4AIAAc IHIAZQBjAG8AcgBkAC0AcgBvAHUAdABlAB0gIABpAG4AIABTAEQAUAAgAHcAaQB0AGgAIABhAGQA ZAByAGUAcwBzACAAbwBmACAAZABlAGQAaQBjAGEAdABlAGQAIAByAGUAbABhAHkAcwANAE0AYQBu AHkAIABvAHQAaABlAHIAIABwAG8AcwBzAGkAYgBpAGwAaQB0AGkAZQBzACwAIABuAGUAZQBkACAA dABvACAAcwBvAHIAdAAgAGkAdAAgAG8AdQB0AAAA8wMUAAAACwAAAAAAAAADAAAACAEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPGgAAAEF1dGhvcml6YXRpb24gZm9yIHByZXNlbmNlEACfDwQAAAAHAAAA AACoD68AAABNVVNUIGJlIGFibGUgdG8gYXV0aG9yaXplIGVhY2ggc3Vic2NyaWJlciBieSBmaW5k aW5nIG91dCBmcm9tIHByZXNlbnRpdHkNV2hhdHMgd3Jvbmcgd2l0aCBRQVVUSD8NVXNlcyByZWdp c3RyYXRpb25zIHRvIGltcGx5IGFiaWxpdHkgdG8gbWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9u cyAtIG92ZXJsb2FkAAChDyoAAABhAAAAAAAAEAAAWgBPAAAAAQAAEAAAWgBhAAAAAAAAAE8AAAAA BAAAAAQAAKoPGgAAAD4AAAAAAAAAEQAAAAEAAAABAGEAAAAAAAAAIACfDwQAAAAHAAAAAACgD2wB AABXAGEAbgB0ACAAdABvACAAcwB1AHAAcABvAHIAdAAgAG0AdQBsAHQAaQBwAGwAZQAgAHUAcwBl AHIAcwAgAHQAaABhAHQAIABjAGEAbgAgAHMAZQB0ACAAcABvAGwAaQBjAHkADQBSAGUAcQB1AGkA cgBlAHMAIABRAEEAVQBUAEgAIAB0AG8AIABmAG8AcgBrAA0AQgB1AHQAIABvAG4AbAB5ACAAbwBu AGUAIAByAGUAcwBwAG8AbgBzAGUAIABpAHMAIABkAGUAbABpAHYAZQByAGUAZAAhACAAQgBSAE8A SwBFAE4AIQANAE4AZQBlAGQAcwAgAGkAbQBtAGUAZABpAGEAdABlACAAcgBlAHMAcABvAG4AcwBl ACAAEyAgAHcAaABhAHQAIABhAGIAbwB1AHQAIABpAGYAIAB1AHMAZQByACAAaQBzACAAYQB3AGEA eQAgAGYAcgBvAG0AIABkAGUAcwBrAD8AAAChDzYAAAAzAAAAAQAAAAAAQwAAAAIAAAAAAEEAAAAB AAAAAAAzAAAAAAAAAEMAAAAAAAAAQQAAAAAAAAAAAPMDFAAAAAwAAAAAAAAAAwAAAAkBAAAAAAAA AACfDwQAAAAAAAAAAACoDwwAAABOZXcgcHJvcG9zYWwQAJ8PBAAAAAcAAAAAAKAPNAEAAE0AeQAg AHMAdQBiAHMAYwByAGkAcAB0AGkAbwBuACAAcwB0AGEAdABlACAAaQBzACAAaQB0AHMAZQBsAGYA IABhACAAcwB1AGIAcwBjAHIAaQBiAGEAYgBsAGUAIABlAG4AdABpAHQAeQANAEMAYQBsAGwAIABp AHQAIAAcIHcAYQB0AGMAaABlAHIAaQBuAGYAbwAdIA0AVwBhAHQAYwBoAGUAcgBpAG4AZgBvACAA YwBvAG4AdABhAGkAbgBzACAAcwBlAHQAIABvAGYAIABwAGUAbgBkAGkAbgBnACAAYQBuAGQAIABh AHAAcAByAG8AdgBlAGQAIABzAHUAYgBzAGMAcgBpAGIAZQByAHMAIABmAG8AcgAgAGEAIABwAHIA ZQBzAGUAbgB0AGkAdAB5AA0AAAChDzYAAAA2AAAAAAAAAAAAFgAAAAEAAAAAAE8AAAAAAAAAAAA2 AAAAAAAAABYAAAAAAAAATwAAAAAAAAAAAKoPSAAAACIAAAAAAAAADQAAAAEAAAABABAAAAAAAAAA CwAAAAEAAAABAAIAAAAAAAAADAAAAAEAAAABADcAAAAAAAAADAAAAAEAAAABACAAnw8EAAAABwAA AAAAqA8TAQAAVXNlcnMgY2FuIHRoZW4gc3Vic2NyaWJlIHRvLCBvciBmZXRjaCwgd2F0Y2hlcmlu Zm8NVXN1YWxseSBvbmx5IHByZXNlbnRpdGllcyBvciBhZG1pbmlzdHJhdG9ycyBhcmUgYWxsb3dl ZA1XaGVuIHN1YnNjcmliZXJzIG9mIHdhdGNoZXJpbmZvIHNlZSBpdHMgY2hhbmdlZCwgdGhleSBj YW4NUHVzaCBhIG5ldyBwb2xpY3kgZG9jdW1lbnQgdG8gc2VydmVyDVBvbGljeSBkb2N1bWVudCBh ZGRzL3JlbW92ZXMgdXNlcnMgZnJvbSBBQ0wgYW5kIHVwZGF0ZXMgd2F0Y2hlcmluZm8gc3RhdGUA AKEPXAAAADMAAAAAAAAQAABaADgAAAABAAAQAABaADoAAAAAAAAQAABaAG8AAAABAAAQAABaADMA AAAAAAIAGAA4AAAAAAACABQAOgAAAAAEAgAABBgAbwAAAAAIAgAACBQAAACqD1AAAAAnAAAAAAAA AAwAAAABAAAAAQANAAAAAAAAAA0AAAABAAAAAQAyAAAAAAAAAAwAAAABAAAAAQB3AAAAAAAAAAwA AAABAAAAAQAGAAAAAAAAAAAA8wMUAAAADQAAAAQAAAADAAAACgEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPCgAAAEJhc2ljIGZsb3cQAJ8PBAAAAAcAAAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAA4A AAAAAAAAAwAAAAsBAAAAAAAAAACfDwQAAAAAAAAAAACoDwgAAABCZW5lZml0cxAAnw8EAAAABwAA AAAAoA9IAgAAVwBoAG8AIABjAGEAbgAgAHUAcABsAG8AYQBkACAAcABvAGwAaQBjAHkAIABoAGEA cwAgAG4AbwB0AGgAaQBuAGcAIAB0AG8AIABkAG8AIAB3AGkAdABoACAAcgBlAGcAaQBzAHQAcgBh AHQAaQBvAG4AcwANAEQAZQB0AGUAcgBtAGkAbgBlAGQAIABiAHkAIAB3AGgAbwAgAGMAYQBuACAA cwBlAG4AZAAgAHUAcABsAG8AYQBkACAAbQBlAHMAcwBhAGcAZQBzAA0ASQAgAGMAYQBuACAAcgBl AGMAZQBpAHYAZQAgAG4AbwB0AGkAZgBpAGMAYQB0AGkAbwBuAHMAIABhAGIAbwB1AHQAIABzAHUA YgBzAGMAcgBpAHAAdABpAG8AbgBzACAAdwBpAHQAaABvAHUAdAAgAHMAZQBuAGQAaQBuAGcAIABw AG8AbABpAGMAeQANAE0AdQBsAHQAaQBwAGwAZQAgAGUAbgB0AGkAdABpAGUAcwAgAGMAYQBuACAA dQBwAGwAbwBhAGQAIABwAG8AbABpAGMAaQBlAHMAIAATICAAcwBlAHIAdgBlAHIAIABzAGUAZQBz ACAAdABoAGUAbQAgAGEAbABsACAAYQBuAGQAIABjAGEAbgAgAHIAZQBjAG8AbgBjAGkAbABlAA0A VQBuAGkAZgBpAGUAcwAgAHQAcgBpAGcAZwBlAHIAZQBkACAAYQBuAGQAIAB1AG4AdAByAGkAZwBn AGUAcgBlAGQAIABwAG8AbABpAGMAeQAAAKEPQgAAADsAAAAAAAAQAABaACsAAAABAAAQAABaAL8A AAAAAAAQAABaADsAAAAAAAIAGAArAAAAAAACABQAvwAAAAAAAgAYAAAAqg8aAAAAEgEAAAAAAAAM AAAAAQAAAAEABwAAAAAAAAAgAJ8PBAAAAAcAAAAAAKgP3gAAAE9mZmxpbmUgY2xpZW50cyBpcyBl YXN5DU5vIHJlc3BvbnNlIHRvIG5vdGlmaWNhdGlvbiwgaXRzIGRlbGV0ZWQNQ2xpZW50IGNvbWVz IG9ubGluZQ1Ub29sIGZldGNoZXMgd2F0Y2hlcmluZm8NUHJvbXB0cyB1c2VyIGZvciBwZW5kaW5n IHN1YnNjcmlwdGlvbnMNTm8gdHJhbnNhY3Rpb25zIHBlbmRpbmcgd2hpbGUgd2Ugd2FpdCENUHVz aGVzIHJlc3VsdGluZyBwb2xpY3kgd2hlbiByZWFkeQAAoQ9WAAAAGAAAAAAAAAAAAH0AAAABAAAA AAAnAAAAAgAAAAAAIwAAAAEAAAAAABgAAAAAAAIAGAB9AAAAAAQCAAAEFAAnAAAAAAQCAAAEEgAj AAAAAAQCAAAEFAAAAKoPGgAAAGIAAAAAAAAADAAAAAEAAAABAHEAAAAAAAAAAADzAxQAAAAPAAAA AAAAAAMAAAAMAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8QAAAASG93IGRvIHdlIGRvIGl0PxAAnw8E AAAABwAAAAAAqA+wAAAARXZlbnQgcGFja2FnZSBmb3Igd2F0Y2hlcmluZm8NRmFpcmx5IGVhc3kN V2l0aGluIFNJTVBMRQ1XYXRjaGVyIGluZm8gZGF0YSBmb3JtYXQNSW4gTk9USUZZIG9mIHdhdGNo ZXJpbmZvDURyYWZ0IDAwIHN1Ym1pdHRlZCBpbiBKdW5lIDIwMDAgd2l0aCBvdGhlciBwcmVzZW5j ZSBkb2NzDVdpdGhpbiBTSU1QTEUAAKEPVAAAAB4AAAAAAAAAAAAaAAAAAQAAAAAAGQAAAAAAAAAA AGAAAAABAAAAAAAeAAAAAAACABgAGgAAAAAAAgAUABkAAAAABAIAAAQYAGAAAAAACAIAAAgUAAAA qg8sAAAAEgAAAAAAAAAMAAAAAQAAAAEAQAAAAAAAAAALAAAAAQAAAAEASAAAAAAAAAAgAJ8PBAAA AAcAAAAAAKAPsgEAAFAAbwBsAGkAYwB5ACAARABvAGMAdQBtAGUAbgB0AA0AVQBzAGkAbgBnACAA YQAgAGQAbwBjAHUAbQBlAG4AdAAgAGkAcwAgAGEAIABnAG8AbwBkACAAaQBkAGUAYQANAEMAYQBu ACAAcwBoAGEAcgBlACAAaQB0AA0AUwB0AG8AcgBlACAAaQB0AA0ARwBlAG4AZQByAGEAdABlACAA aQB0ACAAYgB5ACAAcwBlAHIAdgBsAGUAdABzACwAIABlAHQAYwAuAA0AVQBuAGkAdgBlAHIAcwBh AGwAIABpAG4AdABlAHIAbQBlAGQAaQBhAHQAZQAgAGYAbwByAG0AYQB0ACAAEyAgAGwAaQBrAGUA IABDAFAATAAgAA0AVwBpAHQAaABpAG4AIABTAEkATQBQAEwARQANAFUAcABsAG8AYQBkACAAbQBl AHQAaABvAGQADQBTAGUAbgBkACAAcABvAGwAaQBjAHkAIABkAG8AYwANAEkAcwAgAGkAdAAgAFIA RQBHAEkAUwBUAEUAUgA/ACAASQBzACAAaQB0ACAAZQB2AGUAbgAgAFMASQBQAD8AAAChD44AAAAQ AAAAAAAAEAAAWgAgAAAAAQAAEAAAWgBeAAAAAgAAEAAAWgAOAAAAAQAAEAAAWgAOAAAAAAAAEAAA WgAwAAAAAQAAEAAAWgAQAAAAAAACABgAIAAAAAAEAgAABBQAXgAAAAAEAgAABBIADgAAAAAIAgAA CBQADgAAAAAIAgAACBgAMAAAAAAIAgAACBQAAACqDxoAAABVAAAAAAAAAAgAAAABAAAAAQB9AAAA AAAAAAAA8wMUAAAAEAAAAAAAAAADAAAADQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAAAFVwbG9h ZGluZyBzdHVmZhAAnw8EAAAABwAAAAAAqA+gAAAAU2V2ZXJhbCBjYXNlcyB3aGVyZSB1c2VycyB1 cGxvYWQgZGF0YSB0byBzZXJ2ZXIgZm9yIHBvbGljeQ1DUEwgdXBsb2Fkcw1Qb2xpY3kgdXBsb2Fk cw1QcmVzZW5jZSBkb2N1bWVudCB1cGxvYWRzDUFyZSB0aGVzZSBzYW1lIGVub3VnaCBwcm9ibGVt cyB0byBzb2x2ZSBqb2ludGx5PwAAoQ88AAAAOwAAAAAAABAAAFoANQAAAAEAABAAAFoAMQAAAAAA ABAAAFoAOwAAAAAAAAA1AAAAAAAAADEAAAAAAAAAIACfDwQAAAAHAAAAAACoDwsBAABJcyB0aGlz IFNJUD8NSXRzIGFzIG11Y2ggU0lQIGFzIFJFR0lTVEVSIGlzIFNJUA1OYW1pbmcgdW5pZmljYXRp b24gaXMgcHJpbWFyeSBiZW5lZml0DVNhbWUgQUFBIHN5c3RlbXMgYW5vdGhlciBiZW5lZml0DUlz IGl0IFJFR0lTVEVSPw1Qcm9iYWJseSBub3QhDVJFR0lTVEVSIGRvZXMgc29tZXRoaW5nIHNwZWNp ZmljDUFsc28gZG9pbmcgdXBsb2FkIG1lYW5zIGJvdGggY2FuIGZhaWwgaW5kZXBlbmRlbnRseQ1T aG91bGQgdGVsbCB1cyB0aGVyZSBpcyBhIHByb2JsZW0AAKEPXAAAAA0AAAAAAAAQAABaAGoAAAAB AAAQAABaABAAAAAAAAAQAABaAIUAAAABAAAQAABaAA0AAAAAAAIAGABqAAAAAAACABQAEAAAAAAE AgAABBgAhQAAAAAIAgAACBQAAADzAxQAAAARAAAAAAAAAAMAAAAOAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8IAAAAUHJvcG9zYWwQAJ8PBAAAAAcAAAAAAKAPggEAAFUAcABkAGEAdABlACAATABlAG4A bgBvAHgAGSAgAGQAcgBhAGYAdAAtAGwAZQBuAG4AbwB4AC0AcwBpAHAALQByAGUAZwAtAHAAYQB5 AGwAbwBhAGQADQBEAG8AbgAZIHQAIAB1AHMAZQAgAFIARQBHAEkAUwBUAEUAUgANAEQAZQBmAGkA bgBlACAAYQAgAG4AZQB3ACAAbQBlAHQAaABvAGQALAAgAFMARQBUAEQAQQBUAEEADQBNAGEAeQBi AGUAIABwAGUAcgAgAHQAeQBwAGUAIABtAGUAdABoAG8AZABzAD8ADQBTAEUAVABQAE8ATABJAEMA WQAsACAAUwBFAFQAUwBDAFIASQBQAFQALAAgAFMARQBUAFAARABPAEMADQBSAGUAcwB0ACAAbwBm ACAAaABlAGEAZABlAHIAcwAgAGYAbwByACAAZABlAGYAaQBuAGUAIABjAG8AbgB0AGUAbgB0ACAA cAB1AHIAcABvAHMAZQAgAHMAdABhAHkAAAChD1YAAABcAAAAAAAAAAAAGAAAAAEAAAAAAB4AAAAC AAAAAAAwAAAAAAAAAAAAXAAAAAAAAgAYABgAAAAABAIAAAQUAB4AAAAACAIAAAgSADAAAAAADAIA AAwYAAAAqg8sAAAAFQAAAAAAAAAGAAAAAQAAAAEABQAAAAAAAAADAAAAAQAAAAEAnwAAAAAAAAAg AJ8PBAAAAAcAAAAAAKgPmQAAAFVzZSB0aGlzIGZvciB1cGxvYWRpbmcgcG9saWN5IGRhdGEgZm9y IFNJUCB0byBzZXJ2ZXJzDVRoZSB3b3JrIHN0YXlzIHdpdGhpbiBTSVAgZ3JvdXANU0lNUExFIHBh c3NlcyByZXF1aXJlbWVudCB0byBTSVAgdG8gZ2VuZXJhbGl6ZSBhbmQgbm90IHVzZSByZWdpc3Rl cgAAoQ8mAAAANgAAAAAAAAAAAGQAAAABAAAAAAA2AAAAAAAAAGQAAAAABAAAAAQAAOoDAAAAAA8A +APqCAAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAAAABgAPAHIAAAAAAA/wD///8AAAAA AP//AAD/mQAAAP//AP8AAACWlpYAYADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8A srKyAGAA8AcgAAAA////AAAAAAAzMzMAAAAAAN3d3QCAgIAATU1NAOrq6gBgAPAHIAAAAP//zAAA AAAAZmYzAICAAAAzmTMAgAAAAAAzzAD/zGYAYADwByAAAAD///8AAAAAAICAgAAAAAAA/8xmAAAA /wDMAMwAwMDAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAMDAwAAAZv8A/wAAAACZAABgAPAHIAAA AP///wAAAAAAgICAAAAAAAAzmf8Amf/MAMwAzACysrIAAACjDz4AAAABAP/9PwAAACIgAABkAAAA AAABAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8sAAAAAAMAABAAow98AAAABQD/ /T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAABwAAAP//7wAAAAAA////////IAAAAAAB AACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPADYAMAAAIAFACABQAAuwAQ BYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAB4AAAAAAAAAQAIAAAAABwAAAP// 7wAAAAAA////////DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAA BQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEAAQkAAAAAAQAgAQAAAAACAAEJ AAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCABAAAAABgAKMPDAAAAAEAAAAA AAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIAGAACAAAAAAAAAAIAFAADAAAA AAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABgAAQAAAAAAAAACABQAAgAA AAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBCQFAAAPAALwHAUAABAACPAIAAAA BgAAAAYEAAAPAAPwtAQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA BAAABQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMAC/A2AAAAfwABAAUAgABoarkAhwABAAAA gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAACAAbAB0BRQBA8AEfAQ AAAAAADDCwgAAAAAAAAAAQC5AA8ADfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBl ZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAAAQAAAAAADwAE 8BYBAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEABQCAABhtuQCBAQQAAAiDAQAAAAi/AQEA EQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAC ALkADwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRleHQg c3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlmdGggbGV2ZWwA AKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8A BPDQAAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAUAgABUcbkAgQEEAAAIgwEAAAAIvwEB ABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7ABYAaAEA8AEfAQAAAAAADDCwgAAAACAAAA BwG5AA8ADfBYAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAA AAIADgAAAPgPBAAAAAAAAAAAAKoPEgAAAAEAAAABAAAAAAABAAAAAAAAAA8ABPDSAAAAEgAK8AgA AAAFBAAAAAoAAIMAC/AwAAAAfwABAAUAgADIdrkAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEB AAkAAQICAAAIAAAQ8AgAAABgD7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAACQK5AA8ADfBaAAAA AACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAEAAgAAAAAAAgAOAAAA+g8E AAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE8NIAAAASAArwCAAAAAYEAAAACgAA gwAL8DAAAAB/AAEABQCAAJx7uQCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgA ABDwCAAAAGAPIBDQFIAQDwAR8BAAAAAAAMMLCAAAAAQAAAAIArkADwAN8FoAAAAAAJ8PBAAAAAQA AAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAA4AAADYDwQAAAAAAAAAAACq DxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATwSAAAABIACvAIAAAAAQQAAAAMAACDAAvwMAAAAIEB AAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA//// AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAgALoPHAAAAEQAZQBmAGEAdQBsAHQAIABEAGUA cwBpAGcAbgAPAO4D5AEAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAAAAAHAAAADwAMBJQBAAAP AALwjAEAADAACPAIAAAAAwAAAAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/AeAAAAfwAA AAQAgACsfpYDvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACgBbAB0BRwCA8AEfAQAAAAAADDCwgA AAAAAAAADwCWAw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAgAgAAUwAL 8B4AAAB/AAAABACAAHhWlgO/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAJAJYAMgE+ANDwAR8BAA AAAAAMMLCAAAAAEAAAAQAJYDDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAQgA AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4DZAIAAAIA7wMY AAAACAAAAA0ODgAAAAAAAAAAgAAAAAAHAAAADwAMBBQCAAAPAALwDAIAAEAACPAIAAAABAAAAAQQ AAAPAAPwpAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAEAAABQAA AA8ABPByAAAAEgAK8AgAAAACEAAAIAIAAFMAC/AeAAAAfwAAAAQAgAAcJsEDvwEAAAEA/wEAAAEA AQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQDBAw8ADfAMAAAAAACe DwQAAAAAAAAADwAE8HgAAAASAArwCAAAAAMQAAAgAgAAYwAL8CQAAAAEAAAAAAB/AAAABACAANgm wQO/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAOAEsAEQCwAPDwAR8BAAAAAAAMMLCAAAAAEAAAAO AcEDDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwcgAAABIACvAIAAAABBAAACACAABTAAvwHgAAAH8A AAAEAIAAlCfBA78BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ARwC9AUAA8PABHwEAAAAAAAwwsI AAAAAgAAAA4BwQMPAA3wDAAAAAAAng8EAAAAAgAAAA8ABPBIAAAAEgAK8AgAAAABEAAAAAwAAIMA C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gNeAgAAAgDvAxgAAAAIAAAA DQ4OAAAAAAAAAACAAAAAAAcAAAAPAAwEDgIAAA8AAvAGAgAAUAAI8AgAAAAEAAAABBgAAA8AA/Ce AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAYAAAFAAAADwAE8HIA AAASAArwCAAAAAIYAAAgAgAAUwAL8B4AAAB/AAAABACAANgswQO/AQAAAQD/AQAAAQABAwIEAAAA ABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAMEDDwAN8AwAAAAAAJ4PBAAAAAAA AAAPAATwcgAAABIACvAIAAAAAxgAACACAABTAAvwHgAAAH8AAAAEAIAAnDfBA78BAAABAP8BAAAB AAEDAwQAAAAAEPAIAAAA4ASwARALAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4BwQMPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPByAAAAEgAK8AgAAAAEGAAAIAIAAFMAC/AeAAAAfwAAAAQAgABYOMEDvwEA AAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADgBHAL0BQADw8AEfAQAAAAAADDCwgAAAACAAAADgHBAw8A DfAMAAAAAACeDwQAAAACAAAADwAE8EgAAAASAArwCAAAAAEYAAAADAAAgwAL8DAAAACBAQAAAAiD AQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAA gICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDuA5IDAAACAO8DGAAAAAgAAAANDg4AAAAAAAAAAIAA AAAABwAAAA8ADARCAwAADwAC8DoDAABgAAjwCAAAAAQAAAAFDAAADwAD8NICAAAPAATwKAAAAAEA CfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAwAAAUAAAAPAATwcgAAABIACvAIAAAAAgwA ACACAABTAAvwHgAAAH8AAAAEAIAA/FbBA78BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAgAGwAdAU UAQPABHwEAAAAAAAwwsIAAAAAAAAAA0AwQMPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK 8AgAAAADDAAAIAIAAFMAC/AeAAAAfwAAAAQAgAC4V8EDvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgA AADgBLABEAsADw8AEfAQAAAAAADDCwgAAAABAAAADgHBAw8ADfAMAAAAAACeDwQAAAABAAAADwAE 8KYBAACiDArwCAAAAAUMAAAACgAAowAL8DwAAACAAJxawQOFAAIAAACHAAYAAAC/AAIAAgCBAQQA AAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAABAFAAyVFXoMDwAN8DoBAAAA AJ8PBAAAAAQAAAAAAKAP8gAAAEkATgBWAEkAVABFACAAcwBpAHAAOgB1AEAAaAAgAFMASQBQAC8A MgAuADAADQBGAHIAbwBtADoAIABCAG8AYgAgADwAcwBpAHAAOgBiAG8AYgBAAGYAbwBvAD4ADQBU AG8AOgAgAFkAbwB1ACAAPABzAGkAcAA6AHUAQABoAD4ADQBDAG8AbgB0AGUAbgB0AC0AVAB5AHAA ZQA6ACAAYQBwAHAAbABpAGMAYQB0AGkAbwBuAC8AcwBkAHAADQANACYgDQBtAD0AbQBlAHMAcwBh AGcAZQAgADUAMAA2ADAAIABUAEMAUAAgAFMASQBQAA0AAACqDywAAAAqAAAAAAAAAAMAAAABAAAA AQAuAAAAAAAAAAQAAAABAAAAAQAbAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABDAAAAAwAAIMAC/Aw AAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAA AAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gNeAgAAAgDvAxgAAAAIAAAADQ4O AAAAAAAAAACAAAAAAAcAAAAPAAwEDgIAAA8AAvAGAgAAcAAI8AgAAAAEAAAABBwAAA8AA/CeAQAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAcAAAFAAAADwAE8HIAAAAS AArwCAAAAAIcAAAgAgAAUwAL8B4AAAB/AAAABACAAKxhwQO/AQAAAQD/AQAAAQABAwIEAAAAABDw CAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAMEDDwAN8AwAAAAAAJ4PBAAAAAAAAAAP AATwcgAAABIACvAIAAAAAxwAACACAABTAAvwHgAAAH8AAAAEAIAAaGLBA78BAAABAP8BAAABAAED AwQAAAAAEPAIAAAA4ASwARALAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4BwQMPAA3wDAAAAAAAng8E AAAAAQAAAA8ABPByAAAAEgAK8AgAAAAEHAAAIAIAAFMAC/AeAAAAfwAAAAQAgACYZcEDvwEAAAEA /wEAAAEAAQMDBAAAAAAQ8AgAAADgBHAL0BQADw8AEfAQAAAAAADDCwgAAAACAAAADgHBAw8ADfAM AAAAAACeDwQAAAACAAAADwAE8EgAAAASAArwCAAAAAEcAAAADAAAgwAL8DAAAACBAQAAAAiDAQUA AAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICA AAAAAAAAzJkAMzPMAMzM/wCysrIADwDuA+oBAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAA BwAAAA8ADASaAQAADwAC8JIBAACAAAjwCAAAAAMAAAAEJAAADwAD8CoBAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAACQAAAUAAAAPAATwcgAAABIACvAIAAAAAiQAACAC AABTAAvwHgAAAH8AAAAEAIAAxHnBA78BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAgAGwAdAUUAQP ABHwEAAAAAAAwwsIAAAAAAAAAA0AwQMPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPB4AAAAEgAK8AgA AAADJAAAIAIAAGMAC/AkAAAABAAAAAAAfwAAAAQAgABsesEDvwEAAAEA/wEAAAEAAQMDBAAAAAAQ 8AgAAADgBLAB0BQADw8AEfAQAAAAAADDCwgAAAABAAAADgDBAw8ADfAMAAAAAACeDwQAAAABAAAA DwAE8EgAAAASAArwCAAAAAEkAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM /wCysrIADwDuA14CAAACAO8DGAAAAAgAAAANDg4AAAAAAAAAAIAAAAAABwAAAA8ADAQOAgAADwAC 8AYCAACQAAjwCAAAAAQAAAAEIAAADwAD8J4BAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAA AAAAAAIACvAIAAAAACAAAAUAAAAPAATwcgAAABIACvAIAAAAAiAAACACAABTAAvwHgAAAH8AAAAE AIAAtH7BA78BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAgAGwAdAUUAQPABHwEAAAAAAAwwsIAAAA AAAAAA0AwQMPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADIAAAIAIAAFMAC/Ae AAAAfwAAAAQAgABwf8EDvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADgBLABEAsADw8AEfAQAAAA AADDCwgAAAABAAAADgHBAw8ADfAMAAAAAACeDwQAAAABAAAADwAE8HIAAAASAArwCAAAAAQgAAAg AgAAUwAL8B4AAAB/AAAABACAAHhvwQO/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAOAEcAvQFAAP DwAR8BAAAAAAAMMLCAAAAAIAAAAOAcEDDwAN8AwAAAAAAJ4PBAAAAAIAAAAPAATwSAAAABIACvAI AAAAASAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4DXgIA AAIA7wMYAAAACAAAAA0ODgAAAAAAAAAAgAAAAAAHAAAADwAMBA4CAAAPAALwBgIAAKAACPAIAAAA BAAAAAQsAAAPAAPwngEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAA LAAABQAAAA8ABPByAAAAEgAK8AgAAAACLAAAIAIAAFMAC/AeAAAAfwAAAAQAgABIg8EDvwEAAAEA /wEAAAEAAQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQDBAw8ADfAM AAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMsAAAgAgAAUwAL8B4AAAB/AAAABACAAASE wQO/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAOAEsAEQCwAPDwAR8BAAAAAAAMMLCAAAAAEAAAAO AcEDDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwcgAAABIACvAIAAAABCwAACACAABTAAvwHgAAAH8A AAAEAIAAwITBA78BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ARwC9AUAA8PABHwEAAAAAAAwwsI AAAAAgAAAA4BwQMPAA3wDAAAAAAAng8EAAAAAgAAAA8ABPBIAAAAEgAK8AgAAAABLAAAAAwAAIMA C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gNeAgAAAgDvAxgAAAAIAAAA DQ4OAAAAAAAAAACAAAAAAAcAAAAPAAwEDgIAAA8AAvAGAgAAsAAI8AgAAAAEAAAABDAAAA8AA/Ce AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAwAAAFAAAADwAE8HIA AAASAArwCAAAAAIwAAAgAgAAUwAL8B4AAAB/AAAABACAANSUwQO/AQAAAQD/AQAAAQABAwIEAAAA ABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAMEDDwAN8AwAAAAAAJ4PBAAAAAAA AAAPAATwcgAAABIACvAIAAAAAzAAACACAABTAAvwHgAAAH8AAAAEAIAA8DrBA78BAAABAP8BAAAB AAEDAwQAAAAAEPAIAAAA4ASwARALAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4BwQMPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPByAAAAEgAK8AgAAAAEMAAAIAIAAFMAC/AeAAAAfwAAAAQAgACAO8EDvwEA AAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADgBHAL0BQADw8AEfAQAAAAAADDCwgAAAACAAAADgHBAw8A DfAMAAAAAACeDwQAAAACAAAADwAE8EgAAAASAArwCAAAAAEwAAAADAAAgwAL8DAAAACBAQAAAAiD AQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAA gICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDuA14CAAACAO8DGAAAAAgAAAANDg4AAAAAAAAAAIAA AAAABwAAAA8ADAQOAgAADwAC8AYCAADAAAjwCAAAAAQAAAAENAAADwAD8J4BAAAPAATwKAAAAAEA CfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAADQAAAUAAAAPAATwcgAAABIACvAIAAAAAjQA ACACAABTAAvwHgAAAH8AAAAEAIAAlKvBA78BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAgAGwAdAU UAQPABHwEAAAAAAAwwsIAAAAAAAAAA0AwQMPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK 8AgAAAADNAAAIAIAAFMAC/AeAAAAfwAAAAQAgAA8rMEDvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgA AADgBLABEAsADw8AEfAQAAAAAADDCwgAAAABAAAADgHBAw8ADfAMAAAAAACeDwQAAAABAAAADwAE 8HIAAAASAArwCAAAAAQ0AAAgAgAAUwAL8B4AAAB/AAAABACAAPCuwQO/AQAAAQD/AQAAAQABAwME AAAAABDwCAAAAOAEcAvQFAAPDwAR8BAAAAAAAMMLCAAAAAIAAAAOAcEDDwAN8AwAAAAAAJ4PBAAA AAIAAAAPAATwSAAAABIACvAIAAAAATQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB 3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAz M8wAzMz/ALKysgAPAO4DcwgAAAIA7wMYAAAACAAAAA0ODgAAAAAAAAAAgAAAAAAHAAAADwAMBCMI AAAPAALwGwgAANAACPAIAAAAEgAAABQ4AAAPAAPwswcAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAA AAAAAAAAAAAAAgAK8AgAAAAAOAAABQAAAA8ABPByAAAAEgAK8AgAAAACOAAAIAIAAFMAC/AeAAAA fwAAAAQAgAA8ssEDvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADD CwgAAAAAAAAADQDBAw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8EwAAABCAQrwCAAAAAU4AAAACgAA YwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAFAEwAzA DJAPDwAE8EwAAABCAQrwCAAAAAY4AAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEA AAj/ARgAGAABAgIAAAgAABDwCAAAAFAEEBEQEZAPDwAE8EwAAABCAQrwCAAAAAc4AAAACgAAYwAL 8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAFAEYBVgFZAP DwAE8FIAAABCAQrwCAAAAAg4AAAACgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjR AQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAOAE8AzgEOAEDwAE8IMAAACiDArwCAAAAAk4AAAACgAA owAL8DwAAACAADC8wQOFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAgAABDwCAAAAKoDdg1gD8oEDwAN8BcAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFNV Qg8ABPBSAAAAQgEK8AgAAAAKOAAAQAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI 0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADQBVANsBDQBQ8ABPCDAAAAogwK8AgAAAALOAAAAAoA AKMAC/A8AAAAgABIh8EDhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI /wEAAAgAAQICAAAIAAAQ8AgAAADgBBAOpA8ABg8ADfAXAAAAAACfDwQAAAAEAAAAAACoDwMAAAAy MDIPAATwUgAAAEIBCvAIAAAADDgAAAAKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAA CNEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAAAZAETAVAAYPAATwqwAAAKIMCvAIAAAADTgAAAAK AACjAAvwPAAAAIAAELfBA4UAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAA CP8BAAAIAAECAgAACAAAEPAIAAAAygTGEbUV6gUPAA3wPwAAAAAAnw8EAAAABAAAAAAAqA8JAAAA Tk9UIHdpbmZvAACqDxoAAAAEAAAAAAAAAAUAAAABAAAAAQABAAAAAAAAAA8ABPBSAAAAQgEK8AgA AAAOOAAAQAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEBAAAA/wEYABgAAQIC AAAIAAAQ8AgAAADwBkARMBXwBg8ABPCDAAAAogwK8AgAAAAPOAAAAAoAAKMAC/A8AAAAgAAEccED hQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ 8AgAAAAABtARZBMgBw8ADfAXAAAAAACfDwQAAAAEAAAAAACoDwMAAAAyMDAPAATwUgAAAEIBCvAI AAAAEDgAAEAKAABzAAvwKgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACNEBAQAAAP8BGAAYAAEC AgAACAAAEPAIAAAAkAlAEQAVkAkPAATwjQAAAKIMCvAIAAAAETgAAAAKAACjAAvwPAAAAIAAaMvB A4UAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAA EPAIAAAAWgjGEX4WegkPAA3wIQAAAAAAnw8EAAAABAAAAAAAqA8NAAAAVXBsb2FkIHBvbGljeQ8A BPBSAAAAQgEK8AgAAAASOAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI0QEB AAAA/wEYABgAAQICAAAIAAAQ8AgAAACwCkARMBWwCg8ABPCGAAAAogwK8AgAAAATOAAAAAoAAKMA C/A8AAAAgADAzsEDhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEA AAgAAQICAAAIAAAQ8AgAAAB6CZYRcBSaCg8ADfAaAAAAAACfDwQAAAAEAAAAAACoDwYAAAAyMDAg T0sPAATwcgAAABIACvAIAAAAFDgAACACAABTAAvwHgAAAH8AAAAEAIAA5M3BA78BAQABAP8BAQAB AAEDAwQAAAAAEPAIAAAA4ASwARALAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4BwQMPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABOAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAA AMyZADMzzADMzP8AsrKyAA8A7gPEAgAAAgDvAxgAAAAIAAAADQ4OAAAAAAAAAACAAAAAAAcAAAAP AAwEdAIAAA8AAvBsAgAA4AAI8AgAAAAEAAAABTwAAA8AA/AEAgAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAAA8AAAFAAAADwAE8HIAAAASAArwCAAAAAI8AAAgAgAAUwAL 8B4AAAB/AAAABACAAFQclgO/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAA AAAAAMMLCAAAAAAAAAANAJYDDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAABDwA ACACAABTAAvwHgAAAH8AAAAEAIAA7ACWA78BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ARwC9AU AA8PABHwEAAAAAAAwwsIAAAAAgAAAA4BlgMPAA3wDAAAAAAAng8EAAAAAgAAAA8ABPDYAAAAEgAK 8AgAAAAFPAAAIAoAAGMBC/CEAAAAfwABAAUAgADwHJYDgQAwZQEAggCYsgAAgwAwZQEAhACYsgAA hQAAAAAAhgAAAAAAhwAAAAAAiAAAAAAAiQAAAAAAigAAAAAAiwAAAAAAvwAQAB8AgQEEAAAIgwEA AAAIvwEAABEAwAEBAAAI/wEAAAkAAQICAAAIAQMDBAAAiAMAAAAAAAAQ8AgAAADgBLABEAsADw8A EfAQAAAAAADDCwgAAAABAAAADgGWAw8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAA AAE8AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkA AAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDuA14CAAAC AO8DGAAAAAgAAAANDg4AAAAAAAAAAIAAAAAABwAAAA8ADAQOAgAADwAC8AYCAADwAAjwCAAAAAQA AAAEQAAADwAD8J4BAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAEAA AAUAAAAPAATwcgAAABIACvAIAAAAAkAAACACAABTAAvwHgAAAH8AAAAEAIAASNrBA78BAAABAP8B AAABAAEDAgQAAAAAEPAIAAAAgAGwAdAUUAQPABHwEAAAAAAAwwsIAAAAAAAAAA0AwQMPAA3wDAAA AAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADQAAAIAIAAFMAC/AeAAAAfwAAAAQAgAAE28ED vwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADgBLABEAsADw8AEfAQAAAAAADDCwgAAAABAAAADgHB Aw8ADfAMAAAAAACeDwQAAAABAAAADwAE8HIAAAASAArwCAAAAARAAAAgAgAAUwAL8B4AAAB/AAAA BACAAMDbwQO/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAOAEcAvQFAAPDwAR8BAAAAAAAMMLCAAA AAIAAAAOAcEDDwAN8AwAAAAAAJ4PBAAAAAIAAAAPAATwSAAAABIACvAIAAAAAUAAAAAMAACDAAvw MAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8Acg AAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4DXgIAAAIA7wMYAAAACAAAAA0O DgAAAAAAAAAAgAAAAAAHAAAADwAMBA4CAAAPAALwBgIAAAABCPAIAAAABAAAAAREAAAPAAPwngEA AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAARAAABQAAAA8ABPByAAAA EgAK8AgAAAACRAAAIAIAAFMAC/AeAAAAfwAAAAQAgABo7cEDvwEAAAEA/wEAAAEAAQMCBAAAAAAQ 8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAADQDBAw8ADfAMAAAAAACeDwQAAAAAAAAA DwAE8HIAAAASAArwCAAAAANEAAAgAgAAUwAL8B4AAAB/AAAABACAACTuwQO/AQAAAQD/AQAAAQAB AwMEAAAAABDwCAAAAOAEsAEQCwAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAcEDDwAN8AwAAAAAAJ4P BAAAAAEAAAAPAATwcgAAABIACvAIAAAABEQAACACAABTAAvwHgAAAH8AAAAEAIAA4O7BA78BAAAB AP8BAAABAAEDAwQAAAAAEPAIAAAA4ARwC9AUAA8PABHwEAAAAAAAwwsIAAAAAgAAAA4BwQMPAA3w DAAAAAAAng8EAAAAAgAAAA8ABPBIAAAAEgAK8AgAAAABRAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICA gAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gNeAgAAAgDvAxgAAAAIAAAADQ4OAAAAAAAAAACAAAAA AAcAAAAPAAwEDgIAAA8AAvAGAgAAIAAI8AgAAAAEAAAABEgAAA8AA/CeAQAADwAE8CgAAAABAAnw EAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABIAAAFAAAADwAE8HIAAAASAArwCAAAAAJIAAAg AgAAUwAL8B4AAAB/AAAABACAAIBtlgO/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAE DwAR8BAAAAAAAMMLCAAAAAAAAAANAJYDDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAI AAAAA0gAACACAABTAAvwHgAAAH8AAAAEAIAAKG6WA78BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA 4ASwARALAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4BlgMPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBy AAAAEgAK8AgAAAAESAAAIAIAAFMAC/AeAAAAfwAAAAQAgADkbpYDvwEAAAEA/wEAAAEAAQMDBAAA AAAQ8AgAAADgBHAL0BQADw8AEfAQAAAAAADDCwgAAAACAAAADgGWAw8ADfAMAAAAAACeDwQAAAAC AAAADwAE8EgAAAASAArwCAAAAAFIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69 aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPM AMzM/wCysrIAAAByF0gAAAABABABAAAAABcwAAAJOQAA9ToAAGE9AADHPwAAYUMAAMdFAAC5RwAA H0oAAIVMAADrTgAAUVEAAMxZAACYXAAA/l4AAGRhAAAAAPUPHAAAAAABAACcCgADAAAAAMpjAAAB AAAAEQAAAAEAHQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAAoBgAA CwAAAAEAAABgAAAAAgAAAGgAAAAEAAAAiAAAAAgAAACYAAAACQAAAKwAAAASAAAAuAAAAAoAAADY AAAADAAAAOQAAAANAAAA8AAAAA8AAAD8AAAAEQAAAAQBAAACAAAA5AQAAB4AAAAYAAAASU0gYW5k IFBSRVMgb3BlbiBpc3N1ZXMAHgAAAAgAAABqZHJvc2VuAB4AAAAJAAAAcmpzcGFya3MARVMgHgAA AAIAAAA1AHNwHgAAABUAAABNaWNyb3NvZnQgUG93ZXJQb2ludABlcwBAAAAAMDnmsQ0AAABAAAAA wLgVQ4eywAFAAAAA0BxhkfuywAEDAAAAngMAAEcAAAAcBQAA/////wMAAAAIAIkQZwwAAAEACQAA A4YCAAAGACoAAAAAABEAAAAmBg8AGAD/////AAAQAAAAAAAAAAAAwAMAANACAAAJAAAAJgYPAAgA /////wIAAAAXAAAAJgYPACMA/////wQAGwBUTlBQFAAUAbkAMgAAAP//TwAUAAAATQBpADEACgAA ACYGDwAKAFROUFAAAAIA9AMJAAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5QUAQADAABAAAA AQAAAAAAAAAFAAAACwIAAAAABQAAAAwC0ALAAwUAAAAEAQ0AAAAHAAAA/AIAAP///wAAAAQAAAAt AQAACAAAAPoCBQABAAAAAAAAAAQAAAAtAQEABAAAAC0BAAAJAAAAHQYhAPAA0ALAAwAAAAAEAAAA LQEAAAcAAAD8AgAA////AAAABAAAAC0BAgAEAAAA8AEAAAgAAAD6AgAAAAAAAAAAAAAEAAAALQEA ABAAAAAmBg8AFgD/////AABHAAAAjwIAABEBAADBAgAACAAAACYGDwAGAP////8BABwAAAD7AgAA AAAAAAAAAAAAAAAAAAAAAADcEgCRcvV3QAAAAMEGCtcNVfV3FlX1dwEAAAAAADAABAAAAC0BAwAF AAAACQIAAAACBQAAABQCAAAAAAUAAAACAQIAAAAQAAAAJgYPABYA/////wAARwEAAI8CAAB5AgAA wQIAAAgAAAAmBg8ABgD/////AQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAACAQIAAAAHAAAA/AIB AAAAAAAAAAQAAAAtAQQABAAAAC0BAQAHAAAAGwRpAXkD8ABIAAQAAAAtAQIABAAAAC0BAAAFAAAA CQIAAAACBQAAABQCAAAAABwAAAD7AsX/AAAAAAAAkAEAAAAAAEAAAFRpbWVzIE5ldyBSb21hbgAN VfV3FlX1dwEAAAAAADAABAAAAC0BBQAEAAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4B GAAAAAUAAAACAQEAAAAqAAAAMgpBAa8AFwAAAElNIGFuZCBQUkVTIG9wZW4gaXNzdWVzABMANAAP ABoAHgAeAA4AIQAnACQAIQAPABwAHgAaAB0ADwAQABcAFwAeABkAFwAFAAAALgEBAAAABQAAAAIB AgAAAAUAAAACAQIAAAAEAAAALQEEAAQAAAAtAQEABwAAABsEUQIxA5gBkAAEAAAALQECAAQAAAAt AQAABQAAAAkCAAAAAgUAAAAUAgAAAAAcAAAA+wLV/wAAAAAAAJABAAAAAABAAABUaW1lcyBOZXcg Um9tYW4ADVX1dxZV9XcBAAAAAAAwAAQAAAAtAQMABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAA AAUAAAAuARgAAAAFAAAAAgEBAAAAIgAAADIKxgE0ARIAAABKb25hdGhhbiBSb3NlbmJlcmcRABUA FQATAAwAFQATABUACwAdABUAEQASABUAFwASAA4AFQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAC AQIAAAAEAAAALQEBAAQAAAAtAQQAHAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAAAAAAoA AAAEAAAAAAAFAAAAAQAAAAAAMAAEAAAALQEFAAQAAADwAQMADwAAACYGDwAUAFROUFAEAAwAAAAA AAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8A AAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAABAMAABAAAAABAAAA iAAAAAMAAACQAAAADwAAAKgAAAAEAAAAvAAAAAYAAADEAAAABwAAAMwAAAAIAAAA1AAAAAkAAADc AAAACgAAAOQAAAAXAAAA7AAAAAsAAAD0AAAAEAAAAPwAAAATAAAABAEAABYAAAAMAQAADQAAABQB AAAMAAAApAIAAAIAAADkBAAAHgAAAA8AAABPbi1zY3JlZW4gU2hvdwBzHgAAAAwAAABkeW5hbWlj c29mdAADAAAAPmQAAAMAAACkAAAAAwAAAA8AAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAA 7Q4JAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAABEAAAAQAAAAVGltZXMgTmV3 IFJvbWFuAA8AAABEZWZhdWx0IERlc2lnbgAYAAAASU0gYW5kIFBSRVMgb3BlbiBpc3N1ZXMAGgAA AE1lc3NhZ2luZzogc2Vzc2lvbiBvciBub3QAGgAAAE1lc3NhZ2luZzogc2Vzc2lvbiBvciBub3QA HQAAAEhvdyBpcyBtZXNzYWdlIHNlc3Npb24gZG9uZT8AHQAAAEhvdyBpcyBtZXNzYWdlIHNlc3Np b24gZG9uZT8AGQAAAFdoYXQgYWJvdXQgc2Vzc2lvbi1sZXNzPwAMAAAAQ29tcGFyaXNvbnMAFAAA AERlYWxpbmcgd2l0aCBOQVQvRlcAGwAAAEF1dGhvcml6YXRpb24gZm9yIHByZXNlbmNlAA0AAABO ZXcgcHJvcG9zYWwACwAAAEJhc2ljIGZsb3cACQAAAEJlbmVmaXRzABEAAABIb3cgZG8gd2UgZG8g aXQ/ABAAAABVcGxvYWRpbmcgc3R1ZmYACQAAAFByb3Bvc2FsAAwQAAAGAAAAHgAAAAsAAABGb250 cyBVc2VkAAMAAAABAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNs aWRlIFRpdGxlcwADAAAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9g8gAAAAFAAA AF/AkeMaZAAACAD0AwMAwQNyanNwYXJrcwgAAAByAGoAcwBwAGEAcgBrAHMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAA AAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA FAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAi AAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAA AAAxAAAAMgAAAP7///80AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAA/v///zwAAAA9AAAAPgAA AD8AAABAAAAAQQAAAEIAAAD+////RAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAP7////9//// TQAAAP7///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8D AAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAQwB1AHIA cgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDAAAA ABAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAKAACAQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADMAAAAAEAAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBu AHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD5kAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1 AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7AAAAABAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_000_01C0C132.C376C9A1 Content-Type: application/vnd.ms-powerpoint; name="SIMPLE 50th.ppt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SIMPLE 50th.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////FgAAAP7///8EAAAABQAAAAYAAAAHAAAAMQAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAD+/////v///xgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADAAAAD+////MgAAAP7///////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAOAYMZ0ywcAB AwAAAAAOAAAAAAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABIAAgH/////BQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA1QkAAAAAAABQAG8AdwBlAHIAUABvAGkAbgB0ACAARABvAGMAdQBt AGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf////8EAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAADcGgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJ AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAAIA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFwAAAOAzAAAAAAAAAQAA AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA/v///ykAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA/v////7///////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////9gIRvw YQYAAN8VbjZI/X+B+b4bzHsU9KqGHAAA/hQAAF4AAACKFwAAEAEAAPjKDwDoTwQALwYAAAD+eNrN Wc1rJEUUf1NT06np9NSkOz09nU6np0QQEYT8CYG9iuTgwdOag39A/gAhFw/rIuTiPXtfMODFYw6C B1GC4EHYQ0BEQZAo7mFRca2vro/+SDrBjft2J1P15nW9X733qt6r6hFMAcb3KACCD2fAKeaf14I5 5PCcE8AG/JMC3Ofch0veG4F4QkoQKYF4b6k5r0oOhm145+39/RQOf4NdMSYfAH6kD0HSs1BLh1JK aH469scc895cc1IphSECrlp+BE34Zx3d59hEK0KfwcdItPBITGJDP5vpOTznAN7jvI840PlIPb02 wvyvmPO9OYOvefsNeCTH/hQeoAOAxeu8/UjyhV4if9srwNAr+iP58CVsbGzAWxtfAWMM3mXfwO7u Lry/+y3s7e3B4d53sM8n+8H+93BwcAAPDp7A4eEhfHJ4AUdHR3By9AMcHx/D4+Of4OTkBD4/+QVO T0/hi9Nf4ezsDM7Pfofz83N4cv4ULi4u4OeLZ3B5eQl/XP4l5ggRIVwtK3GQi+88YXmgG0UkGhUO JYMFTIlQlIqvBCPZSxkq1c+CMiQfyjHWw1ViVqwIcMJuRVh9JWmpYFGSJXWDykakVZMSCtWQf5F6 MA9o4HD1F80KPVwEtdzt8Olhac60HSHUsBBJtCGVDImUTXRX62UoTNr4SK4mxUdRcgnKbodPT4tm pVabgNRX8YYCSmudOOnCF+KyjS/Kc9nI+UqR/kUtxUWXQcNWFJAoVNLKbFxtVDeU/Qqq5xBkVMUf yPijOixzpTpAgcCZ6vgLcKZxgQpikvp6KaAOfBSCssFSNmFlcVPL59UVPzaHq3K/y7etzucyuG0g /JdUAqQ9PxWo96fuoXKa8H9FNUy8EMJJVl4thMDG2c5yM46X2/ZHANeC0E3KHWWCDSegXpzUFLrO CQ0bRdqhec0h1rkIzNqYT0aKJvHKjp0Ow5f4PGQRIsu0E8e+OCl78HE5HZ2L8cjSeMvAR+UQfKTF DSoTPw1Li8hukswzbXx81jopLEc+LYwB8QB8uIOtlUQOK+qDx6nswCfmphyxPWrSTh2B1sO9+JJO flJ7yFLtlA5CDr465CJj83Xt1zieaz+v2eiprsFnXRgWrEq8cCvaoWosirKKVwd1L2vZrzJT2lGY ZqK90stELePAMWAfvsRfoImLJvJEo1qrpEpvv7XRmvioMeVCWU/jUPjmRhlq4ctdMhq6slDLiSyt O629tYkPmWYsEcX1RiN7U2uMsqmrGwPpSGw1MONEa97qGnwybKiDSG8qbNPBl1uhPnwF9JF1b2Qj gPRJJw18iVW9iAXtMHevcfCRK/HlV+AztsLGaL34aANfZDcBn2YOvsLBc3N89U6HWWgcHPRJZw18 xHGdS9vu+mBOqFwXf60UYmwVGqQhC/vE8wY+1Gm/nU29AW45yvMr8dXBjxNKxf+6T5ndacyuUpl6 QRY7CTV4m+vDS4mKpmsmf0zZYHyh8aJvzyx1lmrt1tQsp8Kvb8gAfDa9TVbD8aW+xrAVdMSBERpz h/7qz26Cb7Ziw/GZHCuqkMpkjNT4lLo4bAIMS3EI7si/xI6aduIbb7Kb4OssSEjDrtZOuKcK6lq/ /vqI46nOvrGH7+r84dbIbsEUeHnPOrvoKGC8+i+wD7T3l023PBiy/7nKDfGTbumXfc5iaWcc2pHf kp79Oba1zKD8oY+2vnOrViFQul0/iehzYn/+ZVNOawt3fx6zoflXF2sUu2WgW5mW/iqS6za3CM11 UH/9wryYUw529o5yAD4RC5nccPNhx8uqkNLO+TLvOBpgB9JEtbdcfN3134s5ijfxFVbVmrMm1t38 EToxetf4ZJQWbgHNI3A188oD3Hn+uCN8uVlcq57zW+ku8TvHJyKw5/w7t8ujEhdnZZEWd4+vst5b 9+DNbGbN5B1iQCG8e3zCf/WtzXJirzdiW5nIvS8KU0zhf8AnEJj9ajETy3iyvljZ2yOVmyhJEcP2 SPli8FX18IVXvKG+69Aq6Lm5vFNK+65Ji5cCHo/BwLs5NLgRStnLQbTrZoJEzZtX9UZMvF0j+t1Z IN+dqfdef6KJefMmdvU3eWeNf/+NfO6o462dS/5bPvHsWPL/BSY0dwgAbh7wZAMAAPRpiLCmLf3/ FWrz/gxY1lD/iVBORw0KGgoAAAANSUhEUgAAAGQAAAAXCAMAAADKihoJAAAAYFBMVEX///8AAADk 5OTW1tYxMTG3t7fHx8dpaWmHh4d1dXVbW1uoqKj/r6+Xl5caGhr/AgLw8PD/bm4MDAxERET5+fnf 6en/6ur/y8v8/Pz29fX+/v7g9PQGBgb5/////v60ycn3N9dDAAAAAWJLR0QAiAUdSAAAAAxjbVBQ SkNtcDA3MTIAAAADSABzvAAAAolJREFUSEvtlOFy4jAMhBUZ23JcBxNCm1B69/5vebsOtNChPWb6 t54hCY6iT1pJFvld3ygQSvi5Prvt7vkbLzn7NP+U8rLdbnf3ndTgpKYqebr73jYbe5D+/DXEeT9p WuSPiLsj2b7r+gchArm+MHU+z86aVuZvbUIpte+6KN47QTALfuoKrarzQXEPIUwhO9GM3dfD6xtC pXVbh9puk9bFqYSmiI+3mWiHdeq6hIdRNl0XkBZXL7nd9yK4jvjFtgvbIgPfDAfASrbCOMwzLk3J knMJt5W9Lg9ruO4SXU14kjNkIHEPb0a/lzUesZP5EbB7WRLyQ/AakZchfG/OLeJSpgI3EGly4Svd dAMhCUk0d5oYPN4YTHruVkIM9gGgmerMyCQzG4+iuyaXfpKLQQmEiE2qAdERgt1xgu8DfRNSGAd3 F0KAbpDqIvp1RkIMXGMGhIW/C2mZ4JIHyAYY3Z1Q94y9D0h/DenloCpHiwahXOJozGb/hTCdAUV9 h0C8tQPOmXyCNMXVIrIIDSIPQCD0fuz8BdJarb+W6xZyNGsd5JOhqR6AtJpQDMj8AbkuPGtyA4kO SbppgVYxHFtN6qeavOyerlrYUyGp1GaUd0jrLuDvyMXuImTy6No5BWmzG9DHwY7nwr/xAHpZKWyS Vfk2YcMKQbOeZvznVpu/SwufWguzJXHfYCyQwKUoBX0c2hGM7tK/10cpXUGmXuiU832GdNN5Kvcc U+PxRrSyC9aJH1Hx6BfPLKxoKJNoiRzDmsxeF2Ry0YsHtCwoIb87wWKp9SgVOzVnpwFnlKrOVXXh g6hzMMZh2I4n/FtnGw8oPgxgwlMP1+ens1rvky9SrNjNYXD17vcRCvwDxr0d+d1wnRcAAAAASUVO RK5CYIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwDoA/4KAAAB AOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAAkEoAAAAAAA CgQEAAAABAAAAA8A1w9CAAAAAADTDwQAAAABAAAAAAC6Dy4AAAByAHMAcABhAHIAawBzAEAAZAB5 AG4AYQBtAGkAYwBzAG8AZgB0AC4AYwBvAG0ADwDXD0IAAAAAANMPBAAAAAIAAAAAALoPLgAAAGoA bwBuAC4AcABlAHQAZQByAHMAbwBuAEAAbABlAHYAZQBsADMALgBjAG8AbQAPAPIDrgEAAC8AyA8M AAAAMADSDwQAAAABAAAADwDVB+QAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0A YQBuAAAAQDW5AJzaEgCE2hIAdscLMAgAAAAAAAAAnNoSACjdDTAAAAQAEAC3D0QAAABBAHIAaQBh AGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAEA1uQCc2hIAhNoSAHbHCzAIAAAAAAAAAJzaEgAo3Q0w AGgGIiAAtw9EAAAAQQByAGkAYQBsACAATgBhAHIAcgBvAHcAAABhAG4AAABANbkAnNoSAITaEgB2 xwswCAAAAAAAAACc2hIAKN0NMABoBiIAAKQPCgAAAIAAYAAAAP////8AAKUPDAAAAAAAAAguAAAA BwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAA AAAAQAIAAAAABwAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAA AAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsE5AAAAA8AAPDcAAAAAAAG8DAAAAACFAAABQAA ABEAAAAEAAAAAQAAAAcAAAACAAAABgAAAAMAAAAEAAAABAAAAAQAAAAvAAHwWAAAADIAB/AkAAAA AwTfFW42SP1/gfm+G8x7FPSq/wBpBgAAAQAAAAAAAAAAAMgAYgAH8CQAAAAGBvRpiLCmLf3/FWrz /gxY1lD/AGwDAAABAAAAaQYAAAAAyABjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8B CAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAA AAAAAAAAAACAAAAAAA8A0Ac3AQAAHwAUBBwAAAAAABUEFAAAALoddewAypo7Mk7NyQDKmjsBAQAB DwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAQQAAAGQAAABBAAAAZAAAAHbHCzAIAAAAAAAAAJDa EgAAAAAAAAAAAKb////g/v//AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABACwAAHwAH BDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAABg8w0wTN4SAAAAAAAsNrkAAAAAAAAAAAAAAAAA AAAAAAABEgAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAGDzDTBM3hIAAAAAACw2uQAA AAAAAAAAAAAAAAAAAAAAAAESAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAPAPAPEQYAAAAA 8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPRgAAAFNJTVBMRSBXRwtT SVAgZm9yIEluc3RhbnQgTWVzc2FnaW5nIGFuZCBQcmVzZW5jZQtMZXZlcmFnaW5nIEV4dGVuc2lv bnMAAKEPJgAAAEcAAAAAAAAAAAAKAAAAAAAAADwAAAAAAAMAAgAjAAEAAAAAAAAAAACqDwoAAABH AAAAAQAAAAAAEACfDwQAAAAFAAAAAACoD3YAAABDaGFpcnM6DVJvYmVydCBTcGFya3MgKHJzcGFy a3NAZHluYW1pY3NvZnQuY29tKQ1Kb24gUGV0ZXJzb24gKGpvbi5wZXRlcnNvbkBsZXZlbDMuY29t KQ01MHRoIElFVEYgKE1pbm5lYXBvbGlzIE1OIDMvMDEpAAChDyQAAAB3AAAAAAAAAAAAWQAAAAAA AAACAAAAAAAIAB4AHAAAAAAAAAAAAKoPLgAAABcAAAABAAAAAAAXAAAAAAAAABAAAAABAAAAAAAX AAAAAAAAACIAAAABAAAAAAAPAPIPGAAAAAAA8w8QAAAAAAAAAAEAAAAEAAAACCEOMAAA3w8IAAAA FwAAAC4AAAAPAPIPGAAAAAAA8w8QAAAAAAAAAAIAAAAEAAAACCEOMAAA3w8IAAAAPgAAAFUAAAAA APMDFAAAAAQAAAAAAAAAAgAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABTSU1QTEUgQWdl bmRhAACqDwoAAAAOAAAAAQAAAAAAEACfDwQAAAABAAAAAACoD1sAAABBZ2VuZGEgYmFzaGluZw1C bHVlIFNoZWV0cyAvIE1pbnV0ZSB0YWtlcg1XRyBTdGF0dXMgYW5kIERlbGl2ZXJhYmxlcw1PcGVu IElzc3VlcyBkaXNjdXNzaW9uAACqDwoAAABcAAAAAQAAAAAAAADzAxQAAAAFAAAAAAAAAAIAAAAC AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8JAAAAV0cgU3RhdHVzAACqDwoAAAAKAAAAAQAAAAAAEACf DwQAAAABAAAAAACgD1ACAABTAEkATQBQAEwARQAgAGkAcwAgAG4AbwB3ACAAbwBmAGYAaQBjAGkA YQBsAGwAeQAgAGEAIABXAG8AcgBrAGkAbgBnACAARwByAG8AdQBwAA0AJiBhAG4AZAAgAHQAaABl ACAAZABlAGwAaQB2AGUAcgBhAGIAbABlAHMAIABhAHIAZQAgAGgAYQByAGQAIAB1AHAAbwBuACAA dQBzAA0ATQBhAHIAIAAwADEAIABzAHUAYgBtAGkAcwBzAGkAbwBuACAAbwBmACAAUwBJAFAAIABJ AE0AIABkAHIAYQBmAHQADQBkAHIAYQBmAHQALQByAG8AcwBlAG4AYgBlAHIAZwAtAGkAbQBwAHAA LQBpAG0ALQAwADEALgB0AHgAdAANAE0AYQB5ACAAMAAxACAAcwB1AGIAbQBpAHMAcwBpAG8AbgAg AG8AZgAgAFMASQBQACAAcAByAGUAcwBlAG4AYwBlACAAZAByAGEAZgB0AA0AZAByAGEAZgB0AC0A cgBvAHMAZQBuAGIAZQByAGcALQBpAG0AcABwAC0AcAByAGUAcwBlAG4AYwBlAC0AMAAxAC4AdAB4 AHQADQBCAG8AdABoACAAbwBmACAAdABoAGUAcwBlACAAZAByAGEAZgB0AHMAIABzAGgAbwB1AGwA ZAAgAGIAZQAgAFcARwAgAGkAdABlAG0AcwANAFMAZQB2AGUAcgBhAGwAIABvAHAAZQBuACAAaQBz AHMAdQBlAHMAIABvAG4AIABiAG8AdABoACAAZAByAGEAZgB0AHMAAAChD3YAAABQAAAAAAAAAAAA IgAAAAEAAAAAAB8AAAACAAAAAAAoAAAAAQAAAAAAJQAAAAIAAAAAAEsAAAAAAAAAAABQAAAAAAAA ACIAAAAABAAAAQQfAAAAAAQAAAEEKAAAAAAIAAABCCUAAAAADAAAAQxLAAAAABAAAAEQAACqDwoA AAApAQAAAQAAAAAAAADqAwAAAAAPAPgD1AgAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAA AAAAYADwByAAAAAAAP8A////AAAAAAD//wAA/5kAAAD//wD/AAAAlpaWAGAA8AcgAAAA////AAAA AACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgBgAPAHIAAAAP///wAAAAAAMzMzAAAAAADd3d0AgICA AE1NTQDq6uoAYADwByAAAAD//8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA ////AAAAAACAgIAAAAAAAP/MZgAAAP8AzADMAMDAwABgAPAHIAAAAP///wAAAAAAgICAAAAAAADA wMAAAGb/AP8AAAAAmQAAYADwByAAAAD///8AAAAAAICAgAAAAAAAM5n/AJn/zADMAMwAsrKyAAAA ow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAAQAIAAAAABwAAAP//7wABAAEA//// ////JgAAAAAFAAAQAKMPfgAAAAUA//0/AAEAIiAAAGQAAAAAAAAAZAAUAAAA2AAAAEACAAAAAAcA AAD//+8AAQABAP///////xkAAAAAAQAAgAUAABMg1AEgAQAAAgAWAIAFAAAiINACQAIAAAAAgAUA ABMg8ANgAwEAAwAAAAIAFACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAA AABkAB4AAAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////DAAAAAABAAAABQAAIAEgAQAAAAAA BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAA AAAAAAEAAQkAAAAAAQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkA AAAAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAFQABAAAA AAAAAAIAFAACAAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAA AAAAAAACABMAAQAAAAAAAAACABIAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAA DwAMBAwFAAAPAALwBAUAABAACPAIAAAABgAAAAYEAAAPAAPwnAQAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMA C/A2AAAAfwABAAUAgABkbLkAhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAAAQC5AA8ADfBUAAAAAACfDwQA AAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAA AAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8BYBAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEA BQCAABRvuQCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAOAEsAHQ FAAPDwAR8BAAAAAAAMMLCAAAAAEAAAACALkADwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENs aWNrIHRvIGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1G b3VydGggbGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwA AAAEAAAAqg8KAAAAUwAAAAEAAAAAAA8ABPDIAAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwAB AAUAgAC4c7kAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7AB YAaAEA8AEfAQAAAAAADDCwgAAAACAAAABwG5AA8ADfBQAAAAAACfDwQAAAAEAAAAAACgDwIAAAAq AAAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADgAAAPgPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAA AAAPAATwygAAABIACvAIAAAABQQAAAAKAACDAAvwMAAAAH8AAQAFAIAArHm5AIEBBAAACIMBAAAA CL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAYA+wB9AOgBAPABHwEAAAAAAAwwsIAAAA AwAAAAkCuQAPAA3wUgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAAB AAIAAAAAAAIADgAAAPoPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAPAATwygAAABIACvAIAAAA BgQAAAAKAACDAAvwMAAAAH8AAQAFAIAA+H25AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACAAAEPAIAAAAYA8gENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgCuQAPAA3wUgAAAAAA nw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAAANgPBAAA AAAAAAAAAKoPCgAAAAIAAAABAAAAAAAPAATwSAAAABIACvAIAAAAAQQAAAAMAACDAAvwMAAAAIEB AAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA//// AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAgALoPHAAAAEQAZQBmAGEAdQBsAHQAIABEAGUA cwBpAGcAbgAPAO4D1gIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAAAAAHAAAADwAMBIYCAAAP AALwfgIAACAACPAIAAAABQAAAAUIAAAPAAPwFgIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMAC/AeAAAAfwAA AAQAgACkybkAvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACgBbAB0BRwCA8AEfAQAAAAAADDCwgA AAAAAAAADwC5AA8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAgAgAAUwAL 8B4AAAB/AAAABACAAGDKuQC/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAJAJ4AHQFAAPDwAR8BAA AAAAAMMLCAAAAAEAAAAQALkADwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwZgAAALIECvAIAAAABAgA AAAKAACDAAvwMAAAAARBAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8C AAACABMAIvEGAAAAvwMAAAAEAAAQ8AgAAACQACATrBVCAQ8ABPB8AAAAsgQK8AgAAAAFCAAAAAoA AEMAC/BUAAAAfwCAAIAABEECAAAABcE8AAAABgEBAAAARAA6AFwAVwBlAHIAawBlAFwAZAB5AG4A YQBtAGkAYwBzAG8AZgB0AF8AbABvAGcAbwAuAGcAaQBmAAAAAAAQ8AgAAACQAJAAIARiAQ8ABPBI AAAAEgAK8AgAAAABCAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKy AA8A7gPkAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAA MAAI8AgAAAADAAAAAwwAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAAAMAAAFAAAADwAE8HIAAAASAArwCAAAAAIMAAAgAgAAUwAL8B4AAAB/AAAABACAAPT6 uQC/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAAN ALkADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAwwAACACAABTAAvwHgAAAH8A AAAEAIAAnPu5AL8BAAABAP8BAAABAAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsI AAAAAQAAAA4AuQAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABDAAAAAwAAIMA C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPkAQAAAgDvAxgAAAABAAAA DQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAQAAI8AgAAAADAAAAAxAAAA8AA/Ak AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAQAAAFAAAADwAE8HIA AAASAArwCAAAAAIQAAAgAgAAUwAL8B4AAAB/AAAABACAAExDBgS/AQAAAQD/AQAAAQABAwIEAAAA ABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAAYEDwAN8AwAAAAAAJ4PBAAAAAAA AAAPAATwcgAAABIACvAIAAAAAxAAACACAABTAAvwHgAAAH8AAAAEAIAACEQGBL8BAAABAP8BAAAB AAEDAwQAAAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4ABgQPAA3wDAAAAAAA ng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABEAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGO n4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAA AMyZADMzzADMzP8AsrKyAAAAchcYAAAAAQBQAAAAAAAGCwAA4hMAAMAWAACsGAAAAAD1DxwAAAAA AQAAnAoAAwAAAACYGgAAAQAAAAUAAAABAI4EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBt AG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAALgDAAAAAAAAQwB1AHIAcgBl AG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA AgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3AAAAOAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAA AQAAAOCFn/L5T2gQq5EIACsns9kwAAAAsDMAAAsAAAABAAAAYAAAAAIAAABoAAAABAAAAIgAAAAI AAAAoAAAAAkAAAC0AAAAEgAAAMAAAAAKAAAA4AAAAAwAAADsAAAADQAAAPgAAAAPAAAABAEAABEA AAAMAQAAAgAAAOQEAAAeAAAAGAAAAFBvd2VyUG9pbnQgUHJlc2VudGF0aW9uAB4AAAANAAAAam9u IHBldGVyc29uAGVzZR4AAAAJAAAAcmpzcGFya3MAc29uHgAAAAIAAAAzAHNwHgAAABUAAABNaWNy b3NvZnQgUG93ZXJQb2ludABvbgBAAAAA4MN+PQ4AAABAAAAAwBjJIH2ywAFAAAAAQF0jnTLBwAED AAAAYwAAAEcAAACaMgAA/////wMAAAAIAIkQZwwAAAEACQAAA0UZAAAIAIQNAAAAABEAAAAmBg8A GAD/////AAAQAAAAAAAAAAAAwAMAANACAAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA//// /wQAGwBUTlBQFAAIAbkAMgAAAP//TwAUAAAATQBpAAAACgAAACYGDwAKAFROUFAAAAIA9AMJAAAA JgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAAAAAAAAAFAAAACwIAAAAABQAA AAwC0ALAAwUAAAAEAQ0AAAAHAAAA/AIAAP///wAAAAQAAAAtAQAACAAAAPoCBQABAAAAAAAAAAQA AAAtAQEABAAAAC0BAAAJAAAAHQYhAPAA0ALAAwAAAAAEAAAALQEAAAcAAAD8AgAA////AAAABAAA AC0BAgAEAAAA8AEAAAgAAAD6AgAAAAAAAAAAAAAEAAAALQEAABAAAAAmBg8AFgD/////AABHAAAA jwIAABEBAADBAgAACAAAACYGDwAGAP////8BABwAAAD7AgAAAAAAAAAAAAAAAAAAAAAAAADcEgCR cvV3QAAAAJcHCgINVfV3FlX1dwEAAAAAADAABAAAAC0BAwAFAAAACQIAAAACBQAAABQCAAAAAAUA AAACAQIAAAAQAAAAJgYPABYA/////wAARwEAAI8CAAB5AgAAwQIAAAgAAAAmBg8ABgD/////AQAF AAAACQIAAAACBQAAABQCAAAAAAUAAAACAQIAAAAHAAAA/AIBAAAAAAAAAAQAAAAtAQQABAAAAC0B AQAHAAAAGwRpAXkD8ABIAAQAAAAtAQIABAAAAC0BAAAFAAAACQIAAAACBQAAABQCAAAAABwAAAD7 As3/AAAAAAAAvAIAAAAAAEAAIkFyaWFsAPV3QAAAAHAHClkNVfV3FlX1dwEAAAAAADAABAAAAC0B BQAEAAAA8AEDAAUAAAAJAjMzzAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAVAAAAMgoH AU8BCQAAAFNJTVBMRSBXRwAiAA0AKwAiAB8AIgAOAC8AKAAFAAAALgEBAAAABQAAAAIBAgAAABwA AAD7AtH/AAAAAAAAvAIAAAAAAEAAIkFyaWFsIE5hcnJvdwAHCgUNVfV3FlX1dwEAAAAAADAABAAA AC0BAwAEAAAA8AEFAAUAAAAJAjMzzAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAABAAAAA MgpBAXUAJgAAAFNJUCBmb3IgSW5zdGFudCBNZXNzYWdpbmcgYW5kIFByZXNlbmNlGgALABkACwAM ABgADwAKAAsAGAAVAA0AFAAYAA0ACwAgABUAFQAVABUAGAAKABgAFwALABUAFwAYAAoAGgAPABUA FQAVABgAFQAVAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCMzPMAgUAAAAUAgAAAAAFAAAALgEY AAAABQAAAAIBAQAAACcAAAAyCnkBDgEVAAAATGV2ZXJhZ2luZyBFeHRlbnNpb25zABgAFQAVABUA DwAVABgACwAXABgACgAaABUADQAVABgAFQAKABgAGAAVAAUAAAAuAQEAAAAFAAAAAgECAAAABQAA AAIBAgAAAAQAAAAtAQQABAAAAC0BAQAHAAAAGwSBAnkDmAFQAAQAAAAtAQIABAAAAC0BAAAFAAAA CQIzM8wCBQAAABQCAAAAABwAAAD7At//AAAAAAAAvAIAAAAAAEAAIkFyaWFsAPV3QAAAAIkHCmcN VfV3FlX1dwEAAAAAADAABAAAAC0BBQAEAAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4B GAAAAAUAAAACAQEAAAASAAAAMgq9AasBBwAAAENoYWlyczoCGAAUABIACQAOABIACwAFAAAALgEB AAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAeAAAA MgrtAY4ADwAAAFJvYmVydCBTcGFya3MgKAAYABQAFAASAA0ADAAJABYAFQASAA0AEwASAAkACwAF AAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAszM/wIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEA AAAqAAAAMgrtAYUBFwAAAHJzcGFya3NAZHluYW1pY3NvZnQuY29tAA4AEgAUABIADgASABMAIAAU ABMAFQASAB4ACQATABIAFAALAAwACQASABUAHQAFAAAALgEBAAAABQAAAAIBAgAAAAgAAAD6AgYA AQAAAMzM/wIEAAAALQEDAAQAAAAtAQQABQAAABQC8QGGAQUAAAATAvEBLwMEAAAALQEBAAcAAAD8 AgAAzMz/AAAABAAAAC0BBgAFAAAACQLMzP8CBwAAABsE9AExA/ABhQEFAAAACQIAAAACBQAAABQC 8QEvAwUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIK7QEwAwEAAAApAAsABQAAAC4BAQAAAAUAAAAC AQIAAAAFAAAACQIAAAACBQAAABQC8QEvAwUAAAAuARgAAAAFAAAAAgEBAAAAHAAAADIKHQKiAA4A AABKb24gUGV0ZXJzb24gKBIAFAAUAAoAFgASAAwAEgANABMAFAAUAAkADAAFAAAALgEBAAAABQAA AAIBAgAAAAUAAAAJAszM/wIFAAAAFALxAS8DBQAAAC4BGAAAAAUAAAACAQEAAAAqAAAAMgodAokB FwAAAGpvbi5wZXRlcnNvbkBsZXZlbDMuY29tAAkAFAAVAAkAFQASAAsAEgAOABIAFAAVACAACgAS ABMAEgAKABIACQATABQAHgAFAAAALgEBAAAABQAAAAIBAgAAAAQAAAAtAQMABAAAAC0BBAAFAAAA FAIhAooBBQAAABMCIQIbAwQAAAAtAQEABAAAAC0BBgAFAAAACQLMzP8CBwAAABsEJAIdAyACiQEF AAAACQIAAAACBQAAABQCIQIbAwUAAAAuARgAAAAFAAAAAgEBAAAACQAAADIKHQIcAwEAAAApAAsA BQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCIQIbAwUAAAAuARgAAAAFAAAAAgEB AAAACgAAADIKTQLrAAIAAAA1MBIAEgAFAAAALgEBAAAABQAAAAIBAgAAABwAAAD7Aun/AAAAAAAA vAIAAAAAAEAAIkFyaWFsAPV3QAAAAAsFCqcNVfV3FlX1dwEAAAAAADAABAAAAC0BBwAEAAAA8AEF AAUAAAAJAgAAAAIFAAAAFAIhAhsDBQAAAC4BGAAAAAUAAAACAQEAAAAKAAAAMgpCAg8BAgAAAHRo CAAPAAUAAAAuAQEAAAAFAAAAAgECAAAAHAAAAPsC3/8AAAAAAAC8AgAAAAAAQAAiQXJpYWwA9XdA AAAAiQcKaQ1V9XcWVfV3AQAAAAAAMAAEAAAALQEFAAQAAADwAQcABQAAAAkCAAAAAgUAAAAUAiEC GwMFAAAALgEYAAAABQAAAAIBAQAAAC4AAAAyCk0CLwEaAAAASUVURiAoTWlubmVhcG9saXMgTU4g My8wMSkJABYAFQAUAAkACwAdAAkAFAAUABIAEgAVABQACQAKABIACQAdABcACgASAAoAEgASAAsA BQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAAEAAAACYGDwAWAP////8AAC8DAAAXAAAAngMA ADcAAAADAAAAHgAFAAAALgEAAAAABQAAAAoCAAAAAAUAAAAJAgAAAAAFAAAAAQL///8ABAAAAC0B BAAEAAAALQEBAAQAAAADAQgABwAAABIE0AIeAMADbQAFAAAACwLQ/+0BBQAAAAwCsgCMAhEAAAAm Bg8AGAD/////AAAQAP4UAABeAAAAihcAABABAAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA /////wQAGwBUTlBQFABw8AAwAAAAABQAAADkDooAAAAAAAD4CgAAACYGDwAKAFROUFAAAAIA9AMJ AAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAAAAAAAAAFAAAADAKyAIwC BQAAAAQBDQAAABAAAAAmBg8AFgD/////AAD/FAAAXwAAAIkXAAAPAQAABQAAAAcBBAAAAAUAAAAL AtD/7QGEDQAAQw8gAMwAAAAqAKAAAAAAAK4AiAJgAAAVKAAAAKAAAAAqAAAAAQAIAAAAAABAGgAA AAAAAAAAAAAhAAAAIQAAAAAAAABAAMYAEBAQAEwQygAgICAAWCDNADAwMABkMNEAQEBAAHBA1ABQ UFAAfFDYAGBgYACIYNsAcHBwAJRw3wB/f38An3/iAI+PjwCrj+YAn5+fALef6gCvr68Aw6/tAL+/ vwDPv/EAz8/PANvP9ADf398A59/4AO/v7wDz7/sA////AAwICCAgICAcBAYYICAgIBgSIBgGICAg IBgSIBoMICAgIB4ECgYgICAgIAYgBhggICAgDgIUICAgIBIEAiAgICAOFCACHCAgICAGICAgICAW AgwgICAgGAQEGCAgICAYEh4AICAgIBoGBBIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAEICAgICAgEhQcBiAgICAYDggWEiAgICAYDggWDiAgICAY DCAGICAgICAIHAAaICAgICAIICAgICACICAgICAgGAYOBiAgICAgCCAgICAgIAggICAgIA4WGgYg ICAgGA4MACAgICAgIBgGICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCCAgICAgIA4YIAggICAgHAQACg4gICAgGAwCCBIgICAgGBIgCCAgICAgCAwE GCAgICAgCCAgICAgACAgICAgICACChIgICAgIAggICAgICAIICAgICAIGCAGICAgIBgMAgAgICAg IBICFiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAYgICAgICAOFhwIICAgICAAEgASICAgIB4AEgAOICAgIBgOIAggICAgIAgEEhggICAgIAggICAg IAAgICAgICAgCgQcICAgICAIICAgICAgCCAgICAgDBgYCCAgICAYABYAICAgIBoCICAgICAgICAg ICAgICAgICAaBiAgICAgICAgICAgICAgICAgICAKEiAgICAgICAgICAgICAgICAIDAogICAgGgYK DiAgICAgACAMDiAgICAgACAIEiAgICAaDiAGICAgICAGFg4YICAgIA4AFCAgICAOCgYgICAgIBgC ICAgICAGAgYcICAgFAIMICAgIBgGBBYgICAgGgIgACAgICAeBAgUICAgICAgICAgICAgICAOAAIg ICAgICAgICAgICAgICAgICAgDgAGHCAgICAgICAgICAgICAgIBggICAgICAcGiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIBgeICAgICAgICAgICAgICAgICAg ICAgICAgICAgHBogICAgICAgICAgICAgIB4YICAgICAgICAgICAgIB4EAAwgICAgICAgICAgICAg ICAgICAgICAWAAIWICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIBwAABQgICAgICAgICAgICAgICAgICAgICAgIBoC ABQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIBwYDhIOEg4aHiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgGhIOEg4SFhwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIBoCABIgICAgICAgICAdFxMRERcbICAgICAgICAgGgAAFiAgICAgICAg ICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYICAgICAcEgQAAAAAAAAAAAAGDiAgICAgICAgICAg DgAAAAAAAAAAAAogICAgICAgICAgIBYKAAAAAAAAAAAAAgwYICAgICAgGAAAAAAAAAAACCAgICAg ICAgIB4CAAYgICAgICAgIA8FAQEBAQEBAQURHyAgICAgICAOAAAUICAgICAgICAgIAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAGCAgICASAAAAAAAAAAAAAAAAAAACDiAgICAgICAgIAIAAAAAAAAAAAAC ICAgICAgICAgGgQAAAAAAAAAAAAAAAAAAAgcICAgIBgAAAAAAAAAAAggICAgICAgICAEAAAaICAg ICAgFQMBAQEBAQEBAQEBAQMZICAgICAgHgIAAhwgICAgICAgICAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABggICAIAAAAAAAAAAAAAAAAAAAAAAAGHiAgICAgIBwAAAAAAAAAAAAAABggICAgICAgFgAA AAAAAAAAAAAAAAAAAAAAAhQgICAYAAAAAAAAAAAIICAgICAgICASAAAEICAgICAgFwEBAQEBAQEB AQEBAQEBARUgICAgICAOAAAEICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYICAEAAAA AAAAAAAAAAAAAAAAAAAAAAggICAgICAMAAAAAAAAAAAAAAAMICAgICAgFgAAAAAAAAAAAAAAAAAA AAAAAAAAHCAgGAAAAAAAAAAACCAgICAgICAcAAAADiAgICAgGwEBAQEBAQEBAQEBAQEBAQEBHSAg ICAgGgAAABQgICAgICAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGCASAAAAAAAAAAAAAAAAAAAA AAAAAAAAEiAgICAgBAAAAAAAAAAAAAAAACAgICAgHgIAAAAAAAAAAAAAAAAAAAAAAAAAAAIgIBgA AAAAAAAAAAYgICAgICAgDAAAABggICAgIAsBAQEBAQEDEREPAwEBAQEBAQcgICAgICACAAAAHiAg ICAgICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgcAAAAAAAAAAAAChogHhIAAAAAAAAAAAIgICAg GgAAAAAAAAAAAAAAAAAYICAgIAwAAAAAAAAAAAIWHiAYBAAAAAAAAAAAFiAYAAAAAAAAAAAIICAg ICAgHgAAAAAgICAgIB0BAQEBAQENICAgIB8FAQEBAQEBGyAgICAgBgAAABQgICAgICAgAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAYEgAAAAAAAAAACiAgICAgEgAAAAAAAAAAGCAgIAwAAAAAAAAAAAAA AAAADCAgIB4AAAAAAAAAAAAeICAgIB4EAAAAAAAAAAYgGAAAAAAAAAAACCAgICAgIA4AAAAGICAg ICAVAQEBAQEDICAgICAgIAEBAQEBAQ8gICAgIBIAAAACICAgICAgIAAAAAAAAAAAAAAYGBgYGBgY GBgYGBgYHgQAAAAAAAAAAiAgICAgICAgICAgICAgICAgICAAAAAAAAAAAAAAAAAAAAIgICAUAAAA AAAAAAAUICAgICAgICAgICAgICAgIBgAAAAAAAAAAAggICAgICACAAAACCAgICAgEQEBAQEBESAg ICAgICAPAQEBAQEJICAgICASAAAAABwgICAgICAAAAAAAAAAAAAAICAgICAgICAgICAgICAAAAAA AAAAAAggICAgICAgICAgICAgICAgICAYAAAAAAAAAAIAAAAAAAAAFiAgEgAAAAAAAAAAHiAgICAg ICAgICAgICAgICAYAAAAAAAAAAAIICAgICAcAAAAAA4gICAgIA8BAQEBARkgICAgICAgEwEBAQEB CSAgICAgGAAAAAAOICAgICAgAAAAAAAAAAAAACAgICAgICAgICAgICAaAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACAgDAAAAAAAAAAMAAAAAAAAAAogIAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS GAAAAAAAAAAACCAgICAgEgAAAAAOICAgICAVEREREREdICAgICAgIBcBAQEBAQkgICAgIBgAAAAA CCAgICAgIAAAAAAAAAAAAAAgICAgICAgICAgICAgGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAg IAAAAAAAAAAAHgQAAAAAAAAAHiAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADhgAAAAAAAAAAAgg ICAgIAwAAAAAEiAgICAgICAgICAgICAgICAgICANAQEBAQEJICAgICAaAAAAAAAgICAgICAAAAAA AAAAAAAAICAgICAgICAgICAgIBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBYAAAAAAAAABCAK AAAAAAAAABYgBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYYAAAAAAAAAAAIICAgICAIAAAAAA4g ICAgICAgICAgICAgICAgICAbAQEBAQEBDyAgICAgIAAAAAAAHiAgICAgAAAAAAAAAAAAACAgICAg ICAgICAgICAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABiAIAAAAAAAAAAogFgAAAAAAAAAKIAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYGAAAAAAAAAAACCAgICAgAgAAAAASICAgICAgICAgICAg ICAgIB0TAwEBAQEBARkgICAgICAAAAAAABggICAgIAAAAAAAAAAAAAAgICAgICAgICAgICAgIAIA AAAAAAAABBIODhIODhICAAAAAAAAAA4gAAAAAAAAAAAYIB4AAAAAAAAAAB4OAAAAAAAAAAAOEg4S DhIOCgAAAAAAAAAAIBgAAAAAAAAAAAggICAgIAAAAAAAGCAgICAgICAgICAgICAJBwEBAQEBAQEB AQkgICAgICAgAAAAAAAYICAgICAAAAAAAAAAAAAAICAgICAgICAgICAgICAKAAAAAAAAAAQgICAg ICAgAAAAAAAAAAAWFAAAAAAAAAAAHiAgBgAAAAAAAAAUGgAAAAAAAAAAGiAgICAgIA4AAAAAAAAA CCAYAAAAAAAAAAAIICAgICAAAAAAABggICAgICAgICAgICAgAQEBAQEBAQEBAQUfICAgICAgIAAA AAAAGCAgICAgAAAAAAAAAAAAACAgICAgICAgICAgICAgFAAAAAAAAAAAGiAgICAgCgAAAAAAAAAE IAoAAAAAAAAACCAgIA4AAAAAAAAACiACAAAAAAAAAAogICAgIBoAAAAAAAAAABYgGAAAAAAAAAAA CCAgICAgAAAAAAAYICAgICAgICAgICAgIAEBAQEBAQEBAQ0fICAgICAgICAAAAAAABggICAgIAAA AAAAAAAAAAAgICAgICAgICAgICAgICAEAAAAAAAAAAIUICAeDAAAAAAAAAAAFB4AAAAAAAAAAA4g ICAaAAAAAAAAAAAeEgAAAAAAAAAAChwgIBYCAAAAAAAAAAIgIBgAAAAAAAAAAAggICAgIAQAAAAA FCAgICAgICAgICAgICABAQEBAQEBAQMTICAgICAgICAgAAAAAAAYICAgICAAAAAAAAAAAAAAICAg ICAgICAgICAgICAgFgAAAAAAAAAAAAAAAAAAAAAAAAAACCAUAAAAAAAAAAAaICAgIAAAAAAAAAAA FiAEAAAAAAAAAAAAAAAAAAAAAAAAAAAYICAYAAAAAAAAAAAIICAgICAIAAAAABIgICAgICAgICAg ICAgEREJBQEBAQEBAREgICAgICAgIAAAAAAAICAgICAgAAAAAAAAAAAAACAgICAgICAgICAgICAg ICAOAAAAAAAAAAAAAAAAAAAAAAAAABwgBgAAAAAAAAACICAgICAKAAAAAAAAAAggGgIAAAAAAAAA AAAAAAAAAAAAAAAUICAgGAAAAAAAAAAABiAgICAgCgAAAAAOICAgICAgICAgICAgICAgICATAQEB AQEBGyAgICAgIBoAAAAAACAgICAgIAAAAAAAAAAAAAAgICAgICAgICAgICAgICAgIAoAAAAAAAAA AAAAAAAAAAAABBwgHAAAAAAAAAAADCAgICAgFAAAAAAAAAAAHiAaAAAAAAAAAAAAAAAAAAAAAAAO ICAgIBgAAAAAAAAAAAggICAgIBIAAAAAEiAgICAgICAgICAgICAgICAgIBEBAQEBAQ0gICAgICAY AAAAAAggICAgICAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICAgGAIAAAAAAAAAAAAAAAAACB4g IBQAAAAAAAAAABQgICAgIBwAAAAAAAAAABQgICAIAAAAAAAAAAAAAAAAAAIWICAgICAYAAAAAAAA AAAIICAgICAcAAAAAA4gICAgICAJCQkJBxUgICAgICAbAQEBAQEDICAgICAgGAAAAAAOICAgICAg AAAAAAAAAAAAACAgICAgICAgICAgICAgICAgICAeDgQAAAAAAAAAAAAKGiAgICAEAAAAAAAAAAAc ICAgICAgBAAAAAAAAAAKICAgIBgIAAAAAAAAAAAABBIgICAgICAgGAAAAAAAAAAACCAgICAgIAIA AAAIICAgICAgAQEBAQERICAgICAgIAEBAQEBASAgICAgIBQAAAAAHCAgICAgIAAAAAAAAAAAAAAg ICAgICAgICAgICAgICAgICAgICAgGhYOEg4SDhggICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIB4aDhIOEg4WHCAgICAgICAgIBgAAAAAAAAAAAggICAgICAMAAAABCAgICAgIAEB AQEBBSAgICAgIBkBAQEBAQEgICAgICASAAAAAiAgICAgICAAAAAAAAAAAAAAICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAYAAAAAAAAAAAIICAgICAgGgAAAAAgICAgICAHAQEBAQEbICAgICAL AQEBAQEJICAgICAgCgAAABIgICAgICAgAAAAAAAAAAAAACAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgGAAAAAAAAAAACCAgICAgICAIAAAAGiAgICAgFQEBAQEBAxUgIB8NAQEBAQEBDyAgICAg IAQAAAAeICAgICAgIAAAAAAAAAAAAAAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIBgAAAAA AAAAAAggICAgICAgGAAAABQgICAgIB8BAQEBAQEBAQEBAQEBAQEBAR0gICAgIBwAAAASICAgICAg ICAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAYAAAAAAAAAAAIICAgICAg ICAMAAAEICAgICAgFwEBAQEBAQEBAQEBAQEBAQ8gICAgICAUAAAAHiAgGg4cGhQaAAAAAAAAAAAA ACAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgGAAAAAAAAAAACCAgICAgICAgHgAAAB4gICAg ICALAQEBAQEBAQEBAQEBAQ0gICAgICAgBAAAFiAgIAwYBg4ACgAAAAAAAAAAAAAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIBgAAAAAAAAAAAggICAgICAgICAcAAAKICAgICAgIBcFAQEBAQEB AQEBAxEgICAgICAgFAAADiAgICAMChQEDgAAAAAAAAAAAAAAICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAYAAAAAAAAAAAIICAgICAgICAgIBQAABggICAgICAgIBUNBwEBAQULFR8gICAgICAg HgIADCAgICAgDggUAiAEGBgYGBgYGBgYGCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgHhgY GBgYGBgYGiAgICAgICAgICAgFAACGiAgICAgICAgICAgICAgICAgICAgICAgHgYADCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAUAAIWICAgICAgICAgICAgICAgICAgICAgGgYADCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIBwG AAogICAgICAgICAgICAgICAgICAgFAICFCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA4CICAgICAgICAg ICAgICAgICAgIAgMHCAgICAgICAgICAgICAgIAUAAAAHAQEAAAAIAAAAJgYPAAYA/////wEABAAA AC0BAQAEAAAALQEEAA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD///// AQAAAAQAAAAtAQYABAAAAC0BAQAEAAAAJwH//wgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA//// /wAAFwAAABcAAACxAAAAPAAAAAUAAAAHAQQAAADgBAAAQw8gAMwAAAAXAGQAAAAAACMAmAAYABgA KAAAAGQAAAAXAAAAAQAIAAAAAAD8CAAAxA4AAMQOAAAgAAAAIAAAAAAAAAACAv8ABgYGAAwMDAAa GhoAMTExAERERABbW1sAaWlpAG5u/wB1dXUAh4eHAJeXlwCoqKgAr6//ALe3twDHx8cAycm0AMvL /wDW1tYA5OTkAOnp3wDq6v8A8PDwAPT04AD19fYA+fn5APz8/AD+/v4A/v7/AP//+QD///8AHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fDAsNCxcfHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8QEx8fHx8fHwAAAAAAFx8fHxcfHx8XHx8fHw0NExcQDxMfFxcXHx8T Fx8fFxcXHxcTEx8fHxMPDxAfHx8fFxMTEx8fHx8fExMTHx8fExcTFxMfHx8WExQfHxYOEh8fHx8f Hx8DAAADAwAABx8fAwAAAAcfHwUAAAgNAAAAHwYAAAAAAAAGHwAAAAsGAAAHDQAAABcAAAAMHwMA AAAAAx8fEAgPHw8PHx8fCwwXDwwfHxcMCA0XHx8fCAsLGB8BAQEOHx8fHx8QAAAAAAAAAAcfHwMA AAADHx8FAAAIDQAAAB8EAAADAAAABx8AAAALBwAABw0AAAAfBAAADQ8AAAADAAAEHw8LHx8XCBcf EAofHx8MDB8fEAgfHx8fEwgQFRESAQEBCR8fHx8fDwAAAA8FAAAIHx8AAAAAAB8fBQAACA8AAAMf AwAAFwgAAAcfAwAADAgAAAcPAAADHwMAAA0LAAAIEwAAAB8PDx8fHwoQHwwPHx8fEAgTHxALHx8f HxcIEB8fFgEBARIfHx8fHw8AAAAfCAAACB8PAAAAAAAfHwUAAAgPAAAAHwQAABcKAAAHHwMAAAwH AAAHDwAAAB8EAAANCgAACBMAAAAQHx8fHxMIEB8KEx8fHxcIDR8TCx8fHx8TCBAfHx8SCQ4fHx8f Hx8PAAAAHwcAAAgfCwAABgMADx8FAAAIDwAAAx8EAAAHBwAABx8AAAAMBwAABw8AAAMfAwAADQoA AAcfCwsLFx8fHw8KCx8XCB8fHx8fCwsfEwsfHx8fFwgQHx8fHx8fHx8fHx8fDwAAAB8HAAAIHwgA AAoEAAwfBQAACA8AAAAfFwQAAAAAAAcfAwAADAcAAAcPAAAAHwQAAA0KAAAHHx8fHx8fFwsICBcf EAofHx8fHwsLHxMLHx8fHxMIEB8fHx8fHx8fHx8fHw8AAAAfBwAACB8HAAANAwAKHwUAAAgPAAAA Hx8TDQcAAAAHHwAAAAwHAAAHDwAAAx8DAAANCgAABx8XFxMfHwsIChMfHxAKHx8fHx8KCx8TCx8f Hx8XCBAfHx8fHx8fHx8fHx8PAAAAHwgAAAgfBQAAEAQABh8GAAAKDwAAAB8DAAAVBwAABx8DAAAM BwAACA8AAAAfBAAADQoAAAgQAAAAHxAIDR8fHx8fChMfHx8XCA0fEwsfHx8fEwgQHx8fHx8fHx8f Hx8fDwAAAB8HAAAIHwAAABcEAAMfBgAACg0AAAMfAwAAFwoAAAcfAAAACwcAAAcNAAADHwMAAA0L AAAKEAAAAB8QCx8fHwwfHw0MHx8fDwofHxMLHx8fHxcIEB8fHx8fHx8fHx8fHw8AAAAFAAAACh8A AAAfBQAAHwYAAAAAAAADHwUAAAYDAAALHwAAAAAAAAAAAAAAAB8DAAANDwAAAAAAAAUfHwoTHxcL Hx8XCBMfHwsQHx8PCxMQHx8TCg0THx8fHx8fHx8fHx8XAAAAAAAAAAoXAAAAHwUAABAFAAAAAAAA Bx8NAAAAAAAGHx8AAAAAAAAACAAAAAcfAAAADB8DAAAAAAMeHx8TDA0KDB8fHxALDQwPHx8TCgoL ChMTCgoKCx8fHx8fHx8fHx8fHxAMDB8HAAAIHw8PEx8TDw8fEw8PFxMMDx8fHx8TDxAXHx8fEBAQ HxANEx8XDQ8fHx4VGB8fHxMPDxMfHx8fHx8VHx8fHx8fHxcXHxAXHxALHx8fHw8IEB8fHx8fHx8f Hx8fHx8fHx8fBgAABx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8JAQkf Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHxMPDR8TCx8fHx8fCw8fHx8fHx8fHx8fHx8fHx8fHwsFBQsf Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8WAQEBCR8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8QDw8fEwoXHx8fHxMQHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fEgEBAQkfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHxATHx8I Hx8NHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8JAQkWHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fDQ0PCh8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8QDBAfHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8FAAAABwEBAAAACAAAACYGDwAGAP////8BAAQAAAAtAQEABAAAAC0B BAAEAAAA8AEDAAQAAADwAQYAHAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAAAAAAoAAAAE AAAAAAADAAAAAQAAAAAAMAAEAAAALQEDAAQAAADwAQUADwAAACYGDwAUAFROUFAEAAwAAAAAAAAA AAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXV zdWcLhsQk5cIACss+a6EAgAAQAIAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAA0AAA AAYAAADYAAAABwAAAOAAAAAIAAAA6AAAAAkAAADwAAAACgAAAPgAAAAXAAAAAAEAAAsAAAAIAQAA EAAAABABAAATAAAAGAEAABYAAAAgAQAADQAAACgBAAAMAAAA3QEAAAIAAADkBAAAHgAAAA8AAABP bi1zY3JlZW4gU2hvdwAAHgAAAB0AAABMZXZlbCAzIENvbW11bmljYXRpb25zLCBJbmMuAABAAAMA AACxJAAAAwAAABMAAAADAAAAAwAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAADtDgkACwAA AAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAABwAAABAAAABUaW1lcyBOZXcgUm9tYW4A BgAAAEFyaWFsAA0AAABBcmlhbCBOYXJyb3cADwAAAERlZmF1bHQgRGVzaWduAEcAAABTSU1QTEUg V0cgU0lQIGZvciBJbnN0YW50IE1lc3NhZ2luZyBhbmQgUHJlc2VuY2UgTGV2ZXJhZ2luZyBFeHRl bnNpb25zAA4AAABTSU1QTEUgQWdlbmRhAAoAAABXRyBTdGF0dXMADBAAAAYAAAAeAAAACwAAAEZv bnRzIFVzZWQAAwAAAAMAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAA U2xpZGUgVGl0bGVzAAMAAAADAAAAAAAANAEAAAMAAAAAAAAAIAAAAAEAAAA4AAAAAgAAAEAAAAAB AAAAAgAAAAwAAABfUElEX0hMSU5LUwACAAAA5AQAAEEAAADsAAAADAAAAAMAAAAHAAAAAwAAAAYA AAADAAAAAAAAAAMAAAAHAAAAHwAAAB8AAABtAGEAaQBsAHQAbwA6AHIAcwBwAGEAcgBrAHMAQABk AHkAbgBhAG0AaQBjAHMAbwBmAHQALgBjAG8AbQAAAAAAHwAAAAEAAAAAAAAAAwAAAAcAAAADAAAA BgAAAAMAAAAAAAAAAwAAAAcAAAAfAAAAHwAAAG0AYQBpAGwAdABvADoAagBvAG4ALgBwAGUAdABl AHIAcwBvAG4AQABsAGUAdgBlAGwAMwAuAGMAbwBtAAAAAAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAA 9g8gAAAAFAAAAF/AkeO4GgAACAD0AwMABgRyanNwYXJrcwgAAAByAGoAcwBwAGEAcgBrAHMAAAAA AAAAAAA= ------_=_NextPart_000_01C0C132.C376C9A1-- From nsyracus@cnri.reston.va.us Fri Apr 13 07:16:42 2001 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 HAA15248 for ; Fri, 13 Apr 2001 07:16:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05066; Fri, 13 Apr 2001 07:16:25 -0400 (EDT) Message-Id: <200104131116.HAA05066@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 Date: Fri, 13 Apr 2001 07:16:25 -0400 Content-Length: 2357 Subject: [Simple] I-D ACTION:draft-ietf-simple-im-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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Instant Messaging Author(s) : J. Rosenberg et al. Filename : draft-ietf-simple-im-00.txt Pages : 26 Date : 12-Apr-01 This document defines a SIP extension (a single new method) that supports Instant Messaging (IM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-im-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-im-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-im-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: <20010412144222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-im-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-im-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010412144222.I-D@ietf.org> --OtherAccess-- --NextPart-- From bcampbell@dynamicsoft.com Mon Apr 16 12:05:21 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01392 for ; Mon, 16 Apr 2001 12:05:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA06437 for ; Mon, 16 Apr 2001 12:08:53 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 16 Apr 2001 12:05:21 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30AF7@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-00.txt Date: Mon, 16 Apr 2001 12:02:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2259 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: This version is just a name change to reflect the draft's status as a wg item. There are no substantive changes whatsoever. Thanks! Ben Campbell. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Friday, April 13, 2001 6:16 AM > Cc: simple@mailman.dynamicsoft.com > Subject: [Simple] I-D ACTION:draft-ietf-simple-im-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the SIP for Instant Messaging > and Presence Leveraging Extensions Working Group of the IETF. > > Title : SIP Extensions for Instant Messaging > Author(s) : J. Rosenberg et al. > Filename : draft-ietf-simple-im-00.txt > Pages : 26 > Date : 12-Apr-01 > > This document defines a SIP extension (a single new method) that > supports Instant Messaging (IM). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-im-00.txt > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-simple-im-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-im-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. > From charles@versadanet.com Mon Apr 23 17:01:56 2001 Received: from cba0ims00.CBA0.centerbeam.com ([208.46.211.247]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02734 for ; Mon, 23 Apr 2001 17:01:56 -0400 (EDT) Received: by cba0ims00.CBA0.centerbeam.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Apr 2001 14:01:35 -0700 Message-ID: From: Charles Chen To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 23 Apr 2001 14:01:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 825 Subject: [Simple] 487 Request Cancelled 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: "draft-roach-sip-subscribe-notify-03.txt" page 9: For the purposes of generality, both SUBSCRIBE and NOTIFY MAY be canceled; however, doing so is not recommended. Successfully cancelled SUBSCRIBE and NOTIFY requests MUST be completed with a "487 Request Cancelled" response; the server acts as if the request were never received. In general, since neither SUBSCRIBE nor NOTIFY are allowed to have protracted transactions, attempts to cancel them are expected to fail. Can anyone explain to me that why to use a 4xx reponse code to indicate a successful request (to cancel SUBSCRIBE or NOTIFY)? Doesn't a 2xx class response code make more sense? In this case, a "287 Request Cancelled Successfully" might be more straightforward than a "487 Request Cancelled". Comments? Thanks, Charles From sean.olson@ericsson.com Mon Apr 23 17:38:48 2001 Received: from imr2.ericy.com ([12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02846 for ; Mon, 23 Apr 2001 17:38:47 -0400 (EDT) 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 f3NLcj803253 for ; Mon, 23 Apr 2001 16:38:46 -0500 (CDT) 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 f3NLcjm25810 for ; Mon, 23 Apr 2001 16:38:45 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Apr 23 16:38:45 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Apr 2001 16:38:45 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Charles Chen'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] 487 Request Cancelled Date: Mon, 23 Apr 2001 16:38:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CC3D.C41D9BC0" Content-Length: 3559 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: 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_01C0CC3D.C41D9BC0 Content-Type: text/plain; charset="iso-8859-1" >"draft-roach-sip-subscribe-notify-03.txt" page 9: > > For the purposes of generality, both SUBSCRIBE and NOTIFY MAY be > canceled; however, doing so is not recommended. Successfully > cancelled SUBSCRIBE and NOTIFY requests MUST be completed with a > "487 Request Cancelled" response; the server acts as if the > request were never received. In general, since neither SUBSCRIBE > nor NOTIFY are allowed to have protracted transactions, attempts > to cancel them are expected to fail. > >Can anyone explain to me that why to use a 4xx reponse code to >indicate a >successful request (to cancel SUBSCRIBE or NOTIFY)? Doesn't a 2xx class >response code make more sense? In this case, a "287 Request Cancelled >Successfully" might be more straightforward than a "487 >Request Cancelled". > This is *not* a successful request. The SUBSCRIBE/NOTIFY requests are treated as is if they were never received. The 487 is just to consistently close the transaction. >Comments? > >Thanks, >Charles /sean ------_=_NextPart_001_01C0CC3D.C41D9BC0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] 487 Request Cancelled

>"draft-roach-sip-subscribe-notify-03.txt" page 9:
>
>     For the purposes of generality, both SUBSCRIBE and NOTIFY MAY be
>     canceled; however, doing so is not recommended. Successfully
>     cancelled SUBSCRIBE and NOTIFY requests MUST be completed with a
>     "487 Request Cancelled" response; the server acts as if the
>     request were never received. In general, since neither SUBSCRIBE
>     nor NOTIFY are allowed to have protracted transactions, attempts
>     to cancel them are expected to fail.
>
>Can anyone explain to me that why to use a 4xx reponse code to
>indicate a
>successful request (to cancel SUBSCRIBE or NOTIFY)? Doesn't a 2xx class
>response code make more sense? In this case, a "287 Request Cancelled
>Successfully" might be more straightforward than a "487
>Request Cancelled".
>

This is *not* a successful request. The SUBSCRIBE/NOTIFY
requests are treated as is if they were never received.
The 487 is just to consistently close the transaction.

>Comments?
>
>Thanks,
>Charles

/sean

------_=_NextPart_001_01C0CC3D.C41D9BC0-- From jdrosen@dynamicsoft.com Mon Apr 23 18:55:20 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03068 for ; Mon, 23 Apr 2001 18:55:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA14604; Mon, 23 Apr 2001 18:58:53 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Apr 2001 18:55:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson (EUS)'" , "'Charles Chen'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] 487 Request Cancelled Date: Mon, 23 Apr 2001 18:55:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1756 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: -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Monday, April 23, 2001 5:39 PM To: 'Charles Chen'; 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] 487 Request Cancelled >>"draft-roach-sip-subscribe-notify-03.txt" page 9: >> >> For the purposes of generality, both SUBSCRIBE and NOTIFY MAY be >> canceled; however, doing so is not recommended. Successfully >> cancelled SUBSCRIBE and NOTIFY requests MUST be completed with a >> "487 Request Cancelled" response; the server acts as if the >> request were never received. In general, since neither SUBSCRIBE >> nor NOTIFY are allowed to have protracted transactions, attempts >> to cancel them are expected to fail. >> >>Can anyone explain to me that why to use a 4xx reponse code to >>indicate a >>successful request (to cancel SUBSCRIBE or NOTIFY)? Doesn't a 2xx class >>response code make more sense? In this case, a "287 Request Cancelled >>Successfully" might be more straightforward than a "487 >>Request Cancelled". >> >This is *not* a successful request. The SUBSCRIBE/NOTIFY >requests are treated as is if they were never received. >The 487 is just to consistently close the transaction. I'll also add that responding 487 to transaction thats been cancelled is standard behavior for all request types, as spelled out in rfc2543bis. -Jonathan R. --- Jonathan D. Rosenberg 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 From rsparks@dynamicsoft.com Tue Apr 24 11:18:08 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05577 for ; Tue, 24 Apr 2001 11:18:08 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA21009 for ; Tue, 24 Apr 2001 11:21:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Apr 2001 11:18:07 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A74E@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Tue, 24 Apr 2001 11:18:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1852 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: This discussion seems to have stalled. We have not yet clearly identified what problem we want to solve. We _have_ defined two types of messaging to discuss - "page", and "chat". I believe we have a good solution for "page". Do we want to provide a standard mechanism to signal a "chat"? If we do, we have some non-trivial techincal decisions to drill down on. If we don't, we will have applications appear (we have already seen them) that will define their own mechanisms for doing so. The opinions I have heard to date indicate this is a problem we must solve. If anyone has substantive technical dissent, put it forward asap. Given that we address providing the mechanism, I've seen several proposals: 1) Standardize what some implementers have already done - allowing a MESSAGE to infer a session into existance (i.e. a "chat" is a sequence of MESSAGES, sharing the same call-leg identifiers). This has numerous problems, mostly focused around state management (When do sessions go away, how does routing apply to them?). This approach does not seem to have any champions. 2) Create a session for the chat. a) Using INVITE/BYE, signalling a MESSAGE based chat with the SDP, including enough information to indicate 1) The sequence of messages to follow a different path than the INVITE and BYE. 2) The sequence of messages follows the same path as the INVITE and BYE. One problem to address will be how endpoints working with routing elements can indicate that INVITE to voice sessions should go to one endpoint (a phone maybe) while INVITEs to chat should go somewhere else. b) Using something other than INVITE/BYE to bound MESSAGE based chat. Have I missed anything? RjS From bpenfield@acmepacket.com Tue Apr 24 14:17:18 2001 Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06076 for ; Tue, 24 Apr 2001 14:17:17 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id A2CE21D0132; Tue, 24 Apr 2001 14:15:42 -0400 Message-ID: <002f01c0ccea$d7b74660$2300000a@acmepacket.com> From: "Bob Penfield" To: "Charles Chen" , References: Subject: Re: [Simple] 487 Request Cancelled Date: Tue, 24 Apr 2001 14:17:35 -0400 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 Content-Length: 1641 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: This language may be a bit confusing. You can only send the CANCEL if the server is still processing the SUBSCRIBE or NOTIFY request (i.e. it has not sent a response). The CANCEL will get a 200 OK. The server should then response with 487 to the cancelled SUBSCRIBE or NOTIFY request. Bob d:-) Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Charles Chen" To: Sent: Monday, April 23, 2001 5:01 PM Subject: [Simple] 487 Request Cancelled > "draft-roach-sip-subscribe-notify-03.txt" page 9: > > For the purposes of generality, both SUBSCRIBE and NOTIFY MAY be > canceled; however, doing so is not recommended. Successfully > cancelled SUBSCRIBE and NOTIFY requests MUST be completed with a > "487 Request Cancelled" response; the server acts as if the > request were never received. In general, since neither SUBSCRIBE > nor NOTIFY are allowed to have protracted transactions, attempts > to cancel them are expected to fail. > > Can anyone explain to me that why to use a 4xx reponse code to indicate a > successful request (to cancel SUBSCRIBE or NOTIFY)? Doesn't a 2xx class > response code make more sense? In this case, a "287 Request Cancelled > Successfully" might be more straightforward than a "487 Request Cancelled". > > Comments? > > Thanks, > Charles > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From rauckent@ubiquity.net Wed Apr 25 03:50:57 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id DAA09093 for ; Wed, 25 Apr 2001 03:50:56 -0400 (EDT) Received: from gecko by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 25 Apr 2001 07:50:56 UT Received: from raukenthale by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id IAA28917; Wed, 25 Apr 2001 08:50:52 +0100 (BST) Reply-To: From: "Roland Auckenthaler" To: Subject: RE: [Simple] IM: A session or not Date: Wed, 25 Apr 2001 08:50:48 +0100 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 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F314A74E@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Length: 1187 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: > > 2) Create a session for the chat. > > a) Using INVITE/BYE, signalling a MESSAGE based chat > with the SDP, including enough information to indicate > 1) The sequence of messages to follow a different path > than the INVITE and BYE. > 2) The sequence of messages follows the same path as > the INVITE and BYE. > One problem to address will be how endpoints working with > routing elements can indicate that INVITE to voice sessions > should go to one endpoint (a phone maybe) while INVITEs to > chat should go somewhere else. > > b) Using something other than INVITE/BYE to bound MESSAGE based > chat. I'm quite new to the topic of SIP and also this mailing list but in my opinion another solution for a "chat"-based session could use a similar setup to presence, i.e. SUBSCRIBE/NOTIFY. A "chat-room" can be entered using a SUBSCRIBE. This is notified by the server. Then further messaging to and from the server is done using MESSAGE. Subsequent NOTIFY requests could then allow to signal state changes in the chat room, such as leaving or entering of new users. Roland From c-Dai.Ngo@WCOM.Com Fri Apr 27 15:44:30 2001 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 PAA18452 for ; Fri, 27 Apr 2001 15:44:29 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GCG00BG8UTT6Z@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Fri, 27 Apr 2001 19:44:17 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GCG00401UTO1J@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Fri, 27 Apr 2001 19:44:17 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GCG0035OUT93E@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Fri, 27 Apr 2001 19:43:57 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Apr 2001 19:43:57 +0000 Content-return: allowed Date: Fri, 27 Apr 2001 19:43:56 +0000 From: "Ngo, Dai (c)" To: "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E11C549@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_1gUdBvpBIi7ynomhlXt99Q)" Content-Length: 1755 Subject: [Simple] Response to 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: 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_1gUdBvpBIi7ynomhlXt99Q) Content-type: text/plain; charset=ISO-8859-1 The following paragraph is extracted from the draft-ietf-impp-cpim-01.txt: "Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs)." What does it mean? Does it mean there is no "200 OK" to be expected? Please help. Thanks, Dai Ngo WCOM --Boundary_(ID_1gUdBvpBIi7ynomhlXt99Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Response to Notify

The following paragraph is = extracted from the draft-ietf-impp-cpim-01.txt:

"Regardless, there is no = application response to the notify operation (i.e., the application = does not invoke a response operation when a notify operation = occurs)."

What does it mean? Does it mean = there is no "200 OK" to be expected?

Please help.
Thanks,

Dai Ngo
WCOM

--Boundary_(ID_1gUdBvpBIi7ynomhlXt99Q)-- From c-Dai.Ngo@WCOM.Com Fri Apr 27 17:42:52 2001 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 RAA18781 for ; Fri, 27 Apr 2001 17:42:51 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GCH00D0F0BEOL@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Fri, 27 Apr 2001 21:42:50 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GCH00M010BCFB@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Fri, 27 Apr 2001 21:42:50 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GCH00HAL0B1ZX@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Fri, 27 Apr 2001 21:42:37 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Apr 2001 21:42:37 +0000 Content-return: allowed Date: Fri, 27 Apr 2001 21:42:35 +0000 From: "Ngo, Dai (c)" Subject: RE: [Simple] Response to Notify To: "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E11C54A@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_1Vje6mYUSchxYqz0DD9L5Q)" Content-Length: 4075 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: 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_1Vje6mYUSchxYqz0DD9L5Q) Content-type: text/plain; charset=iso-8859-1 My interpretation of the paragraph: "Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs)." which is extracted from the draft-ietf-impp-cpim-01.txt, page 10 of section 3.1 "Overview of the Presence Service", is: that the NOTIFY operation requires no application response. The "200 OK" is related to the SIP protocol. Am I on the right track? Thanks. Dai Ngo -----Original Message----- From: Ngo, Dai (c) Sent: Friday, April 27, 2001 2:44 PM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] Response to Notify The following paragraph is extracted from the draft-ietf-impp-cpim-01.txt: "Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs)." What does it mean? Does it mean there is no "200 OK" to be expected? Please help. Thanks, Dai Ngo WCOM --Boundary_(ID_1Vje6mYUSchxYqz0DD9L5Q) Content-type: text/html; charset=iso-8859-1 Response to Notify
My interpretation of the paragraph:

"Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs)."

which is extracted from the draft-ietf-impp-cpim-01.txt, page 10 of section 3.1 "Overview of the Presence Service", is:
that the NOTIFY operation requires no application response. The "200 OK" is related to the SIP protocol.
 
Am I on the right track?
Thanks.
 
Dai Ngo 
-----Original Message-----
From: Ngo, Dai (c)
Sent: Friday, April 27, 2001 2:44 PM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] Response to Notify

The following paragraph is extracted from the draft-ietf-impp-cpim-01.txt:

"Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs)."

What does it mean? Does it mean there is no "200 OK" to be expected?

Please help.
Thanks,

Dai Ngo
WCOM

--Boundary_(ID_1Vje6mYUSchxYqz0DD9L5Q)-- From rsparks@dynamicsoft.com Fri Apr 27 17:57:44 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18853 for ; Fri, 27 Apr 2001 17:57:44 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA10102 for ; Fri, 27 Apr 2001 18:01:21 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 27 Apr 2001 17:57:44 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A774@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Response to Notify Date: Fri, 27 Apr 2001 17:57:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0CF65.16493DE4" Content-Length: 4933 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: 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_01C0CF65.16493DE4 Content-Type: text/plain; charset="iso-8859-1" It means there is no explicit acknowledgement of NOTIFY in the abstract common protocol. In SIMPLE we require an acknowledgement (because we are using SIP and that's SIPs reliability mechanism). Some other realization of CPIM can get that reliability through some other means. We also get some other side effects out of using SIP (such as causing subscriptions to terminate if the NOTIFY received an error response). A gateway to some other realization of CPIM would have to map these ideas into their protocol. RjS -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Friday, April 27, 2001 2:44 PM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] Response to Notify The following paragraph is extracted from the draft-ietf-impp-cpim-01.txt: "Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs)." What does it mean? Does it mean there is no "200 OK" to be expected? Please help. Thanks, Dai Ngo WCOM ------_=_NextPart_001_01C0CF65.16493DE4 Content-Type: text/html; charset="iso-8859-1" Response to Notify
It means there is no explicit acknowledgement of NOTIFY in the
abstract common protocol.
 
In SIMPLE we require an acknowledgement (because we are using
SIP and that's SIPs reliability mechanism). Some other realization of
CPIM can get that reliability through some other means.
 
We also get some other side effects out of using SIP (such as causing
subscriptions to terminate if the NOTIFY received an error response).
A gateway to some other realization of CPIM would have to map these
ideas into their protocol.
 
RjS
-----Original Message-----
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com]
Sent: Friday, April 27, 2001 2:44 PM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] Response to Notify

The following paragraph is extracted from the draft-ietf-impp-cpim-01.txt:

"Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs)."

What does it mean? Does it mean there is no "200 OK" to be expected?

Please help.
Thanks,

Dai Ngo
WCOM

------_=_NextPart_001_01C0CF65.16493DE4-- From arnaud.weil@winwise.fr Mon Apr 30 05:45:51 2001 Received: from pikachu.winwise.home ([194.98.12.74]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA00452 for ; Mon, 30 Apr 2001 05:45:50 -0400 (EDT) Received: from 172.17.1.250 by pikachu.winwise.home (InterScan E-Mail VirusWall NT); Mon, 30 Apr 2001 11:45:39 +0200 (Romance Daylight Time) Content-Class: urn:content-classes:message Subject: RE: [Simple] Response to Notify MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 30 Apr 2001 11:44:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <98D95D87610EA04296C7C3006888EA0815E532@milou.winwise.home> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Response to Notify thread-index: AcDPZSeQAk/clmYYQcCZ2ZCkgOs6/QB9MYFw From: "Arnaud Weil" To: "Robert Sparks" , Content-Length: 1533 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA00452 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: Excuse me if my question looks stupid, but I couldn't get a copy of the SIMPLE specifications. I'd like to know whether the acknowledgement that's required in SIMPLE is required only for server/server interaction or also for client/server one. Thanks, Arnaud Weil -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: vendredi 27 avril 2001 23:58 To: 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] Response to Notify It means there is no explicit acknowledgement of NOTIFY in the abstract common protocol. In SIMPLE we require an acknowledgement (because we are using SIP and that's SIPs reliability mechanism). Some other realization of CPIM can get that reliability through some other means. We also get some other side effects out of using SIP (such as causing subscriptions to terminate if the NOTIFY received an error response). A gateway to some other realization of CPIM would have to map these ideas into their protocol. RjS -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Friday, April 27, 2001 2:44 PM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] Response to Notify The following paragraph is extracted from the draft-ietf-impp-cpim-01.txt: "Regardless, there is no application response to the notify operation (i.e., the application does not invoke a response operation when a notify operation occurs)." What does it mean? Does it mean there is no "200 OK" to be expected? Please help. Thanks, Dai Ngo WCOM From mwatson@nortelnetworks.com Mon Apr 30 07:59:56 2001 Received: from znsgs0ja.nortelnetworks.com (h44s128a211n47.user.nortelnetworks.com [47.211.128.44]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id HAA00811 for ; Mon, 30 Apr 2001 07:59:55 -0400 (EDT) Received: from qnsgs000.nortel.com by znsgs0ja.nortelnetworks.com (SMI-8.6/SMI-SVR4) id MAA13631; Mon, 30 Apr 2001 12:59:54 +0100 Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Mon, 30 Apr 2001 12:59:33 +0100 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Apr 2001 12:59:05 +0100 Message-ID: From: "Mark Watson" To: "'rauckent'" , simple Subject: RE: [Simple] IM: A session or not Date: Mon, 30 Apr 2001 12:59:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D16C.F30750F0" Content-Length: 8221 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: 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_01C0D16C.F30750F0 Content-Type: text/plain; charset="iso-8859-1" All, I think a baseline requirement for the 'chat' type of service is that it can be combined with other media types, just like voice can. For example you could have text chat combined with video - which if it's a unidirection session provides for subtitles - if you allow multiple 'chat' media streams in a single session, then you can implement subtitles in multiple languages etc. etc. Also, combining 'chat' media with, say, a voice/video multi-cast of a lecture or presentation would allow the observers to submit near-real-time questions in a way which give the presenter control of which questions are asked when - so you don't need to interrupt to ask a question. Just some examples to illustrate that the concept of 'chat' as a media makes sense. Considering 'chat' as just another media type would meet this requirement. There may be other ways, but I'm not sure SUBSCRIBE/NOTIFY meets this requirement. Regards, Mark Watson Nortel Networks > -----Original Message----- > From: Roland Auckenthaler [mailto:rauckent@ubiquity.net] > Sent: 25 April 2001 08:51 > To: simple > Subject: RE: [Simple] IM: A session or not > > > > > > 2) Create a session for the chat. > > > > a) Using INVITE/BYE, signalling a MESSAGE based chat > > with the SDP, including enough information to indicate > > 1) The sequence of messages to follow a different path > > than the INVITE and BYE. > > 2) The sequence of messages follows the same path as > > the INVITE and BYE. > > One problem to address will be how endpoints working with > > routing elements can indicate that INVITE to voice sessions > > should go to one endpoint (a phone maybe) while INVITEs to > > chat should go somewhere else. > > > > b) Using something other than INVITE/BYE to bound MESSAGE based > > chat. > > I'm quite new to the topic of SIP and also this mailing list but in my > opinion another solution for a "chat"-based session could use > a similar > setup to presence, i.e. SUBSCRIBE/NOTIFY. A "chat-room" can > be entered using > a SUBSCRIBE. This is notified by the server. Then further > messaging to and > from the server is done using MESSAGE. Subsequent NOTIFY > requests could then > allow to signal state changes in the chat room, such as > leaving or entering > of new users. > > Roland > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C0D16C.F30750F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] IM: A session or not

All,

I think a baseline requirement for the 'chat' type of = service is that it can be combined with other media types, just like = voice can.

For example you could have text chat combined with = video - which if it's a unidirection session provides for subtitles - = if you allow multiple 'chat' media streams in a single session, then = you can implement subtitles in multiple languages etc. etc.

Also, combining 'chat' media with, say, a voice/video = multi-cast of a lecture or presentation would allow the observers to = submit near-real-time questions in a way which give the presenter = control of which questions are asked when - so you don't need to = interrupt to ask a question.

Just some examples to illustrate that the concept of = 'chat' as a media makes sense.

Considering 'chat' as just another media type would = meet this requirement. There may be other ways, but I'm not sure = SUBSCRIBE/NOTIFY meets this requirement.

Regards,

Mark Watson
Nortel Networks


> -----Original Message-----
> From: Roland Auckenthaler [mailto:rauckent@ubiquity.net]<= /FONT>
> Sent: 25 April 2001 08:51
> To: simple
> Subject: RE: [Simple] IM: A session or = not
>
>
> >
> >   2) Create a session for the = chat.
> >
> >      a) Using = INVITE/BYE, signalling a MESSAGE based chat
> = >         with the SDP, = including enough information to indicate
> = >           = 1)  The sequence of messages to follow a different path
> = >           &n= bsp;   than the INVITE and BYE.
> = >           = 2)  The sequence of messages follows the same path as
> = >           &n= bsp;   the INVITE and BYE.
> = >         One problem to = address will be how endpoints working with
> = >         routing elements = can indicate that INVITE to voice sessions
> = >         should go to one = endpoint (a phone maybe) while INVITEs to
> = >         chat should go = somewhere else.
> >
> >      b) Using = something other than INVITE/BYE to bound MESSAGE based
> = >         chat.
>
> I'm quite new to the topic of SIP and also this = mailing list but in my
> opinion another solution for a = "chat"-based session could use
> a similar
> setup to presence, i.e. SUBSCRIBE/NOTIFY. A = "chat-room" can
> be entered using
> a SUBSCRIBE. This is notified by the server. = Then further
> messaging to and
> from the server is done using MESSAGE. = Subsequent NOTIFY
> requests could then
> allow to signal state changes in the chat room, = such as
> leaving or entering
> of new users.
>
> Roland
>
> = _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=
>

------_=_NextPart_001_01C0D16C.F30750F0-- From rsparks@dynamicsoft.com Mon Apr 30 09:53:56 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01146 for ; Mon, 30 Apr 2001 09:53:56 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA05109; Mon, 30 Apr 2001 09:57:33 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Apr 2001 09:53:54 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A776@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Arnaud Weil'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Response to Notify Date: Mon, 30 Apr 2001 09:53:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2037 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: The response is part of the basic SIP transaction. For this case, it doesn't matter what roles the participants are serving - the response is always required. RjS > -----Original Message----- > From: Arnaud Weil [mailto:arnaud.weil@winwise.fr] > Sent: Monday, April 30, 2001 4:44 AM > To: Robert Sparks; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Response to Notify > > > Excuse me if my question looks stupid, but I couldn't get a > copy of the > SIMPLE specifications. > > I'd like to know whether the acknowledgement that's required in SIMPLE > is required only for server/server interaction or also for > client/server > one. > > Thanks, > Arnaud Weil > > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: vendredi 27 avril 2001 23:58 > To: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] Response to Notify > > > > > It means there is no explicit acknowledgement of NOTIFY in the > abstract common protocol. > > In SIMPLE we require an acknowledgement (because we are using > SIP and that's SIPs reliability mechanism). Some other realization of > CPIM can get that reliability through some other means. > > We also get some other side effects out of using SIP (such as causing > subscriptions to terminate if the NOTIFY received an error response). > A gateway to some other realization of CPIM would have to map these > ideas into their protocol. > > RjS > > -----Original Message----- > From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] > Sent: Friday, April 27, 2001 2:44 PM > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] Response to Notify > > > > The following paragraph is extracted from the > draft-ietf-impp-cpim-01.txt: > > "Regardless, there is no application response to the notify operation > (i.e., the application does not invoke a response operation when a > notify operation occurs)." > > What does it mean? Does it mean there is no "200 OK" to be expected? > > Please help. > Thanks, > > Dai Ngo > WCOM > From rsparks@dynamicsoft.com Mon Apr 30 09:56:42 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01180 for ; Mon, 30 Apr 2001 09:56:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA05179 for ; Mon, 30 Apr 2001 10:00:20 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Apr 2001 09:56:41 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A777@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: simple@mailman.dynamicsoft.com Date: Mon, 30 Apr 2001 09:56:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 553 Subject: [Simple] FYI - Drafts and mailing 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: For those coming up to speed on SIMPLE: The current working drafts are available at http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-00.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-im-00.txt The presence draft makes significant use of http://www.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-03.txt and, of course, they all rely on SIP. http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-02.txt Information on the SIP mailing-lists can be found at http://www.cs.columbia.edu/~hgs/sip/list.html RjS From arnaud.weil@winwise.fr Mon Apr 30 09:57:01 2001 Received: from pikachu.winwise.home ([194.98.12.74]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA01187 for ; Mon, 30 Apr 2001 09:57:01 -0400 (EDT) Received: from 172.17.1.250 by pikachu.winwise.home (InterScan E-Mail VirusWall NT); Mon, 30 Apr 2001 15:56:55 +0200 (Romance Daylight Time) Content-Class: urn:content-classes:message Subject: RE: [Simple] Response to Notify MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 30 Apr 2001 15:55:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Message-ID: <98D95D87610EA04296C7C3006888EA0815E568@milou.winwise.home> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Response to Notify thread-index: AcDRfNHQ0b3dXCisTH28c7lKnWIuoQAAFJUw From: "Arnaud Weil" To: "Robert Sparks" , Content-Length: 2409 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA01187 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: Thank you for your answer. Considering that an aknowledgement response is always needed, isn't this penalazing for devices with a low bandwith (e.g. cellular phones)? -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: lundi 30 avril 2001 15:54 To: Arnaud Weil; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Response to Notify The response is part of the basic SIP transaction. For this case, it doesn't matter what roles the participants are serving - the response is always required. RjS > -----Original Message----- > From: Arnaud Weil [mailto:arnaud.weil@winwise.fr] > Sent: Monday, April 30, 2001 4:44 AM > To: Robert Sparks; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Response to Notify > > > Excuse me if my question looks stupid, but I couldn't get a > copy of the > SIMPLE specifications. > > I'd like to know whether the acknowledgement that's required in SIMPLE > is required only for server/server interaction or also for > client/server > one. > > Thanks, > Arnaud Weil > > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: vendredi 27 avril 2001 23:58 > To: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] Response to Notify > > > > > It means there is no explicit acknowledgement of NOTIFY in the > abstract common protocol. > > In SIMPLE we require an acknowledgement (because we are using > SIP and that's SIPs reliability mechanism). Some other realization of > CPIM can get that reliability through some other means. > > We also get some other side effects out of using SIP (such as causing > subscriptions to terminate if the NOTIFY received an error response). > A gateway to some other realization of CPIM would have to map these > ideas into their protocol. > > RjS > > -----Original Message----- > From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] > Sent: Friday, April 27, 2001 2:44 PM > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] Response to Notify > > > > The following paragraph is extracted from the > draft-ietf-impp-cpim-01.txt: > > "Regardless, there is no application response to the notify operation > (i.e., the application does not invoke a response operation when a > notify operation occurs)." > > What does it mean? Does it mean there is no "200 OK" to be expected? > > Please help. > Thanks, > > Dai Ngo > WCOM > From sean.olson@ericsson.com Mon Apr 30 10:24:49 2001 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 KAA01322 for ; Mon, 30 Apr 2001 10:24:48 -0400 (EDT) Received: from mr6.exu.ericsson.se. (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3UEOp826634 for ; Mon, 30 Apr 2001 09:24:51 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se. (8.11.3/8.11.3) with SMTP id f3UEOli15805 for ; Mon, 30 Apr 2001 09:24:47 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Apr 30 09:24:47 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Apr 2001 09:24:47 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Arnaud Weil'" , Robert Sparks , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Response to Notify Date: Mon, 30 Apr 2001 09:24:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D181.4E857790" Content-Length: 9900 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: 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_01C0D181.4E857790 Content-Type: text/plain; charset="iso-8859-1" Not really. Any good communications protocol includes acknowledgements. The overhead in this case is minimal. /sean >-----Original Message----- >From: Arnaud Weil [mailto:arnaud.weil@winwise.fr] >Sent: Monday, April 30, 2001 8:56 AM >To: Robert Sparks; simple@mailman.dynamicsoft.com >Subject: RE: [Simple] Response to Notify > > >Thank you for your answer. > >Considering that an aknowledgement response is always needed, >isn't this >penalazing for devices with a low bandwith (e.g. cellular phones)? > >-----Original Message----- >From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: lundi 30 avril 2001 15:54 >To: Arnaud Weil; simple@mailman.dynamicsoft.com >Subject: RE: [Simple] Response to Notify > > >The response is part of the basic SIP transaction. For this >case, it doesn't matter what roles the participants are serving - >the response is always required. > >RjS > >> -----Original Message----- >> From: Arnaud Weil [mailto:arnaud.weil@winwise.fr] >> Sent: Monday, April 30, 2001 4:44 AM >> To: Robert Sparks; simple@mailman.dynamicsoft.com >> Subject: RE: [Simple] Response to Notify >> >> >> Excuse me if my question looks stupid, but I couldn't get a >> copy of the >> SIMPLE specifications. >> >> I'd like to know whether the acknowledgement that's required >in SIMPLE >> is required only for server/server interaction or also for >> client/server >> one. >> >> Thanks, >> Arnaud Weil >> >> -----Original Message----- >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >> Sent: vendredi 27 avril 2001 23:58 >> To: 'simple@mailman.dynamicsoft.com' >> Subject: RE: [Simple] Response to Notify >> >> >> >> >> It means there is no explicit acknowledgement of NOTIFY in the >> abstract common protocol. >> >> In SIMPLE we require an acknowledgement (because we are using >> SIP and that's SIPs reliability mechanism). Some other realization of >> CPIM can get that reliability through some other means. >> >> We also get some other side effects out of using SIP (such as causing >> subscriptions to terminate if the NOTIFY received an error response). >> A gateway to some other realization of CPIM would have to map these >> ideas into their protocol. >> >> RjS >> >> -----Original Message----- >> From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] >> Sent: Friday, April 27, 2001 2:44 PM >> To: 'simple@mailman.dynamicsoft.com' >> Subject: [Simple] Response to Notify >> >> >> >> The following paragraph is extracted from the >> draft-ietf-impp-cpim-01.txt: >> >> "Regardless, there is no application response to the notify operation >> (i.e., the application does not invoke a response operation when a >> notify operation occurs)." >> >> What does it mean? Does it mean there is no "200 OK" to be expected? >> >> Please help. >> Thanks, >> >> Dai Ngo >> WCOM >> >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C0D181.4E857790 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Response to Notify

Not really. Any good communications protocol
includes acknowledgements. The overhead in this
case is minimal.

/sean

>-----Original Message-----
>From: Arnaud Weil [mailto:arnaud.weil@winwise.fr]
>Sent: Monday, April 30, 2001 8:56 AM
>To: Robert Sparks; simple@mailman.dynamicsoft.com
>Subject: RE: [Simple] Response to Notify
>
>
>Thank you for your answer.
>
>Considering that an aknowledgement response is always needed,
>isn't this
>penalazing for devices with a low bandwith (e.g. cellular phones)?
>
>-----Original Message-----
>From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
>Sent: lundi 30 avril 2001 15:54
>To: Arnaud Weil; simple@mailman.dynamicsoft.com
>Subject: RE: [Simple] Response to Notify
>
>
>The response is part of the basic SIP transaction. For this
>case, it doesn't matter what roles the participants are serving -
>the response is always required.
>
>RjS
>
>> -----Original Message-----
>> From: Arnaud Weil [mailto:arnaud.weil@winwise.fr]
>> Sent: Monday, April 30, 2001 4:44 AM
>> To: Robert Sparks; simple@mailman.dynamicsoft.com
>> Subject: RE: [Simple] Response to Notify
>>
>>
>> Excuse me if my question looks stupid, but I couldn't get a
>> copy of the
>> SIMPLE specifications.
>> 
>> I'd like to know whether the acknowledgement that's required
>in SIMPLE
>> is required only for server/server interaction or also for
>> client/server
>> one.
>> 
>> Thanks,
>> Arnaud Weil
>>
>>  -----Original Message-----
>> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
>> Sent: vendredi 27 avril 2001 23:58
>> To: 'simple@mailman.dynamicsoft.com'
>> Subject: RE: [Simple] Response to Notify
>>
>>
>>
>>
>> It means there is no explicit acknowledgement of NOTIFY in the
>> abstract common protocol.
>> 
>> In SIMPLE we require an acknowledgement (because we are using
>> SIP and that's SIPs reliability mechanism). Some other realization of
>> CPIM can get that reliability through some other means.
>> 
>> We also get some other side effects out of using SIP (such as causing
>> subscriptions to terminate if the NOTIFY received an error response).
>> A gateway to some other realization of CPIM would have to map these
>> ideas into their protocol.
>> 
>> RjS
>>
>> -----Original Message-----
>> From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com]
>> Sent: Friday, April 27, 2001 2:44 PM
>> To: 'simple@mailman.dynamicsoft.com'
>> Subject: [Simple] Response to Notify
>>
>>
>>
>> The following paragraph is extracted from the
>> draft-ietf-impp-cpim-01.txt:
>>
>> "Regardless, there is no application response to the notify operation
>> (i.e., the application does not invoke a response operation when a
>> notify operation occurs)."
>>
>> What does it mean? Does it mean there is no "200 OK" to be expected?
>>
>> Please help.
>> Thanks,
>>
>> Dai Ngo
>> WCOM
>>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

------_=_NextPart_001_01C0D181.4E857790-- From c-Dai.Ngo@WCOM.Com Mon Apr 30 11:38:27 2001 Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01560 for ; Mon, 30 Apr 2001 11:38:26 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GCM00M963BMDC@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Mon, 30 Apr 2001 15:35:46 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GCM001013B8VH@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Mon, 30 Apr 2001 15:35:46 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GCM000D93B56T@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Mon, 30 Apr 2001 15:35:29 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Apr 2001 15:35:29 +0000 Content-return: allowed Date: Mon, 30 Apr 2001 15:35:25 +0000 From: "Ngo, Dai (c)" To: simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E11C54C@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_y67JRBxnQOguqKZvl2jX7g)" Content-Length: 2687 Subject: [Simple] Unsubscribe Operation Question 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: 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_y67JRBxnQOguqKZvl2jX7g) Content-type: text/plain; charset=ISO-8859-1 In section 3.4.3 (The Unsubscribe Operation) of the draft-ietf-impp-cpim-01.txt it says, "Otherwise, the in-progress subscribe operation for the application is terminated, and a response operation having status "success" is invoked by the service. ". According to this paragraph there is no notification is required to communicate the final status of the target. However in section 5.1.5.3 (Unsubscribing) of the draft-roach-sip-subscribe-notify-03.txt it says, "Note that a successful unsubscription will also trigger a final "NOTIFY". " It seems to me for SIMPLE a final NOTIFY is required to be sent to the watcher. But, by reviewing in section 7 (Mapping to CPIM) of the draft-ietf-simple-presence-00.txt there is no mention of sending a final NOTIFY to the watcher either. Any clarification is appreciated. Thanks. Dai Ngo --Boundary_(ID_y67JRBxnQOguqKZvl2jX7g) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Unsubscribe Operation Question

In section 3.4.3 (The Unsubscribe = Operation) of the draft-ietf-impp-cpim-01.txt it says, "Otherwise, = the in-progress subscribe operation for the application is terminated, = and a response operation having status "success" is invoked = by the service. ". According to this paragraph there is no = notification is required to communicate the final status of the = target.

However in section 5.1.5.3 = (Unsubscribing) of the draft-roach-sip-subscribe-notify-03.txt it says, = "Note that a successful unsubscription will also trigger a final = "NOTIFY". " It seems to me for SIMPLE a final NOTIFY is = required to be sent to the watcher.

But, by reviewing in section 7 = (Mapping to CPIM) of the draft-ietf-simple-presence-00.txt there is no = mention of sending a final NOTIFY to the watcher either.

Any clarification is = appreciated.
Thanks.
Dai Ngo

--Boundary_(ID_y67JRBxnQOguqKZvl2jX7g)-- From adam.roach@ericsson.com Mon Apr 30 14:27:22 2001 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 OAA02043 for ; Mon, 30 Apr 2001 14:27:21 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3UIRN823021; Mon, 30 Apr 2001 13:27:23 -0500 (CDT) 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 f3UIRJb12600; Mon, 30 Apr 2001 13:27:19 -0500 (CDT) Received: from eusadam (pc050163.exu.ericsson.se [138.85.50.163]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id NAA02965; Mon, 30 Apr 2001 13:27:19 -0500 (CDT) Reply-To: To: "'Ngo, Dai (c)'" , Subject: RE: [Simple] Unsubscribe Operation Question Date: Mon, 30 Apr 2001 13:27:17 -0500 Message-ID: <61D824C63B99D311975E00508B0CC9850225170F@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: <492EB4A3F68CD411ABE800508B69362E11C54C@RIPEXCH002.wcomnet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 1381 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: You have to realize that gateways from SIP presence domains into other presence domains may very well need to perform something other than a one-to-one mapping. In this case, a SIP message to unsubscribe from a users presence will be translated to two operations: a) a poll of presence state, and b) a request to unsubscribe from presence state. /a -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Monday, April 30, 2001 10:35 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] Unsubscribe Operation Question In section 3.4.3 (The Unsubscribe Operation) of the draft-ietf-impp-cpim-01.txt it says, "Otherwise, the in-progress subscribe operation for the application is terminated, and a response operation having status "success" is invoked by the service. ". According to this paragraph there is no notification is required to communicate the final status of the target. However in section 5.1.5.3 (Unsubscribing) of the draft-roach-sip-subscribe-notify-03.txt it says, "Note that a successful unsubscription will also trigger a final "NOTIFY". " It seems to me for SIMPLE a final NOTIFY is required to be sent to the watcher. But, by reviewing in section 7 (Mapping to CPIM) of the draft-ietf-simple-presence-00.txt there is no mention of sending a final NOTIFY to the watcher either. Any clarification is appreciated. Thanks. Dai Ngo From ranjitka@email.masconit.com Mon Apr 30 15:42:44 2001 Received: from mail.inetmail.att.net (mailhost1.inetmail.att.net [204.127.132.33]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02278 for ; Mon, 30 Apr 2001 15:42:43 -0400 (EDT) Received: from email.masconit.com ([12.41.17.214]) by mail.inetmail.att.net (mtiagic01) with ESMTP id <20010430194225gi1282831le>; Mon, 30 Apr 2001 19:42:30 +0000 Received: from ashok (RANJIT [12.41.17.196]) by email.masconit.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id JB7P3ZCQ; Mon, 30 Apr 2001 14:49:32 -0500 Message-ID: <031201c0d1ae$d477a760$c411290c@masconit.com> Reply-To: "Ranjit Avasarala" From: "Ranjit Avasarala" To: "Ajay Chitturi" , , References: <2E33960095B58E40A4D3345AB9F65EC121B84E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 30 Apr 2001 14:50:37 -0500 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.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Length: 1901 Subject: [Simple] Re: [Sip-implementors] Crashed and rebooted UAS scenario and CSeqs 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: Hi Ajay, That depends on the implementation of the server. so if the server reboots and all the prevoius transactions are lost, then the transaction will be rejected with a 481 response code , but if the server is able to retrieve prevoius transactions , then you can say trying (100) . Regards Ranjit ----- Original Message ----- From: Ajay Chitturi To: ; Sent: Monday, April 30, 2001 2:24 PM Subject: [Sip-implementors] Crashed and rebooted UAS scenario and CSeqs Hi, Section 11.5 of 2543bis says the UAS MAY reject the INVITE with a new Call-Id and a To header with a tag. Should we reject such an INVITE with a 481 ? Does this hold for SUBSCRIBE / MESSAGE (also an INVITE for an IM session). Could there be any scenarios where rejecting such sessions could create problems ? Also this section suggests that UAs wishing to handle such INVITEs robustly must choose monotonically increasing CSeq numbers even across reboots. Is there any simple mechanism for choosing CSeqs in such a manner ? draft-ietf-simple-im-00 (section 6.7)strongly recommends that CSeq should be computed using a clock (it refers to the SIP section on CSeq). This section also says "This allows for the CSeq to increment without requiring the UA to store the previous CSeq values". The SIP bis draft suggests that a client could use a 32 bit second clock for generating the CSeqs. This mechanism would work only if the client could guarantee that it will not generate more than one request per second. But this could be a problem in IM/Presence scenarios where we could have multiple MESSAGE or NOTIFY requests per second. Thanks Ajay. _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors From ajaych@windows.microsoft.com Mon Apr 30 15:46:16 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA02309 for ; Mon, 30 Apr 2001 15:46:16 -0400 (EDT) Received: from 157.54.7.67 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Apr 2001 12:24:28 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 30 Apr 2001 12:24:25 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 30 Apr 2001 12:24:25 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Apr 2001 12:24:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 30 Apr 2001 12:24:21 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC121B84E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Crashed and rebooted UAS scenario and CSeqs Thread-Index: AcDRqyiQQVWQRGXhR0akLP+6R+Cptg== From: "Ajay Chitturi" To: , X-OriginalArrivalTime: 30 Apr 2001 19:24:22.0049 (UTC) FILETIME=[28CCB110:01C0D1AB] Content-Length: 1149 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA02309 Subject: [Simple] Crashed and rebooted UAS scenario and CSeqs 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: Hi, Section 11.5 of 2543bis says the UAS MAY reject the INVITE with a new Call-Id and a To header with a tag. Should we reject such an INVITE with a 481 ? Does this hold for SUBSCRIBE / MESSAGE (also an INVITE for an IM session). Could there be any scenarios where rejecting such sessions could create problems ? Also this section suggests that UAs wishing to handle such INVITEs robustly must choose monotonically increasing CSeq numbers even across reboots. Is there any simple mechanism for choosing CSeqs in such a manner ? draft-ietf-simple-im-00 (section 6.7)strongly recommends that CSeq should be computed using a clock (it refers to the SIP section on CSeq). This section also says "This allows for the CSeq to increment without requiring the UA to store the previous CSeq values". The SIP bis draft suggests that a client could use a 32 bit second clock for generating the CSeqs. This mechanism would work only if the client could guarantee that it will not generate more than one request per second. But this could be a problem in IM/Presence scenarios where we could have multiple MESSAGE or NOTIFY requests per second. Thanks Ajay. From ajaych@windows.microsoft.com Mon Apr 30 18:48:32 2001 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA02808 for ; Mon, 30 Apr 2001 18:48:32 -0400 (EDT) Received: from 157.54.9.108 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Apr 2001 15:46:22 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 30 Apr 2001 15:48:01 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 30 Apr 2001 15:48:00 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 30 Apr 2001 15:47:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 30 Apr 2001 15:47:56 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC12FCC3D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS SRV query example Thread-Index: AcDRx5oO3In/br5lToqCpTRAMu3FUA== From: "Ajay Chitturi" To: X-OriginalArrivalTime: 30 Apr 2001 22:47:56.0986 (UTC) FILETIME=[997829A0:01C0D1C7] Content-Length: 226 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA02808 Subject: [Simple] DNS SRV query example 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: Hi, In Section 6.3 of draft-ietf-simple-im-00, the example for the SRV query for a url im:user@host is shown as _im._sip.host Shouldn't this be _im._sip._transport.host (where transport is udp, tcp, tls, etc.) Thanks Ajay. From c-Dai.Ngo@WCOM.Com Tue May 1 09:32:06 2001 Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14562 for ; Tue, 1 May 2001 09:32:02 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GCN0096PS9B2U@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Tue, 1 May 2001 13:31:59 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GCN00501S95JH@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Tue, 01 May 2001 13:31:59 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GCN003B1S8Z18@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Tue, 01 May 2001 13:31:47 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Tue, 01 May 2001 13:31:47 +0000 Content-return: allowed Date: Tue, 01 May 2001 13:31:44 +0000 From: "Ngo, Dai (c)" Subject: RE: [Simple] DNS SRV query example To: "'Ajay Chitturi'" , simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E11C552@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_88STR9f4YlVKmUfQK0oNPA)" Content-Length: 3376 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: 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_88STR9f4YlVKmUfQK0oNPA) Content-type: text/plain; charset=ISO-8859-1 Ajay, Here is the format of the record: "The format of the SRV RR Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Domain TTL Class SRV Priority Weight Port Target" Please see draft-ietf-dnsext-rfc2782bis-00.txt for more information. Hope this help. Dai Ngo -----Original Message----- From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] Sent: Monday, April 30, 2001 5:48 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] DNS SRV query example Hi, In Section 6.3 of draft-ietf-simple-im-00, the example for the SRV query for a url im:user@host is shown as _im._sip.host Shouldn't this be _im._sip._transport.host (where transport is udp, tcp, tls, etc.) Thanks Ajay. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple --Boundary_(ID_88STR9f4YlVKmUfQK0oNPA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable RE: [Simple] DNS SRV query example

Ajay,

Here is the format of the record:

"The format of the SRV RR

   Here is the format of the SRV RR, whose = DNS type code is 33:

        = _Service._Proto.Domain TTL Class SRV Priority Weight Port = Target"

Please see draft-ietf-dnsext-rfc2782bis-00.txt for = more information.

Hope this help.

Dai Ngo


-----Original Message-----
From: Ajay Chitturi [mailto:ajaych@windows.micro= soft.com]
Sent: Monday, April 30, 2001 5:48 PM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] DNS SRV query example


Hi,

In Section 6.3 of draft-ietf-simple-im-00, the = example for the SRV
query for a url im:user@host is shown as = _im._sip.host

Shouldn't this be _im._sip._transport.host (where = transport is udp, tcp,
tls, etc.)

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

--Boundary_(ID_88STR9f4YlVKmUfQK0oNPA)-- From c-Dai.Ngo@WCOM.Com Tue May 1 10:46:16 2001 Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14823 for ; Tue, 1 May 2001 10:46:16 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GCN00HO6VNZ8P@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Tue, 1 May 2001 14:45:35 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GCN00G01VNTSC@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Tue, 01 May 2001 14:45:34 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GCN00EFTVNJ7U@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Tue, 01 May 2001 14:45:19 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Tue, 01 May 2001 14:45:18 +0000 Content-return: allowed Date: Tue, 01 May 2001 14:45:17 +0000 From: "Ngo, Dai (c)" Subject: RE: [Simple] Unsubscribe Operation Question To: simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E11C553@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_+FjtlJeKS9Lwf/riwN7zBg)" Content-Length: 6303 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: 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_+FjtlJeKS9Lwf/riwN7zBg) Content-type: text/plain; charset=iso-8859-1 Adam, I understand that there is not a one-to-one mapping between gateways for CPIM and SIP. One thing I'm not sure of: "In order to conform to the SIP for Presence standard a final NOTIFY to the watcher, after sending 200/202 response, is required." Is it correct? For CPIM to SIP gateway function, is it the right the order? a) a poll of presence state, and b) a request to unsubscribe from presence state. If so, does a) mean sending a fetch operation? Thanks and regards, Dai Ngo -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Monday, April 30, 2001 1:27 PM To: Ngo, Dai (c); simple@mailman.dynamicsoft.com Subject: RE: [Simple] Unsubscribe Operation Question You have to realize that gateways from SIP presence domains into other presence domains may very well need to perform something other than a one-to-one mapping. In this case, a SIP message to unsubscribe from a users presence will be translated to two operations: a) a poll of presence state, and b) a request to unsubscribe from presence state. /a -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Monday, April 30, 2001 10:35 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] Unsubscribe Operation Question In section 3.4.3 (The Unsubscribe Operation) of the draft-ietf-impp-cpim-01.txt it says, "Otherwise, the in-progress subscribe operation for the application is terminated, and a response operation having status "success" is invoked by the service. ". According to this paragraph there is no notification is required to communicate the final status of the target. However in section 5.1.5.3 (Unsubscribing) of the draft-roach-sip-subscribe-notify-03.txt it says, "Note that a successful unsubscription will also trigger a final "NOTIFY". " It seems to me for SIMPLE a final NOTIFY is required to be sent to the watcher. But, by reviewing in section 7 (Mapping to CPIM) of the draft-ietf-simple-presence-00.txt there is no mention of sending a final NOTIFY to the watcher either. Any clarification is appreciated. Thanks. Dai Ngo --Boundary_(ID_+FjtlJeKS9Lwf/riwN7zBg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: [Simple] Unsubscribe Operation Question

Adam,

I understand that there is not a one-to-one mapping = between gateways for CPIM and SIP.

One thing I'm not sure of: "In order to conform = to the SIP for Presence standard a final NOTIFY to the watcher, after = sending 200/202 response, is required."

Is it correct?

For CPIM to SIP gateway function, is it the right the = order?

a) a poll of presence state, and
b) a request to unsubscribe from presence = state.

If so, does a) mean sending a fetch operation?

Thanks and regards,

Dai Ngo

-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Monday, April 30, 2001 1:27 PM
To: Ngo, Dai (c); = simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Unsubscribe Operation = Question


You have to realize that gateways from SIP presence = domains into other presence
domains may very well need to perform something = other than a one-to-one
mapping.

In this case, a SIP message to unsubscribe from a = users presence will be
translated to two operations:

a) a poll of presence state, and
b) a request to unsubscribe from presence = state.

/a

-----Original Message-----
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com]=
Sent: Monday, April 30, 2001 10:35 AM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] Unsubscribe Operation = Question


In section 3.4.3 (The Unsubscribe Operation) of the = draft-ietf-impp-cpim-01.txt
it says, "Otherwise, the in-progress subscribe = operation for the application is
terminated, and a response operation having status = "success" is invoked by the
service. ". According to this paragraph there = is no notification is required to
communicate the final status of the target.

However in section 5.1.5.3 (Unsubscribing) of = the
draft-roach-sip-subscribe-notify-03.txt it says, = "Note that a successful
unsubscription will also trigger a final = "NOTIFY". " It seems to me for SIMPLE
a final NOTIFY is required to be sent to the = watcher.
But, by reviewing in section 7 (Mapping to CPIM) of = the
draft-ietf-simple-presence-00.txt there is no = mention of sending a final NOTIFY
to the watcher either.
Any clarification is appreciated.
Thanks.
Dai Ngo

--Boundary_(ID_+FjtlJeKS9Lwf/riwN7zBg)-- From c-Dai.Ngo@WCOM.Com Tue May 1 13:40:47 2001 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 NAA15344 for ; Tue, 1 May 2001 13:40:47 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GCO005J93RXS7@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Tue, 1 May 2001 17:40:45 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GCO00B013RN6M@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Tue, 01 May 2001 17:40:44 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GCO00A383RBPL@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Tue, 01 May 2001 17:40:23 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Tue, 01 May 2001 17:40:23 +0000 Content-return: allowed Date: Tue, 01 May 2001 17:40:20 +0000 From: "Ngo, Dai (c)" To: simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E11C555@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_g4WI4HAy5ZZYA25TtSPd0Q)" Content-Length: 1609 Subject: [Simple] URI Conversion 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: 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_g4WI4HAy5ZZYA25TtSPd0Q) Content-type: text/plain; charset=ISO-8859-1 Hi, Does anyone have any other thoughts of a working "solution" for URI conversion, i.e. SIP URL from/to Presence/IM URI? Thanks. Dai Ngo --Boundary_(ID_g4WI4HAy5ZZYA25TtSPd0Q) Content-type: text/html; charset=ISO-8859-1 RE: [Simple] Unsubscribe Operation Question
Hi,
 
Does anyone have any other thoughts of a working "solution" for URI conversion, i.e. SIP URL from/to Presence/IM URI?
 
Thanks.
 
Dai Ngo
--Boundary_(ID_g4WI4HAy5ZZYA25TtSPd0Q)-- From rsparks@dynamicsoft.com Tue May 1 13:55:00 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15406 for ; Tue, 1 May 2001 13:55:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA01449 for ; Tue, 1 May 2001 13:58:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 13:54:59 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A788@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Tue, 1 May 2001 13:54:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1053 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: Folks - we need to move this along so we can free our crucible for discussion on publishing and authentication. I propose that we move ahead and develop the text around *) session free "pages", very much like what we've already defined *) "chat" sessions consisting of MESSAGE requests bounded by an INVITE/BYE To address the discussions date: Is it sufficient for the MESSAGE requests in the chat session to follow the Route established by the INVITE/BYE bounding it? Proposal : Yes - In the normal case, proxies that don't truly need to be in the path of subsequent requests won't record route, so we should end up with a minimal path for these requests. Would sip services (proxy/redirect servers) need to be able to distinguish INVITEs for MESSAGE sessions from INVITES from other streaming media. Proposal : No - at least not any more than the services already need to be able to differentiate between different types of media streams. Without objection, we will move ahead with these ideas in the text. RjS From bcampbell@dynamicsoft.com Tue May 1 17:06:29 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15971 for ; Tue, 1 May 2001 17:06:29 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA05434 for ; Tue, 1 May 2001 17:10:09 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 May 2001 17:06:29 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30B3A@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: Robert Sparks , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] IM: A session or not Date: Tue, 1 May 2001 17:06:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2692 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: > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Tuesday, May 01, 2001 12:55 PM > To: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] IM: A session or not > > > Folks - we need to move this along so we can free our crucible > for discussion on publishing and authentication. > > I propose that we move ahead and develop the text around > > *) session free "pages", very much like what we've already defined > *) "chat" sessions consisting of MESSAGE requests bounded by > an INVITE/BYE > > To address the discussions date: > > Is it sufficient for the MESSAGE requests in the chat session > to follow the Route established by the INVITE/BYE bounding it? > > Proposal : > Yes - > In the normal case, proxies that don't truly need to be in the > path of subsequent requests won't record route, so we should > end up with a minimal path for these requests. > > Would sip services (proxy/redirect servers) need to be able to > distinguish INVITEs for MESSAGE sessions from INVITES from other > streaming media. > > Proposal : > No - > at least not any more than the services already need to be > able to differentiate between different types of media streams. > On reflection, (and feel free to hit me for not bringing this up in our discussion earlier today), I think I have to object to the not-routing-by-media-type provision. Right now, I have both a PC and a SIP phone on my desk. They have separate IP addresses. My SIP phone does not support messaging (yet) and my PC makes a lousy phone because of windows media considerations. Therefore I would prefer to route message sessions and voice sessions differently. I would still be able to do this by publishing a distinct URI for message sessions and for voice sessions, but this is not very satisfying. I would prefer to just tell everyone to use sip:bcampbell@dynamicsoft.com for either media. This is not an IM specific problem, as I am also likely to wish video sessions to sip:bcampbell@dynamicsoft.com to go to a different device than voice sessions. On the otherhand perhaps, according to CPIM discussions, my published URL for messaging should instead be the abstract im:bcampbell@dynamicsoft.com, and do an SRV lookup or some other DNS magic to convert that to an concrete sip URL. I suppose one could set things up where that actually resolved to sip:bcampbell@im.dynamicsoft.com, which could be routed differently to sip:bcampbell@dynamicsoft.com. This is less annoying than the first situation, as I will typically tell my friends I am bcampbell@dynamicsoft.com and let them figure out what scheme to use based on the application (mailto:, sip:, pres:, im:, etc.) From sean.olson@ericsson.com Tue May 1 17:21:42 2001 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 RAA16034 for ; Tue, 1 May 2001 17:21:42 -0400 (EDT) Received: from mr7.exu.ericsson.se. (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f41LLi828794 for ; Tue, 1 May 2001 16:21:45 -0500 (CDT) 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 f41LLeK10955 for ; Tue, 1 May 2001 16:21:40 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue May 01 16:21:40 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 16:21:39 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Robert Sparks'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Tue, 1 May 2001 16:21:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D284.B516CBE0" Content-Length: 4186 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: 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_01C0D284.B516CBE0 Content-Type: text/plain; charset="iso-8859-1" >Is it sufficient for the MESSAGE requests in the chat session >to follow the Route established by the INVITE/BYE bounding it? > > Proposal : > Yes - > In the normal case, proxies that don't truly need to be in the > path of subsequent requests won't record route, so we should > end up with a minimal path for these requests. This does not compute. If you are treating the MESSAGEs as "media" for the INVITE session, then the routing of the MESSAGE should be independent from the routing for the INVITE and ideally should be directly end-to-end. If you want something different, then you need a different mechanism than INVITE. (You are speaking about the option of using SDP to describe a application/sip "session", right?) > >Would sip services (proxy/redirect servers) need to be able to >distinguish INVITEs for MESSAGE sessions from INVITES from other >streaming media. > > Proposal : > No - > at least not any more than the services already need to be > able to differentiate between different types of media streams. This is equivalent to asking if proxy/redirect servers should care about the SDP / media, right? Again, I am unsure of exactly what you are proposing. > >Without objection, we will move ahead with these ideas in the text. > >RjS /sean ------_=_NextPart_001_01C0D284.B516CBE0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] IM: A session or not

>Is it sufficient for the MESSAGE requests in the chat session
>to follow the Route established by the INVITE/BYE bounding it?
>
>  Proposal :
>   Yes -
>   In the normal case, proxies that don't truly need to be in the
>   path of subsequent requests won't record route, so we should
>   end up with a minimal path for these requests.

This does not compute. If you are treating the MESSAGEs as
"media" for the INVITE session, then the routing of the
MESSAGE should be independent from the routing for the INVITE and
ideally should be directly end-to-end. If you want something different,
then you need a different mechanism than INVITE. (You are speaking
about the option of using SDP to describe a application/sip "session",
right?)

>
>Would sip services (proxy/redirect servers) need to be able to
>distinguish INVITEs for MESSAGE sessions from INVITES from other
>streaming media.
>
>  Proposal :
>   No -
>   at least not any more than the services already need to be
>   able to differentiate between different types of media streams.

This is equivalent to asking if proxy/redirect servers should care
about the SDP / media, right? Again, I am unsure of exactly what
you are proposing.

>
>Without objection, we will move ahead with these ideas in the text.
>
>RjS

/sean

------_=_NextPart_001_01C0D284.B516CBE0-- From adam.roach@ericsson.com Tue May 1 20:03:39 2001 Received: from imr2.ericy.com ([12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16483 for ; Tue, 1 May 2001 20:03:39 -0400 (EDT) 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 f4203b802996; Tue, 1 May 2001 19:03:38 -0500 (CDT) 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 f4203b924724; Tue, 1 May 2001 19:03:37 -0500 (CDT) Received: from eusadam (pc050163.exu.ericsson.se [138.85.50.163]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id TAA15640; Tue, 1 May 2001 19:03:37 -0500 (CDT) Reply-To: To: "'Ngo, Dai (c)'" , Subject: RE: [Simple] Unsubscribe Operation Question Date: Tue, 1 May 2001 18:38:10 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251734@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: <492EB4A3F68CD411ABE800508B69362E11C553@RIPEXCH002.wcomnet.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 2423 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: The order in which they are sent should not matter (assuming a poll is valid in an unsubscribed state, which I beleive it is). /a -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Tuesday, May 01, 2001 9:45 AM To: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Unsubscribe Operation Question Adam, I understand that there is not a one-to-one mapping between gateways for CPIM and SIP. One thing I'm not sure of: "In order to conform to the SIP for Presence standard a final NOTIFY to the watcher, after sending 200/202 response, is required." Is it correct? For CPIM to SIP gateway function, is it the right the order? a) a poll of presence state, and b) a request to unsubscribe from presence state. If so, does a) mean sending a fetch operation? Thanks and regards, Dai Ngo -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Monday, April 30, 2001 1:27 PM To: Ngo, Dai (c); simple@mailman.dynamicsoft.com Subject: RE: [Simple] Unsubscribe Operation Question You have to realize that gateways from SIP presence domains into other presence domains may very well need to perform something other than a one-to-one mapping. In this case, a SIP message to unsubscribe from a users presence will be translated to two operations: a) a poll of presence state, and b) a request to unsubscribe from presence state. /a -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Monday, April 30, 2001 10:35 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] Unsubscribe Operation Question In section 3.4.3 (The Unsubscribe Operation) of the draft-ietf-impp-cpim-01.txt it says, "Otherwise, the in-progress subscribe operation for the application is terminated, and a response operation having status "success" is invoked by the service. ". According to this paragraph there is no notification is required to communicate the final status of the target. However in section 5.1.5.3 (Unsubscribing) of the draft-roach-sip-subscribe-notify-03.txt it says, "Note that a successful unsubscription will also trigger a final "NOTIFY". " It seems to me for SIMPLE a final NOTIFY is required to be sent to the watcher. But, by reviewing in section 7 (Mapping to CPIM) of the draft-ietf-simple-presence-00.txt there is no mention of sending a final NOTIFY to the watcher either. Any clarification is appreciated. Thanks. Dai Ngo From adam.roach@ericsson.com Tue May 1 20:03:43 2001 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 UAA16488 for ; Tue, 1 May 2001 20:03:42 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se. (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f4203j809537; Tue, 1 May 2001 19:03:45 -0500 (CDT) 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 f4203e924742; Tue, 1 May 2001 19:03:40 -0500 (CDT) Received: from eusadam (pc050163.exu.ericsson.se [138.85.50.163]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id TAA15643; Tue, 1 May 2001 19:03:40 -0500 (CDT) Reply-To: To: "'Robert Sparks'" , Subject: RE: [Simple] IM: A session or not Date: Tue, 1 May 2001 18:56:48 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251735@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: <9BF66EBF6BEFD942915B4D4D45C051F314A788@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 2143 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: > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > To address the discussions date: > > Is it sufficient for the MESSAGE requests in the chat session > to follow the Route established by the INVITE/BYE bounding it? > > Proposal : > Yes - > In the normal case, proxies that don't truly need to be in the > path of subsequent requests won't record route, so we should > end up with a minimal path for these requests. Personally, I *really* prefer another approach Jonathan presented at the SIMPLE meeting during the 50th IETF: the INVITE contains SDP using UDP or TCP as the transport, and message/sip as the media type. What you seem to be proposing really sets the idea of sessions as we've previously known them on its head. On the other hand, if we use the body to *describe* the session, it is extremely in line with everything INVITE has meant so far. v=0 o=adam.roach 97438978197648642 0 IN IP4 138.85.60.124 s=- p=+19725830000 c=IN IP4 138.85.60.124 t=0 0 m=message 5060 udp sip (Excuse me if my syntax is incorrect; my knowledge of SDP currently is strongly biased towards using it for RTP/AVP, and I'm feeling a bit too lazy just now to look up whether my hypothetical SDP message is 100% correct -- but I think I get the idea across). > Would sip services (proxy/redirect servers) need to be able to > distinguish INVITEs for MESSAGE sessions from INVITES from other > streaming media. > > Proposal : > No - > at least not any more than the services already need to be > able to differentiate between different types of media streams. This seems okay. Currently, if I have multiple devices which have different capabilities, I would probably need some sort of incoming proxy which would interpret parts of the SDP, at least rudimentarily. E.g. if the snippet "[cr][lf]m=video" is present, it would route to my PC client. If only "m=audio" lines are present, it might fork to my desk phone and my mobile. Extending this scheme to treat SIP IM as just another media makes sense: I could set it up to fork (the *INVITE*, not the *MEDIA*) to my desktop and my palmtop with a CDPD modem. /a From jundery@ubiquity.net Wed May 2 05:38:29 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA18005 for ; Wed, 2 May 2001 05:38:28 -0400 (EDT) Received: from gecko by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 2 May 2001 09:38:28 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA09471; Wed, 2 May 2001 10:38:14 +0100 (BST) Message-ID: <3AEFD589.86DB2616@ubiquity.net> Date: Wed, 02 May 2001 10:38:17 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: Robert Sparks , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] IM: A session or not References: <9BF66EBF6BEFD942915B4D4D45C051F30B3A@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3314 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: Ben Campbell wrote: > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Tuesday, May 01, 2001 12:55 PM > > To: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] IM: A session or not > > > > > > Folks - we need to move this along so we can free our crucible > > for discussion on publishing and authentication. > > > > I propose that we move ahead and develop the text around > > > > *) session free "pages", very much like what we've already defined > > *) "chat" sessions consisting of MESSAGE requests bounded by > > an INVITE/BYE > > > > To address the discussions date: > > > > Is it sufficient for the MESSAGE requests in the chat session > > to follow the Route established by the INVITE/BYE bounding it? > > > > Proposal : > > Yes - > > In the normal case, proxies that don't truly need to be in the > > path of subsequent requests won't record route, so we should > > end up with a minimal path for these requests. > > > > Would sip services (proxy/redirect servers) need to be able to > > distinguish INVITEs for MESSAGE sessions from INVITES from other > > streaming media. > > > > Proposal : > > No - > > at least not any more than the services already need to be > > able to differentiate between different types of media streams. > > > > On reflection, (and feel free to hit me for not bringing this up in our > discussion earlier today), I think I have to object to the > not-routing-by-media-type provision. Right now, I have both a PC and a SIP > phone on my desk. They have separate IP addresses. My SIP phone does not > support messaging (yet) and my PC makes a lousy phone because of windows > media considerations. Therefore I would prefer to route message sessions and > voice sessions differently. I will agree with Ben here, although I'd note I expect dumb phones to reject the INVITE with a chat session in it, and the messaging UA to reject calls with media (if I tell it to). An additional consideration is using callee prefs, "page" messages and invites to "chat" sessions will be routed differently. > On the otherhand perhaps, according to CPIM discussions, my published URL > for messaging should instead be the abstract im:bcampbell@dynamicsoft.com, > and do an SRV lookup or some other DNS magic to convert that to an concrete > sip URL. I suppose one could set things up where that actually resolved to > sip:bcampbell@im.dynamicsoft.com, which could be routed differently to > sip:bcampbell@dynamicsoft.com. This is less annoying than the first > situation, as I will typically tell my friends I am > bcampbell@dynamicsoft.com and let them figure out what scheme to use based > on the application (mailto:, sip:, pres:, im:, etc.) I don't think CPIM requires that the im: tag is used for anything other than interworking. Using im: URLs will cause problems for proxies that don't know how to route them, i.e. just like sip:. On reflection I see this as a problem with caller preferences as it's a more general problem. By this I mean tying a contact url to a method is a very course filter, another example is where an end point handles SUBSCRIBE for "Event: foo", I'd only want SUBSCRIBEs for "Event: foo" to go there and perhaps have other SUBSCRIBEs to be handled at the proxy. Anyway I am typing aloud. James Undery From jdrosen@dynamicsoft.com Wed May 2 09:13:37 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18580 for ; Wed, 2 May 2001 09:13:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA11346; Wed, 2 May 2001 09:17:16 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 09:13:36 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] URI Conversion Date: Wed, 2 May 2001 09:13:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1203 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: -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Tuesday, May 01, 2001 1:40 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] URI Conversion >Hi, > >Does anyone have any other thoughts of a working "solution" for URI conversion, i.e. SIP >URL from/to Presence/IM URI? > I suspect you really only need to convert in one direction - presence/IM URL to SIP URL. When addressing a SIP->CPIM gateway with a SIP request, you shouldn't convert the pres URL to a SIP URL to begin with. How to support that using DNS queries is a good question. Presence URL to SIP URL conversion is trivial, and would be nothing more than replacing the scheme with sip. Alot of this depends on the DNS mechanisms used; if naptr is specified, then the naptr record would actually specify how the conversion is done. -Jonathan R. --- Jonathan D. Rosenberg 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 From jdrosen@dynamicsoft.com Wed May 2 09:23:08 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18626 for ; Wed, 2 May 2001 09:23:07 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA11548; Wed, 2 May 2001 09:26:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 09:23:06 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ajay Chitturi'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] DNS SRV query example Date: Wed, 2 May 2001 09:23:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1114 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: > -----Original Message----- > From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] > Sent: Monday, April 30, 2001 6:48 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] DNS SRV query example > > > Hi, > > In Section 6.3 of draft-ietf-simple-im-00, the example for the SRV > query for a url im:user@host is shown as _im._sip.host > > Shouldn't this be _im._sip._transport.host (where transport > is udp, tcp, > tls, etc.) The usage of SRV for this translation is still being debated within IMPP. If SRV is used, it will not be exactly as specified in rfc2782. One proposal was to use a form along the lines of "_im._sip.domain", and then do a sip srv query on the result. This is still being hammered out on the impp list. -Jonathan R. --- Jonathan D. Rosenberg 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 From rsparks@dynamicsoft.com Wed May 2 11:39:40 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19010 for ; Wed, 2 May 2001 11:39:40 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA13881; Wed, 2 May 2001 11:43:18 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 11:39:37 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A78E@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Sean Olson (EUS)'" , simple@mailman.dynamicsoft.com, "'adam.roach@ericsson.com'" Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 11:39:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2082 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: To: >>Is it sufficient for the MESSAGE requests in the chat session >>to follow the Route established by the INVITE/BYE bounding it? >> >> Proposal : >> Yes - >> In the normal case, proxies that don't truly need to be in the >> path of subsequent requests won't record route, so we should >> end up with a minimal path for these requests. Sean Olsen replied: >This does not compute. If you are treating the MESSAGEs as >"media" for the INVITE session, then the routing of the >MESSAGE should be independent from the routing for the INVITE and >ideally should be directly end-to-end. If you want something different, >then you need a different mechanism than INVITE. (You are speaking >about the option of using SDP to describe a application/sip "session", >right?) Adam Roach replied: >Personally, I *really* prefer another approach Jonathan presented >at the SIMPLE meeting during the 50th IETF: the INVITE contains SDP >using UDP or TCP as the transport, and message/sip as the media type. > >What you seem to be proposing really sets the idea of sessions as >we've previously known them on its head. On the other hand, if we >use the body to *describe* the session, it is extremely in line >with everything INVITE has meant so far. Lets explore the details of this a little then. We are assuming that there is enough information in the setup that things in the middle affecting end-end visibility (SIP aware firewalls or nats for example) can do what they need to do, at least as well as they do for rtp streams today. This is almost a no-brainer for sip over UDP, but are we still ok if the chat session needs to take place over TLS? How will this impact environments that restrict all SIP traffic across thier boundaries to proxies? How can you get the chat session through them? Or are we _only_ going to support chat if we can get e-e with no proxies (this has some appeal - we don't have to worry about a chat MESSAGE getting forked). How much of the call-leg identifier used by the chat session itself do you signal with the INVITE? RjS From adam.roach@ericsson.com Wed May 2 11:49:20 2001 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 LAA19080 for ; Wed, 2 May 2001 11:49:20 -0400 (EDT) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se. (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f42FnG802478; Wed, 2 May 2001 10:49:16 -0500 (CDT) 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 f42FnB412164; Wed, 2 May 2001 10:49:11 -0500 (CDT) Received: from eusadam (pc050163.exu.ericsson.se [138.85.50.163]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id KAA19731; Wed, 2 May 2001 10:49:10 -0500 (CDT) Reply-To: To: "'James Undery'" , "Ben Campbell" Cc: "Robert Sparks" , Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 10:49:08 -0500 Message-ID: <61D824C63B99D311975E00508B0CC9850225173E@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: <3AEFD589.86DB2616@ubiquity.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 230 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: > I don't think CPIM requires that the im: tag is used for > anything other than > interworking. Using im: URLs will cause problems for proxies > that don't know how > to route them, i.e. just like sip:. I strongly agree. /a From bcampbell@dynamicsoft.com Wed May 2 11:57:04 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19131 for ; Wed, 2 May 2001 11:57:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA14343; Wed, 2 May 2001 12:00:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 11:56:56 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30B3F@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: "'adam.roach@ericsson.com'" , "'James Undery'" , Ben Campbell Cc: Robert Sparks , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 11:56:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 953 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: I was not suggesting a UAC would ever send an im: URL, but that if I typed in an im: URL, the UAC would use the srv/naptr stuff to resolve to a sip: URL, then use the sip: URL in the INVITE. If I were to publish an instant message address on a business card, it expected it _would_ be an im: URL. (Realizing of course I would more likely be publishing a presence URL and letting the presence system deliver the message address) > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Wednesday, May 02, 2001 10:49 AM > To: 'James Undery'; Ben Campbell > Cc: Robert Sparks; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] IM: A session or not > > > > I don't think CPIM requires that the im: tag is used for > > anything other than > > interworking. Using im: URLs will cause problems for proxies > > that don't know how > > to route them, i.e. just like sip:. > > I strongly agree. > > /a > From adam.roach@ericsson.com Wed May 2 12:03:12 2001 Received: from imr2.ericy.com ([12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19200 for ; Wed, 2 May 2001 12:03:11 -0400 (EDT) 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 f42G2x818154; Wed, 2 May 2001 11:02:59 -0500 (CDT) 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 f42G2wd25408; Wed, 2 May 2001 11:02:59 -0500 (CDT) Received: from eusadam (pc050163.exu.ericsson.se [138.85.50.163]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA20672; Wed, 2 May 2001 11:02:57 -0500 (CDT) Reply-To: To: "'Robert Sparks'" , "Sean Olson (EUS)" <>, , Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 11:02:56 -0500 Message-ID: <61D824C63B99D311975E00508B0CC9850225173F@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: <9BF66EBF6BEFD942915B4D4D45C051F314A78E@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 2686 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: > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > >>Is it sufficient for the MESSAGE requests in the chat session > >>to follow the Route established by the INVITE/BYE bounding it? > >> > >> Proposal : > >> Yes - > >> In the normal case, proxies that don't truly need to be in the > >> path of subsequent requests won't record route, so we should > >> end up with a minimal path for these requests. ... > Adam Roach replied: > >Personally, I *really* prefer another approach Jonathan presented > >at the SIMPLE meeting during the 50th IETF: the INVITE contains SDP > >using UDP or TCP as the transport, and message/sip as the media type. ... > Lets explore the details of this a little then. > > We are assuming that there is enough information in the > setup that things in the middle affecting end-end > visibility (SIP aware firewalls or nats for example) can > do what they need to do, at least as well as they do for rtp > streams today. This is almost a no-brainer for sip over UDP, > but are we still ok if the chat session needs to take place over > TLS? The exact same way we do it for RTP. Alright, that's sort of flip; my point is: whatever you do to secure RTP traffic can be done for IM "media." If it's sufficient for one, it's sufficient for the other. If it's insufficient for one, it's insufficient for the other. > How will this impact environments that restrict all SIP traffic > across thier boundaries to proxies? How can you get the chat > session through them? Or are we _only_ going to support chat > if we can get e-e with no proxies (this has some appeal - we > don't have to worry about a chat MESSAGE getting forked). The exact same way it does for RTP. And that's *not* intended to be flip. Firewalls break media; for normal SIP sessions to work through them, we expect them to fix the mess they've created: open holes or modify the SDP. Firewalls break SIP-IM messages as media; for SIP-IM sessions to work through them, we expect them to fix them mess they've created: open holes or modify the SDP. Remember, our job is **NOT** trying to figure out ways to circumvent measures put in place by firewall administrators. If you're concerned about getting the messages through a firewall regardless of local policy, we should really be putting together a draft on running SIP IM sessions over HTTP (a la RFC3093). > How much of the call-leg identifier used by the chat session > itself do you signal with the INVITE? Good question. My inclination is to use exactly the same correlation information so that matching up of different messaging "sessions" is trivial. Can anyone think why this might be a bad idea? /a From rsparks@dynamicsoft.com Wed May 2 14:54:21 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19701 for ; Wed, 2 May 2001 14:54:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA17369; Wed, 2 May 2001 14:58:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 14:54:20 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A78F@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'adam.roach@ericsson.com'" , Robert Sparks , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 14:54:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 4501 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: > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Wednesday, May 02, 2001 11:03 AM > To: 'Robert Sparks'; simple@mailman.dynamicsoft.com; > adam.roach@ericsson.com > Subject: RE: [Simple] IM: A session or not > > > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > >>Is it sufficient for the MESSAGE requests in the chat session > > >>to follow the Route established by the INVITE/BYE bounding it? > > >> > > >> Proposal : > > >> Yes - > > >> In the normal case, proxies that don't truly need to be in the > > >> path of subsequent requests won't record route, so we should > > >> end up with a minimal path for these requests. > ... > > Adam Roach replied: > > >Personally, I *really* prefer another approach Jonathan presented > > >at the SIMPLE meeting during the 50th IETF: the INVITE contains SDP > > >using UDP or TCP as the transport, and message/sip as the > media type. > ... > > Lets explore the details of this a little then. > > > > We are assuming that there is enough information in the > > setup that things in the middle affecting end-end > > visibility (SIP aware firewalls or nats for example) can > > do what they need to do, at least as well as they do for rtp > > streams today. This is almost a no-brainer for sip over UDP, > > but are we still ok if the chat session needs to take place over > > TLS? > > The exact same way we do it for RTP. > > Alright, that's sort of flip; my point is: whatever you do to secure > RTP traffic can be done for IM "media." If it's sufficient for one, > it's sufficient for the other. If it's insufficient for one, it's > insufficient for the other. I agree with you here, at least on the approach to the solving the problem. I do want to reinforce that more work would have to be done to support things like signalling that the chat session should take place using SIP over TLS and providing enough information. That is different enough from the mainstream work done to date that we need to look at it closely for dragons. > > > How will this impact environments that restrict all SIP traffic > > across thier boundaries to proxies? How can you get the chat > > session through them? Or are we _only_ going to support chat > > if we can get e-e with no proxies (this has some appeal - we > > don't have to worry about a chat MESSAGE getting forked). > > The exact same way it does for RTP. > > And that's *not* intended to be flip. Firewalls break media; for > normal SIP sessions to work through them, we expect them to fix > the mess they've created: open holes or modify the SDP. > > Firewalls break SIP-IM messages as media; for SIP-IM sessions to > work through them, we expect them to fix them mess they've > created: open holes or modify the SDP. > > Remember, our job is **NOT** trying to figure out ways to > circumvent measures put in place by firewall administrators. > If you're concerned about getting the messages through a > firewall regardless of local policy, we should really be putting > together a draft on running SIP IM sessions over HTTP (a la RFC3093). And you missed my point altogether here. I wasn't talking about circumventing policy. I was talking about being able to actually _comply_ with it if I wanted to. Firewall like behavior is the cheap and easy answer for why one might want SIP traffic to be forced to go through a proxy - there are others (though I can't at the moment come up with a truly compelling application for any of them with respect to a chat session). What you are suggesting is that a chat session be _only_ point to point, ala the use of RTP, and that in no circumstance would it involve a SIP proxy. I'm not comfortable making that strong a statement yet. > > > How much of the call-leg identifier used by the chat session > > itself do you signal with the INVITE? > > Good question. My inclination is to use exactly the same correlation > information so that matching up of different messaging "sessions" > is trivial. Can anyone think why this might be a bad idea? By same correlation information, you mean same to, from, and call-id, counting on the INVITE arriving on a different transport than the MESSAGEs (at least on different ports) so you don't get into CSeq mismatch errors? At its best, this will make for great debugging pain. What about the other end of the spectrum, where you pass the a whole new call-leg tuple as part of the SDP, or at least a new Call-ID? RjS From adam.roach@ericsson.com Wed May 2 15:22:55 2001 Received: from imr2.ericy.com ([12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19808 for ; Wed, 2 May 2001 15:22:54 -0400 (EDT) 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 f42JMq824577; Wed, 2 May 2001 14:22:52 -0500 (CDT) 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 f42JMpI01331; Wed, 2 May 2001 14:22:51 -0500 (CDT) Received: from eusadam (pc050163.exu.ericsson.se [138.85.50.163]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id OAA00882; Wed, 2 May 2001 14:22:51 -0500 (CDT) Reply-To: To: "'Robert Sparks'" , , Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 14:22:47 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251747@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: <9BF66EBF6BEFD942915B4D4D45C051F314A78F@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 1800 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: > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] ... > > Firewalls break SIP-IM messages as media; for SIP-IM sessions to > > work through them, we expect them to fix them mess they've > > created: open holes or modify the SDP. > > > > Remember, our job is **NOT** trying to figure out ways to > > circumvent measures put in place by firewall administrators. > > If you're concerned about getting the messages through a > > firewall regardless of local policy, we should really be putting > > together a draft on running SIP IM sessions over HTTP (a la > RFC3093). > > And you missed my point altogether here. I wasn't talking about > circumventing policy. I was talking about being able to actually > _comply_ with it if I wanted to. Firewall like behavior is the > cheap and easy answer for why one might want SIP traffic to be > forced to go through a proxy - there are others (though I can't > at the moment come up with a truly compelling application for > any of them with respect to a chat session). Pie-in-the-sky answer: babelfish. > What you are suggesting > is that a chat session be _only_ point to point, ala the use of RTP, > and that in no circumstance would it involve a SIP proxy. I'm not > comfortable making that strong a statement yet. Ah. I see what you're getting at. If you want to do that, it's quite acheivable without changing my original proposal: The IP address I publish in my SDP is the public address of my local outbound proxy for reception of SIP messages. When I send messages to the address in your SDP, I indicate that address in the request URI, but send it to my local outbound proxy. Yes, it takes some client configuration -- but so does any use of a local outbound proxy. /a From rsparks@dynamicsoft.com Wed May 2 16:26:07 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20001 for ; Wed, 2 May 2001 16:26:07 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA19316; Wed, 2 May 2001 16:29:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 16:26:06 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A792@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'adam.roach@ericsson.com'" , Robert Sparks , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 16:26:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 901 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: > Pie-in-the-sky answer: babelfish. Cool! > > > What you are suggesting > > is that a chat session be _only_ point to point, ala the use of RTP, > > and that in no circumstance would it involve a SIP proxy. I'm not > > comfortable making that strong a statement yet. > > Ah. I see what you're getting at. If you want to do that, it's quite > acheivable without changing my original proposal: The IP address I > publish in my SDP is the public address of my local outbound proxy > for reception of SIP messages. When I send messages to the address > in your SDP, I indicate that address in the request URI, but send it > to my local outbound proxy. Yes, it takes some client configuration -- > but so does any use of a local outbound proxy. Good - that sets the stage for the initial MESSAGE in the chat session - now do we kick in Route/Record-Route based on the first MESSAGE of the session? RjS From bcampbell@dynamicsoft.com Wed May 2 16:54:20 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20104 for ; Wed, 2 May 2001 16:54:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA19852; Wed, 2 May 2001 16:57:59 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 16:54:19 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30B42@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: Robert Sparks , "'adam.roach@ericsson.com'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 16:54:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1137 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: > > > Pie-in-the-sky answer: babelfish. > Cool! > > > > > What you are suggesting > > > is that a chat session be _only_ point to point, ala the > use of RTP, > > > and that in no circumstance would it involve a SIP proxy. I'm not > > > comfortable making that strong a statement yet. > > > > Ah. I see what you're getting at. If you want to do that, it's quite > > acheivable without changing my original proposal: The IP address I > > publish in my SDP is the public address of my local outbound proxy > > for reception of SIP messages. When I send messages to the address > > in your SDP, I indicate that address in the request URI, but send it > > to my local outbound proxy. Yes, it takes some client > configuration -- > > but so does any use of a local outbound proxy. > > Good - that sets the stage for the initial MESSAGE in the chat > session - now do we kick in Route/Record-Route based on the first > MESSAGE of the session? > Since we are sending over a SIP channel, it would seem the reasonable thing to do. Refresh my memory--would we honor Record-route for a series of "page" model messages on the same call leg? From sean.olson@ericsson.com Wed May 2 18:48:25 2001 Received: from imr2.ericy.com ([12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20438 for ; Wed, 2 May 2001 18:48:20 -0400 (EDT) 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 f42MmG818277 for ; Wed, 2 May 2001 17:48:16 -0500 (CDT) 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 f42MmGI04315 for ; Wed, 2 May 2001 17:48:16 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed May 02 17:48:14 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 17:48:14 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Robert Sparks'" , "'adam.roach@ericsson.com'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 17:48:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D359.F8612500" Content-Length: 5898 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: 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_01C0D359.F8612500 Content-Type: text/plain; charset="iso-8859-1" >> > How much of the call-leg identifier used by the chat session >> > itself do you signal with the INVITE? >> >> Good question. My inclination is to use exactly the same correlation >> information so that matching up of different messaging "sessions" >> is trivial. Can anyone think why this might be a bad idea? > >By same correlation information, you mean same to, from, and call-id, >counting on the INVITE arriving on a different transport than the >MESSAGEs (at least on different ports) so you don't get into CSeq >mismatch errors? At its best, this will make for great debugging pain. >What about the other end of the spectrum, where you pass the a whole >new call-leg tuple as part of the SDP, or at least a new Call-ID? > >RjS A few comments: First, I'm assuming that you want to use an INVITE for a chat session of more than one message. Using CSeq as part of the correlation is difficult to impossible depending on how you interpret correlation. Second, while we are using this INVITE session specifically to create a chat session, there is no reason not to consider this for a more general purpose application. You have created a nested SIP signalling session. There is no reason to limit that SIP signalling to just the MESSAGE request/response. With this in mind, it might make sense to use just the From:/To: with appropriate tags (ignore the Call-ID). Third, SDP allows multiple media streams. Are we going to allow (in the general case) multiple signalling streams? If so, Call-ID is definitely out. But there are more interesting questions raised by this possibility. Fourth, why do we need to do correlation based on the INVITE at all? We have the option to specify a different port on which to receive this MESSAGE stream. There is a certain elegance to piping it back into 5060 (or the same port that the INVITE was sent to/from) but this is not the only way. Finally, do you need to correlate it based on the INVITE/SDP at all? Is it important that you are able to distinguish MESSAGEs as belonging to different streams? (Even in the chat case) /sean ------_=_NextPart_001_01C0D359.F8612500 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] IM: A session or not

>> > How much of the call-leg identifier used by the chat session
>> > itself do you signal with the INVITE?
>>
>> Good question. My inclination is to use exactly the same correlation
>> information so that matching up of different messaging "sessions"
>> is trivial. Can anyone think why this might be a bad idea?
>
>By same correlation information, you mean same to, from, and call-id,
>counting on the INVITE arriving on a different transport than the
>MESSAGEs (at least on different ports) so you don't get into CSeq
>mismatch errors? At its best, this will make for great debugging pain.
>What about the other end of the spectrum, where you pass the a whole
>new call-leg tuple as part of the SDP, or at least a new Call-ID?
>
>RjS

A few comments:

First, I'm assuming that you want to use
an INVITE for a chat session of more than one message. Using
CSeq as part of the correlation is difficult to impossible
depending on how you interpret correlation.

Second, while we are using this INVITE session specifically
to create a chat session, there is no reason not to consider
this for a more general purpose application. You have created
a nested SIP signalling session. There is no reason to limit
that SIP signalling to just the MESSAGE request/response.
With this in mind, it might make sense to use just the From:/To:
with appropriate tags (ignore the Call-ID).

Third, SDP allows multiple media streams. Are we going to
allow (in the general case) multiple signalling streams?
If so, Call-ID is definitely out. But there are more interesting
questions raised by this possibility.

Fourth, why do we need to do correlation based on the INVITE at all?
We have the option to specify a different port on which to receive
this MESSAGE stream. There is a certain elegance to piping it back
into 5060 (or the same port that the INVITE was sent to/from) but
this is not the only way.

Finally, do you need to correlate it based on the INVITE/SDP at all?
Is it important that you are able to distinguish MESSAGEs as belonging
to different streams? (Even in the chat case)

/sean

------_=_NextPart_001_01C0D359.F8612500-- From sean.olson@ericsson.com Wed May 2 18:50:03 2001 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 SAA20466 for ; Wed, 2 May 2001 18:50:02 -0400 (EDT) Received: from mr7.exu.ericsson.se. (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f42Mo6829966 for ; Wed, 2 May 2001 17:50:06 -0500 (CDT) 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 f42Mo1K13199 for ; Wed, 2 May 2001 17:50:01 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 02 17:50:01 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 17:50:01 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Robert Sparks'" , "'adam.roach@ericsson.com'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Wed, 2 May 2001 17:50:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D35A.37C18280" Content-Length: 2120 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: 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_01C0D35A.37C18280 Content-Type: text/plain; charset="iso-8859-1" >Good - that sets the stage for the initial MESSAGE in the chat >session - now do we kick in Route/Record-Route based on the first >MESSAGE of the session? Does Route/Record-Route make sense in a MESSAGE? If you want to do Route:/Record-Route:, why bother with the enclosing INVITE? /sean > >RjS >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C0D35A.37C18280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] IM: A session or not

>Good - that sets the stage for the initial = MESSAGE in the chat
>session - now do we kick in Route/Record-Route = based on the first
>MESSAGE of the session?

Does Route/Record-Route make sense in a MESSAGE? If = you want
to do Route:/Record-Route:, why bother with the = enclosing INVITE?

/sean

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

------_=_NextPart_001_01C0D35A.37C18280-- From Vasilis.Polychronidis@Openwave.com Thu May 3 19:00:41 2001 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 TAA24220 for ; Thu, 3 May 2001 19:00:41 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010503230004.UCCG29533.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 3 May 2001 18:00:04 -0500 Received: from Openwave.com ([64.14.128.39]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010503230039.UUJH6281.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Thu, 3 May 2001 18:00:39 -0500 Message-ID: <3AF1E315.9259605C@Openwave.com> Date: Thu, 03 May 2001 16:00:38 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Ajay Chitturi'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] DNS SRV query example References: Content-Type: multipart/alternative; boundary="------------39BCDBE947DA369279137960" Content-Length: 5846 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: --------------39BCDBE947DA369279137960 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan, Please see my comments below: Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] > > Sent: Monday, April 30, 2001 6:48 PM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] DNS SRV query example > > > > > > Hi, > > > > In Section 6.3 of draft-ietf-simple-im-00, the example for the SRV > > query for a url im:user@host is shown as _im._sip.host > > > > Shouldn't this be _im._sip._transport.host (where transport > > is udp, tcp, > > tls, etc.) Here is the format of the SRV Resource Record (RR): _Service._Proto.Domain TTL Class SRV Priority Weight Port Target According to CPIM --> Service = im or pres Proto = tcp or udp or prim or sip or apex or http or ... Target = sip.openwave.com or presence.openwave.com or prim.openwave.com or apex.openwave.com or openwave.com or .... > > > The usage of SRV for this translation is still being debated within IMPP. If > SRV is used, It has been decided in IMPP wg to use SRV! The result of the SRV query will contain the SRV RR and may contain the Additional field with the IP address of the Target. If the Name Server does not contain the IP address of the Target a second DNS query will be performed on the Target. > it will not be exactly as specified in rfc2782. Why not? > One proposal > was to use a form along the lines of "_im._sip.domain", and then do a sip > srv query on the result. This is one way of doing SRV queries which is compliant with rfc2782. > This is still being hammered out on the impp list. Are you talking about the walk through that we need to work on? > > > -Jonathan R. > > --- > Jonathan D. Rosenberg 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 --------------39BCDBE947DA369279137960 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan,
Please see my comments below:

Jonathan Rosenberg wrote:

 

> -----Original Message-----
> From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com]
> Sent: Monday, April 30, 2001 6:48 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] DNS SRV query example
>
>
> Hi,
>
> In Section 6.3 of draft-ietf-simple-im-00, the example for the SRV
> query for a url im:user@host is shown as _im._sip.host
>
> Shouldn't this be _im._sip._transport.host (where transport
> is udp, tcp,
> tls, etc.)

Here is the format of the SRV Resource Record (RR):
 _Service._Proto.Domain TTL Class SRV Priority Weight Port Target

According to CPIM --> Service = im or pres
Proto = tcp or udp or prim or sip or apex or http or ...
Target = sip.openwave.com or presence.openwave.com or
prim.openwave.com or apex.openwave.com or openwave.com or ....

 

The usage of SRV for this translation is still being debated within IMPP. If
SRV is used,

It has been decided in IMPP wg to use SRV!
The result of the SRV query
will contain the SRV RR and may contain the Additional field with the IP address of the Target.
If the Name Server does not contain the IP address of the Target a second DNS query will
be performed on the Target.
it will not be exactly as specified in rfc2782.
Why not?
One proposal
was to use a form along the lines of "_im._sip.domain", and then do a sip
srv query on the result.
This is one way of doing SRV queries which is compliant with rfc2782.
This is still being hammered out on the impp list.
Are you talking about the walk through that we need to work on?
 

-Jonathan R.

---
Jonathan D. Rosenberg                       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

--------------39BCDBE947DA369279137960-- From Vasilis.Polychronidis@Openwave.com Thu May 3 19:03:38 2001 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 TAA24241 for ; Thu, 3 May 2001 19:03:38 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010503230301.UEBH29533.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 3 May 2001 18:03:01 -0500 Received: from Openwave.com ([64.14.128.39]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010503230336.UULZ6281.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Thu, 3 May 2001 18:03:36 -0500 Message-ID: <3AF1E3C7.5C7A9603@Openwave.com> Date: Thu, 03 May 2001 16:03:35 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: Robert Sparks , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] IM: A session or not References: <9BF66EBF6BEFD942915B4D4D45C051F30B3A@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3053 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: Hi Ben, I like your proposal makes a lot of sense. Regards, Vasilis Ben Campbell wrote: > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Tuesday, May 01, 2001 12:55 PM > > To: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] IM: A session or not > > > > > > Folks - we need to move this along so we can free our crucible > > for discussion on publishing and authentication. > > > > I propose that we move ahead and develop the text around > > > > *) session free "pages", very much like what we've already defined > > *) "chat" sessions consisting of MESSAGE requests bounded by > > an INVITE/BYE > > > > To address the discussions date: > > > > Is it sufficient for the MESSAGE requests in the chat session > > to follow the Route established by the INVITE/BYE bounding it? > > > > Proposal : > > Yes - > > In the normal case, proxies that don't truly need to be in the > > path of subsequent requests won't record route, so we should > > end up with a minimal path for these requests. > > > > Would sip services (proxy/redirect servers) need to be able to > > distinguish INVITEs for MESSAGE sessions from INVITES from other > > streaming media. > > > > Proposal : > > No - > > at least not any more than the services already need to be > > able to differentiate between different types of media streams. > > > > On reflection, (and feel free to hit me for not bringing this up in our > discussion earlier today), I think I have to object to the > not-routing-by-media-type provision. Right now, I have both a PC and a SIP > phone on my desk. They have separate IP addresses. My SIP phone does not > support messaging (yet) and my PC makes a lousy phone because of windows > media considerations. Therefore I would prefer to route message sessions and > voice sessions differently. > > I would still be able to do this by publishing a distinct URI for message > sessions and for voice sessions, but this is not very satisfying. I would > prefer to just tell everyone to use sip:bcampbell@dynamicsoft.com for either > media. This is not an IM specific problem, as I am also likely to wish video > sessions to sip:bcampbell@dynamicsoft.com to go to a different device than > voice sessions. > > On the otherhand perhaps, according to CPIM discussions, my published URL > for messaging should instead be the abstract im:bcampbell@dynamicsoft.com, > and do an SRV lookup or some other DNS magic to convert that to an concrete > sip URL. I suppose one could set things up where that actually resolved to > sip:bcampbell@im.dynamicsoft.com, which could be routed differently to > sip:bcampbell@dynamicsoft.com. This is less annoying than the first > situation, as I will typically tell my friends I am > bcampbell@dynamicsoft.com and let them figure out what scheme to use based > on the application (mailto:, sip:, pres:, im:, etc.) > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From Vasilis.Polychronidis@Openwave.com Thu May 3 19:09:56 2001 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 TAA24283 for ; Thu, 3 May 2001 19:09:56 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010503230919.ULCF29533.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 3 May 2001 18:09:19 -0500 Received: from Openwave.com ([64.14.128.39]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010503230954.UUSD6281.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Thu, 3 May 2001 18:09:54 -0500 Message-ID: <3AF1E541.9E8192E9@Openwave.com> Date: Thu, 03 May 2001 16:09:53 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] URI Conversion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1569 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: Hi Jonathan, Please see my comments below: Jonathan Rosenberg wrote: > > -----Original Message----- > From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] > Sent: Tuesday, May 01, 2001 1:40 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] URI Conversion > > >Hi, > > > >Does anyone have any other thoughts of a working "solution" for URI > conversion, i.e. SIP > >URL from/to Presence/IM URI? > > > > I suspect you really only need to convert in one direction - presence/IM URL > to SIP URL. When addressing a SIP->CPIM gateway with a SIP request, you > shouldn't convert the pres URL to a SIP URL to begin with. How to support > that using DNS queries is a good question. > > Presence URL to SIP URL conversion is trivial, and would be nothing more > than replacing the scheme with sip. > > Alot of this depends on the DNS mechanisms used; if naptr is specified, It was decided in the last IMPP wg meeting to use SRV instead of NAPRT. > then > the naptr record would actually specify how the conversion is done. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 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 jdrosen@dynamicsoft.com Tue May 8 12:30:06 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05055 for ; Tue, 8 May 2001 12:30:06 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA21937; Tue, 8 May 2001 12:33:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 May 2001 12:30:00 -0400 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , Robert Sparks , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM: A session or not Date: Tue, 8 May 2001 12:30:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 6244 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: > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Wednesday, May 02, 2001 3:23 PM > To: 'Robert Sparks'; adam.roach@ericsson.com; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] IM: A session or not > > > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > ... > > > Firewalls break SIP-IM messages as media; for SIP-IM sessions to > > > work through them, we expect them to fix them mess they've > > > created: open holes or modify the SDP. > > > > > > Remember, our job is **NOT** trying to figure out ways to > > > circumvent measures put in place by firewall administrators. > > > If you're concerned about getting the messages through a > > > firewall regardless of local policy, we should really be putting > > > together a draft on running SIP IM sessions over HTTP (a la > > RFC3093). > > > > And you missed my point altogether here. I wasn't talking about > > circumventing policy. I was talking about being able to actually > > _comply_ with it if I wanted to. Firewall like behavior is the > > cheap and easy answer for why one might want SIP traffic to be > > forced to go through a proxy - there are others (though I can't > > at the moment come up with a truly compelling application for > > any of them with respect to a chat session). > > Pie-in-the-sky answer: babelfish. > > > What you are suggesting > > is that a chat session be _only_ point to point, ala the use of RTP, > > and that in no circumstance would it involve a SIP proxy. I'm not > > comfortable making that strong a statement yet. > > Ah. I see what you're getting at. If you want to do that, it's quite > acheivable without changing my original proposal: The IP address I > publish in my SDP is the public address of my local outbound proxy > for reception of SIP messages. When I send messages to the address > in your SDP, I indicate that address in the request URI, but send it > to my local outbound proxy. Yes, it takes some client configuration -- > but so does any use of a local outbound proxy. Actually, the best thing to put in the SDP is a SIP URL. That can encapsulate everything we might want to convey, and unifies the various transport treatments we have been talking about. First off, to answer Robert's original questions, I support the notion of BOTH a page AND a chat conversational model. I think the page should operate just like OPTIONS, and not have any session level semantics. Like all other sessions, an IM based chat session should be wrapped in INVITE/BYE, as I proposed at IETF 50. The chat stream is signaled in SDP. A chat session is nothing more than a series of pages, which share a common Call-iD (to indicate that pages are part of the same stream, similar to the usage of the port number in RTP), and a common CSeq numbering (to provide sequencing, like the SN in RTP), both of which have unidirectional semantics only. What I mean by this is that the UAC, in its invite, indicates the call-id it would like to see for incoming pages for this stream, and the UAS, in the 200 OK, indicate the Call-ID it would like to see. CSeq provides ordering as always. I see no need for the message stream call-id to be the same as the call-id for the SIP INVITE/BYE wrapping the session. In fact, I can think of some compelling third party call control applications where they can't be the same. I think this is in line with what Sean was arguing for. I think that "normal" behavior will be for the URL in the SDP to basically be a Contact URL, enabling direct point to point messaging: m=message 5060 sip sip:172.1.2.3 here, the call-id is not provided, so presumably the IP address or port provide the stream identification. I would expect a more typical scenario to be: m=message 5060 sip sip:172.1.2.3?Call-Id=7ahs082@172.1.2.3 so that a Call-ID is provided. For a callee behind a firewall, it can instruct the caller to attempt to use a proxy network to deliver the message stream: m=message 5060 sip sip:jdrosen@dynamicsoft.com?Call-ID=28372@1.2.3.4 now, this causes the caller to send requests to the proxy for dynamicsoft.com. These requests appear as, and are treated exactly as pages. There is no record-routing, since pages have no session semantics, and therefore, record-routing doesn't make sense. I don't want to define two separate proxy behaviors for MESSAGE - one for pages, and the other for chat streams that are routed through proxies. This will be a huge pain. A smarter callee might realize they are behind a firewall, but can be reached through a single proxy, which is the only one that record-routed the initial INVITE: m=message 5060 sip sip:jdrosen@dynamicsoft.com?Route=sip:172.1.2.3&Call-ID=7ahs92@172.1.2.3 In another case, the callee might realize that they are natted. In that case, they make use of a third party "proxy" provider. The UA registers, using TCP and the contact cookie, with this proxy service. This allows them to receive messages sent to sip:user123@proxyservice.com: m=message 5060 sip sip:user123@proxyservice.com?Call-ID=123@10.0.1.1 Now, it is important to note that in this proposal, the Call-iD is *not* the same in both directions. Just like the RTP port number is not the same, the Call-ID, which is its analogy, is a local ID used for correlating pages that are received. This allows us to unify the treatment of pages and chat streams, which is an important property. By making the behavior mirror that of RTP, it also means we can easily apply concepts like third party call control and multiparty conferencing. Usage of the SIP URL in the SDP allows us to handle pretty much any kind of transport or addressing scneario. The transport parameter can specify TLS, TCP, UDP, or whatever. We can specifies Call-ID's, Route's or whatever we like. -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 From jdrosen@dynamicsoft.com Wed May 9 01:04:35 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06956 for ; Wed, 9 May 2001 01:04:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA00490; Wed, 9 May 2001 01:08:16 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 May 2001 01:04:32 -0400 Message-ID: From: Jonathan Rosenberg To: "'Vasilis Polychronidis'" , Jonathan Rosenberg Cc: "'Ajay Chitturi'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] DNS SRV query example Date: Wed, 9 May 2001 01:04:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1824 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: -----Original Message----- From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com] Sent: Thursday, May 03, 2001 7:01 PM To: Jonathan Rosenberg Cc: 'Ajay Chitturi'; simple@mailman.dynamicsoft.com Subject: Re: [Simple] DNS SRV query example > >Hi Jonathan, >Please see my comments below: >Jonathan Rosenberg wrote: > >> -----Original Message----- >> From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] >> Sent: Monday, April 30, 2001 6:48 PM >> To: simple@mailman.dynamicsoft.com >> Subject: [Simple] DNS SRV query example >> >> >> Hi, >> >>The usage of SRV for this translation is still being debated within IMPP. If >>SRV is used, > >It has been decided in IMPP wg to use SRV! There was a preference, for simplicities sake, although it wasn't clear it really works from the list discussions that followed IETF 50. Indeed, based on Christian's most recent note on impp, it looks like there was significant pushback from the DNS experts, who feel that NAPTR is more correct. >>The result of the SRV query >>will contain the SRV RR and may contain the Additional field with the IP address of the >>Target. >>If the Name Server does not contain the IP address of the Target a second DNS query will >>be performed on the Target. >>it will not be exactly as specified in rfc2782. >Why not? rfc2782 defines the protocol field as a transport protocol - tcp, udp. The proposed approach does not use it that way. -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 From Vasilis.Polychronidis@Openwave.com Wed May 9 02:13:20 2001 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 CAA07156 for ; Wed, 9 May 2001 02:13:20 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010509061241.OYQG19206.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Wed, 9 May 2001 01:12:41 -0500 Received: from Openwave.com ([172.181.166.59]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010509061314.NXS6281.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Wed, 9 May 2001 01:13:14 -0500 Message-ID: <3AF8DFED.8B859267@Openwave.com> Date: Tue, 08 May 2001 23:13:02 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Ajay Chitturi'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] DNS SRV query example References: Content-Type: multipart/alternative; boundary="------------ACD978A650F88AD5D6AA3126" Content-Length: 10151 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: --------------ACD978A650F88AD5D6AA3126 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan, Please see my comments below: Regards, Vasilis Polychronidis Jonathan Rosenberg wrote: > > -----Original Message----- > From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com] > Sent: Thursday, May 03, 2001 7:01 PM > To: Jonathan Rosenberg > Cc: 'Ajay Chitturi'; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] DNS SRV query example > > > > >Hi Jonathan, > >Please see my comments below: > >Jonathan Rosenberg wrote: > > > >> -----Original Message----- > >> From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] > >> Sent: Monday, April 30, 2001 6:48 PM > >> To: simple@mailman.dynamicsoft.com > >> Subject: [Simple] DNS SRV query example > >> > >> > >> Hi, > >> > >>The usage of SRV for this translation is still being debated within IMPP. > If > >>SRV is used, > > > >It has been decided in IMPP wg to use SRV! > > There was a preference, for simplicities sake, although it wasn't clear it > really works from the list discussions that followed IETF 50. Indeed, based > on Christian's most recent note on impp, it looks like there was significant > pushback from the DNS experts, who feel that NAPTR is more correct. I agree with you I was just trying to remind you of the resolution that was agreed in the 50th IETF. Here is a direct quote from the meeting minutes (IETF 50): Issue: Address resolution in multiprotocol context Proposal: SRV at edge? NAPTR at edge? How would NAPTR records be used? Weight/Priority Flags to control the process Services: end point differentiation Regexp: end point identifier "factory" Replacement: (a DNS shortcut if regex is just domainname) Additional info section contains the SRV and A records Michael Mealling presents a brief overview of how NAPTR might be applied to the situation. Some concerns from the floor that NAPTR are expressive and potentially quite complex. The counter argument is that the CPIM application would define a very restrictive application of their use (as does ENUM). Now that NAPTR was explained and discussed, return to the question, do we want to go with some variant of SRV or NAPTR? General feeling of the room is that the potential of NAPTR doesn't buy enough over SRV, and the concern over additional complexity remains. Resolution: Use SRV records for first-round lookups: _._im.domain. (e.g. _simple._im.domain.) Christian will make proposal for revised CPIM text > > > >>The result of the SRV query > >>will contain the SRV RR and may contain the Additional field with the IP > address of the > >>Target. > >>If the Name Server does not contain the IP address of the Target a second > DNS query will > >>be performed on the Target. > >>it will not be exactly as specified in rfc2782. > > >Why not? > > rfc2782 defines the protocol field as a transport protocol - tcp, udp. The > proposed approach does not use it that way. Well the proto field can be anything you want. The following is a direct quote from rfc2782: Proto The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive. > > > > -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 --------------ACD978A650F88AD5D6AA3126 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan,
Please see my comments below:

Regards,

Vasilis Polychronidis

Jonathan Rosenberg wrote:

 
-----Original Message-----
From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com]
Sent: Thursday, May 03, 2001 7:01 PM
To: Jonathan Rosenberg
Cc: 'Ajay Chitturi'; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] DNS SRV query example

>
>Hi Jonathan,
>Please see my comments below:
>Jonathan Rosenberg wrote:
>
>> -----Original Message-----
>> From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com]
>> Sent: Monday, April 30, 2001 6:48 PM
>> To: simple@mailman.dynamicsoft.com
>> Subject: [Simple] DNS SRV query example
>>
>>
>> Hi,
>>
>>The usage of SRV for this translation is still being debated within IMPP.
If
>>SRV is used,
>
>It has been decided in IMPP wg to use SRV!

There was a preference, for simplicities sake, although it wasn't clear it
really works from the list discussions that followed IETF 50. Indeed, based
on Christian's most recent note on impp, it looks like there was significant
pushback from the DNS experts, who feel that NAPTR is more correct.

I agree with you I was just trying to remind you of the resolution that was agreed in the 50th IETF.
Here is a direct quote from the meeting minutes (IETF 50):

    Issue: Address resolution in multiprotocol context

    Proposal:
            SRV at edge?
            NAPTR at edge?

    How would NAPTR records be used?
        Weight/Priority
        Flags to control the process
        Services: end point differentiation
        Regexp: end point identifier "factory"
        Replacement: (a DNS shortcut if regex is just domainname)

        Additional info section contains the SRV and A records

    Michael Mealling presents a brief overview of how NAPTR might be applied to the situation.  Some concerns from the floor that NAPTR are
    expressive and potentially quite complex.  The counter argument is that the CPIM application would define a very restrictive application of their use
    (as does ENUM).

    Now that NAPTR was explained and discussed, return to the question, do we want to go with some variant of SRV or NAPTR?

    General feeling of the room is that the potential of NAPTR doesn't buy enough over SRV, and the concern over additional complexity remains.

    Resolution: Use SRV records for first-round lookups:
                _<proto>._im.domain. (e.g. _simple._im.domain.)

    Christian will make proposal for revised CPIM text

 

>>The result of the SRV query
>>will contain the SRV RR and may contain the Additional field with the IP
address of the
>>Target.
>>If the Name Server does not contain the IP address of the Target a second
DNS query will
>>be performed on the Target.
>>it will not be exactly as specified in rfc2782.

>Why not?

rfc2782 defines the protocol field as a transport protocol - tcp, udp. The
proposed approach does not use it that way.

Well the proto field can be anything you want.
The following is a direct quote from rfc2782:
   Proto
        The symbolic name of the desired protocol, with an underscore
        (_) prepended to prevent collisions with DNS labels that occur
        in nature.  _TCP and _UDP are at present the most useful values
        for this field, though any name defined by Assigned Numbers or
        locally may be used (as for Service).  The Proto is case
        insensitive.
 
 

-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

--------------ACD978A650F88AD5D6AA3126-- From HUITEMA@windows.microsoft.com Wed May 9 23:48:16 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id XAA10563 for ; Wed, 9 May 2001 23:48:15 -0400 (EDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 May 2001 08:26:26 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 9 May 2001 08:25:54 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 9 May 2001 08:25:54 -0700 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(5.0.2195.1600); Wed, 9 May 2001 08:25:31 -0700 content-class: urn:content-classes:message Subject: RE: [Simple] DNS SRV query example MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 Date: Wed, 9 May 2001 08:25:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] DNS SRV query example Thread-Index: AcDYUZ8JpfztPo+fS2y7qRs1sPdquQASieGQ From: "Christian Huitema" To: "Vasilis Polychronidis" , "Jonathan Rosenberg" Cc: "Ajay Chitturi" , X-OriginalArrivalTime: 09 May 2001 15:25:31.0487 (UTC) FILETIME=[48D636F0:01C0D89C] Content-Length: 4492 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id XAA10563 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: This discussion really belongs in the IMPP group, not SIMPLE. As far as Simple is concerned, we could very easily just use a basic SRV record scheme, e.g. _sip._udp.example.com SRV 1 1 5060 sip.example.com Indeed, there may be question of which record we use, i.e. do we look for "sip" or do we look for "simple", and also a question of which transport protocol we prefer, e.g. udp, tcp, tls or ssl. -- Christian Huitema -----Original Message----- From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com] Sent: Tuesday, May 08, 2001 11:13 PM To: Jonathan Rosenberg Cc: Ajay Chitturi; simple@mailman.dynamicsoft.com Subject: Re: [Simple] DNS SRV query example Hi Jonathan, Please see my comments below: Regards, Vasilis Polychronidis Jonathan Rosenberg wrote:   -----Original Message----- From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com] Sent: Thursday, May 03, 2001 7:01 PM To: Jonathan Rosenberg Cc: 'Ajay Chitturi'; simple@mailman.dynamicsoft.com Subject: Re: [Simple] DNS SRV query example > >Hi Jonathan, >Please see my comments below: >Jonathan Rosenberg wrote: > >> -----Original Message----- >> From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] >> Sent: Monday, April 30, 2001 6:48 PM >> To: simple@mailman.dynamicsoft.com >> Subject: [Simple] DNS SRV query example >> >> >> Hi, >> >>The usage of SRV for this translation is still being debated within IMPP. If >>SRV is used, > >It has been decided in IMPP wg to use SRV! There was a preference, for simplicities sake, although it wasn't clear it really works from the list discussions that followed IETF 50. Indeed, based on Christian's most recent note on impp, it looks like there was significant pushback from the DNS experts, who feel that NAPTR is more correct. I agree with you I was just trying to remind you of the resolution that was agreed in the 50th IETF. Here is a direct quote from the meeting minutes (IETF 50):     Issue: Address resolution in multiprotocol context     Proposal:             SRV at edge?             NAPTR at edge?     How would NAPTR records be used?         Weight/Priority         Flags to control the process         Services: end point differentiation         Regexp: end point identifier "factory"         Replacement: (a DNS shortcut if regex is just domainname)         Additional info section contains the SRV and A records     Michael Mealling presents a brief overview of how NAPTR might be applied to the situation.  Some concerns from the floor that NAPTR are     expressive and potentially quite complex.  The counter argument is that the CPIM application would define a very restrictive application of their use     (as does ENUM).     Now that NAPTR was explained and discussed, return to the question, do we want to go with some variant of SRV or NAPTR?     General feeling of the room is that the potential of NAPTR doesn't buy enough over SRV, and the concern over additional complexity remains.     Resolution: Use SRV records for first-round lookups:                 _._im.domain. (e.g. _simple._im.domain.)     Christian will make proposal for revised CPIM text   >>The result of the SRV query >>will contain the SRV RR and may contain the Additional field with the IP address of the >>Target. >>If the Name Server does not contain the IP address of the Target a second DNS query will >>be performed on the Target. >>it will not be exactly as specified in rfc2782. >Why not? rfc2782 defines the protocol field as a transport protocol - tcp, udp. The proposed approach does not use it that way. Well the proto field can be anything you want. The following is a direct quote from rfc2782:    Proto         The symbolic name of the desired protocol, with an underscore         (_) prepended to prevent collisions with DNS labels that occur         in nature.  _TCP and _UDP are at present the most useful values         for this field, though any name defined by Assigned Numbers or         locally may be used (as for Service).  The Proto is case         insensitive.     -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 From rsparks@dynamicsoft.com Thu May 10 11:08:45 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12289 for ; Thu, 10 May 2001 11:08:45 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA24847; Thu, 10 May 2001 11:12:29 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 May 2001 11:08:45 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A7BF@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , simple@mailman.dynamicsoft.com, "'sean.olson@ericsson.com'" Subject: RE: [Simple] IM: A session or not Date: Thu, 10 May 2001 11:08:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2351 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: > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, May 08, 2001 11:30 AM > The chat stream is signaled in SDP. A > chat session is > nothing more than a series of pages, which share a common Call-iD (to > indicate that pages are part of the same stream, similar to > the usage of the > port number in RTP), and a common CSeq numbering (to provide > sequencing, > like the SN in RTP), both of which have unidirectional > semantics only. What > I mean by this is that the UAC, in its invite, indicates the > call-id it > would like to see for incoming pages for this stream, and the > UAS, in the > 200 OK, indicate the Call-ID it would like to see. CSeq > provides ordering as > always. I see no need for the message stream call-id to be > the same as the > call-id for the SIP INVITE/BYE wrapping the session. In fact, > I can think of > some compelling third party call control applications where > they can't be > the same. I think this is in line with what Sean was arguing for. This answers "How much of the call-leg identifier used by the chat session itself do you signal with the INVITE" very nicely. Sean - at one point you were arguing >>From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] >>Sent: Wednesday, May 02, 2001 5:48 PM >> >>Third, SDP allows multiple media streams. Are we going to >>allow (in the general case) multiple signalling streams? >>If so, Call-ID is definitely out. But there are more interesting >>questions raised by this possibility. Jonathan is proposing using Call-ID to demux each of those streams. Does the problem you were seeing still apply? > There is no record-routing, since pages have no session semantics, and > therefore, record-routing doesn't make sense. I don't want to > define two > separate proxy behaviors for MESSAGE - one for pages, and the > other for chat > streams that are routed through proxies. This will be a huge pain. So, we assume that if the first message in a stream can get to its destination any subsequent will as well, and don't care if it takes the same path each time (beyond what we know before the first message is sent and include as preloaded Route headers in the contact SIP URL in the SDP). If the conversation forks in one direction, it will _stay_ forked through the whole conversation. RjS From adam.roach@ericsson.com Thu May 10 11:22:49 2001 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 LAA12355 for ; Thu, 10 May 2001 11:22:49 -0400 (EDT) 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 f4AFMk829933; Thu, 10 May 2001 10:22:46 -0500 (CDT) 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 f4AFMkQ24028; Thu, 10 May 2001 10:22:46 -0500 (CDT) Received: from eusadam (pc050163.exu.ericsson.se [138.85.50.163]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id KAA10073; Thu, 10 May 2001 10:22:45 -0500 (CDT) Reply-To: To: "'Robert Sparks'" , "Jonathan Rosenberg" , , "Sean Olson (EUS)" <> Subject: RE: [Simple] IM: A session or not Date: Thu, 10 May 2001 10:22:44 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251791@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: <9BF66EBF6BEFD942915B4D4D45C051F314A7BF@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 557 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: > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > So, we assume that if the first message in a stream can get to > its destination any subsequent will as well, and don't care if > it takes the same path each time (beyond what we know before the > first message is sent and include as preloaded Route headers in > the contact SIP URL in the SDP). If the conversation forks in > one direction, it will _stay_ forked through the whole conversation. I'm happy with this solution (including the use of URIs in SDP). /a From let'sgo@yahoo.com Fri May 11 15:49:07 2001 Received: from scopsr.gov.cnmail.scopsr.gov.cn ([202.106.127.15]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16705 for ; Fri, 11 May 2001 15:48:56 -0400 (EDT) From: let'sgo@yahoo.com Received: from yahoo.com by scopsr.gov.cnmail.scopsr.gov.cn (8.8.8+Sun/SMI-SVR4) id UAA28458; Wed, 9 May 2001 20:18:21 +0800 (CST) To: simple@mailman.dynamicsoft.com Date: Wed, 9 May 2001 08:23:45 Message-Id: <369.750152.388433@yahoo.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Length: 19079 Subject: [Simple] Gratis 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: WORD PUZZLE LOVERS—

~ WORD PUZZLE LOVERS ~

 

Do you like double acrostics?

We Want To Send You, a FREE Sample?

 

  • Do you like them big with lots of meat in them?

Our puzzles average well over 250 letters. Most published puzzles have around 200.

 

  • Do you like them really tough and challenging?

We dig deep for our clues and once in a while we stick in a real off-the-wall doozer

 
If you answer YES, we have the acrostics for you!

 

 

* We offer a subscription service. *

Our Subscribers receive five new mind-benders every month

and they are delivered right into their mailbox.

 
Would You Like us to Send You, a FREE Sample?

Yes, I want to learn more about your Puzzles.

Please click below

I am not interested; take me off your list.

Please click below
       

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Our puzzles, [word puzzles for the connoisseur] start out with a literary quote. We use all the letters in the quote and create clues. The first letters of the clues spell out the author’s name and the title of the source of the quote. The letters of the clue words are numbered and correspond to squares in the accompanying grid. Filling in the grid reveals the quotation.

Sound complicated?

Well maybe a little, but that's where the solving fun comes in.

 

 

  

Yes, I want to learn more about your Puzzles and I want to receive a FREE sample.

Please click below

 
 

Please include your Name and US Mailing Address including Zip Code.

Because the Internet occasionally distorts graphics, samples are sent only by US mail.

  

 

I am not interested; take me off your list.

Please click below

  
 

 

              

WORD PUZZLE LOVERS—

~ WORD PUZZLE LOVERS ~

 

Do you like double acrostics?

We Want To Send You, a FREE Sample?

 

  • Do you like them big with lots of meat in them?

Our puzzles average well over 250 letters. Most published puzzles have around 200.

 

  • Do you like them really tough and challenging?

We dig deep for our clues and once in a while we stick in a real off-the-wall doozer

 
If you answer YES, we have the acrostics for you!

 

 

* We offer a subscription service. *

Our Subscribers receive five new mind-benders every month

and they are delivered right into their mailbox.

 
Would You Like us to Send You, a FREE Sample?

Yes, I want to learn more about your Puzzles.

Please click below

I am not interested; take me off your list.

Please click below
       

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Our puzzles, [word puzzles for the connoisseur] start out with a literary quote. We use all the letters in the quote and create clues. The first letters of the clues spell out the author’s name and the title of the source of the quote. The letters of the clue words are numbered and correspond to squares in the accompanying grid. Filling in the grid reveals the quotation.

Sound complicated?

Well maybe a little, but that's where the solving fun comes in.

 

 

  

Yes, I want to learn more about your Puzzles and I want to receive a FREE sample.

Please click below

 
 

Please include your Name and US Mailing Address including Zip Code.

Because the Internet occasionally distorts graphics, samples are sent only by US mail.

  

 

I am not interested; take me off your list.

Please click below

  
 

 

              

From snptracking2@yahoo.com Fri May 11 18:37:58 2001 Received: from mail.sisna.com (mail.sisna.com [216.126.204.104]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17152 for ; Fri, 11 May 2001 18:37:57 -0400 (EDT) From: snptracking2@yahoo.com Received: from pacbell [65.160.180.156] by mail.sisna.com (SMTPD32-6.05) id A88969C0024A; Fri, 11 May 2001 16:32:41 -0600 To: MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Message-Id: <200105111632593.SM00391@pacbell> Date: Fri, 11 May 2001 16:32:59 -0600 Content-Length: 6297 Subject: [Simple] Manuf. production/contrl software, $1,495.00 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: (ES511)Job Master, a complete, user friendly Windows based software package, can manage and control your operation from sales quote to shipment. For one week only, Job Master, normally $2,495.00, is on sale for a total price of $1,495.00. In order for you to receive this $1,000.00 savings we must have your order by May 18. Job Master is designed specifically for small to medium sized manufacturers, and costs many thousands of dollars less than any other even remotely comparable software package. Following is a list of features. If you have any questions, would like to discuss the package further, or if you would like to obtain our Web site address for a total walk through of the program, please call me directly at (661) 286-0041 (please do not E Mail me back. I may not get your message if you simply hit "Reply" and respond to this message via return E Mail). By way of background, we are a software company, which for some years has specialized in the development of custom software, primarily for small to medium sized manufacturers. Job Master is a distillation of over a million and a half dollars of software we have developed to control and manage the production of our manufacturing clients. Job Master contains the following features: 1. QUOTATION MODULE. In this module, quotes are developed, modified, and produced for sending to your client. A history is kept of all quotes for future reference, or modification for other clients. All quotations and revisions are "auto numbered," including versions. The quotes section allows for the entry of parts/processes, and costing of each, including materials, labor, markup, and taxes. Inventory status can be accessed from this section for reference. 2. SALES ORDER. Once a quotation is accepted, the final quotation information can be transformed into a Sales Order for your client's signature on a "point and click" basis. The Sales Order can be modified and re issued if necessary. A history if kept of all Sales Orders for future reference, or modification for other clients. All sales orders and revisions are "auto numbered," including versions. Inventory status can be accessed from this section for reference. 3. CUSTOMER LETTERS can be created from the Quotation and Sales Order sections. 4. SHOP TRAVELER/WORK ORDER. Once a Sales Order is accepted, the sales order information can be transformed into a shop traveler/work order on a "point and click" basis. Each item on the Sales Order becomes a shop traveler/work order, with each step of production of the item then listed on the traveler/work order. Each such traveler/work order is tied back into the Sales Order. The shop traveler/work order allows for the entry of line items, and notes on each line item. The shop traveler/work order contains a "notes" section. The Shop traveler/work order allows for the storing or attachment of drawings to the traveler/work order. The shop traveler/work order also contains a "drop down," from which standard processes can be selected for inclusion on the shop traveler/work order. The shop traveler/work order numbers progress in order of production sequence, and re numbers them if new steps are added. The shop traveler/work order allows for change orders or revisions, and numbers changes in sequence of t 5. INVENTORY. The application includes an inventory section, which allows operations to check materials inventory in and out. The inventory section allows for the comparison of inventory received against a P.O., and produces an "overage/underage" report of inventory received as compared against the P.O. The inventory section allows for the setting of minimum (re-order now!) and maximum inventory amounts, and produces reports showing what inventory needs to be ordered, as well as inventory that is at or above the maximum set to have in house. The inventory section also tracks "partially shipped" orders, which are tied in to the shipping function. This section shows how much completed product under a particular order has been actually shipped to a client, and how much remains to be shipped. The balance is adjusted as shipments are made. 6. REQUEST FOR PURCHASE. The application allows operators to produce a Request For Purchase for accounting for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item. 7. REQUEST FOR BID. The application allows operators to produce a Request For Bid for accounting to send to Vendors for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item to which Requests For Bid can be sent. 8. INVOICE. The application produces an invoice/invoice detail for all completed items ready to be billed/shipped to clients. 9. PRODUCTION OUTPUT STATUS. The application produces a date range selectable report on how much product, and the value of the product, which was completed during a selected date range. The application also produces a report on how many orders, and the value of those orders, which remain to be completed during a selected date range. 10. The application produces SHIPPING DOCUMENTS as per selected shippers, and produces a PACKING SLIP. 11. The application has a "FIND" FUNCTION in selected sections, allowing for searches by customer name, work order number, etc. 12. The application has "AUTO FILL;" i.e., when an operator starts to type in a name, number, etc. all related information auto fills after the first few letters or numbers are typed in. Job Master is currently being sold in the marketplace for $2,495.00 per package. However, if we receive your order by Friday, May 18, your total price will be $1,495.00 Again, if you have any questions at all, or would like to place your order, please call me on my direct line, (661) 286-0041. Thank you! Wayne D. McFarland Application Sales, Inc. ---------------------------------------------------------------------- You have received this newsletter because you either signed up or showed interest in receiving updates of our tracking software in the past through publications and other newsletters. If you want to unsubscribe from this newsletter, please send a reply email with "REMOVE" in the subject line. From jdrosen@dynamicsoft.com Sat May 12 02:14:20 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18457 for ; Sat, 12 May 2001 02:14:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA17975; Sat, 12 May 2001 02:18:05 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sat, 12 May 2001 02:14:19 -0400 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'simple@mailman.dynamicsoft.com'" , "'sean.olson@ericsson.com'" Subject: RE: [Simple] IM: A session or not Date: Sat, 12 May 2001 02:14:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1849 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: > -----Original Message----- > From: Robert Sparks > Sent: Thursday, May 10, 2001 11:09 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com; > 'sean.olson@ericsson.com' > Subject: RE: [Simple] IM: A session or not > > > > There is no record-routing, since pages have no session > semantics, and > > therefore, record-routing doesn't make sense. I don't want to > > define two > > separate proxy behaviors for MESSAGE - one for pages, and the > > other for chat > > streams that are routed through proxies. This will be a huge pain. > > So, we assume that if the first message in a stream can get to > its destination any subsequent will as well, and don't care if > it takes the same path each time (beyond what we know before the > first message is sent and include as preloaded Route headers in > the contact SIP URL in the SDP). There is room for some flexibility to deal with cases where, for some reason, the proposed route doesn't work. One can imagine that if the sender never gets a response to the MESSAGE, they instead attempt to send it to the same URI as the original INVITE was sent to. Or, perhaps they use a preloaded Route which is the same the INVITE is taking. All of these are local choices to handle error conditions, and I don't think need to be standardized. If the conversation forks in > one direction, it will _stay_ forked through the whole conversation. By conversation, are you referring to the sip call, or the message "stream"? -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 From rsparks@dynamicsoft.com Sun May 13 02:28:22 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22122 for ; Sun, 13 May 2001 02:28:22 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA20058; Sun, 13 May 2001 02:32:07 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 13 May 2001 02:28:21 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A7D3@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" , "'sean.olson@ericsson.com'" Subject: RE: [Simple] IM: A session or not Date: Sun, 13 May 2001 02:28:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2273 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: >-----Original Message----- >From: Jonathan Rosenberg >> -----Original Message----- >> From: Robert Sparks >> Sent: Thursday, May 10, 2001 11:09 AM >> To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com; >> 'sean.olson@ericsson.com' >> Subject: RE: [Simple] IM: A session or not >> >> >> > There is no record-routing, since pages have no session >> semantics, and >> > therefore, record-routing doesn't make sense. I don't want to >> > define two >> > separate proxy behaviors for MESSAGE - one for pages, and the >> > other for chat >> > streams that are routed through proxies. This will be a huge pain. >> >> So, we assume that if the first message in a stream can get to >> its destination any subsequent will as well, and don't care if >> it takes the same path each time (beyond what we know before the >> first message is sent and include as preloaded Route headers in >> the contact SIP URL in the SDP). > >There is room for some flexibility to deal with >cases where, for some reason, the proposed >route doesn't work. One can imagine that if >the sender never gets a response to the >MESSAGE, they instead attempt to send it to >the same URI as the original INVITE was sent to. >Or, perhaps they use a preloaded Route which is >the same the INVITE is taking. All of these are >local choices to handle error conditions, and >I don't think need to be standardized. > > >> If the conversation forks in >> one direction, it will _stay_ forked through the whole conversation. > >By conversation, are you referring to the sip call, or the message "stream"? The stream of MESSAGE requests (the "chat" conversation). Since we do not want to make any distinction between a page MESSAGE and a chat MESSAGE, if for some reason the stream hits a proxy that forks the chat MESSAGEs, it will fork every one. This is an unlikely scenario - in the best of worlds, we've signaled direct peer-peer delivery of chat MESSAGEs using the SDP in the INVITE. However, if we've been forced to use an outbound proxy, or have introduced a proxy through preloaded routes, as mentioned above, there's a chance that something along the path will fork the chat MESSAGEs. I'm not claiming this is a problem. I just wanted to make sure everyone understood the possibility existed. RjS From jdrosen@dynamicsoft.com Sun May 13 23:42:18 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25438 for ; Sun, 13 May 2001 23:42:18 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA01950; Sun, 13 May 2001 23:46:03 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 13 May 2001 23:42:17 -0400 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'simple@mailman.dynamicsoft.com'" , "'sean.olson@ericsson.com'" Subject: RE: [Simple] IM: A session or not Date: Sun, 13 May 2001 23:42:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2365 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: > -----Original Message----- > From: Robert Sparks > Sent: Sunday, May 13, 2001 2:28 AM > To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com'; > 'sean.olson@ericsson.com' > Subject: RE: [Simple] IM: A session or not > > > > > >> If the conversation forks in > >> one direction, it will _stay_ forked through the whole > conversation. > > > >By conversation, are you referring to the sip call, or the > message "stream"? > > The stream of MESSAGE requests (the "chat" conversation). > Since we do not > want to make any distinction between a page MESSAGE and a > chat MESSAGE, if > for some reason the stream hits a proxy that forks the chat > MESSAGEs, it > will fork every one. > > This is an unlikely scenario - in the best of worlds, we've > signaled direct > peer-peer delivery of chat MESSAGEs using the SDP in the > INVITE. However, if > we've been forced to use an outbound proxy, or have > introduced a proxy through > preloaded routes, as mentioned above, there's a chance that > something along > the path will fork the chat MESSAGEs. > > I'm not claiming this is a problem. I just wanted to make > sure everyone > understood the possibility existed. Yes, it does. Under normal cases, where either Route is used, or where a direct messaging occurs, it definitely won't. In cases where it does end up forking, you want to be able to reject the message at all hosts except the one that was really supposed to get it. The right way to do that is to include a tag in the To field of all MESSAGE requests. This tag would be set as part of the URI in the SDP. Doing this is a little bit of a stretch; tag is really meant for requests that are part of a session. Technically, since MESSAGE operates like OPTIONS, there is really no SIP session associated with the collection of MESSAGES. But, I think its probably reasonable to use tag in any case. We need to explicitly note, in the text, that a UA should reject a MESSAGE if it contains a to tag that is unrecognized. -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 From ndramais@indigosw.com Tue May 15 11:00:42 2001 Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04906 for ; Tue, 15 May 2001 11:00:41 -0400 (EDT) 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 IAA08549 for ; Tue, 15 May 2001 08:01:00 -0700 (PDT) Message-ID: <3B014488.1E7A5D49@indigosw.com> Date: Tue, 15 May 2001 17:00:24 +0200 From: Nicolas Dramais Organization: Indigo Software X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SIMPLE LIST Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 884 Subject: [Simple] presence data format description 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: Hi all, In section 5.4 NOTIFY Bodies of draft-rosenberg-impp-presence-01.txt, one can read : "All subscribers MUST support the presence data format described in [fill in with IMPP document TBD], and MUST list its MIME type, [fill in with MIME type] in an Accept header present in the SUBSCRIBE request." I'd like to get more information about this TBD presence data format document. Has it been written meanwhile by the IMPP working group ? (could not find any reference) Is the presence data format associated with MIME subtype "xpidf+xml" used in the message flow examples described somewhere ? Thanks in advance, Nicolas. -- Nicolas DRAMAIS Communications Software Engineering Indigo Software ~~~~~~~~~~~~~~~~~~~~~~ 50, rue Wiertz 1050 Brussels Belgium tel.: +3222350952 fax: +3222802676 mailto:ndramais@indigosw.com ~~~~~~~~~~~~~~~~~~~~~~ http://www.indigosw.com From jdrosen@dynamicsoft.com Wed May 16 18:18:32 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00667 for ; Wed, 16 May 2001 18:18:32 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA08691 for ; Wed, 16 May 2001 18:22:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 May 2001 18:18:32 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Wed, 16 May 2001 18:18:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5326 Subject: [Simple] authorization for 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: Folks, I think its time we begin discussing the second main open issue discussed at the last IETF. Specifically, the issue of authorization of presence subscriptions. The currently defined method makes use of QAUTH. When a presence server gets a SUBSCRIBE, it sends a QAUTH to the presentity. If the subscription is acceptable, the presentity responds to the QAUTH with a 200 OK. The proxy knows to send QAUTH to the presentity because it will send a methods parameter in a REGISTER, indicating that their contact address supports QAUTH. There are several big problems with this: 1. the QAUTH transaction will timeout if the user doesn't answer right away. QAUTH, like INVITE, requires human interaction, and so its retransmit semantics don't work. 2. If QAUTH forks, we will end up receiving the "best" response to the query, which will be a 200 OK if anyone of the forked requests results in a 200 OK. As a result, the policy for merging approvals for subscriptions is forced to be the same as the forking rules, which is probably not what you want. 3. The model assumes that if I can send a registration for a presentity, that means I am authorized to make policy decisions about subscriptions. That is not necessarily the case. We are really overloading register to imply something else. So, the proposal I made to resolve this was the following: 1. We define a new event package, called "watcherinfo". This package defines a subscribable entity, which is the current subscription state for some presentity. Its a list of those active and pending subscriptions for some presentity. When someone subscribes to a presentity, the subscription state for that presentity changes. A new pending subscription is basically added. Since this state is subscribable, a UA can subscribe to it, and get notifications when it changes. In this case, the UA is notified if someone tries to SUBSCRIBE to the specific presentity. The body of the notifications contains the current subscription list for that presentity. 2. We define an authorization document format for presence. This is a simple document format which indicates the set of subscriber identities that are permitted, or not permitted, to subscribe to a presentity. For example: allow: sip:a@b sip:b@c deny: sip:x@y 3. At any point in time (including after receiving a notification that a new subscriber has attempted to subscribe), a UA can push a new authorization document to the presence server. The presence server applies this policy to the current subscription list, dropping or approving subscriptions as needed. This push could happen via HTTP or through SIP, TBD. Here is an example. A subscriber, sip:sally@foo.com, subscribes to some presentity, sip:peter@bar.com. The presence server receives the subscription, marks it as pending, and sends a 202. Now, the subscriber list for peter has changed; sally@foo.com has been added as pending. peter@bar.com has also subcsribed to the subscription state for peter@bar.com. It did this previously, by sending a SUBSCRIBE that looks like: SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 Event: watcherinfo Now, since the buddy list for Peter has changed, Peter (and any others that have subscribed), get notifications. The NOTIFY might look like: NOTIFY sip:peter@bar.com SIP/2.0 From: sip:peter_buddylist@bar.com To: sip:peter@bar.com Content-type: text/xml+buddies sip:sally@foo.com sip:friend@baz.com Peter's UA gets this NOTIFY, and responds with 200 OK. It also queries peter about whether to accept this pending subscription from sally@foo.com. Peter is away from his desk. He comes back 10 minutes later, and clicks OK. At this point, the UA uploads a new authorization document fragment, using SIP, say: SETDATA sip:peter_presence_auth@bar.com SIP/2.0 From: sip:peter@bar.com Content-type: text/authlist accept: sip:sally@foo.com The presence server gets this, and responds with a 200 OK. Sally is now approved. The benefits of this approach are: 1. we separate the policies on (1) who finds out about subscription changes for a presentity, and (2) who can set policies for subscription changes for a presentity. 2. there is no transaction timeout problem 3. policies on merging multiple authorization documents are at the discretion of the presence server. 4. We unify setting of policies asyncrhonously, and syncrhonously with the arrival of a subscription. 5. since authorization policies are a document, not a protocol, they can be exchanged, stored, and manipulated which is very good. 6. much of this is reusable by other protocols The slides I presented at IETF 50, where I described this proposal, can be found at: http://www.jdrosen.net/papers/simple_open_mar01.ppt We need to decide whether to move forward with this approach. Comments and criticisms are welcome. 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 From hgs@cs.columbia.edu Wed May 16 18:43:56 2001 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00760 for ; Wed, 16 May 2001 18:43:56 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA29041; Wed, 16 May 2001 18:43:54 -0400 (EDT) Message-ID: <3B0302AA.75DDABA5@cs.columbia.edu> Date: Wed, 16 May 2001 18:43:54 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] authorization for presence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 7397 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: One general objective, I believe, has to be that we can present a complete solution, i.e., there needs to be a way to do the authorization in SIP. Otherwise, there's no way to build interoperable systems. (This doesn't disagree with what Jonathan says, just emphasizes that we can't stop with the SUBSCRIBE and NOTIFY parts. Thus, I would create an explicit AUTH or MODIFYSUBSCRIBERLIST method to handle this.) Also, as much as possible, naming must be predictable. I'm not too thrilled about having to configure the variations of peter_buddylist@ and whatever else is needed. Making up URLs with designated names is not general enough. There may also be other events that require the same mechanism. Is 'watcherinfo' tied to 'presence'? Does every new event type need such a pairing? Or can we parameterize this to allow other events to re-use this meta-event mechanism? (For example, it might be possible to use something like Event: foo ;watchers or some variation on this, so that every event is treated as a class with a standard associated meta-event.). Finally, it would be nice if we can avoid special cases. Subscribing to the event 'watcherinfo' should not be substantially different than any other event. In particular, this must recurse, i.e., subscribing to watcherinfo in itself must trigger a notification. Jonathan Rosenberg wrote: > > Folks, > > I think its time we begin discussing the second main open issue discussed at > the last IETF. Specifically, the issue of authorization of presence > subscriptions. > > The currently defined method makes use of QAUTH. When a presence server gets > a SUBSCRIBE, it sends a QAUTH to the presentity. If the subscription is > acceptable, the presentity responds to the QAUTH with a 200 OK. The proxy > knows to send QAUTH to the presentity because it will send a methods > parameter in a REGISTER, indicating that their contact address supports > QAUTH. > > There are several big problems with this: > > 1. the QAUTH transaction will timeout if the user doesn't answer right away. > QAUTH, like INVITE, requires human interaction, and so its retransmit > semantics don't work. > > 2. If QAUTH forks, we will end up receiving the "best" response to the > query, which will be a 200 OK if anyone of the forked requests results in a > 200 OK. As a result, the policy for merging approvals for subscriptions is > forced to be the same as the forking rules, which is probably not what you > want. > > 3. The model assumes that if I can send a registration for a presentity, > that means I am authorized to make policy decisions about subscriptions. > That is not necessarily the case. We are really overloading register to > imply something else. > > So, the proposal I made to resolve this was the following: > > 1. We define a new event package, called "watcherinfo". This package defines > a subscribable entity, which is the current subscription state for some > presentity. Its a list of those active and pending subscriptions for some > presentity. When someone subscribes to a presentity, the subscription state > for that presentity changes. A new pending subscription is basically added. > Since this state is subscribable, a UA can subscribe to it, and get > notifications when it changes. In this case, the UA is notified if someone > tries to SUBSCRIBE to the specific presentity. The body of the notifications > contains the current subscription list for that presentity. > > 2. We define an authorization document format for presence. This is a simple > document format which indicates the set of subscriber identities that are > permitted, or not permitted, to subscribe to a presentity. For example: > > allow: > sip:a@b > sip:b@c > > deny: > sip:x@y Nit-picking: I think we've learned from SDP that positional parsing is bad. I would suggest something like: + sip:a@b - sip:x@y Also, it is not clear whether such a denial is for one subscription event or "sticky". > > 3. At any point in time (including after receiving a notification that a new > subscriber has attempted to subscribe), a UA can push a new authorization > document to the presence server. The presence server applies this policy to > the current subscription list, dropping or approving subscriptions as > needed. This push could happen via HTTP or through SIP, TBD. > > Here is an example. > > A subscriber, sip:sally@foo.com, subscribes to some presentity, > sip:peter@bar.com. The presence server receives the subscription, marks it > as pending, and sends a 202. Now, the subscriber list for peter has changed; > sally@foo.com has been added as pending. peter@bar.com has also subcsribed > to the subscription state for peter@bar.com. It did this previously, by > sending a SUBSCRIBE that looks like: > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > Event: watcherinfo > > Now, since the buddy list for Peter has changed, Peter (and any others that > have subscribed), get notifications. The NOTIFY might look like: > > NOTIFY sip:peter@bar.com SIP/2.0 > From: sip:peter_buddylist@bar.com > To: sip:peter@bar.com > Content-type: text/xml+buddies > > > > sip:sally@foo.com > > > sip:friend@baz.com > > > > Peter's UA gets this NOTIFY, and responds with 200 OK. It also queries peter > about whether to accept this pending subscription from sally@foo.com. Peter > is away from his desk. He comes back 10 minutes later, and clicks OK. At > this point, the UA uploads a new authorization document fragment, using SIP, > say: > > SETDATA sip:peter_presence_auth@bar.com SIP/2.0 > From: sip:peter@bar.com > Content-type: text/authlist > > accept: > sip:sally@foo.com > > The presence server gets this, and responds with a 200 OK. Sally is now > approved. > > The benefits of this approach are: > > 1. we separate the policies on (1) who finds out about subscription changes > for a presentity, and (2) who can set policies for subscription changes for > a presentity. > > 2. there is no transaction timeout problem > > 3. policies on merging multiple authorization documents are at the > discretion of the presence server. > > 4. We unify setting of policies asyncrhonously, and syncrhonously with the > arrival of a subscription. > > 5. since authorization policies are a document, not a protocol, they can be > exchanged, stored, and manipulated which is very good. > > 6. much of this is reusable by other protocols > > The slides I presented at IETF 50, where I described this proposal, can be > found at: > http://www.jdrosen.net/papers/simple_open_mar01.ppt > > We need to decide whether to move forward with this approach. Comments and > criticisms are welcome. > > 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 -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From jdrosen@dynamicsoft.com Wed May 16 22:33:27 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01356 for ; Wed, 16 May 2001 22:33:27 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA09990; Wed, 16 May 2001 22:37:12 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 May 2001 22:33:25 -0400 Message-ID: From: Jonathan Rosenberg To: "'Nicolas Dramais'" , SIMPLE LIST Subject: RE: [Simple] presence data format description Date: Wed, 16 May 2001 22:33:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1371 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: > -----Original Message----- > From: Nicolas Dramais [mailto:ndramais@indigosw.com] > Sent: Tuesday, May 15, 2001 11:00 AM > To: SIMPLE LIST > Subject: [Simple] presence data format description > > > Hi all, > > In section 5.4 NOTIFY Bodies of draft-rosenberg-impp-presence-01.txt, > one can read : > "All subscribers MUST support the presence data format > described in [fill in with IMPP document TBD], and MUST > list its MIME > > type, [fill in with MIME type] in an Accept header present in the > SUBSCRIBE request." > > I'd like to get more information about this TBD presence data format > document. > Has it been written meanwhile by the IMPP working group ? (could not > find any reference) Not yet. THere was a posting on the list with a proposed DTD but that is far from finished. > Is the presence data format associated with MIME subtype "xpidf+xml" > used in the message flow examples described somewhere ? http://www.jdrosen.net/papers/draft-rosenberg-impp-pidf-00.txt -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 From Brian.Rosen@marconi.com Thu May 17 09:07:09 2001 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 JAA02979 for ; Thu, 17 May 2001 09:07:08 -0400 (EDT) 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 JAA17712; Thu, 17 May 2001 09:06:59 -0400 (EDT) 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 JAA22909; Thu, 17 May 2001 09:06:57 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 17 May 2001 09:06:25 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F62A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning G. Schulzrinne'" , Jonathan Rosenberg Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] authorization for presence Date: Thu, 17 May 2001 09:06:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Length: 9009 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: I'm also in favor of more general mechanisms. One specific that I need is a more rich sense of presence; that is, there might be more than a single "state" enumeration of presence. It might also be that the state variable has a lot of states, but a presentity only allows a particular watcher to see a filtered set. Suppose, for example, I could set presence to in-the-building, in-the-office, out-of-the-building, on-cell-phone, or home. I may want some watchers to get the exact state, others to only get in/out. I don't want to see the first version of SIMPLE do all of this, I want the mechanism to be able to expand reasonably. Some of this is easy (add parameters). > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, May 16, 2001 6:44 PM > To: Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] authorization for presence > > > One general objective, I believe, has to be that we can present a > complete solution, i.e., there needs to be a way to do the > authorization > in SIP. Otherwise, there's no way to build interoperable > systems. (This > doesn't disagree with what Jonathan says, just emphasizes > that we can't > stop with the SUBSCRIBE and NOTIFY parts. Thus, I would create an > explicit AUTH or MODIFYSUBSCRIBERLIST method to handle this.) > > Also, as much as possible, naming must be predictable. I'm not too > thrilled about having to configure the variations of peter_buddylist@ > and whatever else is needed. Making up URLs with designated > names is not > general enough. There may also be other events that require the same > mechanism. Is 'watcherinfo' tied to 'presence'? Does every new event > type need such a pairing? Or can we parameterize this to allow other > events to re-use this meta-event mechanism? (For example, it might be > possible to use something like Event: foo ;watchers or some > variation on > this, so that every event is treated as a class with a standard > associated meta-event.). > > Finally, it would be nice if we can avoid special cases. > Subscribing to > the event 'watcherinfo' should not be substantially different than any > other event. In particular, this must recurse, i.e., subscribing to > watcherinfo in itself must trigger a notification. > > > Jonathan Rosenberg wrote: > > > > Folks, > > > > I think its time we begin discussing the second main open > issue discussed at > > the last IETF. Specifically, the issue of authorization of presence > > subscriptions. > > > > The currently defined method makes use of QAUTH. When a > presence server gets > > a SUBSCRIBE, it sends a QAUTH to the presentity. If the > subscription is > > acceptable, the presentity responds to the QAUTH with a 200 > OK. The proxy > > knows to send QAUTH to the presentity because it will send a methods > > parameter in a REGISTER, indicating that their contact > address supports > > QAUTH. > > > > There are several big problems with this: > > > > 1. the QAUTH transaction will timeout if the user doesn't > answer right away. > > QAUTH, like INVITE, requires human interaction, and so its > retransmit > > semantics don't work. > > > > 2. If QAUTH forks, we will end up receiving the "best" > response to the > > query, which will be a 200 OK if anyone of the forked > requests results in a > > 200 OK. As a result, the policy for merging approvals for > subscriptions is > > forced to be the same as the forking rules, which is > probably not what you > > want. > > > > 3. The model assumes that if I can send a registration for > a presentity, > > that means I am authorized to make policy decisions about > subscriptions. > > That is not necessarily the case. We are really overloading > register to > > imply something else. > > > > So, the proposal I made to resolve this was the following: > > > > 1. We define a new event package, called "watcherinfo". > This package defines > > a subscribable entity, which is the current subscription > state for some > > presentity. Its a list of those active and pending > subscriptions for some > > presentity. When someone subscribes to a presentity, the > subscription state > > for that presentity changes. A new pending subscription is > basically added. > > Since this state is subscribable, a UA can subscribe to it, and get > > notifications when it changes. In this case, the UA is > notified if someone > > tries to SUBSCRIBE to the specific presentity. The body of > the notifications > > contains the current subscription list for that presentity. > > > > 2. We define an authorization document format for presence. > This is a simple > > document format which indicates the set of subscriber > identities that are > > permitted, or not permitted, to subscribe to a presentity. > For example: > > > > allow: > > sip:a@b > > sip:b@c > > > > deny: > > sip:x@y > > Nit-picking: I think we've learned from SDP that positional parsing is > bad. I would suggest something like: > > + sip:a@b > - sip:x@y > > Also, it is not clear whether such a denial is for one subscription > event or "sticky". > > > > > 3. At any point in time (including after receiving a > notification that a new > > subscriber has attempted to subscribe), a UA can push a new > authorization > > document to the presence server. The presence server > applies this policy to > > the current subscription list, dropping or approving > subscriptions as > > needed. This push could happen via HTTP or through SIP, TBD. > > > > Here is an example. > > > > A subscriber, sip:sally@foo.com, subscribes to some presentity, > > sip:peter@bar.com. The presence server receives the > subscription, marks it > > as pending, and sends a 202. Now, the subscriber list for > peter has changed; > > sally@foo.com has been added as pending. peter@bar.com has > also subcsribed > > to the subscription state for peter@bar.com. It did this > previously, by > > sending a SUBSCRIBE that looks like: > > > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > > Event: watcherinfo > > > > Now, since the buddy list for Peter has changed, Peter (and > any others that > > have subscribed), get notifications. The NOTIFY might look like: > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > From: sip:peter_buddylist@bar.com > > To: sip:peter@bar.com > > Content-type: text/xml+buddies > > > > > > > > sip:sally@foo.com > > > > > > sip:friend@baz.com > > > > > > > > Peter's UA gets this NOTIFY, and responds with 200 OK. It > also queries peter > > about whether to accept this pending subscription from > sally@foo.com. Peter > > is away from his desk. He comes back 10 minutes later, and > clicks OK. At > > this point, the UA uploads a new authorization document > fragment, using SIP, > > say: > > > > SETDATA sip:peter_presence_auth@bar.com SIP/2.0 > > From: sip:peter@bar.com > > Content-type: text/authlist > > > > accept: > > sip:sally@foo.com > > > > The presence server gets this, and responds with a 200 OK. > Sally is now > > approved. > > > > The benefits of this approach are: > > > > 1. we separate the policies on (1) who finds out about > subscription changes > > for a presentity, and (2) who can set policies for > subscription changes for > > a presentity. > > > > 2. there is no transaction timeout problem > > > > 3. policies on merging multiple authorization documents are at the > > discretion of the presence server. > > > > 4. We unify setting of policies asyncrhonously, and > syncrhonously with the > > arrival of a subscription. > > > > 5. since authorization policies are a document, not a > protocol, they can be > > exchanged, stored, and manipulated which is very good. > > > > 6. much of this is reusable by other protocols > > > > The slides I presented at IETF 50, where I described this > proposal, can be > > found at: > > http://www.jdrosen.net/papers/simple_open_mar01.ppt > > > > We need to decide whether to move forward with this > approach. Comments and > > criticisms are welcome. > > > > 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 > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From c-Dai.Ngo@WCOM.Com Thu May 17 10:51:11 2001 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 KAA03282 for ; Thu, 17 May 2001 10:51:10 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GDH00050IHQXW@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Thu, 17 May 2001 14:49:02 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GDH00A01IH8TR@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 17 May 2001 14:49:01 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GDH008Q1IH070@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 17 May 2001 14:48:36 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 14:48:36 +0000 Content-return: allowed Date: Thu, 17 May 2001 14:48:34 +0000 From: "Ngo, Dai (c)" Subject: RE: [Simple] authorization for presence To: "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E11C574@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_J/IBb3gibdsRb6HxTKo5nA)" Content-Length: 30566 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: 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_J/IBb3gibdsRb6HxTKo5nA) Content-type: text/plain; charset=iso-8859-1 I'm new to speak up in this forum. So, forgive me if I show my ignorance. I agree that QAUTH is having problem. But, what if there is an "AUTH" mechanism that only checks/reads the authorization list (ACL) and sends a 200-class response if the request is allowed. This can avoid the timeout problem or forking issues. The granting of access is left for local implementation. This can be done by uploading policy database as Jonathan suggested or via other means. Regards, Dai Ngo -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, May 17, 2001 8:07 AM To: 'Henning G. Schulzrinne'; Jonathan Rosenberg Cc: 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] authorization for presence I'm also in favor of more general mechanisms. One specific that I need is a more rich sense of presence; that is, there might be more than a single "state" enumeration of presence. It might also be that the state variable has a lot of states, but a presentity only allows a particular watcher to see a filtered set. Suppose, for example, I could set presence to in-the-building, in-the-office, out-of-the-building, on-cell-phone, or home. I may want some watchers to get the exact state, others to only get in/out. I don't want to see the first version of SIMPLE do all of this, I want the mechanism to be able to expand reasonably. Some of this is easy (add parameters). > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, May 16, 2001 6:44 PM > To: Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] authorization for presence > > > One general objective, I believe, has to be that we can present a > complete solution, i.e., there needs to be a way to do the > authorization > in SIP. Otherwise, there's no way to build interoperable > systems. (This > doesn't disagree with what Jonathan says, just emphasizes > that we can't > stop with the SUBSCRIBE and NOTIFY parts. Thus, I would create an > explicit AUTH or MODIFYSUBSCRIBERLIST method to handle this.) > > Also, as much as possible, naming must be predictable. I'm not too > thrilled about having to configure the variations of peter_buddylist@ > and whatever else is needed. Making up URLs with designated > names is not > general enough. There may also be other events that require the same > mechanism. Is 'watcherinfo' tied to 'presence'? Does every new event > type need such a pairing? Or can we parameterize this to allow other > events to re-use this meta-event mechanism? (For example, it might be > possible to use something like Event: foo ;watchers or some > variation on > this, so that every event is treated as a class with a standard > associated meta-event.). > > Finally, it would be nice if we can avoid special cases. > Subscribing to > the event 'watcherinfo' should not be substantially different than any > other event. In particular, this must recurse, i.e., subscribing to > watcherinfo in itself must trigger a notification. > > > Jonathan Rosenberg wrote: > > > > Folks, > > > > I think its time we begin discussing the second main open > issue discussed at > > the last IETF. Specifically, the issue of authorization of presence > > subscriptions. > > > > The currently defined method makes use of QAUTH. When a > presence server gets > > a SUBSCRIBE, it sends a QAUTH to the presentity. If the > subscription is > > acceptable, the presentity responds to the QAUTH with a 200 > OK. The proxy > > knows to send QAUTH to the presentity because it will send a methods > > parameter in a REGISTER, indicating that their contact > address supports > > QAUTH. > > > > There are several big problems with this: > > > > 1. the QAUTH transaction will timeout if the user doesn't > answer right away. > > QAUTH, like INVITE, requires human interaction, and so its > retransmit > > semantics don't work. > > > > 2. If QAUTH forks, we will end up receiving the "best" > response to the > > query, which will be a 200 OK if anyone of the forked > requests results in a > > 200 OK. As a result, the policy for merging approvals for > subscriptions is > > forced to be the same as the forking rules, which is > probably not what you > > want. > > > > 3. The model assumes that if I can send a registration for > a presentity, > > that means I am authorized to make policy decisions about > subscriptions. > > That is not necessarily the case. We are really overloading > register to > > imply something else. > > > > So, the proposal I made to resolve this was the following: > > > > 1. We define a new event package, called "watcherinfo". > This package defines > > a subscribable entity, which is the current subscription > state for some > > presentity. Its a list of those active and pending > subscriptions for some > > presentity. When someone subscribes to a presentity, the > subscription state > > for that presentity changes. A new pending subscription is > basically added. > > Since this state is subscribable, a UA can subscribe to it, and get > > notifications when it changes. In this case, the UA is > notified if someone > > tries to SUBSCRIBE to the specific presentity. The body of > the notifications > > contains the current subscription list for that presentity. > > > > 2. We define an authorization document format for presence. > This is a simple > > document format which indicates the set of subscriber > identities that are > > permitted, or not permitted, to subscribe to a presentity. > For example: > > > > allow: > > sip:a@b > > sip:b@c > > > > deny: > > sip:x@y > > Nit-picking: I think we've learned from SDP that positional parsing is > bad. I would suggest something like: > > + sip:a@b > - sip:x@y > > Also, it is not clear whether such a denial is for one subscription > event or "sticky". > > > > > 3. At any point in time (including after receiving a > notification that a new > > subscriber has attempted to subscribe), a UA can push a new > authorization > > document to the presence server. The presence server > applies this policy to > > the current subscription list, dropping or approving > subscriptions as > > needed. This push could happen via HTTP or through SIP, TBD. > > > > Here is an example. > > > > A subscriber, sip:sally@foo.com, subscribes to some presentity, > > sip:peter@bar.com. The presence server receives the > subscription, marks it > > as pending, and sends a 202. Now, the subscriber list for > peter has changed; > > sally@foo.com has been added as pending. peter@bar.com has > also subcsribed > > to the subscription state for peter@bar.com. It did this > previously, by > > sending a SUBSCRIBE that looks like: > > > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > > Event: watcherinfo > > > > Now, since the buddy list for Peter has changed, Peter (and > any others that > > have subscribed), get notifications. The NOTIFY might look like: > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > From: sip:peter_buddylist@bar.com > > To: sip:peter@bar.com > > Content-type: text/xml+buddies > > > > > > > > sip:sally@foo.com > > > > > > sip:friend@baz.com > > > > > > > > Peter's UA gets this NOTIFY, and responds with 200 OK. It > also queries peter > > about whether to accept this pending subscription from > sally@foo.com. Peter > > is away from his desk. He comes back 10 minutes later, and > clicks OK. At > > this point, the UA uploads a new authorization document > fragment, using SIP, > > say: > > > > SETDATA sip:peter_presence_auth@bar.com SIP/2.0 > > From: sip:peter@bar.com > > Content-type: text/authlist > > > > accept: > > sip:sally@foo.com > > > > The presence server gets this, and responds with a 200 OK. > Sally is now > > approved. > > > > The benefits of this approach are: > > > > 1. we separate the policies on (1) who finds out about > subscription changes > > for a presentity, and (2) who can set policies for > subscription changes for > > a presentity. > > > > 2. there is no transaction timeout problem > > > > 3. policies on merging multiple authorization documents are at the > > discretion of the presence server. > > > > 4. We unify setting of policies asyncrhonously, and > syncrhonously with the > > arrival of a subscription. > > > > 5. since authorization policies are a document, not a > protocol, they can be > > exchanged, stored, and manipulated which is very good. > > > > 6. much of this is reusable by other protocols > > > > The slides I presented at IETF 50, where I described this > proposal, can be > > found at: > > http://www.jdrosen.net/papers/simple_open_mar01.ppt > > > > We need to decide whether to move forward with this > approach. Comments and > > criticisms are welcome. > > > > 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 > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ > 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 --Boundary_(ID_J/IBb3gibdsRb6HxTKo5nA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: [Simple] authorization for presence

I'm new to speak up in this forum. So, forgive me if = I show my ignorance.

I agree that QAUTH is having problem.
But, what if there is an "AUTH" mechanism = that only checks/reads the authorization list (ACL) and sends a = 200-class response if the request is allowed. This can avoid the = timeout problem or forking issues.

The granting of access is left for local = implementation. This can be done by uploading policy database as = Jonathan suggested or via other means.

Regards,

Dai Ngo
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, May 17, 2001 8:07 AM
To: 'Henning G. Schulzrinne'; Jonathan = Rosenberg
Cc: 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] authorization for = presence


I'm also in favor of more general mechanisms.  = One specific that I
need is a more rich sense of presence; that is, = there might be
more than a single "state" enumeration of = presence.  It might also
be that the state variable has a lot of states, but = a presentity
only allows a particular watcher to see a filtered = set.  Suppose,
for example, I could set presence to = in-the-building, in-the-office,
out-of-the-building, on-cell-phone, or home.  I = may want some watchers
to get the exact state, others to only get = in/out.

I don't want to see the first version of SIMPLE do = all of this, I
want the mechanism to be able to expand = reasonably.  Some of this
is easy (add parameters).

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Wednesday, May 16, 2001 6:44 PM
> To: Jonathan Rosenberg
> Cc: 'simple@mailman.dynamicsoft.com'
> Subject: Re: [Simple] authorization for = presence
>
>
> One general objective, I believe, has to be = that we can present a
> complete solution, i.e., there needs to be a = way to do the
> authorization
> in SIP. Otherwise, there's no way to build = interoperable
> systems. (This
> doesn't disagree with what Jonathan says, just = emphasizes
> that we can't
> stop with the SUBSCRIBE and NOTIFY parts. Thus, = I would create an
> explicit AUTH or MODIFYSUBSCRIBERLIST method to = handle this.)
>
> Also, as much as possible, naming must be = predictable. I'm not too
> thrilled about having to configure the = variations of peter_buddylist@
> and whatever else is needed. Making up URLs = with designated
> names is not
> general enough. There may also be other events = that require the same
> mechanism. Is 'watcherinfo' tied to 'presence'? = Does every new event
> type need such a pairing? Or can we = parameterize this to allow other
> events to re-use this meta-event mechanism? = (For example, it might be
> possible to use something like Event: foo = ;watchers or some
> variation on
> this, so that every event is treated as a class = with a standard
> associated meta-event.).
>
> Finally, it would be nice if we can avoid = special cases.
> Subscribing to
> the event 'watcherinfo' should not be = substantially different than any
> other event. In particular, this must recurse, = i.e., subscribing to
> watcherinfo in itself must trigger a = notification.
>
>
> Jonathan Rosenberg wrote:
> >
> > Folks,
> >
> > I think its time we begin discussing the = second main open
> issue discussed at
> > the last IETF. Specifically, the issue of = authorization of presence
> > subscriptions.
> >
> > The currently defined method makes use of = QAUTH. When a
> presence server gets
> > a SUBSCRIBE, it sends a QAUTH to the = presentity. If the
> subscription is
> > acceptable, the presentity responds to the = QAUTH with a 200
> OK. The proxy
> > knows to send QAUTH to the presentity = because it will send a methods
> > parameter in a REGISTER, indicating that = their contact
> address supports
> > QAUTH.
> >
> > There are several big problems with = this:
> >
> > 1. the QAUTH transaction will timeout if = the user doesn't
> answer right away.
> > QAUTH, like INVITE, requires human = interaction, and so its
> retransmit
> > semantics don't work.
> >
> > 2. If QAUTH forks, we will end up = receiving the "best"
> response to the
> > query, which will be a 200 OK if anyone of = the forked
> requests results in a
> > 200 OK. As a result, the policy for = merging approvals for
> subscriptions is
> > forced to be the same as the forking = rules, which is
> probably not what you
> > want.
> >
> > 3. The model assumes that if I can send a = registration for
> a presentity,
> > that means I am authorized to make policy = decisions about
> subscriptions.
> > That is not necessarily the case. We are = really overloading
> register to
> > imply something else.
> >
> > So, the proposal I made to resolve this = was the following:
> >
> > 1. We define a new event package, called = "watcherinfo".
> This package defines
> > a subscribable entity, which is the = current subscription
> state for some
> > presentity. Its a list of those active and = pending
> subscriptions for some
> > presentity. When someone subscribes to a = presentity, the
> subscription state
> > for that presentity changes. A new pending = subscription is
> basically added.
> > Since this state is subscribable, a UA can = subscribe to it, and get
> > notifications when it changes. In this = case, the UA is
> notified if someone
> > tries to SUBSCRIBE to the specific = presentity. The body of
> the notifications
> > contains the current subscription list for = that presentity.
> >
> > 2. We define an authorization document = format for presence.
> This is a simple
> > document format which indicates the set of = subscriber
> identities that are
> > permitted, or not permitted, to subscribe = to a presentity.
> For example:
> >
> > allow:
> > sip:a@b
> > sip:b@c
> >
> > deny:
> > sip:x@y
>
> Nit-picking: I think we've learned from SDP = that positional parsing is
> bad. I would suggest something like:
>
> + sip:a@b
> - sip:x@y
>
> Also, it is not clear whether such a denial is = for one subscription
> event or "sticky".
>
> >
> > 3. At any point in time (including after = receiving a
> notification that a new
> > subscriber has attempted to subscribe), a = UA can push a new
> authorization
> > document to the presence server. The = presence server
> applies this policy to
> > the current subscription list, dropping or = approving
> subscriptions as
> > needed. This push could happen via HTTP or = through SIP, TBD.
> >
> > Here is an example.
> >
> > A subscriber, sip:sally@foo.com, = subscribes to some presentity,
> > sip:peter@bar.com. The presence server = receives the
> subscription, marks it
> > as pending, and sends a 202. Now, the = subscriber list for
> peter has changed;
> > sally@foo.com has been added as pending. = peter@bar.com has
> also subcsribed
> > to the subscription state for = peter@bar.com. It did this
> previously, by
> > sending a SUBSCRIBE that looks = like:
> >
> > SUBSCRIBE sip:peter_buddylist@bar.com = SIP/2.0
> > Event: watcherinfo
> >
> > Now, since the buddy list for Peter has = changed, Peter (and
> any others that
> > have subscribed), get notifications. The = NOTIFY might look like:
> >
> > NOTIFY sip:peter@bar.com SIP/2.0
> > From: sip:peter_buddylist@bar.com
> > To: sip:peter@bar.com
> > Content-type: text/xml+buddies
> >
> > <buddylist>
> >   <pending>
> >     = <subscriber>sip:sally@foo.com</subscriber>
> >   </pending>
> >   <active>
> >     = <subscriber>sip:friend@baz.com</subscriber>
> >   </active>
> > </buddylist>
> >
> > Peter's UA gets this NOTIFY, and responds = with 200 OK. It
> also queries peter
> > about whether to accept this pending = subscription from
> sally@foo.com. Peter
> > is away from his desk. He comes back 10 = minutes later, and
> clicks OK. At
> > this point, the UA uploads a new = authorization document
> fragment, using SIP,
> > say:
> >
> > SETDATA sip:peter_presence_auth@bar.com = SIP/2.0
> > From: sip:peter@bar.com
> > Content-type: text/authlist
> >
> > accept:
> > sip:sally@foo.com
> >
> > The presence server gets this, and = responds with a 200 OK.
> Sally is now
> > approved.
> >
> > The benefits of this approach are:
> >
> > 1. we separate the policies on (1) who = finds out about
> subscription changes
> > for a presentity, and (2) who can set = policies for
> subscription changes for
> > a presentity.
> >
> > 2. there is no transaction timeout = problem
> >
> > 3. policies on merging multiple = authorization documents are at the
> > discretion of the presence server.
> >
> > 4. We unify setting of policies = asyncrhonously, and
> syncrhonously with the
> > arrival of a subscription.
> >
> > 5. since authorization policies are a = document, not a
> protocol, they can be
> > exchanged, stored, and manipulated which = is very good.
> >
> > 6. much of this is reusable by other = protocols
> >
> > The slides I presented at IETF 50, where I = described this
> proposal, can be
> > found at:
> > http://www.jdrosen.net/papers/simple_open_mar01.ppt
> >
> > We need to decide whether to move forward = with this
> approach. Comments and
> > criticisms are welcome.
> >
> > Thanks,
> > 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
> >
> > = _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple=
>
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> = _______________________________________________
> 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=

--Boundary_(ID_J/IBb3gibdsRb6HxTKo5nA)-- From sameer@sankartech.net Fri May 18 01:43:30 2001 Received: from bgl1ml1-a.sancharnet.in (bgl1ml2-a-fixed.sancharnet.in [61.1.128.36]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05566 for ; Fri, 18 May 2001 01:43:21 -0400 (EDT) Received: from voyager.sankartech ([61.1.217.250]) by bgl1ml1-a.sancharnet.in (Netscape Messaging Server 3.6) with ESMTP id AAA5762EC for ; Fri, 18 May 2001 11:15:41 -0500 Received: by VOYAGER with Internet Mail Service (5.5.2653.19) id ; Fri, 18 May 2001 11:15:24 +0530 Message-ID: From: Sameer sheth To: simple@mailman.dynamicsoft.com Date: Fri, 18 May 2001 11:15:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 922 Subject: [Simple] Reply Requested Immediately Please 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: Hi I am new to this group and also to this domain. I have very few basic queries regarding SIP and I would like you to help me out. Please do reply as soon as possible 1) What role does User Agent plays ? Is it necessary that only through User Agent we can contact the SIP Server ? if yes then how does the ordinary Telephone, which everyone at their residences use can get connected ? 2) Can a ordinary Telephone, which everyone at their residences have can contact SIP Server ? and from there interact with other SIP USERS ? 3) When I transmit Voice over SIP which use TCP/IP, what role does SIP play at that time ? I thank you in advance for your kind help and time. I would really appreciate if you could reply back to me as soon as possible. Thanking you Regards > ----------------------------------- > Sameer.Sheth > Analysts > Justvox ---> We(b) Speak, Your Way > T/F: +91-422-446127 / 456753 > > From dsimons@windows.microsoft.com Sun May 20 23:37:25 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id XAA16099 for ; Sun, 20 May 2001 23:37:24 -0400 (EDT) Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 20 May 2001 20:37:13 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 20 May 2001 20:36:39 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 20 May 2001 20:36:36 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 20 May 2001 20:36:11 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E1A7.2E21AD95" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Sun, 20 May 2001 20:36:11 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1463655@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Difference between a SUBSCRIBE and a re-SUBSCRIBE Thread-Index: AcDhpz2LQCpb/tMpQO6lfl1BNDnCvg== From: "David Simons" To: X-OriginalArrivalTime: 21 May 2001 03:36:11.0733 (UTC) FILETIME=[2E342050:01C0E1A7] Content-Length: 4158 Subject: [Simple] Difference between a SUBSCRIBE and a re-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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E1A7.2E21AD95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In draft-roach-sip-subscribe-notify-03.txt a re-SUBSCRIBE is a SUBSCRIBE request with the same Call-ID and higher CSeq. The issue we are having is that if a PA losses state, because deletion after timeout or a crash how does the PA know if a SUBSCRIBE request is a new SUBSCRIBE request or a re-SUBSCRIBE request? This is significant in that the client is expecting a NOTIFY with a greater CSeq but the PA will start over. I suppose that one could just use a time stanp as the CSeq but that won't work if the clocks our synchronized.=20 =20 The solution that I'm proposing is that a new SUBSCRIBES should have a CSeq of 1 and then each re-SUBSCRIBE can have a CSeq greater then one. If a PA receives a SUBSCIBE with a CSeq greater then 1 and it has no record of the SUBSCRIBE it should return a 481. The client could then issue a new SUBSCRIBE with a new Call-ID and a CSeq of 1.=20 =20 Regards, =20 David J. Simons =20 =20 ------_=_NextPart_001_01C0E1A7.2E21AD95 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In draft-roach-sip-subscribe-notify-03.txt a = re-SUBSCRIBE is a SUBSCRIBE request with the same Call-ID and higher CSeq.  The = issue we are having is that if a PA  losses state, because deletion after = timeout or a crash how does the PA know if a SUBSCRIBE request is a new = SUBSCRIBE request or a re-SUBSCRIBE request?  This is significant in that the client = is expecting a NOTIFY with a greater CSeq but the PA will start over.  = I suppose that one could just use a time stanp as the CSeq but that won’t = work if the clocks our synchronized.

 

The solution that I’m proposing is that a new = SUBSCRIBES should have a CSeq of 1 and then each re-SUBSCRIBE can have a CSeq = greater then one.  If a PA receives a SUBSCIBE with a CSeq greater then 1 and it = has no record of the SUBSCRIBE it should return a 481.  The client could = then issue a new SUBSCRIBE with a new Call-ID and a CSeq of 1. =

 

Regards,

 

David J. Simons

 

 

=00 ------_=_NextPart_001_01C0E1A7.2E21AD95-- From jdrosen@dynamicsoft.com Mon May 21 08:26:18 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00853 for ; Mon, 21 May 2001 08:26:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA04382; Mon, 21 May 2001 08:30:07 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 May 2001 08:26:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] authorization for presence Date: Mon, 21 May 2001 08:26:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 9880 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: > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, May 16, 2001 6:44 PM > To: Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] authorization for presence > > > One general objective, I believe, has to be that we can present a > complete solution, i.e., there needs to be a way to do the > authorization > in SIP. Otherwise, there's no way to build interoperable > systems. (This > doesn't disagree with what Jonathan says, just emphasizes > that we can't > stop with the SUBSCRIBE and NOTIFY parts. Thus, I would create an > explicit AUTH or MODIFYSUBSCRIBERLIST method to handle this.) Just so I am clear, are you saying that we need an entire solution that is completely SIP based, or just an entire solution? I agree with the latter, and that was indeed the point of the proposal. I am not yet completely convinced that it is all SIP, and less certain that uploading of authorization documents is best done by a new AUTH method or something similar. > > Also, as much as possible, naming must be predictable. I'm not too > thrilled about having to configure the variations of peter_buddylist@ > and whatever else is needed. Making up URLs with designated > names is not > general enough. There may also be other events that require the same > mechanism. Is 'watcherinfo' tied to 'presence'? Does every new event > type need such a pairing? Or can we parameterize this to allow other > events to re-use this meta-event mechanism? (For example, it might be > possible to use something like Event: foo ;watchers or some > variation on > this, so that every event is treated as a class with a standard > associated meta-event.). I think that having a standard naming convention here is probably a good thing. It also seems clear that this concept does go beyond just presence. One way to consider it is that every event package has a pre-defined set of subpackages: foo.wachters foo.statistics foo.policy or something like that. > > Finally, it would be nice if we can avoid special cases. > Subscribing to > the event 'watcherinfo' should not be substantially different than any > other event. In particular, this must recurse, i.e., subscribing to > watcherinfo in itself must trigger a notification. I think the mechanism should allow this, but we don't need to require each presence server to support these sub-sub packages. So, for example: SUBSCRIBE sip:jdrosen.watcherinfo.watcherinfo@dynamicsoft.com SIP/2.0 Event: presence.subscribers.subscribers might generate: SIP/2.0 489 Package not Supported This example does make me wonder, though; if the package name is "subclassed" to indicate watchers, do we need to indicate this in the R-URI as well? That is, would the SUBSCRIBE instead look like: SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0 Event: presence.subscribers I suspect this is probably more correct and in line with the SUBSCRIBE architecture. -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 Rosenberg wrote: > > > > Folks, > > > > I think its time we begin discussing the second main open > issue discussed at > > the last IETF. Specifically, the issue of authorization of presence > > subscriptions. > > > > The currently defined method makes use of QAUTH. When a > presence server gets > > a SUBSCRIBE, it sends a QAUTH to the presentity. If the > subscription is > > acceptable, the presentity responds to the QAUTH with a 200 > OK. The proxy > > knows to send QAUTH to the presentity because it will send a methods > > parameter in a REGISTER, indicating that their contact > address supports > > QAUTH. > > > > There are several big problems with this: > > > > 1. the QAUTH transaction will timeout if the user doesn't > answer right away. > > QAUTH, like INVITE, requires human interaction, and so its > retransmit > > semantics don't work. > > > > 2. If QAUTH forks, we will end up receiving the "best" > response to the > > query, which will be a 200 OK if anyone of the forked > requests results in a > > 200 OK. As a result, the policy for merging approvals for > subscriptions is > > forced to be the same as the forking rules, which is > probably not what you > > want. > > > > 3. The model assumes that if I can send a registration for > a presentity, > > that means I am authorized to make policy decisions about > subscriptions. > > That is not necessarily the case. We are really overloading > register to > > imply something else. > > > > So, the proposal I made to resolve this was the following: > > > > 1. We define a new event package, called "watcherinfo". > This package defines > > a subscribable entity, which is the current subscription > state for some > > presentity. Its a list of those active and pending > subscriptions for some > > presentity. When someone subscribes to a presentity, the > subscription state > > for that presentity changes. A new pending subscription is > basically added. > > Since this state is subscribable, a UA can subscribe to it, and get > > notifications when it changes. In this case, the UA is > notified if someone > > tries to SUBSCRIBE to the specific presentity. The body of > the notifications > > contains the current subscription list for that presentity. > > > > 2. We define an authorization document format for presence. > This is a simple > > document format which indicates the set of subscriber > identities that are > > permitted, or not permitted, to subscribe to a presentity. > For example: > > > > allow: > > sip:a@b > > sip:b@c > > > > deny: > > sip:x@y > > Nit-picking: I think we've learned from SDP that positional parsing is > bad. I would suggest something like: > > + sip:a@b > - sip:x@y > > Also, it is not clear whether such a denial is for one subscription > event or "sticky". > > > > > 3. At any point in time (including after receiving a > notification that a new > > subscriber has attempted to subscribe), a UA can push a new > authorization > > document to the presence server. The presence server > applies this policy to > > the current subscription list, dropping or approving > subscriptions as > > needed. This push could happen via HTTP or through SIP, TBD. > > > > Here is an example. > > > > A subscriber, sip:sally@foo.com, subscribes to some presentity, > > sip:peter@bar.com. The presence server receives the > subscription, marks it > > as pending, and sends a 202. Now, the subscriber list for > peter has changed; > > sally@foo.com has been added as pending. peter@bar.com has > also subcsribed > > to the subscription state for peter@bar.com. It did this > previously, by > > sending a SUBSCRIBE that looks like: > > > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > > Event: watcherinfo > > > > Now, since the buddy list for Peter has changed, Peter (and > any others that > > have subscribed), get notifications. The NOTIFY might look like: > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > From: sip:peter_buddylist@bar.com > > To: sip:peter@bar.com > > Content-type: text/xml+buddies > > > > > > > > sip:sally@foo.com > > > > > > sip:friend@baz.com > > > > > > > > Peter's UA gets this NOTIFY, and responds with 200 OK. It > also queries peter > > about whether to accept this pending subscription from > sally@foo.com. Peter > > is away from his desk. He comes back 10 minutes later, and > clicks OK. At > > this point, the UA uploads a new authorization document > fragment, using SIP, > > say: > > > > SETDATA sip:peter_presence_auth@bar.com SIP/2.0 > > From: sip:peter@bar.com > > Content-type: text/authlist > > > > accept: > > sip:sally@foo.com > > > > The presence server gets this, and responds with a 200 OK. > Sally is now > > approved. > > > > The benefits of this approach are: > > > > 1. we separate the policies on (1) who finds out about > subscription changes > > for a presentity, and (2) who can set policies for > subscription changes for > > a presentity. > > > > 2. there is no transaction timeout problem > > > > 3. policies on merging multiple authorization documents are at the > > discretion of the presence server. > > > > 4. We unify setting of policies asyncrhonously, and > syncrhonously with the > > arrival of a subscription. > > > > 5. since authorization policies are a document, not a > protocol, they can be > > exchanged, stored, and manipulated which is very good. > > > > 6. much of this is reusable by other protocols > > > > The slides I presented at IETF 50, where I described this > proposal, can be > > found at: > > http://www.jdrosen.net/papers/simple_open_mar01.ppt > > > > We need to decide whether to move forward with this > approach. Comments and > > criticisms are welcome. > > > > 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 > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > From jdrosen@dynamicsoft.com Mon May 21 08:31:00 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00894 for ; Mon, 21 May 2001 08:31:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA04448; Mon, 21 May 2001 08:34:47 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 May 2001 08:30:57 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" , "'Henning G. Schulzrinne'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] authorization for presence Date: Mon, 21 May 2001 08:30:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 11119 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: > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Thursday, May 17, 2001 9:07 AM > To: 'Henning G. Schulzrinne'; Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] authorization for presence > > > I'm also in favor of more general mechanisms. One specific that I > need is a more rich sense of presence; that is, there might be > more than a single "state" enumeration of presence. Absolutely. THe presence data format will, in all likelihood, be an XML document specifically because this will allow us to extend it and provide a rich, tree-like structure for presence data. Even the baseline is more than just a single piece of state; its a listing of communications addresses, each of which is "open" or "closed". > It might also > be that the state variable has a lot of states, but a presentity > only allows a particular watcher to see a filtered set. Suppose, > for example, I could set presence to in-the-building, in-the-office, > out-of-the-building, on-cell-phone, or home. I may want some watchers > to get the exact state, others to only get in/out. The presence package allows subscribers to indicate what aspect of my presence they want (by carrying a subscription filter document in SUBSCRIBE), and the proposed authorization mechanism allows presentities to indicate how they want subscriptions handled (by putting a policy document in an upload request). In the simplest, baseline operation, the SUBSCRIBE carries no document, and the policy from the presentity is yes/no per subscriber. Both can be made arbitrarily complex with more complex documents. > > I don't want to see the first version of SIMPLE do all of this, I > want the mechanism to be able to expand reasonably. Some of this > is easy (add parameters). I think what you are asking is exactly provided by the proposed mechanisms. -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: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Wednesday, May 16, 2001 6:44 PM > > To: Jonathan Rosenberg > > Cc: 'simple@mailman.dynamicsoft.com' > > Subject: Re: [Simple] authorization for presence > > > > > > One general objective, I believe, has to be that we can present a > > complete solution, i.e., there needs to be a way to do the > > authorization > > in SIP. Otherwise, there's no way to build interoperable > > systems. (This > > doesn't disagree with what Jonathan says, just emphasizes > > that we can't > > stop with the SUBSCRIBE and NOTIFY parts. Thus, I would create an > > explicit AUTH or MODIFYSUBSCRIBERLIST method to handle this.) > > > > Also, as much as possible, naming must be predictable. I'm not too > > thrilled about having to configure the variations of > peter_buddylist@ > > and whatever else is needed. Making up URLs with designated > > names is not > > general enough. There may also be other events that require the same > > mechanism. Is 'watcherinfo' tied to 'presence'? Does every new event > > type need such a pairing? Or can we parameterize this to allow other > > events to re-use this meta-event mechanism? (For example, > it might be > > possible to use something like Event: foo ;watchers or some > > variation on > > this, so that every event is treated as a class with a standard > > associated meta-event.). > > > > Finally, it would be nice if we can avoid special cases. > > Subscribing to > > the event 'watcherinfo' should not be substantially > different than any > > other event. In particular, this must recurse, i.e., subscribing to > > watcherinfo in itself must trigger a notification. > > > > > > Jonathan Rosenberg wrote: > > > > > > Folks, > > > > > > I think its time we begin discussing the second main open > > issue discussed at > > > the last IETF. Specifically, the issue of authorization > of presence > > > subscriptions. > > > > > > The currently defined method makes use of QAUTH. When a > > presence server gets > > > a SUBSCRIBE, it sends a QAUTH to the presentity. If the > > subscription is > > > acceptable, the presentity responds to the QAUTH with a 200 > > OK. The proxy > > > knows to send QAUTH to the presentity because it will > send a methods > > > parameter in a REGISTER, indicating that their contact > > address supports > > > QAUTH. > > > > > > There are several big problems with this: > > > > > > 1. the QAUTH transaction will timeout if the user doesn't > > answer right away. > > > QAUTH, like INVITE, requires human interaction, and so its > > retransmit > > > semantics don't work. > > > > > > 2. If QAUTH forks, we will end up receiving the "best" > > response to the > > > query, which will be a 200 OK if anyone of the forked > > requests results in a > > > 200 OK. As a result, the policy for merging approvals for > > subscriptions is > > > forced to be the same as the forking rules, which is > > probably not what you > > > want. > > > > > > 3. The model assumes that if I can send a registration for > > a presentity, > > > that means I am authorized to make policy decisions about > > subscriptions. > > > That is not necessarily the case. We are really overloading > > register to > > > imply something else. > > > > > > So, the proposal I made to resolve this was the following: > > > > > > 1. We define a new event package, called "watcherinfo". > > This package defines > > > a subscribable entity, which is the current subscription > > state for some > > > presentity. Its a list of those active and pending > > subscriptions for some > > > presentity. When someone subscribes to a presentity, the > > subscription state > > > for that presentity changes. A new pending subscription is > > basically added. > > > Since this state is subscribable, a UA can subscribe to > it, and get > > > notifications when it changes. In this case, the UA is > > notified if someone > > > tries to SUBSCRIBE to the specific presentity. The body of > > the notifications > > > contains the current subscription list for that presentity. > > > > > > 2. We define an authorization document format for presence. > > This is a simple > > > document format which indicates the set of subscriber > > identities that are > > > permitted, or not permitted, to subscribe to a presentity. > > For example: > > > > > > allow: > > > sip:a@b > > > sip:b@c > > > > > > deny: > > > sip:x@y > > > > Nit-picking: I think we've learned from SDP that positional > parsing is > > bad. I would suggest something like: > > > > + sip:a@b > > - sip:x@y > > > > Also, it is not clear whether such a denial is for one subscription > > event or "sticky". > > > > > > > > 3. At any point in time (including after receiving a > > notification that a new > > > subscriber has attempted to subscribe), a UA can push a new > > authorization > > > document to the presence server. The presence server > > applies this policy to > > > the current subscription list, dropping or approving > > subscriptions as > > > needed. This push could happen via HTTP or through SIP, TBD. > > > > > > Here is an example. > > > > > > A subscriber, sip:sally@foo.com, subscribes to some presentity, > > > sip:peter@bar.com. The presence server receives the > > subscription, marks it > > > as pending, and sends a 202. Now, the subscriber list for > > peter has changed; > > > sally@foo.com has been added as pending. peter@bar.com has > > also subcsribed > > > to the subscription state for peter@bar.com. It did this > > previously, by > > > sending a SUBSCRIBE that looks like: > > > > > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > > > Event: watcherinfo > > > > > > Now, since the buddy list for Peter has changed, Peter (and > > any others that > > > have subscribed), get notifications. The NOTIFY might look like: > > > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > > From: sip:peter_buddylist@bar.com > > > To: sip:peter@bar.com > > > Content-type: text/xml+buddies > > > > > > > > > > > > sip:sally@foo.com > > > > > > > > > sip:friend@baz.com > > > > > > > > > > > > Peter's UA gets this NOTIFY, and responds with 200 OK. It > > also queries peter > > > about whether to accept this pending subscription from > > sally@foo.com. Peter > > > is away from his desk. He comes back 10 minutes later, and > > clicks OK. At > > > this point, the UA uploads a new authorization document > > fragment, using SIP, > > > say: > > > > > > SETDATA sip:peter_presence_auth@bar.com SIP/2.0 > > > From: sip:peter@bar.com > > > Content-type: text/authlist > > > > > > accept: > > > sip:sally@foo.com > > > > > > The presence server gets this, and responds with a 200 OK. > > Sally is now > > > approved. > > > > > > The benefits of this approach are: > > > > > > 1. we separate the policies on (1) who finds out about > > subscription changes > > > for a presentity, and (2) who can set policies for > > subscription changes for > > > a presentity. > > > > > > 2. there is no transaction timeout problem > > > > > > 3. policies on merging multiple authorization documents are at the > > > discretion of the presence server. > > > > > > 4. We unify setting of policies asyncrhonously, and > > syncrhonously with the > > > arrival of a subscription. > > > > > > 5. since authorization policies are a document, not a > > protocol, they can be > > > exchanged, stored, and manipulated which is very good. > > > > > > 6. much of this is reusable by other protocols > > > > > > The slides I presented at IETF 50, where I described this > > proposal, can be > > > found at: > > > http://www.jdrosen.net/papers/simple_open_mar01.ppt > > > > > > We need to decide whether to move forward with this > > approach. Comments and > > > criticisms are welcome. > > > > > > 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 > > > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > From jdrosen@dynamicsoft.com Mon May 21 08:53:49 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01003 for ; Mon, 21 May 2001 08:53:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA04712; Mon, 21 May 2001 08:57:37 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 May 2001 08:53:47 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] authorization for presence Date: Mon, 21 May 2001 08:53:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 10650 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: -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Thursday, May 17, 2001 10:49 AM To: 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] authorization for presence >But, what if there is an "AUTH" mechanism that only checks/reads the authorization list >(ACL) and sends a 200-class response if the request is allowed. This can avoid the timeout >problem or forking issues. Yes, but it doesn't "write" the authorization into the access list in the presence agent, which is really the whole problem. Reading it was not the problem. It is worth noting, however, they will probably will want a read mechanism so that people can see what changes they've made. -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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Thursday, May 17, 2001 8:07 AM To: 'Henning G. Schulzrinne'; Jonathan Rosenberg Cc: 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] authorization for presence I'm also in favor of more general mechanisms. One specific that I need is a more rich sense of presence; that is, there might be more than a single "state" enumeration of presence. It might also be that the state variable has a lot of states, but a presentity only allows a particular watcher to see a filtered set. Suppose, for example, I could set presence to in-the-building, in-the-office, out-of-the-building, on-cell-phone, or home. I may want some watchers to get the exact state, others to only get in/out. I don't want to see the first version of SIMPLE do all of this, I want the mechanism to be able to expand reasonably. Some of this is easy (add parameters). > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, May 16, 2001 6:44 PM > To: Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] authorization for presence > > > One general objective, I believe, has to be that we can present a > complete solution, i.e., there needs to be a way to do the > authorization > in SIP. Otherwise, there's no way to build interoperable > systems. (This > doesn't disagree with what Jonathan says, just emphasizes > that we can't > stop with the SUBSCRIBE and NOTIFY parts. Thus, I would create an > explicit AUTH or MODIFYSUBSCRIBERLIST method to handle this.) > > Also, as much as possible, naming must be predictable. I'm not too > thrilled about having to configure the variations of peter_buddylist@ > and whatever else is needed. Making up URLs with designated > names is not > general enough. There may also be other events that require the same > mechanism. Is 'watcherinfo' tied to 'presence'? Does every new event > type need such a pairing? Or can we parameterize this to allow other > events to re-use this meta-event mechanism? (For example, it might be > possible to use something like Event: foo ;watchers or some > variation on > this, so that every event is treated as a class with a standard > associated meta-event.). > > Finally, it would be nice if we can avoid special cases. > Subscribing to > the event 'watcherinfo' should not be substantially different than any > other event. In particular, this must recurse, i.e., subscribing to > watcherinfo in itself must trigger a notification. > > > Jonathan Rosenberg wrote: > > > > Folks, > > > > I think its time we begin discussing the second main open > issue discussed at > > the last IETF. Specifically, the issue of authorization of presence > > subscriptions. > > > > The currently defined method makes use of QAUTH. When a > presence server gets > > a SUBSCRIBE, it sends a QAUTH to the presentity. If the > subscription is > > acceptable, the presentity responds to the QAUTH with a 200 > OK. The proxy > > knows to send QAUTH to the presentity because it will send a methods > > parameter in a REGISTER, indicating that their contact > address supports > > QAUTH. > > > > There are several big problems with this: > > > > 1. the QAUTH transaction will timeout if the user doesn't > answer right away. > > QAUTH, like INVITE, requires human interaction, and so its > retransmit > > semantics don't work. > > > > 2. If QAUTH forks, we will end up receiving the "best" > response to the > > query, which will be a 200 OK if anyone of the forked > requests results in a > > 200 OK. As a result, the policy for merging approvals for > subscriptions is > > forced to be the same as the forking rules, which is > probably not what you > > want. > > > > 3. The model assumes that if I can send a registration for > a presentity, > > that means I am authorized to make policy decisions about > subscriptions. > > That is not necessarily the case. We are really overloading > register to > > imply something else. > > > > So, the proposal I made to resolve this was the following: > > > > 1. We define a new event package, called "watcherinfo". > This package defines > > a subscribable entity, which is the current subscription > state for some > > presentity. Its a list of those active and pending > subscriptions for some > > presentity. When someone subscribes to a presentity, the > subscription state > > for that presentity changes. A new pending subscription is > basically added. > > Since this state is subscribable, a UA can subscribe to it, and get > > notifications when it changes. In this case, the UA is > notified if someone > > tries to SUBSCRIBE to the specific presentity. The body of > the notifications > > contains the current subscription list for that presentity. > > > > 2. We define an authorization document format for presence. > This is a simple > > document format which indicates the set of subscriber > identities that are > > permitted, or not permitted, to subscribe to a presentity. > For example: > > > > allow: > > sip:a@b > > sip:b@c > > > > deny: > > sip:x@y > > Nit-picking: I think we've learned from SDP that positional parsing is > bad. I would suggest something like: > > + sip:a@b > - sip:x@y > > Also, it is not clear whether such a denial is for one subscription > event or "sticky". > > > > > 3. At any point in time (including after receiving a > notification that a new > > subscriber has attempted to subscribe), a UA can push a new > authorization > > document to the presence server. The presence server > applies this policy to > > the current subscription list, dropping or approving > subscriptions as > > needed. This push could happen via HTTP or through SIP, TBD. > > > > Here is an example. > > > > A subscriber, sip:sally@foo.com, subscribes to some presentity, > > sip:peter@bar.com. The presence server receives the > subscription, marks it > > as pending, and sends a 202. Now, the subscriber list for > peter has changed; > > sally@foo.com has been added as pending. peter@bar.com has > also subcsribed > > to the subscription state for peter@bar.com. It did this > previously, by > > sending a SUBSCRIBE that looks like: > > > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > > Event: watcherinfo > > > > Now, since the buddy list for Peter has changed, Peter (and > any others that > > have subscribed), get notifications. The NOTIFY might look like: > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > From: sip:peter_buddylist@bar.com > > To: sip:peter@bar.com > > Content-type: text/xml+buddies > > > > > > > > sip:sally@foo.com > > > > > > sip:friend@baz.com > > > > > > > > Peter's UA gets this NOTIFY, and responds with 200 OK. It > also queries peter > > about whether to accept this pending subscription from > sally@foo.com. Peter > > is away from his desk. He comes back 10 minutes later, and > clicks OK. At > > this point, the UA uploads a new authorization document > fragment, using SIP, > > say: > > > > SETDATA sip:peter_presence_auth@bar.com SIP/2.0 > > From: sip:peter@bar.com > > Content-type: text/authlist > > > > accept: > > sip:sally@foo.com > > > > The presence server gets this, and responds with a 200 OK. > Sally is now > > approved. > > > > The benefits of this approach are: > > > > 1. we separate the policies on (1) who finds out about > subscription changes > > for a presentity, and (2) who can set policies for > subscription changes for > > a presentity. > > > > 2. there is no transaction timeout problem > > > > 3. policies on merging multiple authorization documents are at the > > discretion of the presence server. > > > > 4. We unify setting of policies asyncrhonously, and > syncrhonously with the > > arrival of a subscription. > > > > 5. since authorization policies are a document, not a > protocol, they can be > > exchanged, stored, and manipulated which is very good. > > > > 6. much of this is reusable by other protocols > > > > The slides I presented at IETF 50, where I described this > proposal, can be > > found at: > > http://www.jdrosen.net/papers/simple_open_mar01.ppt > > > > We need to decide whether to move forward with this > approach. Comments and > > criticisms are welcome. > > > > 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 > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ > 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 jdrosen@dynamicsoft.com Mon May 21 08:58:50 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01075 for ; Mon, 21 May 2001 08:58:50 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA04884; Mon, 21 May 2001 09:02:37 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 May 2001 08:58:48 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Simons'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Date: Mon, 21 May 2001 08:58:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2159 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: -----Original Message----- From: David Simons [mailto:dsimons@windows.microsoft.com] Sent: Sunday, May 20, 2001 11:36 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE >In draft-roach-sip-subscribe-notify-03.txt a re-SUBSCRIBE is a SUBSCRIBE request with the >same Call-ID and higher CSeq. The issue we are having is that if a PA losses state, >because deletion after timeout or a crash how does the PA know if a SUBSCRIBE request is a >new SUBSCRIBE request or a re-SUBSCRIBE request? This is significant in that the client >is expecting a NOTIFY with a greater CSeq but the PA will start over. I suppose that one >could just use a time stanp as the CSeq but that won't work if the clocks our >synchronized. The same problem exists for INVITE (look for a pending draft on the subject, out soon). In that case, we have proposed using a timestamp for CSeq. It doesn't require any kind of clock synchronization, though, so I'm not sure what the problem is that you are describing. > >The solution that I'm proposing is that a new SUBSCRIBES should have a CSeq of 1 and then >each re-SUBSCRIBE can have a CSeq greater then one. If a PA receives a SUBSCIBE with a >CSeq greater then 1 and it has no record of the SUBSCRIBE it should return a 481. The >client could then issue a new SUBSCRIBE with a new Call-ID and a CSeq of 1. To date, we've tried to maintain that a re-SUBSCRIBE = SUBSCRIBE, as that is core to the concept of soft-state (which is what this is). In fact, there are recovery scenarios where you REALLY want that property, such as when a backup, without state of a subscription, comes online, and we need to establish subscription state there from a refresh. This would not work with your proposal. -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 From sean.olson@ericsson.com Mon May 21 09:42:34 2001 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 JAA01229 for ; Mon, 21 May 2001 09:42:33 -0400 (EDT) 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 f4LDgVa07844 for ; Mon, 21 May 2001 08:42:31 -0500 (CDT) 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 f4LDgUd10009 for ; Mon, 21 May 2001 08:42:30 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon May 21 08:42:29 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 21 May 2001 08:42:29 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Jonathan Rosenberg'" , "'Henning G. Schulzrinne'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] authorization for presence Date: Mon, 21 May 2001 08:42:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E1FB.DFF6D3B0" Content-Length: 6702 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: 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_01C0E1FB.DFF6D3B0 Content-Type: text/plain; charset="iso-8859-1" >I think that having a standard naming convention here is >probably a good >thing. It also seems clear that this concept does go beyond >just presence. >One way to consider it is that every event package has a >pre-defined set of >subpackages: > >foo.wachters >foo.statistics >foo.policy > >or something like that. > > >I think the mechanism should allow this, but we don't need to >require each >presence server to support these sub-sub packages. So, for example: > >SUBSCRIBE sip:jdrosen.watcherinfo.watcherinfo@dynamicsoft.com SIP/2.0 >Event: presence.subscribers.subscribers > >might generate: > >SIP/2.0 489 Package not Supported > > >This example does make me wonder, though; if the package name is >"subclassed" to indicate watchers, do we need to indicate this >in the R-URI >as well? That is, would the SUBSCRIBE instead look like: > >SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0 >Event: presence.subscribers > >I suspect this is probably more correct and in line with the SUBSCRIBE >architecture. > This is a very nice way to handle this problem. But it raises an interesting question. If I SUBSCRIBE to the Event: presence, does this include all "sub-packages" as well? When a client SUBSCRIBEs to "Event: presence", then receives a NOTIFY with "Event: presence.subscribers", how should it respond, particularly when the client doesn't understand what presence.subcribers means? /sean >-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_01C0E1FB.DFF6D3B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] authorization for presence

>I think that having a standard naming convention = here is
>probably a good
>thing. It also seems clear that this concept = does go beyond
>just presence.
>One way to consider it is that every event = package has a
>pre-defined set of
>subpackages:
>
>foo.wachters
>foo.statistics
>foo.policy
>
>or something like that.
>

<snip>

>
>I think the mechanism should allow this, but we = don't need to
>require each
>presence server to support these sub-sub = packages. So, for example:
>
>SUBSCRIBE = sip:jdrosen.watcherinfo.watcherinfo@dynamicsoft.com SIP/2.0
>Event: presence.subscribers.subscribers
>
>might generate:
>
>SIP/2.0 489 Package not Supported
>
>
>This example does make me wonder, though; if the = package name is
>"subclassed" to indicate watchers, do = we need to indicate this
>in the R-URI
>as well? That is, would the SUBSCRIBE instead = look like:
>
>SUBSCRIBE sip:jdrosen@dynamicsoft.com = SIP/2.0
>Event: presence.subscribers
>
>I suspect this is probably more correct and in = line with the SUBSCRIBE
>architecture.
>

This is a very nice way to handle this problem. But = it raises
an interesting question. If I SUBSCRIBE to the = Event: presence,
does this include all "sub-packages" as = well? When a client SUBSCRIBEs
to "Event: presence", then receives a = NOTIFY with "Event: presence.subscribers",
how should it respond, particularly when the client = doesn't understand what
presence.subcribers means?

/sean


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

------_=_NextPart_001_01C0E1FB.DFF6D3B0-- From jdrosen@dynamicsoft.com Mon May 21 10:03:04 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01337 for ; Mon, 21 May 2001 10:03:04 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA05914; Mon, 21 May 2001 10:06:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 May 2001 10:03:02 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson (EUS)'" , Jonathan Rosenberg , "'Henning G. Schulzrinne'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] authorization for presence Date: Mon, 21 May 2001 10:03:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1524 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: -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Monday, May 21, 2001 9:42 AM To: 'Jonathan Rosenberg'; 'Henning G. Schulzrinne' Cc: 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] authorization for presence >>This example does make me wonder, though; if the package name is >>"subclassed" to indicate watchers, do we need to indicate this >>in the R-URI >>as well? That is, would the SUBSCRIBE instead look like: >> >>SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0 >>Event: presence.subscribers >> >>I suspect this is probably more correct and in line with the SUBSCRIBE >>architecture. >> > >This is a very nice way to handle this problem. But it raises >an interesting question. If I SUBSCRIBE to the Event: presence, >does this include all "sub-packages" as well? No. >When a client SUBSCRIBEs >to "Event: presence", then receives a NOTIFY with "Event: presence.subscribers", >how should it respond, particularly when the client doesn't understand what >presence.subcribers means? Exactly the reason why a subscription to presence does not imply a subscription to its sub-packages. -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 From hgs@cs.columbia.edu Mon May 21 11:35:15 2001 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 LAA01613 for ; Mon, 21 May 2001 11:35:14 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA23766; Mon, 21 May 2001 11:35:14 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA02036; Mon, 21 May 2001 11:35:08 -0400 (EDT) Message-ID: <3B0960D7.795EBC50@cs.columbia.edu> Date: Mon, 21 May 2001 11:39:19 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] authorization for presence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1196 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: > Just so I am clear, are you saying that we need an entire solution that is > completely SIP based, or just an entire solution? I agree with the latter, > and that was indeed the point of the proposal. I am not yet completely > convinced that it is all SIP, and less certain that uploading of > authorization documents is best done by a new AUTH method or something > similar. I would prefer that there is a SIP solution, as otherwise we create naming problems, among other things. (Also, as a secondary problem, UDP-only embedded systems are then no longer feasible.) > SUBSCRIBE sip:jdrosen.watcherinfo.watcherinfo@dynamicsoft.com SIP/2.0 > Event: presence.subscribers.subscribers > > might generate: > > SIP/2.0 489 Package not Supported > > This example does make me wonder, though; if the package name is > "subclassed" to indicate watchers, do we need to indicate this in the R-URI > as well? That is, would the SUBSCRIBE instead look like: > > SUBSCRIBE sip:jdrosen@dynamicsoft.com SIP/2.0 > Event: presence.subscribers > > I suspect this is probably more correct and in line with the SUBSCRIBE > architecture. Definitely the second one. This follows the object/properties model. From adam.roach@ericsson.com Tue May 22 09:05:37 2001 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 JAA04959 for ; Tue, 22 May 2001 09:05:37 -0400 (EDT) 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 f4MD5Ya29179; Tue, 22 May 2001 08:05:34 -0500 (CDT) 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 f4MD5YD28170; Tue, 22 May 2001 08:05:34 -0500 (CDT) Received: from pc050163 (pc4218.es.eu.ericsson.se [159.107.4.218]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id IAA14287; Tue, 22 May 2001 08:05:32 -0500 (CDT) Reply-To: From: "Adam Roach" To: "'Jonathan Rosenberg'" , "'Henning G. Schulzrinne'" Cc: Subject: RE: [Simple] authorization for presence Date: Tue, 22 May 2001 08:07:41 -0500 Message-ID: <000301c0e2c0$2ef0b8e0$da046b9f@pc050163.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 V4.72.3612.1700 Content-Length: 894 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: Jonathan Rosenberg writes: > I think that having a standard naming convention here is > probably a good > thing. It also seems clear that this concept does go beyond > just presence. > One way to consider it is that every event package has a > pre-defined set of > subpackages: > > foo.watchers > foo.statistics > foo.policy > > or something like that. I like this idea. Should I be including this sort of thing in the SUB/NOT draft (since it ostensibly applies to all events), or should we leave this to a different draft or set of drafts? It would seem most appropriate to allow this sort of thing to be extensible (e.g. float the idea of generic subpackages in the base draft), and then let other drafts define them. In other words, a new draft would define the "watchers" subpackage which can be applied to any arbitrary package (even other subpackages). That's rather cool... /a From jdrosen@dynamicsoft.com Tue May 22 11:31:07 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05379 for ; Tue, 22 May 2001 11:31:07 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA21518; Tue, 22 May 2001 11:34:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 May 2001 11:31:01 -0400 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , "'Henning G. Schulzrinne'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Tue, 22 May 2001 11:31:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1664 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: > -----Original Message----- > From: Adam Roach [mailto:adam.roach@ericsson.com] > Sent: Tuesday, May 22, 2001 9:08 AM > To: 'Jonathan Rosenberg'; 'Henning G. Schulzrinne' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] authorization for presence > > > Jonathan Rosenberg writes: > > > I think that having a standard naming convention here is > > probably a good > > thing. It also seems clear that this concept does go beyond > > just presence. > > One way to consider it is that every event package has a > > pre-defined set of > > subpackages: > > > > foo.watchers > > foo.statistics > > foo.policy > > > > or something like that. > > I like this idea. Should I be including this sort of thing in the > SUB/NOT draft (since it ostensibly applies to all events), or > should we leave this to a different draft or set of drafts? I think the notion of a sub-package should be defined in SUB/NOT. > > It would seem most appropriate to allow this sort of thing to > be extensible (e.g. float the idea of generic subpackages in > the base draft), and then let other drafts define them. In other > words, a new draft would define the "watchers" subpackage > which can be applied to any arbitrary package (even other > subpackages). That's rather cool... Yup. I agree 100%. -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 From bcampbell@dynamicsoft.com Tue May 22 13:31:21 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05759 for ; Tue, 22 May 2001 13:31:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA23416; Tue, 22 May 2001 13:35:10 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 May 2001 13:31:19 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F1EF@DYN-TX-EXCH-001.dynamicsoft.com> From: Ben Campbell To: "'adam.roach@ericsson.com'" , Jonathan Rosenberg Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] authorization for presence Date: Tue, 22 May 2001 13:31:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1933 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: Hi Adam and Jonathan, Are we suggesting that _all_ packages would share the sub-package? In this case, _all_ packages would have a watchers sub-package? It seems that might unnecessarily encumber a package that did not actually need the sub-package, and therefore sub-packages would be limited to those with universal applicability. If you mean the sub-package is a generic building block that any package could incorporate if needed, then I agree. I gather Adam is suggesting the latter, but Jonathan's original note seems to suggest the former. > -----Original Message----- > From: Adam Roach [mailto:adam.roach@ericsson.com] > Sent: Tuesday, May 22, 2001 8:08 AM > To: 'Jonathan Rosenberg'; 'Henning G. Schulzrinne' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] authorization for presence > > > Jonathan Rosenberg writes: > > > I think that having a standard naming convention here is > > probably a good > > thing. It also seems clear that this concept does go beyond > > just presence. > > One way to consider it is that every event package has a > > pre-defined set of > > subpackages: > > > > foo.watchers > > foo.statistics > > foo.policy > > > > or something like that. > > I like this idea. Should I be including this sort of thing in the > SUB/NOT draft (since it ostensibly applies to all events), or > should we leave this to a different draft or set of drafts? > > It would seem most appropriate to allow this sort of thing to > be extensible (e.g. float the idea of generic subpackages in > the base draft), and then let other drafts define them. In other > words, a new draft would define the "watchers" subpackage > which can be applied to any arbitrary package (even other > subpackages). That's rather cool... > > /a > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From dsimons@windows.microsoft.com Tue May 22 16:14:28 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA06207 for ; Tue, 22 May 2001 16:14:26 -0400 (EDT) Received: from 157.54.1.52 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 22 May 2001 13:14:17 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 22 May 2001 13:14:16 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 22 May 2001 13:14:13 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 22 May 2001 13:13:45 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E2FB.B3F055B0" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Date: Tue, 22 May 2001 13:13:44 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1111F4C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Thread-Index: AcDh9bvqav87gohGTHSMR8/NX4pzwgA5ff6gAAf62dA= From: "David Simons" To: X-OriginalArrivalTime: 22 May 2001 20:13:45.0257 (UTC) FILETIME=[B418D990:01C0E2FB] Content-Length: 19237 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E2FB.B3F055B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Monday, May 21, 2001 5:59 AM To: David Simons; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE =20 =20 =20 =20 -----Original Message----- From: David Simons [mailto:dsimons@windows.microsoft.com] Sent: Sunday, May 20, 2001 11:36 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE =20 =20 >In draft-roach-sip-subscribe-notify-03.txt a re-SUBSCRIBE is a SUBSCRIBE request with the=20 >same Call-ID and higher CSeq. The issue we are having is that if a PA losses state,=20 >because deletion after timeout or a crash how does the PA know if a SUBSCRIBE request is a=20 >new SUBSCRIBE request or a re-SUBSCRIBE request? This is significant in that the client=20 >is expecting a NOTIFY with a greater CSeq but the PA will start over. I suppose that one=20 >could just use a time stanp as the CSeq but that won't work if the clocks our=20 >synchronized.=20 =20 The same problem exists for INVITE (look for a pending draft on the subject, out soon). In that case, we have proposed using a timestamp for CSeq. It doesn't require any kind of clock synchronization, though, so I'm not sure what the problem is that you are describing. =20 [David Simons] I would like to point out that time stamps for anything but seeding a CSeq are a clear violation of RFC2543. The RFC clearly states that CSeq's are consecutive increasing integers that don't wrap. Time stamps would increase my jumps greater then 1. =20 =20 =20 > >The solution that I'm proposing is that a new SUBSCRIBES should have a CSeq of 1 and then=20 >each re-SUBSCRIBE can have a CSeq greater then one. If a PA receives a SUBSCIBE with a=20 >CSeq greater then 1 and it has no record of the SUBSCRIBE it should return a 481. The=20 >client could then issue a new SUBSCRIBE with a new Call-ID and a CSeq of 1. =20 =20 To date, we've tried to maintain that a re-SUBSCRIBE =3D SUBSCRIBE, as that is core to the concept of soft-state (which is what this is). In fact, there are recovery scenarios where you REALLY want that property, such as when a backup, without state of a subscription, comes online, and we need to establish subscription state there from a refresh. This would not work with your proposal. =20 [David Simons] The problem with making re-SUBSCIRGBE =3D SUBSCRIBE is = that you may be trying to reestablish the state of a session a priori. One side has a complete image of the session state and the other has none. It is clearly stated in draft-roach-sip-subscribe-notify-03.txt that it is expected that notifier users a different CSeq space then the subscriber. So we really can't require that that the CSeq of SUBSCRIBE be related to the CSeq of NOTIFY. There needs to be a mechanism by which the notifier can reset the state of the transaction. I believe the 481 would accomplish this. =20 =20 -Jonathan R. =20 =20 --- 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 =20 =20 =20 Regards, =20 David J. Simons SDE Lead Window RTC ------_=_NextPart_001_01C0E2FB.B3F055B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, May 21, 2001 5:59 AM
To: David Simons; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Difference between a SUBSCRIBE and a = re-SUBSCRIBE

 

 

 

 

-----Original Message-----

From: David Simons [mailto:dsimons@windows.microsoft.com]

Sent: Sunday, May 20, 2001 = 11:36 PM

To: = simple@mailman.dynamicsoft.com

Subject: [Simple] Difference between a = SUBSCRIBE and a re-SUBSCRIBE

 

 

>In = draft-roach-sip-subscribe-notify-03.txt a re-SUBSCRIBE is a SUBSCRIBE

request with the

>same Call-ID and higher CSeq.  The = issue we are having is that if a PA

losses state,

>because deletion after timeout or a crash = how does the PA know if a

SUBSCRIBE request is a

>new SUBSCRIBE request or a re-SUBSCRIBE request?  This is significant in

that the client

>is expecting a NOTIFY with a greater CSeq = but the PA will start over.  I

suppose that one

>could just use a time stanp as the CSeq = but that won't work if the clocks

our

>synchronized.

 

The same problem exists for INVITE (look for = a pending draft on the subject,

out soon). In that case, we have proposed = using a timestamp for CSeq. It

doesn't require any kind of clock = synchronization, though, so I'm not sure

what the problem is that you are = describing.

 

[David Simons] I would like to = point out that time stamps for anything but seeding a CSeq are a clear violation = of RFC2543.  The RFC clearly states that CSeq's are consecutive = increasing integers that don't wrap.  Time stamps would increase my jumps = greater then 1. 

 

 

>

>The solution that I'm proposing is that a = new SUBSCRIBES should have a CSeq

of 1 and then

>each re-SUBSCRIBE can have a CSeq greater = then one.  If a PA receives a

SUBSCIBE with a

>CSeq greater then 1 and it has no record = of the SUBSCRIBE it should return

a 481.  The

>client could then issue a new SUBSCRIBE = with a new Call-ID and a CSeq of 1.

 

 

To date, we've tried to maintain that a = re-SUBSCRIBE =3D SUBSCRIBE, as that is

core to the concept of soft-state (which is = what this is). In fact, there

are recovery scenarios where you REALLY want = that property, such as when a

backup, without state of a subscription, = comes online, and we need to

establish subscription state there from a = refresh. This would not work with

your proposal.

 

[David Simons] The problem with = making re-SUBSCIRGBE =3D SUBSCRIBE is that you may be trying to reestablish the = state of a session a priori. One side has a complete image of the session state = and the other has none.  It is clearly stated in draft-roach-sip-subscribe-notify-03.txt that it is expected that = notifier users a different CSeq space then the subscriber.  So we really = can’t require that that the CSeq of SUBSCRIBE be related to the CSeq of = NOTIFY.  There needs to be a mechanism by which the notifier can reset the state = of the transaction.  I believe the 481 would accomplish = this.

 

 

-Jonathan R.

 

 

---

Jonathan D. Rosenberg, Ph.D.           &n= bsp;    72 Eagle Rock Ave.

Chief Scientist          &nbs= p;            = ;      First Floor

dynamicsoft      = ;            =             &= nbsp;  East Hanover, NJ 07936

jdrosen@dynamicsoft.com    = ;            =      FAX:   (973) 952-5050

http://www.jdrosen.net    =             &= nbsp;     PHONE: (973) 952-5000

http://www.dynamicsoft.com

 

 

Regards,

 

David J. Simons

SDE Lead

Window RTC

=00 ------_=_NextPart_001_01C0E2FB.B3F055B0-- From jdrosen@dynamicsoft.com Tue May 22 21:11:37 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00783 for ; Tue, 22 May 2001 21:11:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA00277; Tue, 22 May 2001 21:15:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 May 2001 21:11:35 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Simons'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Date: Tue, 22 May 2001 21:11:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 3474 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: -----Original Message----- From: David Simons [mailto:dsimons@windows.microsoft.com] Sent: Tuesday, May 22, 2001 4:14 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE >>In draft-roach-sip-subscribe-notify-03.txt a re-SUBSCRIBE is a SUBSCRIBE >request with the >>same Call-ID and higher CSeq. The issue we are having is that if a PA >losses state, >>because deletion after timeout or a crash how does the PA know if a >SUBSCRIBE request is a >>new SUBSCRIBE request or a re-SUBSCRIBE request? This is significant in >that the client >>is expecting a NOTIFY with a greater CSeq but the PA will start over. I >suppose that one >>could just use a time stanp as the CSeq but that won't work if the clocks >our >>synchronized. > >The same problem exists for INVITE (look for a pending draft on the subject, >out soon). In that case, we have proposed using a timestamp for CSeq. It >doesn't require any kind of clock synchronization, though, so I'm not sure >what the problem is that you are describing. > >[David Simons] I would like to point out that time stamps for anything but seeding a CSeq >are a clear violation of RFC2543. The RFC clearly states that CSeq's are consecutive >increasing integers that don't wrap. Time stamps would increase my jumps greater then 1. Right. I was only talking about the initial CSeq value. >> >>The solution that I'm proposing is that a new SUBSCRIBES should have a CSeq >of 1 and then >>each re-SUBSCRIBE can have a CSeq greater then one. If a PA receives a >SUBSCIBE with a >>CSeq greater then 1 and it has no record of the SUBSCRIBE it should return >a 481. The >>client could then issue a new SUBSCRIBE with a new Call-ID and a CSeq of 1. > > >To date, we've tried to maintain that a re-SUBSCRIBE = SUBSCRIBE, as that is >core to the concept of soft-state (which is what this is). In fact, there >are recovery scenarios where you REALLY want that property, such as when a >backup, without state of a subscription, comes online, and we need to >establish subscription state there from a refresh. This would not work with >your proposal. > >[David Simons] The problem with making re-SUBSCIRGBE = SUBSCRIBE is that you may be trying >to reestablish the state of a session a priori. One side has a complete image of the >session state and the other has none. It is clearly stated in draft-roach-sip-subscribe- >notify-03.txt that it is expected that notifier users a different CSeq space then the >subscriber. I don't follow. I don't see what the CSeq space in the reverse direction has to do with re-establishing a subscription, where the subscriber thinks its new, and the server thinks it exists. >So we really can't require that that the CSeq of SUBSCRIBE be related to the >CSeq of NOTIFY. I wasn't proposing that. >There needs to be a mechanism by which the notifier can reset the state >of the transaction. I believe the 481 would accomplish this. A 481 to a NOTIFY does delete the subscription, but I still don't see what this has to do with re-SUBSCRIBE = 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 From jdrosen@dynamicsoft.com Tue May 22 21:14:29 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00816 for ; Tue, 22 May 2001 21:14:29 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA00347; Tue, 22 May 2001 21:18:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 22 May 2001 21:14:28 -0400 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , "'adam.roach@ericsson.com'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] authorization for presence Date: Tue, 22 May 2001 21:14:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2907 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: > -----Original Message----- > From: Ben Campbell > Sent: Tuesday, May 22, 2001 1:31 PM > To: 'adam.roach@ericsson.com'; Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] authorization for presence > > > Hi Adam and Jonathan, > > Are we suggesting that _all_ packages would share the > sub-package? In this case, _all_ packages would have a > watchers sub-package? It seems that might unnecessarily > encumber a package that did not actually need the > sub-package, and therefore sub-packages would be limited to > those with universal applicability. > > If you mean the sub-package is a generic building block that > any package could incorporate if needed, then I agree. I > gather Adam is suggesting the latter, but Jonathan's original > note seems to suggest the former. No, I wasn't suggesting anything along those lines. All packages could have a watchers sub-package (and indeed, the watchers sub-package would allow any package to use it), but it might never be used, implemented or invoked if its not 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 > > > -----Original Message----- > > From: Adam Roach [mailto:adam.roach@ericsson.com] > > Sent: Tuesday, May 22, 2001 8:08 AM > > To: 'Jonathan Rosenberg'; 'Henning G. Schulzrinne' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] authorization for presence > > > > > > Jonathan Rosenberg writes: > > > > > I think that having a standard naming convention here is > > > probably a good > > > thing. It also seems clear that this concept does go beyond > > > just presence. > > > One way to consider it is that every event package has a > > > pre-defined set of > > > subpackages: > > > > > > foo.watchers > > > foo.statistics > > > foo.policy > > > > > > or something like that. > > > > I like this idea. Should I be including this sort of thing in the > > SUB/NOT draft (since it ostensibly applies to all events), or > > should we leave this to a different draft or set of drafts? > > > > It would seem most appropriate to allow this sort of thing to > > be extensible (e.g. float the idea of generic subpackages in > > the base draft), and then let other drafts define them. In other > > words, a new draft would define the "watchers" subpackage > > which can be applied to any arbitrary package (even other > > subpackages). That's rather cool... > > > > /a > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > From ffo@ifrance.com Wed May 23 11:56:54 2001 Received: from lh10.opsion.fr (lh10.opsion.fr [212.73.208.236]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA03106 for ; Wed, 23 May 2001 11:56:48 -0400 (EDT) Received: from 12.32.57.153 [12.32.57.153] by lh10.opsion.fr; Wed, 23 May 2001 15:55:48 GMT Message-ID: <000a01c0e3a1$13d638a0$0805260a@VERSADA.centerbeam.com> Reply-To: =?iso-8859-1?Q?Fran=E7ois-Fr=E9d=E9ric_Ozog?= From: =?iso-8859-1?Q?Fran=E7ois-Fr=E9d=E9ric_Ozog?= To: Date: Wed, 23 May 2001 08:57:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0E366.66D86180" 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 Content-Length: 5531 Subject: [Simple] 3GPP implied 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: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0E366.66D86180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 3GPP defines the mechanism I reproduce below. Are there such provisions in SIMPLE? A register is sent from a device to the relevant proxy (P-SCSF in 3GPP): REGISTER sip:registrar.home1.net SIP/2.0 Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] From: To: Contact: Call-ID: 123456789@[5555::aaa:bbb:ccc:ddd] CSeq: 1 REGISTER Expires: 7200 Allow-Events: org.3gpp.nwinitdereg Content-Length: 0 Allow-Events is used to implicitly subscribe to the event = "org.3gpp.nwinitdereg". The P-CSCF will remove this field from the = REGISTER request before sending it on to the home network. The P-CSCF sends a first NOTIFY request to the UE in order to confirm = the successful (implicit) subscription to the event = "org.3gpp.nwinitdereg". A new Call-ID (here: = ab01cd23de45@pcscf1.visited1.net) is generated. NOTIFY sip:[5555::aaa:bbb:ccc:ddd] SIP/2.0 Via: SIP/2.0/UDP pcscf1.visited1.net From: To: Call-ID: ab01cd23de45@pcscf1.visited1.net CSeq: 1 NOTIFY Expires: 7200 Event: org.3gpp.nwinitdereg Content-Length: 0 ------=_NextPart_000_0007_01C0E366.66D86180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
3GPP defines the mechanism I = reproduce=20 below.
Are there such provisions in=20 SIMPLE?
 
 
A register is sent from a = device to the=20 relevant proxy (P-SCSF in 3GPP):
 
    REGISTER=20 sip:registrar.home1.net SIP/2.0
    Via: = SIP/2.0/UDP=20 [5555::aaa:bbb:ccc:ddd]
    From:=20 <sip:user1@home1.net>
    To:=20 <sip:user1@home1.net>
    Contact:=20 <Sip:[5555::aaa:bbb:ccc:ddd]>
    Call-ID:=20 123456789@[5555::aaa:bbb:ccc:ddd]
    CSeq: 1=20 REGISTER
    Expires:=20 7200
    = Allow-Events:=20 org.3gpp.nwinitdereg
    = Content-Length:=20 0
 
Allow-Events is used to implicitly subscribe to the event=20 "org.3gpp.nwinitdereg". The P-CSCF will remove this field from the = REGISTER=20 request before sending it on to the home network.
 
 
The P-CSCF sends a first NOTIFY request to the UE in order to = confirm the=20 successful (implicit) subscription to the event "org.3gpp.nwinitdereg". = A new=20 Call-ID (here: ab01cd23de45@pcscf1.visited1.net) is = generated.
 
 
    NOTIFY=20 sip:[5555::aaa:bbb:ccc:ddd] SIP/2.0
    Via: = SIP/2.0/UDP=20 pcscf1.visited1.net
    From:=20 <sip:pcscf1.visited1.net>
    To:=20 <sip:sip:user1@home1.net>
    Call-ID:=20 ab01cd23de45@pcscf1.visited1.net
    CSeq: 1=20 NOTIFY
    Expires:=20 7200
    Event:=20 org.3gpp.nwinitdereg
    Content-Length: 0
 ------=_NextPart_000_0007_01C0E366.66D86180-- ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif From jdrosen@dynamicsoft.com Wed May 23 15:32:01 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03742 for ; Wed, 23 May 2001 15:32:01 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA09945; Wed, 23 May 2001 15:35:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 23 May 2001 15:31:55 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Simons'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Date: Wed, 23 May 2001 15:31:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 7853 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: > -----Original Message----- > From: David Simons [mailto:dsimons@windows.microsoft.com] > Sent: Wednesday, May 23, 2001 11:33 AM > To: Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Difference between a SUBSCRIBE and a > re-SUBSCRIBE > > > When a subscribe server losses session state, i.e. from server failure > or subscription timeout, and then it receives a re-SUBSCRIBE the > subscriber has session state and is simply updating the > session whereas, > the server has no session state and sees the SUBSCRIBE as a new call. > The most relevant issue would be with NOTIFY CSeq and tag. But, there > may be other implementation specific state issues. There is also record-route, but bis specifies that proxies record-route requests even if they have a Route header. The reason is to allow reconstruction of state. > The server would > start the NOTIFY CSeq at its normal starting point and the > client would > be expecting a CSeq greater then the CSeq of the last NOTIFY it > received. If the server sends notifies with a lower CSeq then the > client expects those notifies will be discarded, thus > information lost. > We can try to patch this issue with things like seeding CSeq with a > timestamp but we could still be out of sync. How? > I believe that > it is much > better to simply start the session over. As I read RFC-2543 > status code > 481 would be the correct way for a subscribe server to > indicated that it > doesn't have session state and needs to start over. The > client can then > reset its session state and generate a new Call-ID. 481 would indeed accomplish this, but you would need to specify that for SUBSCRIBE, a client SHOULD create a brand new subscription. I still think its easier just to start your CSeq using the clock, and then you don't need any additional work on the client or server. So, the question is if we ALSO want to specify that a client should retry the SUBSCRIBE on 481. Its not clear that thats always the right behavior. -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, May 23, 2001 5:52 AM > To: David Simons > Subject: RE: [Simple] Difference between a SUBSCRIBE and a > re-SUBSCRIBE > > I'm still not following you here... I don't see why you want > to generate > 481 > in response 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 > > > > -----Original Message----- > > From: David Simons [mailto:dsimons@windows.microsoft.com] > > Sent: Tuesday, May 22, 2001 9:57 PM > > To: Jonathan Rosenberg > > Subject: RE: [Simple] Difference between a SUBSCRIBE and a > > re-SUBSCRIBE > > > > > > It was my thinking that the 481 be sent in reply to the SUBSCRIBE. > > > > David J. Simons > > Development Lead > > Microsoft Windows RTC > > > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, May 22, 2001 6:12 PM > > To: David Simons; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Difference between a SUBSCRIBE and a > > re-SUBSCRIBE > > > > > > > > > > -----Original Message----- > > From: David Simons [mailto:dsimons@windows.microsoft.com] > > Sent: Tuesday, May 22, 2001 4:14 PM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE > > > > >>In draft-roach-sip-subscribe-notify-03.txt a re-SUBSCRIBE is a > > SUBSCRIBE > > >request with the > > >>same Call-ID and higher CSeq. The issue we are having is > > that if a PA > > >losses state, > > >>because deletion after timeout or a crash how does the PA > know if a > > >SUBSCRIBE request is a > > >>new SUBSCRIBE request or a re-SUBSCRIBE request? This is > > significant > > in > > >that the client > > >>is expecting a NOTIFY with a greater CSeq but the PA will > > start over. > > I > > >suppose that one > > >>could just use a time stanp as the CSeq but that won't work if the > > clocks > > >our > > >>synchronized. > > > > > >The same problem exists for INVITE (look for a pending draft on the > > subject, > > >out soon). In that case, we have proposed using a > timestamp for CSeq. > > It > > >doesn't require any kind of clock synchronization, though, > so I'm not > > sure > > >what the problem is that you are describing. > > > > > >[David Simons] I would like to point out that time stamps > > for anything > > but > > seeding a CSeq > > >are a clear violation of RFC2543. The RFC clearly states > that CSeq's > > are > > consecutive > > >increasing integers that don't wrap. Time stamps would increase my > > jumps > > greater then 1. > > > > Right. I was only talking about the initial CSeq value. > > > > > > >> > > >>The solution that I'm proposing is that a new SUBSCRIBES > > should have a > > CSeq > > >of 1 and then > > >>each re-SUBSCRIBE can have a CSeq greater then one. If a > > PA receives > > a > > >SUBSCIBE with a > > >>CSeq greater then 1 and it has no record of the SUBSCRIBE > it should > > return > > >a 481. The > > >>client could then issue a new SUBSCRIBE with a new Call-ID > > and a CSeq > > of > > 1. > > > > > > > > >To date, we've tried to maintain that a re-SUBSCRIBE = > SUBSCRIBE, as > > that > > is > > >core to the concept of soft-state (which is what this is). In fact, > > there > > >are recovery scenarios where you REALLY want that property, such as > > when a > > >backup, without state of a subscription, comes online, and > we need to > > >establish subscription state there from a refresh. This > > would not work > > with > > >your proposal. > > > > > >[David Simons] The problem with making re-SUBSCIRGBE = SUBSCRIBE is > > that > > you may be trying > > >to reestablish the state of a session a priori. One side has > > a complete > > image of the > > >session state and the other has none. It is clearly stated in > > draft-roach-sip-subscribe- > > >notify-03.txt that it is expected that notifier users a > > different CSeq > > space then the > > >subscriber. > > > > I don't follow. I don't see what the CSeq space in the > > reverse direction > > has > > to do with re-establishing a subscription, where the > subscriber thinks > > its > > new, and the server thinks it exists. > > > > >So we really can't require that that the CSeq of SUBSCRIBE > be related > > to > > the > > >CSeq of NOTIFY. > > > > I wasn't proposing that. > > > > > > >There needs to be a mechanism by which the notifier can > > reset the state > > > > >of the transaction. I believe the 481 would accomplish this. > > > > A 481 to a NOTIFY does delete the subscription, but I still > don't see > > what > > this has to do with re-SUBSCRIBE = 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 > > > From dsimons@windows.microsoft.com Wed May 23 21:54:35 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id VAA04748 for ; Wed, 23 May 2001 21:54:34 -0400 (EDT) Received: from 157.54.9.104 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 23 May 2001 08:34:37 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 23 May 2001 08:34:02 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 23 May 2001 08:33:58 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 23 May 2001 08:33:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Date: Wed, 23 May 2001 08:33:27 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC146365D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Thread-Index: AcDjhyDshdjn+nUSRbiD86pX1ypJhAAEd0mQ From: "David Simons" To: "Jonathan Rosenberg" Cc: X-OriginalArrivalTime: 23 May 2001 15:33:28.0329 (UTC) FILETIME=[B6D70790:01C0E39D] Content-Length: 6481 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id VAA04748 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: When a subscribe server losses session state, i.e. from server failure or subscription timeout, and then it receives a re-SUBSCRIBE the subscriber has session state and is simply updating the session whereas, the server has no session state and sees the SUBSCRIBE as a new call. The most relevant issue would be with NOTIFY CSeq and tag. But, there may be other implementation specific state issues. The server would start the NOTIFY CSeq at its normal starting point and the client would be expecting a CSeq greater then the CSeq of the last NOTIFY it received. If the server sends notifies with a lower CSeq then the client expects those notifies will be discarded, thus information lost. We can try to patch this issue with things like seeding CSeq with a timestamp but we could still be out of sync. I believe that it is much better to simply start the session over. As I read RFC-2543 status code 481 would be the correct way for a subscribe server to indicated that it doesn't have session state and needs to start over. The client can then reset its session state and generate a new Call-ID. The next best proposal would be to have the NOTIFY CSeq always start as an increment to the SUBSCRIBE CSeq. This doesn't strictly follow RFC2543 because the SUBSCRIBE CSeq wouldn't be contiguous. But, it does keep the CSeq counts up-to-date. Regards, David J. Simons Development Lead Microsoft Windows RTC -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, May 23, 2001 5:52 AM To: David Simons Subject: RE: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE I'm still not following you here... I don't see why you want to generate 481 in response 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 > -----Original Message----- > From: David Simons [mailto:dsimons@windows.microsoft.com] > Sent: Tuesday, May 22, 2001 9:57 PM > To: Jonathan Rosenberg > Subject: RE: [Simple] Difference between a SUBSCRIBE and a > re-SUBSCRIBE > > > It was my thinking that the 481 be sent in reply to the SUBSCRIBE. > > David J. Simons > Development Lead > Microsoft Windows RTC > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, May 22, 2001 6:12 PM > To: David Simons; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Difference between a SUBSCRIBE and a > re-SUBSCRIBE > > > > > -----Original Message----- > From: David Simons [mailto:dsimons@windows.microsoft.com] > Sent: Tuesday, May 22, 2001 4:14 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE > > >>In draft-roach-sip-subscribe-notify-03.txt a re-SUBSCRIBE is a > SUBSCRIBE > >request with the > >>same Call-ID and higher CSeq. The issue we are having is > that if a PA > >losses state, > >>because deletion after timeout or a crash how does the PA know if a > >SUBSCRIBE request is a > >>new SUBSCRIBE request or a re-SUBSCRIBE request? This is > significant > in > >that the client > >>is expecting a NOTIFY with a greater CSeq but the PA will > start over. > I > >suppose that one > >>could just use a time stanp as the CSeq but that won't work if the > clocks > >our > >>synchronized. > > > >The same problem exists for INVITE (look for a pending draft on the > subject, > >out soon). In that case, we have proposed using a timestamp for CSeq. > It > >doesn't require any kind of clock synchronization, though, so I'm not > sure > >what the problem is that you are describing. > > > >[David Simons] I would like to point out that time stamps > for anything > but > seeding a CSeq > >are a clear violation of RFC2543. The RFC clearly states that CSeq's > are > consecutive > >increasing integers that don't wrap. Time stamps would increase my > jumps > greater then 1. > > Right. I was only talking about the initial CSeq value. > > > >> > >>The solution that I'm proposing is that a new SUBSCRIBES > should have a > CSeq > >of 1 and then > >>each re-SUBSCRIBE can have a CSeq greater then one. If a > PA receives > a > >SUBSCIBE with a > >>CSeq greater then 1 and it has no record of the SUBSCRIBE it should > return > >a 481. The > >>client could then issue a new SUBSCRIBE with a new Call-ID > and a CSeq > of > 1. > > > > > >To date, we've tried to maintain that a re-SUBSCRIBE = SUBSCRIBE, as > that > is > >core to the concept of soft-state (which is what this is). In fact, > there > >are recovery scenarios where you REALLY want that property, such as > when a > >backup, without state of a subscription, comes online, and we need to > >establish subscription state there from a refresh. This > would not work > with > >your proposal. > > > >[David Simons] The problem with making re-SUBSCIRGBE = SUBSCRIBE is > that > you may be trying > >to reestablish the state of a session a priori. One side has > a complete > image of the > >session state and the other has none. It is clearly stated in > draft-roach-sip-subscribe- > >notify-03.txt that it is expected that notifier users a > different CSeq > space then the > >subscriber. > > I don't follow. I don't see what the CSeq space in the > reverse direction > has > to do with re-establishing a subscription, where the subscriber thinks > its > new, and the server thinks it exists. > > >So we really can't require that that the CSeq of SUBSCRIBE be related > to > the > >CSeq of NOTIFY. > > I wasn't proposing that. > > > >There needs to be a mechanism by which the notifier can > reset the state > > >of the transaction. I believe the 481 would accomplish this. > > A 481 to a NOTIFY does delete the subscription, but I still don't see > what > this has to do with re-SUBSCRIBE = 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 > From jdrosen@dynamicsoft.com Thu May 24 01:02:36 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05258 for ; Thu, 24 May 2001 01:02:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14715; Thu, 24 May 2001 01:06:25 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 May 2001 01:02:34 -0400 Message-ID: From: Jonathan Rosenberg To: =?iso-8859-1?Q?=27Fran=E7ois-Fr=E9d=E9ric_Ozog=27?= , simple@mailman.dynamicsoft.com Subject: RE: [Simple] 3GPP implied SUBSCRIBE Date: Thu, 24 May 2001 01:02:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2112 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id BAA05258 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: -----Original Message----- From: François-Frédéric Ozog [mailto:ffo@ifrance.com] Sent: Wednesday, May 23, 2001 11:58 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] 3GPP implied SUBSCRIBE >3GPP defines the mechanism I reproduce below. >Are there such provisions in SIMPLE? > > >A register is sent from a device to the relevant proxy (P-SCSF in 3GPP): > > REGISTER sip:registrar.home1.net SIP/2.0 > Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] > From: > To: > Contact: > Call-ID: 123456789@[5555::aaa:bbb:ccc:ddd] > CSeq: 1 REGISTER > Expires: 7200 > Allow-Events: org.3gpp.nwinitdereg > Content-Length: 0 > >Allow-Events is used to implicitly subscribe to the event "org.3gpp.nwinitdereg". The P- >CSCF will remove this field from the REGISTER request before sending it on to the home >network. Neither of these is standardized behavior. The semantics of Allow-Events has absolutely nothing to do with implicit subscriptions. > > >The P-CSCF sends a first NOTIFY request to the UE in order to confirm the successful >(implicit) subscription to the event "org.3gpp.nwinitdereg". A new Call-ID (here: >ab01cd23de45@pcscf1.visited1.net) is generated. > > > NOTIFY sip:[5555::aaa:bbb:ccc:ddd] SIP/2.0 > Via: SIP/2.0/UDP pcscf1.visited1.net > From: > To: > Call-ID: ab01cd23de45@pcscf1.visited1.net > CSeq: 1 NOTIFY > Expires: 7200 > Event: org.3gpp.nwinitdereg > Content-Length: 0 Besides the fact that this is a new, undefined event package, notifications in response to a SUBSCRIBE (although there wasn't one) carry the same Call-ID as the 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 From adam.roach@ericsson.com Thu May 24 04:50:32 2001 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 EAA05876 for ; Thu, 24 May 2001 04:50:32 -0400 (EDT) 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 f4O8nx827822; Thu, 24 May 2001 03:49:59 -0500 (CDT) 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 f4O8nwC22597; Thu, 24 May 2001 03:49:58 -0500 (CDT) Received: from pc050163 (pc4218.es.eu.ericsson.se [159.107.4.218]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id DAA27980; Thu, 24 May 2001 03:49:57 -0500 (CDT) Reply-To: From: "Adam Roach" To: "=?iso-8859-1?B?J0ZyYW7nb2lzLUZy6WTpcmljIE96b2cn?=" , Subject: RE: [Simple] 3GPP implied SUBSCRIBE Date: Thu, 24 May 2001 03:52:12 -0500 Message-ID: <000c01c0e42e$d333f4c0$da046b9f@pc050163.exu.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <000a01c0e3a1$13d638a0$0805260a@VERSADA.centerbeam.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Length: 2562 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: >From: François-Frédéric Ozog [mailto:ffo@ifrance.com] > >3GPP defines the mechanism I reproduce below. >Are there such provisions in SIMPLE? No. Not at all. But keep reading. >A register is sent from a device to the relevant proxy (P-SCSF in 3GPP): > > REGISTER sip:registrar.home1.net SIP/2.0 > Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd] > From: > To: > Contact: > Call-ID: 123456789@[5555::aaa:bbb:ccc:ddd] > CSeq: 1 REGISTER > Expires: 7200 > Allow-Events: org.3gpp.nwinitdereg > Content-Length: 0 > >Allow-Events is used to implicitly subscribe to the event "org.3gpp.nwinitdereg". The >P-CSCF will remove this field from the REGISTER request before sending it on to the >home network. This absolutely *IS* *NOT* what "Allow-Events" means. Allow-Events merely lists those packages which a node can support. The message you've included above isn't an implicit subscription; it's an announcement that the node at 5555::aaa:bbb:ccc:ddd is willing and able to receive SUBSCRIBE requests for the package "org.3gpp.nwinitdreg," and will generate NOTIFY messages for that package as appropriate. I strongly suspect that this is not what you want to communicate. I beleive you are trying to install some mechanism by which a terminal is aware of the fact that it has been de-registered (ostensibly by a third party). For some reason, you want to define a brand-new package to do so. Essentially, this is a presence problem. As odd as it sounds, you want to subscribe to your own presence on the network. This is where SIMPLE comes in. (Presumably, you posted to the SIMPLE list instead of the sip-events list because you want to use SIMPLE mechanisms). Luckily, to solve the problem of informing terminals that they are no longer registered, you need absolutely no extensions. You just need to use the "sip for presence" specification being developed by SIMPLE. After a user registers at a terminal, that terminal (if it is interested in this sort of thing) sends a SUBSCRIBE message to its registrar. This SUBSCRIBE is exactly a sip for presence SUBSCRIBE (see the SIMPLE internet drafts for details on the syntax) which subscribes to the presence of the same user. By doing so, whenever the user is un-registered (including by third parties), the terminal will find out. In summary: the bad news is that your proposed solution will not work; the good news is that there already exists a solution to your problem -- all you have to do now is use it. /a From christian@hotsip.com Mon May 28 08:57:18 2001 Received: from hs004.hotsip.com ([212.28.214.197]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00955 for ; Mon, 28 May 2001 08:57:07 -0400 (EDT) Received: from RYMDIS (dhcp013.hotsip.com [212.28.214.213]) by hs004.hotsip.com (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id f4SCv0624036; Mon, 28 May 2001 14:57:00 +0200 X-Authentication-Warning: hs004.hotsip.com: Host dhcp013.hotsip.com [212.28.214.213] claimed to be RYMDIS Message-ID: <006701c0e775$e66284e0$d5d61cd4@RYMDIS> From: "Christian Jansson" To: "David Simons" , "Jonathan Rosenberg" Cc: References: <2E33960095B58E40A4D3345AB9F65EC146365D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Date: Mon, 28 May 2001 14:58:32 +0200 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 Content-Length: 771 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: > This doesn't strictly follow > RFC2543 because the SUBSCRIBE CSeq wouldn't be contiguous. But, it does > keep the CSeq counts up-to-date. >David J. Simons This requirement about contiguous CSeqs, is it really necessary? Is it valid at all? For example if there is one or more proxy servers that requires Proxy-Authentication some CSeqs may be used for resending request with valid credentials. So, a UAS should never expect to receive contiguous CSeqs. But, it should expect to receive strictly monotonically increasing CSeqs. And if this is the case, why do we put the requirement on the UAC to send with contiguous CSeqs. I think the requirement should be changed to: "send with strictly monotonically increasing CSeqs". Christian Jansson Hotsip www.hotsip.com From rsparks@dynamicsoft.com Tue May 29 10:07:07 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04852 for ; Tue, 29 May 2001 10:07:06 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA08618; Tue, 29 May 2001 10:10:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 May 2001 10:06:57 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A841@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Christian Jansson'" , David Simons , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Date: Tue, 29 May 2001 10:06:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1346 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: gentlefolk - Please move this discussion to the SIP list. RjS > -----Original Message----- > From: Christian Jansson [mailto:christian@hotsip.com] > Sent: Monday, May 28, 2001 7:59 AM > To: David Simons; Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Difference between a SUBSCRIBE and a > re-SUBSCRIBE > > > > > This doesn't strictly follow > > RFC2543 because the SUBSCRIBE CSeq wouldn't be contiguous. > But, it does > > keep the CSeq counts up-to-date. > >David J. Simons > > This requirement about contiguous CSeqs, is it really > necessary? Is it valid > at all? For example if there is one or more proxy servers > that requires > Proxy-Authentication some CSeqs may be used for resending > request with valid > credentials. So, a UAS should never expect to receive > contiguous CSeqs. But, > it should expect to receive strictly monotonically increasing > CSeqs. And if > this is the case, why do we put the requirement on the UAC to > send with > contiguous CSeqs. I think the requirement should be changed > to: "send with > strictly monotonically increasing CSeqs". > > Christian Jansson > Hotsip > www.hotsip.com > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From c-Dai.Ngo@WCOM.Com Thu May 31 16:46:53 2001 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 QAA13233 for ; Thu, 31 May 2001 16:46:52 -0400 (EDT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GE700CDOWCIYZ@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Thu, 31 May 2001 20:45:54 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0GE700E01WCFLI@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 31 May 2001 20:45:53 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0GE700BHLWBZJS@dgismtp02.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 31 May 2001 20:45:35 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 20:45:34 +0000 Content-return: allowed Date: Thu, 31 May 2001 20:45:33 +0000 From: "Ngo, Dai (c)" To: simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E11C59A@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_CkY14rSQSdNxsrBca43yXA)" Content-Length: 1535 Subject: [Simple] Contact in 1xx for 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: 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_CkY14rSQSdNxsrBca43yXA) Content-type: text/plain; charset=iso-8859-1 Hi all, When reviewing the draft-roach-sip-subscribe-notify-03.txt I notice that in section 4.1 "New Methods" Table 4 the Contact header is required for 1xx response to a SUBSRIBE. Could anyone explain to me what the 1xx here is used for? and why it's required? Thank you in advance. Dai Ngo --Boundary_(ID_CkY14rSQSdNxsrBca43yXA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Contact in 1xx for SUBSCRIBE

Hi all,

When reviewing the = draft-roach-sip-subscribe-notify-03.txt I notice that in section 4.1 = "New Methods"  Table 4 the Contact header is required = for 1xx response to a SUBSRIBE.

Could anyone explain to me what the = 1xx here is used for? and why it's required?

Thank you in advance.

Dai Ngo

--Boundary_(ID_CkY14rSQSdNxsrBca43yXA)-- From jdrosen@dynamicsoft.com Thu May 31 19:02:17 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13617 for ; Thu, 31 May 2001 19:02:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA17988; Thu, 31 May 2001 19:06:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 May 2001 19:02:16 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Contact in 1xx for SUBSCRIBE Date: Thu, 31 May 2001 19:02:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1085 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: 1xx for non-INVITE methods is allowed, but generally not too useful, since a final response should come right away. For presence in particular, sending a 202 right away is the preferred behavior, so the 1xx serves no purpose. -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: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Thursday, May 31, 2001 4:46 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] Contact in 1xx for SUBSCRIBE Hi all, When reviewing the draft-roach-sip-subscribe-notify-03.txt I notice that in section 4.1 "New Methods" Table 4 the Contact header is required for 1xx response to a SUBSRIBE. Could anyone explain to me what the 1xx here is used for? and why it's required? Thank you in advance. Dai Ngo From rsparks@dynamicsoft.com Fri Jun 1 13:49:06 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26270 for ; Fri, 1 Jun 2001 13:49:05 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA06598; Fri, 1 Jun 2001 13:53:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 13:49:05 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A85B@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com, "'adam.roach@ericsson.com'" Subject: RE: [Simple] Contact in 1xx for SUBSCRIBE Date: Fri, 1 Jun 2001 13:48:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2148 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: If you are sending a subscribe, an intervening proxy could send you a 100 as it passes the subscribe along to squelch your retransmits. If you are receiving a subscribe, you should be able to get a final response out quickly, and if its within the first T1 or so from receiving the request, skipping the provisional would be good. If you _know_ you're going to have a response delayed to the latter part of the legal non-invite transaction period, sending a 100 would be a good idea. I can't think of why Contact is listed as a mandatory header for 1xx responses to SUBSCRIBE. RjS > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, May 31, 2001 6:02 PM > To: 'Ngo, Dai (c)'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Contact in 1xx for SUBSCRIBE > > > 1xx for non-INVITE methods is allowed, but generally not too > useful, since a > final response should come right away. For presence in > particular, sending a > 202 right away is the preferred behavior, so the 1xx serves > no purpose. > > -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: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] > Sent: Thursday, May 31, 2001 4:46 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Contact in 1xx for SUBSCRIBE > > > Hi all, > When reviewing the draft-roach-sip-subscribe-notify-03.txt I > notice that in > section 4.1 "New Methods" Table 4 the Contact header is > required for 1xx > response to a SUBSRIBE. > Could anyone explain to me what the 1xx here is used for? and why it's > required? > Thank you in advance. > Dai Ngo > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From dsimons@windows.microsoft.com Fri Jun 1 15:45:18 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA26618 for ; Fri, 1 Jun 2001 15:45:17 -0400 (EDT) Received: from 157.54.9.104 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Jun 2001 12:44:47 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 1 Jun 2001 12:34:41 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 1 Jun 2001 12:30:35 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Jun 2001 12:29:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EAD1.35E86243" Date: Fri, 1 Jun 2001 12:29:43 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1111FA1@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SETDATA draft Thread-Index: AcDq0UqzzQsVie5SS1uc8BwoE26v/Q== From: "David Simons" To: X-OriginalArrivalTime: 01 Jun 2001 19:29:44.0171 (UTC) FILETIME=[36049BB0:01C0EAD1] Content-Length: 1786 Subject: [Simple] SETDATA draft 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0EAD1.35E86243 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I keep seeing references to a SIP SETDATA request type. Is there a draft for this or is this just REGISTER with a new name? David J. Simons SDE Lead Window RTC ------_=_NextPart_001_01C0EAD1.35E86243 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SETDATA draft

I = keep seeing references to a SIP SETDATA request type.  = Is there a draft for this or is this just = REGISTER = with a new = name?

David J. Simons

SDE Lead

Window RTC

------_=_NextPart_001_01C0EAD1.35E86243-- From jdrosen@dynamicsoft.com Sun Jun 3 00:45:35 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01650 for ; Sun, 3 Jun 2001 00:45:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA14224; Sun, 3 Jun 2001 00:49:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Jun 2001 00:45:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Simons'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] SETDATA draft Date: Sun, 3 Jun 2001 00:45:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1677 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: -----Original Message----- From: David Simons [mailto:dsimons@windows.microsoft.com] Sent: Friday, June 01, 2001 3:30 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] SETDATA draft >I keep seeing references to a SIP SETDATA request type. Is there a draft for this or is >this just REGISTER with a new name? Part of the proposal for presence authorization was to upload policy docs to the server. A few ways were discussed, including non-SIP (HTTP), or SIP, using REGISTER, or perhaps a new method, dubbed SETDATA. The idea for using something beside REGISTER is that the usage of REGISTER for uploading stuff is a bit of a stretch, particularly when you consider that the soft-state characteristics of the body are totally different than the Contact headers. Furthermore, a REGISTER request with a CPL might fail because the CPL script was bad, or because the Contacts were illegal or something. The fact that the method conveys two things that can fail independently, is a sign that they might need to be split. Now, this is controversial, and involves the SIP wg. However, it is something we need to figure out. Given that the overall new authorization framework is agreed upon (and I think there is consensus on that), this is probably the biggest open issue remaining within that proposal. -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 From jdrosen@dynamicsoft.com Sun Jun 3 01:23:29 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01790 for ; Sun, 3 Jun 2001 01:23:29 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14349; Sun, 3 Jun 2001 01:27:25 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Jun 2001 01:23:28 -0400 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , Jonathan Rosenberg , "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com, "'adam.roach@ericsson.com'" Subject: RE: [Simple] Contact in 1xx for SUBSCRIBE Date: Sun, 3 Jun 2001 01:23:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 865 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: > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Friday, June 01, 2001 1:49 PM > To: Jonathan Rosenberg; 'Ngo, Dai (c)'; > simple@mailman.dynamicsoft.com; > 'adam.roach@ericsson.com' > Subject: RE: [Simple] Contact in 1xx for SUBSCRIBE > > > If you are sending a subscribe, an intervening proxy could > send you a 100 as it passes the subscribe along to squelch > your retransmits. Right; I was only considering the hop before the presence agent. -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 From oded@odigo.com Mon Jun 4 15:55:35 2001 Received: from dino.novawiz.com ([212.150.9.210]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00228 for ; Mon, 4 Jun 2001 15:55:31 -0400 (EDT) Received: from odedlap ([10.0.0.131]) by dino.novawiz.com (8.11.1/8.11.1) with SMTP id f54Dswj17244 for ; Mon, 4 Jun 2001 16:54:59 +0300 From: "Oded Cna'an" To: Date: Mon, 4 Jun 2001 16:53:18 +0200 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 1 Subject: [Simple] Add to mail list 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: From jdrosen@dynamicsoft.com Mon Jun 4 17:07:24 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00488 for ; Mon, 4 Jun 2001 17:07:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA13602 for ; Mon, 4 Jun 2001 17:11:21 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Jun 2001 17:07:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 4 Jun 2001 17:07:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 797 Subject: [Simple] FW: Windows Messenger to use SIP 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: FYI. --- 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: Turner Hunt [mailto:turnerhunt@rapman.com] Sent: Monday, June 04, 2001 12:34 PM To: impp@iastate.edu Subject: Windows Messenger to use SIP Windows Messenger to use SIP Is this Old News ? Thought the list might be interested in seeing this - http://news.cnet.com/news/0-1003-200-6180034.html?tag=nbs Turner Hunt Rapman.com [reminder: meta-impp@iastate.edu for non-technical discussions, please] From oded@odigo.com Tue Jun 5 03:38:31 2001 Received: from dino.novawiz.com ([212.150.9.210]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02167 for ; Tue, 5 Jun 2001 03:38:27 -0400 (EDT) Received: from odedlap ([10.0.0.131]) by dino.novawiz.com (8.11.1/8.11.1) with SMTP id f557bMj16591 for ; Tue, 5 Jun 2001 10:37:22 +0300 From: "Oded Cna'an" To: Date: Tue, 5 Jun 2001 10:35:44 +0200 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 1 Subject: [Simple] oded@odigo.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: From theodore.havinis@openwave.com Wed Jun 6 00:01:02 2001 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 AAA05489 for ; Wed, 6 Jun 2001 00:01:02 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010606040039.NEFI5200.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Tue, 5 Jun 2001 23:00:39 -0500 Received: from harviniT ([212.155.2.34]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with SMTP id <20010606035936.TMDX10672.oe-ismta2.bizmailsrvcs.net@harviniT>; Tue, 5 Jun 2001 22:59:36 -0500 From: "Theodore Havinis" To: "Jonathan Rosenberg" , Subject: RE: [Simple] authorization for presence Date: Tue, 5 Jun 2001 21:02:18 -0700 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 6716 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: As I am trying to understand better the proposed solution I am confused as to whether the automatic notification to all watchers as soon as a new watcher tries to subscribe to the event is just *how a buddy list would work* or whether its a *a generic requirement* when dealing with subscriptions to events. I assume, for protecting the presentity's privacy, it would be enough only for the presentity to be notified everytime a new watcher requests subscription to the presentity, unless the presentity explicitly allows the presence server to notify every (or some of them) watcher about which other watcher is in the list. Kind rgds Theo > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan > Rosenberg > Sent: Wednesday, May 16, 2001 3:18 PM > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] authorization for presence > > > Folks, > > I think its time we begin discussing the second main open issue > discussed at > the last IETF. Specifically, the issue of authorization of presence > subscriptions. > > The currently defined method makes use of QAUTH. When a presence > server gets > a SUBSCRIBE, it sends a QAUTH to the presentity. If the subscription is > acceptable, the presentity responds to the QAUTH with a 200 OK. The proxy > knows to send QAUTH to the presentity because it will send a methods > parameter in a REGISTER, indicating that their contact address supports > QAUTH. > > There are several big problems with this: > > 1. the QAUTH transaction will timeout if the user doesn't answer > right away. > QAUTH, like INVITE, requires human interaction, and so its retransmit > semantics don't work. > > 2. If QAUTH forks, we will end up receiving the "best" response to the > query, which will be a 200 OK if anyone of the forked requests > results in a > 200 OK. As a result, the policy for merging approvals for subscriptions is > forced to be the same as the forking rules, which is probably not what you > want. > > 3. The model assumes that if I can send a registration for a presentity, > that means I am authorized to make policy decisions about subscriptions. > That is not necessarily the case. We are really overloading register to > imply something else. > > So, the proposal I made to resolve this was the following: > > 1. We define a new event package, called "watcherinfo". This > package defines > a subscribable entity, which is the current subscription state for some > presentity. Its a list of those active and pending subscriptions for some > presentity. When someone subscribes to a presentity, the > subscription state > for that presentity changes. A new pending subscription is > basically added. > Since this state is subscribable, a UA can subscribe to it, and get > notifications when it changes. In this case, the UA is notified if someone > tries to SUBSCRIBE to the specific presentity. The body of the > notifications > contains the current subscription list for that presentity. > > 2. We define an authorization document format for presence. This > is a simple > document format which indicates the set of subscriber identities that are > permitted, or not permitted, to subscribe to a presentity. For example: > > allow: > sip:a@b > sip:b@c > > deny: > sip:x@y > > > 3. At any point in time (including after receiving a notification > that a new > subscriber has attempted to subscribe), a UA can push a new authorization > document to the presence server. The presence server applies this > policy to > the current subscription list, dropping or approving subscriptions as > needed. This push could happen via HTTP or through SIP, TBD. > > > Here is an example. > > A subscriber, sip:sally@foo.com, subscribes to some presentity, > sip:peter@bar.com. The presence server receives the subscription, marks it > as pending, and sends a 202. Now, the subscriber list for peter > has changed; > sally@foo.com has been added as pending. peter@bar.com has also subcsribed > to the subscription state for peter@bar.com. It did this previously, by > sending a SUBSCRIBE that looks like: > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > Event: watcherinfo > > Now, since the buddy list for Peter has changed, Peter (and any > others that > have subscribed), get notifications. The NOTIFY might look like: > > NOTIFY sip:peter@bar.com SIP/2.0 > From: sip:peter_buddylist@bar.com > To: sip:peter@bar.com > Content-type: text/xml+buddies > > > > sip:sally@foo.com > > > sip:friend@baz.com > > > > Peter's UA gets this NOTIFY, and responds with 200 OK. It also > queries peter > about whether to accept this pending subscription from > sally@foo.com. Peter > is away from his desk. He comes back 10 minutes later, and clicks OK. At > this point, the UA uploads a new authorization document fragment, > using SIP, > say: > > SETDATA sip:peter_presence_auth@bar.com SIP/2.0 > From: sip:peter@bar.com > Content-type: text/authlist > > accept: > sip:sally@foo.com > > > The presence server gets this, and responds with a 200 OK. Sally is now > approved. > > > The benefits of this approach are: > > 1. we separate the policies on (1) who finds out about > subscription changes > for a presentity, and (2) who can set policies for subscription > changes for > a presentity. > > 2. there is no transaction timeout problem > > 3. policies on merging multiple authorization documents are at the > discretion of the presence server. > > 4. We unify setting of policies asyncrhonously, and syncrhonously with the > arrival of a subscription. > > 5. since authorization policies are a document, not a protocol, > they can be > exchanged, stored, and manipulated which is very good. > > 6. much of this is reusable by other protocols > > > The slides I presented at IETF 50, where I described this proposal, can be > found at: > http://www.jdrosen.net/papers/simple_open_mar01.ppt > > We need to decide whether to move forward with this approach. Comments and > criticisms are welcome. > > 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 roberbr@microsoft.com Wed Jun 6 02:38:39 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA05934 for ; Wed, 6 Jun 2001 02:38:38 -0400 (EDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 05 Jun 2001 23:19:25 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 5 Jun 2001 23:18:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] authorization for presence Date: Tue, 5 Jun 2001 23:18:22 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C3297@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] authorization for presence Thread-Index: AcDuPjQr7ydc7kQbQzatotbayE+FXQAEP88w From: "Robert Brown" To: "Theodore Havinis" , "Jonathan Rosenberg" , X-OriginalArrivalTime: 06 Jun 2001 06:18:25.0657 (UTC) FILETIME=[7EAF0E90:01C0EE50] Content-Length: 12133 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id CAA05934 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: To my mind, the strengths of the new proposal are that it: 1 - deals effectively with the potential latency involved in deferred authorization 2 - deals with multiple potential authorization points 3 - attempts to provide current data state that can be used to synchronize state across nodes that might display or enforce authorization But I do share a similar concern to that expressed in the first paragraph of Theodore's mail. --- I'm wondering... 1 - Is it possible to get solution that is applicable to deferred authorization in general, rather than specific to authorizing subscribers to presence state (I think this is the same thing Theodore is referring to in his message?) 2 - I'm a little wary of coupling the current authorization state with the list of pending authorization requests. This can lead to very large auth request messages when users have large numbers of watchers. 3 - I'm a little wary of restricting the solution to a specific set of rights, such as "active" and "blocked", and structuring the state document around those rights, as these may not be meaningful and/or sufficient for all types of events. --- Perhaps we could modify the proposal as follows: --- 1 - Separate the subscription to the current state of the authorization list from the subscription to authorization requests So the example below would become two subscriptions: i) subscribe to the authorization list (in this case "watcherinfo") to ensure you always get notified of the current state of the list. SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 Event: watcherinfo ii) subscribe to authorization list's authorization requests (in this case we'll call it "watcherinfo.authrequests") SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 Event: watcherinfo.authrequests --- 2 - generalize the payload of the authorization list. This means removing words like "buddylist" and replacing with something more general. It may also mean using attributes to contain conferred rights ("allow", "block", etc), rather than having a separate containing element for each right. For example: auth="allow". Or more generally: auth="right1 right2 right3". This will make the rights list easily extensible for any authorization that semantically differs from buddy watchers - i.e. the set of rights does not dictate the grammar of the XML document. For example, we could change the xml payload of the authorization list notification to look like: NOTIFY sip:peter@bar.com SIP/2.0 From: sip:bar.com To: sip:peter@bar.com Event: watcherinfo Content-type: text/xml+authlist Note the general content-type "text/xml+authlist" As a possible optimization to cater for lengthy authorization lists, we could propagate deltas instead. If I have 200 watchers, and grant access to the 201st watcher, I'd rather not propagate all 201 watchers. Clients could monitor CSEQ (which is defined as "monotonic contiguous increasing" - i.e. always increments by 1) in the NOTIFYs to detect missing deltas and re-subscribe to get the full list. For example: NOTIFY sip:peter@bar.com SIP/2.0 From: sip:bar.com To: sip:peter@bar.com Event: watcherinfo Cseq: 34 Content-type: text/xml+authlistdelta --- 3 - generalise the payload of the authorization request in a similar manner. NOTIFY sip:peter@bar.com SIP/2.0 From: sip:bar.com To: sip:peter@bar.com Event: watcherinfo.authrequests Content-type: text/xml+authrequest --- The reason I put a 'request="allow"' attribute in there is because they might be requesting some type of access other than "allow". This would be proprietary to the particular data being watched. This is also why I suggested generalizing the set of authorization states in step 2 above, like auth="right1 right2 right3". For example, the data I want to watch might be the number of minutes left on a calling card. I might request access to 400 minutes, but I only get authorized for 20. I don't know if it's that useful. Supporting multiple simultaneous rights certainly isn't necessary for watcher lists, but might be relevant for something else. Thanks for reading this far :-) - Rob Robert Brown Lead Program Manager Microsoft Real Time Communications Server mailto:roberbr@microsoft.com > -----Original Message----- > From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > Sent: Tuesday, June 05, 2001 9:02 PM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] authorization for presence > > > As I am trying to understand better the proposed solution I am confused as > to whether > the automatic notification to all watchers as soon as a new watcher tries > to > subscribe to the event is just *how a buddy list would work* or whether > its > a *a generic requirement* when dealing with subscriptions to events. > > I assume, for protecting the presentity's privacy, it would > be enough only for the presentity to be notified everytime a new watcher > requests subscription to the presentity, unless the presentity explicitly > allows the presence server to notify every (or some of them) watcher about > which other watcher is in the list. > > Kind rgds > Theo > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan > > Rosenberg > > Sent: Wednesday, May 16, 2001 3:18 PM > > To: 'simple@mailman.dynamicsoft.com' > > Subject: [Simple] authorization for presence > > > > > > Folks, > > > > I think its time we begin discussing the second main open issue > > discussed at > > the last IETF. Specifically, the issue of authorization of presence > > subscriptions. > > > > The currently defined method makes use of QAUTH. When a presence > > server gets > > a SUBSCRIBE, it sends a QAUTH to the presentity. If the subscription is > > acceptable, the presentity responds to the QAUTH with a 200 OK. The > proxy > > knows to send QAUTH to the presentity because it will send a methods > > parameter in a REGISTER, indicating that their contact address supports > > QAUTH. > > > > There are several big problems with this: > > > > 1. the QAUTH transaction will timeout if the user doesn't answer > > right away. > > QAUTH, like INVITE, requires human interaction, and so its retransmit > > semantics don't work. > > > > 2. If QAUTH forks, we will end up receiving the "best" response to the > > query, which will be a 200 OK if anyone of the forked requests > > results in a > > 200 OK. As a result, the policy for merging approvals for subscriptions > is > > forced to be the same as the forking rules, which is probably not what > you > > want. > > > > 3. The model assumes that if I can send a registration for a presentity, > > that means I am authorized to make policy decisions about subscriptions. > > That is not necessarily the case. We are really overloading register to > > imply something else. > > > > So, the proposal I made to resolve this was the following: > > > > 1. We define a new event package, called "watcherinfo". This > > package defines > > a subscribable entity, which is the current subscription state for some > > presentity. Its a list of those active and pending subscriptions for > some > > presentity. When someone subscribes to a presentity, the > > subscription state > > for that presentity changes. A new pending subscription is > > basically added. > > Since this state is subscribable, a UA can subscribe to it, and get > > notifications when it changes. In this case, the UA is notified if > someone > > tries to SUBSCRIBE to the specific presentity. The body of the > > notifications > > contains the current subscription list for that presentity. > > > > 2. We define an authorization document format for presence. This > > is a simple > > document format which indicates the set of subscriber identities that > are > > permitted, or not permitted, to subscribe to a presentity. For example: > > > > allow: > > sip:a@b > > sip:b@c > > > > deny: > > sip:x@y > > > > > > 3. At any point in time (including after receiving a notification > > that a new > > subscriber has attempted to subscribe), a UA can push a new > authorization > > document to the presence server. The presence server applies this > > policy to > > the current subscription list, dropping or approving subscriptions as > > needed. This push could happen via HTTP or through SIP, TBD. > > > > > > Here is an example. > > > > A subscriber, sip:sally@foo.com, subscribes to some presentity, > > sip:peter@bar.com. The presence server receives the subscription, marks > it > > as pending, and sends a 202. Now, the subscriber list for peter > > has changed; > > sally@foo.com has been added as pending. peter@bar.com has also > subcsribed > > to the subscription state for peter@bar.com. It did this previously, by > > sending a SUBSCRIBE that looks like: > > > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > > Event: watcherinfo > > > > Now, since the buddy list for Peter has changed, Peter (and any > > others that > > have subscribed), get notifications. The NOTIFY might look like: > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > From: sip:peter_buddylist@bar.com > > To: sip:peter@bar.com > > Content-type: text/xml+buddies > > > > > > > > sip:sally@foo.com > > > > > > sip:friend@baz.com > > > > > > > > > > Peter's UA gets this NOTIFY, and responds with 200 OK. It also > > queries peter > > about whether to accept this pending subscription from > > sally@foo.com. Peter > > is away from his desk. He comes back 10 minutes later, and clicks OK. At > > this point, the UA uploads a new authorization document fragment, > > using SIP, > > say: > > > > SETDATA sip:peter_presence_auth@bar.com SIP/2.0 > > From: sip:peter@bar.com > > Content-type: text/authlist > > > > accept: > > sip:sally@foo.com > > > > > > The presence server gets this, and responds with a 200 OK. Sally is now > > approved. > > > > > > The benefits of this approach are: > > > > 1. we separate the policies on (1) who finds out about > > subscription changes > > for a presentity, and (2) who can set policies for subscription > > changes for > > a presentity. > > > > 2. there is no transaction timeout problem > > > > 3. policies on merging multiple authorization documents are at the > > discretion of the presence server. > > > > 4. We unify setting of policies asyncrhonously, and syncrhonously with > the > > arrival of a subscription. > > > > 5. since authorization policies are a document, not a protocol, > > they can be > > exchanged, stored, and manipulated which is very good. > > > > 6. much of this is reusable by other protocols > > > > > > The slides I presented at IETF 50, where I described this proposal, can > be > > found at: > > http://www.jdrosen.net/papers/simple_open_mar01.ppt > > > > We need to decide whether to move forward with this approach. Comments > and > > criticisms are welcome. > > > > 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 oded@odigo.com Wed Jun 6 09:21:00 2001 Received: from dino.novawiz.com ([212.150.9.210]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06999 for ; Wed, 6 Jun 2001 09:20:58 -0400 (EDT) Received: from odedlap ([10.0.0.131]) by dino.novawiz.com (8.11.1/8.11.1) with SMTP id f56DJmj08257; Wed, 6 Jun 2001 16:19:48 +0300 From: "Oded Cna'an" To: "SIMPLE Mail List (E-mail)" Cc: "Avner Ronen (E-mail)" , "Gabriel Matsliach (E-mail)" Subject: [SIMPLE] Presence Authorization Date: Wed, 6 Jun 2001 16:18:10 +0200 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Length: 4223 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: Hi, I read Jonathan's proposal on presence authorization and the comments made by Robert and Theodore and would like to add some comments. I agree with Jonathan that the QAUTH mechanism is not suitable for presence authorization in the general case, but I think that the proposed solution has an intrinsic fault regarding who should handle presence authorization and watcher lists. As this is a fundamental question in the definition of a presence server, I'll start from he beginning. A general presence server (PS), in my view, handles 3 basic tasks: 1. Collection and aggregation of presence information - a PS updates the presence information by both connecting to different 'sensors' (location servers, reachability servers, velocity servers etc.) and receiving updates from presentities as to their status (availability, location etc.). Presence information is aggregated so that the server holds the latest presence state of a presentity based on all the UAs currently registered. 2. Manage subscription (not authorization) of entities that wish to receive presence notifications on specific presentities. These entities must already be approved to receive notifications. 3. Issuing notifications to watchers whenever the presence information changes. Normally, a presence server would also support querying of presence information as defined in RFC 2778. Presence servers work hand in hand with applications that require presence info (e.g., IM, UM, call routing, content delivery etc.) in a way that these applications supply the logic part and the PS takes care of presence collection and distribution. The main point is that these services are separated from the PS. If we take a SIMPLE based IM service as an example, this service requires an implicit/explicit login/logout actions, manages message routing (and possibly storing) and is the interface for presence information. The translation of these operations into a SIMPLE work flow can be done as follows (although this is not the only way): UA IM PS | REGISTER | | |------------------->| REGISTER | | |------------->| | | 200 OK | | 200 OK |<-------------| |<-------------------| | | | | | SUBSCRIBE | | |------------------->| SUBSCRIBE | | |------------->| | | 200 OK | | 200 OK |<-------------| |<-------------------| | | | NOTIFY | | NOTIFY |<-------------| |<-------------------| | | | | | MESSAGE | | OTHER UA |------------------->| MESSAGE | | |---------------------------->| | | | | | | 200 OK | | 200 OK |<----------------------------| |<-------------------| | | As shown above, the actions are performed against the service (in this case IM) that passes them (if appropriate) to the PS. Subscription authorization, in the general case, is related to a service and not the PS. As an example, let's say that I am connected to 2 different services (IM and UM) that use the same PS as their back office (a typical scenario for mobile operators and enterprises). Approving subscription to user a@b on the UM service does not mean that I approve subscription to that user on the IM service. The above analysis dictates a solution in which the service is responsible for the subscription authorization and the presence server is informed by the service, which users can receive presence info on a certain presentity (subject to PS provisioning). This approach, that separates between the services and the PS was adopted by the PAM forum and is at the basis of the PAM API. Thanks, ------------------------ Oded Cna'an VP, New Technologies Odigo Inc. From ffo@ifrance.com Wed Jun 6 13:08:51 2001 Received: from lh09.opsion.fr (lh09.opsion.fr [212.73.208.235]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA07651 for ; Wed, 6 Jun 2001 13:08:50 -0400 (EDT) Received: from 208.46.211.130 [208.46.211.130] by lh09.opsion.fr; Wed, 6 Jun 2001 17:13:13 GMT Message-ID: <003d01c0eeab$28e071b0$7a10100a@ffocp800> From: "Francois-Frederic Ozog" To: Subject: RE: [Simple] authorization for presence Date: Wed, 6 Jun 2001 10:07:24 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C0EE70.7BB65A70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 3499 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: This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C0EE70.7BB65A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable watcherinfo event is an elegant proposal. I would like to propose to extend it to define what attributes or events = are subscribable as there are provisions in the standard for other = presence attributes and events. At the same time, why not using the same concept to provision the access = rights and piggy-back this in a REGISTER payload, or a new method like = AUTHORIZE. The critical issue though is TRUST. Can I trust the sip URI to build = authorization? If the presence service is authenticated by only one = server that seems to be OK but what if subscriber A uses SIMPLE service = S1 and publisher B uses SIMPLE server S2 ? Authorization model is the = first step to defining a trustable service.=20 ------=_NextPart_000_003A_01C0EE70.7BB65A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
watcherinfo event is an elegant=20 proposal.
 
I would like to propose to extend it to = define what=20 attributes or events are subscribable as there are provisions in the = standard=20 for other presence attributes and events.
 
<authlist>
   = <subscriber=20 URI=3D"sip:friend@baz.com" event=3D"presence" auth=3D"allow" = />
   <subscriber=20 URI=3D"sip:friend@baz.com" attribute=3D"geolocation" auth=3D"allow"=20 />
   <subscriber URI=3D"sip:badguy@baz.com" = event=3D"presence"=20 auth=3D"block" />
</authlist>
At the same time, why not using the = same concept to=20 provision the access rights and piggy-back this in a REGISTER payload, = or a new=20 method like AUTHORIZE.
 
The critical issue though is TRUST. Can = I trust the=20 sip URI to build authorization? If = the presence=20 service is authenticated by only one server that seems to be OK but what = if=20 subscriber A uses SIMPLE service S1 and publisher B uses SIMPLE server = S2 ?=20 Authorization model is the first step = to defining=20 a trustable service. 
------=_NextPart_000_003A_01C0EE70.7BB65A70-- ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif From jdrosen@dynamicsoft.com Thu Jun 7 01:37:35 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09552 for ; Thu, 7 Jun 2001 01:37:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11034; Thu, 7 Jun 2001 01:41:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Jun 2001 01:37:33 -0400 Message-ID: From: Jonathan Rosenberg To: "'Theodore Havinis'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Thu, 7 Jun 2001 01:37:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Length: 1972 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: > -----Original Message----- > From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > Sent: Wednesday, June 06, 2001 12:02 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] authorization for presence > > > > As I am trying to understand better the proposed solution I > am confused as > to whether > the automatic notification to all watchers as soon as a new > watcher tries to > subscribe to the event is just *how a buddy list would work* > or whether its > a *a generic requirement* when dealing with subscriptions to events. The set of folks that get notified (because they are allowed to subscribe) when my watcherinfo changes (because someone subscribed to my presence), is a matter of local policy. Typically, I expect that local policy would allow only one entity to subscribe to changes in my watcherinfo, and that would be me. > > I assume, for protecting the presentity's privacy, it would > be enough only for the presentity to be notified everytime a > new watcher > requests subscription to the presentity, unless the > presentity explicitly > allows the presence server to notify every (or some of them) > watcher about > which other watcher is in the list. Right; as I said, its a matter of policy. Remember, there are watchers at two levels here. There are the set of folks who subscribed to my presence. Then, there are the set of folks who subscribed to changes in my watcherinfo. That is, the set of folks that want to get notified when someone tries to subscribe to my presence. These two sets of watchers are not the same. -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 From jdrosen@dynamicsoft.com Thu Jun 7 02:00:18 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09649 for ; Thu, 7 Jun 2001 02:00:18 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA11154; Thu, 7 Jun 2001 02:04:14 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Jun 2001 02:00:15 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Theodore Havinis , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Thu, 7 Jun 2001 02:00:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 9300 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Wednesday, June 06, 2001 2:18 AM > To: Theodore Havinis; Jonathan Rosenberg; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] authorization for presence > > > I'm wondering... > > 1 - Is it possible to get solution that is applicable to deferred > authorization in general, rather than specific to authorizing > subscribers to presence state (I think this is the same thing Theodore > is referring to in his message?) I am not entirely sure I understand what you are asking. Perhaps you are asking if this approach to authorization of subscriptions could be used not only for presence, but for other subscribable events, like message waiting indicators. So, in that case, I could subscribe to the watcherinfo for my voicemail inbox. Whenever someone tries to subscribe to my voicemail inbox, I would get notified. THen, I could approve or reject those subscriptions. If this is what you are asking, I agree it should be general. It is for this reason that we proposed (and there seemed to be agreement on), that watcherinfo is basically an abstract sub-package. Each event package could, if it wanted, make use of a watcherinfo subpackage, and that subpackage allows you to subscribe to, and get notified, subscriptions to the parent package. So, for the event mwi, we would have a subpackage mwi.watcherinfo. > > 2 - I'm a little wary of coupling the current authorization state with > the list of pending authorization requests. This can lead to > very large > auth request messages when users have large numbers of watchers. I do not understand what you are saying here. One of the issues which is going to plague us in our discussions is common terminology. THis is especially important when talking about recursive subscription state, which is what watcherinfo is. I do not know what you mean by "authorization state" or "list of pending authorization requests". I suppose the former is the watcherinfo state. I don't know what the latter is. > > 3 - I'm a little wary of restricting the solution to a specific set of > rights, such as "active" and "blocked", and structuring the state > document around those rights, as these may not be meaningful and/or > sufficient for all types of events. Fair enough. One of the nice things about using a document format for this, is that we can define a basic one to get us started, and then define additional documents or extensions as time goes on. The MIME negotiation capabilities in SIP can make sure that we always support a baseline authorization document format (which would be the simple block/accept one), and can figure out whatever common improved-upon format exists. I'll also note that the issue of authorization policy is profoundly complex, and the logic that might go into such a decision may, in many cases, only be expressable in some kind of turing complete language. Therefore, I do not think it is useful to support arbitrarily complex authorization document formats. If your policy is so complex that this is needed, the authorization should all be specified by programmatic logic put in place ahead of time. One such way to structure that logic is using the CPL extensions for presence, an I-D that Xiaotao Wu, Henning Schulzrinne, and myself, recently submitted to IETF: http://www.ietf.org/internet-drafts/draft-wu-cpl-presence-00.txt other things, like SIP servlets, would enable you to create any policy you can possibly dream up. > > --- > > Perhaps we could modify the proposal as follows: > > --- > > 1 - Separate the subscription to the current state of the > authorization > list from the subscription to authorization requests > > So the example below would become two subscriptions: > > i) subscribe to the authorization list (in this case "watcherinfo") to > ensure you always get notified of the current state of the list. > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > Event: watcherinfo > > ii) subscribe to authorization list's authorization requests (in this > case we'll call it "watcherinfo.authrequests") > > SUBSCRIBE sip:peter_buddylist@bar.com SIP/2.0 > Event: watcherinfo.authrequests I still don't know what this is. Can you explain? > 2 - generalize the payload of the authorization list. This means > removing words like "buddylist" and replacing with something more > general. It may also mean using attributes to contain > conferred rights > ("allow", "block", etc), rather than having a separate containing > element for each right. For example: auth="allow". Or more > generally: > auth="right1 right2 right3". By authorization list, I assume you mean the authoriztion document that is pushed to the server by the users, to approve or reject subscriptions. This is not the same as the buddylist or watcherinfo. As I discussed above, I think we need a simple baseline, and support for more complex ones. > > This will make the rights list easily extensible for any authorization > that semantically differs from buddy watchers - i.e. the set of rights > does not dictate the grammar of the XML document. > > For example, we could change the xml payload of the authorization list > notification to look like: > > NOTIFY sip:peter@bar.com SIP/2.0 > From: sip:bar.com > To: sip:peter@bar.com > Event: watcherinfo > Content-type: text/xml+authlist > > > > > I am confused here. THe proposal was to get notified of changes to watcherinfo. That means the notifications contain the current watcherinfo state, which is the set of people who have active or pending subscriptions to me. This state, which I proposed be an XML document (and indeed we submitted a description of in the original June 2000 proposal set), is NOT the same as an authorization policy document. The thing above in the XML looks like an authorization document, and that document would be carried in a REGISTER or SETDATA or whatever we decide upon. > > Note the general content-type "text/xml+authlist" > > As a possible optimization to cater for lengthy authorization > lists, we > could propagate deltas instead. Absolutely, this is essential. We discussed that during IETF 50, and it seemed to be the consensus. If I have 200 watchers, and grant > access to the 201st watcher, I'd rather not propagate all 201 > watchers. Exactly. > Clients could monitor CSEQ (which is defined as "monotonic contiguous > increasing" - i.e. always increments by 1) in the NOTIFYs to detect > missing deltas and re-subscribe to get the full list. For example: > > NOTIFY sip:peter@bar.com SIP/2.0 > From: sip:bar.com > To: sip:peter@bar.com > Event: watcherinfo > Cseq: 34 > Content-type: text/xml+authlistdelta > > > > Hmm, I think maybe I am beginning to understand what you are saying. You want to be able to subscribe to my current authorization policy on the server, since that is also a piece of state (primarily changed through the uploads of authorization documents). Interesting. Not sure that I really need to support notifications and subscriptions to it. I think it would be sufficient just to be able to fetch it (as we do with CPLs). > > --- > > 3 - generalise the payload of the authorization request in a similar > manner. > > NOTIFY sip:peter@bar.com SIP/2.0 > From: sip:bar.com > To: sip:peter@bar.com > Event: watcherinfo.authrequests > Content-type: text/xml+authrequest > > > > > Do you mean what I was referring to as watcherinfo? > > --- > > The reason I put a 'request="allow"' attribute in there is > because they > might be requesting some type of access other than "allow". This would > be proprietary to the particular data being watched. This is > also why I > suggested generalizing the set of authorization states in > step 2 above, > like auth="right1 right2 right3". For example, the data I > want to watch > might be the number of minutes left on a calling card. I > might request > access to 400 minutes, but I only get authorized for 20. I don't know > if it's that useful. Supporting multiple simultaneous rights > certainly > isn't necessary for watcher lists, but might be relevant for something > else. I think all of these would be separate document formats entirely. The general watcherinfo concept, and the concept of uploading policy documents, apply to anything one might want to subscribe to and authorization. However, the document formats - watcherinfo, and the authorization document, are specific to human presence, and that is the subject of concern for this working group. -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 From jdrosen@dynamicsoft.com Fri Jun 8 01:54:00 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13329 for ; Fri, 8 Jun 2001 01:54:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA22192; Fri, 8 Jun 2001 01:57:58 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Jun 2001 01:53:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'Francois-Frederic Ozog'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Fri, 8 Jun 2001 01:53:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Length: 5541 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: -----Original Message----- From: Francois-Frederic Ozog [mailto:ffo@ifrance.com] Sent: Wednesday, June 06, 2001 1:07 PM To: simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence > >watcherinfo event is an elegant proposal. > Thank you. >I would like to propose to extend it to define what attributes or events are >subscribable as there are provisions in the standard for other presence >attributes and events. > > > > > > > > As I commented earlier, policy can be arbitrarily complex. I want to get us off to a good start by defining something very simple and easy first, and then we can define more complex authorization documents down the road as the need arises. Now, the very first cut may be more than just approve/reject, but in my mind, the bar is high for things beyond that. Event, however, is something that has to be there. This would be a token that contains the name of the event package that authorization is being granted or denied for. This is needed since policies for different event packages will undoubtedly be different (in fact, we already have a need for that - watcherinfo is a separate event package, and requires different authorization policies for it!). The other thing that we might want to debate about is the contact type. The initial presence document format being worked on in impp will allow my presence to contain a list of URIs, each of which describes a different means of communications. One can easily imagine that I want certain people to learn about the status of my phone, and others to learn the status of my IM tool. As such, we might want to think about allowing the policy doc to indicate what contact schemes or URLs to distribute to which subscribers. Attributes, like geoloc, are beyond what I would be inclined to put in the first version. The impp presence doc format won't even be able to describe geoloc, so defining a policy doc to control it seems premature. >At the same time, why not using the same concept to provision the access rights >and piggy-back this in a REGISTER payload, or a new method like AUTHORIZE. Indeed, one of the main open issues remaining with this approach is how to upload the authorization doc. We have: 1. http POST 2. SIP REGISTER 3. SIP I'll send a separate note summarizing what I think the pros/cons are with each, to get the discussion moving. > >The critical issue though is TRUST. Can I trust the sip URI to build >authorization? If the presence service is authenticated by only one server that >seems to be OK but what if subscriber A uses SIMPLE service S1 and publisher B >uses SIMPLE server S2 ? Authorization model is the first step to defining a >trustable service. > I think you are talking about authentication, not authorization. The presence document provides authorization, keyed on the subscribers identity in the SUBSCRIBE (From field). The trick is authenticating this ID in order to reliably apply the authorization policy. There are a bunch of models here: 1. We believe in PKI. The server S2 can authenticate the subscribe request from A directly. Everything is great. 2. Trust by transitivity. The domain of S2 trusts that domain S1 has done a good job in authenticating its users. When A sends the SUBSCRIBE, the proxy server in its domain uses standard sip proxy-authentication, and verifies the identity of the subscriber. The subscription is passed between a proxy in S1 to the presence server for S2, using a secure transport layer, like TLS. This allows S2 to verify that requests from S1 are really from S1. So, if S2 trusts that S1 did its job, we get authentication through transitivity. The real drag here is the need for interdomain TLS, which can be a pain for large scale networks. 3. Shared secrets between A and B. I think this is the most workable model. B knows A, and gives A, ahead of time, a password to use in order to access B's presence. When the SUBSCRIBE arrives at the presence agent for A, the SUBSCRIBE is challenged using SIPs digest capabilities. If the subscriber provides a valid password, they are allowed to subscribe. The only trick here is getting the passwords from user B to the presence server for B. There had been some proposals in the iptel working group to standardize some CPL extensions for this purpose, but the idea was rejected. I think the easiest way is to use a web interface to the presence server to establish groups, and associate a digest realm and set of usernames/passwords for these groups. The usernames/passwords are then stored on the presence server. We don't need to define any standardized transfer mechanisms in this case. I think thats OK, since I don't see the need for automata to distribute these passwords out to potential subscribers. That will generally be done with a human user, in which case the web interface is fine. The less that we need to standardize, IMHO, the better. -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 From jdrosen@dynamicsoft.com Fri Jun 8 02:17:13 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13428 for ; Fri, 8 Jun 2001 02:17:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA22349 for ; Fri, 8 Jun 2001 02:21:12 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Jun 2001 02:17:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Fri, 8 Jun 2001 02:17:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Length: 2830 Subject: [Simple] Thoughts on uploading authorization documents 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: Folks, As I have mentioned in other emails, the largest open issue at the moment with the proposed watcherinfo authorization mechanism is how the authorization document gets uploaded to the server. Three things have been proposed: 1. HTTP POST 2. SIP REGISTER 3. SIP , call it SETDATA for now The benefit of using HTTP POST is that HTTP is far more suitable as a pure data transfer protocol, and this is exactly the scenario we are talking about here. The drawback is that we need to authenticate the upload of the document, and the credentials for that will presumably be within the databases used for SIP level authentication. Tying the identity in an HTTP POST request to a SIP identity is a little more complex, but not impossible. Another drawback is the standard "but I don't want to implement yet another protocol in my device" argument. Approach (2) is already in use for uploading of scripts. The benefit is exactly that it is already defined. However, many people think this is a bit of an abuse of REGISTER, which is really meant to convey address bindings, not upload arbitrary documents. One can imagine a case where you have a REGISTER with Contacts and a CPL script. This REGISTER might fail because (1) the contact list had some kind of problem, or (2) the CPL had some kind of problem. Since the request might fail for two very independent reasons, response handling becomes complex. Indeed, this is generally a sign that something should be its own method. Approach (3) stems from this argument. We use SIP, but define a separate method. This method can be specific for uploading of authorization documents, or can be more general. Presumably, we would want to use it for CPL uploads and authorization document uploads, if we go this route. What both of these share is that the method is setting the value for a specific, well defined document that the user can specify. THus, it is "setting data". The primary drawback is that this is a real abuse of SIP; as there is not a session anywhere to be found here. Arguably this is twisting it into a database update protocol. The distiguished name of the element to be written is in the request URI, and the body of the request contains the value of tat element: SETDATA sip:jdrosen.scripts.cpl@dynamicsoft.com SIP/2.0 Content-Type: application/cpl+xml Content-Length: 102 ..... I assure you that I want nothing less than to use SIP as an LDAP alternative. Comments? -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 From hgs@cs.columbia.edu Fri Jun 8 04:35:00 2001 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 EAA13816 for ; Fri, 8 Jun 2001 04:35:00 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id EAA23016; Fri, 8 Jun 2001 04:35:00 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id EAA00321; Fri, 8 Jun 2001 04:34:58 -0400 (EDT) Message-ID: <3B20B959.8A05DFAA@cs.columbia.edu> Date: Fri, 08 Jun 2001 04:39:05 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Thoughts on uploading authorization documents References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4296 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: Jonathan Rosenberg wrote: > > Folks, > > As I have mentioned in other emails, the largest open issue at the moment > with the proposed watcherinfo authorization mechanism is how the > authorization document gets uploaded to the server. Three things have been > proposed: > > 1. HTTP POST > 2. SIP REGISTER > 3. SIP , call it SETDATA for now > > The benefit of using HTTP POST is that HTTP is far more suitable as a pure > data transfer protocol, and this is exactly the scenario we are talking I fail to see the technical difference between direct-routed SIP/TCP and HTTP in terms of efficiency. > about here. The drawback is that we need to authenticate the upload of the > document, and the credentials for that will presumably be within the > databases used for SIP level authentication. Tying the identity in an HTTP > POST request to a SIP identity is a little more complex, but not impossible. It requires making assumptions on creating artificial namespaces, particularly if you want to run a "real" HTTP server on the same host. I don't know what mapping you have in mind, but if you do something like foo@host.com -> host.com/foo or host.com/some/fixed/magic/path/foo this pretty much rules out running a 'real' HTTP server on the same host (it's not clear how you'd map port numbers to anything but the default, except with some explicit SIP header making the association). Also, with DNS SRV, you have to be really careful that the two mappings are similar (assuming we'd be using SRV here; if not, this is a separate disadvantage in terms of naming and scaling). > Another drawback is the standard "but I don't want to implement yet another > protocol in my device" argument. > > Approach (2) is already in use for uploading of scripts. The benefit is > exactly that it is already defined. However, many people think this is a bit > of an abuse of REGISTER, which is really meant to convey address bindings, > not upload arbitrary documents. One can imagine a case where you have a > REGISTER with Contacts and a CPL script. This REGISTER might fail because > (1) the contact list had some kind of problem, or (2) the CPL had some kind > of problem. Since the request might fail for two very independent reasons, > response handling becomes complex. Indeed, this is generally a sign that > something should be its own method. > > Approach (3) stems from this argument. We use SIP, but define a separate > method. This method can be specific for uploading of authorization > documents, or can be more general. Presumably, we would want to use it for > CPL uploads and authorization document uploads, if we go this route. What I don't necessarily see that the methods have to be the same, but that's a minor issue. We should use the Content-Disposition to indicate the property to be set for a particular user. > both of these share is that the method is setting the value for a specific, > well defined document that the user can specify. THus, it is "setting data". > The primary drawback is that this is a real abuse of SIP; as there is not a > session anywhere to be found here. Arguably this is twisting it into a > database update protocol. The distiguished name of the element to be written > is in the request URI, and the body of the request contains the value of tat > element: > > SETDATA sip:jdrosen.scripts.cpl@dynamicsoft.com SIP/2.0 I would not modify the SIP URL. This should be associated directly with the same identifier, not munging the URL in some arbitrary way which creates restrictions on naming users. > Content-Type: application/cpl+xml > Content-Length: 102 > > > ..... > > I assure you that I want nothing less than to use SIP as an LDAP > alternative. > > Comments? > > -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 HUITEMA@windows.microsoft.com Fri Jun 8 14:28:37 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA15399 for ; Fri, 8 Jun 2001 14:28:35 -0400 (EDT) Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Jun 2001 10:40:41 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Jun 2001 10:40:59 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 8 Jun 2001 10:40:51 -0700 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(5.0.2195.1600); Fri, 8 Jun 2001 10:39:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Fri, 8 Jun 2001 10:39:43 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Thoughts on uploading authorization documents Thread-Index: AcDv9hlGIm/TZ9EiQLS79p+BF4bUTwARDetQ From: "Christian Huitema" To: "Henning Schulzrinne" , "Jonathan Rosenberg" Cc: X-OriginalArrivalTime: 08 Jun 2001 17:39:44.0217 (UTC) FILETIME=[0107CC90:01C0F042] Content-Length: 5066 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA15399 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: I think it would be more efficient to just use SOAP, and carry it either over HTTP, or over SIP using a "service" verb. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, June 08, 2001 4:39 AM > To: Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] Thoughts on uploading authorization documents > > > > Jonathan Rosenberg wrote: > > > > Folks, > > > > As I have mentioned in other emails, the largest open issue at the > moment > > with the proposed watcherinfo authorization mechanism is how the > > authorization document gets uploaded to the server. Three things have > been > > proposed: > > > > 1. HTTP POST > > 2. SIP REGISTER > > 3. SIP , call it SETDATA for now > > > > The benefit of using HTTP POST is that HTTP is far more suitable as a > pure > > data transfer protocol, and this is exactly the scenario we are talking > > I fail to see the technical difference between direct-routed SIP/TCP and > HTTP in terms of efficiency. > > > about here. The drawback is that we need to authenticate the upload of > the > > document, and the credentials for that will presumably be within the > > databases used for SIP level authentication. Tying the identity in an > HTTP > > POST request to a SIP identity is a little more complex, but not > impossible. > > It requires making assumptions on creating artificial namespaces, > particularly if you want to run a "real" HTTP server on the same host. I > don't know what mapping you have in mind, but if you do something like > > foo@host.com -> host.com/foo or host.com/some/fixed/magic/path/foo > > this pretty much rules out running a 'real' HTTP server on the same host > (it's not clear how you'd map port numbers to anything but the default, > except with some explicit SIP header making the association). > > Also, with DNS SRV, you have to be really careful that the two mappings > are similar (assuming we'd be using SRV here; if not, this is a separate > disadvantage in terms of naming and scaling). > > > Another drawback is the standard "but I don't want to implement yet > another > > protocol in my device" argument. > > > > Approach (2) is already in use for uploading of scripts. The benefit is > > exactly that it is already defined. However, many people think this is a > bit > > of an abuse of REGISTER, which is really meant to convey address > bindings, > > not upload arbitrary documents. One can imagine a case where you have a > > REGISTER with Contacts and a CPL script. This REGISTER might fail > because > > (1) the contact list had some kind of problem, or (2) the CPL had some > kind > > of problem. Since the request might fail for two very independent > reasons, > > response handling becomes complex. Indeed, this is generally a sign that > > something should be its own method. > > > > Approach (3) stems from this argument. We use SIP, but define a separate > > method. This method can be specific for uploading of authorization > > documents, or can be more general. Presumably, we would want to use it > for > > CPL uploads and authorization document uploads, if we go this route. > What > > I don't necessarily see that the methods have to be the same, but that's > a minor issue. We should use the Content-Disposition to indicate the > property to be set for a particular user. > > > both of these share is that the method is setting the value for a > specific, > > well defined document that the user can specify. THus, it is "setting > data". > > The primary drawback is that this is a real abuse of SIP; as there is > not a > > session anywhere to be found here. Arguably this is twisting it into a > > database update protocol. The distiguished name of the element to be > written > > is in the request URI, and the body of the request contains the value of > tat > > element: > > > > SETDATA sip:jdrosen.scripts.cpl@dynamicsoft.com SIP/2.0 > > I would not modify the SIP URL. This should be associated directly with > the same identifier, not munging the URL in some arbitrary way which > creates restrictions on naming users. > > > Content-Type: application/cpl+xml > > Content-Length: 102 > > > > > > ..... > > > > I assure you that I want nothing less than to use SIP as an LDAP > > alternative. > > > > Comments? > > > > -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 ffo@ifrance.com Fri Jun 8 15:32:38 2001 Received: from lh11.opsion.fr (lh11.opsion.fr [212.73.208.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA15606 for ; Fri, 8 Jun 2001 15:32:37 -0400 (EDT) Received: from 208.46.211.130 [208.46.211.130] by lh11.opsion.fr; Fri, 8 Jun 2001 19:36:53 GMT Message-ID: <002801c0f051$9605beb0$7a10100a@ffocp800> From: "Francois-Frederic Ozog" To: References: Subject: Re: [Simple] Thoughts on uploading authorization documents Date: Fri, 8 Jun 2001 12:31:14 -0700 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 6667 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: I have conceptual and technical issues about HTTP POST. Building on two protocols SIP and HTTP to provide SIMPLE service does not look elegant: it should be either full SIP or full HTTP. HTTP POST is not be available on all devices, for example a WAP J2ME device does not have HTTP stack. Presence would require it in addition to the SIP stack wich maight cause footprint problems. One could argue we could just use the POST format, but it still requires a TCP stack, but again TCP may not be available... Similarly SOAP would require implementation of components that may not be suitable for the J2ME device. Basic XML is sufficient. > > > -----Original Message----- > From: Christian Huitema > To: Henning Schulzrinne; Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Sent: 6/8/2001 10:39 AM > Subject: RE: [Simple] Thoughts on uploading authorization documents > > I think it would be more efficient to just use SOAP, and carry it either > over HTTP, or over SIP using a "service" verb. > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Friday, June 08, 2001 4:39 AM > > To: Jonathan Rosenberg > > Cc: 'simple@mailman.dynamicsoft.com' > > Subject: Re: [Simple] Thoughts on uploading authorization documents > > > > > > > > Jonathan Rosenberg wrote: > > > > > > Folks, > > > > > > As I have mentioned in other emails, the largest open issue at the > > moment > > > with the proposed watcherinfo authorization mechanism is how the > > > authorization document gets uploaded to the server. Three things > have > > been > > > proposed: > > > > > > 1. HTTP POST > > > 2. SIP REGISTER > > > 3. SIP , call it SETDATA for now > > > > > > The benefit of using HTTP POST is that HTTP is far more suitable as > a > > pure > > > data transfer protocol, and this is exactly the scenario we are > talking > > > > I fail to see the technical difference between direct-routed SIP/TCP > and > > HTTP in terms of efficiency. > > > > > about here. The drawback is that we need to authenticate the upload > of > > the > > > document, and the credentials for that will presumably be within the > > > databases used for SIP level authentication. Tying the identity in > an > > HTTP > > > POST request to a SIP identity is a little more complex, but not > > impossible. > > > > It requires making assumptions on creating artificial namespaces, > > particularly if you want to run a "real" HTTP server on the same host. > I > > don't know what mapping you have in mind, but if you do something like > > > > foo@host.com -> host.com/foo or host.com/some/fixed/magic/path/foo > > > > this pretty much rules out running a 'real' HTTP server on the same > host > > (it's not clear how you'd map port numbers to anything but the > default, > > except with some explicit SIP header making the association). > > > > Also, with DNS SRV, you have to be really careful that the two > mappings > > are similar (assuming we'd be using SRV here; if not, this is a > separate > > disadvantage in terms of naming and scaling). > > > > > Another drawback is the standard "but I don't want to implement yet > > another > > > protocol in my device" argument. > > > > > > Approach (2) is already in use for uploading of scripts. The > benefit is > > > exactly that it is already defined. However, many people think this > is a > > bit > > > of an abuse of REGISTER, which is really meant to convey address > > bindings, > > > not upload arbitrary documents. One can imagine a case where you > have a > > > REGISTER with Contacts and a CPL script. This REGISTER might fail > > because > > > (1) the contact list had some kind of problem, or (2) the CPL had > some > > kind > > > of problem. Since the request might fail for two very independent > > reasons, > > > response handling becomes complex. Indeed, this is generally a sign > that > > > something should be its own method. > > > > > > Approach (3) stems from this argument. We use SIP, but define a > separate > > > method. This method can be specific for uploading of authorization > > > documents, or can be more general. Presumably, we would want to use > it > > for > > > CPL uploads and authorization document uploads, if we go this route. > > What > > > > I don't necessarily see that the methods have to be the same, but > that's > > a minor issue. We should use the Content-Disposition to indicate the > > property to be set for a particular user. > > > > > both of these share is that the method is setting the value for a > > specific, > > > well defined document that the user can specify. THus, it is > "setting > > data". > > > The primary drawback is that this is a real abuse of SIP; as there > is > > not a > > > session anywhere to be found here. Arguably this is twisting it into > a > > > database update protocol. The distiguished name of the element to be > > written > > > is in the request URI, and the body of the request contains the > value of > > tat > > > element: > > > > > > SETDATA sip:jdrosen.scripts.cpl@dynamicsoft.com SIP/2.0 > > > > I would not modify the SIP URL. This should be associated directly > with > > the same identifier, not munging the URL in some arbitrary way which > > creates restrictions on naming users. > > > > > Content-Type: application/cpl+xml > > > Content-Length: 102 > > > > > > > > > ..... > > > > > > I assure you that I want nothing less than to use SIP as an LDAP > > > alternative. > > > > > > Comments? > > > > > > -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 ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif From roberbr@microsoft.com Fri Jun 8 16:08:42 2001 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA15729 for ; Fri, 8 Jun 2001 16:08:41 -0400 (EDT) Received: from 157.54.9.101 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Jun 2001 12:33:24 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 8 Jun 2001 12:35:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Fri, 8 Jun 2001 12:35:43 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C32A4@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Thoughts on uploading authorization documents Thread-Index: AcDv4yMat6wjPkjnSBGKq7X/09oaPwAWT++A From: "Robert Brown" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 08 Jun 2001 19:35:44.0658 (UTC) FILETIME=[35C6CF20:01C0F052] Content-Length: 5062 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id QAA15729 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: This is a good summary of the options. I believe that there may be deployment issues with HTTP POST, in that the fact that we have SIP connectivity between two points is not sufficient to imply that we also have HTTP request connectivity, or that there is a reliable way to map a SIP URI to an HTTP URL. I agree that overloading REGISTER semantics introduces some nasty scenarios. This is a good example of tight coupling and why designs should avoid it. I agree that a data update method could be viewed as a corruption of the intent of SIP in that it is not session management. However, this proposal also appears to have the most practical benefit. There are plenty of approaches that can be taken here - none of which are particularly elegant (unfortunately). For example SOAP over SIP, or SETDATA that was described in a previous mail, or something analogous to LDAP 3 or WEVDAV (RFC 2518). Perhaps the most flexible and least like a specific database-update protocol is SOAP over SIP. This could be used for setting CPL, authorizing watchers, or whatever else, by documenting the appropriate SOAP method in each case, but would not necessarily imply a general purpose database protocol. For example something like this could be used to authorize watchers: SERVICE sip:roberbr@microsoft.com SIP/2.0 To: sip:microsoft.com From: roberbr@microsoft.com Content-Type: text/xml+authorizewatcher Content-Length: XXX SIP:max@someplace.com allow > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, June 07, 2001 11:17 PM > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] Thoughts on uploading authorization documents > > Folks, > > As I have mentioned in other emails, the largest open issue at the moment > with the proposed watcherinfo authorization mechanism is how the > authorization document gets uploaded to the server. Three things have been > proposed: > > 1. HTTP POST > 2. SIP REGISTER > 3. SIP , call it SETDATA for now > > > The benefit of using HTTP POST is that HTTP is far more suitable as a pure > data transfer protocol, and this is exactly the scenario we are talking > about here. The drawback is that we need to authenticate the upload of the > document, and the credentials for that will presumably be within the > databases used for SIP level authentication. Tying the identity in an HTTP > POST request to a SIP identity is a little more complex, but not > impossible. > Another drawback is the standard "but I don't want to implement yet > another > protocol in my device" argument. > > Approach (2) is already in use for uploading of scripts. The benefit is > exactly that it is already defined. However, many people think this is a > bit > of an abuse of REGISTER, which is really meant to convey address bindings, > not upload arbitrary documents. One can imagine a case where you have a > REGISTER with Contacts and a CPL script. This REGISTER might fail because > (1) the contact list had some kind of problem, or (2) the CPL had some > kind > of problem. Since the request might fail for two very independent reasons, > response handling becomes complex. Indeed, this is generally a sign that > something should be its own method. > > Approach (3) stems from this argument. We use SIP, but define a separate > method. This method can be specific for uploading of authorization > documents, or can be more general. Presumably, we would want to use it for > CPL uploads and authorization document uploads, if we go this route. What > both of these share is that the method is setting the value for a > specific, > well defined document that the user can specify. THus, it is "setting > data". > The primary drawback is that this is a real abuse of SIP; as there is not > a > session anywhere to be found here. Arguably this is twisting it into a > database update protocol. The distiguished name of the element to be > written > is in the request URI, and the body of the request contains the value of > tat > element: > > SETDATA sip:jdrosen.scripts.cpl@dynamicsoft.com SIP/2.0 > Content-Type: application/cpl+xml > Content-Length: 102 > > > ..... > > > I assure you that I want nothing less than to use SIP as an LDAP > alternative. > > > Comments? > > -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 jdrosen@dynamicsoft.com Sun Jun 10 00:33:45 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20636 for ; Sun, 10 Jun 2001 00:33:45 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA05408; Sun, 10 Jun 2001 00:37:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Jun 2001 00:33:43 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Sun, 10 Jun 2001 00:33:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 4303 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Friday, June 08, 2001 3:36 PM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > Perhaps the most flexible and least like a specific database-update > protocol is SOAP over SIP. This could be used for setting CPL, > authorizing watchers, or whatever else, by documenting the appropriate > SOAP method in each case, but would not necessarily imply a general > purpose database protocol. > > For example something like this could be used to authorize watchers: > > SERVICE sip:roberbr@microsoft.com SIP/2.0 > To: sip:microsoft.com > From: roberbr@microsoft.com > Content-Type: text/xml+authorizewatcher > Content-Length: XXX > > xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/' > > > > SIP:max@someplace.com > allow > > > I really fail to see what value SOAP brings here to the table. It seems to combine the worst of everything - its still an abuse of SIP and yet still requires additional code on the clients beyond baseline SIP. As far as slippery-slopes go, if INFO seemed a problem (and it has been proposed for all kinds of awful things), SERVICE is going to be even worse. Please lets not. Henning writes: > I fail to see the technical difference between direct-routed > SIP/TCP and > HTTP in terms of efficiency. Perhaps for data push its not signficantly different. For data pull, I can make some arguments about the existence of caches, special treatment in routers, etc. which generally make http better for bulk data fetch. > It requires making assumptions on creating artificial namespaces, > particularly if you want to run a "real" HTTP server on the > same host. I > don't know what mapping you have in mind, but if you do something like > > foo@host.com -> host.com/foo or host.com/some/fixed/magic/path/foo > > this pretty much rules out running a 'real' HTTP server on > the same host > (it's not clear how you'd map port numbers to anything but > the default, > except with some explicit SIP header making the association). It doesn't rule it out; presumably there is only the "real" web server, and this server is running a cgi script for all requests for host.com/some/fixed/magic/path/*, placing the scripts into the appropriate place in the DB. The real disadvantage is that we will need to define this standardized mapping. > > Approach (3) stems from this argument. We use SIP, but > define a separate > > method. This method can be specific for uploading of authorization > > documents, or can be more general. Presumably, we would > want to use it for > > CPL uploads and authorization document uploads, if we go > this route. What > > I don't necessarily see that the methods have to be the same, > but that's > a minor issue. We should use the Content-Disposition to indicate the > property to be set for a particular user. Perhaps a reasonable compromise point is to use a SIP method, but keep it specific for uploading of authorization policies. This avoids the abuse and slippery slope issues of SERVICE or SETDATA, both of which make me nervous. So: AUTH sip:jdrosen@dynamicsoft.com SIP/2.0 Content-Type: application/xml+authdata Content-Length: 290 ..... AUTH would have the explicit purpose of setting authorization documents that define access to the resource in the request URI for any method. The content-type (or a content-disposition) would give further information on what methods the authorization document applies to. This is probably a broad enough definition to include CPL (which is, after all, a form of an authorization document for a URL), but narrow enough to exclude more general DB operations, or worse. -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 From christian@hotsip.com Sun Jun 10 11:24:16 2001 Received: from hs004.hotsip.com ([212.28.214.197]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22347 for ; Sun, 10 Jun 2001 11:24:15 -0400 (EDT) Received: from 0 ([212.28.212.219]) by hs004.hotsip.com (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f5ADOBc21187; Sun, 10 Jun 2001 15:24:12 +0200 Message-Id: <200106101324.f5ADOBc21187@hs004.hotsip.com> X-Authentication-Warning: hs004.hotsip.com: Host [212.28.212.219] claimed to be 0 Content-Transfer-Encoding: 8bit Subject: Re: [Simple] Thoughts on uploading authorization documents Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: <002801c0f051$9605beb0$7a10100a@ffocp800> From: Christian Jansson Date: Sun, 10 Jun 2001 18:26:39 +0100 To: =?iso-8859-1?q?=22Francois-Frederic?= =?iso-8859-1?q?_Ozog=22?= Cc: simple@mailman.dynamicsoft.com User-Agent: IMHO/0.98.2 (Webmail for Roxen) Content-Length: 8028 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: Francois-Frederic Ozog wrote: > I have conceptual and technical issues about HTTP POST. > Building on two protocols SIP and HTTP to provide SIMPLE service > does not look elegant: it should be either full SIP or full HTTP. Why is the use of two protocols not elegant? Is the use of DNS + HTTP a non-elegant solution for using the web? Would you rather go for full HTTP there too? I think one should use the best suited protocol to solve the given task, and in this case the task is not to set up a session. > > HTTP POST is not be available on all devices, for example a WAP > J2ME device does not have HTTP stack. Presence would require it in > addition to the SIP stack wich maight cause footprint problems. > One could argue we could just use the POST format, but it still > requires a TCP stack, but again TCP may not be available... So you have small device (small footprint requirement) running a presence app. Is it absolutely necessary to also manage the authorization from that device? (ok, probably it would be nice) Consider a SIP app running on UDP or TCP. I'm not into J2ME but can you have UDP support without TCP? And if you don't have a complete HTTP stack, isn't it possible to reuse the header parsing stuff from the SIP app to minimize the total footprint? Christian Jansson Hotsip http://www.hotsip.com > Similarly SOAP would require implementation of components that may > not be suitable for the J2ME device. > Basic XML is sufficient. > > > > > > > > -----Original Message----- > > From: Christian Huitema > > To: Henning Schulzrinne; Jonathan Rosenberg > > Cc: simple@mailman.dynamicsoft.com > > Sent: 6/8/2001 10:39 AM > > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > I think it would be more efficient to just use SOAP, and carry it either > > over HTTP, or over SIP using a "service" verb. > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Friday, June 08, 2001 4:39 AM > > > To: Jonathan Rosenberg > > > Cc: 'simple@mailman.dynamicsoft.com' > > > Subject: Re: [Simple] Thoughts on uploading authorization documents > > > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > Folks, > > > > > > > > As I have mentioned in other emails, the largest open issue at the > > > moment > > > > with the proposed watcherinfo authorization mechanism is how the > > > > authorization document gets uploaded to the server. Three things > > have > > > been > > > > proposed: > > > > > > > > 1. HTTP POST > > > > 2. SIP REGISTER > > > > 3. SIP , call it SETDATA for now > > > > > > > > The benefit of using HTTP POST is that HTTP is far more suitable as > > a > > > pure > > > > data transfer protocol, and this is exactly the scenario we are > > talking > > > > > > I fail to see the technical difference between direct-routed SIP/TCP > > and > > > HTTP in terms of efficiency. > > > > > > > about here. The drawback is that we need to authenticate the upload > > of > > > the > > > > document, and the credentials for that will presumably be within the > > > > databases used for SIP level authentication. Tying the identity in > > an > > > HTTP > > > > POST request to a SIP identity is a little more complex, but not > > > impossible. > > > > > > It requires making assumptions on creating artificial namespaces, > > > particularly if you want to run a "real" HTTP server on the same host. > > I > > > don't know what mapping you have in mind, but if you do something like > > > > > > foo@host.com -> host.com/foo or host.com/some/fixed/magic/path/foo > > > > > > this pretty much rules out running a 'real' HTTP server on the same > > host > > > (it's not clear how you'd map port numbers to anything but the > > default, > > > except with some explicit SIP header making the association). > > > > > > Also, with DNS SRV, you have to be really careful that the two > > mappings > > > are similar (assuming we'd be using SRV here; if not, this is a > > separate > > > disadvantage in terms of naming and scaling). > > > > > > > Another drawback is the standard "but I don't want to implement yet > > > another > > > > protocol in my device" argument. > > > > > > > > Approach (2) is already in use for uploading of scripts. The > > benefit is > > > > exactly that it is already defined. However, many people think this > > is a > > > bit > > > > of an abuse of REGISTER, which is really meant to convey address > > > bindings, > > > > not upload arbitrary documents. One can imagine a case where you > > have a > > > > REGISTER with Contacts and a CPL script. This REGISTER might fail > > > because > > > > (1) the contact list had some kind of problem, or (2) the CPL had > > some > > > kind > > > > of problem. Since the request might fail for two very independent > > > reasons, > > > > response handling becomes complex. Indeed, this is generally a sign > > that > > > > something should be its own method. > > > > > > > > Approach (3) stems from this argument. We use SIP, but define a > > separate > > > > method. This method can be specific for uploading of authorization > > > > documents, or can be more general. Presumably, we would want to use > > it > > > for > > > > CPL uploads and authorization document uploads, if we go this route. > > > What > > > > > > I don't necessarily see that the methods have to be the same, but > > that's > > > a minor issue. We should use the Content-Disposition to indicate the > > > property to be set for a particular user. > > > > > > > both of these share is that the method is setting the value for a > > > specific, > > > > well defined document that the user can specify. THus, it is > > "setting > > > data". > > > > The primary drawback is that this is a real abuse of SIP; as there > > is > > > not a > > > > session anywhere to be found here. Arguably this is twisting it into > > a > > > > database update protocol. The distiguished name of the element to be > > > written > > > > is in the request URI, and the body of the request contains the > > value of > > > tat > > > > element: > > > > > > > > SETDATA sip:jdrosen.scripts.cpl@dynamicsoft.com SIP/2.0 > > > > > > I would not modify the SIP URL. This should be associated directly > > with > > > the same identifier, not munging the URL in some arbitrary way which > > > creates restrictions on naming users. > > > > > > > Content-Type: application/cpl+xml > > > > Content-Length: 102 > > > > > > > > > > > > ..... > > > > > > > > I assure you that I want nothing less than to use SIP as an LDAP > > > > alternative. > > > > > > > > Comments? > > > > > > > > -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 > > > ______________________________________________________________________ ________ > ifrance.com, l'email gratuit le plus complet de l'Internet ! > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... > http://www.ifrance.com/_reloc/email.emailif > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From roberbr@microsoft.com Sun Jun 10 21:08:05 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id VAA23860 for ; Sun, 10 Jun 2001 21:08:05 -0400 (EDT) Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 10 Jun 2001 18:07:21 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 10 Jun 2001 18:06:10 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Simple] Thoughts on uploading authorization documents X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Sun, 10 Jun 2001 18:06:10 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320CB93@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Thoughts on uploading authorization documents Thread-Index: AcDxZov3c269PNq8QuSwxqy2y2k74QAq8ijQ From: "Robert Brown" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 11 Jun 2001 01:06:10.0826 (UTC) FILETIME=[B3EB76A0:01C0F212] Content-Length: 1337 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id VAA23860 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: > AUTH sip:jdrosen@dynamicsoft.com SIP/2.0 > Content-Type: application/xml+authdata > Content-Length: 290 AUTH is simple and flexible. Both good things. But is it so flexible that it will end up encouraging the things you're trying to avoid? While the description of AUTH is narrow enough to hopefully discourage abuse, it seems that the semantics of AUTH depend entirely on the content-type. I imagine valid AUTH requests like the following two examples may cause some discomfort... AUTH sip:roberbr@microsoft.com SIP/2.0 Content-Type: text/xml+soapenvelope ... It's unclear whether this method actually does authorization. But, like CPL, it does affect the way requests are processed for some URIs, so I figured this content type is OK too... ...And having already taken a step on the slippery slope... AUTH sip:roberbr@microsoft.com SIP/2.0 Content-Type: text/xml+soapenvelope ... foo 1234 From schulzrinne@cs.columbia.edu Sun Jun 10 21:13:49 2001 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 VAA23909 for ; Sun, 10 Jun 2001 21:13:49 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA17409; Sun, 10 Jun 2001 21:13:49 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id VAA17531; Sun, 10 Jun 2001 21:13:48 -0400 (EDT) Message-ID: <3B241B0A.FB81ABD0@cs.columbia.edu> Date: Sun, 10 Jun 2001 21:12:42 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.77 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Robert Brown'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Thoughts on uploading authorization documents References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2114 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: > Henning writes: > > I fail to see the technical difference between direct-routed > > SIP/TCP and > > HTTP in terms of efficiency. > > Perhaps for data push its not signficantly different. For data pull, I can > make some arguments about the existence of caches, special treatment in > routers, etc. which generally make http better for bulk data fetch. Special treatment in routers? Which router vendor are you using? (I knew layer violation was common, but routers peeking at HTTP headers is new to me...) Caches don't apply here, as this is not static data, but rather similar to HTTP cgi-bin and other non-cacheable content. > It doesn't rule it out; presumably there is only the "real" web server, and > this server is running a cgi script for all requests for > host.com/some/fixed/magic/path/*, placing the scripts into the appropriate > place in the DB. The real disadvantage is that we will need to define this > standardized mapping. And we have to make sure that every server and installation can do this easily. For example, locally, such scripts would have to be at http://www.cs.columbia.edu/~user_running_server. Plus, you'll have to be root to run web servers on port 80, so there's yet another configuration issue. > > Perhaps a reasonable compromise point is to use a SIP method, but keep it > specific for uploading of authorization policies. This avoids the abuse and > slippery slope issues of SERVICE or SETDATA, both of which make me nervous. > So: > > AUTH sip:jdrosen@dynamicsoft.com SIP/2.0 > Content-Type: application/xml+authdata > Content-Length: 290 > > ..... > > AUTH would have the explicit purpose of setting authorization documents that > define access to the resource in the request URI for any method. The > content-type (or a content-disposition) would give further information on > what methods the authorization document applies to. > > This is probably a broad enough definition to include CPL (which is, after > all, a form of an authorization document for a URL), but narrow enough to > exclude more general DB operations, or worse. This seems about right. From jdrosen@dynamicsoft.com Mon Jun 11 00:07:22 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24389 for ; Mon, 11 Jun 2001 00:07:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02390; Mon, 11 Jun 2001 00:11:20 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 00:07:20 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Mon, 11 Jun 2001 00:07:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1419 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Sunday, June 10, 2001 9:06 PM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > AUTH sip:jdrosen@dynamicsoft.com SIP/2.0 > > Content-Type: application/xml+authdata > > Content-Length: 290 > > AUTH is simple and flexible. Both good things. > > But is it so flexible that it will end up encouraging the > things you're > trying to avoid? While the description of AUTH is narrow enough to > hopefully discourage abuse, it seems that the semantics of AUTH depend > entirely on the content-type. Generality and flexibility is a two-edged sword. On the one hand, it allows you to do things you hand't previously thought of. At the same time, it opens things up for misuse. Finding the right balance is a very tough task. I think this thread is all about feeling out where that line is. I think AUTH is getting closer, but of course nothing can prevent it from being abused. -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 From jdrosen@dynamicsoft.com Mon Jun 11 00:19:14 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24462 for ; Mon, 11 Jun 2001 00:19:14 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02487; Mon, 11 Jun 2001 00:23:10 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 00:19:10 -0400 Message-ID: From: Jonathan Rosenberg To: "'Oded Cna'an'" , "SIMPLE Mail List (E-mail)" Cc: "Avner Ronen (E-mail)" , "Gabriel Matsliach (E-mail)" Subject: RE: [SIMPLE] Presence Authorization Date: Mon, 11 Jun 2001 00:19:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Content-Length: 6534 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: > -----Original Message----- > From: Oded Cna'an [mailto:oded@odigo.com] > Sent: Wednesday, June 06, 2001 10:18 AM > To: SIMPLE Mail List (E-mail) > Cc: Avner Ronen (E-mail); Gabriel Matsliach (E-mail) > Subject: [SIMPLE] Presence Authorization > > > Hi, > > A general presence server (PS), in my view, handles 3 basic tasks: > > 1. Collection and aggregation of presence information - a PS > updates the > presence information by both connecting to different > 'sensors' (location > servers, reachability servers, velocity servers etc.) and > receiving updates > from presentities as to their status (availability, location etc.). > > Presence information is aggregated so that the server holds the latest > presence state of a presentity based on all the UAs currently > registered. > > 2. Manage subscription (not authorization) of entities that > wish to receive > presence notifications on specific presentities. These > entities must already > be approved to receive notifications. > > 3. Issuing notifications to watchers whenever the presence information > changes. Normally, a presence server would also support > querying of presence > information as defined in RFC 2778. I think they do handle authorization, but I strongly feel that how the authorization is done can, and should, be extremely flexible. The proposed watcherinfo provides one, and only one, means for authorization that is needed to solve an important common case (which is why we factor it out into a separate and orthogonal document set). > > > Presence servers work hand in hand with applications that > require presence > info (e.g., IM, UM, call routing, content delivery etc.) in a > way that these > applications supply the logic part and the PS takes care of presence > collection and distribution. The main point is that these services are > separated from the PS. I agree 100%. In fact, you should have a look at the application component architecture for SIP: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-app-components-01 .txt which is all about the separation of applications from application-unaware components, including media servers, conferencing servers, and presence servers. > > If we take a SIMPLE based IM service as an example, this > service requires an > implicit/explicit login/logout actions, manages message routing (and > possibly storing) and is the interface for presence information. > > The translation of these operations into a SIMPLE work flow > can be done as > follows (although this is not the only way): > > > UA IM PS > | REGISTER | | > |------------------->| REGISTER | > | |------------->| > | | 200 OK | > | 200 OK |<-------------| > |<-------------------| | > | | | > | SUBSCRIBE | | > |------------------->| SUBSCRIBE | > | |------------->| > | | 200 OK | > | 200 OK |<-------------| > |<-------------------| | > | | NOTIFY | > | NOTIFY |<-------------| > |<-------------------| | > | | | > | MESSAGE | | OTHER UA > |------------------->| MESSAGE | > | |---------------------------->| > | | | | > | | 200 OK | > | 200 OK |<----------------------------| > |<-------------------| | | > > > As shown above, the actions are performed against the service > (in this case > IM) that passes them (if appropriate) to the PS. > > Subscription authorization, in the general case, is related > to a service and > not the PS. Absolutely. However, the PS still needs to do authorization, but of a different sort. In this model, the PS needs to authorize that the subscription is coming from a trusted application (in this case, the IM service). That is generally accomplished in SIP using transport layer security techniques. The IM service would have a secure connection to the PS, using SSL/TLS. The authorization policy of the PS would be to accept all subscriptions that come over this connection. The IM service would handle the service level authorization, as you describe. As an example, let's say that I am connected to 2 > different > services (IM and UM) that use the same PS as their back > office (a typical > scenario for mobile operators and enterprises). Approving > subscription to > user a@b on the UM service does not mean that I approve > subscription to that > user on the IM service. While I agree in principle, practically speaking, this is not going to provide real security. If I want to get at your presence for IM, but you refuse, I can simply ask for your presence for UM, get accepted, and then use that information for other purposes. > > The above analysis dictates a solution in which the service > is responsible > for the subscription authorization and the presence server is > informed by > the service, which users can receive presence info on a > certain presentity > (subject to PS provisioning). > > This approach, that separates between the services and the PS > was adopted by > the PAM forum and is at the basis of the PAM API. I hope I have been clear in that I don't think what you are proposing is at odds in any way with the SIMPLE model. In your case, you would simply not use the watcherinfo based authorization. Instead, your authorization is based on transitive trust between and application and the presence server. Standard ways in SIP exist to establish such a relationship. Of course, how the application makes its decision on authorization is also an implementation decision, and there is nothing that would prevent you from running PAM for this purpose. -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 From ndeason@ubiquity.net Mon Jun 11 10:17:23 2001 Received: from firewall.ubiquity.ca ([209.167.187.162]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA01138 for ; Mon, 11 Jun 2001 10:17:19 -0400 (EDT) Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca via smtpd (for [216.173.40.35]) with SMTP; 11 Jun 2001 15:17:07 UT Received: (private information removed) Message-ID: From: Neil Deason To: Jonathan Rosenberg , "'Robert Brown'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Mon, 11 Jun 2001 09:49:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 6474 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: > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan > Rosenberg > Sent: 11 June 2001 05:07 > To: 'Robert Brown'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > -----Original Message----- > > From: Robert Brown [mailto:roberbr@microsoft.com] > > Sent: Sunday, June 10, 2001 9:06 PM > > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > > > > AUTH sip:jdrosen@dynamicsoft.com SIP/2.0 > > > Content-Type: application/xml+authdata > > > Content-Length: 290 > > > > AUTH is simple and flexible. Both good things. > > > > But is it so flexible that it will end up encouraging the > > things you're > > trying to avoid? While the description of AUTH is narrow enough to > > hopefully discourage abuse, it seems that the semantics of > AUTH depend > > entirely on the content-type. > > Generality and flexibility is a two-edged sword. On the one > hand, it allows > you to do things you hand't previously thought of. At the > same time, it > opens things up for misuse. Finding the right balance is a > very tough task. > I think this thread is all about feeling out where that line > is. I think > AUTH is getting closer, but of course nothing can prevent it > from being > abused. On this philosophical point I take the view that flexibility for unforeseeable good things is better. We are not the protocol police and neither should we be the thought police. What strikes me about the above is that whether you use a method name of AUTH or SERVICE make little difference, it is the content type that really matters. The additional definition of a specific content type application/xml+authdata would be required to try and make the misuse of things harder (it is never impossible) at the acknowledged cost of limiting flexibility. How about tossing another idea into the melting pot for discussion. The authorization service could be specified using Web Services Description Language (WSDL). This allow a great deal of flexibility but still provides reasonable control over how we solve the immediate problem. The details of WSDL data types, messages, operations and sets of operations for authorization could be defined within a namespace described by a doc created here and owned by the IETF. This document can then be imported into a WSDL describing the implementation of a presence authorization service by anyone seeking to support it. The actual binding supplied by each vendor can specify the details of their implementation of the authorization service. Implementations can choose to make the presence authorization service available through any interface that has a WSDL binding schema. This could be SOAP over HTTP, SOAP over SIP (for SIP/UDP only supporting clients), HTTP POST (for non SOAP supporting clients), even SIP alone if the binding was defined. There is no restriction on the number of bindings a service provider makes available. Also within their own WSDL implementors can take advantage of extensibility to provide value add differentiators as they see fit. Meanwhile the standard components can evolve within the IETF namespace document over time. So for a simple (and doubtless buggy) example the following document describes a trivial watcher authorization methods and operation. There is a single operation - AuthorizeWatcher with takes the input of the watcher ID (string) and authorization status (boolean) and the output is string describing the result. This abstract description of the service would be defined by the SIMPLE WG/IETF. http://schemas.ietf.org/simple/presenceauthorization.wsdl This can then be used in specific implementations to provide a standard interface into a SIMPLE authorization service. Implementors provide access to their service by publishing a WSDL doc built on top of the above. This example provides an implementation using a SOAP/HTTP binding but others interfaces to the service could easily be added within the same WSDL. http://www.example.com/presenceauthorizationservice.wsdl A Watcher Authorization Service using SOAP over HTTP Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net From roberbr@microsoft.com Mon Jun 11 12:23:23 2001 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA01514 for ; Mon, 11 Jun 2001 12:23:19 -0400 (EDT) Received: from 157.54.7.67 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Jun 2001 08:45:50 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 11 Jun 2001 08:45:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Mon, 11 Jun 2001 08:45:47 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320CB98@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Thoughts on uploading authorization documents Thread-Index: AcDyLAYGfn+wRORVTi+iyhZ6xGcriAAYSD6g From: "Robert Brown" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 11 Jun 2001 15:45:48.0306 (UTC) FILETIME=[95BFCF20:01C0F28D] Content-Length: 1880 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA01514 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: Sorry, but I fail to see the technical distinction between AUTH and SERVICE. There has to be more than just the name of the method. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, June 10, 2001 9:07 PM > To: Robert Brown; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > > > > -----Original Message----- > > From: Robert Brown [mailto:roberbr@microsoft.com] > > Sent: Sunday, June 10, 2001 9:06 PM > > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > > > > AUTH sip:jdrosen@dynamicsoft.com SIP/2.0 > > > Content-Type: application/xml+authdata > > > Content-Length: 290 > > > > AUTH is simple and flexible. Both good things. > > > > But is it so flexible that it will end up encouraging the > > things you're > > trying to avoid? While the description of AUTH is narrow enough to > > hopefully discourage abuse, it seems that the semantics of AUTH depend > > entirely on the content-type. > > Generality and flexibility is a two-edged sword. On the one hand, it > allows > you to do things you hand't previously thought of. At the same time, it > opens things up for misuse. Finding the right balance is a very tough > task. > I think this thread is all about feeling out where that line is. I think > AUTH is getting closer, but of course nothing can prevent it from being > abused. > > -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 From root@mail3.aweber.com Mon Jun 11 13:44:37 2001 Received: from mail1.aweber.com ([64.35.105.180]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01756 for ; Mon, 11 Jun 2001 13:44:36 -0400 (EDT) Date: Mon, 11 Jun 2001 13:44:36 -0400 (EDT) Message-Id: <200106111744.NAA01756@mailman.dynamicsoft.com> To: "" From: "Eric Brown" X-Loop: lovehomebiz@aweber.com X-Remote-Host: X_Id: 16549:1:simple@mailman.dynamicsoft.com Content-type: text/html Content-Length: 5492 Subject: [Simple] FW: (( What do you think?))Get Started Ear... 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: Earn Over $4000.00 In Just 39 Days!

In 39 Months I’ve Earned

OVER $400,000.00!!!*

_______________________________

 

In 39 Days YOU CAN Earn

OVER $4,000.00!!

 

Call NOW For More Details:

(877) 910-2095

www.LoveHomeBiz.com

* Earnings of $400,000.00+ will be documented upon request!

 


To stop additional follow up messages click here

From ajaych@windows.microsoft.com Mon Jun 11 15:04:46 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA02012 for ; Mon, 11 Jun 2001 15:04:45 -0400 (EDT) Received: from 157.54.9.108 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Jun 2001 12:04:38 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 11 Jun 2001 12:04:33 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 11 Jun 2001 12:03:59 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 11 Jun 2001 12:02:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 11 Jun 2001 12:02:44 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC121B8BC@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: simultaneous message transactions Thread-Index: AcDyqUTfzfS9NjZBS2inLdzRf63YPg== From: "Ajay Chitturi" To: X-OriginalArrivalTime: 11 Jun 2001 19:02:44.0934 (UTC) FILETIME=[19022660:01C0F2A9] Content-Length: 880 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA02012 Subject: [Simple] simultaneous message transactions 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: Hi, Does the protocol allow for simultaneous message transactions within the same call leg ? With UDP, the requests could be received out of order. Even with TCP / TLS, a proxy server could reorder the requests (if the requests are sent in quick succession). The receiver will reject a message with a lower cseq value than the highest cseq it has seen for the call leg. Having the sender serialize the message transactions is one solution but it is inefficient. Another option would be to wait for a limited timeout before we process a message request with a non-contiguous cseq. But in a sceanrio where the proxy authenticates the requests, the cseqs on the receiver side will always be non-contiguous. It would be good to have a cseq that is guaranteed to be contiguous on the receiver side. I was wondering what other implementations are doing on this issue. Thanks Ajay. From jdrosen@dynamicsoft.com Mon Jun 11 18:22:41 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02599 for ; Mon, 11 Jun 2001 18:22:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA14956; Mon, 11 Jun 2001 18:26:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 18:22:39 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Mon, 11 Jun 2001 18:22:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 1341 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Monday, June 11, 2001 11:46 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > Sorry, but I fail to see the technical distinction between AUTH and > SERVICE. There has to be more than just the name of the method. Of course. The distinction is in what it does. AUTH uploads a policy document that is enabled to define who is able to access the resources at the URI specified in the method of the AUTH request. There can be separate types of policy docs, but you can't just put any old thing in there. This method would preclude someone from, say, setting the value of a variable, or invoking a media resource. People could abuse it to do other things, but it won't be interoperable across products, since correct implementations would only accept policy documents, not arbitrary RPC requests. -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 From ndeason@ubiquity.net Tue Jun 12 05:49:34 2001 Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA01256 for ; Tue, 12 Jun 2001 05:49:33 -0400 (EDT) Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca via smtpd (for [216.173.40.35]) with SMTP; 12 Jun 2001 10:49:23 UT Received: (private information removed) Message-ID: From: Neil Deason To: Jonathan Rosenberg , "'Robert Brown'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Tue, 12 Jun 2001 05:34:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3210 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: > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan > Rosenberg > Sent: 11 June 2001 23:23 > To: 'Robert Brown'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > -----Original Message----- > > From: Robert Brown [mailto:roberbr@microsoft.com] > > Sent: Monday, June 11, 2001 11:46 AM > > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > > > Sorry, but I fail to see the technical distinction between AUTH and > > SERVICE. There has to be more than just the name of the method. > > Of course. The distinction is in what it does. AUTH uploads a policy > document that is enabled to define who is able to access the > resources at > the URI specified in the method of the AUTH request. There > can be separate > types of policy docs, but you can't just put any old thing in > there. Well anything with a legal media-type is allowed in any SIP request. Which includes, amongst many other, things SOAP requests described as text/xml. > This > method would preclude someone from, say, setting the value of > a variable, or > invoking a media resource. People could abuse it to do other > things, but it > won't be interoperable across products, since correct > implementations would > only accept policy documents, not arbitrary RPC requests. As I said on my previous post on this thread it is the content type that is really important not the method name. So putting to one side the issue of the many different allowed content types there is a nastier problem lurking if you hope to act as the thought police by defining some authdata XML schema to limit usage. Presumably authdata would follow CPL and allow extensions through XML namespaces. Thus you enable something that is designed to be authorization specific to be easily reused for non authorization things. Definite misuse but people will do it as it is there to be done and the bar is low. The results may not be interoperable but what happens if it turns out to actually provide a popular feature and we want to standardise it later to provide interoperability. There is a user base in existence with an implementation based on over loading an inappropriate mechanism like CPL or authdata. I would prefer to provide a more appropriate mechanism as a starting point for inventiveness through something like SOAP. Within this generic mechanism things that need to be defined as interoperable can be still be specified. In my other posting on this thread I gave an example of one way this could be done using WSDL for presence authorization. Other things may not even be specified but at least they can be implemented in a more appropriate manner. Maybe some even prove to be good ideas and get incorporated into standards later based on sensible implementations. Rather than a good idea becoming widespread based on popularisation of a misguided implementation over-loading something like authdata. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net From odedcn@netvision.net.il Tue Jun 12 09:43:17 2001 Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01886 for ; Tue, 12 Jun 2001 09:43:15 -0400 (EDT) Received: from odedlap ([212.150.9.195]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with SMTP id QAA13508; Tue, 12 Jun 2001 16:45:01 +0300 (IDT) From: "Oded" To: "'Jonathan Rosenberg'" , "'SIMPLE Mail List (E-mail)'" Cc: "'Avner Ronen (E-mail)'" , "'Gabriel Matsliach (E-mail)'" Subject: RE: [SIMPLE] Presence Authorization Date: Tue, 12 Jun 2001 16:38:54 +0200 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Content-Length: 8939 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: The debate over how to upload and retrieve watcherinfo documents assumes that these lists should be stored on the presence server while it seems much more logical to store these lists on the services (IM/ UM etc.). In the context of presence to an IM service (this example applies to a more general service as well) 3 basic lists may exist: 1. Permit list - users that can receive presence on a certain presentity (allowed) 2. Deny list - users that should not receive presence (blocked) 3. Waiting authorization list - users that were not approved yet to receive presence (pending) Usually, only one of the first two lists would be active/implemented. The presence server (PS) should be defined as an application that supplies presence services to real applications (presence providers/consumers). The logic of how to handle these lists is usually different among services and thus cannot reside on the PS itself. The presence server need not know anything about the subscription authorization process (that can be different from one service to another). When user A approves to reveal his presence to user B, the service(!) adds B to A's permit list and notifies the PS. Note also, that some services may not implement a deny list, and some even not require subscription authorization. In other words, since the PS cannot know in advance which applications will be using it and their internal logic, it should leave the logic to the services. Jonathan, in your comments you imply that in a certain implementation, the service can manage authorization and the PS may use an 'accept all' policy. The problem is that this implementation will not be compatible with other implementations that implement authorization on the PS and not in the service. It's important that SIMPLE defines where these lists are managed and who to contact to manage them. To conclude, SIMPLE should define how to upload/retrieve watcherinfo documents, but this command should be performed against the service and not the presence server. I agree that presence servers may be allowed to manage these lists but the protocol should encourage doing it on the service level, as a main stream approach. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, June 11, 2001 6:19 AM To: 'Oded Cna'an'; SIMPLE Mail List (E-mail) Cc: Avner Ronen (E-mail); Gabriel Matsliach (E-mail) Subject: RE: [SIMPLE] Presence Authorization > -----Original Message----- > From: Oded Cna'an [mailto:oded@odigo.com] > Sent: Wednesday, June 06, 2001 10:18 AM > To: SIMPLE Mail List (E-mail) > Cc: Avner Ronen (E-mail); Gabriel Matsliach (E-mail) > Subject: [SIMPLE] Presence Authorization > > > Hi, > > A general presence server (PS), in my view, handles 3 basic tasks: > > 1. Collection and aggregation of presence information - a PS > updates the > presence information by both connecting to different > 'sensors' (location > servers, reachability servers, velocity servers etc.) and > receiving updates > from presentities as to their status (availability, location etc.). > > Presence information is aggregated so that the server holds the latest > presence state of a presentity based on all the UAs currently > registered. > > 2. Manage subscription (not authorization) of entities that > wish to receive > presence notifications on specific presentities. These > entities must already > be approved to receive notifications. > > 3. Issuing notifications to watchers whenever the presence information > changes. Normally, a presence server would also support > querying of presence > information as defined in RFC 2778. I think they do handle authorization, but I strongly feel that how the authorization is done can, and should, be extremely flexible. The proposed watcherinfo provides one, and only one, means for authorization that is needed to solve an important common case (which is why we factor it out into a separate and orthogonal document set). > > > Presence servers work hand in hand with applications that > require presence > info (e.g., IM, UM, call routing, content delivery etc.) in a > way that these > applications supply the logic part and the PS takes care of presence > collection and distribution. The main point is that these services are > separated from the PS. I agree 100%. In fact, you should have a look at the application component architecture for SIP: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-app-components-01 .txt which is all about the separation of applications from application-unaware components, including media servers, conferencing servers, and presence servers. > > If we take a SIMPLE based IM service as an example, this > service requires an > implicit/explicit login/logout actions, manages message routing (and > possibly storing) and is the interface for presence information. > > The translation of these operations into a SIMPLE work flow > can be done as > follows (although this is not the only way): > > > UA IM PS > | REGISTER | | > |------------------->| REGISTER | > | |------------->| > | | 200 OK | > | 200 OK |<-------------| > |<-------------------| | > | | | > | SUBSCRIBE | | > |------------------->| SUBSCRIBE | > | |------------->| > | | 200 OK | > | 200 OK |<-------------| > |<-------------------| | > | | NOTIFY | > | NOTIFY |<-------------| > |<-------------------| | > | | | > | MESSAGE | | OTHER UA > |------------------->| MESSAGE | > | |---------------------------->| > | | | | > | | 200 OK | > | 200 OK |<----------------------------| > |<-------------------| | | > > > As shown above, the actions are performed against the service > (in this case > IM) that passes them (if appropriate) to the PS. > > Subscription authorization, in the general case, is related > to a service and > not the PS. Absolutely. However, the PS still needs to do authorization, but of a different sort. In this model, the PS needs to authorize that the subscription is coming from a trusted application (in this case, the IM service). That is generally accomplished in SIP using transport layer security techniques. The IM service would have a secure connection to the PS, using SSL/TLS. The authorization policy of the PS would be to accept all subscriptions that come over this connection. The IM service would handle the service level authorization, as you describe. As an example, let's say that I am connected to 2 > different > services (IM and UM) that use the same PS as their back > office (a typical > scenario for mobile operators and enterprises). Approving > subscription to > user a@b on the UM service does not mean that I approve > subscription to that > user on the IM service. While I agree in principle, practically speaking, this is not going to provide real security. If I want to get at your presence for IM, but you refuse, I can simply ask for your presence for UM, get accepted, and then use that information for other purposes. > > The above analysis dictates a solution in which the service > is responsible > for the subscription authorization and the presence server is > informed by > the service, which users can receive presence info on a > certain presentity > (subject to PS provisioning). > > This approach, that separates between the services and the PS > was adopted by > the PAM forum and is at the basis of the PAM API. I hope I have been clear in that I don't think what you are proposing is at odds in any way with the SIMPLE model. In your case, you would simply not use the watcherinfo based authorization. Instead, your authorization is based on transitive trust between and application and the presence server. Standard ways in SIP exist to establish such a relationship. Of course, how the application makes its decision on authorization is also an implementation decision, and there is nothing that would prevent you from running PAM for this purpose. -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 From adam.roach@ericsson.com Tue Jun 12 12:04:27 2001 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 MAA02342 for ; Tue, 12 Jun 2001 12:04:27 -0400 (EDT) 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 f5CG4Ia08983; Tue, 12 Jun 2001 11:04:18 -0500 (CDT) 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 f5CG4HG06287; Tue, 12 Jun 2001 11:04:17 -0500 (CDT) Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA19081; Tue, 12 Jun 2001 11:04:17 -0500 (CDT) Reply-To: To: "'Jonathan Rosenberg'" , "'Robert Brown'" , "Theodore Havinis" , Subject: RE: [Simple] authorization for presence Date: Tue, 12 Jun 2001 11:04:13 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251831@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 V4.72.3612.1700 Content-Length: 1379 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: I'll make an effort to clear up some confusion here. > > 2 - I'm a little wary of coupling the current authorization > state with > > the list of pending authorization requests. This can lead to > > very large > > auth request messages when users have large numbers of watchers. > > I do not understand what you are saying here. > > One of the issues which is going to plague us in our > discussions is common > terminology. THis is especially important when talking about recursive > subscription state, which is what watcherinfo is. I do not > know what you > mean by "authorization state" or "list of pending > authorization requests". I > suppose the former is the watcherinfo state. I don't know > what the latter > is. Currently, we define "watcherinfo" to conatain current and pending subscriptions. (Jonathan, you use this distinction later in this same post, in the context of: "That means the notifications contain the current watcherinfo state, which is the set of people who have active or pending subscriptions to me.") I beleive what Robert is proposing is that this be considered two completely different sets of state: active subscriptions to a state, and pending subscriptions to a state. I have no opinion on the topic, but wanted to get a feel for group consensus so that whoever writes the watcherinfo draft has an idea of how to craft it. /a From adam.roach@ericsson.com Tue Jun 12 12:11:15 2001 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 MAA02396 for ; Tue, 12 Jun 2001 12:11:15 -0400 (EDT) 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 f5CGB7a12864; Tue, 12 Jun 2001 11:11:07 -0500 (CDT) 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 f5CGB7V29111; Tue, 12 Jun 2001 11:11:07 -0500 (CDT) Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA19523; Tue, 12 Jun 2001 11:11:07 -0500 (CDT) Reply-To: To: "'Robert Brown'" , "Theodore Havinis" , "Jonathan Rosenberg" , , "'Francois-Frederic Ozog'" Subject: RE: [Simple] authorization for presence Date: Tue, 12 Jun 2001 11:11:06 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251832@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: <8DC4B82A94A29D4AB708F05E0EB557AB025C3297@red-msg-05.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Length: 1162 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: Some recent posts have made it clear that the subpackage proposal may be widely misunderstood. I'll attempt to clarify a couple of points. > NOTIFY sip:peter@bar.com SIP/2.0 > From: sip:bar.com > To: sip:peter@bar.com > Event: watcherinfo > Cseq: 34 ... "Event: watcherinfo" will **NEVER** be a valid thing to say. We are proposing this to be a *subpackage*, which means it must be contained in another package. For the purposes of the discussions we've been having here, my guess is that you mean to say "Event: presence.watcherinfo" One of the consequences of this fact is that, for example, including "event" as part of the XML document makes no sense. > > > > > Since this document will be carried in a NOTIFY which has an "Event:" header of "presence.watcherinfo," the event which is referenced *must* be "presence." Including it in the document is redundant if it matches, and invalid if it does not. /a From adam.roach@ericsson.com Tue Jun 12 12:44:26 2001 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 MAA02536 for ; Tue, 12 Jun 2001 12:44:26 -0400 (EDT) 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 f5CGiN808915; Tue, 12 Jun 2001 11:44:23 -0500 (CDT) 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 f5CGiLG29317; Tue, 12 Jun 2001 11:44:21 -0500 (CDT) Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA21741; Tue, 12 Jun 2001 11:44:21 -0500 (CDT) Reply-To: To: "'Robert Brown'" , "Jonathan Rosenberg" , Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Tue, 12 Jun 2001 11:44:20 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251833@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: <8DC4B82A94A29D4AB708F05E0EB557AB0320CB93@red-msg-05.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Length: 764 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > > I imagine valid AUTH requests like the following... > may cause some discomfort... > > AUTH sip:roberbr@microsoft.com SIP/2.0 > Content-Type: text/xml+soapenvelope > ... > xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/' > > > > foo > 1234 > > > If people were stupid enough to do this sort of thing with methods obviously designed for different purposes, we'd already see this sort of abuse with, say, REGISTER, INFO, MESSAGE, and NOTIFY. Oh, wait. Darn it, Pandora -- where did you put that lid? /a From adam.roach@ericsson.com Tue Jun 12 12:54:51 2001 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 MAA02606 for ; Tue, 12 Jun 2001 12:54:50 -0400 (EDT) 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 f5CGsja06436; Tue, 12 Jun 2001 11:54:46 -0500 (CDT) 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 f5CGsjV27797; Tue, 12 Jun 2001 11:54:45 -0500 (CDT) Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA22332; Tue, 12 Jun 2001 11:54:44 -0500 (CDT) Reply-To: To: "'Oded'" , "'Jonathan Rosenberg'" , "'SIMPLE Mail List (E-mail)'" Cc: "'Avner Ronen (E-mail)'" , "'Gabriel Matsliach (E-mail)'" Subject: RE: [SIMPLE] Presence Authorization Date: Tue, 12 Jun 2001 11:54:43 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251834@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 V4.72.3612.1700 Content-Length: 1283 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: > -----Original Message----- > From: Oded [mailto:odedcn@netvision.net.il] > > To conclude, SIMPLE should define how to upload/retrieve watcherinfo > documents, but this command should be performed against the > service and not > the presence server. I agree that presence servers may be > allowed to manage > these lists but the protocol should encourage doing it on the > service level, > as a main stream approach. I think you're presuming a particular architecture for your network. And that's great, but doesn't really have a bearing on the work we're doing here. On the protocol level, we don't really distinguish between a presence server and whatever it is you think of as your nodes on the "service level." I can't make myself see this as a problem, though. In general, you can trivially solve the problem by using any arbitrary protocol (Corba, SIP, RPC, something proprietary -- it doesn't matter) between your PS and your nodes on the service layer. This has an elegance to it inasmuch as it does not require the clients to have knowledge about the way you have chosen to design your network. Or it could be that I'm missing something. Perhaps a clearer illustration of what you mean by "service level" as well as a definition of some terms (UM?) would help. /a From theodore.havinis@openwave.com Tue Jun 12 13:54:13 2001 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 NAA02886 for ; Tue, 12 Jun 2001 13:54:08 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010612175339.TBET20804.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Tue, 12 Jun 2001 12:53:39 -0500 Received: from harviniT ([206.35.147.89]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with SMTP id <20010612175357.BVDN10672.oe-ismta2.bizmailsrvcs.net@harviniT>; Tue, 12 Jun 2001 12:53:57 -0500 From: "Theodore Havinis" To: "Jonathan Rosenberg" , Subject: RE: [Simple] authorization for presence Date: Tue, 12 Jun 2001 10:55:24 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Content-Length: 3096 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: AS>-----Original Message----- AS>From: simple-admin@mailman.dynamicsoft.com AS>[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan AS>Rosenberg AS>Sent: Wednesday, June 06, 2001 10:37 PM AS>To: 'Theodore Havinis'; simple@mailman.dynamicsoft.com AS>Subject: RE: [Simple] authorization for presence AS> AS> AS> AS> AS> AS> AS>> -----Original Message----- AS>> From: Theodore Havinis [mailto:theodore.havinis@openwave.com] AS>> Sent: Wednesday, June 06, 2001 12:02 AM AS>> To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com AS>> Subject: RE: [Simple] authorization for presence AS>> AS>> AS>> AS>> As I am trying to understand better the proposed solution I AS>> am confused as AS>> to whether AS>> the automatic notification to all watchers as soon as a new AS>> watcher tries to AS>> subscribe to the event is just *how a buddy list would work* AS>> or whether its AS>> a *a generic requirement* when dealing with subscriptions to events. AS> AS>The set of folks that get notified (because they are allowed to AS>subscribe) AS>when my watcherinfo changes (because someone subscribed to my AS>presence), is AS>a matter of local policy. Typically, I expect that local policy AS>would allow AS>only one entity to subscribe to changes in my watcherinfo, and AS>that would be AS>me. Understood. Thanks AS>> AS>> I assume, for protecting the presentity's privacy, it would AS>> be enough only for the presentity to be notified everytime a AS>> new watcher AS>> requests subscription to the presentity, unless the AS>> presentity explicitly AS>> allows the presence server to notify every (or some of them) AS>> watcher about AS>> which other watcher is in the list. AS> AS>Right; as I said, its a matter of policy. Remember, there are watchers at AS>two levels here. There are the set of folks who subscribed to my AS>presence. AS>Then, there are the set of folks who subscribed to changes in my AS>watcherinfo. That is, the set of folks that want to get notified when AS>someone tries to subscribe to my presence. These two sets of watchers are AS>not the same. AS> I guess what confuses me is why do we mix together under the mechanism of active/pending subscriptions (which is nice approach) with the 'set of folks to get notified when someone tries to subscribe to my presence'. The later is a separate application as far as I am concerned. ie I subscribe to an application (presentity) that monitors Bob's watchers. If I am correct in my thinking, could we separate those two issues ? Kind Rgds Theo AS>-Jonathan R. AS> AS>--- AS>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. AS>Chief Scientist First Floor AS>dynamicsoft East Hanover, NJ 07936 AS>jdrosen@dynamicsoft.com FAX: (973) 952-5050 AS>http://www.jdrosen.net PHONE: (973) 952-5000 AS>http://www.dynamicsoft.com AS>_______________________________________________ AS>simple mailing list AS>simple@mailman.dynamicsoft.com AS>http://mailman.dynamicsoft.com/mailman/listinfo/simple AS> From dsimons@windows.microsoft.com Tue Jun 12 17:14:30 2001 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA03533 for ; Tue, 12 Jun 2001 17:14:29 -0400 (EDT) Received: from 157.54.7.67 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 12 Jun 2001 12:00:32 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 12 Jun 2001 12:02:50 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 12 Jun 2001 11:46:37 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 12 Jun 2001 11:45:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Tue, 12 Jun 2001 11:45:20 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC146368C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Thoughts on uploading authorization documents Thread-Index: AcDyxXHkI04r6FSJQuq/PKeE1xQQtAAp7/Hw From: "David Simons" To: "Jonathan Rosenberg" , "Robert Brown" , X-OriginalArrivalTime: 12 Jun 2001 18:45:20.0858 (UTC) FILETIME=[D51A8BA0:01C0F36F] Content-Length: 2681 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA03533 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: It is obvious to me that SIP was written to be a protocol between two entities that have direct access to the end user. Without the real concept that agents may be used on servers that users must accessed form a remote clients. The control of these agents will require a significant number of requests form the user's client. Authentication upload is just one of several interactions that will be needed for real world deployments. So instead of polluting SIP with a lot of different methods I think we should give serious consideration to endorsing a single method to be used by clients to communicate with remote agents. I think that SERVICE is the solution. We on SIMPLE can define several standard SOAP methods that can be used to request services of a general nature from agents. Individual implementers can add additional requests as a value add for their services. Regards, David J. Simons Development Lead Microsoft Windows RTC -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, June 11, 2001 3:23 PM To: Robert Brown; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Monday, June 11, 2001 11:46 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > Sorry, but I fail to see the technical distinction between AUTH and > SERVICE. There has to be more than just the name of the method. Of course. The distinction is in what it does. AUTH uploads a policy document that is enabled to define who is able to access the resources at the URI specified in the method of the AUTH request. There can be separate types of policy docs, but you can't just put any old thing in there. This method would preclude someone from, say, setting the value of a variable, or invoking a media resource. People could abuse it to do other things, but it won't be interoperable across products, since correct implementations would only accept policy documents, not arbitrary RPC requests. -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 jdrosen@dynamicsoft.com Wed Jun 13 01:18:17 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04784 for ; Wed, 13 Jun 2001 01:18:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14172; Wed, 13 Jun 2001 01:22:10 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 01:18:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Oded'" , Jonathan Rosenberg , "'SIMPLE Mail List (E-mail)'" Cc: "'Avner Ronen (E-mail)'" , "'Gabriel Matsliach (E-mail)'" Subject: RE: [SIMPLE] Presence Authorization Date: Wed, 13 Jun 2001 01:18:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5104 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: > -----Original Message----- > From: Oded [mailto:odedcn@netvision.net.il] > Sent: Tuesday, June 12, 2001 10:39 AM > To: 'Jonathan Rosenberg'; 'SIMPLE Mail List (E-mail)' > Cc: 'Avner Ronen (E-mail)'; 'Gabriel Matsliach (E-mail)' > Subject: RE: [SIMPLE] Presence Authorization > > > The debate over how to upload and retrieve watcherinfo > documents assumes > that these lists should be stored on the presence server > while it seems much > more logical to store these lists on the services (IM/ UM etc.). No, it doesn't make that assumption. We are just talking about protocols. We are not specifying whether the notifications for watcherinfo come from a presence server, or a decoupled application server. Thats an implementation choice. > The presence server (PS) should be defined as an application > that supplies > presence services to real applications (presence > providers/consumers). The > logic of how to handle these lists is usually different among > services and > thus cannot reside on the PS itself. And its perfectly acceptable to build a system that way. > > The presence server need not know anything about the subscription > authorization process (that can be different from one service > to another). > When user A approves to reveal his presence to user B, the > service(!) adds B > to A's permit list and notifies the PS. My point was that there is still authorization happening here at the PS, even in this case. The PS needs to know that the subscription request is coming from an application that is trusted to do its own authorization. Without that, some random user can just bypass the application server that provides this service, and send a SUBSCRIBE directly to the presence server. > > Note also, that some services may not implement a deny list, > and some even > not require subscription authorization. In other words, since > the PS cannot > know in advance which applications will be using it and their internal > logic, it should leave the logic to the services. Its a reasonable way to build a system, yes, but not the only way. > > Jonathan, in your comments you imply that in a certain > implementation, the > service can manage authorization and the PS may use an > 'accept all' policy. > The problem is that this implementation will not be > compatible with other > implementations that implement authorization on the PS and not in the > service. Why? Consider two cases. Case one, is where the application is within the same administrative domain as the PS. In this case, the administrator of the domain sets the policy of the PS to "accept SUBSCRIBEs only over the TLS connection from the application server". Since no one but the AS from that domain talks to the presence server, it works just fine. Perhaps you are concerned that one cannot buy a presence server that works this way, because everyone has assumed that the PS manages authorization. Well, as I have argued, there are a ton of different authorization mechanisms. WHich ones are included in which presence servers is an issue for RFPs, not RFCs. Sounds like a reasonable RFP line item is "the PS should be able to authorize requests based on the DN provided in TLS credentials". Case two, is where the application is in one domain, and the PS is in another domain. This is a tricky case. The PS in the other domain has a right to challenge the application, and it has a right to authorize based on the actual user of the application, or on the domain of the application itself. I don't think you can dictate what the policy of such a PS has to be. > > It's important that SIMPLE defines where these lists are > managed and who to > contact to manage them. I don't think this needs to be specified, at least not in an RFC. > > To conclude, SIMPLE should define how to upload/retrieve watcherinfo > documents, but this command should be performed against the > service and not > the presence server. I agree that presence servers may be > allowed to manage > these lists but the protocol should encourage doing it on the > service level, > as a main stream approach. It is a general design goal of SIP that the less thats specified, the better. This is particularly the case for how networks are architected. I believe the success of SIP stems, in part, to its flexibility to solve a lot of different problems because it doesn't say too much about how to build networks. Invariably, every single provider I've talked to has their own ideas about how to build a network, and about what boxes perform which functions. I believe we should contineu with that direction in SIMPLE, and keep things like this at the discretion of the implementors and network designers, not in the protocol. -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 From jdrosen@dynamicsoft.com Wed Jun 13 01:30:51 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04851 for ; Wed, 13 Jun 2001 01:30:50 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14208; Wed, 13 Jun 2001 01:34:49 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 01:30:49 -0400 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , Jonathan Rosenberg , "'Robert Brown'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Wed, 13 Jun 2001 01:30:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 4786 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: > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Tuesday, June 12, 2001 5:35 AM > To: Jonathan Rosenberg; 'Robert Brown'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan > > Rosenberg > > Sent: 11 June 2001 23:23 > > To: 'Robert Brown'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > > -----Original Message----- > > > From: Robert Brown [mailto:roberbr@microsoft.com] > > > Sent: Monday, June 11, 2001 11:46 AM > > > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Thoughts on uploading authorization > documents > > > > > > > > > Sorry, but I fail to see the technical distinction > between AUTH and > > > SERVICE. There has to be more than just the name of the method. > > > > Of course. The distinction is in what it does. AUTH uploads a policy > > document that is enabled to define who is able to access the > > resources at > > the URI specified in the method of the AUTH request. There > > can be separate > > types of policy docs, but you can't just put any old thing in > > there. > > Well anything with a legal media-type is allowed in any SIP > request. Which includes, amongst many other, things SOAP > requests described as text/xml. Well, by this argument, I should simply dispose of all the SIP methods. Instead, we'll just have SERVICE. When SERVICE has application/sdp, thats setting up a session. When it has xml+soap, its invoking a service. In fact, we can do away with all the SIP headers too, since its the body which really tells you what to do with the request.... Just because any body type is syntactically allowed, does not mean that all body types can and should be understood in every request. > > > This > > method would preclude someone from, say, setting the value of > > a variable, or > > invoking a media resource. People could abuse it to do other > > things, but it > > won't be interoperable across products, since correct > > implementations would > > only accept policy documents, not arbitrary RPC requests. > > As I said on my previous post on this thread it is the > content type that is really important not the method name. I'm sorry, but that is just false. The method name describes what function is being invoked on the server. Period. Are you telling me that INVITE is meaningless? > So putting to one side the issue of the many different allowed > content types there is a nastier problem lurking if you hope > to act as the thought police by defining some authdata XML > schema to limit usage. I don't know how you come to the ridiculous conclusion that I, or anyone else, is trying to act as thought police. We have a problem - how to allow clients to explicitly allow or disallow subscriptions. The approach is just one way to provide authorization policy, and not the only way. I expect people to run CPL scripts, java servlets, use web interfaces, and so on, to determine authorization as well. > I would prefer to provide a more appropriate mechanism as a > starting point for inventiveness through something like SOAP. Why don't you just come the whole 9 yards, and specify that CORBA should be used, and rather than defining any standardized IDLs, we should allow anyone to use any IDL they like! Wow! Unlimited flexibility. Zero interoperability. > Within this generic mechanism things that need to be defined > as interoperable can be still be specified. In my other > posting on this thread I gave an example of one way this could > be done using WSDL for presence authorization. Other things may > not even be specified but at least they can be implemented > in a more appropriate manner. Maybe some even prove to be good > ideas and get incorporated into standards later based on > sensible implementations. Rather than a good idea becoming > widespread based on popularisation of a misguided > implementation over-loading something like authdata. So, if I understand you correctly, you are arguing that because people will extend and break the protocol anyway, lets design a mechanism that has virtually limitless extensibility because it actually defines nothing? -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 From jdrosen@dynamicsoft.com Wed Jun 13 01:40:05 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04921 for ; Wed, 13 Jun 2001 01:40:05 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14277; Wed, 13 Jun 2001 01:44:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 01:40:00 -0400 Message-ID: From: Jonathan Rosenberg To: "'David Simons'" , Jonathan Rosenberg , Robert Brown , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Wed, 13 Jun 2001 01:39:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Content-Length: 2685 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: > -----Original Message----- > From: David Simons [mailto:dsimons@windows.microsoft.com] > Sent: Tuesday, June 12, 2001 2:45 PM > To: Jonathan Rosenberg; Robert Brown; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > It is obvious to me that SIP was written to be a protocol between two > entities that have direct access to the end user. Without the real > concept that agents may be used on servers that users must > accessed form > a remote clients. Not really. The most common form of SIP UA is an agent thats quite remote from the client - a PSTN gateway. The interface between the user and its "agent" - the gateway - is via PSTN signaling protocols. Totally outside the scope of SIP. Indeed, a SIP client is a "user agent", so the notion of it being an agent on behalf of a user is core to the model. Others have written applications, like click-to-talk, where the user is on a web browser, and calls are initiated through web clicks to a remote server that acts as the user agent. Works just fine. Others have written apps where the interface between the user and the agent is voice. THings like personal attendants, where you call up and say "call bob", are examples of this. The agent speaks SIP to make the call, but the communication between the user and the agent is via speech recognition. > The control of these agents will require a > significant number of requests form the user's client. Sure. And in the current uses, its done via HTTP, ISUP, speech, etc. > Authentication > upload is just one of several interactions that will be > needed for real > world deployments. So instead of polluting SIP with a lot of > different > methods I think we should give serious consideration to endorsing a > single method to be used by clients to communicate with remote agents. A truly general mechanism for users to communicate with remote agents is far beyond the scope of SIP or SIMPLE. As I have pointed out above, things like HTTP (and the HTML forms that are used to driver user input) and ISUP are protocols used for this purpose. Regular, HTTP based SOAP might be another example of such a thing. I think we have a fairly concrete problem here, and I'd prefer to solve it in as simple and well defined manner as possible. -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 From jdrosen@dynamicsoft.com Wed Jun 13 01:44:56 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04980 for ; Wed, 13 Jun 2001 01:44:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14305; Wed, 13 Jun 2001 01:48:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 01:44:52 -0400 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , "'Robert Brown'" , Theodore Havinis , Jonathan Rosenberg , simple@mailman.dynamicsoft.com, "'Francois-Frederic Ozog'" Subject: RE: [Simple] authorization for presence Date: Wed, 13 Jun 2001 01:44:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2317 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: > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Tuesday, June 12, 2001 12:11 PM > To: 'Robert Brown'; Theodore Havinis; Jonathan Rosenberg; > simple@mailman.dynamicsoft.com; 'Francois-Frederic Ozog' > Subject: RE: [Simple] authorization for presence > > > Some recent posts have made it clear that the subpackage proposal > may be widely misunderstood. I'll attempt to clarify a couple > of points. > > > NOTIFY sip:peter@bar.com SIP/2.0 > > From: sip:bar.com > > To: sip:peter@bar.com > > Event: watcherinfo > > Cseq: 34 > > ... > > "Event: watcherinfo" will **NEVER** be a valid thing to say. We are > proposing this to be a *subpackage*, which means it must be contained > in another package. For the purposes of the discussions we've been > having here, my guess is that you mean to say "Event: > presence.watcherinfo" Right. A notification for a watcherinfo event to my presence would have the Event name of presence.watcherinfo. Such a notification would occur when someone asked to subscribe to my presence. > > One of the consequences of this fact is that, for example, including > "event" as part of the XML document makes no sense. > > > > > auth="allow" /> > > attribute="geolocation" auth="allow" > /> > > auth="block" /> > > > > Since this document will be carried in a NOTIFY which has an > "Event:" header of "presence.watcherinfo," Well, thats the question. My interpretation of this document above is that its the thing thats carried in the AUTH (or whatever we defined) method that sets authorization policy. You are correct that the document carried in a NOTIFY of presence.watcherinfo has no need to define the event. But, the document carried in the AUTH does need to define 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 From jdrosen@dynamicsoft.com Wed Jun 13 01:51:30 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05053 for ; Wed, 13 Jun 2001 01:51:30 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14318; Wed, 13 Jun 2001 01:55:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Jun 2001 01:51:30 -0400 Message-ID: From: Jonathan Rosenberg To: "'Theodore Havinis'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Wed, 13 Jun 2001 01:51:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2379 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: > -----Original Message----- > From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > Sent: Tuesday, June 12, 2001 1:55 PM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] authorization for presence > > AS>Right; as I said, its a matter of policy. Remember, there > are watchers at > AS>two levels here. There are the set of folks who subscribed to my > AS>presence. > AS>Then, there are the set of folks who subscribed to changes in my > AS>watcherinfo. That is, the set of folks that want to get > notified when > AS>someone tries to subscribe to my presence. These two sets > of watchers are > AS>not the same. > AS> > > I guess what confuses me is why do we mix together under the > mechanism of > active/pending subscriptions (which is nice approach) with > the 'set of folks > to get > notified when someone tries to subscribe to my presence'. The > later is a > separate application as far as I am concerned. > ie I subscribe to an application (presentity) that monitors > Bob's watchers. I am not understanding what you're saying here. There is a server, and it knows about my presence. My presence is effectively state that changes dynamically. When it changes, the subscribers to that state get notified. That server has another piece of state, which is the set of subscribers to my presence. Thats state changes dynamically too, for example, when someone subscribes to my presence. Users can subscribe to this other piece of state, "presence.watcherinfo", and they get notified when it changes. The set of people subscribed to my presence is unrelated to the set of people who are subscribed to presence.watcherinfo. Thus, the set of people subscribed to my presence (the subscribers of the event "presence"), is not the same as the set of people subscribed to my "presence.watcherinfo". The set of people who subscribe to my presence affects the state of presence.watcherinfo, by definition, but thats the only coupling. Does that clarify 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 From ndeason@ubiquity.net Wed Jun 13 05:02:08 2001 Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA05605 for ; Wed, 13 Jun 2001 05:02:08 -0400 (EDT) Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca via smtpd (for [216.173.40.35]) with SMTP; 13 Jun 2001 10:01:58 UT Received: (private information removed) Message-ID: From: Neil Deason To: Jonathan Rosenberg , "'Robert Brown'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Wed, 13 Jun 2001 04:55:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5988 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: comments inline... > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 13 June 2001 06:31 > To: 'Neil Deason'; Jonathan Rosenberg; 'Robert Brown'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > -----Original Message----- > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > Sent: Tuesday, June 12, 2001 5:35 AM > > To: Jonathan Rosenberg; 'Robert Brown'; > simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > > -----Original Message----- > > > From: simple-admin@mailman.dynamicsoft.com > > > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan > > > Rosenberg > > > Sent: 11 June 2001 23:23 > > > To: 'Robert Brown'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Thoughts on uploading authorization > documents > > > > > > > -----Original Message----- > > > > From: Robert Brown [mailto:roberbr@microsoft.com] > > > > Sent: Monday, June 11, 2001 11:46 AM > > > > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Thoughts on uploading authorization > > documents > > > > > > > > > > > > Sorry, but I fail to see the technical distinction > > between AUTH and > > > > SERVICE. There has to be more than just the name of the method. > > > > > > Of course. The distinction is in what it does. AUTH > uploads a policy > > > document that is enabled to define who is able to access the > > > resources at > > > the URI specified in the method of the AUTH request. There > > > can be separate > > > types of policy docs, but you can't just put any old thing in > > > there. > > > > Well anything with a legal media-type is allowed in any SIP > > request. Which includes, amongst many other, things SOAP > > requests described as text/xml. > > Well, by this argument, I should simply dispose of all the > SIP methods. > Instead, we'll just have SERVICE. When SERVICE has > application/sdp, thats > setting up a session. When it has xml+soap, its invoking a > service. In fact, > we can do away with all the SIP headers too, since its the > body which really > tells you what to do with the request.... > > Just because any body type is syntactically allowed, does not > mean that all > body types can and should be understood in every request. Agreed. I just wanted to highlight the possibilities, not advocate their use. > > > This > > > method would preclude someone from, say, setting the value of > > > a variable, or > > > invoking a media resource. People could abuse it to do other > > > things, but it > > > won't be interoperable across products, since correct > > > implementations would > > > only accept policy documents, not arbitrary RPC requests. > > > > As I said on my previous post on this thread it is the > > content type that is really important not the method name. > > I'm sorry, but that is just false. The method name describes > what function > is being invoked on the server. Period. Are you telling me > that INVITE is > meaningless? No. I am saying the proposal for AUTH as a solution is incomplete without the definition of authdata to go with it. This needs to include how authdata can be extended. > > So putting to one side the issue of the many different allowed > > content types there is a nastier problem lurking if you hope > > to act as the thought police by defining some authdata XML > > schema to limit usage. > > I don't know how you come to the ridiculous conclusion that > I, or anyone > else, is trying to act as thought police. We have a problem - > how to allow > clients to explicitly allow or disallow subscriptions. The > approach is just > one way to provide authorization policy, and not the only > way. I expect > people to run CPL scripts, java servlets, use web interfaces, > and so on, to > determine authorization as well. > > > I would prefer to provide a more appropriate mechanism as a > > starting point for inventiveness through something like SOAP. > > Why don't you just come the whole 9 yards, and specify that > CORBA should be > used, and rather than defining any standardized IDLs, we > should allow anyone > to use any IDL they like! Wow! Unlimited flexibility. Zero > interoperability. Not true, interoperability could be defined through WSDL. I contributed quite a detailed example of how this might work for presence authorization. I would really appreciate hearing what you think about it. > > Within this generic mechanism things that need to be defined > > as interoperable can be still be specified. In my other > > posting on this thread I gave an example of one way this could > > be done using WSDL for presence authorization. Other things may > > not even be specified but at least they can be implemented > > in a more appropriate manner. Maybe some even prove to be good > > ideas and get incorporated into standards later based on > > sensible implementations. Rather than a good idea becoming > > widespread based on popularisation of a misguided > > implementation over-loading something like authdata. > > So, if I understand you correctly, you are arguing that > because people will > extend and break the protocol anyway, lets design a mechanism that has > virtually limitless extensibility because it actually defines > nothing? I don't think you do understand me correctly. What I am saying is that any successful protocol will be extended. Why not provision a sensible starting point for extensions rather than just letting people find starting points such as inappropriately adding to CPL or authdata. SOAP could provide this mechanism and WSDL could define interoperable usage. As this a wider point than presence authorization it probably belongs on SIPPING. However, I would still like to hear your thoughts on the specific usage suggested here for presence authorization. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net From ndeason@ubiquity.net Wed Jun 13 05:36:36 2001 Received: from firewall.ubiquity.ca ([209.167.187.162]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA05725 for ; Wed, 13 Jun 2001 05:36:31 -0400 (EDT) Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca via smtpd (for [216.173.40.35]) with SMTP; 13 Jun 2001 10:36:21 UT Received: (private information removed) Message-ID: From: Neil Deason To: adam.roach@ericsson.com, "'Robert Brown'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Wed, 13 Jun 2001 05:19:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3397 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: > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of > adam.roach@ericsson.com > Sent: 12 June 2001 17:44 > To: 'Robert Brown'; Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > -----Original Message----- > > From: Robert Brown [mailto:roberbr@microsoft.com] > > > > I imagine valid AUTH requests like the following... > > may cause some discomfort... > > > > AUTH sip:roberbr@microsoft.com SIP/2.0 > > Content-Type: text/xml+soapenvelope > > ... > > > xmlns:SOAP-ENV='http://schemas.xmlsoap.org/soap/envelope/' > > > > > > > foo > > 1234 > > > > > > > > If people were stupid enough to do this sort of thing with methods > obviously designed for different purposes, we'd already see this > sort of abuse with, say, REGISTER, INFO, MESSAGE, and NOTIFY. > > Oh, wait. > > Darn it, Pandora -- where did you put that lid? If only we had ASN.1 encoded everything that would have kept a lid on things ;) I thought flexibility and extensibility were good. That's why we're not using H.323 right? The flexibility and extensibility of SIP allow us to build new services which consequently allows service providers to develop new revenue streams (oh yeah and SIP implementors like us to sell kit ;). So how about this for a converged application providing a new service. Say I am finishing work in the UK but want to know the value of my shares portfolio when the US markets close. However, I am going to the pub after work and due to fear of immediate notification of my losses sending me on a major drinking binge I prefer the results to be emailed to my work account. Besides, then I can work out what impact it has on my planned retirement date on the companies time in the morning which seems only fair. I can have this service today through an application that has wisely decided to support SIP for its flexibility and extensibility. As I leave I send a MESSAGE to my broker's stock watcher service carrying a SOAP payload. SOAP is _not_ just an RPC mechanism it is actually an XML messaging protocol. RPC is but one application that can be built over SOAP messaging. This example is of a one way messaging operation using SOAP. The SOAP message carries all necessary info about me, my portfolio, where I want the response emailed to etc. Using SOAP for encoding this message in XML works _today_. Using MESSAGE for transporting a XML message doesn't seem that unreasonable to me. After all if MESSAGE should only be used as seen to date, to carry plain/text for simple IM clients, we should redefine the semantics of INVITE to be a method for only setting up telephony calls. Finally using SIP in general means I can use the end to end authentication and encryption (well one day) mechanisms for security. It means that providers can offer the service reusing their SIP infrastructure so making a cost saving. It means that hand held devices can use the same protocol from IM + Presence as well as this additional type of service. So is the consensus that this is reasonable use or abuse? Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net From dsimons@windows.microsoft.com Wed Jun 13 22:08:01 2001 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id WAA08330 for ; Wed, 13 Jun 2001 22:08:00 -0400 (EDT) Received: from 157.54.9.108 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 13 Jun 2001 17:57:19 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 13 Jun 2001 17:57:47 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 13 Jun 2001 17:57:44 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 13 Jun 2001 17:56:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F46C.D3D7DC0D" Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Wed, 13 Jun 2001 17:56:21 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1463691@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Thoughts on uploading authorization documents Thread-Index: AcDzyy0UhULUl7EATJS3DbDIYu1DAwAhhmUA From: "David Simons" To: "Jonathan Rosenberg" , "Robert Brown" , X-OriginalArrivalTime: 14 Jun 2001 00:56:22.0018 (UTC) FILETIME=[D433BE20:01C0F46C] Content-Length: 32317 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0F46C.D3D7DC0D Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIHRoZXJlIGFyZSBzb2x1dGlvbnMgb3V0IHRoZXJlIHRoYXQgdXNlIG90aGVyIHByb3RvY29s cyB0bw0KY29tbXVuaWNhdGUgYmV0d2VlbiBjbGllbnRzIGFuZCBhZ2VudHMgYnV0IHRoaXMgZG9l c24ndCBtZWFuIHRoYXQgU0lNUExFDQpzaG91bGQgdXNlIHRoYXQgYXMgYSBjcnV0Y2guICBXZSBh cmUgdHJ5aW5nIHRvIGZpbmQgZW5hYmxpbmcgc29sdXRpb25zDQp0byByZWFsIHdvcmxkIHByb2Js ZW1zLg0KDQpJbiBwYXJ0aWN1bGFyIEknbSBjb25jZXJuZWQgYWJvdXQgSFRUUDsgc29tZSBpbiB0 aGUgU0lQIGNvbW11bml0eSBzZWVtDQp0byBzZWUgaXQgYXMgYSBwYW5hY2VhLiAgSXQgaXMgdHJ1 ZSB0aGF0IFNJUCBhbmQgSFRUUCBzaGFyZSBjb21tb24NCmVsZW1lbnRzIGJ1dCB0aGVpciBuYXRp dmUgdG9wb2xvZ3kgYW5kIG5hbWVzcGFjZXMgYXJlIGRpZmZlcmVudC4gIEFzDQpKb25hdGhhbiBw b2ludGVkIG91dCBpbiBhIHByZXZpb3VzIHBvc3RpbmcgdG8gdGhpcyBncm91cCB0aGVyZSBhcmUN Cmlzc3VlcyB3aXRoIGlkZW50aWZ5aW5nIFNJUCBpZGVudGl0aWVzIGluIEhUVFAgUG9zdC4gIEFu ZCB0aGVuIHRoZXJlIGlzDQp0aGUgaXNzdWUgb2YgZmluZGluZyB0aGUgYXBwcm9wcmlhdGUgSFRU UCBzZXJ2ZXIgdG8gc2VuZCBQT1NULiAgQQ0Kc3RhbmRhcmRpemVkIG1hcHBpbmcgZnJvbSBTSVAg VVJJIHRvIGFuIEhUVFAgVVJMIHdpbGwgYWx3YXlzIGNhdXNlIHNvbWUNCmRlcGxveW1lbnQgcHJv YmxlbXMsIHRoZSBTSVAgRE5TIFNSViByZWNvcmQgbWF5IHBvaW50IHRvIGEgZGlmZmVyZW50DQpz ZXJ2ZXIgdGhhbiB0aGUgSFRUUCBETlMgU1JWIHJlY29yZC4gIFB1cml0eSBvZiBwcm90b2NvbCBv bmx5IGV2ZXIgd29ya3MNCnVudGlsIHJlYWwtd29ybGQgcHJvYmxlbXMgbXVzdCBiZSBzb2x2ZWQg YnkgaXQuICAgIA0KDQpFbmFibGluZyBTSVAgdG8gcHJvdmlkZSByZWFsLXdvcmxkIHNvbHV0aW9u cyBpbiBpdHMgcHJvYmxlbSBzcGFjZSBpc24ndA0KYW4gYWJ1c2Ugb2YgdGhlIHByb3RvY29sLiAg U0lQIGJhc2VkIGNsaWVudHMsIGFnZW50cywgYW5kIHNlcnZpY2VzIGFyZQ0KZ29pbmcgdG8gbmVl ZCB0byBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIgdG8gY29vcmRpbmF0ZSB0aGF0IGhhbmRs aW5nDQpvZiBzZXNzaW9ucy4gIFlvdSBjYW4gYXJndWUgdGhhdCB0aGVyZSBpc24ndCBhIHNlc3Np b24gdG8gYmUgZm91bmQgYnV0DQp0aGlzIGNvb3JkaW5hdGlvbiBpcyByZXF1aXJlZCB0byBwcm9w ZXJseSBoYW5kbGUgc2Vzc2lvbnMgYW5kIGlzDQp0aGVyZWZvcmUgc3Ryb25nbHkgcmVsYXRlZCB0 byBzZXNzaW9ucy4NCg0KSSBkb24ndCBiZWxpZXZlIHRoYXQgd2UgYXJlIGRvaW5nIFNJUCBvciBT SU1QTEUgYSBzZXJ2aWNlIGJ5IGxpbWl0aW5nDQp0aGUgcHJvdG9jb2wgc3VjaCB0aGF0IGl0IGNh bid0IHByb3ZpZGUgZGVwbG95YWJsZSBzb2x1dGlvbnMgd2l0aG91dCB0aGUNCmFzc2lzdGFuY2Ug b2Ygb3RoZXIgaGlnaCBsZXZlbCBwcm90b2NvbHMgKHBsZWFzZSwgbm8gb25lIG5lZWQgdG8gcG9p bnQNCnRvIEROUyBhbmQgREhDUCBhcyBjb3VudGVyIGV4YW1wbGVzKSBIVFRQIGRvZXNuJ3QgcmVx dWlyZSBTTVRQIG9yIEZUUC4NClNvIHdoeSBzaG91bGQgU0lQL1NJTVBMRSByZXF1aXJlIEhUVFA/ DQoNCldlIHNob3VsZCByZWNvZ25pemUgdGhhdCBpbXBsZW1lbnRlcnMgYXJlIGdvaW5nIHRvIHdy aXRlIGFwcGxpY2F0aW9uDQpzcGVjaWZpYyBleHRlbnNpb25zIGFuZCB0cnkgdG8gbWluaW1pemUg dGhlIGltcGFjdCBvZiB0aGVzZSBleHRlbnNpb24gb24NClNJUCBieSBzYXlpbmcsICJQdXQgeW91 IGFwcGxpY2F0aW9uIHNwZWNpZmljIGV4dGVuc2lvbnMgaGVyZS4iICBUaGVuIFNJUA0Kd2lsbCBo YXZlIHRoZSBmb2xsb3dpbmcgbWFqb3IgcGllY2VzOiBTZXNzaW9uIE1hbmFnZW1lbnQsIE5vdGlm aWNhdGlvbiwNCk1lc3NhZ2luZywgQXBwbGljYXRpb24gRGF0YSBhbmQgb3RoZXIgYnJvYWRseSBl eHBlY3RlZCBleHRlbnNpb25zLiANCg0KQ1BMIGFuZCBwcmVzZW5jZSBhdXRob3JpemF0aW9uIGFy ZSB0d28gc3BlY2lmaWMgZXhhbXBsZXMgb2YgdGhlIG5lZWQgZm9yDQpjbGllbnRzIHRvIHNlbmQg ZGF0YSB0byBhZ2VudHMgYW5kL29yIHNlcnZlci4gIFNvIGl0IGlzIG9idmlvdXMgdG8gbWUNCnRo YXQgU0lQIG5lZWRzIGEgbWVjaGFuaXNtIGZvciBzb21lIGZvcm0gYSBzZXNzaW9uIGhhbmRsaW5n IGRhdGENCmV4Y2hhbmdlLiAgDQoNClNvIGlmIHdlIGNhbiBhZ3JlZSB0aGF0IGFwcGxpY2F0aW9u IHNwZWNpZmljIGV4dGVuc2lvbnMgYW5kIGRhdGENCmV4Y2hhbmdlIGFyZSBhIHJlYWxpdHkgb2Yg dGhlIFNJUC9TSU1QTEUgdGhlbiB3aHkgZG9uJ3Qgd2UganVzdCBjb21iaW5lDQp0aGVtPyAgQm90 aCBTRVJWSUNFIGFuZCBTRVREQVRBIGhhdmUgYmVlbiBwcm9wb3NlZC4gIEl0IHNlZW1zIHRvIG1l IHRoYXQNCnRoZXkgYXJlIHJlYWxseSB0aGUgc2FtZSB0aGluZy4gIEVhY2ggaXMgc2VuZGluZyBj b250ZW50IGZyb20gb25lIFNJUA0KZW50aXR5IHRvIGFub3RoZXIgd2l0aCB0aGUgZXhwZWN0YXRp b24gdGhhdCB0aGF0IGNvbnRlbnQgd2lsbCBiZSB1c2VkIGluDQp0aGUgU0lQIHNvbHV0aW9uIHNw YWNlLiAgDQoNClRoZSBxdWVzdGlvbiB0aGVuIGlzIHdoYXQgZG8gd2UgY2FsbCB0aGlzIG5ldyBT SVAgbWV0aG9kPyAgTXkgcGVyc29uYWwNCnByZWZlcmVuY2Ugd291bGQgYmUgdG8gY2FsbCBpdCBT RVJWSUNFLiAgU0VUREFUQSBpbXBsaWVzIHN0b3JhZ2VzIGFuZA0KZXZlcnl0aGluZyBkaXNjdXNz ZWQgc28gZmFyIGhhcyBjZW50ZXJlZCBvbiBwcm92aWRpbmcgYSBzZXJ2ZXIgb3IgYWdlbnQNCndp dGggc29tZSBkYXRhIGl0IGNhbiB1c2UgdG8gcHJvdmlkZSBzZXNzaW9uIGhhbmRsaW5nLiAgVGhl cmVmb3JlLCB0aGUNCmNsaWVudCBpcyByZXF1ZXN0aW5nIGEgc2VydmljZSBmcm9tIHRoZSBzZXJ2 ZXIgYW5kL29yIGFnZW50LiAgIFdoYXQNCmNvbnRlbnQgaXMgY2FycmllZCBieSB0aGlzIG5ldyBt ZXRob2QgaXMgYXBwbGljYXRpb24gc3BlY2lmaWMuICBJbiB0aGUNCmNhc2Ugb2YgU0lNUExFIHdl IHNob3VsZCBzcGVjaWZ5IHRoaXMgY29udGVudC4gIE90aGVyIGV4dGVuc2lvbnMgYW5kDQphcHBs aWNhdGlvbiBtaWdodCBjaG9vc2UgU09BUC4gIEkgZm9yIG9uZSB3b3VsZCBsaWtlIHRvIHNlZSBT SU1QTEUgdXNlDQpTT0FQLCBvbmUgZW5jb2Rpbmcgc2NoZW1lIHRoYXQgaXMgZXh0ZW5zaWJsZSBh bmQgYWxyZWFkeSBkZWZpbmVkIHdpdGggYQ0KZ3Jvd2luZyBpbXBsZW1lbnRhdGlvbiBiYXNlLiAg IA0KDQpSZWdhcmRzLA0KDQpEYXZpZCBKLiBTaW1vbnMNClNERSBMZWFkDQpXaW5kb3cgUlRDDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb25hdGhhbiBSb3NlbmJlcmcgW21h aWx0bzpqZHJvc2VuQGR5bmFtaWNzb2Z0LmNvbV0gDQpTZW50OiBUdWVzZGF5LCBKdW5lIDEyLCAy MDAxIDEwOjQwIFBNDQpUbzogRGF2aWQgU2ltb25zOyBKb25hdGhhbiBSb3NlbmJlcmc7IFJvYmVy dCBCcm93bjsNCnNpbXBsZUBtYWlsbWFuLmR5bmFtaWNzb2Z0LmNvbQ0KU3ViamVjdDogUkU6IFtT aW1wbGVdIFRob3VnaHRzIG9uIHVwbG9hZGluZyBhdXRob3JpemF0aW9uIGRvY3VtZW50cw0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhdmlkIFNpbW9ucyBbbWFpbHRv OmRzaW1vbnNAd2luZG93cy5taWNyb3NvZnQuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBKdW5lIDEy LCAyMDAxIDI6NDUgUE0NCj4gVG86IEpvbmF0aGFuIFJvc2VuYmVyZzsgUm9iZXJ0IEJyb3duOyBz aW1wbGVAbWFpbG1hbi5keW5hbWljc29mdC5jb20NCj4gU3ViamVjdDogUkU6IFtTaW1wbGVdIFRo b3VnaHRzIG9uIHVwbG9hZGluZyBhdXRob3JpemF0aW9uIGRvY3VtZW50cw0KPiANCj4gDQo+IEl0 IGlzIG9idmlvdXMgdG8gbWUgdGhhdCBTSVAgd2FzIHdyaXR0ZW4gdG8gYmUgYSBwcm90b2NvbCBi ZXR3ZWVuIHR3bw0KPiBlbnRpdGllcyB0aGF0IGhhdmUgZGlyZWN0IGFjY2VzcyB0byB0aGUgZW5k IHVzZXIuICBXaXRob3V0IHRoZSByZWFsDQo+IGNvbmNlcHQgdGhhdCBhZ2VudHMgbWF5IGJlIHVz ZWQgb24gc2VydmVycyB0aGF0IHVzZXJzIG11c3QgDQo+IGFjY2Vzc2VkIGZvcm0NCj4gYSByZW1v dGUgY2xpZW50cy4gDQoNCk5vdCByZWFsbHkuIFRoZSBtb3N0IGNvbW1vbiBmb3JtIG9mIFNJUCBV QSBpcyBhbiBhZ2VudCB0aGF0cyBxdWl0ZQ0KcmVtb3RlDQpmcm9tIHRoZSBjbGllbnQgLSBhIFBT VE4gZ2F0ZXdheS4gVGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSB1c2VyIGFuZCBpdHMNCiJhZ2Vu dCIgLSB0aGUgZ2F0ZXdheSAtIGlzIHZpYSBQU1ROIHNpZ25hbGluZyBwcm90b2NvbHMuIFRvdGFs bHkgb3V0c2lkZQ0KdGhlDQpzY29wZSBvZiBTSVAuIEluZGVlZCwgYSBTSVAgY2xpZW50IGlzIGEg InVzZXIgYWdlbnQiLCBzbyB0aGUgbm90aW9uIG9mDQppdA0KYmVpbmcgYW4gYWdlbnQgb24gYmVo YWxmIG9mIGEgdXNlciBpcyBjb3JlIHRvIHRoZSBtb2RlbC4NCg0KT3RoZXJzIGhhdmUgd3JpdHRl biBhcHBsaWNhdGlvbnMsIGxpa2UgY2xpY2stdG8tdGFsaywgd2hlcmUgdGhlIHVzZXIgaXMNCm9u IGENCndlYiBicm93c2VyLCBhbmQgY2FsbHMgYXJlIGluaXRpYXRlZCB0aHJvdWdoIHdlYiBjbGlj a3MgdG8gYSByZW1vdGUNCnNlcnZlcg0KdGhhdCBhY3RzIGFzIHRoZSB1c2VyIGFnZW50LiBXb3Jr cyBqdXN0IGZpbmUuDQoNCk90aGVycyBoYXZlIHdyaXR0ZW4gYXBwcyB3aGVyZSB0aGUgaW50ZXJm YWNlIGJldHdlZW4gdGhlIHVzZXIgYW5kIHRoZQ0KYWdlbnQNCmlzIHZvaWNlLiBUSGluZ3MgbGlr ZSBwZXJzb25hbCBhdHRlbmRhbnRzLCB3aGVyZSB5b3UgY2FsbCB1cCBhbmQgc2F5DQoiY2FsbA0K Ym9iIiwgYXJlIGV4YW1wbGVzIG9mIHRoaXMuIFRoZSBhZ2VudCBzcGVha3MgU0lQIHRvIG1ha2Ug dGhlIGNhbGwsIGJ1dA0KdGhlDQpjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIHVzZXIgYW5kIHRo ZSBhZ2VudCBpcyB2aWEgc3BlZWNoIHJlY29nbml0aW9uLg0KDQo+IFRoZSBjb250cm9sIG9mIHRo ZXNlIGFnZW50cyB3aWxsIHJlcXVpcmUgYQ0KPiBzaWduaWZpY2FudCBudW1iZXIgb2YgcmVxdWVz dHMgZm9ybSB0aGUgdXNlcidzIGNsaWVudC4gDQoNClN1cmUuIEFuZCBpbiB0aGUgY3VycmVudCB1 c2VzLCBpdHMgZG9uZSB2aWEgSFRUUCwgSVNVUCwgc3BlZWNoLCBldGMuDQoNCg0KPiBBdXRoZW50 aWNhdGlvbg0KPiB1cGxvYWQgaXMganVzdCBvbmUgb2Ygc2V2ZXJhbCBpbnRlcmFjdGlvbnMgdGhh dCB3aWxsIGJlIA0KPiBuZWVkZWQgZm9yIHJlYWwNCj4gd29ybGQgZGVwbG95bWVudHMuICBTbyBp bnN0ZWFkIG9mIHBvbGx1dGluZyBTSVAgd2l0aCBhIGxvdCBvZiANCj4gZGlmZmVyZW50DQo+IG1l dGhvZHMgSSB0aGluayB3ZSBzaG91bGQgZ2l2ZSBzZXJpb3VzIGNvbnNpZGVyYXRpb24gdG8gZW5k b3JzaW5nIGENCj4gc2luZ2xlIG1ldGhvZCB0byBiZSB1c2VkIGJ5IGNsaWVudHMgdG8gY29tbXVu aWNhdGUgd2l0aCByZW1vdGUgYWdlbnRzLg0KDQpBIHRydWx5IGdlbmVyYWwgbWVjaGFuaXNtIGZv ciB1c2VycyB0byBjb21tdW5pY2F0ZSB3aXRoIHJlbW90ZSBhZ2VudHMgaXMNCmZhciBiZXlvbmQg dGhlIHNjb3BlIG9mIFNJUCBvciBTSU1QTEUuIEFzIEkgaGF2ZSBwb2ludGVkIG91dCBhYm92ZSwN CnRoaW5ncyBsaWtlDQpIVFRQIChhbmQgdGhlIEhUTUwgZm9ybXMgdGhhdCBhcmUgdXNlZCB0byBk cml2ZXIgdXNlciBpbnB1dCkgYW5kIElTVVANCmFyZSBwcm90b2NvbHMgdXNlZCBmb3IgdGhpcyBw dXJwb3NlLiBSZWd1bGFyLCBIVFRQIGJhc2VkIFNPQVAgbWlnaHQgYmUNCmFub3RoZXIgZXhhbXBs ZSBvZiBzdWNoIGEgdGhpbmcuIA0KDQpbRGF2aWQgU2ltb25zXUkgd291bGQgZGlzYWdyZWUgdGhh dCBwcm92aWRpbmcgcmljaCBzb2x1dGlvbnMgdG8gc2Vzc2lvbg0KbWFuYWdlbWVudCBpcyBiZXlv bmQgdGhlIHNjb3BlIG9mIFNJUC4gIFRoZSB1c2Ugb2Ygb3RoZXIgcHJvdG9jb2xzIHdpbGwNCmNh dXNlIGlzc3VlcyB0aGF0IHdlIHNvbHZlIGluIGFuIGV4cGVjdGFibGUgbWFub3IuIA0KDQpJIHRo aW5rIHdlIGhhdmUgYSBmYWlybHkgY29uY3JldGUgcHJvYmxlbSBoZXJlLCBhbmQgSSdkIHByZWZl ciB0byBzb2x2ZQ0KaXQNCmluIGFzIHNpbXBsZSBhbmQgd2VsbCBkZWZpbmVkIG1hbm5lciBhcyBw b3NzaWJsZS4gDQoNCltEYXZpZCBTaW1vbnNdQ29uY3JldGUgeWVzIGJ1dCBzaW1wbGUgaXMgZG9l c24ndCBzZWVtIHRvIGJlLiAgRWxzZSB3ZQ0Kd291bGQgaGF2ZSBoYWQgY29uc2Vuc3VzIG9uIGEg c29sdXRpb24gYnkgbm93LiAgQWNjZXNzIGNvbnRyb2wgaXMgYWx3YXlzDQptb3JlIGNvbXBsZXgg dGhlbiBpdCBzZWVtcy4gDQoNCg0KLUpvbmF0aGFuIFIuDQotLS0NCkpvbmF0aGFuIEQuIFJvc2Vu YmVyZywgUGguRC4gICAgICAgICAgICAgICAgNzIgRWFnbGUgUm9jayBBdmUuDQpDaGllZiBTY2ll bnRpc3QgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpcnN0IEZsb29yDQpkeW5hbWljc29m dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVhc3QgSGFub3ZlciwgTkogMDc5MzYN Cmpkcm9zZW5AZHluYW1pY3NvZnQuY29tICAgICAgICAgICAgICAgICAgICAgRkFYOiAgICg5NzMp IDk1Mi01MDUwDQpodHRwOi8vd3d3Lmpkcm9zZW4ubmV0ICAgICAgICAgICAgICAgICAgICAgIFBI T05FOiAoOTczKSA5NTItNTAwMA0KaHR0cDovL3d3dy5keW5hbWljc29mdC5jb20NCg0K ------_=_NextPart_001_01C0F46C.D3D7DC0D Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjQ3MTIuMCI+DQo8VElUTEU+UkU6IFtTaW1wbGVd IFRob3VnaHRzIG9uIHVwbG9hZGluZyBhdXRob3JpemF0aW9uIGRvY3VtZW50czwvVElUTEU+DQo8 L0hFQUQ+DQo8Qk9EWT4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9ydGYgZm9ybWF0IC0tPg0K DQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291 cmllciBOZXciPlllcyB0aGVyZSBhcmUgc29sdXRpb25zIG91dCB0aGVyZSB0aGF0IHVzZSBvdGhl ciBwcm90b2NvbHMgdG8gY29tbXVuaWNhdGUgYmV0d2VlbiBjbGllbnRzIGFuZCBhZ2VudHMgYnV0 IHRoaXMgZG9lc24ndCBtZWFuIHRoYXQgU0lNUExFIHNob3VsZCB1c2UgdGhhdCBhcyBhIGNydXRj aC4mbmJzcDsgV2UgYXJlIHRyeWluZyB0byBmaW5kIGVuYWJsaW5nIHNvbHV0aW9ucyB0byByZWFs IHdvcmxkIHByb2JsZW1zLjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPjwvU1BBTj48 L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNF PSJDb3VyaWVyIE5ldyI+SW4gcGFydGljdWxhciBJJ20gY29uY2VybmVkIGFib3V0PC9GT05UPjwv U1BBTj48U1BBTiBMQU5HPSJlbi11cyI+IDxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+ SFRUUDs8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0i Q291cmllciBOZXciPiBzb21lIGluIHRoZSBTSVAgY29tbXVuaXR5IHNlZW0gdG8gc2VlIGl0IGFz IGEgcGFuYWNlYS4mbmJzcDsgSXQgaXMgdHJ1ZSB0aGF0IFNJUCBhbmQgSFRUUCBzaGFyZSBjb21t b24gZWxlbWVudHMgYnV0IHRoZWlyIG5hdGl2ZSB0b3BvbG9neSBhbmQgbmFtZXNwYWNlcyBhcmUg ZGlmZmVyZW50LiZuYnNwOyBBcyBKb25hdGhhbiBwb2ludGVkIG91dCBpbiBhIHByZXZpb3VzIHBv c3RpbmcgdG8gdGhpcyBncm91cCB0aGVyZSBhcmUgaXNzdWVzIHdpdGggaWRlbnRpZnlpbmcgU0lQ IGlkZW50aXRpZXMgaW4gSFRUUCBQb3N0LiZuYnNwOyBBbmQgdGhlbiB0aGVyZSBpcyB0aGUgaXNz dWUgb2YgZmluZGluZyB0aGUgYXBwcm9wcmlhdGUgSFRUUCBzZXJ2ZXIgdG8gc2VuZCBQT1NULiZu YnNwOyBBIHN0YW5kYXJkaXplZCBtYXBwaW5nIGZyb20gU0lQIFVSSSB0byBhbiBIVFRQIFVSTCB3 aWxsIGFsd2F5cyBjYXVzZSBzb21lIGRlcGxveW1lbnQgcHJvYmxlbXMsIHRoZSBTSVAgRE5TIFNS ViByZWNvcmQgbWF5IHBvaW50IHRvIGEgZGlmZmVyZW50IHNlcnZlciB0aGFuIHRoZSBIVFRQIERO UyBTUlYgcmVjb3JkLiZuYnNwOyBQdXJpdHkgb2YgcHJvdG9jb2wgb25seSBldmVyIHdvcmtzIHVu dGlsIHJlYWwtd29ybGQgcHJvYmxlbXMgbXVzdCBiZSBzb2x2ZWQgYnkgaXQuJm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVu LXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkVuYWJsaW5nIFNJUCB0byBwcm92 aWRlIHJlYWwtd29ybGQgc29sdXRpb25zIGluIGl0cyBwcm9ibGVtIHNwYWNlIGlzbid0IGFuIGFi dXNlIG9mIHRoZSBwcm90b2NvbC4mbmJzcDsgU0lQIGJhc2VkIGNsaWVudHMsIGFnZW50cywgYW5k IHNlcnZpY2VzIGFyZSBnb2luZyB0byBuZWVkIHRvIGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhl ciB0byBjb29yZGluYXRlIHRoYXQgaGFuZGxpbmcgb2Ygc2Vzc2lvbnMuJm5ic3A7IFlvdSBjYW4g YXJndWUgdGhhdCB0aGVyZSBpc24ndCBhIHNlc3Npb24gdG8gYmUgZm91bmQgYnV0IHRoaXMgY29v cmRpbmF0aW9uIGlzIHJlcXVpcmVkIHRvIHByb3Blcmx5IGhhbmRsZSBzZXNzaW9ucyBhbmQgaXMg dGhlcmVmb3JlIHN0cm9uZ2x5IHJlbGF0ZWQgdG8gc2Vzc2lvbnMuPC9GT05UPjwvU1BBTj48U1BB TiBMQU5HPSJlbi11cyI+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJl bi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5JIGRvbid0IGJlbGlldmUgdGhh dCB3ZSBhcmUgZG9pbmcgU0lQIG9yIFNJTVBMRSBhIHNlcnZpY2UgYnkgbGltaXRpbmcgdGhlIHBy b3RvY29sIHN1Y2ggdGhhdCBpdCBjYW4ndCBwcm92aWRlIGRlcGxveWFibGUgc29sdXRpb25zIHdp dGhvdXQgdGhlIGFzc2lzdGFuY2Ugb2Ygb3RoZXIgaGlnaCBsZXZlbCBwcm90b2NvbHMgKHBsZWFz ZSwgbm8gb25lIG5lZWQgdG8gcG9pbnQgdG8gRE5TIGFuZCBESENQIGFzIGNvdW50ZXIgZXhhbXBs ZXMpIEhUVFAgZG9lc24ndCByZXF1aXJlIFNNVFAgb3IgRlRQLiZuYnNwOyBTbyB3aHkgc2hvdWxk PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi11cyI+IDxGT05UIFNJWkU9MiBGQUNFPSJDb3Vy aWVyIE5ldyI+U0lQLzwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9 MiBGQUNFPSJDb3VyaWVyIE5ldyI+U0lNUExFIHJlcXVpcmUgSFRUUD88L0ZPTlQ+PC9TUEFOPjwv UD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9 IkNvdXJpZXIgTmV3Ij5XPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0la RT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5lPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi11cyI+ IDxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+c2hvdWxkPC9GT05UPjwvU1BBTj48U1BB TiBMQU5HPSJlbi11cyI+IDxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+cmVjb2duaXpl IHRoYXQgaW1wbGVtZW50ZXJzIGFyZSBnb2luZyB0byB3cml0ZSBhcHBsaWNhdGlvbiBzcGVjaWZp YyBleHRlbnNpb25zIGFuZCB0cnkgdG8gbWluaW1pemUgdGhlIGltcGFjdDwvRk9OVD48L1NQQU4+ PFNQQU4gTEFORz0iZW4tdXMiPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPm9mIHRo ZXNlIGV4dGVuc2lvbjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8Rk9OVCBTSVpF PTIgRkFDRT0iQ291cmllciBOZXciPm9uIFNJUCBieSBzYXlpbmcsICZxdW90O1B1dCB5b3UgYXBw bGljYXRpb24gc3BlY2lmaWMgZXh0ZW5zaW9ucyBoZXJlLiZxdW90OyZuYnNwOyBUaGVuIFNJUCB3 aWxsIGhhdmUgdGhlIGZvbGxvd2luZyBtYWpvciBwaWVjZXM6IFNlc3Npb24gTWFuYWdlbWVudCwg Tm90aWZpY2F0aW9uLCBNZXNzYWdpbmcsIEFwcGxpY2F0aW9uIERhdGEgYW5kIG90aGVyIGJyb2Fk bHkgZXhwZWN0ZWQgZXh0ZW5zaW9ucy4gPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxF RlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Q1BM IGFuZCBwcmVzZW5jZSBhdXRob3JpemF0aW9uIGFyZSB0d28gc3BlY2lmaWMgZXhhbXBsZXMgb2Yg dGhlIG5lZWQgZm9yIGNsaWVudHMgdG8gc2VuZCBkYXRhIHRvIGFnZW50cyBhbmQvb3Igc2VydmVy LiZuYnNwOyBTbyBpdCBpcyBvYnZpb3VzIHRvIG1lIHRoYXQgU0lQIG5lZWRzIGEgbWVjaGFuaXNt IGZvciBzb21lIGZvcm0gYTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8Rk9OVCBT SVpFPTIgRkFDRT0iQ291cmllciBOZXciPnNlc3Npb248L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9 ImVuLXVzIj4gPEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5oYW5kbGluZzwvRk9OVD48 L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+ PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi11cyI+IDxGT05UIFNJWkU9MiBGQUNFPSJDb3Vy aWVyIE5ldyI+ZGF0YSBleGNoYW5nZS4mbmJzcDsgPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFM SUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5l dyI+U28gaWYgd2UgY2FuIGFncmVlIHRoYXQgYXBwbGljYXRpb24gc3BlY2lmaWMgZXh0ZW5zaW9u cyBhbmQgZGF0YSBleGNoYW5nZSBhcmUgYSByZWFsaXR5IG9mIHRoZTwvRk9OVD48L1NQQU4+PFNQ QU4gTEFORz0iZW4tdXMiPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPlNJUC88L0ZP TlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBO ZXciPlNJTVBMRSB0aGVuIHdoeSBkb24ndCB3ZSBqdXN0IGNvbWJpbmUgdGhlbT8mbmJzcDsgQm90 aCBTRVJWSUNFIGFuZCBTRVREQVRBIGhhdmUgYmVlbiBwcm9wb3NlZC4mbmJzcDsgSXQgc2VlbXMg dG8gbWUgdGhhdCB0aGV5IGFyZSByZWFsbHkgdGhlIHNhbWUgdGhpbmcuJm5ic3A7PC9GT05UPjwv U1BBTj48U1BBTiBMQU5HPSJlbi11cyI+IDxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+ RWFjaCBpczwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNF PSJDb3VyaWVyIE5ldyI+IHNlbmRpbmcgY29udGVudCBmcm9tIG9uZSBTSVAgZW50aXR5IHRvIGFu b3RoZXIgd2l0aCB0aGUgZXhwZWN0YXRpb24gdGhhdCB0aGF0IGNvbnRlbnQgd2lsbCBiZSB1c2Vk PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJp ZXIgTmV3Ij4gaW4gdGhlIFNJUCBzb2x1dGlvbiBzcGFjZTwvRk9OVD48L1NQQU4+PFNQQU4gTEFO Rz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+LiZuYnNwOzwvRk9OVD48 L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxT UEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPlRoZSBxdWVz dGlvbiB0aGVuIGlzIHdoYXQgZG8gd2UgY2FsbCB0aGlzIG5ldyBTSVAgbWV0aG9kPyZuYnNwOyBN eSBwZXJzb25hbCBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGNhbGwgaXQgU0VSVklDRS4mbmJzcDsg U0VUREFUQSBpbXBsaWVzIHN0b3JhZ2VzIGFuZCBldmVyeXRoaW5nIGRpc2N1c3NlZCBzbyBmYXIg aGFzIGNlbnRlcmVkIG9uIHByb3ZpZGluZyBhIHNlcnZlciBvciBhZ2VudCB3aXRoIHNvbWUgZGF0 YSBpdCBjYW4gdXNlIHRvIHByb3ZpZGUgc2Vzc2lvbiBoYW5kbGluZy4mbmJzcDsgVGhlcmVmb3Jl LCB0aGUgY2xpZW50IGlzIHJlcXVlc3RpbmcgYSBzZXJ2aWNlIGZyb20gdGhlIHNlcnZlcjwvRk9O VD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBO ZXciPmFuZC88L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFD RT0iQ291cmllciBOZXciPm9yIGFnZW50LiZuYnNwOyZuYnNwOyBXaGF0IGNvbnRlbnQgaXMgY2Fy cmllZCBieSB0aGlzIG5ldyBtZXRob2QgaXMgYXBwbGljYXRpb24gc3BlY2lmaWMuJm5ic3A7IElu IHRoZSBjYXNlIG9mIFNJTVBMRSB3ZTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8 Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPnNob3VsZDwvRk9OVD48L1NQQU4+PFNQQU4g TEFORz0iZW4tdXMiPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPnNwZWNpZnk8L0ZP TlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj4gPEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIg TmV3Ij50aGlzIGNvbnRlbnQuJm5ic3A7IE90aGVyIGV4dGVuc2lvbnMgYW5kPC9GT05UPjwvU1BB Tj48U1BBTiBMQU5HPSJlbi11cyI+IDxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+YXBw bGljYXRpb24gbWlnaHQgY2g8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBT SVpFPTIgRkFDRT0iQ291cmllciBOZXciPm88L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVz Ij48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPm9zZSBTT0FQLiZuYnNwOyBJIGZvciBv bmUgd291bGQgbGlrZSB0byBzZWUgU0lNUExFIHVzZSBTT0FQPC9GT05UPjwvU1BBTj48U1BBTiBM QU5HPSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4sPC9GT05UPjwvU1BB Tj48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4gb25l IGVuY29kaW5nIHNjaGVtZSB0aGF0IGlzIGV4dGVuc2libGUgYW5kIGFscmVhZHkgZGVmaW5lZCB3 aXRoIGEgZ3Jvd2luZyBpbXBsZW1lbnRhdGlvbiBiYXNlLiZuYnNwOyZuYnNwOyA8L0ZPTlQ+PC9T UEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0y IEZBQ0U9IkNvdXJpZXIgTmV3Ij5SZWdhcmRzLDwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElH Tj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXci PkRhdmlkIEouIFNpbW9uczwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFO IExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPlNERSBMZWFkPC9G T05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05U IFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+V2luZG93IFJUQzwvRk9OVD48L1NQQU4+PFNQQU4g TEFORz0iZW4tdXMiPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4t dXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08L0ZPTlQ+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11 cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5Gcm9tOiBKb25hdGhhbiBSb3NlbmJl cmcgWzxBIEhSRUY9Im1haWx0bzpqZHJvc2VuQGR5bmFtaWNzb2Z0LmNvbSI+bWFpbHRvOmpkcm9z ZW5AZHluYW1pY3NvZnQuY29tPC9BPl0gPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxF RlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+U2Vu dDogVHVlc2RheSwgSnVuZSAxMiwgMjAwMSAxMDo0MCBQTTwvRk9OVD48L1NQQU4+PC9QPg0KDQo8 UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmll ciBOZXciPlRvOiBEYXZpZCBTaW1vbnM7IEpvbmF0aGFuIFJvc2VuYmVyZzsgUm9iZXJ0IEJyb3du OyBzaW1wbGVAbWFpbG1hbi5keW5hbWljc29mdC5jb208L0ZPTlQ+PC9TUEFOPjwvUD4NCg0KPFAg QUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIg TmV3Ij5TdWJqZWN0OiBSRTogW1NpbXBsZV0gVGhvdWdodHMgb24gdXBsb2FkaW5nIGF1dGhvcml6 YXRpb24gZG9jdW1lbnRzPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4g TEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxT UEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPiZndDsgRnJv bTogRGF2aWQgU2ltb25zIFs8QSBIUkVGPSJtYWlsdG86ZHNpbW9uc0B3aW5kb3dzLm1pY3Jvc29m dC5jb20iPm1haWx0bzpkc2ltb25zQHdpbmRvd3MubWljcm9zb2Z0LmNvbTwvQT5dPC9GT05UPjwv U1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9 MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jmd0OyBTZW50OiBUdWVzZGF5LCBKdW5lIDEyLCAyMDAxIDI6 NDUgUE08L0ZPTlQ+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11 cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IFRvOiBKb25hdGhhbiBSb3Nl bmJlcmc7IFJvYmVydCBCcm93bjsgc2ltcGxlQG1haWxtYW4uZHluYW1pY3NvZnQuY29tPC9GT05U PjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJ WkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jmd0OyBTdWJqZWN0OiBSRTogW1NpbXBsZV0gVGhvdWdo dHMgb24gdXBsb2FkaW5nIGF1dGhvcml6YXRpb24gZG9jdW1lbnRzPC9GT05UPjwvU1BBTj48L1A+ DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJD b3VyaWVyIE5ldyI+Jmd0OyA8L0ZPTlQ+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BB TiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvRk9O VD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBT SVpFPTIgRkFDRT0iQ291cmllciBOZXciPiZndDsgSXQgaXMgb2J2aW91cyB0byBtZSB0aGF0IFNJ UCB3YXMgd3JpdHRlbiB0byBiZSBhIHByb3RvY29sIGJldHdlZW4gdHdvPC9GT05UPjwvU1BBTj48 L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNF PSJDb3VyaWVyIE5ldyI+Jmd0OyBlbnRpdGllcyB0aGF0IGhhdmUgZGlyZWN0IGFjY2VzcyB0byB0 aGUgZW5kIHVzZXIuJm5ic3A7IFdpdGhvdXQgdGhlIHJlYWw8L0ZPTlQ+PC9TUEFOPjwvUD4NCg0K PFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7IGNvbmNlcHQgdGhhdCBhZ2VudHMgbWF5IGJlIHVzZWQgb24gc2VydmVycyB0 aGF0IHVzZXJzIG11c3QgPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4g TEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jmd0OyBhY2Nlc3Nl ZCBmb3JtPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4t dXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jmd0OyBhIHJlbW90ZSBjbGllbnRz LiA8L0ZPTlQ+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+ PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5Ob3QgcmVhbGx5LiBUaGUgbW9zdCBjb21t b24gZm9ybSBvZiBTSVAgVUEgaXMgYW4gYWdlbnQgdGhhdHMgcXVpdGUgcmVtb3RlPC9GT05UPjwv U1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9 MiBGQUNFPSJDb3VyaWVyIE5ldyI+ZnJvbSB0aGUgY2xpZW50IC0gYSBQU1ROIGdhdGV3YXkuIFRo ZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgdXNlciBhbmQgaXRzPC9GT05UPjwvU1BBTj48L1A+DQoN CjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3Vy aWVyIE5ldyI+JnF1b3Q7YWdlbnQmcXVvdDsgLSB0aGUgZ2F0ZXdheSAtIGlzIHZpYSBQU1ROIHNp Z25hbGluZyBwcm90b2NvbHMuIFRvdGFsbHkgb3V0c2lkZSB0aGU8L0ZPTlQ+PC9TUEFOPjwvUD4N Cg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNv dXJpZXIgTmV3Ij5zY29wZSBvZiBTSVAuIEluZGVlZCwgYSBTSVAgY2xpZW50IGlzIGEgJnF1b3Q7 dXNlciBhZ2VudCZxdW90Oywgc28gdGhlIG5vdGlvbiBvZiBpdDwvRk9OVD48L1NQQU4+PC9QPg0K DQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291 cmllciBOZXciPmJlaW5nIGFuIGFnZW50IG9uIGJlaGFsZiBvZiBhIHVzZXIgaXMgY29yZSB0byB0 aGUgbW9kZWwuPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0i ZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+T3RoZXJzIGhhdmUgd3JpdHRl biBhcHBsaWNhdGlvbnMsIGxpa2UgY2xpY2stdG8tdGFsaywgd2hlcmUgdGhlIHVzZXIgaXMgb24g YTwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48 Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPndlYiBicm93c2VyLCBhbmQgY2FsbHMgYXJl IGluaXRpYXRlZCB0aHJvdWdoIHdlYiBjbGlja3MgdG8gYSByZW1vdGUgc2VydmVyPC9GT05UPjwv U1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9 MiBGQUNFPSJDb3VyaWVyIE5ldyI+dGhhdCBhY3RzIGFzIHRoZSB1c2VyIGFnZW50LiBXb3JrcyBq dXN0IGZpbmUuPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0i ZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+T3RoZXJzIGhhdmUgd3JpdHRl biBhcHBzIHdoZXJlIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgdXNlciBhbmQgdGhlIGFnZW50 PC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxG T05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+aXMgdm9pY2UuIFRIaW5ncyBsaWtlIHBlcnNv bmFsIGF0dGVuZGFudHMsIHdoZXJlIHlvdSBjYWxsIHVwIGFuZCBzYXkgJnF1b3Q7Y2FsbDwvRk9O VD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBT SVpFPTIgRkFDRT0iQ291cmllciBOZXciPmJvYiZxdW90OywgYXJlIGV4YW1wbGVzIG9mIHRoaXMu IFRoZSBhZ2VudCBzcGVha3MgU0lQIHRvIG1ha2UgdGhlIGNhbGwsIGJ1dCB0aGU8L0ZPTlQ+PC9T UEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0y IEZBQ0U9IkNvdXJpZXIgTmV3Ij5jb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIHVzZXIgYW5kIHRo ZSBhZ2VudCBpcyB2aWEgc3BlZWNoIHJlY29nbml0aW9uLjwvRk9OVD48L1NQQU4+PC9QPg0KDQo8 UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmll ciBOZXciPiZndDsgVGhlIGNvbnRyb2wgb2YgdGhlc2UgYWdlbnRzIHdpbGwgcmVxdWlyZSBhPC9G T05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05U IFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jmd0OyBzaWduaWZpY2FudCBudW1iZXIgb2YgcmVx dWVzdHMgZm9ybSB0aGUgdXNlcidzIGNsaWVudC4gPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFM SUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5l dyI+U3VyZS4gQW5kIGluIHRoZSBjdXJyZW50IHVzZXMsIGl0cyBkb25lIHZpYSBIVFRQLCBJU1VQ LCBzcGVlY2gsIGV0Yy48L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj48L1NQQU4+PC9Q Pg0KPEJSPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIg RkFDRT0iQ291cmllciBOZXciPiZndDsgQXV0aGVudGljYXRpb248L0ZPTlQ+PC9TUEFOPjwvUD4N Cg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNv dXJpZXIgTmV3Ij4mZ3Q7IHVwbG9hZCBpcyBqdXN0IG9uZSBvZiBzZXZlcmFsIGludGVyYWN0aW9u cyB0aGF0IHdpbGwgYmUgPC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4g TEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Jmd0OyBuZWVkZWQg Zm9yIHJlYWw8L0ZPTlQ+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJl bi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IHdvcmxkIGRlcGxveW1l bnRzLiZuYnNwOyBTbyBpbnN0ZWFkIG9mIHBvbGx1dGluZyBTSVAgd2l0aCBhIGxvdCBvZiA8L0ZP TlQ+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQg U0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IGRpZmZlcmVudDwvRk9OVD48L1NQQU4+PC9Q Pg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0i Q291cmllciBOZXciPiZndDsgbWV0aG9kcyBJIHRoaW5rIHdlIHNob3VsZCBnaXZlIHNlcmlvdXMg Y29uc2lkZXJhdGlvbiB0byBlbmRvcnNpbmcgYTwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElH Tj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXci PiZndDsgc2luZ2xlIG1ldGhvZCB0byBiZSB1c2VkIGJ5IGNsaWVudHMgdG8gY29tbXVuaWNhdGUg d2l0aCByZW1vdGUgYWdlbnRzLjwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxT UEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkEgdHJ1bHkg Z2VuZXJhbCBtZWNoYW5pc20gZm9yIHVzZXJzIHRvIGNvbW11bmljYXRlIHdpdGggcmVtb3RlIGFn ZW50cyBpcyBmYXI8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIg RkFDRT0iQ291cmllciBOZXciPjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8Rk9O VCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPmJleW9uZCB0aGUgc2NvcGUgb2YgU0lQIG9yIFNJ TVBMRS4gQXMgSSBoYXZlIHBvaW50ZWQgb3V0IGFib3ZlLCB0aGluZ3MgbGlrZTwvRk9OVD48L1NQ QU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIg RkFDRT0iQ291cmllciBOZXciPkhUVFAgKGFuZCB0aGUgSFRNTCBmb3JtcyB0aGF0IGFyZSB1c2Vk IHRvIGRyaXZlciB1c2VyIGlucHV0KSBhbmQgSVNVUCBhcmU8L0ZPTlQ+PC9TUEFOPjxTUEFOIExB Tkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPjwvRk9OVD48L1NQQU4+ PFNQQU4gTEFORz0iZW4tdXMiPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPnByb3Rv Y29scyB1c2VkIGZvciB0aGlzIHB1cnBvc2UuIFJlZ3VsYXIsIEhUVFAgYmFzZWQgU09BUCBtaWdo dCBiZSBhbm90aGVyPC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQgU0laRT0y IEZBQ0U9IkNvdXJpZXIgTmV3Ij48L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj4gPEZP TlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5leGFtcGxlIG9mIHN1Y2ggYSB0aGluZy4gPC9G T05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05U IFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+W0RhdmlkIFNpbW9uc108L0ZPTlQ+PC9TUEFOPjxT UEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkkgd291bGQ8 L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj4gPEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJp ZXIgTmV3Ij5kaXNhZ3JlZTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJ WkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi11cyI+ IDxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+dGhhdCBwcm92aWRpbmcgcmljaCBzb2x1 dGlvbnMgdG8gc2Vzc2lvbjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8Rk9OVCBT SVpFPTIgRkFDRT0iQ291cmllciBOZXciPm1hbmFnZW1lbnQ8L0ZPTlQ+PC9TUEFOPjxTUEFOIExB Tkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPiBpcyBiZXlvbmQgdGhl IHNjb3BlIG9mIFNJUC4mbmJzcDsgVGhlIHVzZSBvZiBvdGhlciBwcm90b2NvbHMgd2lsbCBjYXVz ZSBpc3N1ZXMgdGhhdCB3ZTwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8Rk9OVCBT SVpFPTIgRkFDRT0iQ291cmllciBOZXciPnNvbHZlIGluIGFuPC9GT05UPjwvU1BBTj48U1BBTiBM QU5HPSJlbi11cyI+IDxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+ZXhwZWN0YWJsZTwv Rk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVy IE5ldyI+IG1hbm9yLjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8L1NQQU4+PC9Q Pg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0i Q291cmllciBOZXciPkkgdGhpbmsgd2UgaGF2ZSBhIGZhaXJseSBjb25jcmV0ZSBwcm9ibGVtIGhl cmUsIGFuZCBJJ2QgcHJlZmVyIHRvIHNvbHZlIGl0PC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFM SUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5l dyI+aW4gYXMgc2ltcGxlIGFuZCB3ZWxsIGRlZmluZWQgbWFubmVyIGFzIHBvc3NpYmxlLiA8L0ZP TlQ+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+PEZPTlQg U0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij5bRGF2aWQgU2ltb25zXTwvRk9OVD48L1NQQU4+PFNQ QU4gTEFORz0iZW4tdXMiPjxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Q29uY3JldGUg eWVzIGJ1dCBzaW1wbGUgaXMgZG9lc24ndCBzZWVtIHRvIGJlLiZuYnNwOyBFbHNlIHdlPC9GT05U PjwvU1BBTj48U1BBTiBMQU5HPSJlbi11cyI+IDxGT05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5l dyI+d291bGQgaGF2ZSBoYWQ8L0ZPTlQ+PC9TUEFOPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBT SVpFPTIgRkFDRT0iQ291cmllciBOZXciPiBjb25zZW5zdXMgb24gYSBzb2x1dGlvbiBieSBub3cu PC9GT05UPjwvU1BBTj48U1BBTiBMQU5HPSJlbi11cyI+Jm5ic3A7PEZPTlQgU0laRT0yIEZBQ0U9 IkNvdXJpZXIgTmV3Ij4gQWNjZXNzIGNvbnRyb2wgaXMgYWx3YXlzIG1vcmUgY29tcGxleCB0aGVu IGl0IHNlZW1zLjwvRk9OVD48L1NQQU4+PFNQQU4gTEFORz0iZW4tdXMiPiA8L1NQQU4+PC9QPg0K PEJSPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFD RT0iQ291cmllciBOZXciPi1Kb25hdGhhbiBSLjwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElH Tj1MRUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXci Pi0tLTwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1MRUZUPjxTUEFOIExBTkc9ImVuLXVz Ij48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPkpvbmF0aGFuIEQuIFJvc2VuYmVyZywg UGguRC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNzIgRWFnbGUgUm9jayBBdmUu PC9GT05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxG T05UIFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+Q2hpZWYgU2NpZW50aXN0Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpcnN0IEZsb29yPC9G T05UPjwvU1BBTj48L1A+DQoNCjxQIEFMSUdOPUxFRlQ+PFNQQU4gTEFORz0iZW4tdXMiPjxGT05U IFNJWkU9MiBGQUNFPSJDb3VyaWVyIE5ldyI+ZHluYW1pY3NvZnQmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgRWFzdCBIYW5vdmVyLCBOSiAwNzkzNjwvRk9OVD48L1NQQU4+PC9QPg0KDQo8UCBBTElHTj1M RUZUPjxTUEFOIExBTkc9ImVuLXVzIj48Rk9OVCBTSVpFPTIgRkFDRT0iQ291cmllciBOZXciPmpk cm9zZW5AZHluYW1pY3NvZnQuY29tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZBWDombmJzcDsmbmJzcDsgKDk3MykgOTUyLTUw NTA8L0ZPTlQ+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5HPSJlbi11cyI+ PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij48QSBIUkVGPSJodHRwOi8vd3d3Lmpkcm9z ZW4ubmV0Ij5odHRwOi8vd3d3Lmpkcm9zZW4ubmV0PC9BPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQSE9ORTogKDk3 MykgOTUyLTUwMDA8L0ZPTlQ+PC9TUEFOPjwvUD4NCg0KPFAgQUxJR049TEVGVD48U1BBTiBMQU5H PSJlbi11cyI+PEZPTlQgU0laRT0yIEZBQ0U9IkNvdXJpZXIgTmV3Ij48QSBIUkVGPSJodHRwOi8v d3d3LmR5bmFtaWNzb2Z0LmNvbSI+aHR0cDovL3d3dy5keW5hbWljc29mdC5jb208L0E+PC9GT05U PjwvU1BBTj48L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= ------_=_NextPart_001_01C0F46C.D3D7DC0D-- From theodore.havinis@openwave.com Thu Jun 14 02:46:37 2001 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 CAA09092 for ; Thu, 14 Jun 2001 02:46:36 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010614064612.FNIP7886.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Thu, 14 Jun 2001 01:46:12 -0500 Received: from harviniT ([206.35.147.89]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with SMTP id <20010614064629.EJCO10672.oe-ismta2.bizmailsrvcs.net@harviniT>; Thu, 14 Jun 2001 01:46:29 -0500 From: "Theodore Havinis" To: "Jonathan Rosenberg" , Subject: RE: [Simple] authorization for presence Date: Wed, 13 Jun 2001 23:47:57 -0700 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 3753 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: TH>-----Original Message----- TH>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] TH>Sent: Tuesday, June 12, 2001 10:51 PM TH>To: 'Theodore Havinis'; Jonathan Rosenberg; TH>simple@mailman.dynamicsoft.com TH>Subject: RE: [Simple] authorization for presence TH> TH> TH> TH> TH> TH> TH>> -----Original Message----- TH>> From: Theodore Havinis [mailto:theodore.havinis@openwave.com] TH>> Sent: Tuesday, June 12, 2001 1:55 PM TH>> To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com TH>> Subject: RE: [Simple] authorization for presence TH>> TH>> AS>Right; as I said, its a matter of policy. Remember, there TH>> are watchers at TH>> AS>two levels here. There are the set of folks who subscribed to my TH>> AS>presence. TH>> AS>Then, there are the set of folks who subscribed to changes in my TH>> AS>watcherinfo. That is, the set of folks that want to get TH>> notified when TH>> AS>someone tries to subscribe to my presence. These two sets TH>> of watchers are TH>> AS>not the same. TH>> AS> TH>> TH>> I guess what confuses me is why do we mix together under the TH>> mechanism of TH>> active/pending subscriptions (which is nice approach) with TH>> the 'set of folks TH>> to get TH>> notified when someone tries to subscribe to my presence'. The TH>> later is a TH>> separate application as far as I am concerned. TH>> ie I subscribe to an application (presentity) that monitors TH>> Bob's watchers. TH> TH>I am not understanding what you're saying here. TH> TH>There is a server, and it knows about my presence. My presence is TH>effectively state that changes dynamically. When it changes, the TH>subscribers TH>to that state get notified. That server has another piece of TH>state, which is TH>the set of subscribers to my presence. Thats state changes TH>dynamically too, TH>for example, when someone subscribes to my presence. Users can TH>subscribe to TH>this other piece of state, "presence.watcherinfo", and they get notified TH>when it changes. TH> TH>The set of people subscribed to my presence is unrelated to the set of TH>people who are subscribed to presence.watcherinfo. Thus, the set TH>of people TH>subscribed to my presence (the subscribers of the event TH>"presence"), is not TH>the same as the set of people subscribed to my TH>"presence.watcherinfo". The TH>set of people who subscribe to my presence affects the state of TH>presence.watcherinfo, by definition, but thats the only coupling. TH> TH>Does that clarify it? Thanks. Yes it does clarify it. The confusing part is why do we bother about the second state from the standards point of view. Quoting from above "...That server has another piece of state, which is the set of subscribers to my presence. That state changes dynamically too, for example, when someone subscribes to my presence. Users can subscribe to this other piece of state, "presence.watcherinfo", and they get notified when it changes..." Your description, quoting from above again "...There is a server, and it knows about my presence. My presence is effectively state that changes dynamically. When it changes, the subscribers to that state get notified... " That statement should be enough as far as I am concerned. Its implicit that we can have sub-packages associated with a presentity. Actually I tend to see 'presence.watcherinfo' as a presentity itself. Kind Rgds Theodore TH> TH>-Jonathan R. TH> TH>--- TH>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. TH>Chief Scientist First Floor TH>dynamicsoft East Hanover, NJ 07936 TH>jdrosen@dynamicsoft.com FAX: (973) 952-5050 TH>http://www.jdrosen.net PHONE: (973) 952-5000 TH>http://www.dynamicsoft.com TH> TH> From ffo@ifrance.com Thu Jun 14 03:21:43 2001 Received: from lh10.opsion.fr (lh10.opsion.fr [212.73.208.236]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id DAA09223 for ; Thu, 14 Jun 2001 03:21:42 -0400 (EDT) Received: from 193.249.126.196 [193.249.126.196] by lh10.opsion.fr; Thu, 14 Jun 2001 07:24:53 GMT Message-ID: <000c01c0f4a2$6ff30250$c47ef9c1@ffocp800> From: "Francois-Frederic Ozog" To: "Jonathan Rosenberg" , , "'Robert Brown'" , "Theodore Havinis" Cc: References: Subject: Re: [Simple] authorization for presence Date: Thu, 14 Jun 2001 09:20:04 +0200 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 3311 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: What about using the MESSAGE method to carry the authorization document ? Content-Type header would be set to: message/presence-authorization or whatever works like application/simple-authorization... ----- Original Message ----- From: "Jonathan Rosenberg" To: ; "'Robert Brown'" ; "Theodore Havinis" ; "Jonathan Rosenberg" ; ; "'Francois-Frederic Ozog'" Sent: Wednesday, June 13, 2001 7:44 AM Subject: RE: [Simple] authorization for presence > > > > > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Tuesday, June 12, 2001 12:11 PM > > To: 'Robert Brown'; Theodore Havinis; Jonathan Rosenberg; > > simple@mailman.dynamicsoft.com; 'Francois-Frederic Ozog' > > Subject: RE: [Simple] authorization for presence > > > > > > Some recent posts have made it clear that the subpackage proposal > > may be widely misunderstood. I'll attempt to clarify a couple > > of points. > > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > > From: sip:bar.com > > > To: sip:peter@bar.com > > > Event: watcherinfo > > > Cseq: 34 > > > > ... > > > > "Event: watcherinfo" will **NEVER** be a valid thing to say. We are > > proposing this to be a *subpackage*, which means it must be contained > > in another package. For the purposes of the discussions we've been > > having here, my guess is that you mean to say "Event: > > presence.watcherinfo" > > Right. A notification for a watcherinfo event to my presence would have the > Event name of presence.watcherinfo. Such a notification would occur when > someone asked to subscribe to my presence. > > > > > One of the consequences of this fact is that, for example, including > > "event" as part of the XML document makes no sense. > > > > > > > > > auth="allow" /> > > > > attribute="geolocation" auth="allow" > > /> > > > > auth="block" /> > > > > > > > Since this document will be carried in a NOTIFY which has an > > "Event:" header of "presence.watcherinfo," > > Well, thats the question. My interpretation of this document above is that > its the thing thats carried in the AUTH (or whatever we defined) method that > sets authorization policy. You are correct that the document carried in a > NOTIFY of presence.watcherinfo has no need to define the event. But, the > document carried in the AUTH does need to define 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 ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif From hisham.khartabil@hotsip.com Thu Jun 14 05:15:27 2001 Received: from hs004.hotsip.com ([212.28.214.197]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09539 for ; Thu, 14 Jun 2001 05:15:26 -0400 (EDT) Received: from Hash ([195.238.204.173]) by hs004.hotsip.com (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id f5E7FQn10046 for ; Thu, 14 Jun 2001 09:15:29 +0200 X-Authentication-Warning: hs004.hotsip.com: Host [195.238.204.173] claimed to be Hash From: "Hisham Khartabil" To: Date: Thu, 14 Jun 2001 12:15:19 +0300 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C0F4CB.ADA60150" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 2846 Subject: [Simple] Contact header Usage in subsequent MESSAGE Requests 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: This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C0F4CB.ADA60150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Section 6.2 or draft-ietf-simple-im-00.txt specifies that a MESSAGE request MUST contain a Contact header. Section 6.7 does not specify how this Contact should be used. The example is section 8 simply says that user2 can send the IM directly to the address in the Contact header send in the initial MESSAGE request. The use of the Contact header in subsequent requests is not clear. Can I conclude that the use of the Contact header is only a MAY? Regards, Hisham Khartabil Hotsip Finland www.hotsip.com ------=_NextPart_000_001C_01C0F4CB.ADA60150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Section 6.2 or=20 draft-ietf-simple-im-00.txt specifies that a MESSAGE request MUST = contain a=20 Contact header.
Section 6.7 does not=20 specify how this Contact should be used.
The = example is=20 section 8 simply says that user2 can send the IM directly to the address = in the=20 Contact header send in the initial MESSAGE request.
 
The = use of the=20 Contact header in subsequent requests is not clear. Can I conclude that = the use=20 of the Contact header is only a MAY?
 
Regards,
Hisham = Khartabil
Hotsip = Finland
www.hotsip.com
------=_NextPart_000_001C_01C0F4CB.ADA60150-- From jdrosen@dynamicsoft.com Thu Jun 14 05:27:53 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09598 for ; Thu, 14 Jun 2001 05:27:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA27616; Thu, 14 Jun 2001 05:31:47 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 05:27:46 -0400 Message-ID: From: Jonathan Rosenberg To: "'Hisham Khartabil'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Contact header Usage in subsequent MESSAGE Requests Date: Thu, 14 Jun 2001 05:27:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1444 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: In the older MESSAGE approach (where MESSAGE sort-of was INVITE), the Contact header had the same semantics as in INVITE - it would be used to set up the route for subsequent messages in the same IM session. However, in the current proposal, whereby INVITE establishes the session, the Contact in MESSAGE no longer serves a purpose. -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: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] Sent: Thursday, June 14, 2001 5:15 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] Contact header Usage in subsequent MESSAGE Requests Hi, Section 6.2 or draft-ietf-simple-im-00.txt specifies that a MESSAGE request MUST contain a Contact header. Section 6.7 does not specify how this Contact should be used. The example is section 8 simply says that user2 can send the IM directly to the address in the Contact header send in the initial MESSAGE request. The use of the Contact header in subsequent requests is not clear. Can I conclude that the use of the Contact header is only a MAY? Regards, Hisham Khartabil Hotsip Finland www.hotsip.com From sriramp@nortelnetworks.com Thu Jun 14 10:38:10 2001 Received: from zrc2s03g.nortelnetworks.com ([47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10438 for ; Thu, 14 Jun 2001 10:38:09 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id JAA28048 for ; Thu, 14 Jun 2001 09:39:24 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 14 Jun 2001 09:31:57 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 09:37:38 -0500 Message-ID: <9A9367D1556AD21182C40000F80930AB04411C24@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: "'Jonathan Rosenberg'" , "'Hisham Khartabil'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Contact header Usage in subsequent MESSAGE Requests Date: Thu, 14 Jun 2001 09:37:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F4DF.8D18C8F0" X-Orig: Content-Length: 7599 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: 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_01C0F4DF.8D18C8F0 Content-Type: text/plain; charset="iso-8859-1" Jonathan - you refer to a new approach using INVITE rather than MESSAGE. Could you please point me to the latest version the document that reflects this? Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, June 14, 2001 4:28 AM To: 'Hisham Khartabil'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Contact header Usage in subsequent MESSAGE Requests In the older MESSAGE approach (where MESSAGE sort-of was INVITE), the Contact header had the same semantics as in INVITE - it would be used to set up the route for subsequent messages in the same IM session. However, in the current proposal, whereby INVITE establishes the session, the Contact in MESSAGE no longer serves a purpose. -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: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] Sent: Thursday, June 14, 2001 5:15 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] Contact header Usage in subsequent MESSAGE Requests Hi, Section 6.2 or draft-ietf-simple-im-00.txt specifies that a MESSAGE request MUST contain a Contact header. Section 6.7 does not specify how this Contact should be used. The example is section 8 simply says that user2 can send the IM directly to the address in the Contact header send in the initial MESSAGE request. The use of the Contact header in subsequent requests is not clear. Can I conclude that the use of the Contact header is only a MAY? Regards, Hisham Khartabil Hotsip Finland www.hotsip.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C0F4DF.8D18C8F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Contact header Usage in subsequent MESSAGE = Requests

Jonathan - you refer to a new approach using INVITE = rather than MESSAGE. Could you please point me to the latest version = the document that reflects this?

Regards,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: = 972-685-3563
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, June 14, 2001 4:28 AM
To: 'Hisham Khartabil'; = simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Contact header Usage in = subsequent MESSAGE
Requests


In the older MESSAGE approach (where MESSAGE sort-of = was INVITE), the
Contact header had the same semantics as in INVITE - = it would be used to set
up the route for subsequent messages in the same IM = session.

However, in the current proposal, whereby INVITE = establishes the session,
the Contact in MESSAGE no longer serves a = purpose.

-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: Hisham Khartabil [mailto:hisham.khartabil@hots= ip.com]
Sent: Thursday, June 14, 2001 5:15 AM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] Contact header Usage in subsequent = MESSAGE Requests


Hi,

Section 6.2 or draft-ietf-simple-im-00.txt specifies = that a MESSAGE request
MUST contain a Contact header.
Section 6.7 does not specify how this Contact should = be used.
The example is section 8 simply says that user2 can = send the IM directly to
the address in the Contact header send in the = initial MESSAGE request.

The use of the Contact header in subsequent requests = is not clear. Can I
conclude that the use of the Contact header is only = a MAY?

Regards,
Hisham Khartabil
Hotsip Finland
www.hotsip.com
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple=

------_=_NextPart_001_01C0F4DF.8D18C8F0-- From jdrosen@dynamicsoft.com Thu Jun 14 10:43:56 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10478 for ; Thu, 14 Jun 2001 10:43:56 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA00080; Thu, 14 Jun 2001 10:47:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 10:43:15 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sriram Parameswar'" , "'Hisham Khartabil'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Contact header Usage in subsequent MESSAGE Requests Date: Thu, 14 Jun 2001 10:43:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1025 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: -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Thursday, June 14, 2001 10:38 AM To: 'Jonathan Rosenberg'; 'Hisham Khartabil'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Contact header Usage in subsequent MESSAGE Requests >Jonathan - you refer to a new approach using INVITE rather than MESSAGE. Could >you please point me to the latest version the document that reflects this? There is none yet. It has been discussed and (I think) agreed upon only recently on the list. The email which explains the idea can be found at: http://mailman.dynamicsoft.com/pipermail/simple/2001-March/000119.html -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 From jdrosen@dynamicsoft.com Thu Jun 14 10:48:20 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10521 for ; Thu, 14 Jun 2001 10:48:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA00209; Thu, 14 Jun 2001 10:52:16 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 10:48:15 -0400 Message-ID: From: Jonathan Rosenberg To: "'Theodore Havinis'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Thu, 14 Jun 2001 10:48:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3364 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: > -----Original Message----- > From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > Sent: Thursday, June 14, 2001 2:48 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] authorization for presence > > > TH>> I guess what confuses me is why do we mix together under the > TH>> mechanism of > TH>> active/pending subscriptions (which is nice approach) with > TH>> the 'set of folks > TH>> to get > TH>> notified when someone tries to subscribe to my presence'. The > TH>> later is a > TH>> separate application as far as I am concerned. > TH>> ie I subscribe to an application (presentity) that monitors > TH>> Bob's watchers. > TH> > TH>I am not understanding what you're saying here. > TH> > TH>There is a server, and it knows about my presence. My presence is > TH>effectively state that changes dynamically. When it changes, the > TH>subscribers > TH>to that state get notified. That server has another piece of > TH>state, which is > TH>the set of subscribers to my presence. Thats state changes > TH>dynamically too, > TH>for example, when someone subscribes to my presence. Users can > TH>subscribe to > TH>this other piece of state, "presence.watcherinfo", and > they get notified > TH>when it changes. > TH> > TH>The set of people subscribed to my presence is unrelated > to the set of > TH>people who are subscribed to presence.watcherinfo. Thus, the set > TH>of people > TH>subscribed to my presence (the subscribers of the event > TH>"presence"), is not > TH>the same as the set of people subscribed to my > TH>"presence.watcherinfo". The > TH>set of people who subscribe to my presence affects the state of > TH>presence.watcherinfo, by definition, but thats the only coupling. > TH> > TH>Does that clarify it? > > > Thanks. > > Yes it does clarify it. The confusing part is why do we > bother about the > second state from the standards point of view. Quoting from > above "...That > server has another piece of state, which is the set of > subscribers to my > presence. That state changes dynamically too, for example, > when someone > subscribes to my presence. Users can subscribe to this other > piece of state, > "presence.watcherinfo", and they get notified when it changes..." > > Your description, quoting from above again "...There is a > server, and it > knows about my presence. My presence is effectively state that changes > dynamically. When it changes, the > subscribers to that state get notified... " That statement > should be enough > as far as I am concerned. > > Its implicit that we can have sub-packages associated with a > presentity. > > Actually I tend to see 'presence.watcherinfo' as a presentity itself. Sure, thats another way to look at it. The only differece is that the type of information sent to subscribers of this "pseudo-presentity" is different than a normal presentity, since they are different event packages. I think we are agreeing, but differ only on how to view the concept. -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 From rsparks@dynamicsoft.com Thu Jun 14 10:52:00 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10590 for ; Thu, 14 Jun 2001 10:52:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA00243; Thu, 14 Jun 2001 10:53:47 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 10:49:46 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A8AA@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , "'Sriram Parameswar'" , "'Hisham Khartabil'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Contact header Usage in subsequent MESSAGE Requests Date: Thu, 14 Jun 2001 10:49:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1628 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: The draft is being revised and will be out in the next few weeks. RjS > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, June 14, 2001 9:43 AM > To: 'Sriram Parameswar'; 'Hisham Khartabil'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Contact header Usage in subsequent MESSAGE > Requests > > > > > > -----Original Message----- > From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] > Sent: Thursday, June 14, 2001 10:38 AM > To: 'Jonathan Rosenberg'; 'Hisham Khartabil'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Contact header Usage in subsequent > MESSAGE Requests > > > >Jonathan - you refer to a new approach using INVITE rather > than MESSAGE. > Could > >you please point me to the latest version the document that > reflects this? > > There is none yet. It has been discussed and (I think) agreed > upon only > recently on the list. The email which explains the idea can > be found at: > > http://mailman.dynamicsoft.com/pipermail/simple/2001-March/000119.html > > -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 adam.roach@ericsson.com Thu Jun 14 12:46:04 2001 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 MAA10980 for ; Thu, 14 Jun 2001 12:46:04 -0400 (EDT) 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 f5EGjoa17191; Thu, 14 Jun 2001 11:45:50 -0500 (CDT) 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 f5EGjoW07127; Thu, 14 Jun 2001 11:45:50 -0500 (CDT) Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA15626; Thu, 14 Jun 2001 11:45:49 -0500 (CDT) Reply-To: To: "'Francois-Frederic Ozog'" , "Jonathan Rosenberg" , , "'Robert Brown'" , "Theodore Havinis" Cc: Subject: RE: [Simple] authorization for presence Date: Thu, 14 Jun 2001 11:45:49 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251856@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: <000c01c0f4a2$6ff30250$c47ef9c1@ffocp800> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Length: 4433 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: MESSAGE has render semantics associated with it. It means, "the body of this request contains data that is to be rendered in a reasonable manner for the human to whom I have addressed it." What you have suggested is a wildly different application, which generally means that you should create a new method for it. This is widely overlooked: methods actually *mean* something. If all behavior were based on content-type and content-disposition, we could have saved ourselves a *lot* of trouble by defining a transport for sending raw MIME bodies on the wire, and called ourselves done. /a > -----Original Message----- > From: Francois-Frederic Ozog [mailto:ffo@ifrance.com] > Sent: Thursday, June 14, 2001 2:20 AM > To: Jonathan Rosenberg; adam.roach@ericsson.com; 'Robert Brown'; > Theodore Havinis > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] authorization for presence > > > What about using the MESSAGE method to carry the > authorization document ? > > Content-Type header would be set to: message/presence-authorization or > whatever works like application/simple-authorization... > > > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: ; "'Robert Brown'" > ; > "Theodore Havinis" ; "Jonathan > Rosenberg" > ; ; > "'Francois-Frederic Ozog'" > Sent: Wednesday, June 13, 2001 7:44 AM > Subject: RE: [Simple] authorization for presence > > > > > > > > > > > > > -----Original Message----- > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > Sent: Tuesday, June 12, 2001 12:11 PM > > > To: 'Robert Brown'; Theodore Havinis; Jonathan Rosenberg; > > > simple@mailman.dynamicsoft.com; 'Francois-Frederic Ozog' > > > Subject: RE: [Simple] authorization for presence > > > > > > > > > Some recent posts have made it clear that the subpackage proposal > > > may be widely misunderstood. I'll attempt to clarify a couple > > > of points. > > > > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > > > From: sip:bar.com > > > > To: sip:peter@bar.com > > > > Event: watcherinfo > > > > Cseq: 34 > > > > > > ... > > > > > > "Event: watcherinfo" will **NEVER** be a valid thing to > say. We are > > > proposing this to be a *subpackage*, which means it must > be contained > > > in another package. For the purposes of the discussions we've been > > > having here, my guess is that you mean to say "Event: > > > presence.watcherinfo" > > > > Right. A notification for a watcherinfo event to my > presence would have > the > > Event name of presence.watcherinfo. Such a notification > would occur when > > someone asked to subscribe to my presence. > > > > > > > > One of the consequences of this fact is that, for > example, including > > > "event" as part of the XML document makes no sense. > > > > > > > > > > > > > auth="allow" /> > > > > > > attribute="geolocation" auth="allow" > > > /> > > > > > > auth="block" /> > > > > > > > > > > Since this document will be carried in a NOTIFY which has an > > > "Event:" header of "presence.watcherinfo," > > > > Well, thats the question. My interpretation of this > document above is that > > its the thing thats carried in the AUTH (or whatever we > defined) method > that > > sets authorization policy. You are correct that the > document carried in a > > NOTIFY of presence.watcherinfo has no need to define the > event. But, the > > document carried in the AUTH does need to define 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 > > > ______________________________________________________________ > ________________ > ifrance.com, l'email gratuit le plus complet de l'Internet ! > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... > http://www.ifrance.com/_reloc/email.emailif > > From rsparks@dynamicsoft.com Thu Jun 14 13:39:08 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11141 for ; Thu, 14 Jun 2001 13:39:08 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA02867; Thu, 14 Jun 2001 13:43:08 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 13:39:08 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A8AE@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , "'Theodore Havinis'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Thu, 14 Jun 2001 13:39:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1109 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: We touched on a danger point with following this generalization to far at the last meeting. If you take the first statement below literally, then we have to worry about managing authorization for the presence.watcherinfo presentity using the same mechanism we're discussing, leading to a telescoping problem. We'ld have servers having to handle subscriptions for presence.watcherinfo.watcherinfo. The comment in the meeting was that authorization for presence.watcherinfo would be provided somewhere outside the scope of this protocol (using static lists provisioned with an account was one suggested way a service could provide this - whatever other ways made sense to the domain would be valid). RjS > > Actually I tend to see 'presence.watcherinfo' as a > presentity itself. > > Sure, thats another way to look at it. The only differece is > that the type > of information sent to subscribers of this > "pseudo-presentity" is different > than a normal presentity, since they are different event packages. > > I think we are agreeing, but differ only on how to view the concept. > > -Jonathan R. From ffo@ifrance.com Thu Jun 14 13:47:33 2001 Received: from lh10.opsion.fr (lh10.opsion.fr [212.73.208.236]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA11187 for ; Thu, 14 Jun 2001 13:47:32 -0400 (EDT) Received: from 193.253.23.4 [193.253.23.4] by lh10.opsion.fr; Thu, 14 Jun 2001 17:50:42 GMT Message-ID: <000401c0f4f9$dea08630$0417fdc1@ffocp800> From: "Francois-Frederic Ozog" To: , "Jonathan Rosenberg" , "'Robert Brown'" , "Theodore Havinis" Cc: References: <61D824C63B99D311975E00508B0CC98502251856@eamrcnt717.exu.ericsson.se> Subject: Re: [Simple] authorization for presence Date: Thu, 14 Jun 2001 19:45:56 +0200 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 5891 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: It makes sense. I just had the feeling that we may encounter other circumstances where a PUA or a PS has to send "documents", not commands. Now, if we do not need such method, AUTH seems pretty adequate, providing that the content can be flexible. For instance, we define authorization document version 1, after a few years we refine it with version 2. Or two ways of specifying authorization may cohexist: CPL, CGI... And I still do not like HTTP method as it looses the SIP proxying mechanism: PUA must then resolve a PS SIP address down to a non-proxied URL. ----- Original Message ----- From: To: "'Francois-Frederic Ozog'" ; "Jonathan Rosenberg" ; ; "'Robert Brown'" ; "Theodore Havinis" Cc: Sent: Thursday, June 14, 2001 6:45 PM Subject: RE: [Simple] authorization for presence > MESSAGE has render semantics associated with it. It means, "the > body of this request contains data that is to be rendered in > a reasonable manner for the human to whom I have addressed it." > > What you have suggested is a wildly different application, which > generally means that you should create a new method for it. > > This is widely overlooked: methods actually *mean* something. > > If all behavior were based on content-type and content-disposition, > we could have saved ourselves a *lot* of trouble by defining a > transport for sending raw MIME bodies on the wire, and called > ourselves done. > > /a > > > -----Original Message----- > > From: Francois-Frederic Ozog [mailto:ffo@ifrance.com] > > Sent: Thursday, June 14, 2001 2:20 AM > > To: Jonathan Rosenberg; adam.roach@ericsson.com; 'Robert Brown'; > > Theodore Havinis > > Cc: simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] authorization for presence > > > > > > What about using the MESSAGE method to carry the > > authorization document ? > > > > Content-Type header would be set to: message/presence-authorization or > > whatever works like application/simple-authorization... > > > > > > > > ----- Original Message ----- > > From: "Jonathan Rosenberg" > > To: ; "'Robert Brown'" > > ; > > "Theodore Havinis" ; "Jonathan > > Rosenberg" > > ; ; > > "'Francois-Frederic Ozog'" > > Sent: Wednesday, June 13, 2001 7:44 AM > > Subject: RE: [Simple] authorization for presence > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > > Sent: Tuesday, June 12, 2001 12:11 PM > > > > To: 'Robert Brown'; Theodore Havinis; Jonathan Rosenberg; > > > > simple@mailman.dynamicsoft.com; 'Francois-Frederic Ozog' > > > > Subject: RE: [Simple] authorization for presence > > > > > > > > > > > > Some recent posts have made it clear that the subpackage proposal > > > > may be widely misunderstood. I'll attempt to clarify a couple > > > > of points. > > > > > > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > > > > From: sip:bar.com > > > > > To: sip:peter@bar.com > > > > > Event: watcherinfo > > > > > Cseq: 34 > > > > > > > > ... > > > > > > > > "Event: watcherinfo" will **NEVER** be a valid thing to > > say. We are > > > > proposing this to be a *subpackage*, which means it must > > be contained > > > > in another package. For the purposes of the discussions we've been > > > > having here, my guess is that you mean to say "Event: > > > > presence.watcherinfo" > > > > > > Right. A notification for a watcherinfo event to my > > presence would have > > the > > > Event name of presence.watcherinfo. Such a notification > > would occur when > > > someone asked to subscribe to my presence. > > > > > > > > > > > One of the consequences of this fact is that, for > > example, including > > > > "event" as part of the XML document makes no sense. > > > > > > > > > > > > > > > > > auth="allow" /> > > > > > > > > attribute="geolocation" auth="allow" > > > > /> > > > > > > > > auth="block" /> > > > > > > > > > > > > > Since this document will be carried in a NOTIFY which has an > > > > "Event:" header of "presence.watcherinfo," > > > > > > Well, thats the question. My interpretation of this > > document above is that > > > its the thing thats carried in the AUTH (or whatever we > > defined) method > > that > > > sets authorization policy. You are correct that the > > document carried in a > > > NOTIFY of presence.watcherinfo has no need to define the > > event. But, the > > > document carried in the AUTH does need to define 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 > > > > > > ______________________________________________________________ > > ________________ > > ifrance.com, l'email gratuit le plus complet de l'Internet ! > > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... > > http://www.ifrance.com/_reloc/email.emailif > > > > > ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif From ndeason@ubiquity.net Thu Jun 14 13:54:52 2001 Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA11239 for ; Thu, 14 Jun 2001 13:54:51 -0400 (EDT) Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca via smtpd (for [216.173.40.35]) with SMTP; 14 Jun 2001 18:54:40 UT Received: (private information removed) Message-ID: From: Neil Deason To: adam.roach@ericsson.com, "'Francois-Frederic Ozog'" , Jonathan Rosenberg , "'Robert Brown'" , Theodore Havinis Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Thu, 14 Jun 2001 13:25:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5831 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: > MESSAGE has render semantics associated with it. It means, "the > body of this request contains data that is to be rendered in > a reasonable manner for the human to whom I have addressed it." If that is the defined sematics of MESSAGE I fully agree. However, the word 'render' is never actually mentioned in draft-ietf-simple-im-00.txt. In re-reading this draft I am left unsure what the detailed semantics for MESSAGE are. Section 6 talks more about syntax and UAC/UAS/Proxy processing than semantics. Taking your definition, is it limited to messaging to humans? Does it mean the message data must be rendered? Is it just for IM style messaging or more general messaging? I have an assumption based on the traditional IM clients that have motivated MESSAGE, but the guidelines on SIP extensions say that SIP SHOULD define general purpose components rather than narrow ones, even at the cost of some complexity. Before anyone jumps on me I am only asking questions not suggesting answers. There are also important open issues in this area: 9.1 Must a MESSAGE actually include a message? 9.5 What would a body in a 200 OK to a MESSAGE mean? > What you have suggested is a wildly different application, which > generally means that you should create a new method for it. Indeed - to me that is SERVICE. Cheers, Neil. > This is widely overlooked: methods actually *mean* something. > > If all behavior were based on content-type and content-disposition, > we could have saved ourselves a *lot* of trouble by defining a > transport for sending raw MIME bodies on the wire, and called > ourselves done. > > /a > > > -----Original Message----- > > From: Francois-Frederic Ozog [mailto:ffo@ifrance.com] > > Sent: Thursday, June 14, 2001 2:20 AM > > To: Jonathan Rosenberg; adam.roach@ericsson.com; 'Robert Brown'; > > Theodore Havinis > > Cc: simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] authorization for presence > > > > > > What about using the MESSAGE method to carry the > > authorization document ? > > > > Content-Type header would be set to: > message/presence-authorization or > > whatever works like application/simple-authorization... > > > > > > > > ----- Original Message ----- > > From: "Jonathan Rosenberg" > > To: ; "'Robert Brown'" > > ; > > "Theodore Havinis" ; "Jonathan > > Rosenberg" > > ; ; > > "'Francois-Frederic Ozog'" > > Sent: Wednesday, June 13, 2001 7:44 AM > > Subject: RE: [Simple] authorization for presence > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > > Sent: Tuesday, June 12, 2001 12:11 PM > > > > To: 'Robert Brown'; Theodore Havinis; Jonathan Rosenberg; > > > > simple@mailman.dynamicsoft.com; 'Francois-Frederic Ozog' > > > > Subject: RE: [Simple] authorization for presence > > > > > > > > > > > > Some recent posts have made it clear that the > subpackage proposal > > > > may be widely misunderstood. I'll attempt to clarify a couple > > > > of points. > > > > > > > > > NOTIFY sip:peter@bar.com SIP/2.0 > > > > > From: sip:bar.com > > > > > To: sip:peter@bar.com > > > > > Event: watcherinfo > > > > > Cseq: 34 > > > > > > > > ... > > > > > > > > "Event: watcherinfo" will **NEVER** be a valid thing to > > say. We are > > > > proposing this to be a *subpackage*, which means it must > > be contained > > > > in another package. For the purposes of the discussions > we've been > > > > having here, my guess is that you mean to say "Event: > > > > presence.watcherinfo" > > > > > > Right. A notification for a watcherinfo event to my > > presence would have > > the > > > Event name of presence.watcherinfo. Such a notification > > would occur when > > > someone asked to subscribe to my presence. > > > > > > > > > > > One of the consequences of this fact is that, for > > example, including > > > > "event" as part of the XML document makes no sense. > > > > > > > > > > > > > > > > > auth="allow" /> > > > > > > > > attribute="geolocation" auth="allow" > > > > /> > > > > > > > > auth="block" /> > > > > > > > > > > > > > Since this document will be carried in a NOTIFY which has an > > > > "Event:" header of "presence.watcherinfo," > > > > > > Well, thats the question. My interpretation of this > > document above is that > > > its the thing thats carried in the AUTH (or whatever we > > defined) method > > that > > > sets authorization policy. You are correct that the > > document carried in a > > > NOTIFY of presence.watcherinfo has no need to define the > > event. But, the > > > document carried in the AUTH does need to define 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 > > > > > > ______________________________________________________________ > > ________________ > > ifrance.com, l'email gratuit le plus complet de l'Internet ! > > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... > > http://www.ifrance.com/_reloc/email.emailif > > > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From adam.roach@ericsson.com Thu Jun 14 15:49:16 2001 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 PAA11567 for ; Thu, 14 Jun 2001 15:49:15 -0400 (EDT) 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 f5EJnEa23584; Thu, 14 Jun 2001 14:49:14 -0500 (CDT) 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 f5EJnDH29223; Thu, 14 Jun 2001 14:49:13 -0500 (CDT) Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id OAA25203; Thu, 14 Jun 2001 14:49:13 -0500 (CDT) Reply-To: To: "'Robert Sparks'" , "Jonathan Rosenberg" , "'Theodore Havinis'" , Subject: RE: [Simple] authorization for presence Date: Thu, 14 Jun 2001 14:49:12 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251857@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: <9BF66EBF6BEFD942915B4D4D45C051F314A8AE@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Length: 1468 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: > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > We touched on a danger point with following this generalization > to far at the last meeting. ...[W]e have to worry about managing > authorization for the presence.watcherinfo presentity using the > same mechanism we're discussing, leading to a telescoping problem. > We'ld have servers having to handle subscriptions for > presence.watcherinfo.watcherinfo. One of us is confused. If a client *wants* to subscribe to presence.watcherinfo.watcherinfo, and it contacts a server which is able and willing to provide this type of meta-meta-state, I don't see what's wrong with that. I don't beleive that anyone has ever suggested that a server supporting a particular subpackage for one package MUST support it for all possible packages it knows about. It could very well be (and I expect it will usually be the case) that a server implementing presence.watcherinfo would return a 489 in response to a SUBSCRIBE request for presence.watcherinfo.watcherinfo. We don't require them to, but they might. That same server could also very well also support "Event: mailnotification," but reject "mailnotification.watcherinfo." And that's whats just so nifty-keen about subpackages: the semantics can be well enough defined that they can apply to any package (including themselves and other subpackages), but we're not *forcing* anyone to implement more than they need or want to. /a From rsparks@dynamicsoft.com Thu Jun 14 16:59:59 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11771 for ; Thu, 14 Jun 2001 16:59:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA05914; Thu, 14 Jun 2001 17:03:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 16:59:43 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A8B2@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Neil Deason'" , adam.roach@ericsson.com, "'Francois-Frederic Ozog'" , Jonathan Rosenberg , "'Robert Brown'" , Theodore Havinis Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Thu, 14 Jun 2001 16:59:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 848 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: > There are also important open issues in this area: > > 9.1 Must a MESSAGE actually include a message? > 9.5 What would a body in a 200 OK to a MESSAGE mean? We addressed 9.5 in Minnesota. A MESSAGE response may not contain a body - it would break cpim. Issue 9.1 from the document was asking a different question from what you might have meant. Basically, it boiled down to "Is it ok to have a MESSAGE request with and empty body?". We can derive the answer to that from the consensus we already acheived that while an implementation MUST be able to receive message/cpim, it MAY send text/plain. Thus it MAY send an empty text/plain document. I suspect you rather wanting to ask "Can a MESSAGE have a payload that isn't a message?". Outside of the message, and message meta-data like we have with message/cpim, I hope the answer is no. RjS From rsparks@dynamicsoft.com Thu Jun 14 17:43:05 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11915 for ; Thu, 14 Jun 2001 17:43:05 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA06396; Thu, 14 Jun 2001 17:47:04 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 17:43:04 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A8B3@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'adam.roach@ericsson.com'" , Robert Sparks , Jonathan Rosenberg , "'Theodore Havinis'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Thu, 14 Jun 2001 17:42:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3113 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: > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > We touched on a danger point with following this generalization > > to far at the last meeting. ...[W]e have to worry about managing > > authorization for the presence.watcherinfo presentity using the > > same mechanism we're discussing, leading to a telescoping problem. > > We'ld have servers having to handle subscriptions for > > presence.watcherinfo.watcherinfo. > > One of us is confused. Has that ever not been true? I agree fully with what you have below. My point was to remind us _why_ we went with a subpackage instead of creating a separate full-blown identity you could subscribe to in order to get this information. A system MAY choose to manage authorizations to subscriptions for the presence.watcherinfo event using the watcherinfo mechanism. It MAY do this to an arbitrary number of levels. What I want to avoid is propogation of the following bad logic: 1) This presence server provides authorization for subscriptions to _any_ presentity using our mechanism involving a subscription to watcherinfo. 2) presence.watcherinfo is a presentity Therefore, this presence server provides authorization for subscriptions to presence.watcherinfo via subscriptions to presence.watcherinfo.watcherinfo. Further, through induction, this presence server provides authorization for presence.watcherinfo.watcherinfo.watcherinfo...... to an arbitrary number of watcherinfos. This is broken because: Statement 1) misdirects. It should say "This presence server provides authorization for subscriptions to Event: presence of any resource using our mechanism...." Statement 2) is an over-generalization (if not a mis-generalization). So, lets be careful about saying things like 2). RjS > > If a client *wants* to subscribe to presence.watcherinfo.watcherinfo, > and it contacts a server which is able and willing to provide > this type of meta-meta-state, I don't see what's wrong with that. > > I don't beleive that anyone has ever suggested that a server > supporting > a particular subpackage for one package MUST support it for > all possible > packages it knows about. It could very well be (and I expect it will > usually be the case) that a server implementing presence.watcherinfo > would return a 489 in response to a SUBSCRIBE request for > presence.watcherinfo.watcherinfo. We don't require them to, but they > might. That same server could also very well also support > "Event: mailnotification," but reject "mailnotification.watcherinfo." > > And that's whats just so nifty-keen about subpackages: the semantics > can be well enough defined that they can apply to any package > (including themselves and other subpackages), but we're not > *forcing* anyone to implement more than they need or want to. > > /a > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From ndeason@ubiquity.net Fri Jun 15 03:55:14 2001 Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id DAA13526 for ; Fri, 15 Jun 2001 03:55:13 -0400 (EDT) Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca via smtpd (for [216.173.40.35]) with SMTP; 15 Jun 2001 08:55:01 UT Received: (private information removed) Message-ID: From: Neil Deason To: Robert Sparks , adam.roach@ericsson.com, "'Francois-Frederic Ozog'" , Jonathan Rosenberg , "'Robert Brown'" , Theodore Havinis Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Fri, 15 Jun 2001 03:52:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1131 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: > > > There are also important open issues in this area: > > > > 9.1 Must a MESSAGE actually include a message? > > 9.5 What would a body in a 200 OK to a MESSAGE mean? > > We addressed 9.5 in Minnesota. A MESSAGE response may > not contain a body - it would break cpim. Sorry I had to miss SIMPLE WG that time. > Issue 9.1 from the document was asking a different > question from what you might have meant. Basically, > it boiled down to "Is it ok to have a MESSAGE request > with and empty body?". We can derive the answer to that > from the consensus we already acheived that while an > implementation MUST be able to receive message/cpim, > it MAY send text/plain. Thus it MAY send an empty > text/plain document. I suspect you rather wanting to > ask "Can a MESSAGE have a payload that isn't a message?". > Outside of the message, and message meta-data like > we have with message/cpim, I hope the answer is no. That is actually another question and the answer to it that I hoped to hear. If text covering these 3 points can make it into the draft I think the semantics of MESSAGE will be a lot clearer. Cheers, Neil From jdrosen@dynamicsoft.com Sat Jun 16 01:34:36 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03105 for ; Sat, 16 Jun 2001 01:34:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09209; Sat, 16 Jun 2001 01:38:20 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Jun 2001 01:34:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , adam.roach@ericsson.com, "'Francois-Frederic Ozog'" , Jonathan Rosenberg , "'Robert Brown'" , Theodore Havinis Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Sat, 16 Jun 2001 01:34:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3270 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: > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Thursday, June 14, 2001 1:26 PM > To: adam.roach@ericsson.com; 'Francois-Frederic Ozog'; Jonathan > Rosenberg; 'Robert Brown'; Theodore Havinis > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] authorization for presence > > > > MESSAGE has render semantics associated with it. It means, "the > > body of this request contains data that is to be rendered in > > a reasonable manner for the human to whom I have addressed it." > > If that is the defined sematics of MESSAGE I fully agree. > However, the word 'render' is never actually mentioned in > draft-ietf-simple-im-00.txt. We need to rectify that. Coming up with a good definition for the semantics of this is important. I actually like the text Adam has proposed; we should start with that as a basis. > Taking your definition, is it limited to > messaging to humans? IMPP went through a similar debate, around presence as well (what about presence of toasters? stock prices? etc.) The conclusion there was to focus on the problem for humans, since it is more well defined, and allows you to make assumptions that are needed to create a decent protocol. Thats not to say that an IM need only be sent to a human. I can imagine having a system that receives IMs and stores them, allowing me to review them from a web page. THis is quite reasonable. THe key, I think, is that the content in a MESSAGE has no machine-interpretable syntax or semantics. > Does it mean the message data must be > rendered? The intention is that the recipient wishes it to be rendered. Whether it is or not, depends on the implementation at the recipient. > Is it just for IM style messaging or more general > messaging? IM style. There are many differences between IM style messaging and a general purpose messaging protocol (ala tibco). One is that human IM messaging tends to be session oriented... > I have an assumption based on the traditional IM > clients that have motivated MESSAGE, but the guidelines on > SIP extensions say that SIP SHOULD define general purpose > components rather than narrow ones, even at the cost of some > complexity. Before anyone jumps on me I am only asking questions > not suggesting answers. There is a difference between well-defined, but generally useful mechanisms, and ill-defined, and as a result, generally useless mechanisms. Caller prefs is an example of a well-defined, generally useful mechanism. We continue to find new uses for it, since it has utility across many applications. But, the semantics are very well defined, to the point where the proxy algorithms are even specified with code. An example of an ill-defined mechanism that is generally useless, would be to define a method called DOIT, and then say that the headers and body tell you what to do. This is guaranteed not to interoperate. -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 From jdrosen@dynamicsoft.com Sat Jun 16 01:37:24 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03129 for ; Sat, 16 Jun 2001 01:37:23 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09222; Sat, 16 Jun 2001 01:41:23 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Jun 2001 01:37:20 -0400 Message-ID: From: Jonathan Rosenberg To: "'Francois-Frederic Ozog'" , adam.roach@ericsson.com, Jonathan Rosenberg , "'Robert Brown'" , Theodore Havinis Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] authorization for presence Date: Sat, 16 Jun 2001 01:37:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1746 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: > -----Original Message----- > From: Francois-Frederic Ozog [mailto:ffo@ifrance.com] > Sent: Thursday, June 14, 2001 1:46 PM > To: adam.roach@ericsson.com; Jonathan Rosenberg; 'Robert Brown'; > Theodore Havinis > Cc: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] authorization for presence > > Now, if we do not need such method, AUTH seems pretty > adequate, providing > that the content can be flexible. For instance, we define > authorization > document version 1, after a few years we refine it with > version 2. Or two > ways of specifying authorization may cohexist: CPL, CGI... Yes, the idea is that the specific authorization document can be of a variety of types. We will define a basic one first, and in the future, they can get more complex. However, I have argued that in general, if you want really complex, you don't want to do it through the watcherinfo mechanism. Rather, the user would pre-specify policies, which could be done in any real programming language, and you will get the generality you will often want. > And I still do > not like HTTP method as it looses the SIP proxying mechanism: > PUA must then > resolve a PS SIP address down to a non-proxied URL. I think we can declare consensus on not going with HTTP alone (it need not be ruled out, but I think enough people think a SIP mechanism is needed that it has to be done). -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Sat Jun 16 13:47:25 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05012 for ; Sat, 16 Jun 2001 13:47:25 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA10350; Sat, 16 Jun 2001 13:51:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Jun 2001 13:47:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , adam.roach@ericsson.com, "'Robert Brown'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Sat, 16 Jun 2001 13:47:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 4037 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: > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Wednesday, June 13, 2001 5:19 AM > To: adam.roach@ericsson.com; 'Robert Brown'; Jonathan Rosenberg; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of > > adam.roach@ericsson.com > > Sent: 12 June 2001 17:44 > > To: 'Robert Brown'; Jonathan Rosenberg; > simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Thoughts on uploading authorization documents > So how about this for a converged application > providing a new service. Say I am finishing work in the > UK but want to know the value of my shares portfolio > when the US markets close. However, I am going to the pub > after work and due to fear of immediate notification of my > losses sending me on a major drinking binge I prefer the > results to be emailed to my work account. Besides, then I > can work out what impact it has on my planned retirement > date on the companies time in the morning which seems only > fair. > > I can have this service today through an application > that has wisely decided to support SIP for its flexibility > and extensibility. As I leave I send a MESSAGE to my broker's > stock watcher service carrying a SOAP payload. This is the part that baffles me. Stock price notification is a classic SOAP application, and something that people are using SOAP over HTTP for. You can build exactly this app, as you describe it, with regular, normal, well-defined, w3c supported SOAP over HTTP. Why does it ALL have to be SIP? Would you propose that the email that gets sent to be over SIP too?? In fact, SOAP, as I understand it, is most commonly used between back end systems, and so is not likely to be seen by client devices in many cases.. > > Using SOAP for encoding this message in XML works _today_. > Using MESSAGE for transporting a XML message doesn't seem > that unreasonable to me. What is the value proposition over regular SOAP over HTTP? You now need to go out to all these B2B e-commerce guys and convince them to send you SOAP messages in SIP instead of HTTP. Why? There is no user discovery, there is no session (as there is for both presence and IM). SIP provides little value in this scenario. > After all if MESSAGE should only be > used as seen to date, to carry plain/text for simple IM > clients, we should redefine the semantics of INVITE to be > a method for only setting up telephony calls. MESSAGE can carry all different types of content, but the semantics of what MESSAGE means remains unchanged - this content is for rendering to a person. > > Finally using SIP in general means I can use the end to > end authentication and encryption (well one day) mechanisms > for security. It means that providers can offer the service > reusing their SIP infrastructure so making a cost saving. But the SOAP messages are not routed to a "person" (for which existing SIP infrastructure is built to support), they are sent to an ecommerce stock site, in your example. Such a thing doesn't move around, doesn't have multiple points of attachment, etc., all of the things that a SIP network is built to support. > It means that hand held devices can use the same protocol > from IM + Presence as well as this additional type of > service. So is the consensus that this is reasonable use > or abuse? Using the "same protocol" needs to be considered carefully. It makes sense only when there is a strong tie between the needed function and the existing protocols. -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 From jdrosen@dynamicsoft.com Sat Jun 16 13:50:41 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05042 for ; Sat, 16 Jun 2001 13:50:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA10358; Sat, 16 Jun 2001 13:54:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sat, 16 Jun 2001 13:50:40 -0400 Message-ID: From: =?utf-8?B?Sm9uYXRoYW4gUm9zZW5iZXJn?= To: =?utf-8?B?J0RhdmlkIFNpbW9ucyc=?= , =?utf-8?B?Um9iZXJ0IEJyb3du?= , simple@mailman.dynamicsoft.com Date: Sat, 16 Jun 2001 13:50:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="utf-8" Content-Length: 1166 Subject: [Simple] =?utf-8?B?UkU6IFtTaW1wbGVdIFRob3VnaHRzIG9uIHVwbG9hZGluZyBhdXRo?= =?utf-8?B?b3JpemF0aW9uIGRvY3VtZW50cw==?= 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: -----Original Message----- From: David Simons [mailto:dsimons@windows.microsoft.com] Sent: Wednesday, June 13, 2001 8:56 PM To: Jonathan Rosenberg; Robert Brown; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents >So if we can agree that application specific extensions and data exchange are a >reality of the SIP/SIMPLE then why don't we just combine them? Both SERVICE >and SETDATA have been proposed. It seems to me that they are really the same >thing. Each is sending content from one SIP entity to another with the >expectation that that content will be used in the SIP solution space. AUTH has also been proposed. I believe it covers the case of CPL and authorization data upload, but is more well defined that SETDATA or SERVICE. -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 From andreas.a.mayerhofer@siemens.at Mon Jun 18 05:15:25 2001 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 FAA00390 for ; Mon, 18 Jun 2001 05:15:24 -0400 (EDT) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id f5I9FJv04743; Mon, 18 Jun 2001 11:15:19 +0200 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id LAA20579; Mon, 18 Jun 2001 11:15:09 +0200 (MET DST) Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta) id xma006335; Mon, 18 Jun 01 11:07:13 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 11:07:11 +0200 Message-ID: From: Mayerhofer Andreas A To: "'Jonathan Rosenberg'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: AW: [Simple] Contact header Usage in subsequent MESSAGE Requests Date: Mon, 18 Jun 2001 11:07:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1694 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA00390 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: Hello, in this email there is a link for some slides, which explains the idea. But this link doesn´t work. Where can i find these slides? Mayerhofer Andreas > -----Ursprüngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Gesendet am: Donnerstag, 14. Juni 2001 16:43 > An: 'Sriram Parameswar'; 'Hisham Khartabil'; > simple@mailman.dynamicsoft.com > Betreff: RE: [Simple] Contact header Usage in subsequent MESSAGE > Requests > > > > > -----Original Message----- > From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] > Sent: Thursday, June 14, 2001 10:38 AM > To: 'Jonathan Rosenberg'; 'Hisham Khartabil'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Contact header Usage in subsequent > MESSAGE Requests > > > >Jonathan - you refer to a new approach using INVITE rather > than MESSAGE. > Could > >you please point me to the latest version the document that > reflects this? > > There is none yet. It has been discussed and (I think) agreed > upon only > recently on the list. The email which explains the idea can > be found at: > http://mailman.dynamicsoft.com/pipermail/simple/2001-March/000119.html -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 roberbr@microsoft.com Mon Jun 18 12:42:25 2001 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA01828 for ; Mon, 18 Jun 2001 12:42:22 -0400 (EDT) Received: from 157.54.9.108 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Jun 2001 09:36:37 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 18 Jun 2001 09:36:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Mon, 18 Jun 2001 09:36:31 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C32CE@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Thoughts on uploading authorization documents Thread-Index: AcD2jOMpwMB8LMNfRyGLH4djUKTJdABhut+A From: "Robert Brown" To: "Jonathan Rosenberg" , "David Simons" , X-OriginalArrivalTime: 18 Jun 2001 16:36:31.0887 (UTC) FILETIME=[D4C1A9F0:01C0F814] Content-Length: 871 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA01828 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: > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, June 16, 2001 10:51 AM > To: David Simons; Robert Brown; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > ... > AUTH has also been proposed. I believe it covers the case of CPL and > authorization data upload, but is more well defined that SETDATA or > SERVICE. But AUTH _isn't_ better defined than SERVICE or SETDATA. As far as I can tell the semantics of AUTH are: 1. You send an AUTH request to a URI to deliver a document to it. 2. The type and contents of the document are arbitrary, but are intended for "authorization". 3. "Authorization" is not defined but does include uploading CPL and approving watchers of a person's own presence. Am I missing something? Or is AUTH more intent than spec? From marcel.vencour@siemens.at Tue Jun 19 08:44:09 2001 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 IAA04918 for ; Tue, 19 Jun 2001 08:44:07 -0400 (EDT) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id f5JCi6v08568 for ; Tue, 19 Jun 2001 14:44:06 +0200 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id OAA25113 for ; Tue, 19 Jun 2001 14:44:06 +0200 (MET DST) Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta) id xma020545; Tue, 19 Jun 01 14:41:25 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 14:41:23 +0200 Message-ID: From: Vencour Marcel To: "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Date: Tue, 19 Jun 2001 14:41:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1207 Subject: [Simple] Mobility of Buddy List 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: Hello everybody, I have a problem concerning the buddy list used in a presence service: The question is, where is the buddy list of the watcher stored when the watcher goes offline? If it is stored in a file/database at the location of the watcher, then it is bound to the watcher's client, i.e. it does not move around with the watcher (here watcher means the person, not the client used by that person) when he uses different machines to do his watching. Thus the buddy list would have to be stored at the presence server/presence agent (PS). But in this case how can the watcher go offline without deleting his buddy list at the PS? If he goes offline without sending any unsubscribe then the PS would continue to send notifications to the watcher which of course is unnecessary overhead. On the other hand, if the watcher goes offline and sends unsubscribes for all his buddies then the buddy list would be removed from the PS. The next question then is, what happens when the watcher goes online again? How can he send a subscribe without giving a buddy in the request line (just to tell that he is online and thus wants to receive notifications again)? Thanks in advance for an answer, M. Vencour. From sean.olson@ericsson.com Tue Jun 19 09:47:09 2001 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 JAA05102 for ; Tue, 19 Jun 2001 09:46:56 -0400 (EDT) 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 f5JDksa02618 for ; Tue, 19 Jun 2001 08:46:54 -0500 (CDT) 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 f5JDks304541 for ; Tue, 19 Jun 2001 08:46:54 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Tue Jun 19 08:46:53 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 08:46:53 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Tue, 19 Jun 2001 08:46:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8C6.4C0430D0" Content-Length: 6614 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: 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_01C0F8C6.4C0430D0 Content-Type: text/plain; charset="iso-8859-1" I was thinking a little about this. What about the possibility of subscribing to your buddy list? The buddy list could be stored offline in, for example, a database. A SUBSCRIBE request with Event: presence.targets (?) would retrieve the static buddy list in a NOTIFY as well as subsequent updates in future NOTIFYs. The buddy list could also be tailored for the client/terminal. Comments? /sean -- Sean Olson Ericsson Inc. >-----Original Message----- >From: Vencour Marcel [mailto:marcel.vencour@siemens.at] >Sent: Tuesday, June 19, 2001 7:41 AM >To: 'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: [Simple] Mobility of Buddy List > > >Hello everybody, > >I have a problem concerning the buddy list used in a presence >service: The >question is, where is the buddy list of the watcher stored >when the watcher >goes offline? If it is stored in a file/database at the location of the >watcher, then it is bound to the watcher's client, i.e. it >does not move >around with the watcher (here watcher means the person, not >the client used >by that person) when he uses different machines to do his >watching. Thus the >buddy list would have to be stored at the presence >server/presence agent >(PS). But in this case how can the watcher go offline without >deleting his >buddy list at the PS? If he goes offline without sending any >unsubscribe >then the PS would continue to send notifications to the >watcher which of >course is unnecessary overhead. On the other hand, if the watcher goes >offline and sends unsubscribes for all his buddies then the >buddy list would >be removed from the PS. >The next question then is, what happens when the watcher goes >online again? >How can he send a subscribe without giving a buddy in the >request line (just >to tell that he is online and thus wants to receive >notifications again)? > >Thanks in advance for an answer, M. Vencour. > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C0F8C6.4C0430D0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Mobility of Buddy List

I was thinking a little about this. What
about the possibility of subscribing to
your buddy list? The buddy list could be
stored offline in, for example, a database.
A SUBSCRIBE request with Event: presence.targets (?)
would retrieve the static buddy list in a NOTIFY as
well as subsequent updates in future NOTIFYs.
The buddy list could also be tailored for the
client/terminal.

Comments?
/sean

--
Sean Olson <sean.olson@ericsson.com>
Ericsson Inc.

>-----Original Message-----
>From: Vencour Marcel [mailto:marcel.vencour@siemens.at]
>Sent: Tuesday, June 19, 2001 7:41 AM
>To: 'simple@mailman.dynamicsoft.com'
>Cc: Mayerhofer Andreas A
>Subject: [Simple] Mobility of Buddy List
>
>
>Hello everybody,
>
>I have a problem concerning the buddy list used in a presence
>service: The
>question is, where is the buddy list of the watcher stored
>when the watcher
>goes offline? If it is stored in a file/database at the location of the
>watcher, then it is bound to the watcher's client, i.e. it
>does not move
>around with the watcher (here watcher means the person, not
>the client used
>by that person) when he uses different machines to do his
>watching. Thus the
>buddy list would have to be stored at the presence
>server/presence agent
>(PS). But in this case how can the watcher go offline without
>deleting his
>buddy list at the PS? If he goes offline without sending any
>unsubscribe
>then the PS would continue to send notifications to the
>watcher which of
>course is unnecessary overhead. On the other hand, if the watcher goes
>offline and sends unsubscribes for all his buddies then the
>buddy list would
>be removed from the PS.
>The next question then is, what happens when the watcher goes
>online again?
>How can he send a subscribe without giving a buddy in the
>request line (just
>to tell that he is online and thus wants to receive
>notifications again)?
>
>Thanks in advance for an answer, M. Vencour.
>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

------_=_NextPart_001_01C0F8C6.4C0430D0-- From Brian.Rosen@marconi.com Tue Jun 19 11:22:41 2001 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 LAA05441 for ; Tue, 19 Jun 2001 11:22:41 -0400 (EDT) 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 LAA07313; Tue, 19 Jun 2001 11:22:25 -0400 (EDT) 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 LAA13426; Tue, 19 Jun 2001 11:22:27 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 11:22:25 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465587@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sean Olson (EUS)'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Tue, 19 Jun 2001 11:22:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8D3.A4ABBC00" Content-Length: 10610 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: 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_01C0F8D3.A4ABBC00 Content-Type: text/plain; charset="iso-8859-1" You might get the LIST this way, but getting the updates may be problematic because all of your buddies may not be served by the same presence server. You could imagine a server proxy that would do this; the list had a full subscription info, the proxy got the individual Notifies and created one composite Notify. A mobile client might like this a lot, but it's less interesting for "well connected" clients because little aggregation occurs unless there are "popular" buddies where the proxy can use one Notify as input for many lists. Still, it's a worthy idea, and sounds pretty cheap. Seems to me the only protocol impact is that you need a composite Notify that gets you all the presence information in the list as one message. Brian -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Tuesday, June 19, 2001 9:47 AM To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List I was thinking a little about this. What about the possibility of subscribing to your buddy list? The buddy list could be stored offline in, for example, a database. A SUBSCRIBE request with Event: presence.targets (?) would retrieve the static buddy list in a NOTIFY as well as subsequent updates in future NOTIFYs. The buddy list could also be tailored for the client/terminal. Comments? /sean -- Sean Olson Ericsson Inc. >-----Original Message----- >From: Vencour Marcel [ mailto:marcel.vencour@siemens.at ] >Sent: Tuesday, June 19, 2001 7:41 AM >To: 'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: [Simple] Mobility of Buddy List > > >Hello everybody, > >I have a problem concerning the buddy list used in a presence >service: The >question is, where is the buddy list of the watcher stored >when the watcher >goes offline? If it is stored in a file/database at the location of the >watcher, then it is bound to the watcher's client, i.e. it >does not move >around with the watcher (here watcher means the person, not >the client used >by that person) when he uses different machines to do his >watching. Thus the >buddy list would have to be stored at the presence >server/presence agent >(PS). But in this case how can the watcher go offline without >deleting his >buddy list at the PS? If he goes offline without sending any >unsubscribe >then the PS would continue to send notifications to the >watcher which of >course is unnecessary overhead. On the other hand, if the watcher goes >offline and sends unsubscribes for all his buddies then the >buddy list would >be removed from the PS. >The next question then is, what happens when the watcher goes >online again? >How can he send a subscribe without giving a buddy in the >request line (just >to tell that he is online and thus wants to receive >notifications again)? > >Thanks in advance for an answer, M. Vencour. > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C0F8D3.A4ABBC00 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Mobility of Buddy List
You might get the LIST this way, but getting the updates may be
problematic because all of your buddies may not be served by the same
presence server.
 
You could imagine a server proxy that would do this; the list had a full
subscription info, the proxy got the individual Notifies and created one
composite Notify.  A mobile client might like this a lot, but it's less
interesting for "well connected" clients because little aggregation occurs
unless there are "popular" buddies where the proxy can use one Notify
as input for many lists.
 
Still, it's a worthy idea, and sounds pretty cheap.  Seems to me the
only protocol impact is that you need a composite Notify that gets
you all the presence information in the list as one message.
 
Brian
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Tuesday, June 19, 2001 9:47 AM
To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List

I was thinking a little about this. What
about the possibility of subscribing to
your buddy list? The buddy list could be
stored offline in, for example, a database.
A SUBSCRIBE request with Event: presence.targets (?)
would retrieve the static buddy list in a NOTIFY as
well as subsequent updates in future NOTIFYs.
The buddy list could also be tailored for the
client/terminal.

Comments?
/sean

--
Sean Olson <sean.olson@ericsson.com>
Ericsson Inc.

>-----Original Message-----
>From: Vencour Marcel [mailto:marcel.vencour@siemens.at]
>Sent: Tuesday, June 19, 2001 7:41 AM
>To: 'simple@mailman.dynamicsoft.com'
>Cc: Mayerhofer Andreas A
>Subject: [Simple] Mobility of Buddy List
>
>
>Hello everybody,
>
>I have a problem concerning the buddy list used in a presence
>service: The
>question is, where is the buddy list of the watcher stored
>when the watcher
>goes offline? If it is stored in a file/database at the location of the
>watcher, then it is bound to the watcher's client, i.e. it
>does not move
>around with the watcher (here watcher means the person, not
>the client used
>by that person) when he uses different machines to do his
>watching. Thus the
>buddy list would have to be stored at the presence
>server/presence agent
>(PS). But in this case how can the watcher go offline without
>deleting his
>buddy list at the PS? If he goes offline without sending any
>unsubscribe
>then the PS would continue to send notifications to the
>watcher which of
>course is unnecessary overhead. On the other hand, if the watcher goes
>offline and sends unsubscribes for all his buddies then the
>buddy list would
>be removed from the PS.
>The next question then is, what happens when the watcher goes
>online again?
>How can he send a subscribe without giving a buddy in the
>request line (just
>to tell that he is online and thus wants to receive
>notifications again)?
>
>Thanks in advance for an answer, M. Vencour.
>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

------_=_NextPart_001_01C0F8D3.A4ABBC00-- From jdrosen@dynamicsoft.com Tue Jun 19 12:13:42 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05687 for ; Tue, 19 Jun 2001 12:13:42 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA03480; Tue, 19 Jun 2001 12:17:38 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 12:13:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Tue, 19 Jun 2001 12:13:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 6917 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: Hang on here... I think we are all talking about a few different things. First off, in my mind, the definition of a "buddy list" is the set of presentities that a particular user is subscribed to. Lets just make sure we are clear about that. Where this list is stored, and what happens to my subscriptions when I go offline, are two very different things. First off, where is it stored? One place is in the client. This doesn't mean that its deleted when I log off; it would presumably be stored on disk in some way. When the client app is restarted, it looks at that list and generates subscription refreshes for all of the users in the buddy list. The drawback of storing it on the client is that it ties you to a particular desktop. An alternative idea is to store it on a server in the network (this need NOT be the same as the presence server or proxy server or anything else). So, when I start my client app, it goes to a web server, say, and fetches my buddy list. Then, the client app sends a SUBSCRIBE for all of the entries there. Now, I can sit down at any machine, and log in, and then get my buddy list there. This was the motivation for our buddy list format proposal as part of last summer's SIMPLE proposal: http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt In this model, the buddylist is only stored on the web server, but edited on the client. Now, if you go for the model where it can be edited on the web server as well, you run into this synchronization problem. Now, you need to keep interested entities (like my client app) aware of changes to this list that are made. There, having an event package for the "state" of my buddy list makes sense. I think this is what Sean is talking about. Now, a separate issue is what happens to my subscriptions when I go offline. Well, the nice behavior is to unSUBSCRIBE. If you don't, the presence server will eventually send a NOTIFY which either generates a 481 or 404, or a timeout, in which case the presence server would delete the subscription. Please note that this is totally unrelated to the state of my buddy list. This subscription is at the presence server of the presentity, whilst the buddy list is stored at a server in the domain of the watcher. They are totally unrelated. Brian is talking about a different model still. In this model, the buddy list isn't just stored and edited on the server, the server uses it to generate subscriptions directly. Effectively, the server becomes the watcher. If 10 people in its domain subscribe to some user bob, the server sends only one SUBSCRIBE to bob. The server can then use this to deliver notifications to the clients in its domain. The result is aggregation, in that fewer messages need to be sent out to the presentities (1 instead of 10 in the example). However, there is a serious security issue in this model, in that the presentity has no way to know the end user which is requesting the subscription. This approach, which is what I think Brian is talking about, is discussed in the original sip for presence draft: http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, June 19, 2001 11:22 AM To: 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List You might get the LIST this way, but getting the updates may be problematic because all of your buddies may not be served by the same presence server. You could imagine a server proxy that would do this; the list had a full subscription info, the proxy got the individual Notifies and created one composite Notify. A mobile client might like this a lot, but it's less interesting for "well connected" clients because little aggregation occurs unless there are "popular" buddies where the proxy can use one Notify as input for many lists. Still, it's a worthy idea, and sounds pretty cheap. Seems to me the only protocol impact is that you need a composite Notify that gets you all the presence information in the list as one message. Brian -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Tuesday, June 19, 2001 9:47 AM To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List I was thinking a little about this. What about the possibility of subscribing to your buddy list? The buddy list could be stored offline in, for example, a database. A SUBSCRIBE request with Event: presence.targets (?) would retrieve the static buddy list in a NOTIFY as well as subsequent updates in future NOTIFYs. The buddy list could also be tailored for the client/terminal. Comments? /sean -- Sean Olson Ericsson Inc. >-----Original Message----- >From: Vencour Marcel [mailto:marcel.vencour@siemens.at] >Sent: Tuesday, June 19, 2001 7:41 AM >To: 'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: [Simple] Mobility of Buddy List > > >Hello everybody, > >I have a problem concerning the buddy list used in a presence >service: The >question is, where is the buddy list of the watcher stored >when the watcher >goes offline? If it is stored in a file/database at the location of the >watcher, then it is bound to the watcher's client, i.e. it >does not move >around with the watcher (here watcher means the person, not >the client used >by that person) when he uses different machines to do his >watching. Thus the >buddy list would have to be stored at the presence >server/presence agent >(PS). But in this case how can the watcher go offline without >deleting his >buddy list at the PS? If he goes offline without sending any >unsubscribe >then the PS would continue to send notifications to the >watcher which of >course is unnecessary overhead. On the other hand, if the watcher goes >offline and sends unsubscribes for all his buddies then the >buddy list would >be removed from the PS. >The next question then is, what happens when the watcher goes >online again? >How can he send a subscribe without giving a buddy in the >request line (just >to tell that he is online and thus wants to receive >notifications again)? > >Thanks in advance for an answer, M. Vencour. > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple > From zmolek@avaya.com Tue Jun 19 12:55:52 2001 Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05841 for ; Tue, 19 Jun 2001 12:55:51 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26209 for ; Tue, 19 Jun 2001 12:54:54 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26189 for ; Tue, 19 Jun 2001 12:54:53 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8E0.B0F4B004" Subject: RE: [Simple] Mobility of Buddy List X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 19 Jun 2001 10:55:49 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Mobility of Buddy List Thread-Index: AcD421YtRzG64iEqQnmAcANTe+fsxAAA9hKg From: "Zmolek, Andrew (Andrew)" To: "Jonathan Rosenberg" , "Rosen, Brian" , "Sean Olson (EUS)" , "Vencour Marcel" , Cc: "Mayerhofer Andreas A" Content-Length: 23554 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0F8E0.B0F4B004 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the excellent re-frame of the problem set, Jonathan. Regarding Brian's aggregation model, how difficult would it be to allow for aggregation by having the aggregator list the individual subscribers in an aggregated SUBSCRIBE? On the other hand, this could produce some unintended side problems. How would one reject just one name on the list? How is the aggregator trusted? (Or can we verify that any individual is/is not an aggregator and redistributor?)=20 I suspect that this aggregation/redistribution issue set is going to be recurring in any discussion of presence systems and presence data interchange so perhaps it's not worth tacking in this wg right now. On the other hand, is it really possible to avoid it?=20 --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, June 19, 2001 10:14 AM To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Hang on here... I think we are all talking about a few different things. First off, in my mind, the definition of a "buddy list" is the set of presentities that a particular user is subscribed to. Lets just make sure we are clear about that. Where this list is stored, and what happens to my subscriptions when I go offline, are two very different things. First off, where is it stored? One place is in the client. This doesn't mean that its deleted when I log off; it would presumably be stored on disk in some way. When the client app is restarted, it looks at that list and generates subscription refreshes for all of the users in the buddy list. The drawback of storing it on the client is that it ties you to a particular desktop. An alternative idea is to store it on a server in the network (this need NOT be the same as the presence server or proxy server or anything else). So, when I start my client app, it goes to a web server, say, and fetches my buddy list. Then, the client app sends a SUBSCRIBE for all of the entries there. Now, I can sit down at any machine, and log in, and then get my buddy list there. This was the motivation for our buddy list format proposal as part of last summer's SIMPLE proposal: http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt In this model, the buddylist is only stored on the web server, but edited on the client. Now, if you go for the model where it can be edited on the web server as well, you run into this synchronization problem. Now, you need to keep interested entities (like my client app) aware of changes to this list that are made. There, having an event package for the "state" of my buddy list makes sense. I think this is what Sean is talking about. Now, a separate issue is what happens to my subscriptions when I go offline. Well, the nice behavior is to unSUBSCRIBE. If you don't, the presence server will eventually send a NOTIFY which either generates a 481 or 404, or a timeout, in which case the presence server would delete the subscription. Please note that this is totally unrelated to the state of my buddy list. This subscription is at the presence server of the presentity, whilst the buddy list is stored at a server in the domain of the watcher. They are totally unrelated. Brian is talking about a different model still. In this model, the buddy list isn't just stored and edited on the server, the server uses it to generate subscriptions directly. Effectively, the server becomes the watcher. If 10 people in its domain subscribe to some user bob, the server sends only one SUBSCRIBE to bob. The server can then use this to deliver notifications to the clients in its domain. The result is aggregation, in that fewer messages need to be sent out to the presentities (1 instead of 10 in the example). However, there is a serious security issue in this model, in that the presentity has no way to know the end user which is requesting the subscription. This approach, which is what I think Brian is talking about, is discussed in the original sip for presence draft: http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt 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 =20 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, June 19, 2001 11:22 AM To: 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List You might get the LIST this way, but getting the updates may be problematic because all of your buddies may not be served by the same presence server. You could imagine a server proxy that would do this; the list had a full subscription info, the proxy got the individual Notifies and created one composite Notify. A mobile client might like this a lot, but it's less=20 interesting for "well connected" clients because little aggregation occurs unless there are "popular" buddies where the proxy can use one Notify as input for many lists. Still, it's a worthy idea, and sounds pretty cheap. Seems to me the only protocol impact is that you need a composite Notify that gets you all the presence information in the list as one message. Brian -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Tuesday, June 19, 2001 9:47 AM To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List I was thinking a little about this. What=20 about the possibility of subscribing to=20 your buddy list? The buddy list could be=20 stored offline in, for example, a database.=20 A SUBSCRIBE request with Event: presence.targets (?)=20 would retrieve the static buddy list in a NOTIFY as=20 well as subsequent updates in future NOTIFYs.=20 The buddy list could also be tailored for the=20 client/terminal.=20 Comments?=20 /sean=20 --=20 Sean Olson =20 Ericsson Inc.=20 >-----Original Message-----=20 >From: Vencour Marcel [mailto:marcel.vencour@siemens.at]=20 >Sent: Tuesday, June 19, 2001 7:41 AM=20 >To: 'simple@mailman.dynamicsoft.com'=20 >Cc: Mayerhofer Andreas A=20 >Subject: [Simple] Mobility of Buddy List=20 >=20 >=20 >Hello everybody,=20 >=20 >I have a problem concerning the buddy list used in a presence=20 >service: The=20 >question is, where is the buddy list of the watcher stored=20 >when the watcher=20 >goes offline? If it is stored in a file/database at the location of the >watcher, then it is bound to the watcher's client, i.e. it=20 >does not move=20 >around with the watcher (here watcher means the person, not=20 >the client used=20 >by that person) when he uses different machines to do his=20 >watching. Thus the=20 >buddy list would have to be stored at the presence=20 >server/presence agent=20 >(PS). But in this case how can the watcher go offline without=20 >deleting his=20 >buddy list at the PS? If he goes offline without sending any=20 >unsubscribe=20 >then the PS would continue to send notifications to the=20 >watcher which of=20 >course is unnecessary overhead. On the other hand, if the watcher goes=20 >offline and sends unsubscribes for all his buddies then the=20 >buddy list would=20 >be removed from the PS.=20 >The next question then is, what happens when the watcher goes=20 >online again?=20 >How can he send a subscribe without giving a buddy in the=20 >request line (just=20 >to tell that he is online and thus wants to receive=20 >notifications again)?=20 >=20 >Thanks in advance for an answer, M. Vencour.=20 >=20 >_______________________________________________=20 >simple mailing list=20 >simple@mailman.dynamicsoft.com=20 >http://mailman.dynamicsoft.com/mailman/listinfo/simple=20 >=20 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C0F8E0.B0F4B004 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Mobility of Buddy List

Thanks for the excellent re-frame of the problem set, = Jonathan. Regarding Brian's aggregation model, how difficult would it be = to allow for aggregation by having the aggregator list the individual = subscribers in an aggregated SUBSCRIBE?

On the other hand, this could produce some unintended = side problems. How would one reject just one name on the list? How is = the aggregator trusted? (Or can we verify that any individual is/is not = an aggregator and redistributor?)

I suspect that this aggregation/redistribution issue = set is going to be recurring in any discussion of presence systems and = presence data interchange so perhaps it's not worth tacking in this wg = right now. On the other hand, is it really possible to avoid it? =

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, June 19, 2001 10:14 AM
To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour = Marcel';
'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List


Hang on here... I think we are all talking about a few = different things.

First off, in my mind, the definition of a "buddy = list" is the set of
presentities that a particular user is subscribed to. = Lets just make sure we
are clear about that. Where this list is stored, and = what happens to my
subscriptions when I go offline, are two very = different things.

First off, where is it stored? One place is in the = client. This doesn't mean
that its deleted when I log off; it would presumably = be stored on disk in
some way. When the client app is restarted, it looks = at that list and
generates subscription refreshes for all of the users = in the buddy list.

The drawback of storing it on the client is that it = ties you to a particular
desktop. An alternative idea is to store it on a = server in the network (this
need NOT be the same as the presence server or proxy = server or anything
else). So, when I start my client app, it goes to a = web server, say, and
fetches my buddy list. Then, the client app sends a = SUBSCRIBE for all of the
entries there. Now, I can sit down at any machine, = and log in, and then get
my buddy list there. This was the motivation for our = buddy list format
proposal as part of last summer's SIMPLE = proposal:

http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt

In this model, the buddylist is only stored on the web = server, but edited on
the client. Now, if you go for the model where it can = be edited on the web
server as well, you run into this synchronization = problem. Now, you need to
keep interested entities (like my client app) aware = of changes to this list
that are made. There, having an event package for the = "state" of my buddy
list makes sense. I think this is what Sean is = talking about.

Now, a separate issue is what happens to my = subscriptions when I go offline.
Well, the nice behavior is to unSUBSCRIBE. If you = don't, the presence server
will eventually send a NOTIFY which either generates = a 481 or 404, or a
timeout, in which case the presence server would = delete the subscription.
Please note that this is totally unrelated to the = state of my buddy list.
This subscription is at the presence server of the = presentity, whilst the
buddy list is stored at a server in the domain of the = watcher. They are
totally unrelated.

Brian is talking about a different model still. In = this model, the buddy
list isn't just stored and edited on the server, the = server uses it to
generate subscriptions directly. Effectively, the = server becomes the
watcher. If 10 people in its domain subscribe to some = user bob, the server
sends only one SUBSCRIBE to bob. The server can then = use this to deliver
notifications to the clients in its domain. The = result is aggregation, in
that fewer messages need to be sent out to the = presentities (1 instead of 10
in the example). However, there is a serious security = issue in this model,
in that the presentity has no way to know the end = user which is requesting
the subscription.

This approach, which is what I think Brian is talking = about, is discussed in
the original sip for presence draft:

http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt=

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, = Ph.D.           &n= bsp;    72 Eagle Rock Ave.
Chief = Scientist          &nbs= p;            = ;      First Floor
dynamicsoft         = ;            =             East = Hanover, NJ 07936
jdrosen@dynamicsoft.com       = ;            =   FAX:   (973) 952-5050
http://www.jdrosen.net  &nb= sp;           &nbs= p;       PHONE: (973) 952-5000
http://www.dynamicsoft.com=
 
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, June 19, 2001 11:22 AM
To: 'Sean Olson (EUS)'; 'Vencour Marcel'; = 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List


You might get the LIST this way, but getting the = updates may be
problematic because all of your buddies may not be = served by the same
presence server.

You could imagine a server proxy that would do this; = the list had a full
subscription info, the proxy got the individual = Notifies and created one
composite Notify.  A mobile client might like = this a lot, but it's less
interesting for "well connected" clients = because little aggregation occurs
unless there are "popular" buddies where = the proxy can use one Notify
as input for many lists.

Still, it's a worthy idea, and sounds pretty = cheap.  Seems to me the
only protocol impact is that you need a composite = Notify that gets
you all the presence information in the list as one = message.

Brian
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Tuesday, June 19, 2001 9:47 AM
To: 'Vencour Marcel'; = 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List


I was thinking a little about this. What
about the possibility of subscribing to
your buddy list? The buddy list could be
stored offline in, for example, a database.
A SUBSCRIBE request with Event: presence.targets (?) =
would retrieve the static buddy list in a NOTIFY as =
well as subsequent updates in future NOTIFYs.
The buddy list could also be tailored for the
client/terminal.
Comments?
/sean
--
Sean Olson <sean.olson@ericsson.com>
Ericsson Inc.
>-----Original Message-----
>From: Vencour Marcel [mailto:marcel.vencour@siemens.a= t]
>Sent: Tuesday, June 19, 2001 7:41 AM
>To: 'simple@mailman.dynamicsoft.com'
>Cc: Mayerhofer Andreas A
>Subject: [Simple] Mobility of Buddy List
>
>
>Hello everybody,
>
>I have a problem concerning the buddy list used = in a presence
>service: The
>question is, where is the buddy list of the = watcher stored
>when the watcher
>goes offline? If it is stored in a file/database = at the location of the
>watcher, then it is bound to the watcher's = client, i.e. it
>does not move
>around with the watcher (here watcher means the = person, not
>the client used
>by that person) when he uses different machines = to do his
>watching. Thus the
>buddy list would have to be stored at the = presence
>server/presence agent
>(PS). But in this case how can the watcher go = offline without
>deleting his
>buddy list at the PS? If he goes offline without = sending any
>unsubscribe
>then the PS would continue to send notifications = to the
>watcher which of
>course is unnecessary overhead. On the other = hand, if the watcher goes
>offline and sends unsubscribes for all his = buddies then the
>buddy list would
>be removed from the PS.
>The next question then is, what happens when the = watcher goes
>online again?
>How can he send a subscribe without giving a = buddy in the
>request line (just
>to tell that he is online and thus wants to = receive
>notifications again)?
>
>Thanks in advance for an answer, M. Vencour. =
>
>_______________________________________________ =
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple
>
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple

------_=_NextPart_001_01C0F8E0.B0F4B004-- From Brian.Rosen@marconi.com Tue Jun 19 13:41:02 2001 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 NAA06034 for ; Tue, 19 Jun 2001 13:41:01 -0400 (EDT) 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 NAA18198; Tue, 19 Jun 2001 13:40:46 -0400 (EDT) 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 NAA18742; Tue, 19 Jun 2001 13:40:49 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 13:40:47 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446558A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Tue, 19 Jun 2001 13:40:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 8801 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: Yes, you have what I was talking about reasonably well represented. I'll point out that the server can get more aggregation if it is popular, in that, in theory, it can get one Notify from a presentity that it then sends in aggregated Notifies to multiple subscribers to its lists. And yes, this makes the security problem worse (since to be usefull, the real presentity has to actually only send one Notify). The security problem would have to be dealt with, but it seems to me it's pretty straightforward - the client subscribes as usual with the server proxying the subscription request, possibly including its own credentials. The presentity would know the original subscriber, and the server. The presentity could decline the subscription if it didn't trust the server. You could even encrypt the presence information such that the server didn't know the contents - it's simply a relay for the presence information anyway. Probably too complex for the first version of this stuff, but thinking about proxying subscriptions, and structuring the Notify so that an aggregate presence document can pass would be usefull. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, June 19, 2001 12:14 PM > To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; > 'simple@mailman.dynamicsoft.com' > Cc: Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > > Hang on here... I think we are all talking about a few > different things. > > First off, in my mind, the definition of a "buddy list" is the set of > presentities that a particular user is subscribed to. Lets > just make sure we > are clear about that. Where this list is stored, and what > happens to my > subscriptions when I go offline, are two very different things. > > First off, where is it stored? One place is in the client. > This doesn't mean > that its deleted when I log off; it would presumably be > stored on disk in > some way. When the client app is restarted, it looks at that list and > generates subscription refreshes for all of the users in the > buddy list. > > The drawback of storing it on the client is that it ties you > to a particular > desktop. An alternative idea is to store it on a server in > the network (this > need NOT be the same as the presence server or proxy server > or anything > else). So, when I start my client app, it goes to a web > server, say, and > fetches my buddy list. Then, the client app sends a SUBSCRIBE > for all of the > entries there. Now, I can sit down at any machine, and log > in, and then get > my buddy list there. This was the motivation for our buddy list format > proposal as part of last summer's SIMPLE proposal: > > http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt > > In this model, the buddylist is only stored on the web > server, but edited on > the client. Now, if you go for the model where it can be > edited on the web > server as well, you run into this synchronization problem. > Now, you need to > keep interested entities (like my client app) aware of > changes to this list > that are made. There, having an event package for the "state" > of my buddy > list makes sense. I think this is what Sean is talking about. > > Now, a separate issue is what happens to my subscriptions > when I go offline. > Well, the nice behavior is to unSUBSCRIBE. If you don't, the > presence server > will eventually send a NOTIFY which either generates a 481 or > 404, or a > timeout, in which case the presence server would delete the > subscription. > Please note that this is totally unrelated to the state of my > buddy list. > This subscription is at the presence server of the > presentity, whilst the > buddy list is stored at a server in the domain of the > watcher. They are > totally unrelated. > > Brian is talking about a different model still. In this > model, the buddy > list isn't just stored and edited on the server, the server uses it to > generate subscriptions directly. Effectively, the server becomes the > watcher. If 10 people in its domain subscribe to some user > bob, the server > sends only one SUBSCRIBE to bob. The server can then use this > to deliver > notifications to the clients in its domain. The result is > aggregation, in > that fewer messages need to be sent out to the presentities > (1 instead of 10 > in the example). However, there is a serious security issue > in this model, > in that the presentity has no way to know the end user which > is requesting > the subscription. > > This approach, which is what I think Brian is talking about, > is discussed in > the original sip for presence draft: > > http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt > > 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 19, 2001 11:22 AM > To: 'Sean Olson (EUS)'; 'Vencour Marcel'; > 'simple@mailman.dynamicsoft.com' > Cc: Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > > You might get the LIST this way, but getting the updates may be > problematic because all of your buddies may not be served by the same > presence server. > > You could imagine a server proxy that would do this; the list > had a full > subscription info, the proxy got the individual Notifies and > created one > composite Notify. A mobile client might like this a lot, but > it's less > interesting for "well connected" clients because little > aggregation occurs > unless there are "popular" buddies where the proxy can use one Notify > as input for many lists. > > Still, it's a worthy idea, and sounds pretty cheap. Seems to me the > only protocol impact is that you need a composite Notify that gets > you all the presence information in the list as one message. > > Brian > -----Original Message----- > From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > Sent: Tuesday, June 19, 2001 9:47 AM > To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' > Cc: Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > > I was thinking a little about this. What > about the possibility of subscribing to > your buddy list? The buddy list could be > stored offline in, for example, a database. > A SUBSCRIBE request with Event: presence.targets (?) > would retrieve the static buddy list in a NOTIFY as > well as subsequent updates in future NOTIFYs. > The buddy list could also be tailored for the > client/terminal. > Comments? > /sean > -- > Sean Olson > Ericsson Inc. > >-----Original Message----- > >From: Vencour Marcel [mailto:marcel.vencour@siemens.at] > >Sent: Tuesday, June 19, 2001 7:41 AM > >To: 'simple@mailman.dynamicsoft.com' > >Cc: Mayerhofer Andreas A > >Subject: [Simple] Mobility of Buddy List > > > > > >Hello everybody, > > > >I have a problem concerning the buddy list used in a presence > >service: The > >question is, where is the buddy list of the watcher stored > >when the watcher > >goes offline? If it is stored in a file/database at the > location of the > >watcher, then it is bound to the watcher's client, i.e. it > >does not move > >around with the watcher (here watcher means the person, not > >the client used > >by that person) when he uses different machines to do his > >watching. Thus the > >buddy list would have to be stored at the presence > >server/presence agent > >(PS). But in this case how can the watcher go offline without > >deleting his > >buddy list at the PS? If he goes offline without sending any > >unsubscribe > >then the PS would continue to send notifications to the > >watcher which of > >course is unnecessary overhead. On the other hand, if the > watcher goes > >offline and sends unsubscribes for all his buddies then the > >buddy list would > >be removed from the PS. > >The next question then is, what happens when the watcher goes > >online again? > >How can he send a subscribe without giving a buddy in the > >request line (just > >to tell that he is online and thus wants to receive > >notifications again)? > > > >Thanks in advance for an answer, M. Vencour. > > > >_______________________________________________ > >simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > From sean.olson@ericsson.com Tue Jun 19 15:15:40 2001 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 PAA06324 for ; Tue, 19 Jun 2001 15:15:40 -0400 (EDT) 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 f5JJFWR24809 for ; Tue, 19 Jun 2001 14:15:32 -0500 (CDT) 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 f5JJFTj14947 for ; Tue, 19 Jun 2001 14:15:29 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Jun 19 14:15:24 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 14:15:24 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Rosen, Brian'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Tue, 19 Jun 2001 14:15:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8F4.2FBAE4E0" Content-Length: 3262 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: 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_01C0F8F4.2FBAE4E0 Content-Type: text/plain; charset="iso-8859-1" My intention was to provide a mechanism to subscribe to changes in the status of the buddy list itself and not necessarily the presence status of the members of that buddy list. This would support both retrieving of the initial buddy list (the first NOTIFY) as well as any updates that were made, perhaps by non-SIP mechanisms such as a web interface. This is not intended to solve the aggregation problem at all. That is a whole different beast that requires much more thinking. /sean ------_=_NextPart_001_01C0F8F4.2FBAE4E0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Mobility of Buddy List
My intention was to provide a mechanism to
subscribe to changes in the status of the
buddy list itself and not necessarily the
presence status of the members of that
buddy list. This would support both
retrieving of the initial buddy list (the first
NOTIFY) as well as any updates that were
made, perhaps by non-SIP mechanisms such
as a web interface. This is not intended to
solve the aggregation problem at all. That
is a whole different beast that requires much
more thinking.
 
/sean
------_=_NextPart_001_01C0F8F4.2FBAE4E0-- From ROBERTO@windows.microsoft.com Tue Jun 19 17:38:50 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA06728 for ; Tue, 19 Jun 2001 17:38:50 -0400 (EDT) Received: from 157.54.9.104 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Jun 2001 10:50:25 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 19 Jun 2001 10:50:24 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 19 Jun 2001 10:50:24 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Jun 2001 10:48:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Mobility of Buddy List Date: Tue, 19 Jun 2001 10:48:55 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1460E99@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Mobility of Buddy List Thread-Index: AcD43hoCNa84SUkZTVqldzFTfHxo1gABwmAA From: "Robert Osborne" To: "Jonathan Rosenberg" , "Rosen, Brian" , "Sean Olson (EUS)" , "Vencour Marcel" , Cc: "Mayerhofer Andreas A" X-OriginalArrivalTime: 19 Jun 2001 17:48:55.0710 (UTC) FILETIME=[1C4A33E0:01C0F8E8] Content-Length: 8499 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA06728 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: Hi, in your discussion of where the buddy list should be stored, you state that it should be stored on a server, which makes sense. However you state that it need NOT be stored on the presence of proxy server. My question is, why would the buddy list not be stored on the presence server, but be stored somewhere else? If it was, the client needs to have some additionl intelligence: * Which server should I connect to in order to retrieve my buddy list * All devices would need to understand HTTP or whatever other protocol is required * Will I be able to connect to that server, because of firewalls etc It seems to me that this is adding in further complexity to do something which should be relatively simple. I think something similar to what Sean suggests make sense and ensure that the client only requires some minor capabilites, compared to a completely new protocol support. Rob O >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: Tuesday, June 19, 2001 9:14 AM >To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; >'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: RE: [Simple] Mobility of Buddy List > > >Hang on here... I think we are all talking about a few >different things. > >First off, in my mind, the definition of a "buddy list" is the set of >presentities that a particular user is subscribed to. Lets >just make sure we >are clear about that. Where this list is stored, and what happens to my >subscriptions when I go offline, are two very different things. > >First off, where is it stored? One place is in the client. >This doesn't mean >that its deleted when I log off; it would presumably be stored >on disk in >some way. When the client app is restarted, it looks at that list and >generates subscription refreshes for all of the users in the >buddy list. > >The drawback of storing it on the client is that it ties you >to a particular >desktop. An alternative idea is to store it on a server in the >network (this >need NOT be the same as the presence server or proxy server or anything >else). So, when I start my client app, it goes to a web >server, say, and >fetches my buddy list. Then, the client app sends a SUBSCRIBE >for all of the >entries there. Now, I can sit down at any machine, and log in, >and then get >my buddy list there. This was the motivation for our buddy list format >proposal as part of last summer's SIMPLE proposal: > >http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt > >In this model, the buddylist is only stored on the web server, >but edited on >the client. Now, if you go for the model where it can be >edited on the web >server as well, you run into this synchronization problem. >Now, you need to >keep interested entities (like my client app) aware of changes >to this list >that are made. There, having an event package for the "state" >of my buddy >list makes sense. I think this is what Sean is talking about. > >Now, a separate issue is what happens to my subscriptions when >I go offline. >Well, the nice behavior is to unSUBSCRIBE. If you don't, the >presence server >will eventually send a NOTIFY which either generates a 481 or 404, or a >timeout, in which case the presence server would delete the >subscription. >Please note that this is totally unrelated to the state of my >buddy list. >This subscription is at the presence server of the presentity, >whilst the >buddy list is stored at a server in the domain of the watcher. They are >totally unrelated. > >Brian is talking about a different model still. In this model, >the buddy >list isn't just stored and edited on the server, the server uses it to >generate subscriptions directly. Effectively, the server becomes the >watcher. If 10 people in its domain subscribe to some user >bob, the server >sends only one SUBSCRIBE to bob. The server can then use this >to deliver >notifications to the clients in its domain. The result is >aggregation, in >that fewer messages need to be sent out to the presentities (1 >instead of 10 >in the example). However, there is a serious security issue in >this model, >in that the presentity has no way to know the end user which >is requesting >the subscription. > >This approach, which is what I think Brian is talking about, >is discussed in >the original sip for presence draft: > >http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt > >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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] >Sent: Tuesday, June 19, 2001 11:22 AM >To: 'Sean Olson (EUS)'; 'Vencour Marcel'; >'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: RE: [Simple] Mobility of Buddy List > > >You might get the LIST this way, but getting the updates may be >problematic because all of your buddies may not be served by the same >presence server. > >You could imagine a server proxy that would do this; the list >had a full >subscription info, the proxy got the individual Notifies and >created one >composite Notify. A mobile client might like this a lot, but >it's less >interesting for "well connected" clients because little >aggregation occurs >unless there are "popular" buddies where the proxy can use one Notify >as input for many lists. > >Still, it's a worthy idea, and sounds pretty cheap. Seems to me the >only protocol impact is that you need a composite Notify that gets >you all the presence information in the list as one message. > >Brian >-----Original Message----- >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] >Sent: Tuesday, June 19, 2001 9:47 AM >To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: RE: [Simple] Mobility of Buddy List > > >I was thinking a little about this. What >about the possibility of subscribing to >your buddy list? The buddy list could be >stored offline in, for example, a database. >A SUBSCRIBE request with Event: presence.targets (?) >would retrieve the static buddy list in a NOTIFY as >well as subsequent updates in future NOTIFYs. >The buddy list could also be tailored for the >client/terminal. >Comments? >/sean >-- >Sean Olson >Ericsson Inc. >>-----Original Message----- >>From: Vencour Marcel [mailto:marcel.vencour@siemens.at] >>Sent: Tuesday, June 19, 2001 7:41 AM >>To: 'simple@mailman.dynamicsoft.com' >>Cc: Mayerhofer Andreas A >>Subject: [Simple] Mobility of Buddy List >> >> >>Hello everybody, >> >>I have a problem concerning the buddy list used in a presence >>service: The >>question is, where is the buddy list of the watcher stored >>when the watcher >>goes offline? If it is stored in a file/database at the >location of the >>watcher, then it is bound to the watcher's client, i.e. it >>does not move >>around with the watcher (here watcher means the person, not >>the client used >>by that person) when he uses different machines to do his >>watching. Thus the >>buddy list would have to be stored at the presence >>server/presence agent >>(PS). But in this case how can the watcher go offline without >>deleting his >>buddy list at the PS? If he goes offline without sending any >>unsubscribe >>then the PS would continue to send notifications to the >>watcher which of >>course is unnecessary overhead. On the other hand, if the >watcher goes >>offline and sends unsubscribes for all his buddies then the >>buddy list would >>be removed from the PS. >>The next question then is, what happens when the watcher goes >>online again? >>How can he send a subscribe without giving a buddy in the >>request line (just >>to tell that he is online and thus wants to receive >>notifications again)? >> >>Thanks in advance for an answer, M. Vencour. >> >>_______________________________________________ >>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 Vasilis.Polychronidis@Openwave.com Wed Jun 20 04:07:25 2001 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 EAA08325 for ; Wed, 20 Jun 2001 04:07:25 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010620080605.VZO13968.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Wed, 20 Jun 2001 03:06:05 -0500 Received: from Openwave.com ([4.41.19.90]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010620080708.NJXZ10980.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Wed, 20 Jun 2001 03:07:08 -0500 Message-ID: <3B3059A7.6FB253AC@Openwave.com> Date: Wed, 20 Jun 2001 01:07:04 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Osborne CC: Jonathan Rosenberg , "Rosen, Brian" , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com, Mayerhofer Andreas A Subject: Re: [Simple] Mobility of Buddy List References: <2E33960095B58E40A4D3345AB9F65EC1460E99@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 9788 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: Hi Robert, Please see my comments below: Kind Regards, Vasilis Polychronidis Robert Osborne wrote: > Hi, > > in your discussion of where the buddy list should be stored, you > state that it should be stored on a server, which makes sense. However > you state that it need NOT be stored on the presence of proxy server. > My question is, why would the buddy list not be stored on the presence > server, but be stored somewhere else? Well I think buddy lists are application specific data. In my IM application for example I can have a different contact list (buddy list) than my e-mail contact list. Multiple applications with different requirements will need access to the presence data of presentities. The grouping of presentities into contact lists is dependent on the specific application and i do not think is practical of requiring all application that want to use the presence service to store their contact lists to the presence server. > > > If it was, the client needs to have some additionl intelligence: > > * Which server should I connect to in order to retrieve my buddy list > * All devices would need to understand HTTP or whatever other protocol > is required > * Will I be able to connect to that server, because of firewalls etc > > It seems to me that this is adding in further complexity to do something > which should be relatively simple. I do not think that is so simple. I think Contact Lists, PIMs, synchronization, etc. issues are not easy to solve in a standards based approach. > I think something similar to what > Sean suggests make sense and ensure that the client only requires some > minor capabilites, compared to a completely new protocol support. > > Rob O > > >-----Original Message----- > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >Sent: Tuesday, June 19, 2001 9:14 AM > >To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; > >'simple@mailman.dynamicsoft.com' > >Cc: Mayerhofer Andreas A > >Subject: RE: [Simple] Mobility of Buddy List > > > > > >Hang on here... I think we are all talking about a few > >different things. > > > >First off, in my mind, the definition of a "buddy list" is the set of > >presentities that a particular user is subscribed to. Lets > >just make sure we > >are clear about that. Where this list is stored, and what happens to my > >subscriptions when I go offline, are two very different things. > > > >First off, where is it stored? One place is in the client. > >This doesn't mean > >that its deleted when I log off; it would presumably be stored > >on disk in > >some way. When the client app is restarted, it looks at that list and > >generates subscription refreshes for all of the users in the > >buddy list. > > > >The drawback of storing it on the client is that it ties you > >to a particular > >desktop. An alternative idea is to store it on a server in the > >network (this > >need NOT be the same as the presence server or proxy server or anything > >else). So, when I start my client app, it goes to a web > >server, say, and > >fetches my buddy list. Then, the client app sends a SUBSCRIBE > >for all of the > >entries there. Now, I can sit down at any machine, and log in, > >and then get > >my buddy list there. This was the motivation for our buddy list format > >proposal as part of last summer's SIMPLE proposal: > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt > > > >In this model, the buddylist is only stored on the web server, > >but edited on > >the client. Now, if you go for the model where it can be > >edited on the web > >server as well, you run into this synchronization problem. > >Now, you need to > >keep interested entities (like my client app) aware of changes > >to this list > >that are made. There, having an event package for the "state" > >of my buddy > >list makes sense. I think this is what Sean is talking about. > > > >Now, a separate issue is what happens to my subscriptions when > >I go offline. > >Well, the nice behavior is to unSUBSCRIBE. If you don't, the > >presence server > >will eventually send a NOTIFY which either generates a 481 or 404, or a > >timeout, in which case the presence server would delete the > >subscription. > >Please note that this is totally unrelated to the state of my > >buddy list. > >This subscription is at the presence server of the presentity, > >whilst the > >buddy list is stored at a server in the domain of the watcher. They are > >totally unrelated. > > > >Brian is talking about a different model still. In this model, > >the buddy > >list isn't just stored and edited on the server, the server uses it to > >generate subscriptions directly. Effectively, the server becomes the > >watcher. If 10 people in its domain subscribe to some user > >bob, the server > >sends only one SUBSCRIBE to bob. The server can then use this > >to deliver > >notifications to the clients in its domain. The result is > >aggregation, in > >that fewer messages need to be sent out to the presentities (1 > >instead of 10 > >in the example). However, there is a serious security issue in > >this model, > >in that the presentity has no way to know the end user which > >is requesting > >the subscription. > > > >This approach, which is what I think Brian is talking about, > >is discussed in > >the original sip for presence draft: > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt > > > >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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > >Sent: Tuesday, June 19, 2001 11:22 AM > >To: 'Sean Olson (EUS)'; 'Vencour Marcel'; > >'simple@mailman.dynamicsoft.com' > >Cc: Mayerhofer Andreas A > >Subject: RE: [Simple] Mobility of Buddy List > > > > > >You might get the LIST this way, but getting the updates may be > >problematic because all of your buddies may not be served by the same > >presence server. > > > >You could imagine a server proxy that would do this; the list > >had a full > >subscription info, the proxy got the individual Notifies and > >created one > >composite Notify. A mobile client might like this a lot, but > >it's less > >interesting for "well connected" clients because little > >aggregation occurs > >unless there are "popular" buddies where the proxy can use one Notify > >as input for many lists. > > > >Still, it's a worthy idea, and sounds pretty cheap. Seems to me the > >only protocol impact is that you need a composite Notify that gets > >you all the presence information in the list as one message. > > > >Brian > >-----Original Message----- > >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > >Sent: Tuesday, June 19, 2001 9:47 AM > >To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' > >Cc: Mayerhofer Andreas A > >Subject: RE: [Simple] Mobility of Buddy List > > > > > >I was thinking a little about this. What > >about the possibility of subscribing to > >your buddy list? The buddy list could be > >stored offline in, for example, a database. > >A SUBSCRIBE request with Event: presence.targets (?) > >would retrieve the static buddy list in a NOTIFY as > >well as subsequent updates in future NOTIFYs. > >The buddy list could also be tailored for the > >client/terminal. > >Comments? > >/sean > >-- > >Sean Olson > >Ericsson Inc. > >>-----Original Message----- > >>From: Vencour Marcel [mailto:marcel.vencour@siemens.at] > >>Sent: Tuesday, June 19, 2001 7:41 AM > >>To: 'simple@mailman.dynamicsoft.com' > >>Cc: Mayerhofer Andreas A > >>Subject: [Simple] Mobility of Buddy List > >> > >> > >>Hello everybody, > >> > >>I have a problem concerning the buddy list used in a presence > >>service: The > >>question is, where is the buddy list of the watcher stored > >>when the watcher > >>goes offline? If it is stored in a file/database at the > >location of the > >>watcher, then it is bound to the watcher's client, i.e. it > >>does not move > >>around with the watcher (here watcher means the person, not > >>the client used > >>by that person) when he uses different machines to do his > >>watching. Thus the > >>buddy list would have to be stored at the presence > >>server/presence agent > >>(PS). But in this case how can the watcher go offline without > >>deleting his > >>buddy list at the PS? If he goes offline without sending any > >>unsubscribe > >>then the PS would continue to send notifications to the > >>watcher which of > >>course is unnecessary overhead. On the other hand, if the > >watcher goes > >>offline and sends unsubscribes for all his buddies then the > >>buddy list would > >>be removed from the PS. > >>The next question then is, what happens when the watcher goes > >>online again? > >>How can he send a subscribe without giving a buddy in the > >>request line (just > >>to tell that he is online and thus wants to receive > >>notifications again)? > >> > >>Thanks in advance for an answer, M. Vencour. > >> > >>_______________________________________________ > >>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 Brian.Rosen@marconi.com Wed Jun 20 08:25:01 2001 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 IAA09156 for ; Wed, 20 Jun 2001 08:24:46 -0400 (EDT) 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 IAA04611; Wed, 20 Jun 2001 08:24:32 -0400 (EDT) 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 IAA25645; Wed, 20 Jun 2001 08:24:34 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 08:24:32 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465599@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Vasilis Polychronidis'" , Robert Osborne Cc: Jonathan Rosenberg , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com, Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Wed, 20 Jun 2001 08:24:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 11414 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: I agree. The basic contents of the lists are probably common (presentity), but the structure is not. Consider the standard AOL Instant Messenger list already has a two dimensional structure, and it is easy to imagine more elaborate structures for the lists. As Vasilis points out, contact information and "buddy lists" may be combined, and we aren't going to standardize contacts are we? In our implementation, we plan to have more information in our content entries beyond just the presentity, so a standardized list format would be problematic. It is always possible to leave the list as an XML blob, but then I don't think anyone gets any advantage out of that. Brian > -----Original Message----- > From: Vasilis Polychronidis > [mailto:Vasilis.Polychronidis@Openwave.com] > Sent: Wednesday, June 20, 2001 4:07 AM > To: Robert Osborne > Cc: Jonathan Rosenberg; Rosen, Brian; Sean Olson (EUS); > Vencour Marcel; > simple@mailman.dynamicsoft.com; Mayerhofer Andreas A > Subject: Re: [Simple] Mobility of Buddy List > > > Hi Robert, > Please see my comments below: > > Kind Regards, > > Vasilis Polychronidis > > Robert Osborne wrote: > > > Hi, > > > > in your discussion of where the buddy list should be stored, you > > state that it should be stored on a server, which makes > sense. However > > you state that it need NOT be stored on the presence of > proxy server. > > My question is, why would the buddy list not be stored on > the presence > > server, but be stored somewhere else? > > Well I think buddy lists are application specific data. > In my IM application for example I can have a different > contact list (buddy list) than my e-mail contact list. > Multiple applications with different requirements will need access > to the presence data of presentities. The grouping of > presentities into > contact lists is dependent on the specific application and i > do not think > is practical of requiring all application that want to use > the presence > service > to store their contact lists to the presence server. > > > > > > > If it was, the client needs to have some additionl intelligence: > > > > * Which server should I connect to in order to retrieve my > buddy list > > * All devices would need to understand HTTP or whatever > other protocol > > is required > > * Will I be able to connect to that server, because of firewalls etc > > > > It seems to me that this is adding in further complexity to > do something > > which should be relatively simple. > > I do not think that is so simple. I think Contact Lists, PIMs, > synchronization, etc. > issues are not easy to solve in a standards based approach. > > > I think something similar to what > > Sean suggests make sense and ensure that the client only > requires some > > minor capabilites, compared to a completely new protocol support. > > > > Rob O > > > > >-----Original Message----- > > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > >Sent: Tuesday, June 19, 2001 9:14 AM > > >To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; > > >'simple@mailman.dynamicsoft.com' > > >Cc: Mayerhofer Andreas A > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > >Hang on here... I think we are all talking about a few > > >different things. > > > > > >First off, in my mind, the definition of a "buddy list" is > the set of > > >presentities that a particular user is subscribed to. Lets > > >just make sure we > > >are clear about that. Where this list is stored, and what > happens to my > > >subscriptions when I go offline, are two very different things. > > > > > >First off, where is it stored? One place is in the client. > > >This doesn't mean > > >that its deleted when I log off; it would presumably be stored > > >on disk in > > >some way. When the client app is restarted, it looks at > that list and > > >generates subscription refreshes for all of the users in the > > >buddy list. > > > > > >The drawback of storing it on the client is that it ties you > > >to a particular > > >desktop. An alternative idea is to store it on a server in the > > >network (this > > >need NOT be the same as the presence server or proxy > server or anything > > >else). So, when I start my client app, it goes to a web > > >server, say, and > > >fetches my buddy list. Then, the client app sends a SUBSCRIBE > > >for all of the > > >entries there. Now, I can sit down at any machine, and log in, > > >and then get > > >my buddy list there. This was the motivation for our buddy > list format > > >proposal as part of last summer's SIMPLE proposal: > > > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt > > > > > >In this model, the buddylist is only stored on the web server, > > >but edited on > > >the client. Now, if you go for the model where it can be > > >edited on the web > > >server as well, you run into this synchronization problem. > > >Now, you need to > > >keep interested entities (like my client app) aware of changes > > >to this list > > >that are made. There, having an event package for the "state" > > >of my buddy > > >list makes sense. I think this is what Sean is talking about. > > > > > >Now, a separate issue is what happens to my subscriptions when > > >I go offline. > > >Well, the nice behavior is to unSUBSCRIBE. If you don't, the > > >presence server > > >will eventually send a NOTIFY which either generates a 481 > or 404, or a > > >timeout, in which case the presence server would delete the > > >subscription. > > >Please note that this is totally unrelated to the state of my > > >buddy list. > > >This subscription is at the presence server of the presentity, > > >whilst the > > >buddy list is stored at a server in the domain of the > watcher. They are > > >totally unrelated. > > > > > >Brian is talking about a different model still. In this model, > > >the buddy > > >list isn't just stored and edited on the server, the > server uses it to > > >generate subscriptions directly. Effectively, the server > becomes the > > >watcher. If 10 people in its domain subscribe to some user > > >bob, the server > > >sends only one SUBSCRIBE to bob. The server can then use this > > >to deliver > > >notifications to the clients in its domain. The result is > > >aggregation, in > > >that fewer messages need to be sent out to the presentities (1 > > >instead of 10 > > >in the example). However, there is a serious security issue in > > >this model, > > >in that the presentity has no way to know the end user which > > >is requesting > > >the subscription. > > > > > >This approach, which is what I think Brian is talking about, > > >is discussed in > > >the original sip for presence draft: > > > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt > > > > > >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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > >Sent: Tuesday, June 19, 2001 11:22 AM > > >To: 'Sean Olson (EUS)'; 'Vencour Marcel'; > > >'simple@mailman.dynamicsoft.com' > > >Cc: Mayerhofer Andreas A > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > >You might get the LIST this way, but getting the updates may be > > >problematic because all of your buddies may not be served > by the same > > >presence server. > > > > > >You could imagine a server proxy that would do this; the list > > >had a full > > >subscription info, the proxy got the individual Notifies and > > >created one > > >composite Notify. A mobile client might like this a lot, but > > >it's less > > >interesting for "well connected" clients because little > > >aggregation occurs > > >unless there are "popular" buddies where the proxy can use > one Notify > > >as input for many lists. > > > > > >Still, it's a worthy idea, and sounds pretty cheap. Seems > to me the > > >only protocol impact is that you need a composite Notify that gets > > >you all the presence information in the list as one message. > > > > > >Brian > > >-----Original Message----- > > >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > > >Sent: Tuesday, June 19, 2001 9:47 AM > > >To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' > > >Cc: Mayerhofer Andreas A > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > >I was thinking a little about this. What > > >about the possibility of subscribing to > > >your buddy list? The buddy list could be > > >stored offline in, for example, a database. > > >A SUBSCRIBE request with Event: presence.targets (?) > > >would retrieve the static buddy list in a NOTIFY as > > >well as subsequent updates in future NOTIFYs. > > >The buddy list could also be tailored for the > > >client/terminal. > > >Comments? > > >/sean > > >-- > > >Sean Olson > > >Ericsson Inc. > > >>-----Original Message----- > > >>From: Vencour Marcel [mailto:marcel.vencour@siemens.at] > > >>Sent: Tuesday, June 19, 2001 7:41 AM > > >>To: 'simple@mailman.dynamicsoft.com' > > >>Cc: Mayerhofer Andreas A > > >>Subject: [Simple] Mobility of Buddy List > > >> > > >> > > >>Hello everybody, > > >> > > >>I have a problem concerning the buddy list used in a presence > > >>service: The > > >>question is, where is the buddy list of the watcher stored > > >>when the watcher > > >>goes offline? If it is stored in a file/database at the > > >location of the > > >>watcher, then it is bound to the watcher's client, i.e. it > > >>does not move > > >>around with the watcher (here watcher means the person, not > > >>the client used > > >>by that person) when he uses different machines to do his > > >>watching. Thus the > > >>buddy list would have to be stored at the presence > > >>server/presence agent > > >>(PS). But in this case how can the watcher go offline without > > >>deleting his > > >>buddy list at the PS? If he goes offline without sending any > > >>unsubscribe > > >>then the PS would continue to send notifications to the > > >>watcher which of > > >>course is unnecessary overhead. On the other hand, if the > > >watcher goes > > >>offline and sends unsubscribes for all his buddies then the > > >>buddy list would > > >>be removed from the PS. > > >>The next question then is, what happens when the watcher goes > > >>online again? > > >>How can he send a subscribe without giving a buddy in the > > >>request line (just > > >>to tell that he is online and thus wants to receive > > >>notifications again)? > > >> > > >>Thanks in advance for an answer, M. Vencour. > > >> > > >>_______________________________________________ > > >>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 jdrosen@dynamicsoft.com Wed Jun 20 17:06:24 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10740 for ; Wed, 20 Jun 2001 17:06:23 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA06830; Wed, 20 Jun 2001 17:10:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 17:06:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Mayerhofer Andreas A'" , Jonathan Rosenberg Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Contact header Usage in subsequent MESSAGE Requests Date: Wed, 20 Jun 2001 17:06:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 932 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA10740 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: > -----Original Message----- > From: Mayerhofer Andreas A [mailto:andreas.a.mayerhofer@siemens.at] > Sent: Monday, June 18, 2001 5:07 AM > To: 'Jonathan Rosenberg' > Cc: 'simple@mailman.dynamicsoft.com' > Subject: AW: [Simple] Contact header Usage in subsequent MESSAGE > Requests > > > Hello, > > in this email there is a link for some slides, > which explains the idea. > But this link doesn´t work. > Where can i find these slides? Sorry, my web site moved since that email was posted. The slides are at: http://www.jdrosen.net/papers/simple_open_mar01.ppt -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 From jane0l2l@excite.com Wed Jun 20 20:52:19 2001 Received: from mail.huataico.com ([202.96.187.221]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11332 for ; Wed, 20 Jun 2001 20:52:17 -0400 (EDT) Received: from plain [202.105.16.164] by mail.huataico.com (SMTPD32-6.04) id A2B3100FE; Wed, 20 Jun 2001 13:20:51 +0800 From: wayne To: simple@mailman.dynamicsoft.com Date: Wed, 20 Jun 2001 13:24:30 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Message-Id: <200106201320296.SM00137@plain> Content-Length: 6902 Subject: [Simple] Manuf. Production/Contrl Software For $1,495.00. 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: Master, a complete, user friendly Windows based software package, can manage and control your operation from sales quote to shipment. For one week only, Job Master, normally $2,495.00, is on sale for a total price of $1,495.00. In order for you to receive this $1,000.00 savings we must have your order by June 22th. Job Master is designed specifically for small to medium sized manufacturers, and costs many thousands of dollars less than any other even remotely comparable software package. Following is a list of features. If you have any questions, would like to discuss the package further, or if you would like to obtain our Web site address for a total walk through of the program, please call me directly at (661) 286-0041 (please do not E Mail me back. I may not get your message if you simply hit "Reply" and respond to this message via return E Mail). By way of background, we are a software company, which for some years has specialized in the development of custom software, primarily for small to medium sized manufacturers. Job Master is a distillation of over a million and a half dollars of software we have developed to control and manage the production of our manufacturing clients. Job Master contains the following features: 1. QUOTATION MODULE. In this module, quotes are developed, modified, and produced for sending to your client. A history is kept of all quotes for future reference, or modification for other clients. All quotations and revisions are "auto numbered," including versions. The quotes section allows for the entry of parts/processes, and costing of each, including materials, labor, markup, and taxes. Inventory status can be accessed from this section for reference. 2. SALES ORDER. Once a quotation is accepted, the final quotation information can be transformed into a Sales Order for your client's signature on a "point and click" basis. The Sales Order can be modified and re issued if necessary. A history if kept of all Sales Orders for future reference, or modification for other clients. All sales orders and revisions are "auto numbered," including versions. Inventory status can be accessed from this section for reference. 3. CUSTOMER LETTERS can be created from the Quotation and Sales Order sections. 4. SHOP TRAVELER/WORK ORDER. Once a Sales Order is accepted, the sales order information can be transformed into a shop traveler/work order on a "point and click" basis. Each item on the Sales Order becomes a shop traveler/work order, with each step of production of the item then listed on the traveler/work order. Each such traveler/work order is tied back into the Sales Order. The shop traveler/work order allows for the entry of line items, and notes on each line item. The shop traveler/work order contains a "notes" section. The Shop traveler/work order allows for the storing or attachment of drawings to the traveler/work order. The shop traveler/work order also contains a "drop down," from which standard processes can be selected for inclusion on the shop traveler/work order. The shop traveler/work order numbers progress in order of production sequence, and re numbers them if new steps are added. The shop traveler/work order allows for change orders or revisions, and numbers changes in sequence of he original shop traveler/work order number; i.e., 100, 100-1, 100-2, etc. All shop traveler/work orders and related revisions are retained in memory for future reference. The shop traveler/work order is bar coded for tracking of production step by step, and production of ongoing client status reports. Bar coding includes the ability for an employee to "swipe" their own ID bar code for recording in the system as to who upgraded what step. The shop traveler/work order function also allows for manual update of production status. The shop traveler/work order allows for quality control sign off, and the final production of certifications, either from a "canned" list, or hand typed in on a case by case basis. 5. INVENTORY. The application includes an inventory section, which allows operations to check materials inventory in and out. The inventory section allows for the comparison of inventory received against a P.O., and produces an "overage/underage" report of inventory received as compared against the P.O. The inventory section allows for the setting of minimum (re-order now!) and maximum inventory amounts, and produces reports showing what inventory needs to be ordered, as well as inventory that is at or above the maximum set to have in house. The inventory section also tracks "partially shipped" orders, which are tied in to the shipping function. This section shows how much completed product under a particular order has been actually shipped to a client, and how much remains to be shipped. The balance is adjusted as shipments are made. 6. REQUEST FOR PURCHASE. The application allows operators to produce a Request For Purchase for accounting for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item. 7. REQUEST FOR BID. The application allows operators to produce a Request For Bid for accounting to send to Vendors for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item to which Requests For Bid can be sent. 8. INVOICE. The application produces an invoice/invoice detail for all completed items ready to be billed/shipped to clients. 9. PRODUCTION OUTPUT STATUS. The application produces a date range selectable report on how much product, and the value of the product, which was completed during a selected date range. The application also produces a report on how many orders, and the value of those orders, which remain to be completed during a selected date range. 10. The application produces SHIPPING DOCUMENTS as per selected shippers, and produces a PACKING SLIP. 11. The application has a "FIND" FUNCTION in selected sections, allowing for searches by customer name, work order number, etc. 12. The application has "AUTO FILL;" i.e., when an operator starts to type in a name, number, etc. all related information auto fills after the first few letters or numbers are typed in. Job Master is currently being sold in the marketplace for $2,495.00 per package. However, if we receive your order by June 22th, your total price will be $1,495.00 Again, if you have any questions at all, or would like to place your order, please call me on my direct line, (661) 286-0041. Thank you! Wayne D. McFarland Application Sales, Inc. ---------------------------------------------------------------------- You have received this newsletter because you signed up for updates on our tracking software. If you want to unsubscribe from this newsletter, please send a reply email with "REMOVE" in the subject line. From ROBERTO@windows.microsoft.com Wed Jun 20 23:33:00 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id XAA11757 for ; Wed, 20 Jun 2001 23:32:59 -0400 (EDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Jun 2001 20:19:15 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 20 Jun 2001 20:18:22 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 20 Jun 2001 20:18:18 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Jun 2001 20:16:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Mobility of Buddy List Date: Wed, 20 Jun 2001 20:16:47 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC101106F22@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Mobility of Buddy List Thread-Index: AcD5g9mcJZnYqdiMQNWIfHr0noo5egAfAxtQ From: "Robert Osborne" To: "Rosen, Brian" , "Vasilis Polychronidis" Cc: "Jonathan Rosenberg" , "Sean Olson (EUS)" , "Vencour Marcel" , , "Mayerhofer Andreas A" X-OriginalArrivalTime: 21 Jun 2001 03:16:47.0647 (UTC) FILETIME=[9B28F2F0:01C0FA00] Content-Length: 12892 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id XAA11757 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: I think we are discussing two different items here. As a user I have a set of other users whose presence information I am interested in, irrespective of which client or device I am using. So when I am sitting at my desktop I am interested in the presence information for my friends and colleagues. When I am at home using my laptop finishing up a spec, I am still interested in the presence information for my friends and colleagues. Therefore as these are two different devices I do not wish to enter in the presentity information twice, but rather have the buddy information available no matter which device I am using. As for contacts, by which I assume you mean something similar to Outlook contacts where the address, phone number, email etc is stored, then I partially agree that contacts and presentities are different things. It is likely that the list of presentities I am interested in is a subset of my contacts, but not guaranteed. However, I am unsure what this has to do with the fact that the presentities I am interested in should be stored on a central SIP server, and available no matter which device or application I am using. Rob O -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Wednesday, June 20, 2001 5:25 AM To: 'Vasilis Polychronidis'; Robert Osborne Cc: Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel; simple@mailman.dynamicsoft.com; Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List I agree. The basic contents of the lists are probably common (presentity), but the structure is not. Consider the standard AOL Instant Messenger list already has a two dimensional structure, and it is easy to imagine more elaborate structures for the lists. As Vasilis points out, contact information and "buddy lists" may be combined, and we aren't going to standardize contacts are we? In our implementation, we plan to have more information in our content entries beyond just the presentity, so a standardized list format would be problematic. It is always possible to leave the list as an XML blob, but then I don't think anyone gets any advantage out of that. Brian > -----Original Message----- > From: Vasilis Polychronidis > [mailto:Vasilis.Polychronidis@Openwave.com] > Sent: Wednesday, June 20, 2001 4:07 AM > To: Robert Osborne > Cc: Jonathan Rosenberg; Rosen, Brian; Sean Olson (EUS); > Vencour Marcel; > simple@mailman.dynamicsoft.com; Mayerhofer Andreas A > Subject: Re: [Simple] Mobility of Buddy List > > > Hi Robert, > Please see my comments below: > > Kind Regards, > > Vasilis Polychronidis > > Robert Osborne wrote: > > > Hi, > > > > in your discussion of where the buddy list should be stored, you > > state that it should be stored on a server, which makes > sense. However > > you state that it need NOT be stored on the presence of > proxy server. > > My question is, why would the buddy list not be stored on > the presence > > server, but be stored somewhere else? > > Well I think buddy lists are application specific data. > In my IM application for example I can have a different > contact list (buddy list) than my e-mail contact list. > Multiple applications with different requirements will need access > to the presence data of presentities. The grouping of > presentities into > contact lists is dependent on the specific application and i > do not think > is practical of requiring all application that want to use > the presence > service > to store their contact lists to the presence server. > > > > > > > If it was, the client needs to have some additionl intelligence: > > > > * Which server should I connect to in order to retrieve my > buddy list > > * All devices would need to understand HTTP or whatever > other protocol > > is required > > * Will I be able to connect to that server, because of firewalls etc > > > > It seems to me that this is adding in further complexity to > do something > > which should be relatively simple. > > I do not think that is so simple. I think Contact Lists, PIMs, > synchronization, etc. > issues are not easy to solve in a standards based approach. > > > I think something similar to what > > Sean suggests make sense and ensure that the client only > requires some > > minor capabilites, compared to a completely new protocol support. > > > > Rob O > > > > >-----Original Message----- > > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > >Sent: Tuesday, June 19, 2001 9:14 AM > > >To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; > > >'simple@mailman.dynamicsoft.com' > > >Cc: Mayerhofer Andreas A > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > >Hang on here... I think we are all talking about a few > > >different things. > > > > > >First off, in my mind, the definition of a "buddy list" is > the set of > > >presentities that a particular user is subscribed to. Lets > > >just make sure we > > >are clear about that. Where this list is stored, and what > happens to my > > >subscriptions when I go offline, are two very different things. > > > > > >First off, where is it stored? One place is in the client. > > >This doesn't mean > > >that its deleted when I log off; it would presumably be stored > > >on disk in > > >some way. When the client app is restarted, it looks at > that list and > > >generates subscription refreshes for all of the users in the > > >buddy list. > > > > > >The drawback of storing it on the client is that it ties you > > >to a particular > > >desktop. An alternative idea is to store it on a server in the > > >network (this > > >need NOT be the same as the presence server or proxy > server or anything > > >else). So, when I start my client app, it goes to a web > > >server, say, and > > >fetches my buddy list. Then, the client app sends a SUBSCRIBE > > >for all of the > > >entries there. Now, I can sit down at any machine, and log in, > > >and then get > > >my buddy list there. This was the motivation for our buddy > list format > > >proposal as part of last summer's SIMPLE proposal: > > > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt > > > > > >In this model, the buddylist is only stored on the web server, > > >but edited on > > >the client. Now, if you go for the model where it can be > > >edited on the web > > >server as well, you run into this synchronization problem. > > >Now, you need to > > >keep interested entities (like my client app) aware of changes > > >to this list > > >that are made. There, having an event package for the "state" > > >of my buddy > > >list makes sense. I think this is what Sean is talking about. > > > > > >Now, a separate issue is what happens to my subscriptions when > > >I go offline. > > >Well, the nice behavior is to unSUBSCRIBE. If you don't, the > > >presence server > > >will eventually send a NOTIFY which either generates a 481 > or 404, or a > > >timeout, in which case the presence server would delete the > > >subscription. > > >Please note that this is totally unrelated to the state of my > > >buddy list. > > >This subscription is at the presence server of the presentity, > > >whilst the > > >buddy list is stored at a server in the domain of the > watcher. They are > > >totally unrelated. > > > > > >Brian is talking about a different model still. In this model, > > >the buddy > > >list isn't just stored and edited on the server, the > server uses it to > > >generate subscriptions directly. Effectively, the server > becomes the > > >watcher. If 10 people in its domain subscribe to some user > > >bob, the server > > >sends only one SUBSCRIBE to bob. The server can then use this > > >to deliver > > >notifications to the clients in its domain. The result is > > >aggregation, in > > >that fewer messages need to be sent out to the presentities (1 > > >instead of 10 > > >in the example). However, there is a serious security issue in > > >this model, > > >in that the presentity has no way to know the end user which > > >is requesting > > >the subscription. > > > > > >This approach, which is what I think Brian is talking about, > > >is discussed in > > >the original sip for presence draft: > > > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt > > > > > >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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > >Sent: Tuesday, June 19, 2001 11:22 AM > > >To: 'Sean Olson (EUS)'; 'Vencour Marcel'; > > >'simple@mailman.dynamicsoft.com' > > >Cc: Mayerhofer Andreas A > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > >You might get the LIST this way, but getting the updates may be > > >problematic because all of your buddies may not be served > by the same > > >presence server. > > > > > >You could imagine a server proxy that would do this; the list > > >had a full > > >subscription info, the proxy got the individual Notifies and > > >created one > > >composite Notify. A mobile client might like this a lot, but > > >it's less > > >interesting for "well connected" clients because little > > >aggregation occurs > > >unless there are "popular" buddies where the proxy can use > one Notify > > >as input for many lists. > > > > > >Still, it's a worthy idea, and sounds pretty cheap. Seems > to me the > > >only protocol impact is that you need a composite Notify that gets > > >you all the presence information in the list as one message. > > > > > >Brian > > >-----Original Message----- > > >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > > >Sent: Tuesday, June 19, 2001 9:47 AM > > >To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' > > >Cc: Mayerhofer Andreas A > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > >I was thinking a little about this. What > > >about the possibility of subscribing to > > >your buddy list? The buddy list could be > > >stored offline in, for example, a database. > > >A SUBSCRIBE request with Event: presence.targets (?) > > >would retrieve the static buddy list in a NOTIFY as > > >well as subsequent updates in future NOTIFYs. > > >The buddy list could also be tailored for the > > >client/terminal. > > >Comments? > > >/sean > > >-- > > >Sean Olson > > >Ericsson Inc. > > >>-----Original Message----- > > >>From: Vencour Marcel [mailto:marcel.vencour@siemens.at] > > >>Sent: Tuesday, June 19, 2001 7:41 AM > > >>To: 'simple@mailman.dynamicsoft.com' > > >>Cc: Mayerhofer Andreas A > > >>Subject: [Simple] Mobility of Buddy List > > >> > > >> > > >>Hello everybody, > > >> > > >>I have a problem concerning the buddy list used in a presence > > >>service: The > > >>question is, where is the buddy list of the watcher stored > > >>when the watcher > > >>goes offline? If it is stored in a file/database at the > > >location of the > > >>watcher, then it is bound to the watcher's client, i.e. it > > >>does not move > > >>around with the watcher (here watcher means the person, not > > >>the client used > > >>by that person) when he uses different machines to do his > > >>watching. Thus the > > >>buddy list would have to be stored at the presence > > >>server/presence agent > > >>(PS). But in this case how can the watcher go offline without > > >>deleting his > > >>buddy list at the PS? If he goes offline without sending any > > >>unsubscribe > > >>then the PS would continue to send notifications to the > > >>watcher which of > > >>course is unnecessary overhead. On the other hand, if the > > >watcher goes > > >>offline and sends unsubscribes for all his buddies then the > > >>buddy list would > > >>be removed from the PS. > > >>The next question then is, what happens when the watcher goes > > >>online again? > > >>How can he send a subscribe without giving a buddy in the > > >>request line (just > > >>to tell that he is online and thus wants to receive > > >>notifications again)? > > >> > > >>Thanks in advance for an answer, M. Vencour. > > >> > > >>_______________________________________________ > > >>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 Vasilis.Polychronidis@Openwave.com Thu Jun 21 01:33:57 2001 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 BAA12086 for ; Thu, 21 Jun 2001 01:33:57 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010621053251.PSXA13968.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 21 Jun 2001 00:32:51 -0500 Received: from Openwave.com ([4.41.19.90]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010621053353.PAZB10980.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Thu, 21 Jun 2001 00:33:53 -0500 Message-ID: <3B31873C.411EC8FA@Openwave.com> Date: Wed, 20 Jun 2001 22:33:48 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Osborne CC: "Rosen, Brian" , Jonathan Rosenberg , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com, Mayerhofer Andreas A Subject: Re: [Simple] Mobility of Buddy List References: <2E33960095B58E40A4D3345AB9F65EC101106F22@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: multipart/alternative; boundary="------------54D94A480237670F04998346" Content-Length: 35196 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: --------------54D94A480237670F04998346 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert, I think we are in agreement here: 1. There are primary two types of contact lists (buddy lists): 1.1 Server/network based = Contact lists are stored somewhere in the network and provide device independence. This is exactly how many current IM services are functioning today. For example when using a server based IM system I can log on via my mobile client, desktop or "Web/HTML" client and still view the same contact list (buddy list) regardless of the access method. 2.1 Client based = Contact lists are stored on the client side. Of course in this case when you change client or device, etc. in principle you do not view the same contact list. In order to sync up the different contact lists you will need some king of peer to peer sync protocol between the various clients, devices, etc. 2. There are and will be various applications besides IM that will use the presence service. These applications in principle will have different structure and possible different set of elements that comprise their associated contact lists. For example I can have: 2.1 An IM application where my contact list is comprised of a set of "friends", coworkers, etc. 2.2 A gaming application (that is provided by a different vendor than the IM one) that has a different contact list (structure, elements, etc.) Both applications are using the Presence Service (subscribing and being notified of the current status of various presentities) but they have completely different contact lists. Mandating of storing all contact lists (of the different apps) into a single server i think is at best impractical. As you correctly pointed out 1 is a different item than 2. Please see additional comments below: Kind regards, Vasilis Polychronidis Robert Osborne wrote: > I think we are discussing two different items here. As a user > I have a set of other users whose presence information I am > interested in, irrespective of which client or device I am > using. > > So when I am sitting at my desktop I am interested in the > presence information for my friends and colleagues. When I > am at home using my laptop finishing up a spec, I am still > interested in the presence information for my friends and > colleagues. Therefore as these are two different devices I > do not wish to enter in the presentity information twice, > but rather have the buddy information available no matter > which device I am using. So in this case you should choose a provider that offers an IM system with server/network based buddy lists (device/ access independent). > > > As for contacts, I use Contact list and Buddy list as equivalent terms. . Please feel free to replace any reference to Contact list with Buddy list in this thread. If you want to be more precise Buddy List = a form of Contact List + status info. > by which I assume you mean something similar > to Outlook contacts where the address, phone number, email > etc is stored, then I partially agree that contacts and > presentities are different things. It is likely that the list > of presentities I am interested in is a subset of my contacts, > but not guaranteed. However, I am unsure what this has to do > with the fact that the presentities I am interested in should > be stored on a central SIP server, and available no matter which > device or application I am using. Because as a service provider I may want to offer additional apps (different than IM) that make use of the presence data and I do not want to be forced to choose the same vendor for both my IM and the additional presence enabled apps. > > > Rob O > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, June 20, 2001 5:25 AM > To: 'Vasilis Polychronidis'; Robert Osborne > Cc: Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel; > simple@mailman.dynamicsoft.com; Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > I agree. The basic contents of the lists are probably common > (presentity), but the structure is not. Consider the standard > AOL Instant Messenger list already has a two dimensional structure, > and it is easy to imagine more elaborate structures for the lists. > As Vasilis points out, contact information and "buddy lists" may > be combined, and we aren't going to standardize contacts are we? > > In our implementation, we plan to have more information in our content > entries beyond just the presentity, so a standardized list format > would be problematic. > > It is always possible to leave the list as an XML blob, but then > I don't think anyone gets any advantage out of that. > > Brian > > > -----Original Message----- > > From: Vasilis Polychronidis > > [mailto:Vasilis.Polychronidis@Openwave.com] > > Sent: Wednesday, June 20, 2001 4:07 AM > > To: Robert Osborne > > Cc: Jonathan Rosenberg; Rosen, Brian; Sean Olson (EUS); > > Vencour Marcel; > > simple@mailman.dynamicsoft.com; Mayerhofer Andreas A > > Subject: Re: [Simple] Mobility of Buddy List > > > > > > Hi Robert, > > Please see my comments below: > > > > Kind Regards, > > > > Vasilis Polychronidis > > > > Robert Osborne wrote: > > > > > Hi, > > > > > > in your discussion of where the buddy list should be stored, you > > > state that it should be stored on a server, which makes > > sense. However > > > you state that it need NOT be stored on the presence of > > proxy server. > > > My question is, why would the buddy list not be stored on > > the presence > > > server, but be stored somewhere else? > > > > Well I think buddy lists are application specific data. > > In my IM application for example I can have a different > > contact list (buddy list) than my e-mail contact list. > > Multiple applications with different requirements will need access > > to the presence data of presentities. The grouping of > > presentities into > > contact lists is dependent on the specific application and i > > do not think > > is practical of requiring all application that want to use > > the presence > > service > > to store their contact lists to the presence server. > > > > > > > > > > > If it was, the client needs to have some additionl intelligence: > > > > > > * Which server should I connect to in order to retrieve my > > buddy list > > > * All devices would need to understand HTTP or whatever > > other protocol > > > is required > > > * Will I be able to connect to that server, because of firewalls etc > > > > > > It seems to me that this is adding in further complexity to > > do something > > > which should be relatively simple. > > > > I do not think that is so simple. I think Contact Lists, PIMs, > > synchronization, etc. > > issues are not easy to solve in a standards based approach. > > > > > I think something similar to what > > > Sean suggests make sense and ensure that the client only > > requires some > > > minor capabilites, compared to a completely new protocol support. > > > > > > Rob O > > > > > > >-----Original Message----- > > > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > >Sent: Tuesday, June 19, 2001 9:14 AM > > > >To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; > > > >'simple@mailman.dynamicsoft.com' > > > >Cc: Mayerhofer Andreas A > > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > > > > >Hang on here... I think we are all talking about a few > > > >different things. > > > > > > > >First off, in my mind, the definition of a "buddy list" is > > the set of > > > >presentities that a particular user is subscribed to. Lets > > > >just make sure we > > > >are clear about that. Where this list is stored, and what > > happens to my > > > >subscriptions when I go offline, are two very different things. > > > > > > > >First off, where is it stored? One place is in the client. > > > >This doesn't mean > > > >that its deleted when I log off; it would presumably be stored > > > >on disk in > > > >some way. When the client app is restarted, it looks at > > that list and > > > >generates subscription refreshes for all of the users in the > > > >buddy list. > > > > > > > >The drawback of storing it on the client is that it ties you > > > >to a particular > > > >desktop. An alternative idea is to store it on a server in the > > > >network (this > > > >need NOT be the same as the presence server or proxy > > server or anything > > > >else). So, when I start my client app, it goes to a web > > > >server, say, and > > > >fetches my buddy list. Then, the client app sends a SUBSCRIBE > > > >for all of the > > > >entries there. Now, I can sit down at any machine, and log in, > > > >and then get > > > >my buddy list there. This was the motivation for our buddy > > list format > > > >proposal as part of last summer's SIMPLE proposal: > > > > > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt > > > > > > > >In this model, the buddylist is only stored on the web server, > > > >but edited on > > > >the client. Now, if you go for the model where it can be > > > >edited on the web > > > >server as well, you run into this synchronization problem. > > > >Now, you need to > > > >keep interested entities (like my client app) aware of changes > > > >to this list > > > >that are made. There, having an event package for the "state" > > > >of my buddy > > > >list makes sense. I think this is what Sean is talking about. > > > > > > > >Now, a separate issue is what happens to my subscriptions when > > > >I go offline. > > > >Well, the nice behavior is to unSUBSCRIBE. If you don't, the > > > >presence server > > > >will eventually send a NOTIFY which either generates a 481 > > or 404, or a > > > >timeout, in which case the presence server would delete the > > > >subscription. > > > >Please note that this is totally unrelated to the state of my > > > >buddy list. > > > >This subscription is at the presence server of the presentity, > > > >whilst the > > > >buddy list is stored at a server in the domain of the > > watcher. They are > > > >totally unrelated. > > > > > > > >Brian is talking about a different model still. In this model, > > > >the buddy > > > >list isn't just stored and edited on the server, the > > server uses it to > > > >generate subscriptions directly. Effectively, the server > > becomes the > > > >watcher. If 10 people in its domain subscribe to some user > > > >bob, the server > > > >sends only one SUBSCRIBE to bob. The server can then use this > > > >to deliver > > > >notifications to the clients in its domain. The result is > > > >aggregation, in > > > >that fewer messages need to be sent out to the presentities (1 > > > >instead of 10 > > > >in the example). However, there is a serious security issue in > > > >this model, > > > >in that the presentity has no way to know the end user which > > > >is requesting > > > >the subscription. > > > > > > > >This approach, which is what I think Brian is talking about, > > > >is discussed in > > > >the original sip for presence draft: > > > > > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt > > > > > > > >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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > >Sent: Tuesday, June 19, 2001 11:22 AM > > > >To: 'Sean Olson (EUS)'; 'Vencour Marcel'; > > > >'simple@mailman.dynamicsoft.com' > > > >Cc: Mayerhofer Andreas A > > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > > > > >You might get the LIST this way, but getting the updates may be > > > >problematic because all of your buddies may not be served > > by the same > > > >presence server. > > > > > > > >You could imagine a server proxy that would do this; the list > > > >had a full > > > >subscription info, the proxy got the individual Notifies and > > > >created one > > > >composite Notify. A mobile client might like this a lot, but > > > >it's less > > > >interesting for "well connected" clients because little > > > >aggregation occurs > > > >unless there are "popular" buddies where the proxy can use > > one Notify > > > >as input for many lists. > > > > > > > >Still, it's a worthy idea, and sounds pretty cheap. Seems > > to me the > > > >only protocol impact is that you need a composite Notify that gets > > > >you all the presence information in the list as one message. > > > > > > > >Brian > > > >-----Original Message----- > > > >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > > > >Sent: Tuesday, June 19, 2001 9:47 AM > > > >To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' > > > >Cc: Mayerhofer Andreas A > > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > > > > >I was thinking a little about this. What > > > >about the possibility of subscribing to > > > >your buddy list? The buddy list could be > > > >stored offline in, for example, a database. > > > >A SUBSCRIBE request with Event: presence.targets (?) > > > >would retrieve the static buddy list in a NOTIFY as > > > >well as subsequent updates in future NOTIFYs. > > > >The buddy list could also be tailored for the > > > >client/terminal. > > > >Comments? > > > >/sean > > > >-- > > > >Sean Olson > > > >Ericsson Inc. > > > >>-----Original Message----- > > > >>From: Vencour Marcel [mailto:marcel.vencour@siemens.at] > > > >>Sent: Tuesday, June 19, 2001 7:41 AM > > > >>To: 'simple@mailman.dynamicsoft.com' > > > >>Cc: Mayerhofer Andreas A > > > >>Subject: [Simple] Mobility of Buddy List > > > >> > > > >> > > > >>Hello everybody, > > > >> > > > >>I have a problem concerning the buddy list used in a presence > > > >>service: The > > > >>question is, where is the buddy list of the watcher stored > > > >>when the watcher > > > >>goes offline? If it is stored in a file/database at the > > > >location of the > > > >>watcher, then it is bound to the watcher's client, i.e. it > > > >>does not move > > > >>around with the watcher (here watcher means the person, not > > > >>the client used > > > >>by that person) when he uses different machines to do his > > > >>watching. Thus the > > > >>buddy list would have to be stored at the presence > > > >>server/presence agent > > > >>(PS). But in this case how can the watcher go offline without > > > >>deleting his > > > >>buddy list at the PS? If he goes offline without sending any > > > >>unsubscribe > > > >>then the PS would continue to send notifications to the > > > >>watcher which of > > > >>course is unnecessary overhead. On the other hand, if the > > > >watcher goes > > > >>offline and sends unsubscribes for all his buddies then the > > > >>buddy list would > > > >>be removed from the PS. > > > >>The next question then is, what happens when the watcher goes > > > >>online again? > > > >>How can he send a subscribe without giving a buddy in the > > > >>request line (just > > > >>to tell that he is online and thus wants to receive > > > >>notifications again)? > > > >> > > > >>Thanks in advance for an answer, M. Vencour. > > > >> > > > >>_______________________________________________ > > > >>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 > > > > > > --------------54D94A480237670F04998346 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert,
I think we are in agreement here:
1. There are primary two types of contact lists (buddy lists):
    1.1 Server/network based = Contact lists are stored somewhere in the network and
          provide device independence. This is exactly how many current IM services are
          functioning today. For example when using a server based IM system I can log on
          via my mobile client, desktop or "Web/HTML" client and still view the same contact list (buddy list)
          regardless of the access method.
    2.1 Client based = Contact lists are stored on the client side. Of course in this case when you change client
          or device, etc. in principle you do not view the same contact list. In order to sync up the
          different contact lists you will need some king of peer to peer sync protocol between the various
          clients, devices, etc.
2. There are and will be various applications besides IM that will use the presence service.
    These applications in principle will have different structure and possible different set of elements that
    comprise their associated contact lists.
    For example I can have:
    2.1 An IM application where my contact list is comprised of a set of "friends", coworkers, etc.
    2.2 A gaming application (that is provided by a different vendor than the IM one) that has a different
          contact list (structure, elements, etc.)
    Both applications are using the Presence Service (subscribing and being notified of the current status of various
    presentities) but they have completely different contact lists.
    Mandating of storing all contact lists  (of the different apps) into a single server i think is at best impractical.

As you correctly pointed out 1 is a different item than 2.
Please see additional comments below:

Kind regards,

Vasilis Polychronidis

Robert Osborne wrote:

I think we are discussing two different items here. As a user
I have a set of other users whose presence information I am
interested in, irrespective of which client or device I am
using.

So when I am sitting at my desktop I am interested in the
presence information for my friends and colleagues. When I
am at home using my laptop finishing up a spec, I am still
interested in the presence information for my friends and
colleagues. Therefore as these are two different devices I
do not wish to enter in the presentity information twice,
but rather have the buddy information available no matter
which device I am using.

So in this case you should choose a provider that offers an IM system
with server/network based buddy lists (device/ access independent).
 

As for contacts,

I use Contact list and Buddy list as equivalent terms. .
Please feel free to replace any reference to Contact list with Buddy list in this thread.
If you want to be more precise Buddy List = a form of Contact List + status info.
by which I assume you mean something similar
to Outlook contacts where the address, phone number, email
etc is stored, then I partially agree that contacts and
presentities are different things. It is likely that the list
of presentities I am interested in is a subset of my contacts,
but not guaranteed. However, I am unsure what this has to do
with the fact that the presentities I am interested in should
be stored on a central SIP server, and available no matter which
device or application I am using.
Because as a service provider I may want to offer additional apps (different than IM)
that make use of the presence data and I do not want to be forced to choose the same
vendor for both my IM and the additional presence enabled apps.
 

Rob O

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, June 20, 2001 5:25 AM
To: 'Vasilis Polychronidis'; Robert Osborne
Cc: Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel;
simple@mailman.dynamicsoft.com; Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List

I agree.  The basic contents of the lists are probably common
(presentity), but the structure is not.  Consider the standard
AOL Instant Messenger list already has a two dimensional structure,
and it is easy to imagine more elaborate structures for the lists.
As Vasilis points out, contact information and "buddy lists" may
be combined, and we aren't going to standardize contacts are we?

In our implementation, we plan to have more information in our content
entries beyond just the presentity, so a standardized list format
would be problematic.

It is always possible to leave the list as an XML blob, but then
I don't think anyone gets any advantage out of that.

Brian

> -----Original Message-----
> From: Vasilis Polychronidis
> [mailto:Vasilis.Polychronidis@Openwave.com]
> Sent: Wednesday, June 20, 2001 4:07 AM
> To: Robert Osborne
> Cc: Jonathan Rosenberg; Rosen, Brian; Sean Olson (EUS);
> Vencour Marcel;
> simple@mailman.dynamicsoft.com; Mayerhofer Andreas A
> Subject: Re: [Simple] Mobility of Buddy List
>
>
> Hi Robert,
> Please see my comments below:
>
> Kind Regards,
>
> Vasilis Polychronidis
>
> Robert Osborne wrote:
>
> > Hi,
> >
> > in your discussion of where the buddy list should be stored, you
> > state that it should be stored on a server, which makes
> sense. However
> > you state that it need NOT be stored on the presence of
> proxy server.
> > My question is, why would the buddy list not be stored on
> the presence
> > server, but be stored somewhere else?
>
> Well I think buddy lists are application specific data.
> In my IM application for example I can have a different
> contact list (buddy list) than my e-mail contact list.
> Multiple applications with different requirements will need access
> to the presence data of presentities. The grouping of
> presentities into
> contact lists is dependent on the specific application and i
> do not think
> is practical of requiring all application that want to use
> the presence
> service
> to store their contact lists to the presence server.
>
> >
> >
> > If it was, the client needs to have some additionl intelligence:
> >
> > * Which server should I connect to in order to retrieve my
> buddy list
> > * All devices would need to understand HTTP or whatever
> other protocol
> >   is required
> > * Will I be able to connect to that server, because of firewalls etc
> >
> > It seems to me that this is adding in further complexity to
> do something
> > which should be relatively simple.
>
> I do not think that is so simple. I think Contact Lists, PIMs,
> synchronization, etc.
> issues are not easy to solve in a standards based approach.
>
> > I think something similar to what
> > Sean suggests make sense and ensure that the client only
> requires some
> > minor capabilites, compared to a completely new protocol support.
> >
> > Rob O
> >
> > >-----Original Message-----
> > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > >Sent: Tuesday, June 19, 2001 9:14 AM
> > >To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel';
> > >'simple@mailman.dynamicsoft.com'
> > >Cc: Mayerhofer Andreas A
> > >Subject: RE: [Simple] Mobility of Buddy List
> > >
> > >
> > >Hang on here... I think we are all talking about a few
> > >different things.
> > >
> > >First off, in my mind, the definition of a "buddy list" is
> the set of
> > >presentities that a particular user is subscribed to. Lets
> > >just make sure we
> > >are clear about that. Where this list is stored, and what
> happens to my
> > >subscriptions when I go offline, are two very different things.
> > >
> > >First off, where is it stored? One place is in the client.
> > >This doesn't mean
> > >that its deleted when I log off; it would presumably be stored
> > >on disk in
> > >some way. When the client app is restarted, it looks at
> that list and
> > >generates subscription refreshes for all of the users in the
> > >buddy list.
> > >
> > >The drawback of storing it on the client is that it ties you
> > >to a particular
> > >desktop. An alternative idea is to store it on a server in the
> > >network (this
> > >need NOT be the same as the presence server or proxy
> server or anything
> > >else). So, when I start my client app, it goes to a web
> > >server, say, and
> > >fetches my buddy list. Then, the client app sends a SUBSCRIBE
> > >for all of the
> > >entries there. Now, I can sit down at any machine, and log in,
> > >and then get
> > >my buddy list there. This was the motivation for our buddy
> list format
> > >proposal as part of last summer's SIMPLE proposal:
> > >
> > >http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt
> > >
> > >In this model, the buddylist is only stored on the web server,
> > >but edited on
> > >the client. Now, if you go for the model where it can be
> > >edited on the web
> > >server as well, you run into this synchronization problem.
> > >Now, you need to
> > >keep interested entities (like my client app) aware of changes
> > >to this list
> > >that are made. There, having an event package for the "state"
> > >of my buddy
> > >list makes sense. I think this is what Sean is talking about.
> > >
> > >Now, a separate issue is what happens to my subscriptions when
> > >I go offline.
> > >Well, the nice behavior is to unSUBSCRIBE. If you don't, the
> > >presence server
> > >will eventually send a NOTIFY which either generates a 481
> or 404, or a
> > >timeout, in which case the presence server would delete the
> > >subscription.
> > >Please note that this is totally unrelated to the state of my
> > >buddy list.
> > >This subscription is at the presence server of the presentity,
> > >whilst the
> > >buddy list is stored at a server in the domain of the
> watcher. They are
> > >totally unrelated.
> > >
> > >Brian is talking about a different model still. In this model,
> > >the buddy
> > >list isn't just stored and edited on the server, the
> server uses it to
> > >generate subscriptions directly. Effectively, the server
> becomes the
> > >watcher. If 10 people in its domain subscribe to some user
> > >bob, the server
> > >sends only one SUBSCRIBE to bob. The server can then use this
> > >to deliver
> > >notifications to the clients in its domain. The result is
> > >aggregation, in
> > >that fewer messages need to be sent out to the presentities (1
> > >instead of 10
> > >in the example). However, there is a serious security issue in
> > >this model,
> > >in that the presentity has no way to know the end user which
> > >is requesting
> > >the subscription.
> > >
> > >This approach, which is what I think Brian is talking about,
> > >is discussed in
> > >the original sip for presence draft:
> > >
> > >http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt
> > >
> > >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: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > >Sent: Tuesday, June 19, 2001 11:22 AM
> > >To: 'Sean Olson (EUS)'; 'Vencour Marcel';
> > >'simple@mailman.dynamicsoft.com'
> > >Cc: Mayerhofer Andreas A
> > >Subject: RE: [Simple] Mobility of Buddy List
> > >
> > >
> > >You might get the LIST this way, but getting the updates may be
> > >problematic because all of your buddies may not be served
> by the same
> > >presence server.
> > >
> > >You could imagine a server proxy that would do this; the list
> > >had a full
> > >subscription info, the proxy got the individual Notifies and
> > >created one
> > >composite Notify.  A mobile client might like this a lot, but
> > >it's less
> > >interesting for "well connected" clients because little
> > >aggregation occurs
> > >unless there are "popular" buddies where the proxy can use
> one Notify
> > >as input for many lists.
> > >
> > >Still, it's a worthy idea, and sounds pretty cheap.  Seems
> to me the
> > >only protocol impact is that you need a composite Notify that gets
> > >you all the presence information in the list as one message.
> > >
> > >Brian
> > >-----Original Message-----
> > >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
> > >Sent: Tuesday, June 19, 2001 9:47 AM
> > >To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'
> > >Cc: Mayerhofer Andreas A
> > >Subject: RE: [Simple] Mobility of Buddy List
> > >
> > >
> > >I was thinking a little about this. What
> > >about the possibility of subscribing to
> > >your buddy list? The buddy list could be
> > >stored offline in, for example, a database.
> > >A SUBSCRIBE request with Event: presence.targets (?)
> > >would retrieve the static buddy list in a NOTIFY as
> > >well as subsequent updates in future NOTIFYs.
> > >The buddy list could also be tailored for the
> > >client/terminal.
> > >Comments?
> > >/sean
> > >--
> > >Sean Olson <sean.olson@ericsson.com>
> > >Ericsson Inc.
> > >>-----Original Message-----
> > >>From: Vencour Marcel [mailto:marcel.vencour@siemens.at]
> > >>Sent: Tuesday, June 19, 2001 7:41 AM
> > >>To: 'simple@mailman.dynamicsoft.com'
> > >>Cc: Mayerhofer Andreas A
> > >>Subject: [Simple] Mobility of Buddy List
> > >>
> > >>
> > >>Hello everybody,
> > >>
> > >>I have a problem concerning the buddy list used in a presence
> > >>service: The
> > >>question is, where is the buddy list of the watcher stored
> > >>when the watcher
> > >>goes offline? If it is stored in a file/database at the
> > >location of the
> > >>watcher, then it is bound to the watcher's client, i.e. it
> > >>does not move
> > >>around with the watcher (here watcher means the person, not
> > >>the client used
> > >>by that person) when he uses different machines to do his
> > >>watching. Thus the
> > >>buddy list would have to be stored at the presence
> > >>server/presence agent
> > >>(PS). But in this case how can the watcher go offline without
> > >>deleting his
> > >>buddy list at the PS? If he goes offline without sending any
> > >>unsubscribe
> > >>then the PS would continue to send notifications to the
> > >>watcher which of
> > >>course is unnecessary overhead. On the other hand, if the
> > >watcher goes
> > >>offline and sends unsubscribes for all his buddies then the
> > >>buddy list would
> > >>be removed from the PS.
> > >>The next question then is, what happens when the watcher goes
> > >>online again?
> > >>How can he send a subscribe without giving a buddy in the
> > >>request line (just
> > >>to tell that he is online and thus wants to receive
> > >>notifications again)?
> > >>
> > >>Thanks in advance for an answer, M. Vencour.
> > >>
> > >>_______________________________________________
> > >>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
>
>
>

--------------54D94A480237670F04998346-- From jdrosen@dynamicsoft.com Thu Jun 21 01:52:53 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12198 for ; Thu, 21 Jun 2001 01:52:53 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11949; Thu, 21 Jun 2001 01:56:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 01:52:49 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" , Jonathan Rosenberg , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Thu, 21 Jun 2001 01:52:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 6480 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: > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, June 19, 2001 1:41 PM > To: 'Jonathan Rosenberg'; 'Sean Olson (EUS)'; 'Vencour Marcel'; > 'simple@mailman.dynamicsoft.com' > Cc: Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > > Yes, you have what I was talking about reasonably well represented. > > I'll point out that the server can get more aggregation if it > is popular, in that, in theory, it can get one Notify from a > presentity that it then sends in aggregated Notifies to multiple > subscribers to its lists. And yes, this makes the security problem > worse (since to be usefull, the real presentity has to actually > only send one Notify). Right. Its important that this scenario be modeled as one where the server which generates the notifies locally is a watcher itself. In SIP terms, its a B2BUA. It receives multiple subscriptions from users in its domain, and accepts them locally, as if it were a presence agent. To obtain the data it needs to drive notifications, it subscribes itself (providing its own credentials/keys to the presentity's presence agent) to the presentity. The presentity would see that the subscription is from some domain server, rather than individuals, and could decide, based on its own policies, about whether to accept such an aggregated subscription or not. Assuming its accepted, the server gets the notifications. It the generates notifications back to its subscribers. It is NOT a proxy at all. Using this B2BUA model makes things vastly simpler than trying to specifically support aggregation in this way. Andrew had suggested: >Regarding Brian's aggregation model, how difficult would it be to allow for >aggregation by having the aggregator list the individual subscribers in an >aggregated SUBSCRIBE? > >On the other hand, this could produce some unintended side problems. How would >one reject just one name on the list? How is the aggregator trusted? (Or can we >verify that any individual is/is not an aggregator and redistributor?) These problems are all indicative of the difficulties of these hybrid models. There are no easy solutions if this approach is taken. Keep the basic SUBCRIBE/NOTIFY mechanism simple - some entity subscribes, its authorized, and it gets notified. Build flexibility by varying what that entity is, and what it does with the data once it gets it. > > The security problem would have to be dealt with, but it seems to me > it's pretty straightforward - the client subscribes as usual with > the server proxying the subscription request, possibly including > its own credentials. The presentity would know the original > subscriber, and the server. The presentity could decline the > subscription if it didn't trust the server. The original subscriber is meaningless. There are other subscribers - why is the first important? Its not. Furhermore, if encryption is used, the message has to be encrypted with the public key of the SERVER, not of one of the subscribers. The server will decrypt it, and then redistribute it by re-encrypting it with the keys of each of the subscribers in its own domain. Aggregation fundamentally implies a transitive trust relationship. > > You could even encrypt the presence information such that the > server didn't know the contents - it's simply a relay for the > presence information anyway. Nope. WHose key would the presence data be encrypted with? As soon as the server relays it to more than one person, it doesn't make sense. > > Probably too complex for the first version of this stuff, > but thinking about proxying subscriptions, and structuring the > Notify so that an aggregate presence document can pass would > be usefull. Presence aggregation, as I describe it above, requires no special standardization effort. Its a usage scenario. Please note, though, that there are two types of aggregation: 1. multiple subscriptions for the same presentity, from subscribers in one domain, are aggregated into a single subscription for that presentity from the server for the subsciber's domain. Pictorally: Please view in a fixed-width font such as Courier. +----+ | | | | +----+\ \ SUB joe \ \ \ aggregator \ joe's presence server +--+ SUB joe> +----+ SUB joe +----+ | | --------->| | -----------> | | +--+ > | | | | // +----+ +----+ / / // SUB joe +----* | | +----+ 2. a single watcher subscribes to multiple presentities, but aggregates all its subscribe requests into a single subscribe message to its local server. For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com". That server generates individual subscriptions for each user in the buddylist. Pictorially: Please view in a fixed-width font such as Courier. / / / / SUB joe / / / +----+ SUB buddies ------+/ | | ---------------| | SUB bob | | | |--------------- +----+ | | +------+ \ user \ de- \ aggregator \ SUB ralph \ \ \ \ These two cases are opposites, really. In the second case, you might want to aggregate the notifications back to the user. This would require an aggregate presence document which represents a group of users. Brian mentions this above. Its something different, and I agree out of scope for now. -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 From jdrosen@dynamicsoft.com Thu Jun 21 02:04:53 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12271 for ; Thu, 21 Jun 2001 02:04:53 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA12092; Thu, 21 Jun 2001 02:08:55 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 02:04:50 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Jonathan Rosenberg , David Simons , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Thu, 21 Jun 2001 02:04:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2811 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Monday, June 18, 2001 12:37 PM > To: Jonathan Rosenberg; David Simons; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Saturday, June 16, 2001 10:51 AM > > To: David Simons; Robert Brown; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > ... > > AUTH has also been proposed. I believe it covers the case of CPL and > > authorization data upload, but is more well defined that SETDATA or > > SERVICE. > > But AUTH _isn't_ better defined than SERVICE or SETDATA. > > As far as I can tell the semantics of AUTH are: > 1. You send an AUTH request to a URI to deliver a document to it. > 2. The type and contents of the document are arbitrary, but > are intended > for "authorization". > 3. "Authorization" is not defined but does include uploading CPL and > approving watchers of a person's own presence. > > Am I missing something? Or is AUTH more intent than spec? There is more definition than that. When a document is uploaded for some request URI foo@bar, that means that when a request arrives later on for foo@bar, the document that is uploaded provides a way to determine whether to accept, reject, or proxy the request elsewhere. Only document formats that provide a way for a server to determine what to do with a request that arrives, can be uploaded. That includes CPL and it includes a policy list of accept/rejecfts. But, it doesn't include things like HTML, JPEgs, or whatever, since they make no sense for this method definition. So, AUTH seems pretty specific. Its much more specific than SERVICE. SERVICE just means, do something, and the body says what to do. So, here are some examples of what one might try to do with service that make no sense with AUTH: 1. Send a SERVICE request asking for notifications when a stock reaches a specific value. AUTH can't do this at all, since there is no notion of a subsequent request here. 2. send a SERVICE request asking for a third party call to be set up between A and B. The body is a doc which contains the numbers for A and B. This makes no sense for AUTH, since, again, there is no subsequent request for the request URI for which some processing is done. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From Brian.Rosen@marconi.com Thu Jun 21 11:48:53 2001 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 LAA13871 for ; Thu, 21 Jun 2001 11:48:53 -0400 (EDT) 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 LAA13511; Thu, 21 Jun 2001 11:48:37 -0400 (EDT) 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 LAA07729; Thu, 21 Jun 2001 11:48:38 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 11:48:35 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655BF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Robert Osborne'" , Vasilis Polychronidis Cc: Jonathan Rosenberg , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com, Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Thu, 21 Jun 2001 11:48:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 14915 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: I have the view that I have a (potentially large) set of contacts, a subset of whom I subscribe to their presence information. It is beyond the SIMPLE charter to really deal with contacts per se, and I don't want to force any implementation to mix contacts and presentities, but I clearly want that to work, and work well. Secondly, I don't think a "buddy list" is just a simple linear list. It has structure. The issue is, of course, what is the structure. If we make buddy lists part of SIMPLE, we have to define the structure of the list. I don't think we are ready for that. So, I am leery of standardizing the concept of buddy list I think that in many cases the list is part of a larger database I think that the structure of the list is implementation dependent, we don't have enough experience to know what structures will be needed, and standardized simplistic structures tend to get in the way of future more elaborate structures Brian > -----Original Message----- > From: Robert Osborne [mailto:roberto@windows.microsoft.com] > Sent: Wednesday, June 20, 2001 11:17 PM > To: Rosen, Brian; Vasilis Polychronidis > Cc: Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel; > simple@mailman.dynamicsoft.com; Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > > I think we are discussing two different items here. As a user > I have a set of other users whose presence information I am > interested in, irrespective of which client or device I am > using. > > So when I am sitting at my desktop I am interested in the > presence information for my friends and colleagues. When I > am at home using my laptop finishing up a spec, I am still > interested in the presence information for my friends and > colleagues. Therefore as these are two different devices I > do not wish to enter in the presentity information twice, > but rather have the buddy information available no matter > which device I am using. > > As for contacts, by which I assume you mean something similar > to Outlook contacts where the address, phone number, email > etc is stored, then I partially agree that contacts and > presentities are different things. It is likely that the list > of presentities I am interested in is a subset of my contacts, > but not guaranteed. However, I am unsure what this has to do > with the fact that the presentities I am interested in should > be stored on a central SIP server, and available no matter which > device or application I am using. > > Rob O > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, June 20, 2001 5:25 AM > To: 'Vasilis Polychronidis'; Robert Osborne > Cc: Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel; > simple@mailman.dynamicsoft.com; Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > > I agree. The basic contents of the lists are probably common > (presentity), but the structure is not. Consider the standard > AOL Instant Messenger list already has a two dimensional structure, > and it is easy to imagine more elaborate structures for the lists. > As Vasilis points out, contact information and "buddy lists" may > be combined, and we aren't going to standardize contacts are we? > > In our implementation, we plan to have more information in our content > entries beyond just the presentity, so a standardized list format > would be problematic. > > It is always possible to leave the list as an XML blob, but then > I don't think anyone gets any advantage out of that. > > Brian > > > -----Original Message----- > > From: Vasilis Polychronidis > > [mailto:Vasilis.Polychronidis@Openwave.com] > > Sent: Wednesday, June 20, 2001 4:07 AM > > To: Robert Osborne > > Cc: Jonathan Rosenberg; Rosen, Brian; Sean Olson (EUS); > > Vencour Marcel; > > simple@mailman.dynamicsoft.com; Mayerhofer Andreas A > > Subject: Re: [Simple] Mobility of Buddy List > > > > > > Hi Robert, > > Please see my comments below: > > > > Kind Regards, > > > > Vasilis Polychronidis > > > > Robert Osborne wrote: > > > > > Hi, > > > > > > in your discussion of where the buddy list should be stored, you > > > state that it should be stored on a server, which makes > > sense. However > > > you state that it need NOT be stored on the presence of > > proxy server. > > > My question is, why would the buddy list not be stored on > > the presence > > > server, but be stored somewhere else? > > > > Well I think buddy lists are application specific data. > > In my IM application for example I can have a different > > contact list (buddy list) than my e-mail contact list. > > Multiple applications with different requirements will need access > > to the presence data of presentities. The grouping of > > presentities into > > contact lists is dependent on the specific application and i > > do not think > > is practical of requiring all application that want to use > > the presence > > service > > to store their contact lists to the presence server. > > > > > > > > > > > If it was, the client needs to have some additionl intelligence: > > > > > > * Which server should I connect to in order to retrieve my > > buddy list > > > * All devices would need to understand HTTP or whatever > > other protocol > > > is required > > > * Will I be able to connect to that server, because of > firewalls etc > > > > > > It seems to me that this is adding in further complexity to > > do something > > > which should be relatively simple. > > > > I do not think that is so simple. I think Contact Lists, PIMs, > > synchronization, etc. > > issues are not easy to solve in a standards based approach. > > > > > I think something similar to what > > > Sean suggests make sense and ensure that the client only > > requires some > > > minor capabilites, compared to a completely new protocol support. > > > > > > Rob O > > > > > > >-----Original Message----- > > > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > >Sent: Tuesday, June 19, 2001 9:14 AM > > > >To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; > > > >'simple@mailman.dynamicsoft.com' > > > >Cc: Mayerhofer Andreas A > > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > > > > >Hang on here... I think we are all talking about a few > > > >different things. > > > > > > > >First off, in my mind, the definition of a "buddy list" is > > the set of > > > >presentities that a particular user is subscribed to. Lets > > > >just make sure we > > > >are clear about that. Where this list is stored, and what > > happens to my > > > >subscriptions when I go offline, are two very different things. > > > > > > > >First off, where is it stored? One place is in the client. > > > >This doesn't mean > > > >that its deleted when I log off; it would presumably be stored > > > >on disk in > > > >some way. When the client app is restarted, it looks at > > that list and > > > >generates subscription refreshes for all of the users in the > > > >buddy list. > > > > > > > >The drawback of storing it on the client is that it ties you > > > >to a particular > > > >desktop. An alternative idea is to store it on a server in the > > > >network (this > > > >need NOT be the same as the presence server or proxy > > server or anything > > > >else). So, when I start my client app, it goes to a web > > > >server, say, and > > > >fetches my buddy list. Then, the client app sends a SUBSCRIBE > > > >for all of the > > > >entries there. Now, I can sit down at any machine, and log in, > > > >and then get > > > >my buddy list there. This was the motivation for our buddy > > list format > > > >proposal as part of last summer's SIMPLE proposal: > > > > > > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt > > > > > > > >In this model, the buddylist is only stored on the web server, > > > >but edited on > > > >the client. Now, if you go for the model where it can be > > > >edited on the web > > > >server as well, you run into this synchronization problem. > > > >Now, you need to > > > >keep interested entities (like my client app) aware of changes > > > >to this list > > > >that are made. There, having an event package for the "state" > > > >of my buddy > > > >list makes sense. I think this is what Sean is talking about. > > > > > > > >Now, a separate issue is what happens to my subscriptions when > > > >I go offline. > > > >Well, the nice behavior is to unSUBSCRIBE. If you don't, the > > > >presence server > > > >will eventually send a NOTIFY which either generates a 481 > > or 404, or a > > > >timeout, in which case the presence server would delete the > > > >subscription. > > > >Please note that this is totally unrelated to the state of my > > > >buddy list. > > > >This subscription is at the presence server of the presentity, > > > >whilst the > > > >buddy list is stored at a server in the domain of the > > watcher. They are > > > >totally unrelated. > > > > > > > >Brian is talking about a different model still. In this model, > > > >the buddy > > > >list isn't just stored and edited on the server, the > > server uses it to > > > >generate subscriptions directly. Effectively, the server > > becomes the > > > >watcher. If 10 people in its domain subscribe to some user > > > >bob, the server > > > >sends only one SUBSCRIBE to bob. The server can then use this > > > >to deliver > > > >notifications to the clients in its domain. The result is > > > >aggregation, in > > > >that fewer messages need to be sent out to the presentities (1 > > > >instead of 10 > > > >in the example). However, there is a serious security issue in > > > >this model, > > > >in that the presentity has no way to know the end user which > > > >is requesting > > > >the subscription. > > > > > > > >This approach, which is what I think Brian is talking about, > > > >is discussed in > > > >the original sip for presence draft: > > > > > > > > >http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt > > > > > > > >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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > >Sent: Tuesday, June 19, 2001 11:22 AM > > > >To: 'Sean Olson (EUS)'; 'Vencour Marcel'; > > > >'simple@mailman.dynamicsoft.com' > > > >Cc: Mayerhofer Andreas A > > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > > > > >You might get the LIST this way, but getting the updates may be > > > >problematic because all of your buddies may not be served > > by the same > > > >presence server. > > > > > > > >You could imagine a server proxy that would do this; the list > > > >had a full > > > >subscription info, the proxy got the individual Notifies and > > > >created one > > > >composite Notify. A mobile client might like this a lot, but > > > >it's less > > > >interesting for "well connected" clients because little > > > >aggregation occurs > > > >unless there are "popular" buddies where the proxy can use > > one Notify > > > >as input for many lists. > > > > > > > >Still, it's a worthy idea, and sounds pretty cheap. Seems > > to me the > > > >only protocol impact is that you need a composite Notify > that gets > > > >you all the presence information in the list as one message. > > > > > > > >Brian > > > >-----Original Message----- > > > >From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > > > >Sent: Tuesday, June 19, 2001 9:47 AM > > > >To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' > > > >Cc: Mayerhofer Andreas A > > > >Subject: RE: [Simple] Mobility of Buddy List > > > > > > > > > > > >I was thinking a little about this. What > > > >about the possibility of subscribing to > > > >your buddy list? The buddy list could be > > > >stored offline in, for example, a database. > > > >A SUBSCRIBE request with Event: presence.targets (?) > > > >would retrieve the static buddy list in a NOTIFY as > > > >well as subsequent updates in future NOTIFYs. > > > >The buddy list could also be tailored for the > > > >client/terminal. > > > >Comments? > > > >/sean > > > >-- > > > >Sean Olson > > > >Ericsson Inc. > > > >>-----Original Message----- > > > >>From: Vencour Marcel [mailto:marcel.vencour@siemens.at] > > > >>Sent: Tuesday, June 19, 2001 7:41 AM > > > >>To: 'simple@mailman.dynamicsoft.com' > > > >>Cc: Mayerhofer Andreas A > > > >>Subject: [Simple] Mobility of Buddy List > > > >> > > > >> > > > >>Hello everybody, > > > >> > > > >>I have a problem concerning the buddy list used in a presence > > > >>service: The > > > >>question is, where is the buddy list of the watcher stored > > > >>when the watcher > > > >>goes offline? If it is stored in a file/database at the > > > >location of the > > > >>watcher, then it is bound to the watcher's client, i.e. it > > > >>does not move > > > >>around with the watcher (here watcher means the person, not > > > >>the client used > > > >>by that person) when he uses different machines to do his > > > >>watching. Thus the > > > >>buddy list would have to be stored at the presence > > > >>server/presence agent > > > >>(PS). But in this case how can the watcher go offline without > > > >>deleting his > > > >>buddy list at the PS? If he goes offline without sending any > > > >>unsubscribe > > > >>then the PS would continue to send notifications to the > > > >>watcher which of > > > >>course is unnecessary overhead. On the other hand, if the > > > >watcher goes > > > >>offline and sends unsubscribes for all his buddies then the > > > >>buddy list would > > > >>be removed from the PS. > > > >>The next question then is, what happens when the watcher goes > > > >>online again? > > > >>How can he send a subscribe without giving a buddy in the > > > >>request line (just > > > >>to tell that he is online and thus wants to receive > > > >>notifications again)? > > > >> > > > >>Thanks in advance for an answer, M. Vencour. > > > >> > > > >>_______________________________________________ > > > >>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 hgs@cs.columbia.edu Thu Jun 21 11:54:25 2001 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 LAA13916 for ; Thu, 21 Jun 2001 11:54:25 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA17794; Thu, 21 Jun 2001 11:54:21 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA13278; Thu, 21 Jun 2001 11:54:15 -0400 (EDT) Message-ID: <3B322E02.5B8513E7@cs.columbia.edu> Date: Thu, 21 Jun 2001 10:25:22 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Vasilis Polychronidis'" , Robert Osborne , Jonathan Rosenberg , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com, Mayerhofer Andreas A Subject: Re: [Simple] Mobility of Buddy List References: <4FBEA8857476D311A03300204840E1CF04465599@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1539 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: This seems like a topic where standardization may be useful, but certainly not required. After all, we do have a standard for address books that's followed reasonably widely, namely LDIF and the underlying "Internet person object" out of LDAP. I suspect that a common interchange format may emerge that allows different applications to at least exchange (import/export) this information, as long as the major apps vendors play along. However, this would seem an appropriate topic for IMPP, not SIMPLE. It would be useful to be able to subscribe to one's address book or contact list and get (in the LDIF update format) a list of changes since the last update. I suspect that if IMPP or similar doesn't standardize this, a certain large software company will make this part of Snow breeze or whatever it's called. "Rosin, Brian" wrote: > > I agree. The basic contents of the lists are probably common > (presentity), but the structure is not. Consider the standard > AOL Instant Messenger list already has a two dimensional structure, > and it is easy to imagine more elaborate structures for the lists. > As Vasilis points out, contact information and "buddy lists" may > be combined, and we aren't going to standardize contacts are we? > > In our implementation, we plan to have more information in our content > entries beyond just the presentity, so a standardized list format > would be problematic. > > It is always possible to leave the list as an XML blob, but then > I don't think anyone gets any advantage out of that. > From Brian.Rosen@marconi.com Thu Jun 21 12:02:52 2001 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 MAA13992 for ; Thu, 21 Jun 2001 12:02:52 -0400 (EDT) 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 MAA14602; Thu, 21 Jun 2001 12:02:38 -0400 (EDT) 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 MAA11586; Thu, 21 Jun 2001 12:02:41 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 12:02:38 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655C0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" Cc: "'Vasilis Polychronidis'" , Robert Osborne , Jonathan Rosenberg , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com, Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Thu, 21 Jun 2001 12:02:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2261 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: I think that's a fine idea. I agree we wouldn't do that in SIMPLE. Do you think IMPP could actually consider it? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, June 21, 2001 1:25 PM > To: Rosen, Brian > Cc: 'Vasilis Polychronidis'; Robert Osborne; Jonathan Rosenberg; Sean > Olson (EUS); Vencour Marcel; simple@mailman.dynamicsoft.com; > Mayerhofer > Andreas A > Subject: Re: [Simple] Mobility of Buddy List > > > This seems like a topic where standardization may be useful, but > certainly not required. After all, we do have a standard for address > books that's followed reasonably widely, namely LDIF and the > underlying > "Internet person object" out of LDAP. I suspect that a common > interchange format may emerge that allows different applications to at > least exchange (import/export) this information, as long as the major > apps vendors play along. However, this would seem an appropriate topic > for IMPP, not SIMPLE. > > It would be useful to be able to subscribe to one's address book or > contact list and get (in the LDIF update format) a list of > changes since > the last update. I suspect that if IMPP or similar doesn't standardize > this, a certain large software company will make this part of Snow > breeze or whatever it's called. > > "Rosin, Brian" wrote: > > > > I agree. The basic contents of the lists are probably common > > (presentity), but the structure is not. Consider the standard > > AOL Instant Messenger list already has a two dimensional structure, > > and it is easy to imagine more elaborate structures for the lists. > > As Vasilis points out, contact information and "buddy lists" may > > be combined, and we aren't going to standardize contacts are we? > > > > In our implementation, we plan to have more information in > our content > > entries beyond just the presentity, so a standardized list format > > would be problematic. > > > > It is always possible to leave the list as an XML blob, but then > > I don't think anyone gets any advantage out of that. > > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From ssaha@lboard.com Thu Jun 21 12:31:17 2001 Received: from exmail.lboard.com (16.node.lboard.com [204.17.219.16] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14106 for ; Thu, 21 Jun 2001 12:31:16 -0400 (EDT) Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 09:30:36 -0700 Message-ID: From: Subir Saha To: "'simple@mailman.dynamicsoft.com'" Date: Thu, 21 Jun 2001 09:30:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 7682 Subject: [Simple] Centralize Presence Server... 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: Reading through the SIMPLE drafts and mailing list, it looks like a centralize presence server is not must. Even the value of such an entity is not well understood. However I see lot of vendors are working on a centralized presence server in a big way. Any comments? Subir Saha, Ph.D. Sr Product Architect LongBoard Inc. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, June 19, 2001 9:14 AM To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Hang on here... I think we are all talking about a few different things. First off, in my mind, the definition of a "buddy list" is the set of presentities that a particular user is subscribed to. Lets just make sure we are clear about that. Where this list is stored, and what happens to my subscriptions when I go offline, are two very different things. First off, where is it stored? One place is in the client. This doesn't mean that its deleted when I log off; it would presumably be stored on disk in some way. When the client app is restarted, it looks at that list and generates subscription refreshes for all of the users in the buddy list. The drawback of storing it on the client is that it ties you to a particular desktop. An alternative idea is to store it on a server in the network (this need NOT be the same as the presence server or proxy server or anything else). So, when I start my client app, it goes to a web server, say, and fetches my buddy list. Then, the client app sends a SUBSCRIBE for all of the entries there. Now, I can sit down at any machine, and log in, and then get my buddy list there. This was the motivation for our buddy list format proposal as part of last summer's SIMPLE proposal: http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt In this model, the buddylist is only stored on the web server, but edited on the client. Now, if you go for the model where it can be edited on the web server as well, you run into this synchronization problem. Now, you need to keep interested entities (like my client app) aware of changes to this list that are made. There, having an event package for the "state" of my buddy list makes sense. I think this is what Sean is talking about. Now, a separate issue is what happens to my subscriptions when I go offline. Well, the nice behavior is to unSUBSCRIBE. If you don't, the presence server will eventually send a NOTIFY which either generates a 481 or 404, or a timeout, in which case the presence server would delete the subscription. Please note that this is totally unrelated to the state of my buddy list. This subscription is at the presence server of the presentity, whilst the buddy list is stored at a server in the domain of the watcher. They are totally unrelated. Brian is talking about a different model still. In this model, the buddy list isn't just stored and edited on the server, the server uses it to generate subscriptions directly. Effectively, the server becomes the watcher. If 10 people in its domain subscribe to some user bob, the server sends only one SUBSCRIBE to bob. The server can then use this to deliver notifications to the clients in its domain. The result is aggregation, in that fewer messages need to be sent out to the presentities (1 instead of 10 in the example). However, there is a serious security issue in this model, in that the presentity has no way to know the end user which is requesting the subscription. This approach, which is what I think Brian is talking about, is discussed in the original sip for presence draft: http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, June 19, 2001 11:22 AM To: 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List You might get the LIST this way, but getting the updates may be problematic because all of your buddies may not be served by the same presence server. You could imagine a server proxy that would do this; the list had a full subscription info, the proxy got the individual Notifies and created one composite Notify. A mobile client might like this a lot, but it's less interesting for "well connected" clients because little aggregation occurs unless there are "popular" buddies where the proxy can use one Notify as input for many lists. Still, it's a worthy idea, and sounds pretty cheap. Seems to me the only protocol impact is that you need a composite Notify that gets you all the presence information in the list as one message. Brian -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Tuesday, June 19, 2001 9:47 AM To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List I was thinking a little about this. What about the possibility of subscribing to your buddy list? The buddy list could be stored offline in, for example, a database. A SUBSCRIBE request with Event: presence.targets (?) would retrieve the static buddy list in a NOTIFY as well as subsequent updates in future NOTIFYs. The buddy list could also be tailored for the client/terminal. Comments? /sean -- Sean Olson Ericsson Inc. >-----Original Message----- >From: Vencour Marcel [mailto:marcel.vencour@siemens.at] >Sent: Tuesday, June 19, 2001 7:41 AM >To: 'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: [Simple] Mobility of Buddy List > > >Hello everybody, > >I have a problem concerning the buddy list used in a presence >service: The >question is, where is the buddy list of the watcher stored >when the watcher >goes offline? If it is stored in a file/database at the location of the >watcher, then it is bound to the watcher's client, i.e. it >does not move >around with the watcher (here watcher means the person, not >the client used >by that person) when he uses different machines to do his >watching. Thus the >buddy list would have to be stored at the presence >server/presence agent >(PS). But in this case how can the watcher go offline without >deleting his >buddy list at the PS? If he goes offline without sending any >unsubscribe >then the PS would continue to send notifications to the >watcher which of >course is unnecessary overhead. On the other hand, if the watcher goes >offline and sends unsubscribes for all his buddies then the >buddy list would >be removed from the PS. >The next question then is, what happens when the watcher goes >online again? >How can he send a subscribe without giving a buddy in the >request line (just >to tell that he is online and thus wants to receive >notifications again)? > >Thanks in advance for an answer, M. Vencour. > >_______________________________________________ >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 sean.olson@ericsson.com Thu Jun 21 14:31:18 2001 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 OAA14437 for ; Thu, 21 Jun 2001 14:31:17 -0400 (EDT) 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 f5LIVGa25039 for ; Thu, 21 Jun 2001 13:31:16 -0500 (CDT) 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 f5LIVGn22033 for ; Thu, 21 Jun 2001 13:31:16 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jun 21 13:30:35 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 13:30:35 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Rosen, Brian'" , "'Robert Osborne'" , Vasilis Polychronidis Cc: Jonathan Rosenberg , Vencour Marcel , simple@mailman.dynamicsoft.com, Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Thu, 21 Jun 2001 13:30:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA80.421C4240" Content-Length: 2493 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: 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_01C0FA80.421C4240 Content-Type: text/plain; charset="iso-8859-1" > If we have a common buddy list, what you get is the ability for a watcher to > switch clients. That is not the problem you are worried about - you want > any client to be able to see presence information for buddies who have their > own choice of clients. Specifying a buddy list format won't help that. Actually, this is exactly the problem I am looking to solve. I want to be able to access the same buddy list from a wireless handset, my PDA, my laptop, my desktop at work, my SIP "PBX", etc. I realize this may not be interesting for everyone. I certainly don't expect this to be a mandatory part of SIMPLE. I would just like to explore the idea of a simple buddy list format (perhaps in IMPP as Henning has suggested) /sean ------_=_NextPart_001_01C0FA80.421C4240 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Mobility of Buddy List

> If we have a common buddy list, what you get is the ability for a watcher to
> switch clients.  That is not the problem you are worried about - you want
> any client to be able to see presence information for buddies who have their
> own choice of clients.  Specifying a buddy list format won't help that.

Actually, this is exactly the problem I am looking to solve.
I want to be able to access the same buddy list from a
wireless handset, my PDA, my laptop, my desktop at work,
my SIP "PBX", etc.  I realize this may not be interesting
for everyone. I certainly don't expect this to be a
mandatory part of SIMPLE. I would just like to explore
the idea of a simple buddy list format (perhaps in IMPP
as Henning has suggested)

/sean

------_=_NextPart_001_01C0FA80.421C4240-- From zmolek@avaya.com Thu Jun 21 14:36:04 2001 Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14480 for ; Thu, 21 Jun 2001 14:36:03 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28005 for ; Thu, 21 Jun 2001 14:35:08 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27992 for ; Thu, 21 Jun 2001 14:35:07 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA81.06B8D2F8" Subject: RE: [Simple] Centralize Presence Server... X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Thu, 21 Jun 2001 12:36:03 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Centralize Presence Server... Thread-Index: AcD6b9JlbLCeORjiSWCm9LTRntWvmAAD/FzQ From: "Zmolek, Andrew (Andrew)" To: "Subir Saha" , Content-Length: 24974 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0FA81.06B8D2F8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Initial implementations for simplicity's sake may use a single centralized presence server. The longer-term reality will be closer to domains of presence information with the possibility for multiple aggregators and distributors even within a given domain. There are a lot of possible topologies for the flow of presence information and the centralized model is only one of them. When a critical mass of presence service information is available, things will get decentralized in a hurry. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Subir Saha [mailto:ssaha@lboard.com] Sent: Thursday, June 21, 2001 10:30 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] Centralize Presence Server... Reading through the SIMPLE drafts and mailing list, it looks like a centralize presence server is not must. Even the value of such an entity is not well understood. However I see lot of vendors are working on a centralized presence server in a big way.=20 Any comments? Subir Saha, Ph.D. Sr Product Architect LongBoard Inc. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, June 19, 2001 9:14 AM To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Hang on here... I think we are all talking about a few different things. First off, in my mind, the definition of a "buddy list" is the set of presentities that a particular user is subscribed to. Lets just make sure we are clear about that. Where this list is stored, and what happens to my subscriptions when I go offline, are two very different things. First off, where is it stored? One place is in the client. This doesn't mean that its deleted when I log off; it would presumably be stored on disk in some way. When the client app is restarted, it looks at that list and generates subscription refreshes for all of the users in the buddy list. The drawback of storing it on the client is that it ties you to a particular desktop. An alternative idea is to store it on a server in the network (this need NOT be the same as the presence server or proxy server or anything else). So, when I start my client app, it goes to a web server, say, and fetches my buddy list. Then, the client app sends a SUBSCRIBE for all of the entries there. Now, I can sit down at any machine, and log in, and then get my buddy list there. This was the motivation for our buddy list format proposal as part of last summer's SIMPLE proposal: http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt In this model, the buddylist is only stored on the web server, but edited on the client. Now, if you go for the model where it can be edited on the web server as well, you run into this synchronization problem. Now, you need to keep interested entities (like my client app) aware of changes to this list that are made. There, having an event package for the "state" of my buddy list makes sense. I think this is what Sean is talking about. Now, a separate issue is what happens to my subscriptions when I go offline. Well, the nice behavior is to unSUBSCRIBE. If you don't, the presence server will eventually send a NOTIFY which either generates a 481 or 404, or a timeout, in which case the presence server would delete the subscription. Please note that this is totally unrelated to the state of my buddy list. This subscription is at the presence server of the presentity, whilst the buddy list is stored at a server in the domain of the watcher. They are totally unrelated. Brian is talking about a different model still. In this model, the buddy list isn't just stored and edited on the server, the server uses it to generate subscriptions directly. Effectively, the server becomes the watcher. If 10 people in its domain subscribe to some user bob, the server sends only one SUBSCRIBE to bob. The server can then use this to deliver notifications to the clients in its domain. The result is aggregation, in that fewer messages need to be sent out to the presentities (1 instead of 10 in the example). However, there is a serious security issue in this model, in that the presentity has no way to know the end user which is requesting the subscription. This approach, which is what I think Brian is talking about, is discussed in the original sip for presence draft: http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt 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 =20 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, June 19, 2001 11:22 AM To: 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List You might get the LIST this way, but getting the updates may be problematic because all of your buddies may not be served by the same presence server. You could imagine a server proxy that would do this; the list had a full subscription info, the proxy got the individual Notifies and created one composite Notify. A mobile client might like this a lot, but it's less=20 interesting for "well connected" clients because little aggregation occurs unless there are "popular" buddies where the proxy can use one Notify as input for many lists. Still, it's a worthy idea, and sounds pretty cheap. Seems to me the only protocol impact is that you need a composite Notify that gets you all the presence information in the list as one message. Brian -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Tuesday, June 19, 2001 9:47 AM To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List I was thinking a little about this. What=20 about the possibility of subscribing to=20 your buddy list? The buddy list could be=20 stored offline in, for example, a database.=20 A SUBSCRIBE request with Event: presence.targets (?)=20 would retrieve the static buddy list in a NOTIFY as=20 well as subsequent updates in future NOTIFYs.=20 The buddy list could also be tailored for the=20 client/terminal.=20 Comments?=20 /sean=20 --=20 Sean Olson =20 Ericsson Inc.=20 >-----Original Message-----=20 >From: Vencour Marcel [mailto:marcel.vencour@siemens.at]=20 >Sent: Tuesday, June 19, 2001 7:41 AM=20 >To: 'simple@mailman.dynamicsoft.com'=20 >Cc: Mayerhofer Andreas A=20 >Subject: [Simple] Mobility of Buddy List=20 >=20 >=20 >Hello everybody,=20 >=20 >I have a problem concerning the buddy list used in a presence=20 >service: The=20 >question is, where is the buddy list of the watcher stored=20 >when the watcher=20 >goes offline? If it is stored in a file/database at the location of the >watcher, then it is bound to the watcher's client, i.e. it=20 >does not move=20 >around with the watcher (here watcher means the person, not=20 >the client used=20 >by that person) when he uses different machines to do his=20 >watching. Thus the=20 >buddy list would have to be stored at the presence=20 >server/presence agent=20 >(PS). But in this case how can the watcher go offline without=20 >deleting his=20 >buddy list at the PS? If he goes offline without sending any=20 >unsubscribe=20 >then the PS would continue to send notifications to the=20 >watcher which of=20 >course is unnecessary overhead. On the other hand, if the watcher goes=20 >offline and sends unsubscribes for all his buddies then the=20 >buddy list would=20 >be removed from the PS.=20 >The next question then is, what happens when the watcher goes=20 >online again?=20 >How can he send a subscribe without giving a buddy in the=20 >request line (just=20 >to tell that he is online and thus wants to receive=20 >notifications again)?=20 >=20 >Thanks in advance for an answer, M. Vencour.=20 >=20 >_______________________________________________=20 >simple mailing list=20 >simple@mailman.dynamicsoft.com=20 >http://mailman.dynamicsoft.com/mailman/listinfo/simple=20 >=20 _______________________________________________ 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_01C0FA81.06B8D2F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Centralize Presence Server...

Initial implementations for simplicity's sake may use = a single centralized presence server. The longer-term reality will be = closer to domains of presence information with the possibility for = multiple aggregators and distributors even within a given domain. There = are a lot of possible topologies for the flow of presence information = and the centralized model is only one of them. When a critical mass of = presence service information is available, things will get decentralized = in a hurry.

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001


-----Original Message-----
From: Subir Saha [mailto:ssaha@lboard.com]
Sent: Thursday, June 21, 2001 10:30 AM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] Centralize Presence = Server...


Reading through the SIMPLE drafts and mailing list, it = looks like a
centralize presence server is not must. Even the = value of such an entity is
not well understood. However I see lot of vendors are = working on a
centralized presence server in a big way.
Any comments?

Subir Saha, Ph.D.
Sr Product Architect
LongBoard Inc.



-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, June 19, 2001 9:14 AM
To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour = Marcel';
'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List


Hang on here... I think we are all talking about a few = different things.

First off, in my mind, the definition of a "buddy = list" is the set of
presentities that a particular user is subscribed to. = Lets just make sure we
are clear about that. Where this list is stored, and = what happens to my
subscriptions when I go offline, are two very = different things.

First off, where is it stored? One place is in the = client. This doesn't mean
that its deleted when I log off; it would presumably = be stored on disk in
some way. When the client app is restarted, it looks = at that list and
generates subscription refreshes for all of the users = in the buddy list.

The drawback of storing it on the client is that it = ties you to a particular
desktop. An alternative idea is to store it on a = server in the network (this
need NOT be the same as the presence server or proxy = server or anything
else). So, when I start my client app, it goes to a = web server, say, and
fetches my buddy list. Then, the client app sends a = SUBSCRIBE for all of the
entries there. Now, I can sit down at any machine, = and log in, and then get
my buddy list there. This was the motivation for our = buddy list format
proposal as part of last summer's SIMPLE = proposal:

http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt

In this model, the buddylist is only stored on the web = server, but edited on
the client. Now, if you go for the model where it can = be edited on the web
server as well, you run into this synchronization = problem. Now, you need to
keep interested entities (like my client app) aware = of changes to this list
that are made. There, having an event package for the = "state" of my buddy
list makes sense. I think this is what Sean is = talking about.

Now, a separate issue is what happens to my = subscriptions when I go offline.
Well, the nice behavior is to unSUBSCRIBE. If you = don't, the presence server
will eventually send a NOTIFY which either generates = a 481 or 404, or a
timeout, in which case the presence server would = delete the subscription.
Please note that this is totally unrelated to the = state of my buddy list.
This subscription is at the presence server of the = presentity, whilst the
buddy list is stored at a server in the domain of the = watcher. They are
totally unrelated.

Brian is talking about a different model still. In = this model, the buddy
list isn't just stored and edited on the server, the = server uses it to
generate subscriptions directly. Effectively, the = server becomes the
watcher. If 10 people in its domain subscribe to some = user bob, the server
sends only one SUBSCRIBE to bob. The server can then = use this to deliver
notifications to the clients in its domain. The = result is aggregation, in
that fewer messages need to be sent out to the = presentities (1 instead of 10
in the example). However, there is a serious security = issue in this model,
in that the presentity has no way to know the end = user which is requesting
the subscription.

This approach, which is what I think Brian is talking = about, is discussed in
the original sip for presence draft:

http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt=

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, = Ph.D.           &n= bsp;    72 Eagle Rock Ave.
Chief = Scientist          &nbs= p;            = ;      First Floor
dynamicsoft         = ;            =             East = Hanover, NJ 07936
jdrosen@dynamicsoft.com       = ;            =   FAX:   (973) 952-5050
http://www.jdrosen.net  &nb= sp;           &nbs= p;       PHONE: (973) 952-5000
http://www.dynamicsoft.com=
 
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, June 19, 2001 11:22 AM
To: 'Sean Olson (EUS)'; 'Vencour Marcel'; = 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List


You might get the LIST this way, but getting the = updates may be
problematic because all of your buddies may not be = served by the same
presence server.

You could imagine a server proxy that would do this; = the list had a full
subscription info, the proxy got the individual = Notifies and created one
composite Notify.  A mobile client might like = this a lot, but it's less
interesting for "well connected" clients = because little aggregation occurs
unless there are "popular" buddies where = the proxy can use one Notify
as input for many lists.

Still, it's a worthy idea, and sounds pretty = cheap.  Seems to me the
only protocol impact is that you need a composite = Notify that gets
you all the presence information in the list as one = message.

Brian
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Tuesday, June 19, 2001 9:47 AM
To: 'Vencour Marcel'; = 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List


I was thinking a little about this. What
about the possibility of subscribing to
your buddy list? The buddy list could be
stored offline in, for example, a database.
A SUBSCRIBE request with Event: presence.targets (?) =
would retrieve the static buddy list in a NOTIFY as =
well as subsequent updates in future NOTIFYs.
The buddy list could also be tailored for the
client/terminal.
Comments?
/sean
--
Sean Olson <sean.olson@ericsson.com>
Ericsson Inc.
>-----Original Message-----
>From: Vencour Marcel [mailto:marcel.vencour@siemens.a= t]
>Sent: Tuesday, June 19, 2001 7:41 AM
>To: 'simple@mailman.dynamicsoft.com'
>Cc: Mayerhofer Andreas A
>Subject: [Simple] Mobility of Buddy List
>
>
>Hello everybody,
>
>I have a problem concerning the buddy list used = in a presence
>service: The
>question is, where is the buddy list of the = watcher stored
>when the watcher
>goes offline? If it is stored in a file/database = at the location of the
>watcher, then it is bound to the watcher's = client, i.e. it
>does not move
>around with the watcher (here watcher means the = person, not
>the client used
>by that person) when he uses different machines = to do his
>watching. Thus the
>buddy list would have to be stored at the = presence
>server/presence agent
>(PS). But in this case how can the watcher go = offline without
>deleting his
>buddy list at the PS? If he goes offline without = sending any
>unsubscribe
>then the PS would continue to send notifications = to the
>watcher which of
>course is unnecessary overhead. On the other = hand, if the watcher goes
>offline and sends unsubscribes for all his = buddies then the
>buddy list would
>be removed from the PS.
>The next question then is, what happens when the = watcher goes
>online again?
>How can he send a subscribe without giving a = buddy in the
>request line (just
>to tell that he is online and thus wants to = receive
>notifications again)?
>
>Thanks in advance for an answer, M. Vencour. =
>
>_______________________________________________ =
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple
>
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple

------_=_NextPart_001_01C0FA81.06B8D2F8-- From Brian.Rosen@marconi.com Thu Jun 21 14:45:55 2001 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 OAA14556 for ; Thu, 21 Jun 2001 14:45:54 -0400 (EDT) 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 OAA27746; Thu, 21 Jun 2001 14:45:35 -0400 (EDT) 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 OAA21199; Thu, 21 Jun 2001 14:45:39 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Jun 2001 14:45:36 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655CF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sean Olson (EUS)'" , "'Robert Osborne'" , Vasilis Polychronidis Cc: Jonathan Rosenberg , Vencour Marcel , simple@mailman.dynamicsoft.com, Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Thu, 21 Jun 2001 14:45:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FA82.5B61C340" Content-Length: 5095 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: 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_01C0FA82.5B61C340 Content-Type: text/plain; charset="iso-8859-1" Well, I surely agree that if anything is done, it's an interchange issue, and therefore has to be done in IMPP and not SIMPLE. I was okay with what Henning proposed, as long as the information is structured so that extensions are easy. If you want to infer a buddy list from that, I wouldn't actually have a problem. It will be interesting to see how your various clients deal with our LDIF. Brian -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Thursday, June 21, 2001 2:31 PM To: 'Rosen, Brian'; 'Robert Osborne'; Vasilis Polychronidis Cc: Jonathan Rosenberg; Vencour Marcel; simple@mailman.dynamicsoft.com; Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List > If we have a common buddy list, what you get is the ability for a watcher to > switch clients. That is not the problem you are worried about - you want > any client to be able to see presence information for buddies who have their > own choice of clients. Specifying a buddy list format won't help that. Actually, this is exactly the problem I am looking to solve. I want to be able to access the same buddy list from a wireless handset, my PDA, my laptop, my desktop at work, my SIP "PBX", etc. I realize this may not be interesting for everyone. I certainly don't expect this to be a mandatory part of SIMPLE. I would just like to explore the idea of a simple buddy list format (perhaps in IMPP as Henning has suggested) /sean ------_=_NextPart_001_01C0FA82.5B61C340 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Mobility of Buddy List
Well, I surely agree that if anything is done, it's an interchange issue, and therefore
has to be done in IMPP and not SIMPLE.
 
I was okay with what Henning proposed, as long as the information is structured
so that extensions are easy.  If you want to infer a buddy list from that, I wouldn't
actually have a problem.  It will be interesting to see how your various clients
deal with our LDIF. 
 
Brian
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Thursday, June 21, 2001 2:31 PM
To: 'Rosen, Brian'; 'Robert Osborne'; Vasilis Polychronidis
Cc: Jonathan Rosenberg; Vencour Marcel; simple@mailman.dynamicsoft.com; Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List

> If we have a common buddy list, what you get is the ability for a watcher to
> switch clients.  That is not the problem you are worried about - you want
> any client to be able to see presence information for buddies who have their
> own choice of clients.  Specifying a buddy list format won't help that.

Actually, this is exactly the problem I am looking to solve.
I want to be able to access the same buddy list from a
wireless handset, my PDA, my laptop, my desktop at work,
my SIP "PBX", etc.  I realize this may not be interesting
for everyone. I certainly don't expect this to be a
mandatory part of SIMPLE. I would just like to explore
the idea of a simple buddy list format (perhaps in IMPP
as Henning has suggested)

/sean

------_=_NextPart_001_01C0FA82.5B61C340-- From theodore.havinis@openwave.com Thu Jun 21 16:24:18 2001 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 QAA14847 for ; Thu, 21 Jun 2001 16:24:17 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010621202310.BFBY27103.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 21 Jun 2001 15:23:10 -0500 Received: from harviniT ([206.35.147.89]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with SMTP id <20010621202414.QDIJ10980.oe-ismta1.bizmailsrvcs.net@harviniT>; Thu, 21 Jun 2001 15:24:14 -0500 From: "Theodore Havinis" To: "Vencour Marcel" , Subject: RE: [Simple] Mobility of Buddy List Date: Thu, 21 Jun 2001 13:25:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Content-Length: 3144 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: Hi Vencour, I don't think we should mix the presence service and its services (provide notification of state changes) with the capabilities of a specific application that helps you create a buddy-list and potentially may also support 'reachability/mobility' capabilities which will mean that you will beb able to access the 'buddy list' from any device. To give you an example of what I mean, I don't believe that you need to have presence service to have IM. Presence is an *enhancement* to IM. Likewise, reachability/mobility is an *enhanacement* to IM. Thus, its the application's capability to provide you with a reachability/mobility *service* that helps you access your 'buddies' anywhere from any device and *not* the presence service's responsibility. (Please I want to avoid to get into mobility issues here ie whether it's better to handle it at application layer or lower layer...) So, I tend to believe, that your question its a mobility/reachability issue which means it should be addressed either at an IETF SIP/MobileIP group, but also its a pure application issue ie how the particular application is proposing to handle reachability/mobility and thus 3GPP/3GPP2 may also be suitable since they are providing generic solutions. Of course if 'buddy list' is an extension to IMPP then it should also be addressed there. Kind Rgrds, Theo TH>-----Original Message----- TH>From: simple-admin@mailman.dynamicsoft.com TH>[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Vencour Marcel TH>Sent: Tuesday, June 19, 2001 5:41 AM TH>To: 'simple@mailman.dynamicsoft.com' TH>Cc: Mayerhofer Andreas A TH>Subject: [Simple] Mobility of Buddy List TH> TH> TH>Hello everybody, TH> TH>I have a problem concerning the buddy list used in a presence TH>service: The TH>question is, where is the buddy list of the watcher stored when TH>the watcher TH>goes offline? If it is stored in a file/database at the location of the TH>watcher, then it is bound to the watcher's client, i.e. it does not move TH>around with the watcher (here watcher means the person, not the TH>client used TH>by that person) when he uses different machines to do his TH>watching. Thus the TH>buddy list would have to be stored at the presence server/presence agent TH>(PS). But in this case how can the watcher go offline without TH>deleting his TH>buddy list at the PS? If he goes offline without sending any unsubscribe TH>then the PS would continue to send notifications to the watcher which of TH>course is unnecessary overhead. On the other hand, if the watcher goes TH>offline and sends unsubscribes for all his buddies then the TH>buddy list would TH>be removed from the PS. TH>The next question then is, what happens when the watcher goes TH>online again? TH>How can he send a subscribe without giving a buddy in the TH>request line (just TH>to tell that he is online and thus wants to receive notifications again)? TH> TH>Thanks in advance for an answer, M. Vencour. TH> TH>_______________________________________________ TH>simple mailing list TH>simple@mailman.dynamicsoft.com TH>http://mailman.dynamicsoft.com/mailman/listinfo/simple TH> From Diana.Rawlins@wcom.com Thu Jun 21 18:52:59 2001 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 SAA15274 for ; Thu, 21 Jun 2001 18:52:59 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GFA00792Y892R@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Thu, 21 Jun 2001 22:52:58 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GFA00M01Y89JJ@pmismtp01.wcomnet.com>; Thu, 21 Jun 2001 22:52:57 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GFA00IB9Y7UQ7@pmismtp01.wcomnet.com>; Thu, 21 Jun 2001 22:52:42 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jun 2001 22:52:41 +0000 Content-return: allowed Date: Thu, 21 Jun 2001 22:52:40 +0000 From: "Rawlins, Diana" Subject: RE: [Simple] Centralize Presence Server... To: "'Zmolek, Andrew (Andrew)'" , Subir Saha , simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E31AA80@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_JMX3wyWGnX0TLDy+F/qx6Q)" Content-Length: 27259 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: 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_JMX3wyWGnX0TLDy+F/qx6Q) Content-type: text/plain; charset=ISO-8859-1 A nice feature of a presence server is that it helps scales mobility scenarios and permits a single user oriented uri to be used to locate the presentity's actual contact address. For example, one day I "present myself" on my PDA and the next I may register and "present" my presence application from a desktop with an entirely different contact address. The presence server accepts the subscribe from the watcher addressed to the user and when the presentity for the user become available the contact address information is used by the presence server to facilitate the exchange of presence data between the watcher and presentity --- authorization and access being a prerequisite for the presence exchange. -Diana -----Original Message----- From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] Sent: Thursday, June 21, 2001 1:36 PM To: Subir Saha; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Centralize Presence Server... Initial implementations for simplicity's sake may use a single centralized presence server. The longer-term reality will be closer to domains of presence information with the possibility for multiple aggregators and distributors even within a given domain. There are a lot of possible topologies for the flow of presence information and the centralized model is only one of them. When a critical mass of presence service information is available, things will get decentralized in a hurry. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Subir Saha [ mailto:ssaha@lboard.com ] Sent: Thursday, June 21, 2001 10:30 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] Centralize Presence Server... Reading through the SIMPLE drafts and mailing list, it looks like a centralize presence server is not must. Even the value of such an entity is not well understood. However I see lot of vendors are working on a centralized presence server in a big way. Any comments? Subir Saha, Ph.D. Sr Product Architect LongBoard Inc. -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Tuesday, June 19, 2001 9:14 AM To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Hang on here... I think we are all talking about a few different things. First off, in my mind, the definition of a "buddy list" is the set of presentities that a particular user is subscribed to. Lets just make sure we are clear about that. Where this list is stored, and what happens to my subscriptions when I go offline, are two very different things. First off, where is it stored? One place is in the client. This doesn't mean that its deleted when I log off; it would presumably be stored on disk in some way. When the client app is restarted, it looks at that list and generates subscription refreshes for all of the users in the buddy list. The drawback of storing it on the client is that it ties you to a particular desktop. An alternative idea is to store it on a server in the network (this need NOT be the same as the presence server or proxy server or anything else). So, when I start my client app, it goes to a web server, say, and fetches my buddy list. Then, the client app sends a SUBSCRIBE for all of the entries there. Now, I can sit down at any machine, and log in, and then get my buddy list there. This was the motivation for our buddy list format proposal as part of last summer's SIMPLE proposal: http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt In this model, the buddylist is only stored on the web server, but edited on the client. Now, if you go for the model where it can be edited on the web server as well, you run into this synchronization problem. Now, you need to keep interested entities (like my client app) aware of changes to this list that are made. There, having an event package for the "state" of my buddy list makes sense. I think this is what Sean is talking about. Now, a separate issue is what happens to my subscriptions when I go offline. Well, the nice behavior is to unSUBSCRIBE. If you don't, the presence server will eventually send a NOTIFY which either generates a 481 or 404, or a timeout, in which case the presence server would delete the subscription. Please note that this is totally unrelated to the state of my buddy list. This subscription is at the presence server of the presentity, whilst the buddy list is stored at a server in the domain of the watcher. They are totally unrelated. Brian is talking about a different model still. In this model, the buddy list isn't just stored and edited on the server, the server uses it to generate subscriptions directly. Effectively, the server becomes the watcher. If 10 people in its domain subscribe to some user bob, the server sends only one SUBSCRIBE to bob. The server can then use this to deliver notifications to the clients in its domain. The result is aggregation, in that fewer messages need to be sent out to the presentities (1 instead of 10 in the example). However, there is a serious security issue in this model, in that the presentity has no way to know the end user which is requesting the subscription. This approach, which is what I think Brian is talking about, is discussed in the original sip for presence draft: http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt 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: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] Sent: Tuesday, June 19, 2001 11:22 AM To: 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List You might get the LIST this way, but getting the updates may be problematic because all of your buddies may not be served by the same presence server. You could imagine a server proxy that would do this; the list had a full subscription info, the proxy got the individual Notifies and created one composite Notify. A mobile client might like this a lot, but it's less interesting for "well connected" clients because little aggregation occurs unless there are "popular" buddies where the proxy can use one Notify as input for many lists. Still, it's a worthy idea, and sounds pretty cheap. Seems to me the only protocol impact is that you need a composite Notify that gets you all the presence information in the list as one message. Brian -----Original Message----- From: Sean Olson (EUS) [ mailto:sean.olson@ericsson.com ] Sent: Tuesday, June 19, 2001 9:47 AM To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List I was thinking a little about this. What about the possibility of subscribing to your buddy list? The buddy list could be stored offline in, for example, a database. A SUBSCRIBE request with Event: presence.targets (?) would retrieve the static buddy list in a NOTIFY as well as subsequent updates in future NOTIFYs. The buddy list could also be tailored for the client/terminal. Comments? /sean -- Sean Olson Ericsson Inc. >-----Original Message----- >From: Vencour Marcel [ mailto:marcel.vencour@siemens.at ] >Sent: Tuesday, June 19, 2001 7:41 AM >To: 'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: [Simple] Mobility of Buddy List > > >Hello everybody, > >I have a problem concerning the buddy list used in a presence >service: The >question is, where is the buddy list of the watcher stored >when the watcher >goes offline? If it is stored in a file/database at the location of the >watcher, then it is bound to the watcher's client, i.e. it >does not move >around with the watcher (here watcher means the person, not >the client used >by that person) when he uses different machines to do his >watching. Thus the >buddy list would have to be stored at the presence >server/presence agent >(PS). But in this case how can the watcher go offline without >deleting his >buddy list at the PS? If he goes offline without sending any >unsubscribe >then the PS would continue to send notifications to the >watcher which of >course is unnecessary overhead. On the other hand, if the watcher goes >offline and sends unsubscribes for all his buddies then the >buddy list would >be removed from the PS. >The next question then is, what happens when the watcher goes >online again? >How can he send a subscribe without giving a buddy in the >request line (just >to tell that he is online and thus wants to receive >notifications again)? > >Thanks in advance for an answer, M. Vencour. > >_______________________________________________ >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 --Boundary_(ID_JMX3wyWGnX0TLDy+F/qx6Q) Content-type: text/html; charset=ISO-8859-1 RE: [Simple] Centralize Presence Server...
A nice feature of a presence server is that it helps scales mobility scenarios and permits a single user oriented uri to be used to locate the presentity's actual contact address. For example, one day I  "present myself" on my PDA and the next I may register and "present" my  presence application from a desktop with an entirely different contact address. The presence server accepts the subscribe from the watcher addressed to the user and when the presentity for the user become available the contact address information is used by the presence server to facilitate the exchange of presence data between the watcher and presentity --- authorization and access being a prerequisite for the presence exchange.
 
-Diana
 
-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]
Sent: Thursday, June 21, 2001 1:36 PM
To: Subir Saha; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Centralize Presence Server...

Initial implementations for simplicity's sake may use a single centralized presence server. The longer-term reality will be closer to domains of presence information with the possibility for multiple aggregators and distributors even within a given domain. There are a lot of possible topologies for the flow of presence information and the centralized model is only one of them. When a critical mass of presence service information is available, things will get decentralized in a hurry.

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            zmolek@avaya.com
              +1 720 444 4001


-----Original Message-----
From: Subir Saha [mailto:ssaha@lboard.com]
Sent: Thursday, June 21, 2001 10:30 AM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] Centralize Presence Server...


Reading through the SIMPLE drafts and mailing list, it looks like a
centralize presence server is not must. Even the value of such an entity is
not well understood. However I see lot of vendors are working on a
centralized presence server in a big way.
Any comments?

Subir Saha, Ph.D.
Sr Product Architect
LongBoard Inc.



-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, June 19, 2001 9:14 AM
To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel';
'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List


Hang on here... I think we are all talking about a few different things.

First off, in my mind, the definition of a "buddy list" is the set of
presentities that a particular user is subscribed to. Lets just make sure we
are clear about that. Where this list is stored, and what happens to my
subscriptions when I go offline, are two very different things.

First off, where is it stored? One place is in the client. This doesn't mean
that its deleted when I log off; it would presumably be stored on disk in
some way. When the client app is restarted, it looks at that list and
generates subscription refreshes for all of the users in the buddy list.

The drawback of storing it on the client is that it ties you to a particular
desktop. An alternative idea is to store it on a server in the network (this
need NOT be the same as the presence server or proxy server or anything
else). So, when I start my client app, it goes to a web server, say, and
fetches my buddy list. Then, the client app sends a SUBSCRIBE for all of the
entries there. Now, I can sit down at any machine, and log in, and then get
my buddy list there. This was the motivation for our buddy list format
proposal as part of last summer's SIMPLE proposal:

http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt

In this model, the buddylist is only stored on the web server, but edited on
the client. Now, if you go for the model where it can be edited on the web
server as well, you run into this synchronization problem. Now, you need to
keep interested entities (like my client app) aware of changes to this list
that are made. There, having an event package for the "state" of my buddy
list makes sense. I think this is what Sean is talking about.

Now, a separate issue is what happens to my subscriptions when I go offline.
Well, the nice behavior is to unSUBSCRIBE. If you don't, the presence server
will eventually send a NOTIFY which either generates a 481 or 404, or a
timeout, in which case the presence server would delete the subscription.
Please note that this is totally unrelated to the state of my buddy list.
This subscription is at the presence server of the presentity, whilst the
buddy list is stored at a server in the domain of the watcher. They are
totally unrelated.

Brian is talking about a different model still. In this model, the buddy
list isn't just stored and edited on the server, the server uses it to
generate subscriptions directly. Effectively, the server becomes the
watcher. If 10 people in its domain subscribe to some user bob, the server
sends only one SUBSCRIBE to bob. The server can then use this to deliver
notifications to the clients in its domain. The result is aggregation, in
that fewer messages need to be sent out to the presentities (1 instead of 10
in the example). However, there is a serious security issue in this model,
in that the presentity has no way to know the end user which is requesting
the subscription.

This approach, which is what I think Brian is talking about, is discussed in
the original sip for presence draft:

http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt

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: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, June 19, 2001 11:22 AM
To: 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List


You might get the LIST this way, but getting the updates may be
problematic because all of your buddies may not be served by the same
presence server.

You could imagine a server proxy that would do this; the list had a full
subscription info, the proxy got the individual Notifies and created one
composite Notify.  A mobile client might like this a lot, but it's less
interesting for "well connected" clients because little aggregation occurs
unless there are "popular" buddies where the proxy can use one Notify
as input for many lists.

Still, it's a worthy idea, and sounds pretty cheap.  Seems to me the
only protocol impact is that you need a composite Notify that gets
you all the presence information in the list as one message.

Brian
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Tuesday, June 19, 2001 9:47 AM
To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List


I was thinking a little about this. What
about the possibility of subscribing to
your buddy list? The buddy list could be
stored offline in, for example, a database.
A SUBSCRIBE request with Event: presence.targets (?)
would retrieve the static buddy list in a NOTIFY as
well as subsequent updates in future NOTIFYs.
The buddy list could also be tailored for the
client/terminal.
Comments?
/sean
--
Sean Olson <sean.olson@ericsson.com>
Ericsson Inc.
>-----Original Message-----
>From: Vencour Marcel [mailto:marcel.vencour@siemens.at]
>Sent: Tuesday, June 19, 2001 7:41 AM
>To: 'simple@mailman.dynamicsoft.com'
>Cc: Mayerhofer Andreas A
>Subject: [Simple] Mobility of Buddy List
>
>
>Hello everybody,
>
>I have a problem concerning the buddy list used in a presence
>service: The
>question is, where is the buddy list of the watcher stored
>when the watcher
>goes offline? If it is stored in a file/database at the location of the
>watcher, then it is bound to the watcher's client, i.e. it
>does not move
>around with the watcher (here watcher means the person, not
>the client used
>by that person) when he uses different machines to do his
>watching. Thus the
>buddy list would have to be stored at the presence
>server/presence agent
>(PS). But in this case how can the watcher go offline without
>deleting his
>buddy list at the PS? If he goes offline without sending any
>unsubscribe
>then the PS would continue to send notifications to the
>watcher which of
>course is unnecessary overhead. On the other hand, if the watcher goes
>offline and sends unsubscribes for all his buddies then the
>buddy list would
>be removed from the PS.
>The next question then is, what happens when the watcher goes
>online again?
>How can he send a subscribe without giving a buddy in the
>request line (just
>to tell that he is online and thus wants to receive
>notifications again)?
>
>Thanks in advance for an answer, M. Vencour.
>
>_______________________________________________
>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

--Boundary_(ID_JMX3wyWGnX0TLDy+F/qx6Q)-- From Vasilis.Polychronidis@Openwave.com Thu Jun 21 19:34:09 2001 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 TAA15421 for ; Thu, 21 Jun 2001 19:34:09 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010621233302.DTAH27103.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 21 Jun 2001 18:33:02 -0500 Received: from Openwave.com ([4.41.19.90]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010621233407.QLDA10980.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Thu, 21 Jun 2001 18:34:07 -0500 Message-ID: <3B328468.6C9BB95C@Openwave.com> Date: Thu, 21 Jun 2001 16:34:01 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: "Rosen, Brian" , Robert Osborne , Jonathan Rosenberg , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com, Mayerhofer Andreas A , impp@iastate.edu Subject: Re: [Simple] Mobility of Buddy List References: <4FBEA8857476D311A03300204840E1CF04465599@whq-msgusr-02.pit.comms.marconi.com> <3B322E02.5B8513E7@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------84AD12161636E5CB3A4198CB" Content-Length: 4131 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: --------------84AD12161636E5CB3A4198CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Henning, I totally agree with all of your statements below. I think this is a good discussion/initiative for the IMPP list. Kind Regards, Vasilis Polychronidis Henning Schulzrinne wrote: > This seems like a topic where standardization may be useful, but > certainly not required. After all, we do have a standard for address > books that's followed reasonably widely, namely LDIF and the underlying > "Internet person object" out of LDAP. I suspect that a common > interchange format may emerge that allows different applications to at > least exchange (import/export) this information, as long as the major > apps vendors play along. However, this would seem an appropriate topic > for IMPP, not SIMPLE. > > It would be useful to be able to subscribe to one's address book or > contact list and get (in the LDIF update format) a list of changes since > the last update. I suspect that if IMPP or similar doesn't standardize > this, a certain large software company will make this part of Snow > breeze or whatever it's called. > > "Rosin, Brian" wrote: > > > > I agree. The basic contents of the lists are probably common > > (presentity), but the structure is not. Consider the standard > > AOL Instant Messenger list already has a two dimensional structure, > > and it is easy to imagine more elaborate structures for the lists. > > As Vasilis points out, contact information and "buddy lists" may > > be combined, and we aren't going to standardize contacts are we? > > > > In our implementation, we plan to have more information in our content > > entries beyond just the presentity, so a standardized list format > > would be problematic. > > > > It is always possible to leave the list as an XML blob, but then > > I don't think anyone gets any advantage out of that. > > > > --------------84AD12161636E5CB3A4198CB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Henning,
I totally agree with all of your statements below.
I think this is a good discussion/initiative for the IMPP list.

Kind Regards,

Vasilis Polychronidis

Henning Schulzrinne wrote:

This seems like a topic where standardization may be useful, but
certainly not required. After all, we do have a standard for address
books that's followed reasonably widely, namely LDIF and the underlying
"Internet person object" out of LDAP. I suspect that a common
interchange format may emerge that allows different applications to at
least exchange (import/export) this information, as long as the major
apps vendors play along. However, this would seem an appropriate topic
for IMPP, not SIMPLE.

It would be useful to be able to subscribe to one's address book or
contact list and get (in the LDIF update format) a list of changes since
the last update. I suspect that if IMPP or similar doesn't standardize
this, a certain large software company will make this part of Snow
breeze or whatever it's called.

"Rosin, Brian" wrote:
>
> I agree.  The basic contents of the lists are probably common
> (presentity), but the structure is not.  Consider the standard
> AOL Instant Messenger list already has a two dimensional structure,
> and it is easy to imagine more elaborate structures for the lists.
> As Vasilis points out, contact information and "buddy lists" may
> be combined, and we aren't going to standardize contacts are we?
>
> In our implementation, we plan to have more information in our content
> entries beyond just the presentity, so a standardized list format
> would be problematic.
>
> It is always possible to leave the list as an XML blob, but then
> I don't think anyone gets any advantage out of that.
>
 
 

--------------84AD12161636E5CB3A4198CB-- From sriramp@nortelnetworks.com Fri Jun 22 09:36:33 2001 Received: from zrc2s03g.us.nortel.com ([47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17620 for ; Fri, 22 Jun 2001 09:36:30 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id IAA05433 for ; Fri, 22 Jun 2001 08:38:01 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 22 Jun 2001 08:34:55 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 08:34:54 -0500 Message-ID: <9A9367D1556AD21182C40000F80930AB04411C49@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: "'Jonathan Rosenberg'" , "'Rosen, Brian'" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 08:34:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FB20.1DD8B300" Content-Length: 13403 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: 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_01C0FB20.1DD8B300 Content-Type: text/plain; charset="iso-8859-1" Jonathan, Your second case (please see below) brings up a very interesting question - do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are online and others are offline? Is the group online or offline? It is my personal opinion that groups do *NOT* have presence, its only the individual members of the group that have presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list. Example: mybuddies ====> note groups have no presence John Mary Jack Comments? Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, June 21, 2001 12:53 AM To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List <<<<<<>>>>>>>>>>>>>> 2. a single watcher subscribes to multiple presentities, but aggregates all its subscribe requests into a single subscribe message to its local server. For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com". That server generates individual subscriptions for each user in the buddylist. Pictorially: Please view in a fixed-width font such as Courier. / / / / SUB joe / / / +----+ SUB buddies ------+/ | | ---------------| | SUB bob | | | |--------------- +----+ | | +------+ \ user \ de- \ aggregator \ SUB ralph \ \ \ \ These two cases are opposites, really. In the second case, you might want to aggregate the notifications back to the user. This would require an aggregate presence document which represents a group of users. Brian mentions this above. Its something different, and I agree out of scope for now. -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_01C0FB20.1DD8B300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Mobility of Buddy List

Jonathan,

Your second case (please see below) brings up a very = interesting question - do groups have presence? For instance you have = said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what = happens if some members are online and others are offline? Is the group = online or offline?

It is my personal opinion that groups do *NOT* have = presence, its only the individual members of the group that have = presence. Hence I strongly feel that individual SUBSCRIBES have to be = sent for each of the members, the resulting NOTIFIES are used to = indicate the presence of individual presentities in your buddy list. =

Example:
mybuddies =3D=3D=3D=3D> note groups have no = presence
        John = <Online>
        Mary = <Offline>
        Jack = <Online>

Comments?
Regards,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: = 972-685-3563
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, June 21, 2001 12:53 AM
To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson = (EUS)'; 'Vencour
Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List
<<<<<<<snip>>>>>>>>= ;>>>>>>>
2. a single watcher subscribes to multiple = presentities, but aggregates all
its subscribe requests into a single subscribe = message to its local server.
For example, the user would send "SUBSCRIBE = sip:mybuddies@mydomain.com".
That server generates individual subscriptions for = each user in the
buddylist. Pictorially:

Please view in a fixed-width font such as = Courier.




          &nb= sp;           &nb= sp;           &nb= sp;      /
          &nb= sp;           &nb= sp;           &nb= sp;     /
          &nb= sp;           &nb= sp;           &nb= sp;    /
          &nb= sp;           &nb= sp;           &nb= sp;   / SUB joe
          &nb= sp;           &nb= sp;           &nb= sp;  /
          &nb= sp;           &nb= sp;           &nb= sp; /
          &nb= sp;           &nb= sp;            = /
    +----+ SUB = buddies     ------+/
    |    | = ---------------|      = |      SUB bob
    |    = |            = ;    |      = |---------------
    = +----+           =      |      |
          &nb= sp;           &nb= sp;   +------+ \
     = user           &n= bsp;           &n= bsp;   \
          &nb= sp;           &nb= sp;   de-        \
          &nb= sp;           &nb= sp;   aggregator  \  SUB ralph
          &nb= sp;           &nb= sp;           &nb= sp;    \
          &nb= sp;           &nb= sp;           &nb= sp;     \
          &nb= sp;           &nb= sp;           &nb= sp;      \
          &nb= sp;           &nb= sp;           &nb= sp;       \

These two cases are opposites, really. In the second = case, you might want to
aggregate the notifications back to the user. This = would require an
aggregate presence document which represents a group = of users. Brian
mentions this above. Its something different, and I = agree out of scope for
now.

-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_01C0FB20.1DD8B300-- From Brian.Rosen@marconi.com Fri Jun 22 11:13:04 2001 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 LAA17896 for ; Fri, 22 Jun 2001 11:13:03 -0400 (EDT) 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 LAA25947; Fri, 22 Jun 2001 11:12:24 -0400 (EDT) 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 LAA05608; Fri, 22 Jun 2001 11:12:28 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 11:12:24 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655DF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sriram Parameswar'" , "'Jonathan Rosenberg'" , "Rosen, Brian" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 11:12:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FB2D.BDB6AE60" Content-Length: 17822 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: 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_01C0FB2D.BDB6AE60 Content-Type: text/plain; charset="iso-8859-1" Right, this is why I suggest that to handle the current notion of groups, in fact the list is a simple list, and individual entries on the list have a list of groups to which they belong. Of course the entry may want a few more fields so that you can render it the way the client (and the user) wants. For example, you may want an icon, or a picture. This is where the idea Henning had of using the LDIF format to represent the presentity comes in. So now the list is an LDIF file. Hmmm, can you put an icon in an LDIF/LDAP entry? You get a photo, but I don't remember an icon. Hmmmm, I smell an extension for inetOrgPerson. There are a couple of fields I can see co-opting for group membership but there isn't an exact match. Is that another extension? But, of course, a simple list may not be appropriate for all implementations, but we've covered that :) Brian -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Friday, June 22, 2001 9:35 AM To: 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Jonathan, Your second case (please see below) brings up a very interesting question - do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are online and others are offline? Is the group online or offline? It is my personal opinion that groups do *NOT* have presence, its only the individual members of the group that have presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list. Example: mybuddies ====> note groups have no presence John Mary Jack Comments? Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Thursday, June 21, 2001 12:53 AM To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List <<<<<<>>>>>>>>>>>>>> 2. a single watcher subscribes to multiple presentities, but aggregates all its subscribe requests into a single subscribe message to its local server. For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com". That server generates individual subscriptions for each user in the buddylist. Pictorially: Please view in a fixed-width font such as Courier. / / / / SUB joe / / / +----+ SUB buddies ------+/ | | ---------------| | SUB bob | | | |--------------- +----+ | | +------+ \ user \ de- \ aggregator \ SUB ralph \ \ \ \ These two cases are opposites, really. In the second case, you might want to aggregate the notifications back to the user. This would require an aggregate presence document which represents a group of users. Brian mentions this above. Its something different, and I agree out of scope for now. -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_01C0FB2D.BDB6AE60 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Mobility of Buddy List
Right, this is why I suggest that to handle the current notion of groups,
in fact the list is a simple list, and individual entries on the list have a list of
groups to which they belong.   Of course the entry may want a few
more fields so that you can render it the way the client (and the user) wants.
For example, you may want an icon, or a picture.  This is where the idea
Henning had of using the LDIF format to represent the presentity comes in.
 
So now the list is an LDIF file.
Hmmm, can you put an icon in an LDIF/LDAP entry?  You get a photo, but
I don't remember an icon.  Hmmmm, I smell an extension for inetOrgPerson.
There are a couple of fields I can see co-opting for group membership
but there isn't an exact match.  Is that another extension?
 
But, of course, a simple list may not be appropriate for all implementations,
but we've covered that :)
 
Brian
-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: Friday, June 22, 2001 9:35 AM
To: 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List

Jonathan,

Your second case (please see below) brings up a very interesting question - do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are online and others are offline? Is the group online or offline?

It is my personal opinion that groups do *NOT* have presence, its only the individual members of the group that have presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list.

Example:
mybuddies ====> note groups have no presence
        John <Online>
        Mary <Offline>
        Jack <Online>

Comments?
Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, June 21, 2001 12:53 AM
To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour
Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List
<<<<<<<snip>>>>>>>>>>>>>>>
2. a single watcher subscribes to multiple presentities, but aggregates all
its subscribe requests into a single subscribe message to its local server.
For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com".
That server generates individual subscriptions for each user in the
buddylist. Pictorially:

Please view in a fixed-width font such as Courier.




                                         /
                                        /
                                       /
                                      / SUB joe
                                     /
                                    /
                                   /
    +----+ SUB buddies     ------+/
    |    | ---------------|      |      SUB bob
    |    |                |      |---------------
    +----+                |      |
                          +------+ \
     user                           \
                          de-        \
                          aggregator  \  SUB ralph
                                       \
                                        \
                                         \
                                          \

These two cases are opposites, really. In the second case, you might want to
aggregate the notifications back to the user. This would require an
aggregate presence document which represents a group of users. Brian
mentions this above. Its something different, and I agree out of scope for
now.

-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_01C0FB2D.BDB6AE60-- From roberbr@microsoft.com Fri Jun 22 13:07:23 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA18248 for ; Fri, 22 Jun 2001 13:07:09 -0400 (EDT) Received: from 157.54.9.101 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Jun 2001 09:43:43 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Jun 2001 09:43:36 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FB3A.792D7B53" Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 09:43:32 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C32E9@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Mobility of Buddy List Thread-Index: AcD7Lja9iOaxDz2jRdGfgUDA4XclZQACvvrQ From: "Robert Brown" To: "Rosen, Brian" , "Sriram Parameswar" , "Jonathan Rosenberg" , "Sean Olson (EUS)" , "Vencour Marcel" , Cc: "Mayerhofer Andreas A" X-OriginalArrivalTime: 22 Jun 2001 16:43:36.0569 (UTC) FILETIME=[7B89FE90:01C0FB3A] Content-Length: 27347 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0FB3A.792D7B53 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't see that the structure of a document for describing the users and groups that an application subscribes to has anything to do with SIMPLE. =20 We should assume that an application has some way of determining the set of presentities it wants to subscribe to. But any assumption beyond this becomes completely application specific. There are so many applications in use that contain information on people, and there's no reason any of them wouldn't offer the ability to watch at least some of those people. If an implementer wants a "buddy list", that's up to them to figure out. If an implementer wants to create a URI for a group of presentities and aggregate the presence state of those presentities into the state of the group, that's fine too. But it has nothing to do with the protocol. They're just scenarios that can be implemented with the subscription and authorization methods that are being discussed in SIMPLE. =20 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 Sent: Friday, June 22, 2001 8:12 AM To: 'Sriram Parameswar'; 'Jonathan Rosenberg'; Rosen, Brian; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List =20 Right, this is why I suggest that to handle the current notion of groups,=20 in fact the list is a simple list, and individual entries on the list have a list of=20 groups to which they belong. Of course the entry may want a few=20 more fields so that you can render it the way the client (and the user) wants. For example, you may want an icon, or a picture. This is where the idea Henning had of using the LDIF format to represent the presentity comes in. =20 So now the list is an LDIF file. Hmmm, can you put an icon in an LDIF/LDAP entry? You get a photo, but I don't remember an icon. Hmmmm, I smell an extension for inetOrgPerson. There are a couple of fields I can see co-opting for group membership but there isn't an exact match. Is that another extension? =20 But, of course, a simple list may not be appropriate for all implementations, but we've covered that :) =20 Brian -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Friday, June 22, 2001 9:35 AM To: 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Jonathan,=20 Your second case (please see below) brings up a very interesting question - do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are online and others are offline? Is the group online or offline?=20 It is my personal opinion that groups do *NOT* have presence, its only the individual members of the group that have presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list.=20 Example:=20 mybuddies =3D=3D=3D=3D> note groups have no presence=20 John =20 Mary =20 Jack =20 Comments?=20 Regards,=20 Sriram=20 __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 =20 -----Original Message-----=20 From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Thursday, June 21, 2001 12:53 AM=20 To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour=20 Marcel'; 'simple@mailman.dynamicsoft.com'=20 Cc: Mayerhofer Andreas A=20 Subject: RE: [Simple] Mobility of Buddy List=20 <<<<<<>>>>>>>>>>>>>>=20 2. a single watcher subscribes to multiple presentities, but aggregates all=20 its subscribe requests into a single subscribe message to its local server.=20 For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com".=20 That server generates individual subscriptions for each user in the=20 buddylist. Pictorially:=20 Please view in a fixed-width font such as Courier.=20 =09 =09 =09 /=20 /=20 /=20 / SUB joe=20 /=20 /=20 /=20 +----+ SUB buddies ------+/=20 | | ---------------| | SUB bob=20 | | | |---------------=20 +----+ | |=20 +------+ \=20 user \=20 de- \=20 aggregator \ SUB ralph=20 \=20 \=20 \=20 \=20 These two cases are opposites, really. In the second case, you might want to=20 aggregate the notifications back to the user. This would require an=20 aggregate presence document which represents a group of users. Brian=20 mentions this above. Its something different, and I agree out of scope for=20 now.=20 -Jonathan R.=20 =20 ---=20 Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.=20 Chief Scientist First Floor=20 dynamicsoft East Hanover, NJ 07936=20 jdrosen@dynamicsoft.com FAX: (973) 952-5050=20 http://www.jdrosen.net PHONE: (973) 952-5000=20 http://www.dynamicsoft.com=20 _______________________________________________=20 simple mailing list=20 simple@mailman.dynamicsoft.com=20 http://mailman.dynamicsoft.com/mailman/listinfo/simple=20 ------_=_NextPart_001_01C0FB3A.792D7B53 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Simple] Mobility of Buddy List

I don’t see that the = structure of a document for describing the users and groups that an application = subscribes to has anything to do with SIMPLE.

 

We should assume that an = application has some way of determining the set of presentities it wants to subscribe = to.  But any assumption beyond this becomes completely application = specific.  There are so many applications in use that contain information on people, and = there’s no reason any of them wouldn’t offer the ability to watch at least = some of those people.  If an implementer wants a “buddy = list”, that’s up to them to figure out.  If an implementer wants to create a URI = for a group of presentities and aggregate the presence state of those = presentities into the state of the group, that’s fine too.  But it has = nothing to do with the protocol. They’re just scenarios that can be = implemented with the subscription and authorization methods that are being discussed in = SIMPLE.

 

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, June 22, = 2001 8:12 AM
To: 'Sriram Parameswar'; = 'Jonathan Rosenberg'; Rosen, Brian; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas = A
Subject: RE: [Simple] = Mobility of Buddy List

 

Right, this is why I suggest that = to handle the current notion of groups,

in fact the list is a simple list, = and individual entries on the list have a list of

groups to which they = belong.   Of course the entry may want a few

more fields so that you can render = it the way the client (and the user) wants.

For example, you may want an icon, = or a picture.  This is where the idea

Henning had of using the LDIF = format to represent the presentity comes in.

 

So now the list is an LDIF = file.

Hmmm, can you put an icon in an = LDIF/LDAP entry?  You get a photo, but

I don't remember an icon.  = Hmmmm, I smell an extension for inetOrgPerson.

There are a couple of fields I can = see co-opting for group membership

but there isn't an exact = match.  Is that another extension?

 

But, of course, a simple list may = not be appropriate for all implementations,

but we've covered that = :)

 

Brian

-----Original = Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: Friday, June 22, = 2001 9:35 AM
To: 'Jonathan Rosenberg'; = 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; = 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas = A
Subject: RE: [Simple] = Mobility of Buddy List

Jonathan,

Your second case (please see below) brings up a very interesting question - = do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are = online and others are offline? Is the group online or offline? =

It is my personal opinion that groups do *NOT* have presence, its only the = individual members of the group that have presence. Hence I strongly feel that = individual SUBSCRIBES have to be sent for each of the members, the resulting = NOTIFIES are used to indicate the presence of individual presentities in your buddy = list.

Example:
mybuddies = =3D=3D=3D=3D> note groups have no presence
        John <Online>
        Mary <Offline>
        Jack <Online>

Comments?
Regards, =

Sriram

__________________________________________
Sriram Parameswar          &nb= sp;   Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
Nortel Networks, = Richardson USA  Email: sriramp@nortelnetworks.com

 

-----Original Message-----
From: Jonathan Rosenberg = [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, June 21, = 2001 12:53 AM
To: 'Rosen, Brian'; = Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour
Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas = A
Subject: RE: [Simple] = Mobility of Buddy List
<<<<<<<snip>>>&g= t;>>>>>>>>>>>
2. a single watcher = subscribes to multiple presentities, but aggregates all
its subscribe requests = into a single subscribe message to its local server.
For example, the user = would send "SUBSCRIBE sip:mybuddies@mydomain.com".
That server generates = individual subscriptions for each user in the
buddylist. = Pictorially:

Please view in a fixed-width font such as Courier.



       &nbs= p;            = ;            =          /
       &nbs= p;            = ;            =         /
       &nbs= p;            = ;            =        /
       &nbs= p;            = ;            =       / SUB joe
       &nbs= p;            = ;            =      /
       &nbs= p;            = ;            =     /
       &nbs= p;            = ;            =    /
    = +----+ SUB buddies     ------+/
    |    | ---------------|      |      SUB bob
    |    |            =     |      |---------------
    +----+           &= nbsp;    |      |
       &nbs= p;            = ;      +------+ \
     user           &nb= sp;           &nbs= p;   \
       &nbs= p;            = ;      de-        \
       &nbs= p;            = ;      aggregator  \  SUB ralph
       &nbs= p;            = ;            =        \
       &nbs= p;            = ;            =         \
       &nbs= p;            = ;            =          \
       &nbs= p;            = ;            =           \

These two cases are opposites, really. In the second case, you might want = to
aggregate the = notifications back to the user. This would require an
aggregate presence = document which represents a group of users. Brian
mentions this above. Its = something different, and I agree out of scope for
now.

-Jonathan R.

 

---
Jonathan D. Rosenberg, Ph.D.           &n= bsp;    72 Eagle Rock Ave.
Chief Scientist          &nbs= p;            = ;      First Floor
dynamicsoft      = ;            =             &= nbsp;  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<= /a>

=00 ------_=_NextPart_001_01C0FB3A.792D7B53-- From jdrosen@dynamicsoft.com Fri Jun 22 13:13:10 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18283 for ; Fri, 22 Jun 2001 13:13:09 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA19019; Fri, 22 Jun 2001 13:17:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 13:13:06 -0400 Message-ID: From: Jonathan Rosenberg To: "'Theodore Havinis'" , Vencour Marcel , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 13:13:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Length: 2560 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: > -----Original Message----- > From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > Sent: Thursday, June 21, 2001 4:26 PM > To: Vencour Marcel; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Mobility of Buddy List > > > > Hi Vencour, > > I don't think we should mix the presence service and its > services (provide > notification of state changes) with the capabilities of a specific > application that helps you create a buddy-list and > potentially may also support 'reachability/mobility' > capabilities which will > mean that you will beb able to access the 'buddy list' from > any device. Agree totally. IM is one potential application of presence, and the buddylist is an application-specific (i.e., for IM) tool that allows cross-device access to the application. However, its worth noting that there are clases of data which are "cross-application subscriber feature data", which means that they are data, created by a user, but specific to several related applications. There are other apps, not IM, which may want to know your "set of buddies". Therefore, having a standardized format provides two benefits: 1. allows access to the IM application from many devices 2. allows other related applications to access this important piece of data There are other examples of such datum. iCalendar is another example; knowing the set of meetings I'm scheduled for is useful for a PC based calendar application (like Outlook), but also useful for a call processing language script in a proxy, which wants to filter calls when you're in a meeting (and indeed, this integration is happening). One might imagine that instead of embedding the date information in a CPL, a SIP servlet on a proxy fetches my calendar information, and processes it in its native iCalendar format, rejecting calls when I'm in a meeting. This wouldn't be possible if iCalendar weren't a standardized format. Because of the cross-application nature of the IM buddy list, standardization is definitely useful. I agree its not a SIMPLE issue. Whether its an IMPP issue is also a good question. Perhaps if there is sufficient interest, we can have a BoF on this topic at the next IETF. -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 From rohan@cisco.com Fri Jun 22 15:16:43 2001 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18645 for ; Fri, 22 Jun 2001 15:15:08 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5MJB7h19547; Fri, 22 Jun 2001 12:11:07 -0700 (PDT) Received: from rmahy-laptop.cisco.com (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with ESMTP id ABH58381; Fri, 22 Jun 2001 12:11:02 -0700 (PDT) Message-Id: <5.1.0.14.1.20010622113557.022d1d90@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Jun 2001 12:12:08 -0700 To: "Sriram Parameswar" , "'Jonathan Rosenberg'" , "'Rosen, Brian'" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" From: Rohan Mahy Subject: RE: [Simple] Mobility of Buddy List Cc: Mayerhofer Andreas A In-Reply-To: <9A9367D1556AD21182C40000F80930AB04411C49@crchy28b.us.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_14358175==_.ALT" Content-Length: 13711 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: --=====================_14358175==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I'd like to give a counter example: a group that has presence, where the desired behavior is that if one member of the group is online, then the group is online. sip:east-coast-call-center-agents@company.com I think the merge policy is up to the PA that is repsonsible for the merge. thanks, -rohan At 06:34 AM 6/22/01, Sriram Parameswar wrote: >Jonathan, > >Your second case (please see below) brings up a very interesting question >- do groups have presence? For instance you have said "SUBSCRIBE >sip:mybuddies@mydomain.com" - now what happens if some members are online >and others are offline? Is the group online or offline? > >It is my personal opinion that groups do *NOT* have presence, its only the >individual members of the group that have presence. Hence I strongly feel >that individual SUBSCRIBES have to be sent for each of the members, the >resulting NOTIFIES are used to indicate the presence of individual >presentities in your buddy list. > >Example: >mybuddies ====> note groups have no presence > John > Mary > Jack > >Comments? >Regards, > >Sriram > >__________________________________________ >Sriram Parameswar Phone: 972-685-8540 >Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 >Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > >-----Original Message----- >From: Jonathan Rosenberg >[mailto:jdrosen@dynamicsoft.com] >Sent: Thursday, June 21, 2001 12:53 AM >To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour >Marcel'; 'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: RE: [Simple] Mobility of Buddy List ><<<<<<>>>>>>>>>>>>>> >2. a single watcher subscribes to multiple presentities, but aggregates all >its subscribe requests into a single subscribe message to its local server. >For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com". >That server generates individual subscriptions for each user in the >buddylist. Pictorially: > >Please view in a fixed-width font such as Courier. > > > > / > / > / > / SUB joe > / > / > / > +----+ SUB buddies ------+/ > | | ---------------| | SUB bob > | | | |--------------- > +----+ | | > +------+ \ > user \ > de- \ > aggregator \ SUB ralph > \ > \ > \ > \ > >These two cases are opposites, really. In the second case, you might want to >aggregate the notifications back to the user. This would require an >aggregate presence document which represents a group of users. Brian >mentions this above. Its something different, and I agree out of scope for >now. > >-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 > --=====================_14358175==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

I'd like to give a counter example: a group that has presence, where the desired behavior is that if one member of the group is online, then the group is online.

        sip:east-coast-call-center-agents@company.com

I think the merge policy is up to the PA that is repsonsible for the merge.

thanks,
-rohan


At 06:34 AM 6/22/01, Sriram Parameswar wrote:

Jonathan,

Your second case (please see below) brings up a very interesting question - do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are online and others are offline? Is the group online or offline?

It is my personal opinion that groups do *NOT* have presence, its only the individual members of the group that have presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list.

Example:
mybuddies ====> note groups have no presence
        John <Online>
        Mary <Offline>
        Jack <Online>

Comments?
Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, June 21, 2001 12:53 AM
To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour
Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List
<<<<<<<snip>>>>>>>>>>>>>>>
2. a single watcher subscribes to multiple presentities, but aggregates all
its subscribe requests into a single subscribe message to its local server.
For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com".
That server generates individual subscriptions for each user in the
buddylist. Pictorially:

Please view in a fixed-width font such as Courier.



                                         /
                                        /
                                       /
                                      / SUB joe
                                     /
                                    /
                                   /
    +----+ SUB buddies     ------+/
    |    | ---------------|      |      SUB bob
    |    |                |      |---------------
    +----+                |      |
                          +------+ \
     user                           \
                          de-        \
                          aggregator  \  SUB ralph
                                       \
                                        \
                                         \
                                          \

These two cases are opposites, really. In the second case, you might want to
aggregate the notifications back to the user. This would require an
aggregate presence document which represents a group of users. Brian
mentions this above. Its something different, and I agree out of scope for
now.

-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

--=====================_14358175==_.ALT-- From Brian.Rosen@marconi.com Fri Jun 22 15:26:49 2001 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 PAA18696 for ; Fri, 22 Jun 2001 15:26:48 -0400 (EDT) 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 PAA15690; Fri, 22 Jun 2001 15:26:24 -0400 (EDT) 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 PAA07669; Fri, 22 Jun 2001 15:26:29 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 15:26:26 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655E9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Rohan Mahy'" , Sriram Parameswar , "'Jonathan Rosenberg'" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 15:26:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FB51.3A33A600" Content-Length: 18144 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: 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_01C0FB51.3A33A600 Content-Type: text/plain; charset="iso-8859-1" I would assert that sip:east-coast-call-center-agents@company.com is a presentity, and not a group. That presentity obtains it's presence status by subscribing to the individual member's presence and then advertises its presence according to whatever rules it has. To me, groups are buckets I put people into, and a given person can be in more than one bucket (friend, co-worker, volleyball-team-member). If you want the sip:east-coast-call-centeragents@company.com presentity to define it's state based on all the people in the east-coast-call-center-agents group, fine. Brian -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Friday, June 22, 2001 3:12 PM To: Sriram Parameswar; 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Hi, I'd like to give a counter example: a group that has presence, where the desired behavior is that if one member of the group is online, then the group is online. sip:east-coast-call-center-agents@company.com I think the merge policy is up to the PA that is repsonsible for the merge. thanks, -rohan At 06:34 AM 6/22/01, Sriram Parameswar wrote: Jonathan, Your second case (please see below) brings up a very interesting question - do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are online and others are offline? Is the group online or offline? It is my personal opinion that groups do *NOT* have presence, its only the individual members of the group that have presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list. Example: mybuddies ====> note groups have no presence John Mary Jack Comments? Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Thursday, June 21, 2001 12:53 AM To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List <<<<<<>>>>>>>>>>>>>> 2. a single watcher subscribes to multiple presentities, but aggregates all its subscribe requests into a single subscribe message to its local server. For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com". That server generates individual subscriptions for each user in the buddylist. Pictorially: Please view in a fixed-width font such as Courier. / / / / SUB joe / / / +----+ SUB buddies ------+/ | | ---------------| | SUB bob | | | |--------------- +----+ | | +------+ \ user \ de- \ aggregator \ SUB ralph \ \ \ \ These two cases are opposites, really. In the second case, you might want to aggregate the notifications back to the user. This would require an aggregate presence document which represents a group of users. Brian mentions this above. Its something different, and I agree out of scope for now. -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_01C0FB51.3A33A600 Content-Type: text/html; charset="iso-8859-1"
I would assert that sip:east-coast-call-center-agents@company.com
is a presentity, and not a group. That presentity obtains it's presence
status by subscribing to the individual member's presence and then
advertises its presence according to whatever rules it has.
 
To me, groups are buckets I put people into, and a given person can
be in more than one bucket (friend, co-worker, volleyball-team-member). 
If you want the sip:east-coast-call-centeragents@company.com
presentity to define it's state based on all the people in the
east-coast-call-center-agents group, fine.
 
Brian
 
-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Friday, June 22, 2001 3:12 PM
To: Sriram Parameswar; 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List

Hi,

I'd like to give a counter example: a group that has presence, where the desired behavior is that if one member of the group is online, then the group is online.

        sip:east-coast-call-center-agents@company.com

I think the merge policy is up to the PA that is repsonsible for the merge.

thanks,
-rohan


At 06:34 AM 6/22/01, Sriram Parameswar wrote:

Jonathan,

Your second case (please see below) brings up a very interesting question - do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are online and others are offline? Is the group online or offline?

It is my personal opinion that groups do *NOT* have presence, its only the individual members of the group that have presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list.

Example:
mybuddies ====> note groups have no presence
        John <Online>
        Mary <Offline>
        Jack <Online>

Comments?
Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, June 21, 2001 12:53 AM
To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour
Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List
<<<<<<<snip>>>>>>>>>>>>>>>
2. a single watcher subscribes to multiple presentities, but aggregates all
its subscribe requests into a single subscribe message to its local server.
For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com".
That server generates individual subscriptions for each user in the
buddylist. Pictorially:

Please view in a fixed-width font such as Courier.



                                         /
                                        /
                                       /
                                      / SUB joe
                                     /
                                    /
                                   /
    +----+ SUB buddies     ------+/
    |    | ---------------|      |      SUB bob
    |    |                |      |---------------
    +----+                |      |
                          +------+ \
     user                           \
                          de-        \
                          aggregator  \  SUB ralph
                                       \
                                        \
                                         \
                                          \

These two cases are opposites, really. In the second case, you might want to
aggregate the notifications back to the user. This would require an
aggregate presence document which represents a group of users. Brian
mentions this above. Its something different, and I agree out of scope for
now.

-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_01C0FB51.3A33A600-- From rohan@cisco.com Fri Jun 22 16:28:20 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18913 for ; Fri, 22 Jun 2001 16:28:20 -0400 (EDT) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5MKSDx16110; Fri, 22 Jun 2001 13:28:13 -0700 (PDT) Received: from rmahy-laptop.cisco.com (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with ESMTP id ABH59119; Fri, 22 Jun 2001 13:23:04 -0700 (PDT) Message-Id: <5.1.0.14.1.20010622132402.022b9d90@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 22 Jun 2001 13:24:56 -0700 To: "Rosen, Brian" , "'Rohan Mahy'" , Sriram Parameswar , "'Jonathan Rosenberg'" , "'Sean Olson (EUS)'" , "'Vencour Marcel'" , "'simple@mailman.dynamicsoft.com'" From: Rohan Mahy Subject: RE: [Simple] Mobility of Buddy List Cc: Mayerhofer Andreas A In-Reply-To: <4FBEA8857476D311A03300204840E1CF044655E9@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18680904==_.ALT" Content-Length: 16780 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: --=====================_18680904==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Sounds reasonable. The term "group-presentity" may be useful. is there a formal definition for "group" now? thanks, -r At 12:26 PM 6/22/01, Rosen, Brian wrote: >I would assert that sip:east-coast-call-center-agents@company.com >is a presentity, and not a group. That presentity obtains it's presence >status by subscribing to the individual member's presence and then >advertises its presence according to whatever rules it has. > >To me, groups are buckets I put people into, and a given person can >be in more than one bucket (friend, co-worker, volleyball-team-member). >If you want the sip:east-coast-call-centeragents@company.com >presentity to define it's state based on all the people in the >east-coast-call-center-agents group, fine. > >Brian > >-----Original Message----- >From: Rohan Mahy [mailto:rohan@cisco.com] >Sent: Friday, June 22, 2001 3:12 PM >To: Sriram Parameswar; 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson >(EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: RE: [Simple] Mobility of Buddy List > >Hi, > >I'd like to give a counter example: a group that has presence, where the >desired behavior is that if one member of the group is online, then the >group is online. > > sip:east-coast-call-center-agents@company.com > >I think the merge policy is up to the PA that is repsonsible for the merge. > >thanks, >-rohan > > > >At 06:34 AM 6/22/01, Sriram Parameswar wrote: > >>Jonathan, >> >>Your second case (please see below) brings up a very interesting question >>- do groups have presence? For instance you have said "SUBSCRIBE >>sip:mybuddies@mydomain.com" - now what happens if some members are online >>and others are offline? Is the group online or offline? >>It is my personal opinion that groups do *NOT* have presence, its only >>the individual members of the group that have presence. Hence I strongly >>feel that individual SUBSCRIBES have to be sent for each of the members, >>the resulting NOTIFIES are used to indicate the presence of individual >>presentities in your buddy list. >>Example: >>mybuddies ====> note groups have no presence >> John >> Mary >> Jack >> >>Comments? >>Regards, >> >>Sriram >> >>__________________________________________ >>Sriram Parameswar Phone: 972-685-8540 >>Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 >>Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com >> >>-----Original Message----- >>From: Jonathan Rosenberg >>[mailto:jdrosen@dynamicsoft.com] >>Sent: Thursday, June 21, 2001 12:53 AM >>To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour >>Marcel'; 'simple@mailman.dynamicsoft.com' >>Cc: Mayerhofer Andreas A >>Subject: RE: [Simple] Mobility of Buddy List >><<<<<<>>>>>>>>>>>>>> >>2. a single watcher subscribes to multiple presentities, but aggregates all >>its subscribe requests into a single subscribe message to its local server. >>For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com". >>That server generates individual subscriptions for each user in the >>buddylist. Pictorially: >> >>Please view in a fixed-width font such as Courier. >> >> >> >> >> >> / >> / >> / >> / SUB joe >> / >> / >> / >> +----+ SUB buddies ------+/ >> | | ---------------| | SUB bob >> | | | |--------------- >> +----+ | | >> +------+ \ >> user \ >> de- \ >> aggregator \ SUB ralph >> \ >> \ >> \ >> \ >> >>These two cases are opposites, really. In the second case, you might want >>to >>aggregate the notifications back to the user. This would require an >>aggregate presence document which represents a group of users. Brian >>mentions this above. Its something different, and I agree out of scope for >>now. >> >>-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 >> --=====================_18680904==_.ALT Content-Type: text/html; charset="us-ascii" Sounds reasonable.  The term "group-presentity" may be useful.   is there a formal definition for "group" now?

thanks,
-r

At 12:26 PM 6/22/01, Rosen, Brian wrote:
I would assert that sip:east-coast-call-center-agents@company.com
is a presentity, and not a group. That presentity obtains it's presence
status by subscribing to the individual member's presence and then
advertises its presence according to whatever rules it has.
 
To me, groups are buckets I put people into, and a given person can
be in more than one bucket (friend, co-worker, volleyball-team-member). 
If you want the sip:east-coast-call-centeragents@company.com
presentity to define it's state based on all the people in the
east-coast-call-center-agents group, fine.
 
Brian
 
-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Friday, June 22, 2001 3:12 PM
To: Sriram Parameswar; 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List
Hi,

I'd like to give a counter example: a group that has presence, where the desired behavior is that if one member of the group is online, then the group is online.

        sip:east-coast-call-center-agents@company.com

I think the merge policy is up to the PA that is repsonsible for the merge.

thanks,
-rohan



At 06:34 AM 6/22/01, Sriram Parameswar wrote:

Jonathan,

Your second case (please see below) brings up a very interesting question - do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are online and others are offline? Is the group online or offline?
It is my personal opinion that groups do *NOT* have presence, its only the individual members of the group that have presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list.
Example:
mybuddies ====> note groups have no presence
        John <Online>
        Mary <Offline>
        Jack <Online>

Comments?
Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, June 21, 2001 12:53 AM
To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour
Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List
<<<<<<<snip>>>>>>>>>>>>>>>
2. a single watcher subscribes to multiple presentities, but aggregates all
its subscribe requests into a single subscribe message to its local server.
For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com".
That server generates individual subscriptions for each user in the
buddylist. Pictorially:

Please view in a fixed-width font such as Courier.





                                         /
                                        /
                                       /
                                      / SUB joe
                                     /
                                    /
                                   /
    +----+ SUB buddies     ------+/
    |    | ---------------|      |      SUB bob
    |    |                |      |---------------
    +----+                |      |
                          +------+ \
     user                           \
                          de-        \
                          aggregator  \  SUB ralph
                                       \
                                        \
                                         \
                                          \

These two cases are opposites, really. In the second case, you might want to
aggregate the notifications back to the user. This would require an
aggregate presence document which represents a group of users. Brian
mentions this above. Its something different, and I agree out of scope for
now.

-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

--=====================_18680904==_.ALT-- From roberbr@microsoft.com Fri Jun 22 16:59:18 2001 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA19015 for ; Fri, 22 Jun 2001 16:59:17 -0400 (EDT) Received: from 157.54.9.108 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Jun 2001 13:55:35 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 22 Jun 2001 13:55:33 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0FB5D.ADB3BF62" Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 13:55:33 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320CC9D@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Mobility of Buddy List Thread-Index: AcD7WkHxKbNGfWyCQ8a+C0zlxE73DgAAw0eg From: "Robert Brown" To: "Rohan Mahy" , "Rosen, Brian" , "Sriram Parameswar" , "Jonathan Rosenberg" , "Sean Olson (EUS)" , "Vencour Marcel" , Cc: "Mayerhofer Andreas A" X-OriginalArrivalTime: 22 Jun 2001 20:55:33.0910 (UTC) FILETIME=[AE2D2B60:01C0FB5D] Content-Length: 30991 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C0FB5D.ADB3BF62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There doesn't need to be. We just need to define how to work with a presentity. Whatever an implementation does to determine the state of the presentity is up to the implementation (e.g. Brian's call center example). =20 =20 -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com]=20 Sent: Friday, June 22, 2001 1:25 PM To: Rosen, Brian; 'Rohan Mahy'; Sriram Parameswar; 'Jonathan Rosenberg'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List =20 Sounds reasonable. The term "group-presentity" may be useful. is there a formal definition for "group" now? thanks, -r At 12:26 PM 6/22/01, Rosen, Brian wrote: I would assert that sip:east-coast-call-center-agents@company.com is a presentity, and not a group. That presentity obtains it's presence=20 status by subscribing to the individual member's presence and then=20 advertises its presence according to whatever rules it has. =20 To me, groups are buckets I put people into, and a given person can=20 be in more than one bucket (friend, co-worker, volleyball-team-member). If you want the sip:east-coast-call-centeragents@company.com presentity to define it's state based on all the people in the=20 east-coast-call-center-agents group, fine. =20 Brian =20 -----Original Message-----=20 From: Rohan Mahy [mailto:rohan@cisco.com]=20 Sent: Friday, June 22, 2001 3:12 PM=20 To: Sriram Parameswar; 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'=20 Cc: Mayerhofer Andreas A=20 Subject: RE: [Simple] Mobility of Buddy List Hi, I'd like to give a counter example: a group that has presence, where the desired behavior is that if one member of the group is online, then the group is online. sip:east-coast-call-center-agents@company.com I think the merge policy is up to the PA that is repsonsible for the merge. thanks,=20 -rohan At 06:34 AM 6/22/01, Sriram Parameswar wrote: Jonathan,=20 Your second case (please see below) brings up a very interesting question - do groups have presence? For instance you have said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if some members are online and others are offline? Is the group online or offline?=20 It is my personal opinion that groups do *NOT* have presence, its only the individual members of the group that have presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list.=20 Example:=20 mybuddies =3D=3D=3D=3D> note groups have no presence=20 John =20 Mary =20 Jack =20 Comments?=20 Regards,=20 Sriram=20 __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 -----Original Message-----=20 From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Thursday, June 21, 2001 12:53 AM=20 To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour=20 Marcel'; 'simple@mailman.dynamicsoft.com'=20 Cc: Mayerhofer Andreas A=20 Subject: RE: [Simple] Mobility of Buddy List=20 <<<<<<>>>>>>>>>>>>>>=20 2. a single watcher subscribes to multiple presentities, but aggregates all=20 its subscribe requests into a single subscribe message to its local server.=20 For example, the user would send "SUBSCRIBE sip:mybuddies@mydomain.com". That server generates individual subscriptions for each user in the=20 buddylist. Pictorially:=20 Please view in a fixed-width font such as Courier.=20 /=20 /=20 /=20 / SUB joe=20 /=20 /=20 /=20 +----+ SUB buddies ------+/=20 | | ---------------| | SUB bob=20 | | | |---------------=20 +----+ | |=20 +------+ \=20 user \=20 de- \=20 aggregator \ SUB ralph=20 \=20 \=20 \=20 \=20 These two cases are opposites, really. In the second case, you might want to=20 aggregate the notifications back to the user. This would require an=20 aggregate presence document which represents a group of users. Brian=20 mentions this above. Its something different, and I agree out of scope for=20 now.=20 -Jonathan R.=20 ---=20 Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.=20 Chief Scientist First Floor=20 dynamicsoft East Hanover, NJ 07936=20 jdrosen@dynamicsoft.com FAX: (973) 952-5050=20 http://www.jdrosen.net PHONE: (973) 952-5000=20 http://www.dynamicsoft.com=20 _______________________________________________=20 simple mailing list=20 simple@mailman.dynamicsoft.com=20 http://mailman.dynamicsoft.com/mailman/listinfo/simple=20 =20 ------_=_NextPart_001_01C0FB5D.ADB3BF62 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There doesn’t need to be. =  We just need to define how to work with a presentity.  Whatever an = implementation does to determine the state of the presentity is up to the implementation = (e.g. Brian’s call center example).

 

 

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Friday, June 22, = 2001 1:25 PM
To: Rosen, Brian; 'Rohan = Mahy'; Sriram Parameswar; 'Jonathan Rosenberg'; 'Sean Olson (EUS)'; 'Vencour = Marcel'; 'simple@mailman.dynamicsoft.com'
Cc: Mayerhofer Andreas = A
Subject: RE: [Simple] = Mobility of Buddy List

 

Sounds reasonable.  The term "group-presentity" = may be useful.   is there a formal definition for "group" = now?

thanks,
-r

At 12:26 PM 6/22/01, Rosen, Brian wrote:

I would assert that sip:east-coast-call-center-agents@company.com
is a presentity, and not a group. That presentity obtains it's presence =
status by subscribing to the individual member's presence and then =
advertises its presence according to whatever rules it has.
 
To me, groups are buckets I put people into, and a given person can =
be in more than one bucket (friend, co-worker, volleyball-team-member).  =
If you want the sip:east-coast-call-centeragents@company.com
presentity to define it's state based on all the people in the
east-coast-call-center-agents group, fine.
 
Brian
 

-----Original Message----- =

From: Rohan Mahy [mailto:rohan@cisco.com]

Sent: Friday, June 22, = 2001 3:12 PM

To: Sriram Parameswar; = 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com'

Cc: Mayerhofer Andreas A =

Subject: RE: [Simple] Mobility of Buddy List

Hi,

I'd like to give a counter example: a group that has presence, where the = desired behavior is that if one member of the group is online, then the group is online.

      &nb= sp; sip:east-coast-call-center-agents@company.com

I think the merge policy is up to the PA that is repsonsible for the = merge.

thanks,

-rohan


At 06:34 AM 6/22/01, Sriram Parameswar = wrote:


Jonathan,

Your second case (please see below) brings up = a very interesting question - do groups have presence? For instance you have = said "SUBSCRIBE sip:mybuddies@mydomain.com" - now what happens if = some members are online and others are offline? Is the group online or = offline?

It is my personal opinion that groups do = *NOT* have presence, its only the individual members of the group that have = presence. Hence I strongly feel that individual SUBSCRIBES have to be sent for = each of the members, the resulting NOTIFIES are used to indicate the presence of individual presentities in your buddy list.

Example:

mybuddies =3D=3D=3D=3D> note groups have = no presence

        = John = <Online>

        = Mary = <Offline>

        Jack = <Online>

Comments?

Regards,

Sriram

__________________________________________

Sriram Parameswar          &nb= sp;   Phone: 972-685-8540

Wireless IP MultiMedia (WIPMM)   = Fax: 972-685-3563

Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com

-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Thursday, June 21, 2001 12:53 = AM

To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean = Olson (EUS)'; 'Vencour

Marcel'; = 'simple@mailman.dynamicsoft.com'

Cc: Mayerhofer Andreas A

Subject: RE: [Simple] Mobility of Buddy = List

<<<<<<<snip>>>&g= t;>>>>>>>>>>>

2. a single watcher subscribes to multiple presentities, but aggregates all

its subscribe requests into a single = subscribe message to its local server.

For example, the user would send = "SUBSCRIBE sip:mybuddies@mydomain.com".

That server generates individual = subscriptions for each user in the

buddylist. Pictorially:

Please view in a fixed-width font such as Courier.




       &nbs= p;            = ;            =          /

       &nbs= p;            = ;            =         /

       &nbs= p;            = ;            =        /

       &nbs= p;            = ;            =       / SUB joe

       &nbs= p;            = ;            =      /

       &nbs= p;            = ;            =     /

       &nbs= p;            = ;            =    /

    +----+ SUB buddies     ------+/

    |    | ---------------|      = |      SUB bob

    |    |            =     |      |---------------

    +----+           &= nbsp;    |      |

       &nbs= p;            = ;      +------+ \

     user           &nb= sp;           &nbs= p;   \

       &nbs= p;            = ;      de-        \

       &nbs= p;            = ;      aggregator  \  SUB ralph

       &nbs= p;            = ;            =        \

       &nbs= p;            = ;            =         \

       &nbs= p;            = ;            =          \

       &nbs= p;            = ;            =           \

These two cases are opposites, really. In the = second case, you might want to

aggregate the notifications back to the user. = This would require an

aggregate presence document which represents = a group of users. Brian

mentions this above. Its something different, = and I agree out of scope for

now.

-Jonathan R.

---

Jonathan D. Rosenberg, Ph.D.           &n= bsp;    72 Eagle Rock Ave.

Chief = Scientist          &nbs= p;            = ;      First Floor

dynamicsoft      = ;            =             &= nbsp;  East Hanover, NJ 07936

jdrosen@dynamicsoft.com    = ;            =      FAX:   (973) 952-5050

http://www.jdrosen.net  &nb= sp;           &nbs= p;       PHONE: (973) 952-5000

http://www.dynamicsoft.com=

______________________________________________= _

simple mailing list

simple@mailman.dynamicsoft.com =

http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple

 

=00 ------_=_NextPart_001_01C0FB5D.ADB3BF62-- From jdrosen@dynamicsoft.com Fri Jun 22 17:36:37 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19162 for ; Fri, 22 Jun 2001 17:36:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA23290; Fri, 22 Jun 2001 17:40:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 17:36:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Rohan Mahy , "Rosen, Brian" , Sriram Parameswar , Jonathan Rosenberg , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 17:36:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 3319 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: -----Original Message----- >From: Robert Brown [mailto:roberbr@microsoft.com] >Sent: Friday, June 22, 2001 4:56 PM >To: Rohan Mahy; Rosen, Brian; Sriram Parameswar; Jonathan Rosenberg; Sean Olson >(EUS); Vencour Marcel; simple@mailman.dynamicsoft.com >Cc: Mayerhofer Andreas A >Subject: RE: [Simple] Mobility of Buddy List > > >There doesn't need to be. We just need to define how to work with a >presentity. Whatever an implementation does to determine the state of the >presentity is up to the implementation (e.g. Brian's call center example). There are two cases of what it means to subscribe to a group: 1. The group is a regular presentity, in that it is indistinguishable from a presentity thats a single person. It has an aggregated status that masks the status of individuals within the group. How the state of this group-presentity is determined, and how the set of users in the group are determined, is orthogonal and has no impact of SIMPLE. We don't need to do any work to support this model. There are many, many good uses for these. For example, a presentity can be sip:help-desk@company.com, and this presentity is available so long as any customer support person for company.com is available. 2. The group is not a regular presentity. The set of people within the group are visible at the individual level. That is, I can get a NOTIFY from sip:mybuddies@foo.com, and these notifies contain state for the individuals within that group. Why do this? The benefit is to avoid the overhead of individual refreshes. I can SUBSCRIBE to sip:mybuddies@foo.com, and this causes the foo.com server to generate SUBSCRIBEs for all the users on my buddy list. This does require modest standardization, in the sense that we need to allow for a NOTIFY for a presentity to contain a presence doc for another presentity, and possibly even contain multiple presence docs. -Jonathan R. -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Friday, June 22, 2001 1:25 PM To: Rosen, Brian; 'Rohan Mahy'; Sriram Parameswar; 'Jonathan Rosenberg'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Sounds reasonable. The term "group-presentity" may be useful. is there a formal definition for "group" now? thanks, -r At 12:26 PM 6/22/01, Rosen, Brian wrote: I would assert that sip:east-coast-call-center-agents@company.com is a presentity, and not a group. That presentity obtains it's presence status by subscribing to the individual member's presence and then advertises its presence according to whatever rules it has. To me, groups are buckets I put people into, and a given person can be in more than one bucket (friend, co-worker, volleyball-team-member). If you want the sip:east-coast-call-centeragents@company.com presentity to define it's state based on all the people in the east-coast-call-center-agents group, fine. --- 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 From ssaha@lboard.com Fri Jun 22 18:00:17 2001 Received: from exmail.lboard.com (16.node.lboard.com [204.17.219.16] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19242 for ; Fri, 22 Jun 2001 18:00:16 -0400 (EDT) Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Jun 2001 15:00:02 -0700 Message-ID: From: Subir Saha To: "'Jonathan Rosenberg'" , "'Robert Brown'" , Rohan Mahy , "Rosen, Brian" , Sriram Parameswar , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 15:00:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 4206 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: The idea of a group can also be help full when I have quite a few presentities : cell phone, sip phone, PC and couple of games. All these individually send presence information to my presence server as a group mypresence@presence.com. So my complete presence info can be made available by a single subscription to the watcher. Subir Saha, Ph.D. Senior Product Architect LongBoard Inc. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, June 22, 2001 2:36 PM To: 'Robert Brown'; Rohan Mahy; Rosen, Brian; Sriram Parameswar; Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel; simple@mailman.dynamicsoft.com Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List -----Original Message----- >From: Robert Brown [mailto:roberbr@microsoft.com] >Sent: Friday, June 22, 2001 4:56 PM >To: Rohan Mahy; Rosen, Brian; Sriram Parameswar; Jonathan Rosenberg; Sean Olson >(EUS); Vencour Marcel; simple@mailman.dynamicsoft.com >Cc: Mayerhofer Andreas A >Subject: RE: [Simple] Mobility of Buddy List > > >There doesn't need to be. We just need to define how to work with a >presentity. Whatever an implementation does to determine the state of the >presentity is up to the implementation (e.g. Brian's call center example). There are two cases of what it means to subscribe to a group: 1. The group is a regular presentity, in that it is indistinguishable from a presentity thats a single person. It has an aggregated status that masks the status of individuals within the group. How the state of this group-presentity is determined, and how the set of users in the group are determined, is orthogonal and has no impact of SIMPLE. We don't need to do any work to support this model. There are many, many good uses for these. For example, a presentity can be sip:help-desk@company.com, and this presentity is available so long as any customer support person for company.com is available. 2. The group is not a regular presentity. The set of people within the group are visible at the individual level. That is, I can get a NOTIFY from sip:mybuddies@foo.com, and these notifies contain state for the individuals within that group. Why do this? The benefit is to avoid the overhead of individual refreshes. I can SUBSCRIBE to sip:mybuddies@foo.com, and this causes the foo.com server to generate SUBSCRIBEs for all the users on my buddy list. This does require modest standardization, in the sense that we need to allow for a NOTIFY for a presentity to contain a presence doc for another presentity, and possibly even contain multiple presence docs. -Jonathan R. -----Original Message----- From: Rohan Mahy [mailto:rohan@cisco.com] Sent: Friday, June 22, 2001 1:25 PM To: Rosen, Brian; 'Rohan Mahy'; Sriram Parameswar; 'Jonathan Rosenberg'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Sounds reasonable. The term "group-presentity" may be useful. is there a formal definition for "group" now? thanks, -r At 12:26 PM 6/22/01, Rosen, Brian wrote: I would assert that sip:east-coast-call-center-agents@company.com is a presentity, and not a group. That presentity obtains it's presence status by subscribing to the individual member's presence and then advertises its presence according to whatever rules it has. To me, groups are buckets I put people into, and a given person can be in more than one bucket (friend, co-worker, volleyball-team-member). If you want the sip:east-coast-call-centeragents@company.com presentity to define it's state based on all the people in the east-coast-call-center-agents group, fine. --- 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 Brian.Rosen@marconi.com Fri Jun 22 18:03:19 2001 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 SAA19269 for ; Fri, 22 Jun 2001 18:03:18 -0400 (EDT) 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 SAA25187; Fri, 22 Jun 2001 18:03:03 -0400 (EDT) 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 SAA07405; Fri, 22 Jun 2001 18:03:08 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Jun 2001 18:03:05 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044655F5@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , "'Robert Brown'" , Rohan Mahy , "Rosen, Brian" , Sriram Parameswar , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 18:03:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 4257 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: Doesn't this seem to be a pretty small benefit for a bunch of standardization (you need a way to specify the group, and a way to modify the list,...). It only helps a refresh (a watcher wouldn't get much gain). Could we make this a simpler optimization - something where you ask for multiple refreshes in a single message and get multiple docs back? Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, June 22, 2001 5:36 PM > To: 'Robert Brown'; Rohan Mahy; Rosen, Brian; Sriram Parameswar; > Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel; > simple@mailman.dynamicsoft.com > Cc: Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > > > > > -----Original Message----- > >From: Robert Brown [mailto:roberbr@microsoft.com] > >Sent: Friday, June 22, 2001 4:56 PM > >To: Rohan Mahy; Rosen, Brian; Sriram Parameswar; Jonathan > Rosenberg; Sean > Olson >(EUS); Vencour Marcel; simple@mailman.dynamicsoft.com > >Cc: Mayerhofer Andreas A > >Subject: RE: [Simple] Mobility of Buddy List > > > > > >There doesn't need to be. We just need to define how to work with a > >presentity. Whatever an implementation does to determine > the state of the > >presentity is up to the implementation (e.g. Brian's call > center example). > > There are two cases of what it means to subscribe to a group: > > 1. The group is a regular presentity, in that it is > indistinguishable from a > presentity thats a single person. It has an aggregated status > that masks the > status of individuals within the group. How the state of this > group-presentity is determined, and how the set of users in > the group are > determined, is orthogonal and has no impact of SIMPLE. We > don't need to do > any work to support this model. There are many, many good > uses for these. > For example, a presentity can be sip:help-desk@company.com, and this > presentity is available so long as any customer support person for > company.com is available. > > 2. The group is not a regular presentity. The set of people > within the group > are visible at the individual level. That is, I can get a NOTIFY from > sip:mybuddies@foo.com, and these notifies contain state for > the individuals > within that group. Why do this? The benefit is to avoid the > overhead of > individual refreshes. I can SUBSCRIBE to > sip:mybuddies@foo.com, and this > causes the foo.com server to generate SUBSCRIBEs for all the > users on my > buddy list. This does require modest standardization, in the > sense that we > need to allow for a NOTIFY for a presentity to contain a > presence doc for > another presentity, and possibly even contain multiple presence docs. > > > -Jonathan R. > > > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Friday, June 22, 2001 1:25 PM > To: Rosen, Brian; 'Rohan Mahy'; Sriram Parameswar; 'Jonathan > Rosenberg'; > 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' > Cc: Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > Sounds reasonable. The term "group-presentity" may be > useful. is there a > formal definition for "group" now? > > thanks, > -r > > At 12:26 PM 6/22/01, Rosen, Brian wrote: > > > I would assert that sip:east-coast-call-center-agents@company.com > is a presentity, and not a group. That presentity obtains > it's presence > status by subscribing to the individual member's presence and then > advertises its presence according to whatever rules it has. > > To me, groups are buckets I put people into, and a given person can > be in more than one bucket (friend, co-worker, > volleyball-team-member). > If you want the sip:east-coast-call-centeragents@company.com > presentity to define it's state based on all the people in the > east-coast-call-center-agents group, fine. > > --- > 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 > From roberbr@microsoft.com Fri Jun 22 18:38:24 2001 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA19377 for ; Fri, 22 Jun 2001 18:38:23 -0400 (EDT) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Jun 2001 15:17:19 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 22 Jun 2001 15:15:59 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 15:15:58 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C32EC@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Mobility of Buddy List Thread-Index: AcD7ZsOfO49gFQQFQiuersd5aGdQxgAAM8Jg From: "Robert Brown" To: "Subir Saha" , "Jonathan Rosenberg" , "Rohan Mahy" , "Rosen, Brian" , "Sriram Parameswar" , "Sean Olson (EUS)" , "Vencour Marcel" , Cc: "Mayerhofer Andreas A" X-OriginalArrivalTime: 22 Jun 2001 22:15:59.0340 (UTC) FILETIME=[EA5B5AC0:01C0FB68] Content-Length: 885 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA19377 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: > -----Original Message----- > From: Subir Saha [mailto:ssaha@lboard.com] > Subject: RE: [Simple] Mobility of Buddy List > > The idea of a group can also be help full when I have quite a few > presentities : cell phone, sip phone, PC and couple of games. All these > individually send presence information to my presence server as a group > mypresence@presence.com. So my complete presence info can be made available > by a single subscription to the watcher. If it helps to think of this as grouping, sure, that's a valid conceptual model. But it is purely an implementation decision. A presence agent (server) may support subscription to a presentity representing a person. And it may represent that presentity's state as an aggregation of the presence states of individual devices owned by that person. But this is just the functionality of that particular implementation. From roberbr@microsoft.com Fri Jun 22 19:04:47 2001 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id TAA19466 for ; Fri, 22 Jun 2001 19:04:47 -0400 (EDT) Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Jun 2001 15:35:36 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Jun 2001 15:34:42 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Mobility of Buddy List Date: Fri, 22 Jun 2001 15:34:41 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C32ED@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Mobility of Buddy List Thread-Index: AcD7Y2vWLif5HMToQUW0vPCoGwAqtwABcwnQ From: "Robert Brown" To: "Jonathan Rosenberg" , "Rohan Mahy" , "Rosen, Brian" , "Sriram Parameswar" , "Sean Olson (EUS)" , "Vencour Marcel" , Cc: "Mayerhofer Andreas A" X-OriginalArrivalTime: 22 Jun 2001 22:34:42.0307 (UTC) FILETIME=[87B28530:01C0FB6B] Content-Length: 1528 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id TAA19466 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: > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > 2. The group is not a regular presentity. The set of people within the > group > are visible at the individual level. That is, I can get a NOTIFY from > sip:mybuddies@foo.com, and these notifies contain state for the > individuals > within that group. Why do this? The benefit is to avoid the overhead of > individual refreshes. I can SUBSCRIBE to sip:mybuddies@foo.com, and this > causes the foo.com server to generate SUBSCRIBEs for all the users on my > buddy list. This does require modest standardization, in the sense that we > need to allow for a NOTIFY for a presentity to contain a presence doc for > another presentity, and possibly even contain multiple presence docs. This is an interesting proposal. I do have a concern that in deployments that involve the common use of large groups, real-time group expansion could place a lot of load at a single point in the network and limit scale. A lot of email users are familiar with distribution lists and equate them conceptually to groups. Email servers can get away with this because they don't have a real-time delivery expectation and can afford to store and expand. I'm also wondering about the complexity of state management logic involved - for example will we find this to be of similar complexity to forking INVITE? BTW, has a similar discussion happened for other methods relating to groups? E.g. send IM to a group, start a conference call with a group, etc. From jdrosen@dynamicsoft.com Mon Jun 25 12:28:29 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01667 for ; Mon, 25 Jun 2001 12:28:29 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA18291; Mon, 25 Jun 2001 12:31:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 12:27:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rawlins, Diana'" , "'Zmolek, Andrew (Andrew)'" , Subir Saha , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Centralize Presence Server... Date: Mon, 25 Jun 2001 12:27:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 10752 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: Just to be clear, the SIMPLE group is not specifying architectures for presence. It is not our role to dictate to providers how many presence servers they have, how they are distributed, or even whether there is one. The protocol is flexible enough to operate in a pure peer-to-peer mode without any network servers (the presence agent function resides in the clients), or with a single centralized server for the known universe. -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: Rawlins, Diana [mailto:Diana.Rawlins@wcom.com] Sent: Thursday, June 21, 2001 6:53 PM To: 'Zmolek, Andrew (Andrew)'; Subir Saha; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Centralize Presence Server... A nice feature of a presence server is that it helps scales mobility scenarios and permits a single user oriented uri to be used to locate the presentity's actual contact address. For example, one day I "present myself" on my PDA and the next I may register and "present" my presence application from a desktop with an entirely different contact address. The presence server accepts the subscribe from the watcher addressed to the user and when the presentity for the user become available the contact address information is used by the presence server to facilitate the exchange of presence data between the watcher and presentity --- authorization and access being a prerequisite for the presence exchange. -Diana -----Original Message----- From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] Sent: Thursday, June 21, 2001 1:36 PM To: Subir Saha; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Centralize Presence Server... Initial implementations for simplicity's sake may use a single centralized presence server. The longer-term reality will be closer to domains of presence information with the possibility for multiple aggregators and distributors even within a given domain. There are a lot of possible topologies for the flow of presence information and the centralized model is only one of them. When a critical mass of presence service information is available, things will get decentralized in a hurry. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Subir Saha [mailto:ssaha@lboard.com] Sent: Thursday, June 21, 2001 10:30 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] Centralize Presence Server... Reading through the SIMPLE drafts and mailing list, it looks like a centralize presence server is not must. Even the value of such an entity is not well understood. However I see lot of vendors are working on a centralized presence server in a big way. Any comments? Subir Saha, Ph.D. Sr Product Architect LongBoard Inc. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, June 19, 2001 9:14 AM To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Hang on here... I think we are all talking about a few different things. First off, in my mind, the definition of a "buddy list" is the set of presentities that a particular user is subscribed to. Lets just make sure we are clear about that. Where this list is stored, and what happens to my subscriptions when I go offline, are two very different things. First off, where is it stored? One place is in the client. This doesn't mean that its deleted when I log off; it would presumably be stored on disk in some way. When the client app is restarted, it looks at that list and generates subscription refreshes for all of the users in the buddy list. The drawback of storing it on the client is that it ties you to a particular desktop. An alternative idea is to store it on a server in the network (this need NOT be the same as the presence server or proxy server or anything else). So, when I start my client app, it goes to a web server, say, and fetches my buddy list. Then, the client app sends a SUBSCRIBE for all of the entries there. Now, I can sit down at any machine, and log in, and then get my buddy list there. This was the motivation for our buddy list format proposal as part of last summer's SIMPLE proposal: http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt In this model, the buddylist is only stored on the web server, but edited on the client. Now, if you go for the model where it can be edited on the web server as well, you run into this synchronization problem. Now, you need to keep interested entities (like my client app) aware of changes to this list that are made. There, having an event package for the "state" of my buddy list makes sense. I think this is what Sean is talking about. Now, a separate issue is what happens to my subscriptions when I go offline. Well, the nice behavior is to unSUBSCRIBE. If you don't, the presence server will eventually send a NOTIFY which either generates a 481 or 404, or a timeout, in which case the presence server would delete the subscription. Please note that this is totally unrelated to the state of my buddy list. This subscription is at the presence server of the presentity, whilst the buddy list is stored at a server in the domain of the watcher. They are totally unrelated. Brian is talking about a different model still. In this model, the buddy list isn't just stored and edited on the server, the server uses it to generate subscriptions directly. Effectively, the server becomes the watcher. If 10 people in its domain subscribe to some user bob, the server sends only one SUBSCRIBE to bob. The server can then use this to deliver notifications to the clients in its domain. The result is aggregation, in that fewer messages need to be sent out to the presentities (1 instead of 10 in the example). However, there is a serious security issue in this model, in that the presentity has no way to know the end user which is requesting the subscription. This approach, which is what I think Brian is talking about, is discussed in the original sip for presence draft: http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt 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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, June 19, 2001 11:22 AM To: 'Sean Olson (EUS)'; 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List You might get the LIST this way, but getting the updates may be problematic because all of your buddies may not be served by the same presence server. You could imagine a server proxy that would do this; the list had a full subscription info, the proxy got the individual Notifies and created one composite Notify. A mobile client might like this a lot, but it's less interesting for "well connected" clients because little aggregation occurs unless there are "popular" buddies where the proxy can use one Notify as input for many lists. Still, it's a worthy idea, and sounds pretty cheap. Seems to me the only protocol impact is that you need a composite Notify that gets you all the presence information in the list as one message. Brian -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Tuesday, June 19, 2001 9:47 AM To: 'Vencour Marcel'; 'simple@mailman.dynamicsoft.com' Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List I was thinking a little about this. What about the possibility of subscribing to your buddy list? The buddy list could be stored offline in, for example, a database. A SUBSCRIBE request with Event: presence.targets (?) would retrieve the static buddy list in a NOTIFY as well as subsequent updates in future NOTIFYs. The buddy list could also be tailored for the client/terminal. Comments? /sean -- Sean Olson Ericsson Inc. >-----Original Message----- >From: Vencour Marcel [mailto:marcel.vencour@siemens.at] >Sent: Tuesday, June 19, 2001 7:41 AM >To: 'simple@mailman.dynamicsoft.com' >Cc: Mayerhofer Andreas A >Subject: [Simple] Mobility of Buddy List > > >Hello everybody, > >I have a problem concerning the buddy list used in a presence >service: The >question is, where is the buddy list of the watcher stored >when the watcher >goes offline? If it is stored in a file/database at the location of the >watcher, then it is bound to the watcher's client, i.e. it >does not move >around with the watcher (here watcher means the person, not >the client used >by that person) when he uses different machines to do his >watching. Thus the >buddy list would have to be stored at the presence >server/presence agent >(PS). But in this case how can the watcher go offline without >deleting his >buddy list at the PS? If he goes offline without sending any >unsubscribe >then the PS would continue to send notifications to the >watcher which of >course is unnecessary overhead. On the other hand, if the watcher goes >offline and sends unsubscribes for all his buddies then the >buddy list would >be removed from the PS. >The next question then is, what happens when the watcher goes >online again? >How can he send a subscribe without giving a buddy in the >request line (just >to tell that he is online and thus wants to receive >notifications again)? > >Thanks in advance for an answer, M. Vencour. > >_______________________________________________ >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 dsimons@windows.microsoft.com Mon Jun 25 12:50:39 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA01738 for ; Mon, 25 Jun 2001 12:50:25 -0400 (EDT) Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Jun 2001 09:36:01 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Jun 2001 09:35:53 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 25 Jun 2001 09:35:27 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 25 Jun 2001 09:34:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Mon, 25 Jun 2001 09:34:57 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC14636B9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Thoughts on uploading authorization documents Thread-Index: AcD2jLtddSrXml/LRDmAnEVXo1c9WQHByFXQ From: "David Simons" To: "Jonathan Rosenberg" , "Neil Deason" , , "Robert Brown" , X-OriginalArrivalTime: 25 Jun 2001 16:34:57.0487 (UTC) FILETIME=[C5619DF0:01C0FD94] Content-Length: 5187 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA01738 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: Jonathan's comment below about SOAP over HTTP being equal to SOAP in a sip message assume the topology of a deployed HTTP and SIP network are always that same. And that it is a trivial task to map a SIP address to an HTTP address (URL) in a generic way. I believe that neither of these is correct. Deployment of SIP shouldn't require deployment of HTTP. Never should we require this. All solutions that SIMPLE determines useful enough to standardize should have a SIP solution. I believe those of us that advocate SOAP over SIP are only advocating its use in support of a SIP deployment not as a general application server solution. Regards, David J. Simons Development Lead Microsoft Windows RTC -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Saturday, June 16, 2001 10:47 AM To: 'Neil Deason'; adam.roach@ericsson.com; Robert Brown; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Wednesday, June 13, 2001 5:19 AM > To: adam.roach@ericsson.com; 'Robert Brown'; Jonathan Rosenberg; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Thoughts on uploading authorization documents > > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of > > adam.roach@ericsson.com > > Sent: 12 June 2001 17:44 > > To: 'Robert Brown'; Jonathan Rosenberg; > simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Thoughts on uploading authorization documents > So how about this for a converged application > providing a new service. Say I am finishing work in the > UK but want to know the value of my shares portfolio > when the US markets close. However, I am going to the pub > after work and due to fear of immediate notification of my > losses sending me on a major drinking binge I prefer the > results to be emailed to my work account. Besides, then I > can work out what impact it has on my planned retirement > date on the companies time in the morning which seems only > fair. > > I can have this service today through an application > that has wisely decided to support SIP for its flexibility > and extensibility. As I leave I send a MESSAGE to my broker's > stock watcher service carrying a SOAP payload. This is the part that baffles me. Stock price notification is a classic SOAP application, and something that people are using SOAP over HTTP for. You can build exactly this app, as you describe it, with regular, normal, well-defined, w3c supported SOAP over HTTP. Why does it ALL have to be SIP? Would you propose that the email that gets sent to be over SIP too?? In fact, SOAP, as I understand it, is most commonly used between back end systems, and so is not likely to be seen by client devices in many cases.. > > Using SOAP for encoding this message in XML works _today_. > Using MESSAGE for transporting a XML message doesn't seem > that unreasonable to me. What is the value proposition over regular SOAP over HTTP? You now need to go out to all these B2B e-commerce guys and convince them to send you SOAP messages in SIP instead of HTTP. Why? There is no user discovery, there is no session (as there is for both presence and IM). SIP provides little value in this scenario. > After all if MESSAGE should only be > used as seen to date, to carry plain/text for simple IM > clients, we should redefine the semantics of INVITE to be > a method for only setting up telephony calls. MESSAGE can carry all different types of content, but the semantics of what MESSAGE means remains unchanged - this content is for rendering to a person. > > Finally using SIP in general means I can use the end to > end authentication and encryption (well one day) mechanisms > for security. It means that providers can offer the service > reusing their SIP infrastructure so making a cost saving. But the SOAP messages are not routed to a "person" (for which existing SIP infrastructure is built to support), they are sent to an ecommerce stock site, in your example. Such a thing doesn't move around, doesn't have multiple points of attachment, etc., all of the things that a SIP network is built to support. > It means that hand held devices can use the same protocol > from IM + Presence as well as this additional type of > service. So is the consensus that this is reasonable use > or abuse? Using the "same protocol" needs to be considered carefully. It makes sense only when there is a strong tie between the needed function and the existing protocols. -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 ffo@ifrance.com Mon Jun 25 14:49:04 2001 Received: from lh11.opsion.fr (lh11.opsion.fr [212.73.208.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA02094 for ; Mon, 25 Jun 2001 14:49:03 -0400 (EDT) Received: from 193.250.247.224 [193.250.247.224] by lh11.opsion.fr; Mon, 25 Jun 2001 18:50:05 GMT Message-ID: <000a01c0fda7$3aabb070$e0f7fac1@ffocp800> Reply-To: "Francois-Frederic Ozog" From: "Francois-Frederic Ozog" To: Cc: , , , Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Mon, 25 Jun 2001 20:47:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C0FDB7.FD6326B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 1636 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: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C0FDB7.FD6326B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, I hope you could explain why SOAP is more desirable than plain XML in = SIMPLE context: 1) what do we have with it ? 2) what do we miss without it ? Thank you ------=_NextPart_000_0007_01C0FDB7.FD6326B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
David,
 
I hope you could explain why SOAP is = more desirable=20 than plain XML in SIMPLE context:
1) what do we have with it = ?
2) what do we miss without it = ?
 
Thank you
 
------=_NextPart_000_0007_01C0FDB7.FD6326B0-- ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif From ndeason@ubiquity.net Tue Jun 26 04:50:02 2001 Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA04292 for ; Tue, 26 Jun 2001 04:50:01 -0400 (EDT) Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca via smtpd (for [216.173.40.35]) with SMTP; 26 Jun 2001 09:49:49 UT Received: (private information removed) Message-ID: From: Neil Deason To: Francois-Frederic Ozog , dsimons@windows.microsoft.com Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Tue, 26 Jun 2001 04:50:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1031 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: XML is a markup language that allows you to define your own tags and attributes. 'Plain XML' is never going to be that useful. Typically you use XML to build something else, e.g. CPL, which is then defined by a XML schema. SOAP is a pre-defined and extensible XML vocabulary for describing generic messages. These SOAP messages can be specified within WSDL. Which is more desirable therefore depends on what you want to do. What consensus there is about SOAP and SIP seems to indicate that _if_ SIP should be able to carry SOAP then defining a new method is the way to go about. SERVICE has been floated in this context. As such it would be compatible with, but not directly part of, SIMPLE. The SIPPING list is probably the most appropriate forum for discussion of this topic. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net David, I hope you could explain why SOAP is more desirable than plain XML in SIMPLE context: 1) what do we have with it ? 2) what do we miss without it ? Thank you From ffo@ifrance.com Tue Jun 26 08:19:23 2001 Received: from lh09.opsion.fr (lh09.opsion.fr [212.73.208.235]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id IAA04852 for ; Tue, 26 Jun 2001 08:19:22 -0400 (EDT) Received: from 193.249.124.133 [193.249.124.133] by lh09.opsion.fr; Tue, 26 Jun 2001 12:20:28 GMT Message-ID: <000401c0fe39$f874a980$857cf9c1@ffocp800> Reply-To: "Francois-Frederic Ozog" From: "Francois-Frederic Ozog" To: "Neil Deason" , Cc: References: Subject: Re: [Simple] Thoughts on uploading authorization documents Date: Tue, 26 Jun 2001 14:17:25 +0200 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 4616 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: Thanks Neil, I agree that SOAP is very powerful. When I see WSDL descriptions such as the one following the one attached, I cannot do but think that SIP payloads will become very big and the computing resources needed to handle them may be to important. As Jonathan said, the group does not focus on architecture and a presence agent may end-up in a PDA. As the size of SOAP client for Windows is already 1.5MB (http://msdn.microsoft.com/downloads/default.asp?URL=/code/sample.asp?url=/m sdn-files/027/001/580/msdncompositedoc.xml), I am quite concerned about keeping SIMPLE ubiquitous (from server to PDA). Alternatively, the group could drop some design goals like the mobility of the Presence Agent. What do you think? net.xmethods.services.currencyexchange.CurrencyExchange web service ----- Original Message ----- From: "Neil Deason" To: "Francois-Frederic Ozog" ; Cc: Sent: Tuesday, June 26, 2001 10:50 AM Subject: RE: [Simple] Thoughts on uploading authorization documents > XML is a markup language that allows you to define your > own tags and attributes. 'Plain XML' is never going to be > that useful. Typically you use XML to build something > else, e.g. CPL, which is then defined by a XML schema. > SOAP is a pre-defined and extensible XML vocabulary for > describing generic messages. These SOAP messages can be > specified within WSDL. > > Which is more desirable therefore depends on what you want > to do. What consensus there is about SOAP and SIP seems > to indicate that _if_ SIP should be able to carry SOAP then > defining a new method is the way to go about. SERVICE has > been floated in this context. As such it would be compatible > with, but not directly part of, SIMPLE. The SIPPING list > is probably the most appropriate forum for discussion of > this topic. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > David, > > I hope you could explain why SOAP is more desirable than plain XML in > SIMPLE context: > 1) what do we have with it ? > 2) what do we miss without it ? > > Thank you > > ______________________________________________________________________________ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif From ndeason@ubiquity.net Tue Jun 26 09:01:31 2001 Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA04992 for ; Tue, 26 Jun 2001 09:01:30 -0400 (EDT) Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca via smtpd (for [216.173.40.35]) with SMTP; 26 Jun 2001 14:01:19 UT Received: (private information removed) Message-ID: From: Neil Deason To: Francois-Frederic Ozog , dsimons@windows.microsoft.com Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Thoughts on uploading authorization documents Date: Tue, 26 Jun 2001 09:03:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2030 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: > I agree that SOAP is very powerful. When I see WSDL > descriptions such as the > one following the one attached, I cannot do but think that > SIP payloads will > become very big and the computing resources needed to handle > them may be to > important. The WSDL would not go in the payload of a SIP message carrrying SOAP!! Just like the fact that the CPL DTD does not go in a REGISTER when uploading scripts. IP fragamentation can be an issue for any large SIP messages over UDP but it applies in exactly the same way to PIDF, CPL, SOAP and indeed any other XML based content. The same computing resources are required for these type of applications too. (Bear in mind that that PDAs with 200+ MHz processors and 64M RAM are around today). > As Jonathan said, the group does not focus on architecture > and a presence > agent may end-up in a PDA. As the size of SOAP client for > Windows is already > 1.5MB > (http://msdn.microsoft.com/downloads/default.asp?URL=/code/sam > ple.asp?url=/m > sdn-files/027/001/580/msdncompositedoc.xml), I am quite > concerned about > keeping SIMPLE ubiquitous (from server to PDA). > Alternatively, the group > could drop some design goals like the mobility of the Presence Agent. > > What do you think? I don't think you should base estimations of size on the installation executable of a single implementation written for a completely different environment. Why not conclude all SOAP libraries will be 131KB instead? (Size of the Apache SOAP library.) Supporting mobility of Presence Agent is obviously a fundamental design goal for SIMPLE. However, it seems likely to me that most SIMPLE devices will need to support SIP and XML as a baseline. This naturally opens the way for them to run SOAP over SIP for services. Memory and processor limited devices actually benefit from this type of protocol re-use. But as I said previously this is really a matter for outside of SIMPLE. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net From jdrosen@dynamicsoft.com Tue Jun 26 16:51:08 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06316 for ; Tue, 26 Jun 2001 16:51:08 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA18820 for ; Tue, 26 Jun 2001 16:55:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Jun 2001 16:51:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Tue, 26 Jun 2001 16:51:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 7394 Subject: [Simple] Open issue: migration of subscriptions 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: Folks, I'd like to begin a thread on another presence open issue that we discussed at IETF 49. The issue is with migration of subscriptions. It is discussed in section 6.1 of http://www.jdrosen.net/papers/draft-ietf-simple-presence-00.txt. The idea is that when a subscription refresh arrives, a presence server can destroy the subscription state, and proxy the request to the PUA, which accepts it there. The draft indicates that this is problematic for a few reasons: 1. the refresh has to and from tags which don't match an existing subscription state in the PUA. This means defining special case tag handling. Tags are awful enough as it is. 2. The route set is already established, and in this route set, the presence server has inserted the contact. When the presence server acts as a proxy, it now needs to add itself into the route set with a record-route, and the contact needs to be updated to be that of the PUA. This kind of route set update is not possible. Only the contact can change; record-route headers cannot be added. Some additional problems: 3. The migration to the PUA is very gradual, taking up to the duration of the longest subscription refresh interval. 4. It is not clear how to get the subscriptions to migrate back to the presence server, since the PUA isn't a proxy and can't begin proxying them there. I have a proposal on how to fix these problems. The approach is to use our new friend, the watcherinfo sub-package. Here's how it works. Lets say A subscribes to B, with the event package presence. Initially, these subscriptions are handled by the presence server in B's domain, which acts as a PA. A also subscribes to B using the event package presence.watcherinfo. B's presence server allows this subscription, but won't provide A with all information on B's watchers. Rather, A gets notified only of changes to A's subscription state for B (in other words, the presence server will, by default, filter the information sent to subscribers for Bs presence.watcherinfo). At some point, the presence server decides to migrate the subscriptions to B directly. So, it destroys the subscriptions for B, which results in a notification to the those subscribed to presence.watcherinfo for B (which includes A). A will therefore get a NOTIFY indicating that their subscription is invalidated. A then re-SUBSCRIBEs, using a brand new Call-ID (i.e., its not a refresh within the existing call leg, its a totally new one). The presence server proxies these to B. Since these are brand new subscriptions, they establish a new route set, which can include the presence server of B on the record-route list. A also needs to re-SUBSCRIBE to presence.watcherinfo for B, as this too will now be handled by the B (note that I do not think we need to support A subscribing to presence.watcherinfo.watcherinfo to determine that its subsription to presence.watcherinfo for B has been terminated; this can be implied from the destruction of its presence subscription. Without this, we have infinite recursion of subscriptions). Now, at any time, B can also destroy subscription states. This causes notifications to go to the subcribers of presence.watcherinfo for A. They can re-SUBSCRIBE once more, and the presence server can terminate them this time around. To be specific, here is the call flow: | SUB B presence C-ID: 10 | | |------------------------>| | | 202 Accepted | | |<------------------------| | | | | | SUB B pres.winfo C-ID 11| | |------------------------>| | | 202 Accepted | | |<------------------------| | | | | | NOT A pres.winfo C-ID 11| | | sub. invalidated | server decides | |<------------------------| to migrate subs. | | 200 OK | | |------------------------>| | | SUB B presence C-ID: 12 | | |------------------------>| SUB B presence C-ID: 12 | | |-------------------------->| | | 202 Accepted | | 202 Accepted |<--------------------------| |<------------------------| | | SUB B pres.winfo CID: 13| | |------------------------>| SUB B pres.winfo CID: 13 | | |-------------------------->| | | 202 Accepted | | 202 Accepted |<--------------------------| |<------------------------| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A B's B presence server I've left off some details, such as the initial NOTIFY after the SUBSCRIBE, and the authorization. Also, how the presence server decides to migrate the subscriptions is orthogonal. It could be because B registered support for the SUBSCRIBE method, or perhaps the user clicked on a web page or something. Its not shown. I think this is a fairly clean way to handle migrations, but it introduces some of the burden for this at the subscriber; namely, when I subscribe to B, I also need to subscribe to B's presence.watcherinfo to learn the status of my subscription. Worst case, if this second subscription is not done, when the first (the normal presence subscription) is refreshed, it generates a 481 at B's presence server. This can then trigger A to generate a brand new subscription (with a new Call-ID) which will migrate at that point. This means we need to additionally specify that a 481 response to a SUBSCRIBE refresh should cause a new subscription to be made. I think thats reasonable. We will also need to somehow allow a SUBSCRIBE to a presence.watcherinfo package to indicate that the subscription is desired for a particular watcher only. Not too hard. Comments? -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 From jdrosen@dynamicsoft.com Wed Jun 27 03:45:58 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08063 for ; Wed, 27 Jun 2001 03:45:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA26205; Wed, 27 Jun 2001 03:49:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Jun 2001 03:45:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Jonathan Rosenberg , Rohan Mahy , "Rosen, Brian" , Sriram Parameswar , "Sean Olson (EUS)" , Vencour Marcel , simple@mailman.dynamicsoft.com Cc: Mayerhofer Andreas A Subject: RE: [Simple] Mobility of Buddy List Date: Wed, 27 Jun 2001 03:45:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 4772 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Friday, June 22, 2001 6:35 PM > To: Jonathan Rosenberg; Rohan Mahy; Rosen, Brian; Sriram Parameswar; > Sean Olson (EUS); Vencour Marcel; simple@mailman.dynamicsoft.com > Cc: Mayerhofer Andreas A > Subject: RE: [Simple] Mobility of Buddy List > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > 2. The group is not a regular presentity. The set of people > within the > > group > > are visible at the individual level. That is, I can get a > NOTIFY from > > sip:mybuddies@foo.com, and these notifies contain state for the > > individuals > > within that group. Why do this? The benefit is to avoid the overhead > of > > individual refreshes. I can SUBSCRIBE to sip:mybuddies@foo.com, and > this > > causes the foo.com server to generate SUBSCRIBEs for all > the users on > my > > buddy list. This does require modest standardization, in the sense > that we > > need to allow for a NOTIFY for a presentity to contain a > presence doc > for > > another presentity, and possibly even contain multiple > presence docs. > > This is an interesting proposal. > > I do have a concern that in deployments that involve the common use of > large groups, real-time group expansion could place a lot of load at a > single point in the network and limit scale. A lot of email users are > familiar with distribution lists and equate them conceptually > to groups. > Email servers can get away with this because they don't have > a real-time > delivery expectation and can afford to store and expand. I suppose this could be an issue, yes. However, it seems no different than the general scaling issues with any sort of network server. The standard techniques of load balancing, coupled with the benefits of Moore's law, are on your side as always. I think its up to the operators of these servers to make sure they are big enough to handle whatever groups they are trying to handle. > > I'm also wondering about the complexity of state management logic > involved - for example will we find this to be of similar > complexity to > forking INVITE? Goodness, no. The group server in this model is more like a B2BUA, which is conceptually (and programming-wise) simpler than a forking proxy. There is certainly state here. For any given group foo, the server will need to maintain the list of subscribers to foo and their associated state, and also maintain the subscriptions to the users comprising the group foo, and their state. Brian Rosen wrote: > Doesn't this seem to be a pretty small benefit for a bunch of > standardization (you need a way to specify the group, and a way > to modify the list,...). It only helps a refresh (a watcher > wouldn't get much gain). I think that group management would be outside of the scope of our concerns. Typically, web interfaces would be used, voice browsers, or whatever, none of which require standardization. Specifying groups is easy; they are just SIP URLs that you know are groups. Much like for SIP conferences; its a request URI that just happens to be a conference resource. > > Could we make this a simpler optimization - something where > you ask for multiple refreshes in a single message and get > multiple docs back? That was the idea; the SUBSCRIBE has a group in the R-URI, and this results in NOTIFYs that contain presence docs from different users. I was not proposing that there is some way to merge the presence docs from the users in the group. Robert Brown wrote: > > BTW, has a similar discussion happened for other methods relating to > groups? E.g. send IM to a group, start a conference call > with a group, > etc. > IM-ing to a group has been discussed a bit. When you take the approach of IM-as-a-stream, as has been proposed (and I think there was consensus for), group conferences are really easy, as they are done identically to the way they are done for regular INVITE-initiated sessions. There are many mecahnisms for conferencing in SIP, documented in: http://www.jdrosen.net/papers/draft-rosenberg-sip-conferencing-models-00.txt All of these would then work for IM. If you work with IM as a standalone message, conferencing becomes more complex, and then you need to explicitly think about how things like distribution lists might work, and define support for them. -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 From jdrosen@dynamicsoft.com Thu Jun 28 19:33:29 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14272 for ; Thu, 28 Jun 2001 19:33:28 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA03678 for ; Thu, 28 Jun 2001 19:37:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 19:33:28 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Thu, 28 Jun 2001 19:33:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3277 Subject: [Simple] Another idea for presence authorization 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: Folks, I was in the process of writing up the consensus to date on presence authorization, and I had another idea on uploading authorization for the subscriptions. The approach is a hybrid between the intitial "post a document to an http URL" idea, and the AUTH or SERVICE methods in SIP. Here's the idea. B is some presentity. B subscribes to his own watcher information. When A subscribes to B's presence, B gets notified of a pending subscription. This comes in a NOTIFY carrying a watcher information data format. This data format has, as part of its definition, URLs that can be used to accept or reject the subscription. So, for example, B would get a NOTIFY like: NOTIFY sip:B@computer.bar.com SIP/2.0 From: sip:B@bar.com To: sip:B@bar.com Content-Type: application/watcherinfo+xml Event: presence.winfo http://bar.com/approve.cgi?user=A&watcher=B http://bar.com/reject.cgi?user=A&watcher=B Now, if B wants to approve the subscription, the URL within the approve tags is taken and used, and if it wants to reject, the one within the reject tags is used. Of course, the http POST needs to be authenticated. That can be done with digest over https, and the username and password provided would be checked against the same back end database that holds the SIP username and passwords. No document formats or anything else are generated. Now, the benefits of this approach are: 1. no need to define an authorization policy data format 2. no need to standardize a mapping from sip URLs to http URLs, which was one of the main (and valid) objections to the initial HTTP approach. 3. the server chooses the URLs for approval and rejection, their structure has no semantics anywhere outside of the server. 4. views approval and rejection as form post operations, which is what they really are (indeed, I expect offline authorization systems to be entirely web based, with forms as the primary tool for setting data. Indeed, the same back end cgi scripts can be used, which is very nice) The drawbacks: 1. still reuqires http. Now, you could, in principle, put a sip url in there instead of an http URL, but I think thats pushing it a bit. I really think that this kind of thing is a form post operation. This kind of mecahnism is, BTW, exactly how collected data is passed in VXML systems. 2. doesn't allow more complex policies to be set *this* way; you can still set authorization policy through CPLs, web interfaces, and so on. This mechanism would just automate the baseline case of approve/reject. Indeed, we could even have another tag, , which has a URL you can visit for an interactive web session to set arbitrarily complex policies. Comments? -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 From jdrosen@dynamicsoft.com Fri Jun 29 00:43:47 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15072 for ; Fri, 29 Jun 2001 00:43:47 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA04921 for ; Fri, 29 Jun 2001 00:47:55 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 00:43:46 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 29 Jun 2001 00:43:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5204 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: An additional thought below... > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, June 28, 2001 7:33 PM > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] Another idea for presence authorization > > > Folks, > > I was in the process of writing up the consensus to date on presence > authorization, and I had another idea on uploading > authorization for the > subscriptions. The approach is a hybrid between the intitial "post a > document to an http URL" idea, and the AUTH or SERVICE > methods in SIP. > > Here's the idea. B is some presentity. B subscribes to his own watcher > information. When A subscribes to B's presence, B gets > notified of a pending > subscription. This comes in a NOTIFY carrying a watcher > information data > format. This data format has, as part of its definition, URLs > that can be > used to accept or reject the subscription. So, for example, B > would get a > NOTIFY like: > > NOTIFY sip:B@computer.bar.com SIP/2.0 > From: sip:B@bar.com > To: sip:B@bar.com > Content-Type: application/watcherinfo+xml > Event: presence.winfo > > > > event="subscribe"> > http://bar.com/approve.cgi?user=A&watcher=B > http://bar.com/reject.cgi?user=A&watcher=B > > > > > > Now, if B wants to approve the subscription, the URL within > the approve tags > is taken and used, and if it wants to reject, the one within > the reject tags > is used. Of course, the http POST needs to be authenticated. > That can be > done with digest over https, and the username and password > provided would be > checked against the same back end database that holds the SIP > username and > passwords. No document formats or anything else are generated. > > Now, the benefits of this approach are: > > 1. no need to define an authorization policy data format > 2. no need to standardize a mapping from sip URLs to http > URLs, which was > one of the main (and valid) objections to the initial HTTP approach. > 3. the server chooses the URLs for approval and rejection, > their structure > has no semantics anywhere outside of the server. > 4. views approval and rejection as form post operations, > which is what they > really are (indeed, I expect offline authorization systems to > be entirely > web based, with forms as the primary tool for setting data. > Indeed, the same > back end cgi scripts can be used, which is very nice) > > The drawbacks: > > 1. still reuqires http. Now, you could, in principle, put a > sip url in there > instead of an http URL, but I think thats pushing it a bit. I > really think > that this kind of thing is a form post operation. This kind > of mecahnism is, > BTW, exactly how collected data is passed in VXML systems. Thinking about this more, I think there is merit in having a SIP URL in there, but the meaning of that is different than what people have been thinking (but more in line with what sip is actually for). A SIP URL here would mean that "use this to initiate a session to some IVR or something else which will use voice prompts to authenticate you and then change the authorization policy. So, for example, you might have: http://bar.com/approve.cgi?user=A&watcher=B sip:vxml.approve@vxmlservers.com http://bar.com/reject.cgi?user=A&watcher=B So, a client now has a choice. If http enabled, it can post the form data to approve or reject. If its voice only, it can call the SIP URL provided. That would go to a VXML server, which might interact with the user like this: VXML server: "please say your username" user: joe VXML server: "please say or enter your pin" user: 7654 VXML server: "to authorize the subscription from A, please say yes" user: yes VXML server: "thank you. User A now approved. Bye." The VXML server would then form post the data to a web server thats managing the authorization list. So, really, the idea here is that there are many potential user interfaces one might take advantage of for managing the authorization list: 1. web pages 2. custom GUI application 3. voice interaction we want to separate the way the UI is done from the interface to the application. For 2 of the three above (web, voice interaction), the standard interface is already defined as http form posts. Seems natural to extend that further to the second case, by doing what I am proposing above. -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 From jdrosen@dynamicsoft.com Fri Jun 29 01:23:20 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15201 for ; Fri, 29 Jun 2001 01:23:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA05012; Fri, 29 Jun 2001 01:27:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 01:23:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 29 Jun 2001 01:23:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 5429 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Friday, June 29, 2001 12:57 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > I think the other objection to HTTP GET was that the fact that a route > exists that can deliver a NOTIFY SIP request to B doesn't imply that > HTTP connectivity is possible between wherever B is and the > host that is > addressed in the HTTP request. After all, there is no guarantee that > the entity that issued the notification has omnipotence regarding the > firewalls or HTTP proxies between B and the HTTP servers expressed in > the notification. Well, unlike SIP which has known firewall and nat issues, http works pretty darn well. I don't see this as a real problem. > > Now, certainly, this would work in many cases. But there are > likely to > be situations where this assumption is not valid. Such as? -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: Thursday, June 28, 2001 4:33 PM > > To: 'simple@mailman.dynamicsoft.com' > > Subject: [Simple] Another idea for presence authorization > > > > Folks, > > > > I was in the process of writing up the consensus to date on presence > > authorization, and I had another idea on uploading authorization for > the > > subscriptions. The approach is a hybrid between the intitial "post a > > document to an http URL" idea, and the AUTH or SERVICE > methods in SIP. > > > > Here's the idea. B is some presentity. B subscribes to his > own watcher > > information. When A subscribes to B's presence, B gets notified of a > > pending > > subscription. This comes in a NOTIFY carrying a watcher information > data > > format. This data format has, as part of its definition, > URLs that can > be > > used to accept or reject the subscription. So, for example, B would > get a > > NOTIFY like: > > > > NOTIFY sip:B@computer.bar.com SIP/2.0 > > From: sip:B@bar.com > > To: sip:B@bar.com > > Content-Type: application/watcherinfo+xml > > Event: presence.winfo > > > > > > > > > event="subscribe"> > > http://bar.com/approve.cgi?user=A&watcher=B > > http://bar.com/reject.cgi?user=A&watcher=B > > > > > > > > > > > > Now, if B wants to approve the subscription, the URL within the > approve > > tags > > is taken and used, and if it wants to reject, the one within the > reject > > tags > > is used. Of course, the http POST needs to be > authenticated. That can > be > > done with digest over https, and the username and password provided > would > > be > > checked against the same back end database that holds the > SIP username > and > > passwords. No document formats or anything else are generated. > > > > Now, the benefits of this approach are: > > > > 1. no need to define an authorization policy data format > > 2. no need to standardize a mapping from sip URLs to http > URLs, which > was > > one of the main (and valid) objections to the initial HTTP approach. > > 3. the server chooses the URLs for approval and rejection, their > structure > > has no semantics anywhere outside of the server. > > 4. views approval and rejection as form post operations, > which is what > > they > > really are (indeed, I expect offline authorization systems to be > entirely > > web based, with forms as the primary tool for setting data. Indeed, > the > > same > > back end cgi scripts can be used, which is very nice) > > > > The drawbacks: > > > > 1. still reuqires http. Now, you could, in principle, put a > sip url in > > there > > instead of an http URL, but I think thats pushing it a bit. I really > think > > that this kind of thing is a form post operation. This kind of > mecahnism > > is, > > BTW, exactly how collected data is passed in VXML systems. > > 2. doesn't allow more complex policies to be set *this* way; you can > still > > set authorization policy through CPLs, web interfaces, and > so on. This > > mechanism would just automate the baseline case of approve/reject. > Indeed, > > we could even have another tag, , which has a URL you can > visit > > for an interactive web session to set arbitrarily complex policies. > > > > > > Comments? > > > > -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 roberbr@microsoft.com Fri Jun 29 01:59:14 2001 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id BAA15319 for ; Fri, 29 Jun 2001 01:59:14 -0400 (EDT) Received: from 157.54.9.101 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Jun 2001 21:54:12 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Jun 2001 21:56:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Another idea for presence authorization Date: Thu, 28 Jun 2001 21:56:44 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C3316@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Another idea for presence authorization Thread-Index: AcEAK4L8nc/+7qblTdyGoJHVsju+GQAKbNWQ From: "Robert Brown" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 29 Jun 2001 04:56:34.0648 (UTC) FILETIME=[DEFECD80:01C10057] Content-Length: 4672 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id BAA15319 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: I think the other objection to HTTP GET was that the fact that a route exists that can deliver a NOTIFY SIP request to B doesn't imply that HTTP connectivity is possible between wherever B is and the host that is addressed in the HTTP request. After all, there is no guarantee that the entity that issued the notification has omnipotence regarding the firewalls or HTTP proxies between B and the HTTP servers expressed in the notification. Now, certainly, this would work in many cases. But there are likely to be situations where this assumption is not valid. For this reason it is tempting to also allow a SIP URL. However, it isn't clear how this can be accomplished without also pre-defining other semantics for how the URL is to be used. Even with HTTP we have to define that this is a GET, but this is a pretty easy definition. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, June 28, 2001 4:33 PM > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] Another idea for presence authorization > > Folks, > > I was in the process of writing up the consensus to date on presence > authorization, and I had another idea on uploading authorization for the > subscriptions. The approach is a hybrid between the intitial "post a > document to an http URL" idea, and the AUTH or SERVICE methods in SIP. > > Here's the idea. B is some presentity. B subscribes to his own watcher > information. When A subscribes to B's presence, B gets notified of a > pending > subscription. This comes in a NOTIFY carrying a watcher information data > format. This data format has, as part of its definition, URLs that can be > used to accept or reject the subscription. So, for example, B would get a > NOTIFY like: > > NOTIFY sip:B@computer.bar.com SIP/2.0 > From: sip:B@bar.com > To: sip:B@bar.com > Content-Type: application/watcherinfo+xml > Event: presence.winfo > > > > event="subscribe"> > http://bar.com/approve.cgi?user=A&watcher=B > http://bar.com/reject.cgi?user=A&watcher=B > > > > > > Now, if B wants to approve the subscription, the URL within the approve > tags > is taken and used, and if it wants to reject, the one within the reject > tags > is used. Of course, the http POST needs to be authenticated. That can be > done with digest over https, and the username and password provided would > be > checked against the same back end database that holds the SIP username and > passwords. No document formats or anything else are generated. > > Now, the benefits of this approach are: > > 1. no need to define an authorization policy data format > 2. no need to standardize a mapping from sip URLs to http URLs, which was > one of the main (and valid) objections to the initial HTTP approach. > 3. the server chooses the URLs for approval and rejection, their structure > has no semantics anywhere outside of the server. > 4. views approval and rejection as form post operations, which is what > they > really are (indeed, I expect offline authorization systems to be entirely > web based, with forms as the primary tool for setting data. Indeed, the > same > back end cgi scripts can be used, which is very nice) > > The drawbacks: > > 1. still reuqires http. Now, you could, in principle, put a sip url in > there > instead of an http URL, but I think thats pushing it a bit. I really think > that this kind of thing is a form post operation. This kind of mecahnism > is, > BTW, exactly how collected data is passed in VXML systems. > 2. doesn't allow more complex policies to be set *this* way; you can still > set authorization policy through CPLs, web interfaces, and so on. This > mechanism would just automate the baseline case of approve/reject. Indeed, > we could even have another tag, , which has a URL you can visit > for an interactive web session to set arbitrarily complex policies. > > > Comments? > > -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 roberbr@microsoft.com Fri Jun 29 02:19:31 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA15399 for ; Fri, 29 Jun 2001 02:19:29 -0400 (EDT) Received: from 157.54.1.52 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 28 Jun 2001 22:47:24 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Jun 2001 22:47:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Another idea for presence authorization Date: Thu, 28 Jun 2001 22:47:24 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C3318@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Another idea for presence authorization Thread-Index: AcEAW6cmWesAGjo+QKS6aTODBVnhrQAABhMg From: "Robert Brown" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 29 Jun 2001 05:47:14.0568 (UTC) FILETIME=[F2EDC880:01C1005E] Content-Length: 7439 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id CAA15399 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: HTTP works because it is uni-directional, has no routing, and is more mature - the solutions are well understood and widely available. SIP works too if you configure your network right, use the right NATs, etc. The issue is not whether or not one works. The issue is that just because one works doesn't mean the other does. Such as your typical enterprise network... There's a company called foobar. It has a directory service containing userid and password for all its users. It has a DMZ consisting of a network between two firewalls - one on the boundary of the corporate network, one on the boundary of the Internet. Any host within the DMZ is regarded to be compromizable, hence the directory service can be accessed from within foobar's corporate network, but not from within the DMZ. The inner firewall only permits inbound requests between specific server pairs on specific ports - e.g. an SMTP router in the DMZ can send to an SMTP server in the inner network. Foobar deploys a SIP infrastructure on its network for instant messaging and presence. It deploys a SIP proxy in the DMZ to route between external SIP nodes and the internal network. It deploys an HTTP server for authorization in the internal network - where it needs to be so it can access the directory service. Everything works fine until one of Foobar's users tries connecting from the Internet. How does this user request an HTTP GET to the internal HTTP server? > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, June 28, 2001 10:23 PM > To: Robert Brown; Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > -----Original Message----- > > From: Robert Brown [mailto:roberbr@microsoft.com] > > Sent: Friday, June 29, 2001 12:57 AM > > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > I think the other objection to HTTP GET was that the fact that a route > > exists that can deliver a NOTIFY SIP request to B doesn't imply that > > HTTP connectivity is possible between wherever B is and the > > host that is > > addressed in the HTTP request. After all, there is no guarantee that > > the entity that issued the notification has omnipotence regarding the > > firewalls or HTTP proxies between B and the HTTP servers expressed in > > the notification. > > Well, unlike SIP which has known firewall and nat issues, http works > pretty > darn well. I don't see this as a real problem. > > > > > > Now, certainly, this would work in many cases. But there are > > likely to > > be situations where this assumption is not valid. > > Such as? > > -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: Thursday, June 28, 2001 4:33 PM > > > To: 'simple@mailman.dynamicsoft.com' > > > Subject: [Simple] Another idea for presence authorization > > > > > > Folks, > > > > > > I was in the process of writing up the consensus to date on presence > > > authorization, and I had another idea on uploading authorization for > > the > > > subscriptions. The approach is a hybrid between the intitial "post a > > > document to an http URL" idea, and the AUTH or SERVICE > > methods in SIP. > > > > > > Here's the idea. B is some presentity. B subscribes to his > > own watcher > > > information. When A subscribes to B's presence, B gets notified of a > > > pending > > > subscription. This comes in a NOTIFY carrying a watcher information > > data > > > format. This data format has, as part of its definition, > > URLs that can > > be > > > used to accept or reject the subscription. So, for example, B would > > get a > > > NOTIFY like: > > > > > > NOTIFY sip:B@computer.bar.com SIP/2.0 > > > From: sip:B@bar.com > > > To: sip:B@bar.com > > > Content-Type: application/watcherinfo+xml > > > Event: presence.winfo > > > > > > > > > > > > > > event="subscribe"> > > > http://bar.com/approve.cgi?user=A&watcher=B > > > http://bar.com/reject.cgi?user=A&watcher=B > > > > > > > > > > > > > > > > > > Now, if B wants to approve the subscription, the URL within the > > approve > > > tags > > > is taken and used, and if it wants to reject, the one within the > > reject > > > tags > > > is used. Of course, the http POST needs to be > > authenticated. That can > > be > > > done with digest over https, and the username and password provided > > would > > > be > > > checked against the same back end database that holds the > > SIP username > > and > > > passwords. No document formats or anything else are generated. > > > > > > Now, the benefits of this approach are: > > > > > > 1. no need to define an authorization policy data format > > > 2. no need to standardize a mapping from sip URLs to http > > URLs, which > > was > > > one of the main (and valid) objections to the initial HTTP approach. > > > 3. the server chooses the URLs for approval and rejection, their > > structure > > > has no semantics anywhere outside of the server. > > > 4. views approval and rejection as form post operations, > > which is what > > > they > > > really are (indeed, I expect offline authorization systems to be > > entirely > > > web based, with forms as the primary tool for setting data. Indeed, > > the > > > same > > > back end cgi scripts can be used, which is very nice) > > > > > > The drawbacks: > > > > > > 1. still reuqires http. Now, you could, in principle, put a > > sip url in > > > there > > > instead of an http URL, but I think thats pushing it a bit. I really > > think > > > that this kind of thing is a form post operation. This kind of > > mecahnism > > > is, > > > BTW, exactly how collected data is passed in VXML systems. > > > 2. doesn't allow more complex policies to be set *this* way; you can > > still > > > set authorization policy through CPLs, web interfaces, and > > so on. This > > > mechanism would just automate the baseline case of approve/reject. > > Indeed, > > > we could even have another tag, , which has a URL you can > > visit > > > for an interactive web session to set arbitrarily complex policies. > > > > > > > > > Comments? > > > > > > -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 ndeason@ubiquity.net Fri Jun 29 08:48:29 2001 Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id IAA16539 for ; Fri, 29 Jun 2001 08:48:28 -0400 (EDT) Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca via smtpd (for [216.173.40.35]) with SMTP; 29 Jun 2001 13:48:17 UT Received: (private information removed) Message-ID: From: Neil Deason To: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 29 Jun 2001 07:16:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 7529 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: We should have a SIP based mechanism. A problem for the proposal here is that the SIP auth service requires support for voice sessions. SIMPLE devices may not support voice and also IM+P providers may not have VoiceXML servers in their backend systems. Support for SIP messaging + XML seems a more reasonable entry level for the authorization service within SIMPLE. As what we are looking for is a web service for authorization I previously raised the possibility for using WSDL ( http://www.w3.org/TR/wsdl ). I didn't hear anything to say why this wouldn't work. In fact it fits nicely with the idea of defining a web service that could be accessed through both HTTP and SIP. A SIMPLE WG XML doc defines the basic elements of the auth service. Service providers then import this definition into the publication a WSDL desription of their SIMPLE auth service implementation. The service could support all of HTTP-CGI, SOAP/HTTP and SOAP/SIP intefaces. (WSDL can already describe how services are made available through HTTP-CGI and SOAP/ HTTP. Service bindings for SOAP/SIP would need to be added). We could standardize what mechanism(s) a min impl must support. I gave an example of a definition of the service elements for the service and how a service provider would make the service available through SOAP/HTTP before. http://mailman.dynamicsoft.com/pipermail/simple/2001-June/000257.html The WSDL spec has an example of a HTTP-CGI service at the end. The Definition SIP/SOAP bindings would be close to the existing HTTP/SOAP ones. 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 Jonathan > Rosenberg > Sent: 29 June 2001 05:44 > To: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] Another idea for presence authorization > > An additional thought below... > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, June 28, 2001 7:33 PM > > To: 'simple@mailman.dynamicsoft.com' > > Subject: [Simple] Another idea for presence authorization > > > > > > Folks, > > > > I was in the process of writing up the consensus to date on presence > > authorization, and I had another idea on uploading > > authorization for the > > subscriptions. The approach is a hybrid between the intitial "post a > > document to an http URL" idea, and the AUTH or SERVICE > > methods in SIP. > > > > Here's the idea. B is some presentity. B subscribes to his > own watcher > > information. When A subscribes to B's presence, B gets > > notified of a pending > > subscription. This comes in a NOTIFY carrying a watcher > > information data > > format. This data format has, as part of its definition, URLs > > that can be > > used to accept or reject the subscription. So, for example, B > > would get a > > NOTIFY like: > > > > NOTIFY sip:B@computer.bar.com SIP/2.0 > > From: sip:B@bar.com > > To: sip:B@bar.com > > Content-Type: application/watcherinfo+xml > > Event: presence.winfo > > > > > > > > > event="subscribe"> > > http://bar.com/approve.cgi?user=A&watcher=B > > http://bar.com/reject.cgi?user=A&watcher=B > > > > > > > > > > > > Now, if B wants to approve the subscription, the URL within > > the approve tags > > is taken and used, and if it wants to reject, the one within > > the reject tags > > is used. Of course, the http POST needs to be authenticated. > > That can be > > done with digest over https, and the username and password > > provided would be > > checked against the same back end database that holds the SIP > > username and > > passwords. No document formats or anything else are generated. > > > > Now, the benefits of this approach are: > > > > 1. no need to define an authorization policy data format > > 2. no need to standardize a mapping from sip URLs to http > > URLs, which was > > one of the main (and valid) objections to the initial HTTP approach. > > 3. the server chooses the URLs for approval and rejection, > > their structure > > has no semantics anywhere outside of the server. > > 4. views approval and rejection as form post operations, > > which is what they > > really are (indeed, I expect offline authorization systems to > > be entirely > > web based, with forms as the primary tool for setting data. > > Indeed, the same > > back end cgi scripts can be used, which is very nice) > > > > The drawbacks: > > > > 1. still reuqires http. Now, you could, in principle, put a > > sip url in there > > instead of an http URL, but I think thats pushing it a bit. I > > really think > > that this kind of thing is a form post operation. This kind > > of mecahnism is, > > BTW, exactly how collected data is passed in VXML systems. > > Thinking about this more, I think there is merit in having a > SIP URL in > there, but the meaning of that is different than what people have been > thinking (but more in line with what sip is actually for). A > SIP URL here > would mean that "use this to initiate a session to some IVR > or something > else which will use voice prompts to authenticate you and > then change the > authorization policy. So, for example, you might have: > > > > event="subscribe"> > http://bar.com/approve.cgi?user=A&watcher=B > sip:vxml.approve@vxmlservers.com > http://bar.com/reject.cgi?user=A&watcher=B > > > > > So, a client now has a choice. If http enabled, it can post > the form data to > approve or reject. If its voice only, it can call the SIP URL > provided. That > would go to a VXML server, which might interact with the user > like this: > > VXML server: "please say your username" > user: joe > VXML server: "please say or enter your pin" > user: 7654 > VXML server: "to authorize the subscription from A, please say yes" > user: yes > VXML server: "thank you. User A now approved. Bye." > > The VXML server would then form post the data to a web server > thats managing > the authorization list. > > So, really, the idea here is that there are many potential > user interfaces > one might take advantage of for managing the authorization list: > > 1. web pages > 2. custom GUI application > 3. voice interaction > > we want to separate the way the UI is done from the interface to the > application. For 2 of the three above (web, voice > interaction), the standard > interface is already defined as http form posts. Seems > natural to extend > that further to the second case, by doing what I am proposing above. > > -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 jdrosen@dynamicsoft.com Fri Jun 29 11:13:33 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16941 for ; Fri, 29 Jun 2001 11:13:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA08719; Fri, 29 Jun 2001 11:17:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 11:13:30 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 29 Jun 2001 11:13:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2262 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Friday, June 29, 2001 1:47 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > HTTP works because it is uni-directional, has no routing, and is more > mature - the solutions are well understood and widely available. SIP > works too if you configure your network right, use the right > NATs, etc. > The issue is not whether or not one works. The issue is that just > because one works doesn't mean the other does. > > Such as your typical enterprise network... > > There's a company called foobar. It has a directory service > containing > userid and password for all its users. It has a DMZ consisting of a > network between two firewalls - one on the boundary of the corporate > network, one on the boundary of the Internet. Any host within the DMZ > is regarded to be compromizable, hence the directory service can be > accessed from within foobar's corporate network, but not from > within the > DMZ. The inner firewall only permits inbound requests > between specific > server pairs on specific ports - e.g. an SMTP router in the > DMZ can send > to an SMTP server in the inner network. Foobar deploys a SIP > infrastructure on its network for instant messaging and presence. It > deploys a SIP proxy in the DMZ to route between external SIP nodes and > the internal network. It deploys an HTTP server for authorization in > the internal network - where it needs to be so it can access the > directory service. Everything works fine until one of Foobar's users > tries connecting from the Internet. How does this user > request an HTTP > GET to the internal HTTP server? VPN. The scenario you are describing is why VPN was invented. Many other applications will have the same problem you describe. -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 From jdrosen@dynamicsoft.com Fri Jun 29 11:49:26 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17059 for ; Fri, 29 Jun 2001 11:49:26 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA09272; Fri, 29 Jun 2001 11:53:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 11:49:21 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 29 Jun 2001 11:49:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 4288 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Friday, June 29, 2001 11:37 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > VPN. The scenario you are describing is why VPN was invented. > > No it isn't. > > VPN won't work. For example the foobar user is a consultant or > supply-chain partner sitting in a customer's network behind their > firewall. It is all too common for outbound PPTP to be blocked. If the user is not served by the foobar domain, why would they be sending their authorization information to the foobar server? Also, lets assume its all SIP. I'm hoping you're still in favor of authenticating these SIP messages. That requires access to the DB inside the corporate network. So, the proxy in the DMZ forward the request to the server inside the network. Can you explain why that doesn't work for http? There is an http proxy in the DMZ, and it forwards HTTP requests to the HTTP server inside the corporate domain. Granted HTTP cannot do complex routing, but we're not talking about that. -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: Friday, June 29, 2001 8:13 AM > > To: Robert Brown; Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > -----Original Message----- > > > From: Robert Brown [mailto:roberbr@microsoft.com] > > > Sent: Friday, June 29, 2001 1:47 AM > > > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > HTTP works because it is uni-directional, has no routing, and is > more > > > mature - the solutions are well understood and widely available. > SIP > > > works too if you configure your network right, use the right > > > NATs, etc. > > > The issue is not whether or not one works. The issue is that just > > > because one works doesn't mean the other does. > > > > > > Such as your typical enterprise network... > > > > > > There's a company called foobar. It has a directory service > > > containing > > > userid and password for all its users. It has a DMZ > consisting of a > > > network between two firewalls - one on the boundary of > the corporate > > > network, one on the boundary of the Internet. Any host within the > DMZ > > > is regarded to be compromizable, hence the directory > service can be > > > accessed from within foobar's corporate network, but not from > > > within the > > > DMZ. The inner firewall only permits inbound requests > > > between specific > > > server pairs on specific ports - e.g. an SMTP router in the > > > DMZ can send > > > to an SMTP server in the inner network. Foobar deploys a SIP > > > infrastructure on its network for instant messaging and presence. > It > > > deploys a SIP proxy in the DMZ to route between external SIP nodes > and > > > the internal network. It deploys an HTTP server for authorization > in > > > the internal network - where it needs to be so it can access the > > > directory service. Everything works fine until one of Foobar's > users > > > tries connecting from the Internet. How does this user > > > request an HTTP > > > GET to the internal HTTP server? > > > > VPN. The scenario you are describing is why VPN was invented. Many > other > > applications will have the same problem you describe. > > > > -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 > From roberbr@microsoft.com Fri Jun 29 12:19:42 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA17190 for ; Fri, 29 Jun 2001 12:19:41 -0400 (EDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 29 Jun 2001 08:37:01 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Jun 2001 08:36:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 29 Jun 2001 08:36:37 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C3319@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Another idea for presence authorization Thread-Index: AcEArh7nekJKJYtERe+ujv/6vmPFjwAAqLkQ From: "Robert Brown" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 29 Jun 2001 15:36:37.0595 (UTC) FILETIME=[48EF7AB0:01C100B1] Content-Length: 2936 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA17190 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: > VPN. The scenario you are describing is why VPN was invented. No it isn't. VPN won't work. For example the foobar user is a consultant or supply-chain partner sitting in a customer's network behind their firewall. It is all too common for outbound PPTP to be blocked. The solution needs to work in SIP. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, June 29, 2001 8:13 AM > To: Robert Brown; Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > -----Original Message----- > > From: Robert Brown [mailto:roberbr@microsoft.com] > > Sent: Friday, June 29, 2001 1:47 AM > > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > HTTP works because it is uni-directional, has no routing, and is more > > mature - the solutions are well understood and widely available. SIP > > works too if you configure your network right, use the right > > NATs, etc. > > The issue is not whether or not one works. The issue is that just > > because one works doesn't mean the other does. > > > > Such as your typical enterprise network... > > > > There's a company called foobar. It has a directory service > > containing > > userid and password for all its users. It has a DMZ consisting of a > > network between two firewalls - one on the boundary of the corporate > > network, one on the boundary of the Internet. Any host within the DMZ > > is regarded to be compromizable, hence the directory service can be > > accessed from within foobar's corporate network, but not from > > within the > > DMZ. The inner firewall only permits inbound requests > > between specific > > server pairs on specific ports - e.g. an SMTP router in the > > DMZ can send > > to an SMTP server in the inner network. Foobar deploys a SIP > > infrastructure on its network for instant messaging and presence. It > > deploys a SIP proxy in the DMZ to route between external SIP nodes and > > the internal network. It deploys an HTTP server for authorization in > > the internal network - where it needs to be so it can access the > > directory service. Everything works fine until one of Foobar's users > > tries connecting from the Internet. How does this user > > request an HTTP > > GET to the internal HTTP server? > > VPN. The scenario you are describing is why VPN was invented. Many other > applications will have the same problem you describe. > > -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 From roberbr@microsoft.com Fri Jun 29 20:03:58 2001 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id UAA18417 for ; Fri, 29 Jun 2001 20:03:57 -0400 (EDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 29 Jun 2001 17:01:51 -0700 (Pacific Daylight Time) Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 29 Jun 2001 17:01:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 29 Jun 2001 17:01:49 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C331B@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Another idea for presence authorization Thread-Index: AcEAmhtwxzfXDzyzQVGrubj349IS8gAW4Mqw From: "Robert Brown" To: "Neil Deason" , "Jonathan Rosenberg" , X-OriginalArrivalTime: 30 Jun 2001 00:01:50.0501 (UTC) FILETIME=[DCD5DD50:01C100F7] Content-Length: 8792 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id UAA18417 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: I agree. There are two proposals here: (1) - SOAP over SIP (2) - Using WSDL to describe services implemented in (1) Implementors would adhere to (1) and have the option of doing (2) SOAP over SIP will enable any scenario that could alternatively be done with HTTP, but without additional infrastructure or complexity. WSDL can be published by a product/service for the purposes of describing the services it implements. Watcher authorization would be one such service. > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Friday, June 29, 2001 4:17 AM > To: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > We should have a SIP based mechanism. A problem for the > proposal here is that the SIP auth service requires support > for voice sessions. SIMPLE devices may not support voice and > also IM+P providers may not have VoiceXML servers in their > backend systems. Support for SIP messaging + XML seems a more > reasonable entry level for the authorization service within > SIMPLE. > > As what we are looking for is a web service for > authorization I previously raised the possibility for > using WSDL ( http://www.w3.org/TR/wsdl ). I didn't > hear anything to say why this wouldn't work. In fact it > fits nicely with the idea of defining a web service > that could be accessed through both HTTP and SIP. A SIMPLE > WG XML doc defines the basic elements of the auth service. > Service providers then import this definition into the > publication a WSDL desription of their SIMPLE auth service > implementation. The service could support all of HTTP-CGI, > SOAP/HTTP and SOAP/SIP intefaces. (WSDL can already describe > how services are made available through HTTP-CGI and SOAP/ > HTTP. Service bindings for SOAP/SIP would need to be added). > We could standardize what mechanism(s) a min impl must support. > > I gave an example of a definition of the service elements > for the service and how a service provider would make the > service available through SOAP/HTTP before. > http://mailman.dynamicsoft.com/pipermail/simple/2001-June/000257.html > The WSDL spec has an example of a HTTP-CGI service at > the end. The Definition SIP/SOAP bindings would be close to > the existing HTTP/SOAP ones. > > 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 Jonathan > > Rosenberg > > Sent: 29 June 2001 05:44 > > To: 'simple@mailman.dynamicsoft.com' > > Subject: RE: [Simple] Another idea for presence authorization > > > > An additional thought below... > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, June 28, 2001 7:33 PM > > > To: 'simple@mailman.dynamicsoft.com' > > > Subject: [Simple] Another idea for presence authorization > > > > > > > > > Folks, > > > > > > I was in the process of writing up the consensus to date on presence > > > authorization, and I had another idea on uploading > > > authorization for the > > > subscriptions. The approach is a hybrid between the intitial "post a > > > document to an http URL" idea, and the AUTH or SERVICE > > > methods in SIP. > > > > > > Here's the idea. B is some presentity. B subscribes to his > > own watcher > > > information. When A subscribes to B's presence, B gets > > > notified of a pending > > > subscription. This comes in a NOTIFY carrying a watcher > > > information data > > > format. This data format has, as part of its definition, URLs > > > that can be > > > used to accept or reject the subscription. So, for example, B > > > would get a > > > NOTIFY like: > > > > > > NOTIFY sip:B@computer.bar.com SIP/2.0 > > > From: sip:B@bar.com > > > To: sip:B@bar.com > > > Content-Type: application/watcherinfo+xml > > > Event: presence.winfo > > > > > > > > > > > > > > event="subscribe"> > > > http://bar.com/approve.cgi?user=A&watcher=B > > > http://bar.com/reject.cgi?user=A&watcher=B > > > > > > > > > > > > > > > > > > Now, if B wants to approve the subscription, the URL within > > > the approve tags > > > is taken and used, and if it wants to reject, the one within > > > the reject tags > > > is used. Of course, the http POST needs to be authenticated. > > > That can be > > > done with digest over https, and the username and password > > > provided would be > > > checked against the same back end database that holds the SIP > > > username and > > > passwords. No document formats or anything else are generated. > > > > > > Now, the benefits of this approach are: > > > > > > 1. no need to define an authorization policy data format > > > 2. no need to standardize a mapping from sip URLs to http > > > URLs, which was > > > one of the main (and valid) objections to the initial HTTP approach. > > > 3. the server chooses the URLs for approval and rejection, > > > their structure > > > has no semantics anywhere outside of the server. > > > 4. views approval and rejection as form post operations, > > > which is what they > > > really are (indeed, I expect offline authorization systems to > > > be entirely > > > web based, with forms as the primary tool for setting data. > > > Indeed, the same > > > back end cgi scripts can be used, which is very nice) > > > > > > The drawbacks: > > > > > > 1. still reuqires http. Now, you could, in principle, put a > > > sip url in there > > > instead of an http URL, but I think thats pushing it a bit. I > > > really think > > > that this kind of thing is a form post operation. This kind > > > of mecahnism is, > > > BTW, exactly how collected data is passed in VXML systems. > > > > Thinking about this more, I think there is merit in having a > > SIP URL in > > there, but the meaning of that is different than what people have been > > thinking (but more in line with what sip is actually for). A > > SIP URL here > > would mean that "use this to initiate a session to some IVR > > or something > > else which will use voice prompts to authenticate you and > > then change the > > authorization policy. So, for example, you might have: > > > > > > > > > event="subscribe"> > > http://bar.com/approve.cgi?user=A&watcher=B > > sip:vxml.approve@vxmlservers.com > > http://bar.com/reject.cgi?user=A&watcher=B > > > > > > > > > > So, a client now has a choice. If http enabled, it can post > > the form data to > > approve or reject. If its voice only, it can call the SIP URL > > provided. That > > would go to a VXML server, which might interact with the user > > like this: > > > > VXML server: "please say your username" > > user: joe > > VXML server: "please say or enter your pin" > > user: 7654 > > VXML server: "to authorize the subscription from A, please say yes" > > user: yes > > VXML server: "thank you. User A now approved. Bye." > > > > The VXML server would then form post the data to a web server > > thats managing > > the authorization list. > > > > So, really, the idea here is that there are many potential > > user interfaces > > one might take advantage of for managing the authorization list: > > > > 1. web pages > > 2. custom GUI application > > 3. voice interaction > > > > we want to separate the way the UI is done from the interface to the > > application. For 2 of the three above (web, voice > > interaction), the standard > > interface is already defined as http form posts. Seems > > natural to extend > > that further to the second case, by doing what I am proposing above. > > > > -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 bcampbell@dynamicsoft.com Mon Jul 2 11:20:06 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01373 for ; Mon, 2 Jul 2001 11:20:06 -0400 (EDT) Received: from dynamicsoft.com (dsl081-162-190.sea1.dsl.speakeasy.net [64.81.162.190]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA03274; Mon, 2 Jul 2001 11:24:13 -0400 (EDT) Message-ID: <3B4090D6.7070906@dynamicsoft.com> Date: Mon, 02 Jul 2001 10:18:46 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.7) Gecko/20010316 X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Another idea for presence authorization References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 3839 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: Jonathan Rosenberg wrote: > Folks, > > I was in the process of writing up the consensus to date on presence > authorization, and I had another idea on uploading authorization for the > subscriptions. The approach is a hybrid between the intitial "post a > document to an http URL" idea, and the AUTH or SERVICE methods in SIP. > > Here's the idea. B is some presentity. B subscribes to his own watcher > information. When A subscribes to B's presence, B gets notified of a pending > subscription. This comes in a NOTIFY carrying a watcher information data > format. This data format has, as part of its definition, URLs that can be > used to accept or reject the subscription. So, for example, B would get a > NOTIFY like: > > NOTIFY sip:B@computer.bar.com SIP/2.0 > From: sip:B@bar.com > To: sip:B@bar.com > Content-Type: application/watcherinfo+xml > Event: presence.winfo > > > > event="subscribe"> > http://bar.com/approve.cgi?user=A&watcher=B > http://bar.com/reject.cgi?user=A&watcher=B > > > > > > Now, if B wants to approve the subscription, the URL within the approve tags > is taken and used, and if it wants to reject, the one within the reject tags > is used. Of course, the http POST needs to be authenticated. That can be > done with digest over https, and the username and password provided would be > checked against the same back end database that holds the SIP username and > passwords. No document formats or anything else are generated. > > Now, the benefits of this approach are: > > 1. no need to define an authorization policy data format > 2. no need to standardize a mapping from sip URLs to http URLs, which was > one of the main (and valid) objections to the initial HTTP approach. > 3. the server chooses the URLs for approval and rejection, their structure > has no semantics anywhere outside of the server. > 4. views approval and rejection as form post operations, which is what they > really are (indeed, I expect offline authorization systems to be entirely > web based, with forms as the primary tool for setting data. Indeed, the same > back end cgi scripts can be used, which is very nice) > > The drawbacks: > > 1. still reuqires http. Now, you could, in principle, put a sip url in there > instead of an http URL, but I think thats pushing it a bit. I really think > that this kind of thing is a form post operation. This kind of mecahnism is, > BTW, exactly how collected data is passed in VXML systems. > 2. doesn't allow more complex policies to be set *this* way; you can still > set authorization policy through CPLs, web interfaces, and so on. This > mechanism would just automate the baseline case of approve/reject. Indeed, > we could even have another tag, , which has a URL you can visit > for an interactive web session to set arbitrarily complex policies. > > I can see value in this approach for simple yes/no decisions. However, I do not think benefits 1 and 2 really apply, as we would _still_ need the method for pushing policy outside of the context of a subscription request. For example, if I using the above approach choose to disapprove your subscription to me(assuming you mean for that decision to be sticky) how could I change my mind tomorrow and allow you access? I assume that I would not be notified for every _denied_ subscription. That requirement alone suggests that _every_ (or at least most) presence system must have a way for pushing policy at any time, not _just_ in response to a pending subscription. If this is true, then we also need to standardize the method and formats of pushing policy at any time. From bcampbell@dynamicsoft.com Mon Jul 2 11:39:56 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01449 for ; Mon, 2 Jul 2001 11:39:55 -0400 (EDT) Received: from dynamicsoft.com (dsl081-162-190.sea1.dsl.speakeasy.net [64.81.162.190]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA03442; Mon, 2 Jul 2001 11:43:43 -0400 (EDT) Message-ID: <3B40956A.3030609@dynamicsoft.com> Date: Mon, 02 Jul 2001 10:38:18 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.7) Gecko/20010316 X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason CC: Robert Sparks , adam.roach@ericsson.com, "'Francois-Frederic Ozog'" , Jonathan Rosenberg , "'Robert Brown'" , Theodore Havinis , simple@mailman.dynamicsoft.com Subject: Re: [Simple] authorization for presence References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1245 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: Neil Deason wrote: >>> There are also important open issues in this area: >>> >>> 9.1 Must a MESSAGE actually include a message? >>> 9.5 What would a body in a 200 OK to a MESSAGE mean? >> >> We addressed 9.5 in Minnesota. A MESSAGE response may >> not contain a body - it would break cpim. > > > Sorry I had to miss SIMPLE WG that time. > > >> Issue 9.1 from the document was asking a different >> question from what you might have meant. Basically, >> it boiled down to "Is it ok to have a MESSAGE request >> with and empty body?". We can derive the answer to that >> from the consensus we already acheived that while an >> implementation MUST be able to receive message/cpim, >> it MAY send text/plain. Thus it MAY send an empty >> text/plain document. I suspect you rather wanting to >> ask "Can a MESSAGE have a payload that isn't a message?". >> Outside of the message, and message meta-data like >> we have with message/cpim, I hope the answer is no. > > > That is actually another question and the answer > to it that I hoped to hear. If text covering these > 3 points can make it into the draft I think the > semantics of MESSAGE will be a lot clearer. > I will add this to the next MESSAGE draft revision. Thanks! Ben. From bcampbell@dynamicsoft.com Mon Jul 2 11:43:33 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01489 for ; Mon, 2 Jul 2001 11:43:33 -0400 (EDT) Received: from dynamicsoft.com (dsl081-162-190.sea1.dsl.speakeasy.net [64.81.162.190]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA03494; Mon, 2 Jul 2001 11:47:25 -0400 (EDT) Message-ID: <3B409647.6090008@dynamicsoft.com> Date: Mon, 02 Jul 2001 10:41:59 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.7) Gecko/20010316 X-Accept-Language: en MIME-Version: 1.0 To: Sriram Parameswar CC: "'Jonathan Rosenberg'" , "'Hisham Khartabil'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Contact header Usage in subsequent MESSAGE Requests References: <9A9367D1556AD21182C40000F80930AB04411C24@crchy28b.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 2588 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: Hi Sriram, There will be a new MESSAGE draft including this prior to the London meeting. For the moment, the thinking is only documented in the mail archives. Thanks! Ben Campbell Sriram Parameswar wrote: > Jonathan - you refer to a new approach using INVITE rather than MESSAGE. > Could you please point me to the latest version the document that > reflects this? > > Regards, > > Sriram > > __________________________________________ > Sriram Parameswar Phone: 972-685-8540 > Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, June 14, 2001 4:28 AM > To: 'Hisham Khartabil'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Contact header Usage in subsequent MESSAGE > Requests > > > In the older MESSAGE approach (where MESSAGE sort-of was INVITE), the > Contact header had the same semantics as in INVITE - it would be used to > set > up the route for subsequent messages in the same IM session. > > However, in the current proposal, whereby INVITE establishes the session, > the Contact in MESSAGE no longer serves a purpose. > > -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: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > Sent: Thursday, June 14, 2001 5:15 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Contact header Usage in subsequent MESSAGE Requests > > > Hi, > > Section 6.2 or draft-ietf-simple-im-00.txt specifies that a MESSAGE request > MUST contain a Contact header. > Section 6.7 does not specify how this Contact should be used. > The example is section 8 simply says that user2 can send the IM directly to > the address in the Contact header send in the initial MESSAGE request. > > The use of the Contact header in subsequent requests is not clear. Can I > conclude that the use of the Contact header is only a MAY? > > Regards, > Hisham Khartabil > Hotsip Finland > www.hotsip.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From jdrosen@dynamicsoft.com Tue Jul 3 01:24:53 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03956 for ; Tue, 3 Jul 2001 01:24:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f635OQki004621 for ; Tue, 3 Jul 2001 01:24:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3CZ0ZN2P>; Tue, 3 Jul 2001 01:24:52 -0400 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Jonathan Rosenberg Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 3 Jul 2001 01:24:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 3061 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: > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, July 02, 2001 11:19 AM > To: Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] Another idea for presence authorization > > > > 1. still reuqires http. Now, you could, in principle, put a > sip url in there > > instead of an http URL, but I think thats pushing it a bit. > I really think > > that this kind of thing is a form post operation. This kind > of mecahnism is, > > BTW, exactly how collected data is passed in VXML systems. > > 2. doesn't allow more complex policies to be set *this* > way; you can still > > set authorization policy through CPLs, web interfaces, and > so on. This > > mechanism would just automate the baseline case of > approve/reject. Indeed, > > we could even have another tag, , which has a > URL you can visit > > for an interactive web session to set arbitrarily complex policies. > > > > > > I can see value in this approach for simple yes/no decisions. > However, I > do not think benefits 1 and 2 really apply, as we would > _still_ need the > method for pushing policy outside of the context of a subscription > request. For example, if I using the above approach choose to > disapprove > your subscription to me(assuming you mean for that decision to be > sticky) how could I change my mind tomorrow and allow you access? Sure. The million dollar question is - how will you do that? Will it be from a browser type of thing? Or do we need to define a custom protocol for the whole thing? I would argue that because this policy can be arbitrarily complex, the ideal solution is not to specify a protocol or document for it, but simply use web forms or voice prompts. This leaves a lot of flexibility in how the policy can be specified, without requiring standardization. You need a protocol only when automata are going to be setting the policy, and I just don't see automata setting complex authorization policies. People will. I > assume that I would not be notified for every _denied_ subscription. > That requirement alone suggests that _every_ (or at least > most) presence > system must have a way for pushing policy at any time, not _just_ in > response to a pending subscription. If this is true, then we > also need > to standardize the method and formats of pushing policy at any time. > Right. Thats all part of the watcherinfo package. I've come up with a basic state machine for generic subscriptions, so that notifications are sent on the transitions of this machine. One of the transitions is due to rejected subscriptions, so that you'd get a notification of that. -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 From Brian.Rosen@marconi.com Tue Jul 3 12:00:29 2001 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 MAA05716 for ; Tue, 3 Jul 2001 12:00:28 -0400 (EDT) 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 MAA14150; Tue, 3 Jul 2001 12:00:24 -0400 (EDT) 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 MAA19414; Tue, 3 Jul 2001 12:00:24 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Jul 2001 12:00:24 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044656C6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , Ben Campbell Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 3 Jul 2001 12:00:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 4610 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: Maybe one of the issues that is causing confusion is that there are actually two "subscription" kinds of things. One is the one where you get the human involved - will you as presentity allow so-and-so as watcher presence information (along with what kind/how often/....). That has a possible long delay, and lots of policy, and, as Jonathan has pointed out, possibly no protocol. When you decide, a database records your choice, but there is no SIP. Then you get right down to the actual user agent trying to get the Notifies to come. That too is a "subscription", but it happens AFTER the former thing, has no UI, no delay, no policy, and very much is a protocol thing. Let's keep them straight. Maybe we need some terminology: Suppose we call the first "authorization" and the other "subscription". Both have to be authenticated. Thus you would have to be authorized before you could subscribe. Brian Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, July 03, 2001 1:25 AM > To: Ben Campbell; Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Monday, July 02, 2001 11:19 AM > > To: Jonathan Rosenberg > > Cc: 'simple@mailman.dynamicsoft.com' > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > > 1. still reuqires http. Now, you could, in principle, put a > > sip url in there > > > instead of an http URL, but I think thats pushing it a bit. > > I really think > > > that this kind of thing is a form post operation. This kind > > of mecahnism is, > > > BTW, exactly how collected data is passed in VXML systems. > > > 2. doesn't allow more complex policies to be set *this* > > way; you can still > > > set authorization policy through CPLs, web interfaces, and > > so on. This > > > mechanism would just automate the baseline case of > > approve/reject. Indeed, > > > we could even have another tag, , which has a > > URL you can visit > > > for an interactive web session to set arbitrarily complex > policies. > > > > > > > > > > I can see value in this approach for simple yes/no decisions. > > However, I > > do not think benefits 1 and 2 really apply, as we would > > _still_ need the > > method for pushing policy outside of the context of a subscription > > request. For example, if I using the above approach choose to > > disapprove > > your subscription to me(assuming you mean for that decision to be > > sticky) how could I change my mind tomorrow and allow you access? > > Sure. The million dollar question is - how will you do that? > Will it be from > a browser type of thing? Or do we need to define a custom > protocol for the > whole thing? I would argue that because this policy can be arbitrarily > complex, the ideal solution is not to specify a protocol or > document for it, > but simply use web forms or voice prompts. This leaves a lot > of flexibility > in how the policy can be specified, without requiring > standardization. You > need a protocol only when automata are going to be setting > the policy, and I > just don't see automata setting complex authorization > policies. People will. > > > I > > assume that I would not be notified for every _denied_ subscription. > > That requirement alone suggests that _every_ (or at least > > most) presence > > system must have a way for pushing policy at any time, not > _just_ in > > response to a pending subscription. If this is true, then we > > also need > > to standardize the method and formats of pushing policy at any time. > > > > Right. Thats all part of the watcherinfo package. I've come > up with a basic > state machine for generic subscriptions, so that > notifications are sent on > the transitions of this machine. One of the transitions is > due to rejected > subscriptions, so that you'd get a notification of that. > > -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 adam.roach@ericsson.com Tue Jul 3 16:39:41 2001 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 QAA06482 for ; Tue, 3 Jul 2001 16:39:41 -0400 (EDT) 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 f63Kddp11915; Tue, 3 Jul 2001 15:39:39 -0500 (CDT) 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 f63Kdcq15323; Tue, 3 Jul 2001 15:39:38 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id PAA19480; Tue, 3 Jul 2001 15:39:37 -0500 (CDT) Reply-To: To: "'Jonathan Rosenberg'" , Subject: RE: [Simple] Open issue: migration of subscriptions Date: Tue, 3 Jul 2001 15:39:34 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251905@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 V4.72.3612.1700 Content-Length: 8933 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: I like the overall idea, but I see a much easier way to do it. In draft-roach-sip-subscribe-notify-03, I described a mechanism by which the notifier can let the subscriber know that the subscription has been kicked out: send a NOTIFY with an "Expires: 0". This avoids the double subscription, and allows all packages -- even .watcherinfo sub-packages -- to be migrated. If you want to use such a mechanism, I could add text to support it; essentially, saying that a "NOTIFY" with an "Expires: 0" should be answered by an attempt to re-subscribe. If the notifier wanted the subscription to migrate, it migrates. If the notifier really wanted to kick the subscriber out, it rejects the SUBSCRIBE it with a 403 or similar. /a > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, June 26, 2001 3:51 PM > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] Open issue: migration of subscriptions > > > Folks, > > I'd like to begin a thread on another presence open issue > that we discussed > at IETF 49. > > The issue is with migration of subscriptions. It is discussed > in section 6.1 > of > http://www.jdrosen.net/papers/draft-ietf-simple-presence-00.tx > t. The idea is > that when a subscription refresh arrives, a presence server > can destroy the > subscription state, and proxy the request to the PUA, which accepts it > there. The draft indicates that this is problematic for a few reasons: > > 1. the refresh has to and from tags which don't match an existing > subscription state in the PUA. This means defining special case tag > handling. Tags are awful enough as it is. > > 2. The route set is already established, and in this route > set, the presence > server has inserted the contact. When the presence server > acts as a proxy, > it now needs to add itself into the route set with a > record-route, and the > contact needs to be updated to be that of the PUA. This kind > of route set > update is not possible. Only the contact can change; > record-route headers > cannot be added. > > Some additional problems: > > 3. The migration to the PUA is very gradual, taking up to the > duration of > the longest subscription refresh interval. > > 4. It is not clear how to get the subscriptions to migrate back to the > presence server, since the PUA isn't a proxy and can't begin > proxying them > there. > > > I have a proposal on how to fix these problems. The approach > is to use our > new friend, the watcherinfo sub-package. Here's how it works. > > Lets say A subscribes to B, with the event package presence. > Initially, > these subscriptions are handled by the presence server in B's > domain, which > acts as a PA. A also subscribes to B using the event package > presence.watcherinfo. B's presence server allows this > subscription, but > won't provide A with all information on B's watchers. Rather, A gets > notified only of changes to A's subscription state for B (in > other words, > the presence server will, by default, filter the information sent to > subscribers for Bs presence.watcherinfo). At some point, the > presence server > decides to migrate the subscriptions to B directly. So, it > destroys the > subscriptions for B, which results in a notification to the > those subscribed > to presence.watcherinfo for B (which includes A). A will > therefore get a > NOTIFY indicating that their subscription is invalidated. A then > re-SUBSCRIBEs, using a brand new Call-ID (i.e., its not a > refresh within the > existing call leg, its a totally new one). The presence > server proxies these > to B. Since these are brand new subscriptions, they establish > a new route > set, which can include the presence server of B on the > record-route list. A > also needs to re-SUBSCRIBE to presence.watcherinfo for B, as > this too will > now be handled by the B (note that I do not think we need to support A > subscribing to presence.watcherinfo.watcherinfo to determine that its > subscription to presence.watcherinfo for B has been > terminated; this can be > implied from the destruction of its presence subscription. > Without this, we > have infinite recursion of subscriptions). > > Now, at any time, B can also destroy subscription states. This causes > notifications to go to the subscribers of presence.watcherinfo > for A. They > can re-SUBSCRIBE once more, and the presence server can > terminate them this > time around. > > To be specific, here is the call flow: > > > > | SUB B presence C-ID: 10 | | > |------------------------>| | > | 202 Accepted | | > |<------------------------| | > | | | > | SUB B pres.winfo C-ID 11| | > |------------------------>| | > | 202 Accepted | | > |<------------------------| | > | | | > | NOT A pres.winfo C-ID 11| | > | sub. invalidated | server decides | > |<------------------------| to migrate subs. | > | 200 OK | | > |------------------------>| | > | SUB B presence C-ID: 12 | | > |------------------------>| SUB B presence C-ID: 12 | > | |-------------------------->| > | | 202 Accepted | > | 202 Accepted |<--------------------------| > |<------------------------| | > | SUB B pres.winfo CID: 13| | > |------------------------>| SUB B pres.winfo CID: 13 | > | |-------------------------->| > | | 202 Accepted | > | 202 Accepted |<--------------------------| > |<------------------------| | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > > A B's B > presence > server > > > I've left off some details, such as the initial NOTIFY after > the SUBSCRIBE, > and the authorization. Also, how the presence server decides > to migrate the > subscriptions is orthogonal. It could be because B registered > support for > the SUBSCRIBE method, or perhaps the user clicked on a web page or > something. Its not shown. > > I think this is a fairly clean way to handle migrations, but > it introduces > some of the burden for this at the subscriber; namely, when I > subscribe to > B, I also need to subscribe to B's presence.watcherinfo to > learn the status > of my subscription. Worst case, if this second subscription > is not done, > when the first (the normal presence subscription) is > refreshed, it generates > a 481 at B's presence server. This can then trigger A to > generate a brand > new subscription (with a new Call-ID) which will migrate at > that point. This > means we need to additionally specify that a 481 response to > a SUBSCRIBE > refresh should cause a new subscription to be made. I think thats > reasonable. > > We will also need to somehow allow a SUBSCRIBE to a > presence.watcherinfo > package to indicate that the subscription is desired for a particular > watcher only. Not too hard. > > Comments? > > -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 adam.roach@ericsson.com Tue Jul 3 21:03:44 2001 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 VAA07170 for ; Tue, 3 Jul 2001 21:03:44 -0400 (EDT) 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 f6413hp22890 for ; Tue, 3 Jul 2001 20:03:43 -0500 (CDT) 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 f6413gH19342 for ; Tue, 3 Jul 2001 20:03:43 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id UAA27333 for ; Tue, 3 Jul 2001 20:03:42 -0500 (CDT) Reply-To: "Adam Roach (EUS)" To: Date: Tue, 3 Jul 2001 20:03:41 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251908@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 V4.72.3612.1700 Content-Length: 778 Subject: [Simple] New SUBSCRIBE/NOTIFY draft (WGLC approaching) 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: A new draft for the SUBSCRIBE/NOTIFY extensions has been submitted and should appear in the internet-draft archives soon. Until it does, you may retrieve a copy from: http://standards.ericsson.net/sip/drafts/draft-ietf-sip-events-00.txt This newest version should include all comments to date, and is scheduled for working group last call this Saturday, July 7th. A thorough examination by all interested parties is strongly suggested at this time. Discussion on the two open issues discussed in the draft is urgently encouraged. Responses to this message will (should) go directly to me. General discussions related the draft should be new threads with appropriate "Subject" lines on the sip-events list (see http://standards.ericsson.net/sip/sip-mailing-lists.html). /a From jdrosen@dynamicsoft.com Tue Jul 3 22:39:41 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07437 for ; Tue, 3 Jul 2001 22:39:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f642dDki007639; Tue, 3 Jul 2001 22:39:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3CZ0ZP4B>; Tue, 3 Jul 2001 22:39:40 -0400 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Open issue: migration of subscriptions Date: Tue, 3 Jul 2001 22:39:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2178 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: > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Tuesday, July 03, 2001 4:40 PM > To: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Open issue: migration of subscriptions > > > I like the overall idea, but I see a much easier way to do it. > > In draft-roach-sip-subscribe-notify-03, I described a mechanism > by which the notifier can let the subscriber know that the > subscription has been kicked out: send a NOTIFY with an > "Expires: 0". Hmm. Thats definitely simpler. The one nagging doubt I have is whether this is really what Expires means in a NOTIFY. You'd think the proper interpretation is, "the state described in this notification is no longer valid after the time in the expires header". Perhaps its just an academic concern.... It also would be useful for telling you only one of the reasons why a subscription might be destroyed. There are other reasons - normal expiration, change in policy, etc. THe right behavior for each are different. Normal expiration should result in a subscription within the same call leg. Migration requires a new subscription with a new call leg. With change in policy, there is nothing you can do. > > This avoids the double subscription, and allows all packages -- > even .watcherinfo sub-packages -- to be migrated. If you want > to use such a mechanism, I could add text to support it; essentially, > saying that a "NOTIFY" with an "Expires: 0" should be answered > by an attempt to re-subscribe. If the notifier wanted the subscription > to migrate, it migrates. If the notifier really wanted to kick the > subscriber out, it rejects the SUBSCRIBE it with a 403 or similar. Whatever it is, it definitely needs to be generic and apply to all packages. No doubt. -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 From jdrosen@dynamicsoft.com Wed Jul 4 12:21:08 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09611 for ; Wed, 4 Jul 2001 12:21:07 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f64GKeki008202; Wed, 4 Jul 2001 12:20:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3CZ0ZQGR>; Wed, 4 Jul 2001 12:21:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" , Jonathan Rosenberg , Ben Campbell Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 4 Jul 2001 12:21:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2620 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: > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, July 03, 2001 12:00 PM > To: 'Jonathan Rosenberg'; Ben Campbell > Cc: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] Another idea for presence authorization > > > Maybe one of the issues that is causing confusion is that > there are actually two "subscription" kinds of things. > > One is the one where you get the human involved - will you > as presentity allow so-and-so as watcher presence information > (along with what kind/how often/....). That has a possible > long delay, and lots of policy, and, as Jonathan has pointed > out, possibly no protocol. When you decide, a database records > your choice, but there is no SIP. > > Then you get right down to the actual user agent trying to > get the Notifies to come. That too is a "subscription", > but it happens AFTER the former thing, has no UI, no delay, > no policy, and very much is a protocol thing. > > Let's keep them straight. Maybe we need some terminology: > > Suppose we call the first "authorization" and the other > "subscription". Both have to be authenticated. Thus you > would have to be authorized before you could subscribe. The complexity is that one (subscription) will frequently need to trigger the other (authroization). That is, when someone suscribes to me for the first time, there is no authorization policy. In order to make a yes/no decision on the subscription, the particular application scenario might require that I be notified of the subscription in order to generate an authorization decision. So, the authorization policy here is "pseudo-real-time", in the sense that its triggered based on a subscription. However, because, ultimately, its still the process of providing authorization, and also, still may not happen immediately after the subscription arrives, I like the model of having a single mechanism for providing authorization. That mechanism is server specific, I argue, and ideally done through web interfaces. By providing the URL to give authroization, the process can be facilitated and can even be done without a browser, for simple cases at least. More complex policy is going to be too complex to do in a protocol. -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 From Brian.Rosen@marconi.com Thu Jul 5 09:28:43 2001 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 JAA12829 for ; Thu, 5 Jul 2001 09:28:43 -0400 (EDT) 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 JAA03984; Thu, 5 Jul 2001 09:28:38 -0400 (EDT) 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 JAA22003; Thu, 5 Jul 2001 09:28:39 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Jul 2001 09:28:38 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044656E0@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , "Rosen, Brian" , Ben Campbell Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Another idea for presence authorization Date: Thu, 5 Jul 2001 09:28:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3216 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: Why can't the request to subscribe fail if there is no authorization? Provide the URL in the response. Get authorized, try subscribing again. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 04, 2001 12:21 PM > To: 'Rosen, Brian'; Jonathan Rosenberg; Ben Campbell > Cc: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, July 03, 2001 12:00 PM > > To: 'Jonathan Rosenberg'; Ben Campbell > > Cc: 'simple@mailman.dynamicsoft.com' > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Maybe one of the issues that is causing confusion is that > > there are actually two "subscription" kinds of things. > > > > One is the one where you get the human involved - will you > > as presentity allow so-and-so as watcher presence information > > (along with what kind/how often/....). That has a possible > > long delay, and lots of policy, and, as Jonathan has pointed > > out, possibly no protocol. When you decide, a database records > > your choice, but there is no SIP. > > > > Then you get right down to the actual user agent trying to > > get the Notifies to come. That too is a "subscription", > > but it happens AFTER the former thing, has no UI, no delay, > > no policy, and very much is a protocol thing. > > > > Let's keep them straight. Maybe we need some terminology: > > > > Suppose we call the first "authorization" and the other > > "subscription". Both have to be authenticated. Thus you > > would have to be authorized before you could subscribe. > > The complexity is that one (subscription) will frequently > need to trigger > the other (authroization). That is, when someone suscribes to > me for the > first time, there is no authorization policy. In order to > make a yes/no > decision on the subscription, the particular application > scenario might > require that I be notified of the subscription in order to generate an > authorization decision. So, the authorization policy here is > "pseudo-real-time", in the sense that its triggered based on > a subscription. > > However, because, ultimately, its still the process of providing > authorization, and also, still may not happen immediately after the > subscription arrives, I like the model of having a single > mechanism for > providing authorization. That mechanism is server specific, I > argue, and > ideally done through web interfaces. By providing the URL to give > authroization, the process can be facilitated and can even be > done without a > browser, for simple cases at least. More complex policy is > going to be too > complex to do in a protocol. > > -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 > From rsparks@dynamicsoft.com Thu Jul 5 10:54:52 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13077 for ; Thu, 5 Jul 2001 10:54:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f65EsOki009256; Thu, 5 Jul 2001 10:54:24 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3CZ0ZRJW>; Thu, 5 Jul 2001 10:54:51 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A951@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , "'adam.roach@ericsson.com'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Open issue: migration of subscriptions Date: Thu, 5 Jul 2001 10:54:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1809 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: > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Tuesday, July 03, 2001 4:40 PM > > To: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Open issue: migration of subscriptions > > > > > > I like the overall idea, but I see a much easier way to do it. > > > > In draft-roach-sip-subscribe-notify-03, I described a mechanism > > by which the notifier can let the subscriber know that the > > subscription has been kicked out: send a NOTIFY with an > > "Expires: 0". > > Hmm. Thats definitely simpler. > > The one nagging doubt I have is whether this is really what > Expires means in > a NOTIFY. You'd think the proper interpretation is, "the > state described in > this notification is no longer valid after the time in the > expires header". > Perhaps its just an academic concern.... I rather prefer this interpretation of Expires. I certainly want that to be is meaning when the Expires value is non-zero and not a countdown timer indicating the remaining duration of the subscription. For Expires: 0, coupling "The state described here is no longer valid" with "You will receive no future Notifications in this subscription" only limits our ability to say "Here's a peice of state that's good for the rest of the week - I'm not going to tell you any more". Is that a problem? > > It also would be useful for telling you only one of the reasons why a > subscription might be destroyed. There are other reasons - normal > expiration, change in policy, etc. THe right behavior for each are > different. Normal expiration should result in a subscription > within the same > call leg. Migration requires a new subscription with a new > call leg. With > change in policy, there is nothing you can do. > From jdrosen@dynamicsoft.com Thu Jul 5 11:10:03 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13148 for ; Thu, 5 Jul 2001 11:10:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f65F9Yki009355; Thu, 5 Jul 2001 11:09:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3CZ0ZRLP>; Thu, 5 Jul 2001 11:10:01 -0400 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'adam.roach@ericsson.com'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Open issue: migration of subscriptions Date: Thu, 5 Jul 2001 11:09:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3140 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: > -----Original Message----- > From: Robert Sparks > Sent: Thursday, July 05, 2001 10:55 AM > To: Jonathan Rosenberg; 'adam.roach@ericsson.com'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Open issue: migration of subscriptions > > > > > -----Original Message----- > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > Sent: Tuesday, July 03, 2001 4:40 PM > > > To: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Open issue: migration of subscriptions > > > > > > > > > I like the overall idea, but I see a much easier way to do it. > > > > > > In draft-roach-sip-subscribe-notify-03, I described a mechanism > > > by which the notifier can let the subscriber know that the > > > subscription has been kicked out: send a NOTIFY with an > > > "Expires: 0". > > > > Hmm. Thats definitely simpler. > > > > The one nagging doubt I have is whether this is really what > > Expires means in > > a NOTIFY. You'd think the proper interpretation is, "the > > state described in > > this notification is no longer valid after the time in the > > expires header". > > Perhaps its just an academic concern.... > > I rather prefer this interpretation of Expires. I certainly want > that to be is meaning when the Expires value is non-zero and not > a countdown timer indicating the remaining duration of the > subscription. > > For Expires: 0, coupling "The state described here is no longer valid" > with "You will receive no future Notifications in this subscription" > only limits our ability to say "Here's a peice of state > that's good for > the rest of the week - I'm not going to tell you any more". > > Is that a problem? How about a compromise approach? Expires retains the meaning that Robert and I like - which is to define the lifetime of the state in the NOTIFY. We can define another header, Subscription-Expires, which has the same syntax. Its present in a NOTIFY and indicates the lifetime remaining of the subscription. If zero, there can be parameters which indicate the reason for it becoming zero: NOTIFY sip:subscriber@foo.com SIP/2.0 Subscription-Expires: 0;reason=deactivated I still think that it is useful to subscribe to the watcherinfo for the presentities you watch, in order to be notified of changes in your own subscription state. Indeed, with watcherinfo defined as a sub-package, this becomes possible. I would argue that watcherinfo is still the most correct approach (although admittedly more complex), as the above approach still mixes two different things together. Indeed, with the above, I might get a NOTIFY even though the state of the presentity remains unchanged, which is a bit odd. Might there be other interactions lurking around the corner....? -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 From res02mg1@gte.net Fri Jul 6 03:59:16 2001 Received: from smtp-hub2.mrf.mail.rcn.net (smtp-hub2.mrf.mail.rcn.net [207.172.4.76]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15770 for ; Fri, 6 Jul 2001 03:59:15 -0400 (EDT) Received: from smtp01.mrf.mail.rcn.net ([207.172.4.60]) by smtp-hub2.mrf.mail.rcn.net with esmtp (Exim 3.30 #2) id 15IQW0-0005qK-00 for SIMPLE@mailman.dynamicsoft.com; Fri, 06 Jul 2001 03:59:04 -0400 Received: from 66-44-67-230.s484.tnt7.lnhva.md.dialup.rcn.com ([66.44.67.230] helo=EAGLE) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.30 #2) id 15IQVy-0005Pn-00 for SIMPLE@MAILMAN.DYNAMICSOFT.COM; Fri, 06 Jul 2001 03:59:03 -0400 Message-ID: <15035200175674524130@EAGLE> X-EM-Version: 5, 0, 0, 19 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: res02mg1@gte.net X-MSMail-Priority: Normal From: "David C. Dickson" To: SIMPLE@mailman.dynamicsoft.com Date: Fri, 6 Jul 2001 03:45:24 -0400 MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-Length: 5213 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA15770 Subject: [Simple] Network and Info Systems Security Training Conference - Wash DC, 16 July 2001 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: To: SIMPLE@MAILMAN.DYNAMICSOFT.COM NEW SPEAKERS ADDED PLEASE FORWARD THIS TO YOUR MANAGER OF SYSTEMS SECURITY, TRENDS, AND SECURITY TECHNOLOGIES GROUP. Market*Access International is proud to present .... NETWORK AND INFORMATION SYSTEMS SECURITY - TRAINING CONFERENCE AGENCY INTRUSION DETECTION REQUIREMENTS and TECHNOLOGY SOLUTIONS Date: July 16, 2001 Ronald Reagan Building and International Trade Center 1300 Pennsylvania Avenue Washington D.C. Atrium Ballroom Time: 7:30 AM Registration and Continental Breakfast Program Starts: 8:30 AM Wrap-up: 4:15 PM About this Conference: As government becomes more dependent on e-business, databases, information storehouses, mission critical information storage and information sharing, new risks are posed. These risks may come from student hackers, foreign governments or foreign military, terrorist organizations or even internal users. With the new e-Government applications and communications, computer security has emerged as a top issue and challenge. This conference will highlight the risks, opportunities and innovative management and technical approaches to the detection and response to unauthorized intrusions into agency data. The conference will focus on business and military applications and agency plans and programs for securing these applications. A highlight of this conference will be a section on AGENCY REQUIREMENTS AND NEW TECHNOLOGIES and strategies of coping with unauthorized attempts to compromise agency and DoD systems and data. SPEAKERS WILL REPRESENT THE FOLLOWING AGENCIES/COMPANIES: Navy NMCI – Mark Lavoie – Communications Officer, CDR, USNR PEO IT (Program Executive Office of Information Technology). Department of Transportation - Bonnie Fisher – Director, TASC Millennium Solutions Center National Science Foundation - Dara Murry – Director, ADP Security FBI - James Burrell – Acting Unit Chief, Computer Investigation Unit DARPA - Jim Webster – Manager, Information Assurance Office GSA/FedCIRC - Larry Hale – Liaison Director, Federal Computer Incident Response Center DOJ – TBD DISA – TBD Gartner – Keynote – TBD Guardant – Robert Lee – Director, Senior Principal Consultant Global Integrity - Errol Weiss, Bill Morgan Verizon, Federal Network Systems - Char Sample – Raytheon – Barton Abbott – Director, Information Assurance, Navy /USMC Intranet, Information Strike Force Symantec - TBD For more information on speakers and the conference agenda, please visit our web site at www.marketaccess.org. Who should attend: * Agency IT Executives, Managers, and Staff * Agency Security Executives, Managers and Staff * Agency information systems program managers * Agency Telecommunications Executives, Managers and Staff * Tele-work and Telecomm Directors, Managers, and Staff * Functional area managers * Systems integrators that support federal agency security requirements * Hardware and software solutions providers What you will learn: * Agency plans, programs and priorities * Successes and Lessons learned * Innovative government intrusion detection security approaches and applications * New technologies and strategies - what is on the drawing boards * How the military approaches network security and intrusion detection * Security of remote database management * How to structure intrusion detection solutions * Risks, sources of attacks... the internal risk * Commercial and government best practices Corporate Sponsors: * Symantec * Verizon * Market*Access .... others to be announced Organizational Sponsors: * Department of Transportation * INPUT Government ....other sponsors to be announced. Please register early. The conference area has limited seating available and we anticipate a sell out. Points of Contact: * For technical support with this web site, please contact Mr. Parrish Knight, 703/807-2748 * For general information about this event, please contact Ms. Kristen Brooks, 703/807-2745 * For information on sponsorship opportunities & exhibitor arrangements, please contact Ms. Cara Lombardi at 703/807-2743 The registration fee for this important training conference is: * Government Credit Card or Check in Advance: $395 * Government Training Forms/Invoice: $445 * Industry and Federal Contractors, Payment in Advance: $595 * Industry and Federal Contractors/Invoice: $645 We accept government training forms and government and commercial credit cards (VISA, MC, American Express). Options: [1] Phone: 703-807-2745 and speak with Ms. Kristen Brooks. [2] Email: kbrooks@marketaccess.org [3] Register online: Use our online booking form to register and pay by credit card electronically. To register, go to www.marketaccess.org. [4] Fax: registration form to 301-652-0914. [5] Mail: registration form to: Market*Access International, Inc. 4301 Wilson Blvd. #1003 Arlington, VA 22203 Sponsorships Available! For sponsorship information, please contact: Cara Lombardi Market*Access International 4301 Wilson Blvd. #1003 Arlington, VA 22203 Phone (703) 807-2743 Fax (703) 807-2728 clombardi@marketaccess.org If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line. Thank you From bcampbell@dynamicsoft.com Fri Jul 6 11:26:34 2001 Received: from redball.dynamicsoft.com (mailhost.dynamicsoft.com [216.173.40.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17141 for ; Fri, 6 Jul 2001 11:26:34 -0400 (EDT) Received: from dynamicsoft.com ([63.110.3.239]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA26585; Fri, 6 Jul 2001 11:30:41 -0400 (EDT) Message-ID: <3B45D87C.2020701@dynamicsoft.com> Date: Fri, 06 Jul 2001 10:25:48 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.7) Gecko/20010316 X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: Jonathan Rosenberg , "'adam.roach@ericsson.com'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Open issue: migration of subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F314A951@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1072 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: Robert Sparks wrote: >> >> The one nagging doubt I have is whether this is really what >> Expires means in >> a NOTIFY. You'd think the proper interpretation is, "the >> state described in >> this notification is no longer valid after the time in the >> expires header". >> Perhaps its just an academic concern.... > > > I rather prefer this interpretation of Expires. I certainly want > that to be is meaning when the Expires value is non-zero and not > a countdown timer indicating the remaining duration of the subscription. > > For Expires: 0, coupling "The state described here is no longer valid" > with "You will receive no future Notifications in this subscription" > only limits our ability to say "Here's a peice of state that's good for > the rest of the week - I'm not going to tell you any more". > > Is that a problem? It might open up a kettle of worms in the situation where you have rich presence data, not all of which expires at the same time. It almost seems the concept of data expiration belongs to the data format, not the transport. From zmolek@avaya.com Fri Jul 6 12:02:59 2001 Received: from iere.net.avaya.com (h198-152-12-101.outland.avaya.com [198.152.12.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17291 for ; Fri, 6 Jul 2001 12:02:54 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f66G2B716830 for ; Fri, 6 Jul 2001 12:02:11 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f66G2Bd16810 for ; Fri, 6 Jul 2001 12:02:11 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10635.21C24E20" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Subject: RE: [Simple] Open issue: migration of subscriptions Date: Fri, 6 Jul 2001 10:03:01 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Open issue: migration of subscriptions Thread-Index: AcEGMOh7JZKHfMquSuqpV2CbE9tGGQAArKHQ From: "Zmolek, Andrew (Andrew)" To: "Ben Campbell" , "Robert Sparks" Cc: "Jonathan Rosenberg" , , Content-Length: 6957 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C10635.21C24E20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eventually, sufficient presence data from many sources will flow through aggregators and redistributors. If an expiration isn't linked to each piece of data individually, the value and usefulness of that data will be diminished by aggregators and redistributors who will have to assign some other value to the whole collection. Moreover, as aggregation and redistribution become common, tracing the origin of any given piece of presence data will be useful when things go awry. It might be nice to have in addition a pointer to the originator, maybe just a fully qualified host name.=20 --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Friday, July 06, 2001 9:26 AM To: Robert Sparks Cc: Jonathan Rosenberg; 'adam.roach@ericsson.com'; simple@mailman.dynamicsoft.com Subject: Re: [Simple] Open issue: migration of subscriptions Robert Sparks wrote: >>=20 >> The one nagging doubt I have is whether this is really what=20 >> Expires means in >> a NOTIFY. You'd think the proper interpretation is, "the=20 >> state described in >> this notification is no longer valid after the time in the=20 >> expires header". >> Perhaps its just an academic concern.... >=20 >=20 > I rather prefer this interpretation of Expires. I certainly want > that to be is meaning when the Expires value is non-zero and not=20 > a countdown timer indicating the remaining duration of the subscription. >=20 > For Expires: 0, coupling "The state described here is no longer valid" > with "You will receive no future Notifications in this subscription" > only limits our ability to say "Here's a peice of state that's good for > the rest of the week - I'm not going to tell you any more". >=20 > Is that a problem? It might open up a kettle of worms in the situation where you have rich=20 presence data, not all of which expires at the same time. It almost=20 seems the concept of data expiration belongs to the data format, not the transport. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C10635.21C24E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Open issue: migration of subscriptions

Eventually, sufficient presence data from many sources = will flow through aggregators and redistributors. If an expiration isn't = linked to each piece of data individually, the value and usefulness of = that data will be diminished by aggregators and redistributors who will = have to assign some other value to the whole collection.

Moreover, as aggregation and redistribution become = common, tracing the origin of any given piece of presence data will be = useful when things go awry. It might be nice to have in addition a = pointer to the originator, maybe just a fully qualified host name. =

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya = Inc.

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.co= m]
Sent: Friday, July 06, 2001 9:26 AM
To: Robert Sparks
Cc: Jonathan Rosenberg; = 'adam.roach@ericsson.com';
simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Open issue: migration of = subscriptions


Robert Sparks wrote:

>>
>> The one nagging doubt I have is whether this = is really what
>> Expires means in
>> a NOTIFY. You'd think the proper = interpretation is, "the
>> state described in
>> this notification is no longer valid after = the time in the
>> expires header".
>> Perhaps its just an academic = concern....
>
>
> I rather prefer this interpretation of Expires. = I certainly want
> that to be is meaning when the Expires value is = non-zero and not
> a countdown timer indicating the remaining = duration of the subscription.
>
> For Expires: 0, coupling "The state = described here is no longer valid"
> with "You will receive no future = Notifications in this subscription"
> only limits our ability to say "Here's a = peice of state that's good for
> the rest of the week - I'm not going to tell you = any more".
>
> Is that a problem?

It might open up a kettle of worms in the situation = where you have rich
presence data, not all of which expires at the same = time. It almost
seems the concept of data expiration belongs to the = data format, not the
transport.

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

------_=_NextPart_001_01C10635.21C24E20-- From jdrosen@dynamicsoft.com Fri Jul 6 13:11:39 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17492 for ; Fri, 6 Jul 2001 13:11:39 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f66HBAki013495; Fri, 6 Jul 2001 13:11:10 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3CZ0Z4KC>; Fri, 6 Jul 2001 13:11:36 -0400 Message-ID: From: Jonathan Rosenberg To: "'Zmolek, Andrew (Andrew)'" , Ben Campbell , Robert Sparks Cc: Jonathan Rosenberg , adam.roach@ericsson.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Open issue: migration of subscriptions Date: Fri, 6 Jul 2001 13:11:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3555 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: I think there may be expiration times for each piece of data individualy within the presence document. This is an issue for impp, which is doing the presence document format. I know they have talked about timestamps for each piece of data individually. So, whilst I agree that you want expirations for each piece of data individually, that doesn't change the fact that Expires is really referring to the content of the message, and thus the notification. It may be that this is frequently not useful, but I'm not sure that means applying Expires to mean something else is a good idea (namely, expiration of the subscription). -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: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] Sent: Friday, July 06, 2001 12:03 PM To: Ben Campbell; Robert Sparks Cc: Jonathan Rosenberg; adam.roach@ericsson.com; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Open issue: migration of subscriptions Eventually, sufficient presence data from many sources will flow through aggregators and redistributors. If an expiration isn't linked to each piece of data individually, the value and usefulness of that data will be diminished by aggregators and redistributors who will have to assign some other value to the whole collection. Moreover, as aggregation and redistribution become common, tracing the origin of any given piece of presence data will be useful when things go awry. It might be nice to have in addition a pointer to the originator, maybe just a fully qualified host name. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Friday, July 06, 2001 9:26 AM To: Robert Sparks Cc: Jonathan Rosenberg; 'adam.roach@ericsson.com'; simple@mailman.dynamicsoft.com Subject: Re: [Simple] Open issue: migration of subscriptions Robert Sparks wrote: >> >> The one nagging doubt I have is whether this is really what >> Expires means in >> a NOTIFY. You'd think the proper interpretation is, "the >> state described in >> this notification is no longer valid after the time in the >> expires header". >> Perhaps its just an academic concern.... > > > I rather prefer this interpretation of Expires. I certainly want > that to be is meaning when the Expires value is non-zero and not > a countdown timer indicating the remaining duration of the subscription. > > For Expires: 0, coupling "The state described here is no longer valid" > with "You will receive no future Notifications in this subscription" > only limits our ability to say "Here's a peice of state that's good for > the rest of the week - I'm not going to tell you any more". > > Is that a problem? It might open up a kettle of worms in the situation where you have rich presence data, not all of which expires at the same time. It almost seems the concept of data expiration belongs to the data format, not the transport. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From Vasilis.Polychronidis@Openwave.com Sun Jul 8 20:39:51 2001 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 UAA25998 for ; Sun, 8 Jul 2001 20:39:51 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010709003911.CMYP21684.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Sun, 8 Jul 2001 19:39:11 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010709003915.FNNI23773.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Sun, 8 Jul 2001 19:39:15 -0500 Message-ID: <3B48FD48.B1353B90@Openwave.com> Date: Sun, 08 Jul 2001 17:39:37 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Robert Sparks , "'simple@mailman.dynamicsoft.com'" , "'sean.olson@ericsson.com'" Subject: Re: [Simple] IM: A session or not References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2896 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: Hi All, I think this was the last message on this thread (IM: A session or not). This was a very interesting discussion. Can someone summarize the consensus of the group on this important issue? Thank you in advance, Vasilis Polychronidis Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Robert Sparks > > Sent: Sunday, May 13, 2001 2:28 AM > > To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com'; > > 'sean.olson@ericsson.com' > > Subject: RE: [Simple] IM: A session or not > > > > > > > > > >> If the conversation forks in > > >> one direction, it will _stay_ forked through the whole > > conversation. > > > > > >By conversation, are you referring to the sip call, or the > > message "stream"? > > > > The stream of MESSAGE requests (the "chat" conversation). > > Since we do not > > want to make any distinction between a page MESSAGE and a > > chat MESSAGE, if > > for some reason the stream hits a proxy that forks the chat > > MESSAGEs, it > > will fork every one. > > > > This is an unlikely scenario - in the best of worlds, we've > > signaled direct > > peer-peer delivery of chat MESSAGEs using the SDP in the > > INVITE. However, if > > we've been forced to use an outbound proxy, or have > > introduced a proxy through > > preloaded routes, as mentioned above, there's a chance that > > something along > > the path will fork the chat MESSAGEs. > > > > I'm not claiming this is a problem. I just wanted to make > > sure everyone > > understood the possibility existed. > > Yes, it does. Under normal cases, where either Route is used, or where a > direct messaging occurs, it definitely won't. In cases where it does end up > forking, you want to be able to reject the message at all hosts except the > one that was really supposed to get it. The right way to do that is to > include a tag in the To field of all MESSAGE requests. This tag would be set > as part of the URI in the SDP. Doing this is a little bit of a stretch; tag > is really meant for requests that are part of a session. Technically, since > MESSAGE operates like OPTIONS, there is really no SIP session associated > with the collection of MESSAGES. But, I think its probably reasonable to use > tag in any case. We need to explicitly note, in the text, that a UA should > reject a MESSAGE if it contains a to tag that is unrecognized. > > -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 sriramp@nortelnetworks.com Mon Jul 9 11:36:37 2001 Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01344 for ; Mon, 9 Jul 2001 11:36:32 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA12845 for ; Mon, 9 Jul 2001 10:38:10 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 9 Jul 2001 10:29:49 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <3HRFBYH8>; Mon, 9 Jul 2001 10:35:41 -0500 Message-ID: <9A9367D1556AD21182C40000F80930AB04411C70@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: simple@mailman.dynamicsoft.com Date: Mon, 9 Jul 2001 10:35:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1088C.CBF095B0" X-Orig: Content-Length: 2443 Subject: [Simple] "Fetch" of 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: 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_01C1088C.CBF095B0 Content-Type: text/plain; charset="iso-8859-1" Hi all: I apologize if this has been discussed before (I am desperately trying to catch up with traffic on this list). Previously an expires=0 in a SUBSCRIBE indicated a 'fetch'(a one time retrieval) of presence information - the current draft indicate that this is no longer the case. Instead expires=0 is a way to indicate an end to the subscription. I personally think that 'fetch' is an important capability, is there some way to re-introduce this? Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C1088C.CBF095B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "Fetch" of Presence

Hi all:

I apologize if this has been discussed before (I am = desperately trying to catch up with traffic on this list). Previously = an expires=3D0 in a SUBSCRIBE indicated a 'fetch'(a one time retrieval) = of presence information - the current draft indicate that this is no = longer the case. Instead expires=3D0 is a way to indicate an end to the = subscription.

I personally think that 'fetch' is an important = capability, is there some way to re-introduce this?

Regards,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: = 972-685-3563
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


------_=_NextPart_001_01C1088C.CBF095B0-- From adam.roach@ericsson.com Mon Jul 9 12:05:15 2001 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 MAA01468 for ; Mon, 9 Jul 2001 12:05:14 -0400 (EDT) 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 f69G51p22390; Mon, 9 Jul 2001 11:05:01 -0500 (CDT) 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 f69G51c12771; Mon, 9 Jul 2001 11:05:01 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA07068; Mon, 9 Jul 2001 11:05:00 -0500 (CDT) Reply-To: To: "'Rosen, Brian'" , "'Jonathan Rosenberg'" , "Ben Campbell" Cc: Subject: RE: [Simple] Another idea for presence authorization Date: Mon, 9 Jul 2001 10:46:52 -0500 Message-ID: <61D824C63B99D311975E00508B0CC9850225190C@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 V4.72.3612.1700 In-Reply-To: <4FBEA8857476D311A03300204840E1CF044656E0@whq-msgusr-02.pit.comms.marconi.com> Content-Length: 398 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: > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Why can't the request to subscribe fail if there is no > authorization? Provide the URL in the response. Largely because it's crucial that an unauthorized subscription, a denied subscription, and a subscription to the presence of an offline user be completely and utterly indistinguishable from the point of view of the subscriber. /a From adam.roach@ericsson.com Mon Jul 9 12:06:33 2001 Received: from imr2.ericy.com ([12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01489 for ; Mon, 9 Jul 2001 12:06:32 -0400 (EDT) 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 f69G54509206; Mon, 9 Jul 2001 11:05:04 -0500 (CDT) 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 f69G54S21654; Mon, 9 Jul 2001 11:05:04 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA07074; Mon, 9 Jul 2001 11:05:04 -0500 (CDT) Reply-To: To: "'Sriram Parameswar'" , Subject: RE: [Simple] "Fetch" of Presence Date: Mon, 9 Jul 2001 10:56:04 -0500 Message-ID: <61D824C63B99D311975E00508B0CC9850225190D@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 V4.72.3612.1700 In-Reply-To: <9A9367D1556AD21182C40000F80930AB04411C70@crchy28b.us.nortel.com> Content-Length: 1466 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: Nothing about the handling of "Expires" has changed in the past four versions of this draft. Perhaps the following text will clarify the situation for you. 5.3. Polling Resource State A natural consequence of the behavior described in the preceding sections is that an immediate fetch without a persistent subscription may be effected by sending an appropriate SUBSCRIBE with an "Expires" of 0. Of course, an immediate fetch while a subscription is active may be effected by sending an appropriate SUBSCRIBE with an "Expires" greater than 0. /a -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Monday, July 09, 2001 10:36 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] "Fetch" of Presence Hi all: I apologize if this has been discussed before (I am desperately trying to catch up with traffic on this list). Previously an expires=0 in a SUBSCRIBE indicated a 'fetch'(a one time retrieval) of presence information - the current draft indicate that this is no longer the case. Instead expires=0 is a way to indicate an end to the subscription. I personally think that 'fetch' is an important capability, is there some way to re-introduce this? Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com From Brian.Rosen@marconi.com Mon Jul 9 13:13:21 2001 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 NAA01699 for ; Mon, 9 Jul 2001 13:13:20 -0400 (EDT) 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 NAA25923; Mon, 9 Jul 2001 13:13:17 -0400 (EDT) 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 NAA05889; Mon, 9 Jul 2001 13:13:18 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 9 Jul 2001 13:13:18 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446571C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'adam.roach@ericsson.com'" , "'Jonathan Rosenberg'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Mon, 9 Jul 2001 13:13:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1615 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: Of course. What is the point? Every failure of the subscribe would return the URL to a page that would authorize. It wouldn't matter if there was or wasn't authorization. Denied authorization wouldn't be distinguishable from failed or not attempted authorization. It seems to me that trying to put a human in a protocol loop is a bad design decision. The subscription results should be immediate. The decision to seek authorization, and its success or failure, is not really something that needs to be, or should be standardized. What you want is the immediate subscription to the presence to work between arbitrary presentities and watcher/fetchers. The failure of subscription, we agree, should not reveal why. Brian > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Monday, July 09, 2001 11:47 AM > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Why can't the request to subscribe fail if there is no > > authorization? Provide the URL in the response. > > Largely because it's crucial that an unauthorized subscription, > a denied subscription, and a subscription to the presence of > an offline user be completely and utterly indistinguishable > from the point of view of the subscriber. > > /a > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From dgboyer@avaya.com Tue Jul 10 10:34:05 2001 Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03235 for ; Tue, 10 Jul 2001 10:34:03 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21064 for ; Tue, 10 Jul 2001 10:33:09 -0400 (EDT) Received: from NJ7460CLUSTER.usae.avaya.com (h135-8-7-232.avaya.com [135.8.7.232]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20855 for ; Tue, 10 Jul 2001 10:33:05 -0400 (EDT) Received: by nj7460cluster.usae.avaya.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 10:32:38 -0400 Message-ID: <1EB06B0C0D7B484BAECBFACCE290B39F8920D4@nj7460cluster.usae.avaya.com> From: "Boyer, D G (Dave)" To: "'Rosen, Brian'" , "'adam.roach@ericsson.com'" , "'Jonathan Rosenberg'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 10 Jul 2001 10:32:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1094D.265FAA20" Content-Length: 7706 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: 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_01C1094D.265FAA20 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, July 09, 2001 1:13 PM > To: 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Of course. What is the point? > Every failure of the subscribe would return the URL > to a page that would authorize. It wouldn't matter if > there was or wasn't authorization. Denied authorization > wouldn't be distinguishable from failed or not attempted > authorization. > > It seems to me that trying to put a human in a protocol > loop is a bad design decision. The subscription results should > be immediate. The decision to seek authorization, and its > success or failure, is not really something that needs to be, > or should be standardized. What you want is the immediate > subscription to the presence to work between arbitrary > presentities and watcher/fetchers. The failure of > subscription, we agree, should not reveal why. Isn't this a policy decision that should be let up to the application? In some implementations it is allowable and useful to let a user know why their subscription failed. Dave Boyer > > Brian > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Monday, July 09, 2001 11:47 AM > > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > Why can't the request to subscribe fail if there is no > > > authorization? Provide the URL in the response. > > > > Largely because it's crucial that an unauthorized subscription, > > a denied subscription, and a subscription to the presence of > > an offline user be completely and utterly indistinguishable > > from the point of view of the subscriber. > > > > /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_01C1094D.265FAA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Another idea for presence authorization

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Monday, July 09, 2001 1:13 PM
> To: 'adam.roach@ericsson.com'; 'Jonathan = Rosenberg'; Ben Campbell
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Another idea for presence = authorization
>
>
> Of course.  What is the point?
> Every failure of the subscribe would return the = URL
> to a page that would authorize.  It = wouldn't matter if
> there was or wasn't authorization.  Denied = authorization
> wouldn't be distinguishable from failed or not = attempted
> authorization.
>
> It seems to me that trying to put a human in a = protocol
> loop is a bad design decision.  The = subscription results should
> be immediate.  The decision to seek = authorization, and its
> success or failure, is not really something = that needs to be,
> or should be standardized.   What you = want is the immediate
> subscription to the presence to work between = arbitrary
> presentities and watcher/fetchers.  The = failure of
> subscription, we agree, should not reveal = why.

Isn't this a policy decision that should be let up to = the application?
In some implementations it is allowable and useful = to
let a user know why their subscription = failed.

Dave Boyer

>      
> Brian
> > -----Original Message-----
> > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> > Sent: Monday, July 09, 2001 11:47 = AM
> > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; = Ben Campbell
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Another idea for = presence authorization
> >
> >
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > >
> > > Why can't the request to subscribe = fail if there is no
> > > authorization?  Provide the URL = in the response.
> >
> > Largely because it's crucial that an = unauthorized subscription,
> > a denied subscription, and a subscription = to the presence of
> > an offline user be completely and utterly = indistinguishable
> > from the point of view of the subscriber.
> >
> > /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_01C1094D.265FAA20-- From Brian.Rosen@marconi.com Tue Jul 10 10:38:45 2001 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 KAA03261 for ; Tue, 10 Jul 2001 10:38:13 -0400 (EDT) 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 KAA12780; Tue, 10 Jul 2001 10:38:08 -0400 (EDT) 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 KAA05014; Tue, 10 Jul 2001 10:38:10 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Jul 2001 10:38:09 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465735@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Boyer, D G (Dave)'" , "Rosen, Brian" , "'adam.roach@ericsson.com'" , "'Jonathan Rosenberg'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 10 Jul 2001 10:38:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1094D.EE61E790" Content-Length: 9806 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: 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_01C1094D.EE61E790 Content-Type: text/plain; charset="iso-8859-1" It's clearly a choice, but there are indeed nasty security problems that arise because information leaks that is intended to be helpful in diagnosing a problem, but instead is used by J. Wiley Hacker to debug his hack. Usually best to silently fail. Brian -----Original Message----- From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com] Sent: Tuesday, July 10, 2001 10:33 AM To: 'Rosen, Brian'; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization > -----Original Message----- > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] > Sent: Monday, July 09, 2001 1:13 PM > To: 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Of course. What is the point? > Every failure of the subscribe would return the URL > to a page that would authorize. It wouldn't matter if > there was or wasn't authorization. Denied authorization > wouldn't be distinguishable from failed or not attempted > authorization. > > It seems to me that trying to put a human in a protocol > loop is a bad design decision. The subscription results should > be immediate. The decision to seek authorization, and its > success or failure, is not really something that needs to be, > or should be standardized. What you want is the immediate > subscription to the presence to work between arbitrary > presentities and watcher/fetchers. The failure of > subscription, we agree, should not reveal why. Isn't this a policy decision that should be let up to the application? In some implementations it is allowable and useful to let a user know why their subscription failed. Dave Boyer > > Brian > > -----Original Message----- > > From: adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com ] > > Sent: Monday, July 09, 2001 11:47 AM > > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] > > > > > > Why can't the request to subscribe fail if there is no > > > authorization? Provide the URL in the response. > > > > Largely because it's crucial that an unauthorized subscription, > > a denied subscription, and a subscription to the presence of > > an offline user be completely and utterly indistinguishable > > from the point of view of the subscriber. > > > > /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_01C1094D.EE61E790 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Another idea for presence authorization
It's clearly a choice, but there are indeed nasty security problems that
arise because information leaks that is intended to be helpful in diagnosing
a problem, but instead is used by J. Wiley Hacker to debug his hack.
Usually best to silently fail.
 
Brian
-----Original Message-----
From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com]
Sent: Tuesday, July 10, 2001 10:33 AM
To: 'Rosen, Brian'; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Another idea for presence authorization



> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Monday, July 09, 2001 1:13 PM
> To: 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Another idea for presence authorization
>
>
> Of course.  What is the point?
> Every failure of the subscribe would return the URL
> to a page that would authorize.  It wouldn't matter if
> there was or wasn't authorization.  Denied authorization
> wouldn't be distinguishable from failed or not attempted
> authorization.
>
> It seems to me that trying to put a human in a protocol
> loop is a bad design decision.  The subscription results should
> be immediate.  The decision to seek authorization, and its
> success or failure, is not really something that needs to be,
> or should be standardized.   What you want is the immediate
> subscription to the presence to work between arbitrary
> presentities and watcher/fetchers.  The failure of
> subscription, we agree, should not reveal why.

Isn't this a policy decision that should be let up to the application?
In some implementations it is allowable and useful to
let a user know why their subscription failed.

Dave Boyer

>      
> Brian
> > -----Original Message-----
> > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> > Sent: Monday, July 09, 2001 11:47 AM
> > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Another idea for presence authorization
> >
> >
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > >
> > > Why can't the request to subscribe fail if there is no
> > > authorization?  Provide the URL in the response.
> >
> > Largely because it's crucial that an unauthorized subscription,
> > a denied subscription, and a subscription to the presence of
> > an offline user be completely and utterly indistinguishable
> > from the point of view of the subscriber.
> >
> > /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_01C1094D.EE61E790-- From dgboyer@avaya.com Tue Jul 10 10:49:30 2001 Received: from iere.net.avaya.com (h198-152-12-101.outland.avaya.com [198.152.12.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03332 for ; Tue, 10 Jul 2001 10:49:25 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6AEmbx07411 for ; Tue, 10 Jul 2001 10:48:37 -0400 (EDT) Received: from NJ7460CLUSTER.usae.avaya.com (h135-8-7-232.avaya.com [135.8.7.232]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6AEmZn07384 for ; Tue, 10 Jul 2001 10:48:36 -0400 (EDT) Received: by nj7460cluster.usae.avaya.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 10:47:59 -0400 Message-ID: <1EB06B0C0D7B484BAECBFACCE290B39F8920D6@nj7460cluster.usae.avaya.com> From: "Boyer, D G (Dave)" To: "'Rosen, Brian'" , "Boyer, D G (Dave)" , "'adam.roach@ericsson.com'" , "'Jonathan Rosenberg'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 10 Jul 2001 10:47:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1094F.4E8E0080" Content-Length: 13258 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: 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_01C1094F.4E8E0080 Content-Type: text/plain; charset="iso-8859-1" Hi Brian, I am trying to get up to speed with this. I see where you are coming from with this, but I still have a question or three. From your answer below it appears that a subscription to the presence of an offline user and a subscription to a user who deny you access would lead to the same response. There will presumably be implementations that deal with the offline subscription problem; won't they need to have a different response from the case when a user tries to make an unauthorized subscription? Thanks Dave -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, July 10, 2001 10:38 AM To: 'Boyer, D G (Dave)'; Rosen, Brian; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization It's clearly a choice, but there are indeed nasty security problems that arise because information leaks that is intended to be helpful in diagnosing a problem, but instead is used by J. Wiley Hacker to debug his hack. Usually best to silently fail. Brian -----Original Message----- From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com] Sent: Tuesday, July 10, 2001 10:33 AM To: 'Rosen, Brian'; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization > -----Original Message----- > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] > Sent: Monday, July 09, 2001 1:13 PM > To: 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Of course. What is the point? > Every failure of the subscribe would return the URL > to a page that would authorize. It wouldn't matter if > there was or wasn't authorization. Denied authorization > wouldn't be distinguishable from failed or not attempted > authorization. > > It seems to me that trying to put a human in a protocol > loop is a bad design decision. The subscription results should > be immediate. The decision to seek authorization, and its > success or failure, is not really something that needs to be, > or should be standardized. What you want is the immediate > subscription to the presence to work between arbitrary > presentities and watcher/fetchers. The failure of > subscription, we agree, should not reveal why. Isn't this a policy decision that should be let up to the application? In some implementations it is allowable and useful to let a user know why their subscription failed. Dave Boyer > > Brian > > -----Original Message----- > > From: adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com ] > > Sent: Monday, July 09, 2001 11:47 AM > > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] > > > > > > Why can't the request to subscribe fail if there is no > > > authorization? Provide the URL in the response. > > > > Largely because it's crucial that an unauthorized subscription, > > a denied subscription, and a subscription to the presence of > > an offline user be completely and utterly indistinguishable > > from the point of view of the subscriber. > > > > /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_01C1094F.4E8E0080 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Another idea for presence authorization
Hi Brian,
 
I am trying to get up to speed with this.  I see where you are coming from with this, but
I still have a question or three.
From your answer below it appears that  a subscription to the presence of an offline
user and a subscription to a user who deny you access would lead to the same response.
There will presumably be implementations that deal with the offline subscription problem; won't they
need to have a different response from the case when a user tries to make an unauthorized subscription?
 
Thanks
Dave
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, July 10, 2001 10:38 AM
To: 'Boyer, D G (Dave)'; Rosen, Brian; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Another idea for presence authorization

It's clearly a choice, but there are indeed nasty security problems that
arise because information leaks that is intended to be helpful in diagnosing
a problem, but instead is used by J. Wiley Hacker to debug his hack.
Usually best to silently fail.
 
Brian
-----Original Message-----
From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com]
Sent: Tuesday, July 10, 2001 10:33 AM
To: 'Rosen, Brian'; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Another idea for presence authorization



> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Monday, July 09, 2001 1:13 PM
> To: 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Another idea for presence authorization
>
>
> Of course.  What is the point?
> Every failure of the subscribe would return the URL
> to a page that would authorize.  It wouldn't matter if
> there was or wasn't authorization.  Denied authorization
> wouldn't be distinguishable from failed or not attempted
> authorization.
>
> It seems to me that trying to put a human in a protocol
> loop is a bad design decision.  The subscription results should
> be immediate.  The decision to seek authorization, and its
> success or failure, is not really something that needs to be,
> or should be standardized.   What you want is the immediate
> subscription to the presence to work between arbitrary
> presentities and watcher/fetchers.  The failure of
> subscription, we agree, should not reveal why.

Isn't this a policy decision that should be let up to the application?
In some implementations it is allowable and useful to
let a user know why their subscription failed.

Dave Boyer

>      
> Brian
> > -----Original Message-----
> > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> > Sent: Monday, July 09, 2001 11:47 AM
> > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Another idea for presence authorization
> >
> >
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > >
> > > Why can't the request to subscribe fail if there is no
> > > authorization?  Provide the URL in the response.
> >
> > Largely because it's crucial that an unauthorized subscription,
> > a denied subscription, and a subscription to the presence of
> > an offline user be completely and utterly indistinguishable
> > from the point of view of the subscriber.
> >
> > /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_01C1094F.4E8E0080-- From Brian.Rosen@marconi.com Tue Jul 10 11:01:40 2001 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 LAA03423 for ; Tue, 10 Jul 2001 11:01:39 -0400 (EDT) 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 LAA15994; Tue, 10 Jul 2001 11:01:35 -0400 (EDT) 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 LAA11595; Tue, 10 Jul 2001 11:01:38 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Jul 2001 11:01:36 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465737@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , "'Jonathan Rosenberg'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 10 Jul 2001 11:01:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10951.351D05E0" Content-Length: 17143 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: 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_01C10951.351D05E0 Content-Type: text/plain; charset="iso-8859-1" Well, some of us may question what the proper response to an "offline" user subscription request might be. I would say that the subscription is accepted, if authorized, and you get a presence status that could be "off line", or something else ("not available" perhaps). That would be very handy if the presentity subsequently became available. YMMV, but existing systems do that. If you did want offline to return something that was an "error" when someone subscribes, AND the watcher/fetcher is authorized, then I'd say that wasn't much of a security issue. Still separates "authorization" from "subscription", which is the main point of the thread. Brian -----Original Message----- From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com] Sent: Tuesday, July 10, 2001 10:48 AM To: 'Rosen, Brian'; Boyer, D G (Dave); 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Hi Brian, I am trying to get up to speed with this. I see where you are coming from with this, but I still have a question or three. From your answer below it appears that a subscription to the presence of an offline user and a subscription to a user who deny you access would lead to the same response. There will presumably be implementations that deal with the offline subscription problem; won't they need to have a different response from the case when a user tries to make an unauthorized subscription? Thanks Dave -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, July 10, 2001 10:38 AM To: 'Boyer, D G (Dave)'; Rosen, Brian; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization It's clearly a choice, but there are indeed nasty security problems that arise because information leaks that is intended to be helpful in diagnosing a problem, but instead is used by J. Wiley Hacker to debug his hack. Usually best to silently fail. Brian -----Original Message----- From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com] Sent: Tuesday, July 10, 2001 10:33 AM To: 'Rosen, Brian'; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization > -----Original Message----- > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] > Sent: Monday, July 09, 2001 1:13 PM > To: 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Of course. What is the point? > Every failure of the subscribe would return the URL > to a page that would authorize. It wouldn't matter if > there was or wasn't authorization. Denied authorization > wouldn't be distinguishable from failed or not attempted > authorization. > > It seems to me that trying to put a human in a protocol > loop is a bad design decision. The subscription results should > be immediate. The decision to seek authorization, and its > success or failure, is not really something that needs to be, > or should be standardized. What you want is the immediate > subscription to the presence to work between arbitrary > presentities and watcher/fetchers. The failure of > subscription, we agree, should not reveal why. Isn't this a policy decision that should be let up to the application? In some implementations it is allowable and useful to let a user know why their subscription failed. Dave Boyer > > Brian > > -----Original Message----- > > From: adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com ] > > Sent: Monday, July 09, 2001 11:47 AM > > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] > > > > > > Why can't the request to subscribe fail if there is no > > > authorization? Provide the URL in the response. > > > > Largely because it's crucial that an unauthorized subscription, > > a denied subscription, and a subscription to the presence of > > an offline user be completely and utterly indistinguishable > > from the point of view of the subscriber. > > > > /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_01C10951.351D05E0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Another idea for presence authorization
Well, some of us may question what the proper response to an "offline"
user subscription request might be.  I would say that the subscription is
accepted, if authorized, and you get a presence status that could be
"off line", or something else ("not available" perhaps).  That would be
very handy if the presentity subsequently became available.  YMMV,
but existing systems do that.
 
If you did want offline to return something that was an "error" when
someone subscribes, AND the watcher/fetcher is authorized, then
I'd say that wasn't much of a security issue. 
 
Still separates "authorization" from "subscription", which is the main point
of the thread.
 
Brian
-----Original Message-----
From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com]
Sent: Tuesday, July 10, 2001 10:48 AM
To: 'Rosen, Brian'; Boyer, D G (Dave); 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Another idea for presence authorization

Hi Brian,
 
I am trying to get up to speed with this.  I see where you are coming from with this, but
I still have a question or three.
From your answer below it appears that  a subscription to the presence of an offline
user and a subscription to a user who deny you access would lead to the same response.
There will presumably be implementations that deal with the offline subscription problem; won't they
need to have a different response from the case when a user tries to make an unauthorized subscription?
 
Thanks
Dave
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, July 10, 2001 10:38 AM
To: 'Boyer, D G (Dave)'; Rosen, Brian; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Another idea for presence authorization

It's clearly a choice, but there are indeed nasty security problems that
arise because information leaks that is intended to be helpful in diagnosing
a problem, but instead is used by J. Wiley Hacker to debug his hack.
Usually best to silently fail.
 
Brian
-----Original Message-----
From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com]
Sent: Tuesday, July 10, 2001 10:33 AM
To: 'Rosen, Brian'; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Another idea for presence authorization



> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Monday, July 09, 2001 1:13 PM
> To: 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Another idea for presence authorization
>
>
> Of course.  What is the point?
> Every failure of the subscribe would return the URL
> to a page that would authorize.  It wouldn't matter if
> there was or wasn't authorization.  Denied authorization
> wouldn't be distinguishable from failed or not attempted
> authorization.
>
> It seems to me that trying to put a human in a protocol
> loop is a bad design decision.  The subscription results should
> be immediate.  The decision to seek authorization, and its
> success or failure, is not really something that needs to be,
> or should be standardized.   What you want is the immediate
> subscription to the presence to work between arbitrary
> presentities and watcher/fetchers.  The failure of
> subscription, we agree, should not reveal why.

Isn't this a policy decision that should be let up to the application?
In some implementations it is allowable and useful to
let a user know why their subscription failed.

Dave Boyer

>      
> Brian
> > -----Original Message-----
> > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> > Sent: Monday, July 09, 2001 11:47 AM
> > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Another idea for presence authorization
> >
> >
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > >
> > > Why can't the request to subscribe fail if there is no
> > > authorization?  Provide the URL in the response.
> >
> > Largely because it's crucial that an unauthorized subscription,
> > a denied subscription, and a subscription to the presence of
> > an offline user be completely and utterly indistinguishable
> > from the point of view of the subscriber.
> >
> > /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_01C10951.351D05E0-- From jdrosen@dynamicsoft.com Tue Jul 10 17:37:59 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04492 for ; Tue, 10 Jul 2001 17:37:58 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6ALbRki023584; Tue, 10 Jul 2001 17:37:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3THBBP3W>; Tue, 10 Jul 2001 17:37:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Jonathan Rosenberg , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 10 Jul 2001 17:37:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 7883 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: Brian, A lot of different things are being confused here. From your original response: > Why can't the request to subscribe fail if there is no > authorization? Provide the URL in the response. > > Get authorized, try subscribing again. > > Brian This is not right. The party that approves or denies the subscription is NOT the party that has subscribed. Here is the scenario. A subsciber, A, subscribes to B. For any subscription to B to be approved, B has to have given authorization for it. However, there is currently no authorization policy specified by B about whether A can subscribe. So, when A's subscription is received by the server, a response is generated, but the subscription is not activated. Now, the problem is that the server needs to know whether B approves this subscription. It might just wait, hoping that someday, B sets a policy for user A. However, that doesn't work well. What you want is some way to prod B, and say to him, "hey, A tried to subscribe, please set a policy for A". Then, A can go to some web page, or whatver the backend policy mechanism is, and set up policy. So, to provide this "prodding" capability, we've agreed to use a new event package, called watcherinfo. The idea is that B can subscribe to his own set of watchers, so that when it changes (for example, when A subscribes), B gets notified. B can then go to the web page and upload approval. The additional thing we are debating, is whether there should be an actual protocol mechanism for conveying that approval/rejection to the server. I have proposed that the NOTIFY that gets sent to B when A subscribes have two URLs specified by the server, one which approves the subscription from A, and one which rejects. Others have proposed that we specify a protocol for B to upload approval in a presence document. Others want to specify SIP/SOAP/WSDL for this. All of this is different from what A sees when A's subscription to B is rejected, approved, or marked as "pending" because there is no policy. We have already agreed some time back that in all cases, the subscription request is immediately responded to with a 202 and a NOTIFY with the status. If the subscription was accepted, the status is correct. If the subscription failed, or was marked as pending, the NOTIFY contains syntactically correct but invalid data. This way, the subscriber can't know what happened to their subscription. Hope that clarifies things. -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: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, July 10, 2001 11:02 AM To: 'Boyer, D G (Dave)'; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Well, some of us may question what the proper response to an "offline" user subscription request might be. I would say that the subscription is accepted, if authorized, and you get a presence status that could be "off line", or something else ("not available" perhaps). That would be very handy if the presentity subsequently became available. YMMV, but existing systems do that. If you did want offline to return something that was an "error" when someone subscribes, AND the watcher/fetcher is authorized, then I'd say that wasn't much of a security issue. Still separates "authorization" from "subscription", which is the main point of the thread. Brian -----Original Message----- From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com] Sent: Tuesday, July 10, 2001 10:48 AM To: 'Rosen, Brian'; Boyer, D G (Dave); 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Hi Brian, I am trying to get up to speed with this. I see where you are coming from with this, but I still have a question or three. From your answer below it appears that a subscription to the presence of an offline user and a subscription to a user who deny you access would lead to the same response. There will presumably be implementations that deal with the offline subscription problem; won't they need to have a different response from the case when a user tries to make an unauthorized subscription? Thanks Dave -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, July 10, 2001 10:38 AM To: 'Boyer, D G (Dave)'; Rosen, Brian; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization It's clearly a choice, but there are indeed nasty security problems that arise because information leaks that is intended to be helpful in diagnosing a problem, but instead is used by J. Wiley Hacker to debug his hack. Usually best to silently fail. Brian -----Original Message----- From: Boyer, D G (Dave) [mailto:dgboyer@avaya.com] Sent: Tuesday, July 10, 2001 10:33 AM To: 'Rosen, Brian'; 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, July 09, 2001 1:13 PM > To: 'adam.roach@ericsson.com'; 'Jonathan Rosenberg'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Of course. What is the point? > Every failure of the subscribe would return the URL > to a page that would authorize. It wouldn't matter if > there was or wasn't authorization. Denied authorization > wouldn't be distinguishable from failed or not attempted > authorization. > > It seems to me that trying to put a human in a protocol > loop is a bad design decision. The subscription results should > be immediate. The decision to seek authorization, and its > success or failure, is not really something that needs to be, > or should be standardized. What you want is the immediate > subscription to the presence to work between arbitrary > presentities and watcher/fetchers. The failure of > subscription, we agree, should not reveal why. Isn't this a policy decision that should be let up to the application? In some implementations it is allowable and useful to let a user know why their subscription failed. Dave Boyer > > Brian > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Monday, July 09, 2001 11:47 AM > > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > Why can't the request to subscribe fail if there is no > > > authorization? Provide the URL in the response. > > > > Largely because it's crucial that an unauthorized subscription, > > a denied subscription, and a subscription to the presence of > > an offline user be completely and utterly indistinguishable > > from the point of view of the subscriber. > > > > /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 Brian.Rosen@marconi.com Tue Jul 10 18:18:04 2001 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 SAA04629 for ; Tue, 10 Jul 2001 18:18:04 -0400 (EDT) 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 SAA02457; Tue, 10 Jul 2001 18:18:01 -0400 (EDT) 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 SAA08923; Tue, 10 Jul 2001 18:18:03 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Jul 2001 18:18:02 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465749@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 10 Jul 2001 18:18:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5484 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: Yes, I understand what you are proposing; I think it is not appropriate to confuse the concept of authorization (will I allow you to subscribe) from the actual subscription. You want to do that - you want the very first action to be a subscribe. If the server for B can immediately confirm a new authorization, because there is some policy in place that lets it do so, you propose to let that subscription succeed. You want to talk about what happens when it fails. I want to completely remove authorization from the protocol; Subscriptions are then only how you connect to the presentity's server. It succeeds if you are authorized, fails if you aren't (also fails for other reasons). I see no win at all to have the protocol deal with authorization. So, with that in mind, let's look at what you propose: > This is not right. The party that approves or denies the > subscription is NOT > the party that has subscribed. We all agree, B is the approver. B's server has the authorization. A subscribes. It succeeds only if B has given approval. > > Here is the scenario. A subsciber, A, subscribes to B. For > any subscription > to B to be approved, B has to have given authorization for > it. However, > there is currently no authorization policy specified by B > about whether A > can subscribe. So, when A's subscription is received by the server, a > response is generated, but the subscription is not activated. I claim if B has no authorization for A, then A's subscription request is denied, and that is the end of the story. So I agree you get a response, and that is fail, with a referral (URL). If A wants to get approval, he might consult the URL to find a web page that might allow him to be authorized. >Now, the > problem is that the server needs to know whether B approves this > subscription. It might just wait, hoping that someday, B sets > a policy for > user A. However, that doesn't work well. What you want is > some way to prod > B, and say to him, "hey, A tried to subscribe, please set a > policy for A". > Then, A can go to some web page, or whatver the backend > policy mechanism is, > and set up policy. Wrong end. You don't want B to take action just because A tried to subscribe. Great opportunity to drive B nuts. What you want to do is tell A how to get authorized. A is the one who wants to get authorized, and we can tell him how to do it. There is no win in telling B how to run his own authorization mechanism. Mostly, there is no win in prodding B based on a subscription attempt for A when A isn't even authorized. Importantly, the subscription request failed. If B's server eventually gets some authorization info, it has nothing to do with it but wait until A tries to subscribe again. > > So, to provide this "prodding" capability, we've agreed to > use a new event > package, called watcherinfo. The idea is that B can subscribe > to his own set > of watchers, so that when it changes (for example, when A > subscribes), B > gets notified. B can then go to the web page and upload approval. This seems wacky to me. Why should the protocol prod B? Why should the protocol do anything to support authorization - that is a non-real-time issue. Sending B an email may be a more appropriate thing to do, but that should be because A asks for authorization. The question is, how does A do that? The point is that since it's B's decision, B may need arbitrary information from A before he will authorize. Therefore, A needs to use B's authorization mechanism. You can't make A's user interface know how to give B what he needs to authorize. A web page that B creates is at least one way to do that. >The > additional thing we are debating, is whether there should be an actual > protocol mechanism for conveying that approval/rejection to > the server. I > have proposed that the NOTIFY that gets sent to B when A > subscribes have two > URLs specified by the server, one which approves the > subscription from A, > and one which rejects. Others have proposed that we specify a > protocol for B > to upload approval in a presence document. Others want to specify > SIP/SOAP/WSDL for this. Repeating myself, there is no point in having protocol support for human-in-the-loop messaging. While this might be something that is worth specifying so that B's agent can talk to B's server, I suspect that at least for now, we can safely leave this out of the spec because it has nothing to do with A and B. You are talking about how B the human interacts with B's server; not something I think is worth standardizing. > > All of this is different from what A sees when A's > subscription to B is > rejected, approved, or marked as "pending" because there is > no policy. We > have already agreed some time back that in all cases, the subscription > request is immediately responded to with a 202 and a NOTIFY > with the status. > If the subscription was accepted, the status is correct. If > the subscription > failed, or was marked as pending, the NOTIFY contains > syntactically correct > but invalid data. This way, the subscriber can't know what > happened to their > subscription. I think we are in agreement here. A doesn't get to know if he is authorized or not, subscription just fails. In particular, when B finally does authorize A, A has to "just know" to try subscribing again; we don't help him. It's always possible that the authorization mechanism tells A, say by email. Brian > From pkyzivat@cisco.com Tue Jul 10 19:18:25 2001 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 TAA04816 for ; Tue, 10 Jul 2001 19:18:25 -0400 (EDT) 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 f6ANGjn14983; Tue, 10 Jul 2001 19:16:45 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-146.cisco.com [161.44.241.146]) by cannon.cisco.com (Mirapoint) with ESMTP id ADL01392 (AUTH pkyzivat); Tue, 10 Jul 2001 19:18:11 -0400 (EDT) Message-ID: <3B4B8C14.497D0683@cisco.com> Date: Tue, 10 Jul 2001 19:13:24 -0400 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: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: <4FBEA8857476D311A03300204840E1CF04465749@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 6938 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: Brian, A key difference between what you propose and what Jonathan proposes is that in your scenario A is able to tell (because his SUBSCRIBE fails) that he isn't getting accurate presence information about B. In this case with Jonathan's proposal A believes that he has been permitted to subscribe and that B isn't present. I gather that Jonathan's approach is intended as a form of confidentiality, and is akin to having your secretary tell people you aren't in when you want to avoid them. Your proposal doesn't provide a way to do this sort of fibbing. While I understand the reason for wanting to do this, it seems to me that is incomplete, and as long as it is incomplete then it may not be worth the trouble. The reason it is incomplete is because A can still try inviting B and get a bunch of extra information out of the resulting status. To get the full intended effect, it is probably necessary to configure either the phone or a proxy, to return a particular status to undesired callers. Paul Kyzivat Cisco Systems "Rosen, Brian" wrote: > > Yes, I understand what you are proposing; I think it > is not appropriate to confuse the concept of > authorization (will I allow you to subscribe) from > the actual subscription. You want to do that - you > want the very first action to be a subscribe. > If the server for B can immediately confirm a new > authorization, because there is some policy in place > that lets it do so, you propose to let that subscription > succeed. You want to talk about what happens when > it fails. > > I want to completely remove authorization from the protocol; > Subscriptions are then only how you connect to the > presentity's server. It succeeds if you are authorized, > fails if you aren't (also fails for other reasons). > I see no win at all to have the protocol deal with > authorization. > > So, with that in mind, let's look at what you propose: > > > This is not right. The party that approves or denies the > > subscription is NOT > > the party that has subscribed. > We all agree, B is the approver. B's server has the authorization. > A subscribes. It succeeds only if B has given approval. > > > > > Here is the scenario. A subsciber, A, subscribes to B. For > > any subscription > > to B to be approved, B has to have given authorization for > > it. However, > > there is currently no authorization policy specified by B > > about whether A > > can subscribe. So, when A's subscription is received by the server, a > > response is generated, but the subscription is not activated. > I claim if B has no authorization for A, then A's subscription > request is denied, and that is the end of the story. > So I agree you get a response, and that is fail, with > a referral (URL). > > If A wants to get approval, he might consult the URL to find > a web page that might allow him to be authorized. > > >Now, the > > problem is that the server needs to know whether B approves this > > subscription. It might just wait, hoping that someday, B sets > > a policy for > > user A. However, that doesn't work well. What you want is > > some way to prod > > B, and say to him, "hey, A tried to subscribe, please set a > > policy for A". > > Then, A can go to some web page, or whatver the backend > > policy mechanism is, > > and set up policy. > Wrong end. You don't want B to take action just because > A tried to subscribe. Great opportunity to drive B nuts. > What you want to do is tell A how to get authorized. > A is the one who wants to get authorized, and we can tell > him how to do it. There is no win in telling B how to > run his own authorization mechanism. Mostly, there is > no win in prodding B based on a subscription attempt for A > when A isn't even authorized. > > Importantly, the subscription request failed. > If B's server eventually gets some authorization info, > it has nothing to do with it but wait until A tries > to subscribe again. > > > > > So, to provide this "prodding" capability, we've agreed to > > use a new event > > package, called watcherinfo. The idea is that B can subscribe > > to his own set > > of watchers, so that when it changes (for example, when A > > subscribes), B > > gets notified. B can then go to the web page and upload approval. > This seems wacky to me. Why should the protocol prod B? > Why should the protocol do anything to support authorization - > that is a non-real-time issue. Sending B an email may be a more > appropriate thing to do, but that should be because A asks for > authorization. The question is, how does A do that? The point > is that since it's B's decision, B may need arbitrary information > from A before he will authorize. Therefore, A needs to use B's > authorization mechanism. You can't make A's user interface > know how to give B what he needs to authorize. A web page that > B creates is at least one way to do that. > > >The > > additional thing we are debating, is whether there should be an actual > > protocol mechanism for conveying that approval/rejection to > > the server. I > > have proposed that the NOTIFY that gets sent to B when A > > subscribes have two > > URLs specified by the server, one which approves the > > subscription from A, > > and one which rejects. Others have proposed that we specify a > > protocol for B > > to upload approval in a presence document. Others want to specify > > SIP/SOAP/WSDL for this. > Repeating myself, there is no point in having protocol support > for human-in-the-loop messaging. While this might be something > that is worth specifying so that B's agent can talk to B's > server, I suspect that at least for now, we can safely leave this > out of the spec because it has nothing to do with A and B. > You are talking about how B the human interacts with B's server; > not something I think is worth standardizing. > > > > > All of this is different from what A sees when A's > > subscription to B is > > rejected, approved, or marked as "pending" because there is > > no policy. We > > have already agreed some time back that in all cases, the subscription > > request is immediately responded to with a 202 and a NOTIFY > > with the status. > > If the subscription was accepted, the status is correct. If > > the subscription > > failed, or was marked as pending, the NOTIFY contains > > syntactically correct > > but invalid data. This way, the subscriber can't know what > > happened to their > > subscription. > I think we are in agreement here. A doesn't get to know if > he is authorized or not, subscription just fails. > > In particular, when B finally does authorize A, A has to > "just know" to try subscribing again; we don't help him. > > It's always possible that the authorization mechanism tells > A, say by email. > > Brian > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From ssaha@lboard.com Tue Jul 10 19:37:32 2001 Received: from exmail.lboard.com (16.node.lboard.com [204.17.219.16] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04894 for ; Tue, 10 Jul 2001 19:37:32 -0400 (EDT) Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 16:37:00 -0700 Message-ID: From: Subir Saha To: "'Rosen, Brian'" , "'Jonathan Rosenberg'" , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 10 Jul 2001 16:36:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 6140 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: Brain: By sending the URL with a response to failed subscribers, are we not indicating that he is being denied to subscribe as opposed to silent rejection? Or we include the URL every time. Subir -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, July 10, 2001 3:18 PM To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; 'adam.roach@ericsson.com'; Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Yes, I understand what you are proposing; I think it is not appropriate to confuse the concept of authorization (will I allow you to subscribe) from the actual subscription. You want to do that - you want the very first action to be a subscribe. If the server for B can immediately confirm a new authorization, because there is some policy in place that lets it do so, you propose to let that subscription succeed. You want to talk about what happens when it fails. I want to completely remove authorization from the protocol; Subscriptions are then only how you connect to the presentity's server. It succeeds if you are authorized, fails if you aren't (also fails for other reasons). I see no win at all to have the protocol deal with authorization. So, with that in mind, let's look at what you propose: > This is not right. The party that approves or denies the > subscription is NOT > the party that has subscribed. We all agree, B is the approver. B's server has the authorization. A subscribes. It succeeds only if B has given approval. > > Here is the scenario. A subsciber, A, subscribes to B. For > any subscription > to B to be approved, B has to have given authorization for > it. However, > there is currently no authorization policy specified by B > about whether A > can subscribe. So, when A's subscription is received by the server, a > response is generated, but the subscription is not activated. I claim if B has no authorization for A, then A's subscription request is denied, and that is the end of the story. So I agree you get a response, and that is fail, with a referral (URL). If A wants to get approval, he might consult the URL to find a web page that might allow him to be authorized. >Now, the > problem is that the server needs to know whether B approves this > subscription. It might just wait, hoping that someday, B sets > a policy for > user A. However, that doesn't work well. What you want is > some way to prod > B, and say to him, "hey, A tried to subscribe, please set a > policy for A". > Then, A can go to some web page, or whatver the backend > policy mechanism is, > and set up policy. Wrong end. You don't want B to take action just because A tried to subscribe. Great opportunity to drive B nuts. What you want to do is tell A how to get authorized. A is the one who wants to get authorized, and we can tell him how to do it. There is no win in telling B how to run his own authorization mechanism. Mostly, there is no win in prodding B based on a subscription attempt for A when A isn't even authorized. Importantly, the subscription request failed. If B's server eventually gets some authorization info, it has nothing to do with it but wait until A tries to subscribe again. > > So, to provide this "prodding" capability, we've agreed to > use a new event > package, called watcherinfo. The idea is that B can subscribe > to his own set > of watchers, so that when it changes (for example, when A > subscribes), B > gets notified. B can then go to the web page and upload approval. This seems wacky to me. Why should the protocol prod B? Why should the protocol do anything to support authorization - that is a non-real-time issue. Sending B an email may be a more appropriate thing to do, but that should be because A asks for authorization. The question is, how does A do that? The point is that since it's B's decision, B may need arbitrary information from A before he will authorize. Therefore, A needs to use B's authorization mechanism. You can't make A's user interface know how to give B what he needs to authorize. A web page that B creates is at least one way to do that. >The > additional thing we are debating, is whether there should be an actual > protocol mechanism for conveying that approval/rejection to > the server. I > have proposed that the NOTIFY that gets sent to B when A > subscribes have two > URLs specified by the server, one which approves the > subscription from A, > and one which rejects. Others have proposed that we specify a > protocol for B > to upload approval in a presence document. Others want to specify > SIP/SOAP/WSDL for this. Repeating myself, there is no point in having protocol support for human-in-the-loop messaging. While this might be something that is worth specifying so that B's agent can talk to B's server, I suspect that at least for now, we can safely leave this out of the spec because it has nothing to do with A and B. You are talking about how B the human interacts with B's server; not something I think is worth standardizing. > > All of this is different from what A sees when A's > subscription to B is > rejected, approved, or marked as "pending" because there is > no policy. We > have already agreed some time back that in all cases, the subscription > request is immediately responded to with a 202 and a NOTIFY > with the status. > If the subscription was accepted, the status is correct. If > the subscription > failed, or was marked as pending, the NOTIFY contains > syntactically correct > but invalid data. This way, the subscriber can't know what > happened to their > subscription. I think we are in agreement here. A doesn't get to know if he is authorized or not, subscription just fails. In particular, when B finally does authorize A, A has to "just know" to try subscribing again; we don't help him. It's always possible that the authorization mechanism tells A, say by email. Brian > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From jdrosen@dynamicsoft.com Tue Jul 10 21:58:09 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05292 for ; Tue, 10 Jul 2001 21:58:09 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6B1veki024408; Tue, 10 Jul 2001 21:57:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3VPSWHN5>; Tue, 10 Jul 2001 21:58:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" , Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 10 Jul 2001 21:58:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 8604 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: Brian, Now I understand what you are saying. I want there to be a way for B to find out when someone subscribes to him, so he can, if desired, provide authorization. You don't want to ever tell B when someone subscribes; rather, you tell A that they should visit some web page, and maybe that allows them to send email to B asking for authorization. So, let me make a few comments in response: 1. this bit about letting B know is **NOT** part of the main presence specification whatsoever. All that specification says is "the server obtains authorization in some fashion, not specified". The mechanism that allows B to find out who subscribes is separate, and opt-in, not opt-out. That is, B has to explicitly request to find out who subscribed to him. If B does nothing, B finds out nothing. Presence servers don't have to provide the function either. 2. why even worry about this? Well, all of the major IM and presence systems do this today. We should at least be able to provide the same application interface thats available, if users and their providers want it. 3. I agree with you that defining authorization policy is a back-end mechanism, and typically not real time. Thats why I have been arguing that the notification to B about the subscriber contain http URLs that can be used to accept/reject, and those URLs are part of the back-end non-real-time application. They facilitate a screen pop to a slim phone that says "approve or reject?" and thus allows setting of simple policies right away without a browser. The problem that has been observed with your alternate approach, of telling A about a URL, is that this allows A to learn whether they have been approved or rejected. Paul argues that this knowledge can be learned anyway, by sending an INVITE and seeing whether the call is accepted or rejected. Not necessarily; I can set up a service to achieve the same effect for voice. If someone calls me, and I don't want to talk to them, instead of them getting a "600 I hate you" response, the server can simply let the phone ring indefinitely, so that the caller can't tell whether I'm not there, or whether they've been rejected. -Jonathan R. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, July 10, 2001 6:18 PM > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Yes, I understand what you are proposing; I think it > is not appropriate to confuse the concept of > authorization (will I allow you to subscribe) from > the actual subscription. You want to do that - you > want the very first action to be a subscribe. > If the server for B can immediately confirm a new > authorization, because there is some policy in place > that lets it do so, you propose to let that subscription > succeed. You want to talk about what happens when > it fails. > > I want to completely remove authorization from the protocol; > Subscriptions are then only how you connect to the > presentity's server. It succeeds if you are authorized, > fails if you aren't (also fails for other reasons). > I see no win at all to have the protocol deal with > authorization. > > So, with that in mind, let's look at what you propose: > > > This is not right. The party that approves or denies the > > subscription is NOT > > the party that has subscribed. > We all agree, B is the approver. B's server has the authorization. > A subscribes. It succeeds only if B has given approval. > > > > > Here is the scenario. A subsciber, A, subscribes to B. For > > any subscription > > to B to be approved, B has to have given authorization for > > it. However, > > there is currently no authorization policy specified by B > > about whether A > > can subscribe. So, when A's subscription is received by the > server, a > > response is generated, but the subscription is not activated. > I claim if B has no authorization for A, then A's subscription > request is denied, and that is the end of the story. > So I agree you get a response, and that is fail, with > a referral (URL). > > If A wants to get approval, he might consult the URL to find > a web page that might allow him to be authorized. > > >Now, the > > problem is that the server needs to know whether B approves this > > subscription. It might just wait, hoping that someday, B sets > > a policy for > > user A. However, that doesn't work well. What you want is > > some way to prod > > B, and say to him, "hey, A tried to subscribe, please set a > > policy for A". > > Then, A can go to some web page, or whatver the backend > > policy mechanism is, > > and set up policy. > Wrong end. You don't want B to take action just because > A tried to subscribe. Great opportunity to drive B nuts. > What you want to do is tell A how to get authorized. > A is the one who wants to get authorized, and we can tell > him how to do it. There is no win in telling B how to > run his own authorization mechanism. Mostly, there is > no win in prodding B based on a subscription attempt for A > when A isn't even authorized. > > Importantly, the subscription request failed. > If B's server eventually gets some authorization info, > it has nothing to do with it but wait until A tries > to subscribe again. > > > > > So, to provide this "prodding" capability, we've agreed to > > use a new event > > package, called watcherinfo. The idea is that B can subscribe > > to his own set > > of watchers, so that when it changes (for example, when A > > subscribes), B > > gets notified. B can then go to the web page and upload approval. > This seems wacky to me. Why should the protocol prod B? > Why should the protocol do anything to support authorization - > that is a non-real-time issue. Sending B an email may be a more > appropriate thing to do, but that should be because A asks for > authorization. The question is, how does A do that? The point > is that since it's B's decision, B may need arbitrary information > from A before he will authorize. Therefore, A needs to use B's > authorization mechanism. You can't make A's user interface > know how to give B what he needs to authorize. A web page that > B creates is at least one way to do that. > > >The > > additional thing we are debating, is whether there should > be an actual > > protocol mechanism for conveying that approval/rejection to > > the server. I > > have proposed that the NOTIFY that gets sent to B when A > > subscribes have two > > URLs specified by the server, one which approves the > > subscription from A, > > and one which rejects. Others have proposed that we specify a > > protocol for B > > to upload approval in a presence document. Others want to specify > > SIP/SOAP/WSDL for this. > Repeating myself, there is no point in having protocol support > for human-in-the-loop messaging. While this might be something > that is worth specifying so that B's agent can talk to B's > server, I suspect that at least for now, we can safely leave this > out of the spec because it has nothing to do with A and B. > You are talking about how B the human interacts with B's server; > not something I think is worth standardizing. > > > > > All of this is different from what A sees when A's > > subscription to B is > > rejected, approved, or marked as "pending" because there is > > no policy. We > > have already agreed some time back that in all cases, the > subscription > > request is immediately responded to with a 202 and a NOTIFY > > with the status. > > If the subscription was accepted, the status is correct. If > > the subscription > > failed, or was marked as pending, the NOTIFY contains > > syntactically correct > > but invalid data. This way, the subscriber can't know what > > happened to their > > subscription. > I think we are in agreement here. A doesn't get to know if > he is authorized or not, subscription just fails. > > In particular, when B finally does authorize A, A has to > "just know" to try subscribing again; we don't help him. > > It's always possible that the authorization mechanism tells > A, say by email. > > Brian > > > --- 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 From jdrosen@dynamicsoft.com Tue Jul 10 23:52:18 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05604 for ; Tue, 10 Jul 2001 23:52:18 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6B3pnki024526; Tue, 10 Jul 2001 23:51:49 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3VPSWHRM>; Tue, 10 Jul 2001 23:52:16 -0400 Message-ID: From: Jonathan Rosenberg To: "'Vasilis Polychronidis'" , Jonathan Rosenberg Cc: Robert Sparks , "'simple@mailman.dynamicsoft.com'" , "'sean.olson@ericsson.com'" Subject: RE: [Simple] IM: A session or not Date: Tue, 10 Jul 2001 23:52:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 4143 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: > -----Original Message----- > From: Vasilis Polychronidis > [mailto:Vasilis.Polychronidis@Openwave.com] > Sent: Sunday, July 08, 2001 8:40 PM > To: Jonathan Rosenberg > Cc: Robert Sparks; 'simple@mailman.dynamicsoft.com'; > 'sean.olson@ericsson.com' > Subject: Re: [Simple] IM: A session or not > > > Hi All, > I think this was the last message on this thread (IM: A > session or not). > This was a very interesting discussion. > Can someone summarize the consensus of the group on this > important issue? I think there was consensus that we would move forward with: 1. defining MESSAGE as a sessionless page mechanism 2. allow for INVITE/BYE to establish an IM session I think we still have a bit more thinking to do on exactly how the IM-as-a-session will work. I had proposed including a SIP URL in the SDP, which will work in many cases, but there are still some record-routing issues, like the one Robert points out. I don't think those details were yet ironed out, though. -Jonathan R. > > > -----Original Message----- > > > From: Robert Sparks > > > Sent: Sunday, May 13, 2001 2:28 AM > > > To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com'; > > > 'sean.olson@ericsson.com' > > > Subject: RE: [Simple] IM: A session or not > > > > > > > > > > > > > >> If the conversation forks in > > > >> one direction, it will _stay_ forked through the whole > > > conversation. > > > > > > > >By conversation, are you referring to the sip call, or the > > > message "stream"? > > > > > > The stream of MESSAGE requests (the "chat" conversation). > > > Since we do not > > > want to make any distinction between a page MESSAGE and a > > > chat MESSAGE, if > > > for some reason the stream hits a proxy that forks the chat > > > MESSAGEs, it > > > will fork every one. > > > > > > This is an unlikely scenario - in the best of worlds, we've > > > signaled direct > > > peer-peer delivery of chat MESSAGEs using the SDP in the > > > INVITE. However, if > > > we've been forced to use an outbound proxy, or have > > > introduced a proxy through > > > preloaded routes, as mentioned above, there's a chance that > > > something along > > > the path will fork the chat MESSAGEs. > > > > > > I'm not claiming this is a problem. I just wanted to make > > > sure everyone > > > understood the possibility existed. > > > > Yes, it does. Under normal cases, where either Route is > used, or where a > > direct messaging occurs, it definitely won't. In cases > where it does end up > > forking, you want to be able to reject the message at all > hosts except the > > one that was really supposed to get it. The right way to do > that is to > > include a tag in the To field of all MESSAGE requests. This > tag would be set > > as part of the URI in the SDP. Doing this is a little bit > of a stretch; tag > > is really meant for requests that are part of a session. > Technically, since > > MESSAGE operates like OPTIONS, there is really no SIP > session associated > > with the collection of MESSAGES. But, I think its probably > reasonable to use > > tag in any case. We need to explicitly note, in the text, > that a UA should > > reject a MESSAGE if it contains a to tag that is unrecognized. > > > > -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 > > > --- 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 From Brian.Rosen@marconi.com Wed Jul 11 08:41:49 2001 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 IAA06981 for ; Wed, 11 Jul 2001 08:41:49 -0400 (EDT) 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 IAA10792; Wed, 11 Jul 2001 08:41:46 -0400 (EDT) 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 IAA25098; Wed, 11 Jul 2001 08:41:48 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Jul 2001 08:41:46 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446574C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 11 Jul 2001 08:41:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 4233 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: Jonathan We agree that the authorization mechanism is not part of the spec, so why is notification of request for subscription part of the spec? In particular, why is there a STANDARD way that B finds out that A wants to subscribe? That is entirely within the domain of B's implementation, and usually we don't standardize such things. > 1. this bit about letting B know is **NOT** part of the main presence > specification whatsoever. All that specification says is "the > server obtains > authorization in some fashion, not specified". The mechanism > that allows B > to find out who subscribes is separate, and opt-in, not > opt-out. That is, B > has to explicitly request to find out who subscribed to him. If B does > nothing, B finds out nothing. Presence servers don't have to > provide the > function either. Got it, but that is entirely in B's implementation - there is no point in standardizing how B's server tells B the human how to authorize (or indeed that he is asked to authorize). If your implementation wanted to use such a mechanism, and mine wanted to send me email, they would interoperate. In fact, no aspect of interoperability is affected by this spec, and thus I claim it is not appropriate. My suggestion, on the other hand, is about interoperability - if B wants to let A know how to get authorized, he can supply the URL. A's implementation - not knowing anything about B's implementation, could assist A to get authorization. While there could be other ways, having one standardized way is a good thing. > > 2. why even worry about this? Well, all of the major IM and > presence systems > do this today. We should at least be able to provide the same > application > interface thats available, if users and their providers want it. Excuse me, all existing IM systems have a way to find out who is subscribed to your presence? All existing IM systems supply two URLs to approve or deny subscriptions? Funny, I didn't think any of them did. Let me fire up AIM. Hmmm, doesn't seem to have any controls on authorization, doesn't seem to have a way to find out who is looking at your presence. You can control who sends you IM. Actually, I don't know of ANY existing presence service that has the authorization idea, although there are "closed group" systems which limit who can do anything. Of course if there were, my argument still holds - it's within one implementation, not subject to standardization. > > 3. I agree with you that defining authorization policy is a back-end > mechanism, and typically not real time. Thats why I have been > arguing that > the notification to B about the subscriber contain http URLs > that can be > used to accept/reject, and those URLs are part of the > back-end non-real-time > application. They facilitate a screen pop to a slim phone > that says "approve > or reject?" and thus allows setting of simple policies right > away without a > browser. That may be appropriate for some implementations, but clearly not all. However, it doesn't matter because it's entirely in one implementation. > > The problem that has been observed with your alternate > approach, of telling > A about a URL, is that this allows A to learn whether they have been > approved or rejected. Paul argues that this knowledge can be > learned anyway, > by sending an INVITE and seeing whether the call is accepted > or rejected. > Not necessarily; I can set up a service to achieve the same effect for > voice. If someone calls me, and I don't want to talk to them, > instead of > them getting a "600 I hate you" response, the server can > simply let the > phone ring indefinitely, so that the caller can't tell whether I'm not > there, or whether they've been rejected. Well of course if the behavior you want is that authorization is automatic, and what you get is a constant presence indication of some form of "not available", fine, your presence system allows anyone to subscribe any time. That means the subscription never fails, and you don't see my URL. A policy choice, which I would certainly support. Seems to be lots of opportunity for DoS attacks, but if you get flooded with SUBSCRIBEs that fail, that is a form of DoS attack too. Brian From Brian.Rosen@marconi.com Wed Jul 11 08:46:38 2001 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 IAA07012 for ; Wed, 11 Jul 2001 08:46:37 -0400 (EDT) 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 IAA11416; Wed, 11 Jul 2001 08:46:35 -0400 (EDT) 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 IAA26558; Wed, 11 Jul 2001 08:46:37 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Jul 2001 08:46:31 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446574E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Subir Saha'" , "'Jonathan Rosenberg'" , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 11 Jul 2001 08:46:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 6904 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: Policy choice. You can: 1. Fail and return the URL 2. Fail silently 3. Succeed and return constant status Brian > -----Original Message----- > From: Subir Saha [mailto:ssaha@lboard.com] > Sent: Tuesday, July 10, 2001 7:37 PM > To: 'Rosen, Brian'; 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Brain: > By sending the URL with a response to failed subscribers, are we not > indicating that he is being denied to subscribe as opposed to silent > rejection? Or we include the URL every time. > > Subir > > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, July 10, 2001 3:18 PM > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Yes, I understand what you are proposing; I think it > is not appropriate to confuse the concept of > authorization (will I allow you to subscribe) from > the actual subscription. You want to do that - you > want the very first action to be a subscribe. > If the server for B can immediately confirm a new > authorization, because there is some policy in place > that lets it do so, you propose to let that subscription > succeed. You want to talk about what happens when > it fails. > > I want to completely remove authorization from the protocol; > Subscriptions are then only how you connect to the > presentity's server. It succeeds if you are authorized, > fails if you aren't (also fails for other reasons). > I see no win at all to have the protocol deal with > authorization. > > So, with that in mind, let's look at what you propose: > > > This is not right. The party that approves or denies the > > subscription is NOT > > the party that has subscribed. > We all agree, B is the approver. B's server has the authorization. > A subscribes. It succeeds only if B has given approval. > > > > > Here is the scenario. A subsciber, A, subscribes to B. For > > any subscription > > to B to be approved, B has to have given authorization for > > it. However, > > there is currently no authorization policy specified by B > > about whether A > > can subscribe. So, when A's subscription is received by the > server, a > > response is generated, but the subscription is not activated. > I claim if B has no authorization for A, then A's subscription > request is denied, and that is the end of the story. > So I agree you get a response, and that is fail, with > a referral (URL). > > If A wants to get approval, he might consult the URL to find > a web page that might allow him to be authorized. > > >Now, the > > problem is that the server needs to know whether B approves this > > subscription. It might just wait, hoping that someday, B sets > > a policy for > > user A. However, that doesn't work well. What you want is > > some way to prod > > B, and say to him, "hey, A tried to subscribe, please set a > > policy for A". > > Then, A can go to some web page, or whatver the backend > > policy mechanism is, > > and set up policy. > Wrong end. You don't want B to take action just because > A tried to subscribe. Great opportunity to drive B nuts. > What you want to do is tell A how to get authorized. > A is the one who wants to get authorized, and we can tell > him how to do it. There is no win in telling B how to > run his own authorization mechanism. Mostly, there is > no win in prodding B based on a subscription attempt for A > when A isn't even authorized. > > Importantly, the subscription request failed. > If B's server eventually gets some authorization info, > it has nothing to do with it but wait until A tries > to subscribe again. > > > > > So, to provide this "prodding" capability, we've agreed to > > use a new event > > package, called watcherinfo. The idea is that B can subscribe > > to his own set > > of watchers, so that when it changes (for example, when A > > subscribes), B > > gets notified. B can then go to the web page and upload approval. > This seems wacky to me. Why should the protocol prod B? > Why should the protocol do anything to support authorization - > that is a non-real-time issue. Sending B an email may be a more > appropriate thing to do, but that should be because A asks for > authorization. The question is, how does A do that? The point > is that since it's B's decision, B may need arbitrary information > from A before he will authorize. Therefore, A needs to use B's > authorization mechanism. You can't make A's user interface > know how to give B what he needs to authorize. A web page that > B creates is at least one way to do that. > > >The > > additional thing we are debating, is whether there should > be an actual > > protocol mechanism for conveying that approval/rejection to > > the server. I > > have proposed that the NOTIFY that gets sent to B when A > > subscribes have two > > URLs specified by the server, one which approves the > > subscription from A, > > and one which rejects. Others have proposed that we specify a > > protocol for B > > to upload approval in a presence document. Others want to specify > > SIP/SOAP/WSDL for this. > Repeating myself, there is no point in having protocol support > for human-in-the-loop messaging. While this might be something > that is worth specifying so that B's agent can talk to B's > server, I suspect that at least for now, we can safely leave this > out of the spec because it has nothing to do with A and B. > You are talking about how B the human interacts with B's server; > not something I think is worth standardizing. > > > > > All of this is different from what A sees when A's > > subscription to B is > > rejected, approved, or marked as "pending" because there is > > no policy. We > > have already agreed some time back that in all cases, the > subscription > > request is immediately responded to with a 202 and a NOTIFY > > with the status. > > If the subscription was accepted, the status is correct. If > > the subscription > > failed, or was marked as pending, the NOTIFY contains > > syntactically correct > > but invalid data. This way, the subscriber can't know what > > happened to their > > subscription. > I think we are in agreement here. A doesn't get to know if > he is authorized or not, subscription just fails. > > In particular, when B finally does authorize A, A has to > "just know" to try subscribing again; we don't help him. > > It's always possible that the authorization mechanism tells > A, say by email. > > Brian > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From mhammer@cisco.com Wed Jul 11 10:35:03 2001 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 KAA07305 for ; Wed, 11 Jul 2001 10:35:03 -0400 (EDT) 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 KAA17702; Wed, 11 Jul 2001 10:35:00 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id AKU05119; Wed, 11 Jul 2001 10:35:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20010711101227.00b0cf00@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jul 2001 10:37:20 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] Another idea for presence authorization Cc: "'Rosen, Brian'" , Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 10028 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: Jonathan, Why is this so hard? It seems there are three separate processes here: A: Authorization - between system and authorizer B: Subscription - requestor and system C: Notification - presentity and subscriber C won't happen without B won't complete without A. Only C should be reveal presence. If X subscribes, they get a response saying "your request has been accepted, you'll know it worked when you start getting notifications." Variation: If X subscribes and was already authorized, response says "you were previously accepted." Says nothing about when that occurred. Note this should not be done for rejections, as consecutive pings by X could detect when X went from accepted to rejected, indicating presence at least momentarily. When the authorizer logs in, they accept (authorize) or reject requests. Notifications occur based on authorized subscriptions. Have I missed something? Mike At 09:58 PM 7/10/2001 -0400, Jonathan Rosenberg wrote: >Brian, > >Now I understand what you are saying. I want there to be a way for B to find >out when someone subscribes to him, so he can, if desired, provide >authorization. You don't want to ever tell B when someone subscribes; >rather, you tell A that they should visit some web page, and maybe that >allows them to send email to B asking for authorization. > >So, let me make a few comments in response: > >1. this bit about letting B know is **NOT** part of the main presence >specification whatsoever. All that specification says is "the server obtains >authorization in some fashion, not specified". The mechanism that allows B >to find out who subscribes is separate, and opt-in, not opt-out. That is, B >has to explicitly request to find out who subscribed to him. If B does >nothing, B finds out nothing. Presence servers don't have to provide the >function either. > >2. why even worry about this? Well, all of the major IM and presence systems >do this today. We should at least be able to provide the same application >interface thats available, if users and their providers want it. > >3. I agree with you that defining authorization policy is a back-end >mechanism, and typically not real time. Thats why I have been arguing that >the notification to B about the subscriber contain http URLs that can be >used to accept/reject, and those URLs are part of the back-end non-real-time >application. They facilitate a screen pop to a slim phone that says "approve >or reject?" and thus allows setting of simple policies right away without a >browser. > >The problem that has been observed with your alternate approach, of telling >A about a URL, is that this allows A to learn whether they have been >approved or rejected. Paul argues that this knowledge can be learned anyway, >by sending an INVITE and seeing whether the call is accepted or rejected. >Not necessarily; I can set up a service to achieve the same effect for >voice. If someone calls me, and I don't want to talk to them, instead of >them getting a "600 I hate you" response, the server can simply let the >phone ring indefinitely, so that the caller can't tell whether I'm not >there, or whether they've been rejected. > >-Jonathan R. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, July 10, 2001 6:18 PM > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Yes, I understand what you are proposing; I think it > > is not appropriate to confuse the concept of > > authorization (will I allow you to subscribe) from > > the actual subscription. You want to do that - you > > want the very first action to be a subscribe. > > If the server for B can immediately confirm a new > > authorization, because there is some policy in place > > that lets it do so, you propose to let that subscription > > succeed. You want to talk about what happens when > > it fails. > > > > I want to completely remove authorization from the protocol; > > Subscriptions are then only how you connect to the > > presentity's server. It succeeds if you are authorized, > > fails if you aren't (also fails for other reasons). > > I see no win at all to have the protocol deal with > > authorization. > > > > So, with that in mind, let's look at what you propose: > > > > > This is not right. The party that approves or denies the > > > subscription is NOT > > > the party that has subscribed. > > We all agree, B is the approver. B's server has the authorization. > > A subscribes. It succeeds only if B has given approval. > > > > > > > > Here is the scenario. A subsciber, A, subscribes to B. For > > > any subscription > > > to B to be approved, B has to have given authorization for > > > it. However, > > > there is currently no authorization policy specified by B > > > about whether A > > > can subscribe. So, when A's subscription is received by the > > server, a > > > response is generated, but the subscription is not activated. > > I claim if B has no authorization for A, then A's subscription > > request is denied, and that is the end of the story. > > So I agree you get a response, and that is fail, with > > a referral (URL). > > > > If A wants to get approval, he might consult the URL to find > > a web page that might allow him to be authorized. > > > > >Now, the > > > problem is that the server needs to know whether B approves this > > > subscription. It might just wait, hoping that someday, B sets > > > a policy for > > > user A. However, that doesn't work well. What you want is > > > some way to prod > > > B, and say to him, "hey, A tried to subscribe, please set a > > > policy for A". > > > Then, A can go to some web page, or whatver the backend > > > policy mechanism is, > > > and set up policy. > > Wrong end. You don't want B to take action just because > > A tried to subscribe. Great opportunity to drive B nuts. > > What you want to do is tell A how to get authorized. > > A is the one who wants to get authorized, and we can tell > > him how to do it. There is no win in telling B how to > > run his own authorization mechanism. Mostly, there is > > no win in prodding B based on a subscription attempt for A > > when A isn't even authorized. > > > > Importantly, the subscription request failed. > > If B's server eventually gets some authorization info, > > it has nothing to do with it but wait until A tries > > to subscribe again. > > > > > > > > So, to provide this "prodding" capability, we've agreed to > > > use a new event > > > package, called watcherinfo. The idea is that B can subscribe > > > to his own set > > > of watchers, so that when it changes (for example, when A > > > subscribes), B > > > gets notified. B can then go to the web page and upload approval. > > This seems wacky to me. Why should the protocol prod B? > > Why should the protocol do anything to support authorization - > > that is a non-real-time issue. Sending B an email may be a more > > appropriate thing to do, but that should be because A asks for > > authorization. The question is, how does A do that? The point > > is that since it's B's decision, B may need arbitrary information > > from A before he will authorize. Therefore, A needs to use B's > > authorization mechanism. You can't make A's user interface > > know how to give B what he needs to authorize. A web page that > > B creates is at least one way to do that. > > > > >The > > > additional thing we are debating, is whether there should > > be an actual > > > protocol mechanism for conveying that approval/rejection to > > > the server. I > > > have proposed that the NOTIFY that gets sent to B when A > > > subscribes have two > > > URLs specified by the server, one which approves the > > > subscription from A, > > > and one which rejects. Others have proposed that we specify a > > > protocol for B > > > to upload approval in a presence document. Others want to specify > > > SIP/SOAP/WSDL for this. > > Repeating myself, there is no point in having protocol support > > for human-in-the-loop messaging. While this might be something > > that is worth specifying so that B's agent can talk to B's > > server, I suspect that at least for now, we can safely leave this > > out of the spec because it has nothing to do with A and B. > > You are talking about how B the human interacts with B's server; > > not something I think is worth standardizing. > > > > > > > > All of this is different from what A sees when A's > > > subscription to B is > > > rejected, approved, or marked as "pending" because there is > > > no policy. We > > > have already agreed some time back that in all cases, the > > subscription > > > request is immediately responded to with a 202 and a NOTIFY > > > with the status. > > > If the subscription was accepted, the status is correct. If > > > the subscription > > > failed, or was marked as pending, the NOTIFY contains > > > syntactically correct > > > but invalid data. This way, the subscriber can't know what > > > happened to their > > > subscription. > > I think we are in agreement here. A doesn't get to know if > > he is authorized or not, subscription just fails. > > > > In particular, when B finally does authorize A, A has to > > "just know" to try subscribing again; we don't help him. > > > > It's always possible that the authorization mechanism tells > > A, say by email. > > > > Brian > > > > > > >--- >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 mhammer@cisco.com Wed Jul 11 13:51:32 2001 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 NAA07988 for ; Wed, 11 Jul 2001 13:51:32 -0400 (EDT) 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 NAA20602; Wed, 11 Jul 2001 13:51:31 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id AKU07186; Wed, 11 Jul 2001 13:51:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20010711134429.03d6aa70@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jul 2001 13:53:49 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] Another idea for presence authorization Cc: Jonathan Rosenberg , "'Rosen, Brian'" , Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 3318 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: At 01:36 PM 7/11/2001 -0400, Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Wednesday, July 11, 2001 10:37 AM > > To: Jonathan Rosenberg > > Cc: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell; > > simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Jonathan, > > > > Why is this so hard? It seems there are three separate > > processes here: > > > > A: Authorization - between system and authorizer > > B: Subscription - requestor and system > > C: Notification - presentity and subscriber > >Well, the notification is really between the system and the subscriber, but >thats a nit. > > > > > C won't happen without B won't complete without A. > > Only C should be reveal presence. > > > > If X subscribes, they get a response saying "your request has been > > accepted, you'll know it worked when you start getting notifications." > >That is what is specified now, yes. > > > > > Variation: If X subscribes and was already authorized, > > response says "you > > were previously accepted." Says nothing about when that > > occurred. Note > > this should not be done for rejections, as consecutive pings > > by X could > > detect when X went from accepted to rejected, indicating > > presence at least > > momentarily. > > > > When the authorizer logs in, they accept (authorize) or > > reject requests. > > > > Notifications occur based on authorized subscriptions. > > > > Have I missed something? > >Yes. You say: > >"when the authorizer logs in, they accept (authorize) or reject requests". > >How does the authorizer know whether there are subscriptions waiting to be >authorized? Sure, the system can send the authorizer email, or an IM, but >that means there is no way to manage that information on the client side >using an automata which queries the user, or applies local policy to >generate an authorization. I'm interested in this primarily because that is >what systems do today. When I start Yahoo, it tells me who has tried to >subscribe, and allows me to accept/reject each of those. Are we willing to >say that a tool cannot be written that queries the user for this, that the >only way is to send email or IM or something else which is only >interpretable by a human? Not that using IM or email is bad; just that we >may want to enable an automata to handle the information. I should have described the transaction there. I believe that is related to the watcherinfo stuff you were working on. I was viewing that as part of A above. Once you log into the system, the authentication process sends you a message indicating who requested subscription and your response contains the authorize/deny per request. The key is that A, B, and C are independent transactions only related together by the system application. Mike >-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 From Brian.Rosen@marconi.com Wed Jul 11 14:25:17 2001 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 OAA08102 for ; Wed, 11 Jul 2001 14:25:17 -0400 (EDT) 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 OAA22205; Wed, 11 Jul 2001 14:25:14 -0400 (EDT) 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 OAA11433; Wed, 11 Jul 2001 14:25:17 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Jul 2001 14:25:15 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF0446575C@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 11 Jul 2001 14:25:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 8283 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: Well, I'm real confused. 1. The "automata" you are talking about -- I don't understand what role it has in the context of this discussion. We have "servers" that have presence information and "clients" that want to get it. The server is an entity operating on behalf of a presentity. The client is an entity operating on behalf of a watcher. In SIP terms, we have a UAC and a UAS. The UAS is the agent of the presentity, and the UAC is the agent of the watcher. Now, where is this automata? In the UAS? The UAS is what the protocol defines, you seem to want to deal with something that is not the UAS but is connecting to it. At the moment, the model I'm imagining in your head is one where the presentity and the watcher are both UACs and there is a centralized UAS - the sort of AIM/Yahoo/MSN messenger idea. If that is the model you are pushing, I want to push back. The UAC is the agent of the presentity, the UAS is the agent of the watcher, and the UAC doesn't need any protocol to the presentity -- it "is" the presentity. If you want the presentity to be a UAC, then we need more than what we are talking about on this thread - we need to standardize how the UAC at the presentity tells the UAS how to change its presence, and then we get into all sorts of issues about how this model supports rich presence information (since it requires that two UACs AND the UAS all have the same capabilities). How the UAC interacts with the presentity is not the place we standardize. It could be split into a "client" and a "server", but the interactions between those pieces are complex, and I don't see how we could standardize them right now. 2. I never used Yahoo Messenger. I just loaded it. Yes, you get a message when someone puts you in his friend list. However, what it is asking you seems to be whether you want to put him in YOUR buddy list. In particular, if you reject, you are still in his friend list, and he sees your presence. You cannot hide your presence from someone. You can hide your presence from everyone, and you can ignore messages from selected people. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 11, 2001 1:50 PM > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Wednesday, July 11, 2001 8:42 AM > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Jonathan > > > > We agree that the authorization mechanism is not part of > > the spec, so why is notification of request for subscription > > part of the spec? In particular, why is there a STANDARD > > way that B finds out that A wants to subscribe? That > > is entirely within the domain of B's implementation, and > > usually we don't standardize such things. > > We standardize things when an automata and one point needs to > process some > information sent by an entity at another point. If we want a client > application to be able to process the fact that a > subscription was made to > its user (so that it might, for example, do a screen pop asking for > approval), then we need a standard. If we think that this > information will > never be processed by automata, then we don't need a > standard. I think we > might need it processed by automata. > > > > > > 1. this bit about letting B know is **NOT** part of the > > main presence > > > specification whatsoever. All that specification says is "the > > > server obtains > > > authorization in some fashion, not specified". The mechanism > > > that allows B > > > to find out who subscribes is separate, and opt-in, not > > > opt-out. That is, B > > > has to explicitly request to find out who subscribed to > > him. If B does > > > nothing, B finds out nothing. Presence servers don't have to > > > provide the > > > function either. > > Got it, but that is entirely in B's implementation - there is > > no point in standardizing how B's server tells B the human > > how to authorize (or indeed that he is asked to authorize). > > If your implementation wanted to use such a mechanism, and > > mine wanted to send me email, they would interoperate. > > In fact, no aspect of interoperability is affected by this > > spec, and thus I claim it is not appropriate. > > I think I've addressed this above. Email or IM content is not > processed by > automata. > > > > > My suggestion, on the other hand, is about interoperability - > > if B wants to let A know how to get authorized, he can > > supply the URL. A's implementation - not knowing anything > > about B's implementation, could assist A to get authorization. > > While there could be other ways, having one standardized way > > is a good thing. > > Whether or not we standardize a way to notify B about the > subscription from > A, I would argue there is no need to tell A how to get authorized. > Ultimately, B has to provide authorization. So, anything that A can do > ultimately results in getting some information to B in order > to allow B to > make a decision. So, why have the presence server for B, for > example, tell A > to send email to B, when the presence server itself can send > the email? > Particularly since you may not want A to know that no > authorization policy > exists for them. > > > > > > > > > 2. why even worry about this? Well, all of the major IM and > > > presence systems > > > do this today. We should at least be able to provide the same > > > application > > > interface thats available, if users and their providers want it. > > Excuse me, all existing IM systems have a way to find out > > who is subscribed to your presence? All existing IM systems > > supply two URLs to approve or deny subscriptions? Funny, > > I didn't think any of them did. Let me fire up AIM. > > Hmmm, doesn't seem to have any controls on authorization, > > doesn't seem to have a way to find out who is looking at your > > presence. You can control who sends you IM. > > Actually, I don't know of ANY existing presence service that has > > the authorization idea, although there are "closed group" > > systems which limit who can do anything. > > On Yahoo messenger, when someone subscribes to me, if I'm > logged in at the > time, I get a screen pop which says "User Joe just asked to > be added to your > buddy list. Click here to approve, click here to reject, click here to > approve and add". If I'm offline, this screen pop arrives > when I next log > in. This tells me that the system provides some way for an > automata to learn > the set of outstanding subscriptions for its user, in order > to provide that > screen pop. > > > > 3. I agree with you that defining authorization policy is > a back-end > > > mechanism, and typically not real time. Thats why I have been > > > arguing that > > > the notification to B about the subscriber contain http URLs > > > that can be > > > used to accept/reject, and those URLs are part of the > > > back-end non-real-time > > > application. They facilitate a screen pop to a slim phone > > > that says "approve > > > or reject?" and thus allows setting of simple policies right > > > away without a > > > browser. > > That may be appropriate for some implementations, but clearly > > not all. However, it doesn't matter because it's entirely in > > one implementation. > > Don't we want interoperability between client applications > and servers? I > thought that was the point - to not need to have a client > written by the > vendor of the server. > > -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 > From jdrosen@dynamicsoft.com Wed Jul 11 17:30:36 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08597 for ; Wed, 11 Jul 2001 17:30:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6BLU2RX006713; Wed, 11 Jul 2001 17:30:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3W6DK8YL>; Wed, 11 Jul 2001 17:30:35 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 11 Jul 2001 17:30:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5519 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: > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, July 11, 2001 8:42 AM > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Jonathan > > We agree that the authorization mechanism is not part of > the spec, so why is notification of request for subscription > part of the spec? In particular, why is there a STANDARD > way that B finds out that A wants to subscribe? That > is entirely within the domain of B's implementation, and > usually we don't standardize such things. We standardize things when an automata and one point needs to process some information sent by an entity at another point. If we want a client application to be able to process the fact that a subscription was made to its user (so that it might, for example, do a screen pop asking for approval), then we need a standard. If we think that this information will never be processed by automata, then we don't need a standard. I think we might need it processed by automata. > > > 1. this bit about letting B know is **NOT** part of the > main presence > > specification whatsoever. All that specification says is "the > > server obtains > > authorization in some fashion, not specified". The mechanism > > that allows B > > to find out who subscribes is separate, and opt-in, not > > opt-out. That is, B > > has to explicitly request to find out who subscribed to > him. If B does > > nothing, B finds out nothing. Presence servers don't have to > > provide the > > function either. > Got it, but that is entirely in B's implementation - there is > no point in standardizing how B's server tells B the human > how to authorize (or indeed that he is asked to authorize). > If your implementation wanted to use such a mechanism, and > mine wanted to send me email, they would interoperate. > In fact, no aspect of interoperability is affected by this > spec, and thus I claim it is not appropriate. I think I've addressed this above. Email or IM content is not processed by automata. > > My suggestion, on the other hand, is about interoperability - > if B wants to let A know how to get authorized, he can > supply the URL. A's implementation - not knowing anything > about B's implementation, could assist A to get authorization. > While there could be other ways, having one standardized way > is a good thing. Whether or not we standardize a way to notify B about the subscription from A, I would argue there is no need to tell A how to get authorized. Ultimately, B has to provide authorization. So, anything that A can do ultimately results in getting some information to B in order to allow B to make a decision. So, why have the presence server for B, for example, tell A to send email to B, when the presence server itself can send the email? Particularly since you may not want A to know that no authorization policy exists for them. > > > > > 2. why even worry about this? Well, all of the major IM and > > presence systems > > do this today. We should at least be able to provide the same > > application > > interface thats available, if users and their providers want it. > Excuse me, all existing IM systems have a way to find out > who is subscribed to your presence? All existing IM systems > supply two URLs to approve or deny subscriptions? Funny, > I didn't think any of them did. Let me fire up AIM. > Hmmm, doesn't seem to have any controls on authorization, > doesn't seem to have a way to find out who is looking at your > presence. You can control who sends you IM. > Actually, I don't know of ANY existing presence service that has > the authorization idea, although there are "closed group" > systems which limit who can do anything. On Yahoo messenger, when someone subscribes to me, if I'm logged in at the time, I get a screen pop which says "User Joe just asked to be added to your buddy list. Click here to approve, click here to reject, click here to approve and add". If I'm offline, this screen pop arrives when I next log in. This tells me that the system provides some way for an automata to learn the set of outstanding subscriptions for its user, in order to provide that screen pop. > > 3. I agree with you that defining authorization policy is a back-end > > mechanism, and typically not real time. Thats why I have been > > arguing that > > the notification to B about the subscriber contain http URLs > > that can be > > used to accept/reject, and those URLs are part of the > > back-end non-real-time > > application. They facilitate a screen pop to a slim phone > > that says "approve > > or reject?" and thus allows setting of simple policies right > > away without a > > browser. > That may be appropriate for some implementations, but clearly > not all. However, it doesn't matter because it's entirely in > one implementation. Don't we want interoperability between client applications and servers? I thought that was the point - to not need to have a client written by the vendor of the server. -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 From jdrosen@dynamicsoft.com Wed Jul 11 17:35:49 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08630 for ; Wed, 11 Jul 2001 17:35:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6BLZCRX006757; Wed, 11 Jul 2001 17:35:12 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3W6DK8Y8>; Wed, 11 Jul 2001 17:35:45 -0400 Message-ID: From: Jonathan Rosenberg To: "'Michael Hammer'" , Jonathan Rosenberg Cc: "'Rosen, Brian'" , Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 11 Jul 2001 17:35:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2710 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: > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, July 11, 2001 10:37 AM > To: Jonathan Rosenberg > Cc: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Jonathan, > > Why is this so hard? It seems there are three separate > processes here: > > A: Authorization - between system and authorizer > B: Subscription - requestor and system > C: Notification - presentity and subscriber Well, the notification is really between the system and the subscriber, but thats a nit. > > C won't happen without B won't complete without A. > Only C should be reveal presence. > > If X subscribes, they get a response saying "your request has been > accepted, you'll know it worked when you start getting notifications." That is what is specified now, yes. > > Variation: If X subscribes and was already authorized, > response says "you > were previously accepted." Says nothing about when that > occurred. Note > this should not be done for rejections, as consecutive pings > by X could > detect when X went from accepted to rejected, indicating > presence at least > momentarily. > > When the authorizer logs in, they accept (authorize) or > reject requests. > > Notifications occur based on authorized subscriptions. > > Have I missed something? Yes. You say: "when the authorizer logs in, they accept (authorize) or reject requests". How does the authorizer know whether there are subscriptions waiting to be authorized? Sure, the system can send the authorizer email, or an IM, but that means there is no way to manage that information on the client side using an automata which queries the user, or applies local policy to generate an authorization. I'm interested in this primarily because that is what systems do today. When I start Yahoo, it tells me who has tried to subscribe, and allows me to accept/reject each of those. Are we willing to say that a tool cannot be written that queries the user for this, that the only way is to send email or IM or something else which is only interpretable by a human? Not that using IM or email is bad; just that we may want to enable an automata to handle the information. -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 From ssaha@lboard.com Wed Jul 11 18:59:00 2001 Received: from exmail.lboard.com (16.node.lboard.com [204.17.219.16] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08883 for ; Wed, 11 Jul 2001 18:59:00 -0400 (EDT) Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Jul 2001 15:58:39 -0700 Message-ID: From: Subir Saha To: "'Jonathan Rosenberg'" , "'Rosen, Brian'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 11 Jul 2001 15:58:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 7232 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: I think what Brain is objecting about putting a human in the authorization loop. However, I think it is not necessarily so. Let us assume the call flown below: A subscribes to B's presence server(PS). The first thing PS does a send a 202 back to A and then a authorization request to B giving some info about A. If B may have an "automata" to authorize A or he may do it interactively. If the PS is waiting on this result then it is problem. However, PS may fire an authorize request and forget and when the authorization is done in B, PS may get back a new message AUTHDONE or something like from B. A PS B |----Sub--->| | |<---202----| | | |-----auth A---->| | |<----200--------| | | | | |<--AuthDone A---| | |------200------>| | | | Now as PS is not waiting on B for an interaction, I don't thing this is an objection. However the question remains how do we authorize - i.e., what are the information needed to make the authorization done. Is it wise to protocolize that? Like if my friend wants my presence, I may be just authorize on looking at his e-mail or sip or any id. However with the case of business colleague, I may need hell lot of info. Now is it possible to standardized such an arbitrary requirement? That is what a valid objection, I see, Brian has. Subir -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, July 11, 2001 2:30 PM To: 'Rosen, Brian' Cc: 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] Another idea for presence authorization > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, July 11, 2001 8:42 AM > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Jonathan > > We agree that the authorization mechanism is not part of > the spec, so why is notification of request for subscription > part of the spec? In particular, why is there a STANDARD > way that B finds out that A wants to subscribe? That > is entirely within the domain of B's implementation, and > usually we don't standardize such things. We standardize things when an automata and one point needs to process some information sent by an entity at another point. If we want a client application to be able to process the fact that a subscription was made to its user (so that it might, for example, do a screen pop asking for approval), then we need a standard. If we think that this information will never be processed by automata, then we don't need a standard. I think we might need it processed by automata. > > > 1. this bit about letting B know is **NOT** part of the > main presence > > specification whatsoever. All that specification says is "the > > server obtains > > authorization in some fashion, not specified". The mechanism > > that allows B > > to find out who subscribes is separate, and opt-in, not > > opt-out. That is, B > > has to explicitly request to find out who subscribed to > him. If B does > > nothing, B finds out nothing. Presence servers don't have to > > provide the > > function either. > Got it, but that is entirely in B's implementation - there is > no point in standardizing how B's server tells B the human > how to authorize (or indeed that he is asked to authorize). > If your implementation wanted to use such a mechanism, and > mine wanted to send me email, they would interoperate. > In fact, no aspect of interoperability is affected by this > spec, and thus I claim it is not appropriate. I think I've addressed this above. Email or IM content is not processed by automata. > > My suggestion, on the other hand, is about interoperability - > if B wants to let A know how to get authorized, he can > supply the URL. A's implementation - not knowing anything > about B's implementation, could assist A to get authorization. > While there could be other ways, having one standardized way > is a good thing. Whether or not we standardize a way to notify B about the subscription from A, I would argue there is no need to tell A how to get authorized. Ultimately, B has to provide authorization. So, anything that A can do ultimately results in getting some information to B in order to allow B to make a decision. So, why have the presence server for B, for example, tell A to send email to B, when the presence server itself can send the email? Particularly since you may not want A to know that no authorization policy exists for them. > > > > > 2. why even worry about this? Well, all of the major IM and > > presence systems > > do this today. We should at least be able to provide the same > > application > > interface thats available, if users and their providers want it. > Excuse me, all existing IM systems have a way to find out > who is subscribed to your presence? All existing IM systems > supply two URLs to approve or deny subscriptions? Funny, > I didn't think any of them did. Let me fire up AIM. > Hmmm, doesn't seem to have any controls on authorization, > doesn't seem to have a way to find out who is looking at your > presence. You can control who sends you IM. > Actually, I don't know of ANY existing presence service that has > the authorization idea, although there are "closed group" > systems which limit who can do anything. On Yahoo messenger, when someone subscribes to me, if I'm logged in at the time, I get a screen pop which says "User Joe just asked to be added to your buddy list. Click here to approve, click here to reject, click here to approve and add". If I'm offline, this screen pop arrives when I next log in. This tells me that the system provides some way for an automata to learn the set of outstanding subscriptions for its user, in order to provide that screen pop. > > 3. I agree with you that defining authorization policy is a back-end > > mechanism, and typically not real time. Thats why I have been > > arguing that > > the notification to B about the subscriber contain http URLs > > that can be > > used to accept/reject, and those URLs are part of the > > back-end non-real-time > > application. They facilitate a screen pop to a slim phone > > that says "approve > > or reject?" and thus allows setting of simple policies right > > away without a > > browser. > That may be appropriate for some implementations, but clearly > not all. However, it doesn't matter because it's entirely in > one implementation. Don't we want interoperability between client applications and servers? I thought that was the point - to not need to have a client written by the vendor of the server. -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 sardana@obsoft.com Thu Jul 12 01:49:51 2001 Received: from obsoft.com (sdsl-208-185-238-35.dsl.sjc.megapath.net [208.185.238.35]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09969 for ; Thu, 12 Jul 2001 01:49:50 -0400 (EDT) Received: from obsoft.com (IDENT:sardana@localhost.localdomain [127.0.0.1]) by obsoft.com (8.9.3/8.9.3) with ESMTP id WAA28845; Wed, 11 Jul 2001 22:53:18 -0700 Message-ID: <3B4D3B4E.9771F776@obsoft.com> Date: Wed, 11 Jul 2001 22:53:18 -0700 From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Subir Saha CC: "'Jonathan Rosenberg'" , "'Rosen, Brian'" , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Another idea for presence authorization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 8413 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: Greetings: Allowing ad-hoc authorization decisions, for subscription, based on proprietary implementations is worse than formalizing them, IMHO. So there needs to be guidelines/mechanisms in place for authorization. Presenting URLs for subscription authorization is one such mechanism that is being proposed by Jonathan. If it leads to formalization in implementations, then it should be protocolized. Otherwise, we'll have what's out there now -- the popular IMs and folks trying to inter-operate them. Bobby Sardana. sardana@obsoft.com Subir Saha wrote: > I think what Brain is objecting about putting a human in the authorization > loop. However, I think it is not necessarily so. Let us assume the call > flown below: > > A subscribes to B's presence server(PS). The first thing PS does a send a > 202 back to A and then a authorization request to B giving some info about > A. If B may have an "automata" to authorize A or he may do it interactively. > If the PS is waiting on this result then it is problem. However, PS may fire > an authorize request and forget and when the authorization is done in B, PS > may get back a new message AUTHDONE or something like from B. > > A PS B > |----Sub--->| | > |<---202----| | > | |-----auth A---->| > | |<----200--------| > | | | > | |<--AuthDone A---| > | |------200------>| > | | | > > Now as PS is not waiting on B for an interaction, I don't thing this is an > objection. However the question remains how do we authorize - i.e., what are > the information needed to make the authorization done. Is it wise to > protocolize that? Like if my friend wants my presence, I may be just > authorize on looking at his e-mail or sip or any id. However with the case > of business colleague, I may need hell lot of info. Now is it possible to > standardized such an arbitrary requirement? That is what a valid objection, > I see, Brian has. > > Subir > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, July 11, 2001 2:30 PM > To: 'Rosen, Brian' > Cc: 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] Another idea for presence authorization > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Wednesday, July 11, 2001 8:42 AM > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Jonathan > > > > We agree that the authorization mechanism is not part of > > the spec, so why is notification of request for subscription > > part of the spec? In particular, why is there a STANDARD > > way that B finds out that A wants to subscribe? That > > is entirely within the domain of B's implementation, and > > usually we don't standardize such things. > > We standardize things when an automata and one point needs to process some > information sent by an entity at another point. If we want a client > application to be able to process the fact that a subscription was made to > its user (so that it might, for example, do a screen pop asking for > approval), then we need a standard. If we think that this information will > never be processed by automata, then we don't need a standard. I think we > might need it processed by automata. > > > > > > 1. this bit about letting B know is **NOT** part of the > > main presence > > > specification whatsoever. All that specification says is "the > > > server obtains > > > authorization in some fashion, not specified". The mechanism > > > that allows B > > > to find out who subscribes is separate, and opt-in, not > > > opt-out. That is, B > > > has to explicitly request to find out who subscribed to > > him. If B does > > > nothing, B finds out nothing. Presence servers don't have to > > > provide the > > > function either. > > Got it, but that is entirely in B's implementation - there is > > no point in standardizing how B's server tells B the human > > how to authorize (or indeed that he is asked to authorize). > > If your implementation wanted to use such a mechanism, and > > mine wanted to send me email, they would interoperate. > > In fact, no aspect of interoperability is affected by this > > spec, and thus I claim it is not appropriate. > > I think I've addressed this above. Email or IM content is not processed by > automata. > > > > > My suggestion, on the other hand, is about interoperability - > > if B wants to let A know how to get authorized, he can > > supply the URL. A's implementation - not knowing anything > > about B's implementation, could assist A to get authorization. > > While there could be other ways, having one standardized way > > is a good thing. > > Whether or not we standardize a way to notify B about the subscription from > A, I would argue there is no need to tell A how to get authorized. > Ultimately, B has to provide authorization. So, anything that A can do > ultimately results in getting some information to B in order to allow B to > make a decision. So, why have the presence server for B, for example, tell A > to send email to B, when the presence server itself can send the email? > Particularly since you may not want A to know that no authorization policy > exists for them. > > > > > > > > > 2. why even worry about this? Well, all of the major IM and > > > presence systems > > > do this today. We should at least be able to provide the same > > > application > > > interface thats available, if users and their providers want it. > > Excuse me, all existing IM systems have a way to find out > > who is subscribed to your presence? All existing IM systems > > supply two URLs to approve or deny subscriptions? Funny, > > I didn't think any of them did. Let me fire up AIM. > > Hmmm, doesn't seem to have any controls on authorization, > > doesn't seem to have a way to find out who is looking at your > > presence. You can control who sends you IM. > > Actually, I don't know of ANY existing presence service that has > > the authorization idea, although there are "closed group" > > systems which limit who can do anything. > > On Yahoo messenger, when someone subscribes to me, if I'm logged in at the > time, I get a screen pop which says "User Joe just asked to be added to your > buddy list. Click here to approve, click here to reject, click here to > approve and add". If I'm offline, this screen pop arrives when I next log > in. This tells me that the system provides some way for an automata to learn > the set of outstanding subscriptions for its user, in order to provide that > screen pop. > > > > 3. I agree with you that defining authorization policy is a back-end > > > mechanism, and typically not real time. Thats why I have been > > > arguing that > > > the notification to B about the subscriber contain http URLs > > > that can be > > > used to accept/reject, and those URLs are part of the > > > back-end non-real-time > > > application. They facilitate a screen pop to a slim phone > > > that says "approve > > > or reject?" and thus allows setting of simple policies right > > > away without a > > > browser. > > That may be appropriate for some implementations, but clearly > > not all. However, it doesn't matter because it's entirely in > > one implementation. > > Don't we want interoperability between client applications and servers? I > thought that was the point - to not need to have a client written by the > vendor of the server. > > -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 Vasilis.Polychronidis@Openwave.com Thu Jul 12 03:01:01 2001 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 DAA10181 for ; Thu, 12 Jul 2001 03:01:00 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712070024.GHHJ24568.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Thu, 12 Jul 2001 02:00:24 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712070024.BTTQ9573.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Thu, 12 Jul 2001 02:00:24 -0500 Message-ID: <3B4D4B21.4D9CFD00@Openwave.com> Date: Thu, 12 Jul 2001 00:00:50 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Robert Sparks , "'simple@mailman.dynamicsoft.com'" , "'sean.olson@ericsson.com'" Subject: Re: [Simple] IM: A session or not References: Content-Type: multipart/alternative; boundary="------------C473E91E197E8083ACFB5E45" Content-Length: 9532 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: --------------C473E91E197E8083ACFB5E45 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan, Thank you for your prompt response. Please see my comments below: BR, Vasilis Polychronidis Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Vasilis Polychronidis > > [mailto:Vasilis.Polychronidis@Openwave.com] > > Sent: Sunday, July 08, 2001 8:40 PM > > To: Jonathan Rosenberg > > Cc: Robert Sparks; 'simple@mailman.dynamicsoft.com'; > > 'sean.olson@ericsson.com' > > Subject: Re: [Simple] IM: A session or not > > > > > > Hi All, > > I think this was the last message on this thread (IM: A > > session or not). > > This was a very interesting discussion. > > Can someone summarize the consensus of the group on this > > important issue? > > I think there was consensus that we would move forward with: > > 1. defining MESSAGE as a sessionless page mechanism I would prefer if this becomes a separate ID (Notification/paging service based on SIP). Notifications/Pages should be described in a more generic framework. (the same way SIP Events are more general than the presence service). In any rate I do not have any strong feelings about this. On another issue I am always hesitant of using signaling infrastructure (SIP proxies) for transporting user messaging. The signaling infrastructure (SIP proxies) has completely different requirements (QOS, reliability, availability, etc.) than your messaging or your transport (RTP, etc.) infrastructure. IMO mixing signaling data (session initiation) with application data is not a very good idea. You do not want the SIP proxies to start dropping INVITE messages (VoIP call set up) because your signaling infrastructure is congested from user notification/pages. SMS which is a huge commercial success was a technical nightmare for the operators for exactly the above mentioned reason (mixing signaling in this case SS7 with messaging data). I hope we will learn from examples like this and will not repeat similar technical mistakes. > > 2. allow for INVITE/BYE to establish an IM session This is an excellent idea. I will list some of the most important (IMO) benefits of doing this (Jonathan mentioned many of them in previous e-mails): 1. Unification of Multimedia sessions (VoIP, Video with the Instant Messaging Service). Control all sessions (IM, Voice, Multimedia) in a unified method using the same signaling protocol. 2. forking actually works 3. you can actually clean up state in end systems which are automata (like an IM conference server, which you cannot build without this!) This is a huge benefit. Multiparty chat sessions is very natural (easy) with SIP. 4. you can avoid sending 5meg MP3 "IMs" over proxies This is very important. Separate signaling from transport. Follow similar architecture as VoIP. Actually by introducing the concept of a chat (IM) server you can solve the NAT issues associated with IM 4. you can reuse alot of the sip tools we have constructed for sessions - transfers, multiparty conferencing, etc. Again you unify the user experience. User is presented with the same features/options regardless the session (IM, Voice, etc.) > > > I think we still have a bit more thinking to do on exactly how the > IM-as-a-session will work. I had proposed including a SIP URL in the SDP, > which will work in many cases, but there are still some record-routing > issues, like the one Robert points out. I don't think those details were yet > ironed out, though. The session description should be flexible enough to allow different message transport protocols as well as peer to peer and client-server (IM server or chat Server) communication models: c = IN IP4 FQDN or IP Address m = message [ "/" MP integer] where: FQDN or IP Address = the address/identifier of expected data source or data relay or data sink port = port number protocol = udp | tcp | http | rtp | sip/udp | sip/tcp sip/udp and sip/tcp should not be used to transport messages over SIP proxies (signaling) IM-identifier = im:user@domain (CPIM IM identifier) MP stands for message profile for example MP 0 may mean CPIM MP 1 may represent some type of XML type message etc. The beauty of this format is that is extensible. Also this approach allow us to separate the signaling addressing from the transport addressing Please lets resolve this issue before the next IETF meeting. > > > -Jonathan R. > --------------C473E91E197E8083ACFB5E45 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan,
Thank you for your prompt response.
Please see my comments below:

BR,

Vasilis Polychronidis

Jonathan Rosenberg wrote:

 

> -----Original Message-----
> From: Vasilis Polychronidis
> [mailto:Vasilis.Polychronidis@Openwave.com]
> Sent: Sunday, July 08, 2001 8:40 PM
> To: Jonathan Rosenberg
> Cc: Robert Sparks; 'simple@mailman.dynamicsoft.com';
> 'sean.olson@ericsson.com'
> Subject: Re: [Simple] IM: A session or not
>
>
> Hi All,
> I think this was the last message on this thread (IM: A
> session or not).
> This was a very interesting discussion.
> Can someone summarize the consensus of the group on this
> important issue?

I think there was consensus that we would move forward with:

1. defining MESSAGE as a sessionless page mechanism

I would prefer if this becomes a separate ID (Notification/paging service based on SIP).
Notifications/Pages should be described in a more generic framework. (the same way SIP Events
are more general than the presence service).
In any rate I do not have any strong feelings about this.
On another issue I am always hesitant of using signaling infrastructure (SIP proxies) for transporting user messaging.
The signaling infrastructure (SIP proxies) has completely different requirements (QOS, reliability, availability, etc.) than
your messaging or your transport (RTP, etc.) infrastructure.
IMO mixing signaling data (session initiation) with application data is not a very good idea.
You do not want the SIP proxies to start dropping INVITE messages (VoIP call set up)
because your signaling infrastructure is congested from user notification/pages.
SMS which is a huge commercial success was a technical nightmare for the operators for exactly
the above mentioned reason (mixing signaling in this case SS7 with messaging data).
I hope we will learn from examples like this and will not repeat similar technical mistakes.
 
2. allow for INVITE/BYE to establish an IM session
This is an excellent idea.
I will list some of the most important (IMO) benefits of doing this (Jonathan mentioned many of them in previous e-mails):
1. Unification of Multimedia sessions (VoIP, Video with the Instant Messaging Service).
Control all sessions (IM, Voice, Multimedia) in a unified method using the same signaling protocol.
2. forking actually works
3. you can actually clean up state in end systems which are
automata (like an IM conference server, which you cannot build without this!)
This is a huge benefit. Multiparty chat sessions is very natural (easy) with SIP.
4. you can avoid sending 5meg MP3 "IMs" over proxies
This is very important. Separate signaling from transport. Follow similar architecture as VoIP.
Actually by introducing the concept of a chat (IM) server you can solve the NAT issues associated with IM
4. you can reuse alot of the sip tools we have constructed for
sessions - transfers, multiparty conferencing, etc.
Again you unify the user experience. User is presented with the same features/options regardless
the session (IM, Voice, etc.)
 

I think we still have a bit more thinking to do on exactly how the
IM-as-a-session will work. I had proposed including a SIP URL in the SDP,
which will work in many cases, but there are still some record-routing
issues, like the one Robert points out. I don't think those details were yet
ironed out, though.

The session description should be flexible enough to allow different message transport protocols as well as
peer to peer and client-server (IM server or chat Server) communication models:

c = IN IP4 FQDN or IP Address
m = message <port> <protocol> [ "/" MP integer] <IM-identifier>

where:
FQDN or IP Address = the address/identifier of expected data source or data relay or data sink
port = port number
protocol = udp | tcp | http | rtp | sip/udp | sip/tcp
    sip/udp and sip/tcp should not be used to transport messages over SIP proxies (signaling)
IM-identifier = im:user@domain (CPIM IM identifier)
MP stands for message profile
for example MP 0 may mean CPIM
MP 1 may represent some type of XML type message
etc.
The beauty of this format is that is extensible.
Also this approach allow us to separate the signaling addressing from the transport addressing

Please lets resolve this issue before the next IETF meeting.

 

-Jonathan R.
 

--------------C473E91E197E8083ACFB5E45-- From Brian.Rosen@marconi.com Thu Jul 12 09:21:58 2001 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 JAA11208 for ; Thu, 12 Jul 2001 09:21:58 -0400 (EDT) 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 JAA22875; Thu, 12 Jul 2001 09:21:54 -0400 (EDT) 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 JAA08884; Thu, 12 Jul 2001 09:21:56 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 12 Jul 2001 09:21:54 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465775@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Bobby Sardana'" , Subir Saha Cc: "'Jonathan Rosenberg'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Another idea for presence authorization Date: Thu, 12 Jul 2001 09:21:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 11434 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: We have a presence server and a presence client. We can standardize the interface between the presence server and the presence client, but we can't standardize the interface between the presence server and the presentity (a human). Actually, of course we could - we could add a new entity, which is a presentity agent, distinct from the presence server and then standardize the interface between the presentity agent and the presence server. I propose that we DON'T do that. If you want the effect of a centralized server with the agent of the presentity distinct from the server, then use a B2BUA where the "presence server" is the only client of the "real" presentity, and the rest of the clients connect to the presence server. Before anyone yelps about privacy, I'll point out that there is NO WAY to prevent anyone from doing this - if you give me authorization to your presence, I can then run a presence server for anyone I like that offers your presence, and there is nothing you can do about it, except unauthorize me. If you run your own version of it, you control the policy of the presence server, and it's the same level of control you ever get to have. We went through all of this in SPATIAL. It's much simpler to keep the basic SIP paradigm of UAC/UAS at the edge, and then get some help with scaling from proxies in the middle then it is to have a different protocol between the presentity agent and the presence server then between the presence server and the watcher agent. If you do it my way, then you are talking about the GUI mechanism between the UAS and the human - not something we standardize. More importantly, authorization is very complex, because it is tied to what the actual presence model is. While you all might be thinking about the simple minded logged on/not logged on model, I have a much richer model, as many folks working on presence do. To authorize, I need to know a fair amount about who you are, and then I will authorize you for some, but possibly not all, of the presence information my server can supply. While I agree that you can do this with a URL in some cases, in my case, that would be insufficient. But mostly, I don't want to open that can of worms at all, at least not now. Brian > -----Original Message----- > From: Bobby Sardana [mailto:sardana@obsoft.com] > Sent: Thursday, July 12, 2001 1:53 AM > To: Subir Saha > Cc: 'Jonathan Rosenberg'; 'Rosen, Brian'; > 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] Another idea for presence authorization > > > Greetings: > > Allowing ad-hoc authorization decisions, for subscription, > based on proprietary > implementations is worse than formalizing them, IMHO. So > there needs to be > guidelines/mechanisms in place for authorization. > > Presenting URLs for subscription authorization is one such > mechanism that is > being proposed by Jonathan. If it leads to formalization in > implementations, > then it should be protocolized. Otherwise, we'll have what's > out there now -- > the popular IMs and folks trying to inter-operate them. > > Bobby Sardana. > sardana@obsoft.com > > Subir Saha wrote: > > > I think what Brain is objecting about putting a human in > the authorization > > loop. However, I think it is not necessarily so. Let us > assume the call > > flown below: > > > > A subscribes to B's presence server(PS). The first thing PS > does a send a > > 202 back to A and then a authorization request to B giving > some info about > > A. If B may have an "automata" to authorize A or he may do > it interactively. > > If the PS is waiting on this result then it is problem. > However, PS may fire > > an authorize request and forget and when the authorization > is done in B, PS > > may get back a new message AUTHDONE or something like from B. > > > > A PS B > > |----Sub--->| | > > |<---202----| | > > | |-----auth A---->| > > | |<----200--------| > > | | | > > | |<--AuthDone A---| > > | |------200------>| > > | | | > > > > Now as PS is not waiting on B for an interaction, I don't > thing this is an > > objection. However the question remains how do we authorize > - i.e., what are > > the information needed to make the authorization done. Is it wise to > > protocolize that? Like if my friend wants my presence, I may be just > > authorize on looking at his e-mail or sip or any id. > However with the case > > of business colleague, I may need hell lot of info. Now is > it possible to > > standardized such an arbitrary requirement? That is what a > valid objection, > > I see, Brian has. > > > > Subir > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Wednesday, July 11, 2001 2:30 PM > > To: 'Rosen, Brian' > > Cc: 'simple@mailman.dynamicsoft.com' > > Subject: RE: [Simple] Another idea for presence authorization > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Wednesday, July 11, 2001 8:42 AM > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > 'adam.roach@ericsson.com'; Ben Campbell > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > Jonathan > > > > > > We agree that the authorization mechanism is not part of > > > the spec, so why is notification of request for subscription > > > part of the spec? In particular, why is there a STANDARD > > > way that B finds out that A wants to subscribe? That > > > is entirely within the domain of B's implementation, and > > > usually we don't standardize such things. > > > > We standardize things when an automata and one point needs > to process some > > information sent by an entity at another point. If we want a client > > application to be able to process the fact that a > subscription was made to > > its user (so that it might, for example, do a screen pop asking for > > approval), then we need a standard. If we think that this > information will > > never be processed by automata, then we don't need a > standard. I think we > > might need it processed by automata. > > > > > > > > > 1. this bit about letting B know is **NOT** part of the > > > main presence > > > > specification whatsoever. All that specification says is "the > > > > server obtains > > > > authorization in some fashion, not specified". The mechanism > > > > that allows B > > > > to find out who subscribes is separate, and opt-in, not > > > > opt-out. That is, B > > > > has to explicitly request to find out who subscribed to > > > him. If B does > > > > nothing, B finds out nothing. Presence servers don't have to > > > > provide the > > > > function either. > > > Got it, but that is entirely in B's implementation - there is > > > no point in standardizing how B's server tells B the human > > > how to authorize (or indeed that he is asked to authorize). > > > If your implementation wanted to use such a mechanism, and > > > mine wanted to send me email, they would interoperate. > > > In fact, no aspect of interoperability is affected by this > > > spec, and thus I claim it is not appropriate. > > > > I think I've addressed this above. Email or IM content is > not processed by > > automata. > > > > > > > > My suggestion, on the other hand, is about interoperability - > > > if B wants to let A know how to get authorized, he can > > > supply the URL. A's implementation - not knowing anything > > > about B's implementation, could assist A to get authorization. > > > While there could be other ways, having one standardized way > > > is a good thing. > > > > Whether or not we standardize a way to notify B about the > subscription from > > A, I would argue there is no need to tell A how to get authorized. > > Ultimately, B has to provide authorization. So, anything > that A can do > > ultimately results in getting some information to B in > order to allow B to > > make a decision. So, why have the presence server for B, > for example, tell A > > to send email to B, when the presence server itself can > send the email? > > Particularly since you may not want A to know that no > authorization policy > > exists for them. > > > > > > > > > > > > > 2. why even worry about this? Well, all of the major IM and > > > > presence systems > > > > do this today. We should at least be able to provide the same > > > > application > > > > interface thats available, if users and their providers want it. > > > Excuse me, all existing IM systems have a way to find out > > > who is subscribed to your presence? All existing IM systems > > > supply two URLs to approve or deny subscriptions? Funny, > > > I didn't think any of them did. Let me fire up AIM. > > > Hmmm, doesn't seem to have any controls on authorization, > > > doesn't seem to have a way to find out who is looking at your > > > presence. You can control who sends you IM. > > > Actually, I don't know of ANY existing presence service that has > > > the authorization idea, although there are "closed group" > > > systems which limit who can do anything. > > > > On Yahoo messenger, when someone subscribes to me, if I'm > logged in at the > > time, I get a screen pop which says "User Joe just asked to > be added to your > > buddy list. Click here to approve, click here to reject, > click here to > > approve and add". If I'm offline, this screen pop arrives > when I next log > > in. This tells me that the system provides some way for an > automata to learn > > the set of outstanding subscriptions for its user, in order > to provide that > > screen pop. > > > > > > 3. I agree with you that defining authorization policy > is a back-end > > > > mechanism, and typically not real time. Thats why I have been > > > > arguing that > > > > the notification to B about the subscriber contain http URLs > > > > that can be > > > > used to accept/reject, and those URLs are part of the > > > > back-end non-real-time > > > > application. They facilitate a screen pop to a slim phone > > > > that says "approve > > > > or reject?" and thus allows setting of simple policies right > > > > away without a > > > > browser. > > > That may be appropriate for some implementations, but clearly > > > not all. However, it doesn't matter because it's entirely in > > > one implementation. > > > > Don't we want interoperability between client applications > and servers? I > > thought that was the point - to not need to have a client > written by the > > vendor of the server. > > > > -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 vijay@saraswat.org Thu Jul 12 09:24:22 2001 Received: from prserv.net (asmtp2.prserv.net [32.97.166.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11233 for ; Thu, 12 Jul 2001 09:24:22 -0400 (EDT) Received: from saraswat.org (107.suab.nyrk.nycenycp.dsl.att.net[12.98.192.107]) by prserv.net (asmtp2) with SMTP id <20010712132421252048ie0de> (Authid: dslvi.dslvis1); Thu, 12 Jul 2001 13:24:21 +0000 Message-ID: <3B4DA5B5.417C92A0@saraswat.org> Date: Thu, 12 Jul 2001 09:27:17 -0400 From: Vijay Saraswat X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vasilis Polychronidis CC: Jonathan Rosenberg , simple@mailman.dynamicsoft.com, sean.olson@ericsson.com Subject: Re: [Simple] IM: A session or not References: <3B4D4B21.4D9CFD00@Openwave.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 6567 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: IM-as-a-session is the right conceptual idea -- when I looked at the SIP proposal a year ago, the lack of support for this was one of the things that stood out (I remarked on this in my evaluation). SIP is for *session initiation* ... it is very natural in this context to think of multiple IM interactions between the same party as constituting a session. (Note that the MSN Messenger architecture explicitly has the notion that even one-on-one IM sessions are sustained through a "Session server".) One significant issue to be thought through is this .... many, many IM interactions (and I am willing to bet the proportion is increasing rather than decreasing as IM sees more business use) are actually still of the kind: I: Are you there? (followed by a long pause) R: Yeah, whats up (long pause) I: Sorry, phone call, am back. R: cool I: ok, so what do you think about [....] In other words, the actual social negotiation of "presence" (availability of *attention*) might take some time. Regardless of the technical advances we might make, I will argue that there will always be a concept of "social presence", hence the need for explicit human negotiation. So this raises the issue of when should a session *actually* be established: when the first message is sent from I(nitiator) to R(esponder), or when the "system" detects that a sequence of messages (how long does the sequence have to be) has been exchanged in some amount of time (how short does that have to be)? Some other issues to be dealt with: -- determine when a session times out ..most IM session simply get abandoned .. users dont explicitly indicate that they are leaving them. (e.g., the phone call phenomenon alluded to above.) -- figure out whether multi-party chat sessions are/need to be different from two-party IM sessions BTW, I dont think the 5meg MP3 IM issue is realistic. All extant IM systems impose a limit on the size of an IM entering the system. Clients typically drop IMs exceeding this limit. Vasilis Polychronidis wrote: > Hi Jonathan, > Thank you for your prompt response. > Please see my comments below: > > BR, > > Vasilis Polychronidis > > Jonathan Rosenberg wrote: > >> >> >> > -----Original Message----- >> > From: Vasilis Polychronidis >> > [mailto:Vasilis.Polychronidis@Openwave.com] >> > Sent: Sunday, July 08, 2001 8:40 PM >> > To: Jonathan Rosenberg >> > Cc: Robert Sparks; 'simple@mailman.dynamicsoft.com'; >> > 'sean.olson@ericsson.com' >> > Subject: Re: [Simple] IM: A session or not >> > >> > >> > Hi All, >> > I think this was the last message on this thread (IM: A >> > session or not). >> > This was a very interesting discussion. >> > Can someone summarize the consensus of the group on this >> > important issue? >> >> I think there was consensus that we would move forward with: >> >> 1. defining MESSAGE as a sessionless page mechanism > > I would prefer if this becomes a separate ID (Notification/paging > service based on SIP). > Notifications/Pages should be described in a more generic framework. > (the same way SIP Events > are more general than the presence service). > In any rate I do not have any strong feelings about this. > On another issue I am always hesitant of using signaling > infrastructure (SIP proxies) for transporting user messaging. > The signaling infrastructure (SIP proxies) has completely different > requirements (QOS, reliability, availability, etc.) than > your messaging or your transport (RTP, etc.) infrastructure. > IMO mixing signaling data (session initiation) with application data > is not a very good idea. > You do not want the SIP proxies to start dropping INVITE messages > (VoIP call set up) > because your signaling infrastructure is congested from user > notification/pages. > SMS which is a huge commercial success was a technical nightmare for > the operators for exactly > the above mentioned reason (mixing signaling in this case SS7 with > messaging data). > I hope we will learn from examples like this and will not repeat > similar technical mistakes. > >> >> 2. allow for INVITE/BYE to establish an IM session > > This is an excellent idea. > I will list some of the most important (IMO) benefits of doing this > (Jonathan mentioned many of them in previous e-mails): > 1. Unification of Multimedia sessions (VoIP, Video with the Instant > Messaging Service). > Control all sessions (IM, Voice, Multimedia) in a unified method using > the same signaling protocol. > 2. forking actually works > 3. you can actually clean up state in end systems which are > automata (like an IM conference server, which you cannot build without > this!) > This is a huge benefit. Multiparty chat sessions is very natural > (easy) with SIP. > 4. you can avoid sending 5meg MP3 "IMs" over proxies > This is very important. Separate signaling from transport. Follow > similar architecture as VoIP. > Actually by introducing the concept of a chat (IM) server you can > solve the NAT issues associated with IM > 4. you can reuse alot of the sip tools we have constructed for > sessions - transfers, multiparty conferencing, etc. > Again you unify the user experience. User is presented with the same > features/options regardless > the session (IM, Voice, etc.) > >> >> >> I think we still have a bit more thinking to do on exactly how the >> IM-as-a-session will work. I had proposed including a SIP URL in the >> SDP, >> which will work in many cases, but there are still some >> record-routing >> issues, like the one Robert points out. I don't think those details >> were yet >> ironed out, though. > > The session description should be flexible enough to allow different > message transport protocols as well as > peer to peer and client-server (IM server or chat Server) > communication models: > > c = IN IP4 FQDN or IP Address > m = message [ "/" MP integer] > > where: > FQDN or IP Address = the address/identifier of expected data source or > data relay or data sink > port = port number > protocol = udp | tcp | http | rtp | sip/udp | sip/tcp > sip/udp and sip/tcp should not be used to transport messages over > SIP proxies (signaling) > IM-identifier = im:user@domain (CPIM IM identifier) > MP stands for message profile > for example MP 0 may mean CPIM > MP 1 may represent some type of XML type message > etc. > The beauty of this format is that is extensible. > Also this approach allow us to separate the signaling addressing from > the transport addressing > > Please lets resolve this issue before the next IETF meeting. > >> >> >> -Jonathan R. >> > From Vasilis.Polychronidis@Openwave.com Thu Jul 12 13:58:37 2001 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 NAA12040 for ; Thu, 12 Jul 2001 13:58:35 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712175805.MJPE24568.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Thu, 12 Jul 2001 12:58:05 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712175804.CLNX9573.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Thu, 12 Jul 2001 12:58:04 -0500 Message-ID: <3B4DE542.2EFC718D@Openwave.com> Date: Thu, 12 Jul 2001 10:58:27 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Saraswat CC: Jonathan Rosenberg , simple@mailman.dynamicsoft.com, sean.olson@ericsson.com Subject: Re: [Simple] IM: A session or not References: <3B4D4B21.4D9CFD00@Openwave.com> <3B4DA5B5.417C92A0@saraswat.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 9954 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: Hi Vijay, Very good comments/questions. Please see my comments below: BR, Vasilis Polychronidis Vijay Saraswat wrote: > IM-as-a-session is the right conceptual idea -- when I looked at the SIP > proposal a year ago, the lack of support for this was one of the things > that stood out (I remarked on this in my evaluation). SIP is for > *session initiation* ... it is very natural in this context to think of > multiple IM interactions between the same party as constituting a > session. (Note that the MSN Messenger architecture explicitly has the > notion that even one-on-one IM sessions are sustained through a "Session > server".) Exactly. This architecture makes a lot of sense and solves many potential problems: 1. NAT issues 2. Universal access issues (mobile, PDA, PC, etc.) 3. Consistency and synchronization issues 4. Authorization/Authentication 5. "Mobility" of buddy lists 6. Security > > > One significant issue to be thought through is this .... many, many IM > interactions (and I am willing to bet the proportion is increasing > rather than decreasing as IM sees more business use) are actually still > of the kind: > > I: Are you there? > (followed by a long pause) > R: Yeah, whats up > (long pause) > I: Sorry, phone call, am back. > R: cool > I: ok, so what do you think about [....] > > In other words, the actual social negotiation of "presence" > (availability of *attention*) might take some time. True. This is a valid (maybe frequent) use case. But the user behavior is constraint and shaped by current IM system implementations. For example in some IM systems the recipient is first alerted of ("Vijay wants to chat with you do you accept?") about the IM session which starts only after explicit acceptance of the invitation by the recipient. Of course you can automate this and start the IM session without explicit answer from the called party. This is an implementation issue and should be decided by the vendor and the service provider. The standard should be flexible to allow for the majority of the use cases (which I think the IM session model does). Then this will allow the IM vendors (Server and Client) and the service providers to differentiate from each other and the best ones (more features, scalable, etc.) will win. We should not try to predict user behavior the market will do this for us. > Regardless of the > technical advances we might make, I will argue that there will always be > a concept of "social presence", hence the need for explicit human > negotiation. So this raises the issue of when should a session > *actually* be established: when the first message is sent from > I(nitiator) to R(esponder), Well here are some of my thoughts on the session initiation issue: When you want to start an IM session you are basically ringing your called party. It is true that the duration of the conceptual ringing may take a long time but the beauty of SIP is that it allows for such a behavior. So coming back to your specific issue: I: sends an INVITE message the receiving IM User Agent alerts the user by displaying: "Vijay wants to chat with you do you accept?" If responder accepts: R: sends an ACK bi-directional transport is established via the IM Server (Client-Server model) or directly between the two users (Peer to Peer model). Of course the above are just initial thoughts on this issue I agree with you that someone needs to work on the SIMPLE ID where all the use cases are very carefully though out. > or when the "system" detects that a sequence > of messages (how long does the sequence have to be) has been exchanged > in some amount of time (how short does that have to be)? I do not support this type of solution. It is more complicated and I do not see the additional value of it. > > > Some other issues to be dealt with: > -- determine when a session times out ..most IM session simply get > abandoned .. users dont explicitly indicate that they are leaving them. > (e.g., the phone call phenomenon alluded to above.) Well that should be easy you have a configurable timer. If session is inactive for a long time send BYE messages. > > -- figure out whether multi-party chat sessions are/need to be different > from two-party IM sessions Technically makes sense to unify multiparty and two party chat sessions. I have though about this and I do not see any compelling technical reason why they should be different. > > > BTW, I dont think the 5meg MP3 IM issue is realistic. It is not the issue of individual messages that maybe very big but IMO the overall volume of IM (user) message traffic vs. signaling (call/seesion set up messages). To my understanding certain IESG members have an issue of transporting "large" user data over the signaling infrastructure (SIP proxies). IMO "large" refers to the overall user data volume. > All extant IM > systems impose a limit on the size of an IM entering the system. Clients > typically drop IMs exceeding this limit. Resolving the above mentioned issues IMO is very critical to the success of SIMPLE and I would prefer if we can accomplish this before the next IETF meeting. > > > Vasilis Polychronidis wrote: > > > Hi Jonathan, > > Thank you for your prompt response. > > Please see my comments below: > > > > BR, > > > > Vasilis Polychronidis > > > > Jonathan Rosenberg wrote: > > > >> > >> > >> > -----Original Message----- > >> > From: Vasilis Polychronidis > >> > [mailto:Vasilis.Polychronidis@Openwave.com] > >> > Sent: Sunday, July 08, 2001 8:40 PM > >> > To: Jonathan Rosenberg > >> > Cc: Robert Sparks; 'simple@mailman.dynamicsoft.com'; > >> > 'sean.olson@ericsson.com' > >> > Subject: Re: [Simple] IM: A session or not > >> > > >> > > >> > Hi All, > >> > I think this was the last message on this thread (IM: A > >> > session or not). > >> > This was a very interesting discussion. > >> > Can someone summarize the consensus of the group on this > >> > important issue? > >> > >> I think there was consensus that we would move forward with: > >> > >> 1. defining MESSAGE as a sessionless page mechanism > > > > I would prefer if this becomes a separate ID (Notification/paging > > service based on SIP). > > Notifications/Pages should be described in a more generic framework. > > (the same way SIP Events > > are more general than the presence service). > > In any rate I do not have any strong feelings about this. > > On another issue I am always hesitant of using signaling > > infrastructure (SIP proxies) for transporting user messaging. > > The signaling infrastructure (SIP proxies) has completely different > > requirements (QOS, reliability, availability, etc.) than > > your messaging or your transport (RTP, etc.) infrastructure. > > IMO mixing signaling data (session initiation) with application data > > is not a very good idea. > > You do not want the SIP proxies to start dropping INVITE messages > > (VoIP call set up) > > because your signaling infrastructure is congested from user > > notification/pages. > > SMS which is a huge commercial success was a technical nightmare for > > the operators for exactly > > the above mentioned reason (mixing signaling in this case SS7 with > > messaging data). > > I hope we will learn from examples like this and will not repeat > > similar technical mistakes. > > > >> > >> 2. allow for INVITE/BYE to establish an IM session > > > > This is an excellent idea. > > I will list some of the most important (IMO) benefits of doing this > > (Jonathan mentioned many of them in previous e-mails): > > 1. Unification of Multimedia sessions (VoIP, Video with the Instant > > Messaging Service). > > Control all sessions (IM, Voice, Multimedia) in a unified method using > > the same signaling protocol. > > 2. forking actually works > > 3. you can actually clean up state in end systems which are > > automata (like an IM conference server, which you cannot build without > > this!) > > This is a huge benefit. Multiparty chat sessions is very natural > > (easy) with SIP. > > 4. you can avoid sending 5meg MP3 "IMs" over proxies > > This is very important. Separate signaling from transport. Follow > > similar architecture as VoIP. > > Actually by introducing the concept of a chat (IM) server you can > > solve the NAT issues associated with IM > > 4. you can reuse alot of the sip tools we have constructed for > > sessions - transfers, multiparty conferencing, etc. > > Again you unify the user experience. User is presented with the same > > features/options regardless > > the session (IM, Voice, etc.) > > > >> > >> > >> I think we still have a bit more thinking to do on exactly how the > >> IM-as-a-session will work. I had proposed including a SIP URL in the > >> SDP, > >> which will work in many cases, but there are still some > >> record-routing > >> issues, like the one Robert points out. I don't think those details > >> were yet > >> ironed out, though. > > > > The session description should be flexible enough to allow different > > message transport protocols as well as > > peer to peer and client-server (IM server or chat Server) > > communication models: > > > > c = IN IP4 FQDN or IP Address > > m = message [ "/" MP integer] > > > > where: > > FQDN or IP Address = the address/identifier of expected data source or > > data relay or data sink > > port = port number > > protocol = udp | tcp | http | rtp | sip/udp | sip/tcp > > sip/udp and sip/tcp should not be used to transport messages over > > SIP proxies (signaling) > > IM-identifier = im:user@domain (CPIM IM identifier) > > MP stands for message profile > > for example MP 0 may mean CPIM > > MP 1 may represent some type of XML type message > > etc. > > The beauty of this format is that is extensible. > > Also this approach allow us to separate the signaling addressing from > > the transport addressing > > > > Please lets resolve this issue before the next IETF meeting. > > > >> > >> > >> -Jonathan R. > >> > > From pkyzivat@cisco.com Thu Jul 12 16:27:22 2001 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 QAA12543 for ; Thu, 12 Jul 2001 16:27:22 -0400 (EDT) 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 f6CKPWT00914; Thu, 12 Jul 2001 16:25:38 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-146.cisco.com [161.44.241.146]) by cannon.cisco.com (Mirapoint) with ESMTP id ADR00081 (AUTH pkyzivat); Thu, 12 Jul 2001 16:26:54 -0400 (EDT) Message-ID: <3B4E06ED.710F24AB@cisco.com> Date: Thu, 12 Jul 2001 16:22:05 -0400 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: Vasilis Polychronidis CC: Vijay Saraswat , Jonathan Rosenberg , simple@mailman.dynamicsoft.com, sean.olson@ericsson.com Subject: Re: [Simple] IM: A session or not References: <3B4D4B21.4D9CFD00@Openwave.com> <3B4DA5B5.417C92A0@saraswat.org> <3B4DE542.2EFC718D@Openwave.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 849 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: Vasilis Polychronidis wrote: ... > > -- figure out whether multi-party chat sessions are/need to be different > > from two-party IM sessions > > Technically makes sense to unify multiparty and two party chat sessions. > I have though about this and I do not see any compelling technical reason > why they should be different. Depends on what you mean by them being different. For instance, the same protocol could be used in both cases but there might be an extra party (a conference server) present for some multiparty chat sessions. It would be nice if a two party chat didn't require a server. It would also be nice for both parties to agree on the message ordering. Always requiring a server in the middle is one way of agreeing on an ordering of messages, but there are other ways that don't require a server. Paul Kyzivat Cisco Systems From Vasilis.Polychronidis@Openwave.com Thu Jul 12 18:01:17 2001 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 SAA12817 for ; Thu, 12 Jul 2001 18:01:17 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712220047.PFXO24568.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Thu, 12 Jul 2001 17:00:47 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712220048.CVKM9573.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Thu, 12 Jul 2001 17:00:48 -0500 Message-ID: <3B4E1E27.A2320D08@Openwave.com> Date: Thu, 12 Jul 2001 15:01:12 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Vijay Saraswat , Jonathan Rosenberg , simple@mailman.dynamicsoft.com, sean.olson@ericsson.com Subject: Re: [Simple] IM: A session or not References: <3B4D4B21.4D9CFD00@Openwave.com> <3B4DA5B5.417C92A0@saraswat.org> <3B4DE542.2EFC718D@Openwave.com> <3B4E06ED.710F24AB@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1336 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: Hi Paul, Please see below: BR, Vasilis Polychronidis Paul Kyzivat wrote: > Vasilis Polychronidis wrote: > ... > > > -- figure out whether multi-party chat sessions are/need to be different > > > from two-party IM sessions > > > > Technically makes sense to unify multiparty and two party chat sessions. > > I have though about this and I do not see any compelling technical reason > > why they should be different. > > Depends on what you mean by them being different. > > For instance, the same protocol could be used in both cases but there > might be an extra party (a conference server) present for some > multiparty chat sessions. > > It would be nice if a two party chat didn't require a server. It would > also be nice for both parties to agree on the message ordering. Always > requiring a server in the middle is one way of agreeing on an ordering > of messages, but there are other ways that don't require a server. Very true. In my previous Emails I mentioned 2 type of models: 1. Peer to Peer (I think this is the one you prefer) 2. Client-Server model (BTW most of the Service providers prefer this model) My suggestion is for the protocol to be flexible enough that accommodates both cases. I think SIP gives you this flexibility and fits perfectly both models. > > > Paul Kyzivat > Cisco Systems From Vasilis.Polychronidis@Openwave.com Thu Jul 12 18:01:40 2001 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 SAA12822 for ; Thu, 12 Jul 2001 18:01:39 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712220110.PFYS24568.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Thu, 12 Jul 2001 17:01:10 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712220110.CVKW9573.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Thu, 12 Jul 2001 17:01:10 -0500 Message-ID: <3B4E1E3D.1B61B6BE@Openwave.com> Date: Thu, 12 Jul 2001 15:01:34 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Vijay Saraswat , Jonathan Rosenberg , simple@mailman.dynamicsoft.com, sean.olson@ericsson.com Subject: Re: [Simple] IM: A session or not References: <3B4D4B21.4D9CFD00@Openwave.com> <3B4DA5B5.417C92A0@saraswat.org> <3B4DE542.2EFC718D@Openwave.com> <3B4E06ED.710F24AB@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1347 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: Hi Paul, Please see below: BR, Vasilis Polychronidis Paul Kyzivat wrote: > Vasilis Polychronidis wrote: > ... > > > -- figure out whether multi-party chat sessions are/need to be different > > > from two-party IM sessions > > > > Technically makes sense to unify multiparty and two party chat sessions. > > I have though about this and I do not see any compelling technical reason > > why they should be different. > > Depends on what you mean by them being different. > > For instance, the same protocol could be used in both cases but there > might be an extra party (a conference server) present for some > multiparty chat sessions. > > It would be nice if a two party chat didn't require a server. It would > also be nice for both parties to agree on the message ordering. Always > requiring a server in the middle is one way of agreeing on an ordering > of messages, but there are other ways that don't require a server. Very true. In my previous Emails I mentioned 2 type of models: 1. Peer to Peer (I think this is the one you prefer) 2. Client-Server model (BTW most of the Service providers prefer this model) My suggestion is for the IM SIMPLE protocol to be flexible enough that accommodates both cases. I think SIP gives you this flexibility and fits perfectly both models. > > > Paul Kyzivat > Cisco Systems From Vasilis.Polychronidis@Openwave.com Thu Jul 12 18:37:50 2001 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 SAA12966 for ; Thu, 12 Jul 2001 18:37:49 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712223720.PQME24568.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Thu, 12 Jul 2001 17:37:20 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010712223720.CWRY9573.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Thu, 12 Jul 2001 17:37:20 -0500 Message-ID: <3B4E26B2.176B6AD1@Openwave.com> Date: Thu, 12 Jul 2001 15:37:40 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , "'Rosen, Brian'" CC: "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 9671 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: Hi Brian, Looking through this issue I tend to agree with Jonathan's proposal. It is really important that the method described by Jonathan (Subscribing to your watcher info) is optional. As Jonathan said B has to explicitly request it (subscribe to his watcher info). In addition we should not mandate the Presence Server to accept "watcher type": subscriptions. So the proposed feature is an optional one. Is this acceptable to you Brian? I also agree with the use of URLs for accepting/rejecting a subscription. BR, Vasilis Polychronidis Jonathan Rosenberg wrote: > Brian, > > Now I understand what you are saying. I want there to be a way for B to find > out when someone subscribes to him, so he can, if desired, provide > authorization. You don't want to ever tell B when someone subscribes; > rather, you tell A that they should visit some web page, and maybe that > allows them to send email to B asking for authorization. > > So, let me make a few comments in response: > > 1. this bit about letting B know is **NOT** part of the main presence > specification whatsoever. All that specification says is "the server obtains > authorization in some fashion, not specified". The mechanism that allows B > to find out who subscribes is separate, and opt-in, not opt-out. That is, B > has to explicitly request to find out who subscribed to him. If B does > nothing, B finds out nothing. Presence servers don't have to provide the > function either. > > 2. why even worry about this? Well, all of the major IM and presence systems > do this today. We should at least be able to provide the same application > interface thats available, if users and their providers want it. > > 3. I agree with you that defining authorization policy is a back-end > mechanism, and typically not real time. Thats why I have been arguing that > the notification to B about the subscriber contain http URLs that can be > used to accept/reject, and those URLs are part of the back-end non-real-time > application. They facilitate a screen pop to a slim phone that says "approve > or reject?" and thus allows setting of simple policies right away without a > browser. > > The problem that has been observed with your alternate approach, of telling > A about a URL, is that this allows A to learn whether they have been > approved or rejected. Paul argues that this knowledge can be learned anyway, > by sending an INVITE and seeing whether the call is accepted or rejected. > Not necessarily; I can set up a service to achieve the same effect for > voice. If someone calls me, and I don't want to talk to them, instead of > them getting a "600 I hate you" response, the server can simply let the > phone ring indefinitely, so that the caller can't tell whether I'm not > there, or whether they've been rejected. > > -Jonathan R. > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Tuesday, July 10, 2001 6:18 PM > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Yes, I understand what you are proposing; I think it > > is not appropriate to confuse the concept of > > authorization (will I allow you to subscribe) from > > the actual subscription. You want to do that - you > > want the very first action to be a subscribe. > > If the server for B can immediately confirm a new > > authorization, because there is some policy in place > > that lets it do so, you propose to let that subscription > > succeed. You want to talk about what happens when > > it fails. > > > > I want to completely remove authorization from the protocol; > > Subscriptions are then only how you connect to the > > presentity's server. It succeeds if you are authorized, > > fails if you aren't (also fails for other reasons). > > I see no win at all to have the protocol deal with > > authorization. > > > > So, with that in mind, let's look at what you propose: > > > > > This is not right. The party that approves or denies the > > > subscription is NOT > > > the party that has subscribed. > > We all agree, B is the approver. B's server has the authorization. > > A subscribes. It succeeds only if B has given approval. > > > > > > > > Here is the scenario. A subsciber, A, subscribes to B. For > > > any subscription > > > to B to be approved, B has to have given authorization for > > > it. However, > > > there is currently no authorization policy specified by B > > > about whether A > > > can subscribe. So, when A's subscription is received by the > > server, a > > > response is generated, but the subscription is not activated. > > I claim if B has no authorization for A, then A's subscription > > request is denied, and that is the end of the story. > > So I agree you get a response, and that is fail, with > > a referral (URL). > > > > If A wants to get approval, he might consult the URL to find > > a web page that might allow him to be authorized. > > > > >Now, the > > > problem is that the server needs to know whether B approves this > > > subscription. It might just wait, hoping that someday, B sets > > > a policy for > > > user A. However, that doesn't work well. What you want is > > > some way to prod > > > B, and say to him, "hey, A tried to subscribe, please set a > > > policy for A". > > > Then, A can go to some web page, or whatver the backend > > > policy mechanism is, > > > and set up policy. > > Wrong end. You don't want B to take action just because > > A tried to subscribe. Great opportunity to drive B nuts. > > What you want to do is tell A how to get authorized. > > A is the one who wants to get authorized, and we can tell > > him how to do it. There is no win in telling B how to > > run his own authorization mechanism. Mostly, there is > > no win in prodding B based on a subscription attempt for A > > when A isn't even authorized. > > > > Importantly, the subscription request failed. > > If B's server eventually gets some authorization info, > > it has nothing to do with it but wait until A tries > > to subscribe again. > > > > > > > > So, to provide this "prodding" capability, we've agreed to > > > use a new event > > > package, called watcherinfo. The idea is that B can subscribe > > > to his own set > > > of watchers, so that when it changes (for example, when A > > > subscribes), B > > > gets notified. B can then go to the web page and upload approval. > > This seems wacky to me. Why should the protocol prod B? > > Why should the protocol do anything to support authorization - > > that is a non-real-time issue. Sending B an email may be a more > > appropriate thing to do, but that should be because A asks for > > authorization. The question is, how does A do that? The point > > is that since it's B's decision, B may need arbitrary information > > from A before he will authorize. Therefore, A needs to use B's > > authorization mechanism. You can't make A's user interface > > know how to give B what he needs to authorize. A web page that > > B creates is at least one way to do that. > > > > >The > > > additional thing we are debating, is whether there should > > be an actual > > > protocol mechanism for conveying that approval/rejection to > > > the server. I > > > have proposed that the NOTIFY that gets sent to B when A > > > subscribes have two > > > URLs specified by the server, one which approves the > > > subscription from A, > > > and one which rejects. Others have proposed that we specify a > > > protocol for B > > > to upload approval in a presence document. Others want to specify > > > SIP/SOAP/WSDL for this. > > Repeating myself, there is no point in having protocol support > > for human-in-the-loop messaging. While this might be something > > that is worth specifying so that B's agent can talk to B's > > server, I suspect that at least for now, we can safely leave this > > out of the spec because it has nothing to do with A and B. > > You are talking about how B the human interacts with B's server; > > not something I think is worth standardizing. > > > > > > > > All of this is different from what A sees when A's > > > subscription to B is > > > rejected, approved, or marked as "pending" because there is > > > no policy. We > > > have already agreed some time back that in all cases, the > > subscription > > > request is immediately responded to with a 202 and a NOTIFY > > > with the status. > > > If the subscription was accepted, the status is correct. If > > > the subscription > > > failed, or was marked as pending, the NOTIFY contains > > > syntactically correct > > > but invalid data. This way, the subscriber can't know what > > > happened to their > > > subscription. > > I think we are in agreement here. A doesn't get to know if > > he is authorized or not, subscription just fails. > > > > In particular, when B finally does authorize A, A has to > > "just know" to try subscribing again; we don't help him. > > > > It's always possible that the authorization mechanism tells > > A, say by email. > > > > Brian > > > > > > > --- > 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 sardana@obsoft.com Fri Jul 13 01:59:03 2001 Received: from obsoft.com (sdsl-208-185-238-35.dsl.sjc.megapath.net [208.185.238.35]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14100 for ; Fri, 13 Jul 2001 01:59:02 -0400 (EDT) Received: from obsoft.com (IDENT:sardana@localhost.localdomain [127.0.0.1]) by obsoft.com (8.9.3/8.9.3) with ESMTP id XAA29991; Thu, 12 Jul 2001 23:02:39 -0700 Message-ID: <3B4E8EFF.D3638A25@obsoft.com> Date: Thu, 12 Jul 2001 23:02:39 -0700 From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Jonathan Rosenberg'" , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Another idea for presence authorization References: <4FBEA8857476D311A03300204840E1CF04465775@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 12428 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: Greetings Brian: The interface we talk about is the presentation of a URL -- that can result in a specific action upon invocation. How is this URL presented to the presentity is *implementation dependent* but the presentation of the URL should be mandated. Bobby Sardana. sardana@obsoft.com "Rosen, Brian" wrote: > We have a presence server and a presence client. > We can standardize the interface between the presence > server and the presence client, but we can't standardize > the interface between the presence server and the presentity > (a human). > > Actually, of course we could - we could add a new entity, > which is a presentity agent, distinct from the presence > server and then standardize the interface between the > presentity agent and the presence server. I propose that > we DON'T do that. If you want the effect of a centralized > server with the agent of the presentity distinct from the > server, then use a B2BUA where the "presence server" is > the only client of the "real" presentity, and the > rest of the clients connect to the presence server. > > Before anyone yelps about privacy, I'll point out that > there is NO WAY to prevent anyone from doing this - if > you give me authorization to your presence, I can then > run a presence server for anyone I like that offers > your presence, and there is nothing you can do about it, > except unauthorize me. If you run your own version of it, > you control the policy of the presence server, and it's > the same level of control you ever get to have. > > We went through all of this in SPATIAL. It's much simpler > to keep the basic SIP paradigm of UAC/UAS at the edge, > and then get some help with scaling from proxies in the > middle then it is to have a different protocol between the > presentity agent and the presence server then between > the presence server and the watcher agent. > > If you do it my way, then you are talking about the GUI > mechanism between the UAS and the human - not something > we standardize. More importantly, authorization is > very complex, because it is tied to what the actual > presence model is. While you all might be thinking about > the simple minded logged on/not logged on model, I have > a much richer model, as many folks working on presence do. > To authorize, I need to know a fair amount about who you > are, and then I will authorize you for some, but possibly > not all, of the presence information my server can supply. > While I agree that you can do this with a URL in some > cases, in my case, that would be insufficient. > > But mostly, I don't want to open that can of worms at all, > at least not now. > > Brian > > > -----Original Message----- > > From: Bobby Sardana [mailto:sardana@obsoft.com] > > Sent: Thursday, July 12, 2001 1:53 AM > > To: Subir Saha > > Cc: 'Jonathan Rosenberg'; 'Rosen, Brian'; > > 'simple@mailman.dynamicsoft.com' > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > Greetings: > > > > Allowing ad-hoc authorization decisions, for subscription, > > based on proprietary > > implementations is worse than formalizing them, IMHO. So > > there needs to be > > guidelines/mechanisms in place for authorization. > > > > Presenting URLs for subscription authorization is one such > > mechanism that is > > being proposed by Jonathan. If it leads to formalization in > > implementations, > > then it should be protocolized. Otherwise, we'll have what's > > out there now -- > > the popular IMs and folks trying to inter-operate them. > > > > Bobby Sardana. > > sardana@obsoft.com > > > > Subir Saha wrote: > > > > > I think what Brain is objecting about putting a human in > > the authorization > > > loop. However, I think it is not necessarily so. Let us > > assume the call > > > flown below: > > > > > > A subscribes to B's presence server(PS). The first thing PS > > does a send a > > > 202 back to A and then a authorization request to B giving > > some info about > > > A. If B may have an "automata" to authorize A or he may do > > it interactively. > > > If the PS is waiting on this result then it is problem. > > However, PS may fire > > > an authorize request and forget and when the authorization > > is done in B, PS > > > may get back a new message AUTHDONE or something like from B. > > > > > > A PS B > > > |----Sub--->| | > > > |<---202----| | > > > | |-----auth A---->| > > > | |<----200--------| > > > | | | > > > | |<--AuthDone A---| > > > | |------200------>| > > > | | | > > > > > > Now as PS is not waiting on B for an interaction, I don't > > thing this is an > > > objection. However the question remains how do we authorize > > - i.e., what are > > > the information needed to make the authorization done. Is it wise to > > > protocolize that? Like if my friend wants my presence, I may be just > > > authorize on looking at his e-mail or sip or any id. > > However with the case > > > of business colleague, I may need hell lot of info. Now is > > it possible to > > > standardized such an arbitrary requirement? That is what a > > valid objection, > > > I see, Brian has. > > > > > > Subir > > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Wednesday, July 11, 2001 2:30 PM > > > To: 'Rosen, Brian' > > > Cc: 'simple@mailman.dynamicsoft.com' > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Wednesday, July 11, 2001 8:42 AM > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > Cc: simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > Jonathan > > > > > > > > We agree that the authorization mechanism is not part of > > > > the spec, so why is notification of request for subscription > > > > part of the spec? In particular, why is there a STANDARD > > > > way that B finds out that A wants to subscribe? That > > > > is entirely within the domain of B's implementation, and > > > > usually we don't standardize such things. > > > > > > We standardize things when an automata and one point needs > > to process some > > > information sent by an entity at another point. If we want a client > > > application to be able to process the fact that a > > subscription was made to > > > its user (so that it might, for example, do a screen pop asking for > > > approval), then we need a standard. If we think that this > > information will > > > never be processed by automata, then we don't need a > > standard. I think we > > > might need it processed by automata. > > > > > > > > > > > > 1. this bit about letting B know is **NOT** part of the > > > > main presence > > > > > specification whatsoever. All that specification says is "the > > > > > server obtains > > > > > authorization in some fashion, not specified". The mechanism > > > > > that allows B > > > > > to find out who subscribes is separate, and opt-in, not > > > > > opt-out. That is, B > > > > > has to explicitly request to find out who subscribed to > > > > him. If B does > > > > > nothing, B finds out nothing. Presence servers don't have to > > > > > provide the > > > > > function either. > > > > Got it, but that is entirely in B's implementation - there is > > > > no point in standardizing how B's server tells B the human > > > > how to authorize (or indeed that he is asked to authorize). > > > > If your implementation wanted to use such a mechanism, and > > > > mine wanted to send me email, they would interoperate. > > > > In fact, no aspect of interoperability is affected by this > > > > spec, and thus I claim it is not appropriate. > > > > > > I think I've addressed this above. Email or IM content is > > not processed by > > > automata. > > > > > > > > > > > My suggestion, on the other hand, is about interoperability - > > > > if B wants to let A know how to get authorized, he can > > > > supply the URL. A's implementation - not knowing anything > > > > about B's implementation, could assist A to get authorization. > > > > While there could be other ways, having one standardized way > > > > is a good thing. > > > > > > Whether or not we standardize a way to notify B about the > > subscription from > > > A, I would argue there is no need to tell A how to get authorized. > > > Ultimately, B has to provide authorization. So, anything > > that A can do > > > ultimately results in getting some information to B in > > order to allow B to > > > make a decision. So, why have the presence server for B, > > for example, tell A > > > to send email to B, when the presence server itself can > > send the email? > > > Particularly since you may not want A to know that no > > authorization policy > > > exists for them. > > > > > > > > > > > > > > > > > 2. why even worry about this? Well, all of the major IM and > > > > > presence systems > > > > > do this today. We should at least be able to provide the same > > > > > application > > > > > interface thats available, if users and their providers want it. > > > > Excuse me, all existing IM systems have a way to find out > > > > who is subscribed to your presence? All existing IM systems > > > > supply two URLs to approve or deny subscriptions? Funny, > > > > I didn't think any of them did. Let me fire up AIM. > > > > Hmmm, doesn't seem to have any controls on authorization, > > > > doesn't seem to have a way to find out who is looking at your > > > > presence. You can control who sends you IM. > > > > Actually, I don't know of ANY existing presence service that has > > > > the authorization idea, although there are "closed group" > > > > systems which limit who can do anything. > > > > > > On Yahoo messenger, when someone subscribes to me, if I'm > > logged in at the > > > time, I get a screen pop which says "User Joe just asked to > > be added to your > > > buddy list. Click here to approve, click here to reject, > > click here to > > > approve and add". If I'm offline, this screen pop arrives > > when I next log > > > in. This tells me that the system provides some way for an > > automata to learn > > > the set of outstanding subscriptions for its user, in order > > to provide that > > > screen pop. > > > > > > > > 3. I agree with you that defining authorization policy > > is a back-end > > > > > mechanism, and typically not real time. Thats why I have been > > > > > arguing that > > > > > the notification to B about the subscriber contain http URLs > > > > > that can be > > > > > used to accept/reject, and those URLs are part of the > > > > > back-end non-real-time > > > > > application. They facilitate a screen pop to a slim phone > > > > > that says "approve > > > > > or reject?" and thus allows setting of simple policies right > > > > > away without a > > > > > browser. > > > > That may be appropriate for some implementations, but clearly > > > > not all. However, it doesn't matter because it's entirely in > > > > one implementation. > > > > > > Don't we want interoperability between client applications > > and servers? I > > > thought that was the point - to not need to have a client > > written by the > > > vendor of the server. > > > > > > -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 Brian.Rosen@marconi.com Fri Jul 13 08:17:04 2001 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 IAA15114 for ; Fri, 13 Jul 2001 08:17:04 -0400 (EDT) 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 IAA24618; Fri, 13 Jul 2001 08:17:01 -0400 (EDT) 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 IAA22898; Fri, 13 Jul 2001 08:17:03 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <35STXYMW>; Fri, 13 Jul 2001 08:17:02 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF04465798@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Vasilis Polychronidis'" Cc: Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 08:17:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 12465 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: Vasilis There are a couple of issues: 1. Can you subscribe to your own something that Notifies you when a watcher subscribes? I say, sure, why not, fine idea. I think the concept that you CAN get notification when someone actually starts looking at your presence info is a good one. As you say, it's optional to subscribe. Note that this has nothing to do, in my mind, with authorization 2. Can you subscribe to something that gets you Notification that you have some authorization effort to make? I say, not interesting. The process of authorization is within an implementation of a UAS (the presence server, as an endpoint in a SIP system, is a UAS) and is not subject to standardization. The only way this isn't true is if the presentity is represented as a UAC, and the PS is a UAS, and then you need a standardized way that the presentity's UAC conveys authorization and presence setting information to the PS's UAS. I think that is a bad design idea. 3. Is a pair of URLs the way to represent an accept/deny authorization decision? I'd say, no, not by a whole lot. To make an authorization decision, the presentity needs to be presented with credentials (who are you that is asking to be authorized). Presence information may come in several forms, and you may need to specify what form. A decision on presence may not be binary (it may be, for example, which form is allowed). So to authorize, you have to present a variable amount of information from the watcher, and you have to accept a variable amount of information from the presentity. While I happen to think that a web based GUI to do this is a very fine idea, I think that you can't standardize it, at least now. Brian > -----Original Message----- > From: Vasilis Polychronidis > [mailto:Vasilis.Polychronidis@openwave.com] > Sent: Thursday, July 12, 2001 6:38 PM > To: Jonathan Rosenberg; 'Rosen, Brian' > Cc: 'Boyer, D G (Dave)'; 'adam.roach@ericsson.com'; Ben Campbell; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Another idea for presence authorization > > > Hi Brian, > Looking through this issue I tend to agree with Jonathan's proposal. > It is really important that the method described by Jonathan > (Subscribing to > your watcher info) > is optional. > As Jonathan said B has to explicitly request it (subscribe to > his watcher info). > > In addition we should not mandate the Presence Server to > accept "watcher type": subscriptions. > So the proposed feature is an optional one. > Is this acceptable to you Brian? > > I also agree with the use of URLs for accepting/rejecting a > subscription. > > BR, > > Vasilis Polychronidis > > Jonathan Rosenberg wrote: > > > Brian, > > > > Now I understand what you are saying. I want there to be a > way for B to find > > out when someone subscribes to him, so he can, if desired, provide > > authorization. You don't want to ever tell B when someone > subscribes; > > rather, you tell A that they should visit some web page, > and maybe that > > allows them to send email to B asking for authorization. > > > > So, let me make a few comments in response: > > > > 1. this bit about letting B know is **NOT** part of the > main presence > > specification whatsoever. All that specification says is > "the server obtains > > authorization in some fashion, not specified". The > mechanism that allows B > > to find out who subscribes is separate, and opt-in, not > opt-out. That is, B > > has to explicitly request to find out who subscribed to > him. If B does > > nothing, B finds out nothing. Presence servers don't have > to provide the > > function either. > > > > 2. why even worry about this? Well, all of the major IM and > presence systems > > do this today. We should at least be able to provide the > same application > > interface thats available, if users and their providers want it. > > > > 3. I agree with you that defining authorization policy is a back-end > > mechanism, and typically not real time. Thats why I have > been arguing that > > the notification to B about the subscriber contain http > URLs that can be > > used to accept/reject, and those URLs are part of the > back-end non-real-time > > application. They facilitate a screen pop to a slim phone > that says "approve > > or reject?" and thus allows setting of simple policies > right away without a > > browser. > > > > The problem that has been observed with your alternate > approach, of telling > > A about a URL, is that this allows A to learn whether they have been > > approved or rejected. Paul argues that this knowledge can > be learned anyway, > > by sending an INVITE and seeing whether the call is > accepted or rejected. > > Not necessarily; I can set up a service to achieve the same > effect for > > voice. If someone calls me, and I don't want to talk to > them, instead of > > them getting a "600 I hate you" response, the server can > simply let the > > phone ring indefinitely, so that the caller can't tell > whether I'm not > > there, or whether they've been rejected. > > > > -Jonathan R. > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Tuesday, July 10, 2001 6:18 PM > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > 'adam.roach@ericsson.com'; Ben Campbell > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > Yes, I understand what you are proposing; I think it > > > is not appropriate to confuse the concept of > > > authorization (will I allow you to subscribe) from > > > the actual subscription. You want to do that - you > > > want the very first action to be a subscribe. > > > If the server for B can immediately confirm a new > > > authorization, because there is some policy in place > > > that lets it do so, you propose to let that subscription > > > succeed. You want to talk about what happens when > > > it fails. > > > > > > I want to completely remove authorization from the protocol; > > > Subscriptions are then only how you connect to the > > > presentity's server. It succeeds if you are authorized, > > > fails if you aren't (also fails for other reasons). > > > I see no win at all to have the protocol deal with > > > authorization. > > > > > > So, with that in mind, let's look at what you propose: > > > > > > > This is not right. The party that approves or denies the > > > > subscription is NOT > > > > the party that has subscribed. > > > We all agree, B is the approver. B's server has the > authorization. > > > A subscribes. It succeeds only if B has given approval. > > > > > > > > > > > Here is the scenario. A subsciber, A, subscribes to B. For > > > > any subscription > > > > to B to be approved, B has to have given authorization for > > > > it. However, > > > > there is currently no authorization policy specified by B > > > > about whether A > > > > can subscribe. So, when A's subscription is received by the > > > server, a > > > > response is generated, but the subscription is not activated. > > > I claim if B has no authorization for A, then A's subscription > > > request is denied, and that is the end of the story. > > > So I agree you get a response, and that is fail, with > > > a referral (URL). > > > > > > If A wants to get approval, he might consult the URL to find > > > a web page that might allow him to be authorized. > > > > > > >Now, the > > > > problem is that the server needs to know whether B approves this > > > > subscription. It might just wait, hoping that someday, B sets > > > > a policy for > > > > user A. However, that doesn't work well. What you want is > > > > some way to prod > > > > B, and say to him, "hey, A tried to subscribe, please set a > > > > policy for A". > > > > Then, A can go to some web page, or whatver the backend > > > > policy mechanism is, > > > > and set up policy. > > > Wrong end. You don't want B to take action just because > > > A tried to subscribe. Great opportunity to drive B nuts. > > > What you want to do is tell A how to get authorized. > > > A is the one who wants to get authorized, and we can tell > > > him how to do it. There is no win in telling B how to > > > run his own authorization mechanism. Mostly, there is > > > no win in prodding B based on a subscription attempt for A > > > when A isn't even authorized. > > > > > > Importantly, the subscription request failed. > > > If B's server eventually gets some authorization info, > > > it has nothing to do with it but wait until A tries > > > to subscribe again. > > > > > > > > > > > So, to provide this "prodding" capability, we've agreed to > > > > use a new event > > > > package, called watcherinfo. The idea is that B can subscribe > > > > to his own set > > > > of watchers, so that when it changes (for example, when A > > > > subscribes), B > > > > gets notified. B can then go to the web page and upload > approval. > > > This seems wacky to me. Why should the protocol prod B? > > > Why should the protocol do anything to support authorization - > > > that is a non-real-time issue. Sending B an email may be a more > > > appropriate thing to do, but that should be because A asks for > > > authorization. The question is, how does A do that? The point > > > is that since it's B's decision, B may need arbitrary information > > > from A before he will authorize. Therefore, A needs to use B's > > > authorization mechanism. You can't make A's user interface > > > know how to give B what he needs to authorize. A web page that > > > B creates is at least one way to do that. > > > > > > >The > > > > additional thing we are debating, is whether there should > > > be an actual > > > > protocol mechanism for conveying that approval/rejection to > > > > the server. I > > > > have proposed that the NOTIFY that gets sent to B when A > > > > subscribes have two > > > > URLs specified by the server, one which approves the > > > > subscription from A, > > > > and one which rejects. Others have proposed that we specify a > > > > protocol for B > > > > to upload approval in a presence document. Others want > to specify > > > > SIP/SOAP/WSDL for this. > > > Repeating myself, there is no point in having protocol support > > > for human-in-the-loop messaging. While this might be something > > > that is worth specifying so that B's agent can talk to B's > > > server, I suspect that at least for now, we can safely leave this > > > out of the spec because it has nothing to do with A and B. > > > You are talking about how B the human interacts with B's server; > > > not something I think is worth standardizing. > > > > > > > > > > > All of this is different from what A sees when A's > > > > subscription to B is > > > > rejected, approved, or marked as "pending" because there is > > > > no policy. We > > > > have already agreed some time back that in all cases, the > > > subscription > > > > request is immediately responded to with a 202 and a NOTIFY > > > > with the status. > > > > If the subscription was accepted, the status is correct. If > > > > the subscription > > > > failed, or was marked as pending, the NOTIFY contains > > > > syntactically correct > > > > but invalid data. This way, the subscriber can't know what > > > > happened to their > > > > subscription. > > > I think we are in agreement here. A doesn't get to know if > > > he is authorized or not, subscription just fails. > > > > > > In particular, when B finally does authorize A, A has to > > > "just know" to try subscribing again; we don't help him. > > > > > > It's always possible that the authorization mechanism tells > > > A, say by email. > > > > > > Brian > > > > > > > > > > > --- > > 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 jdrosen@dynamicsoft.com Fri Jul 13 10:03:11 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15464 for ; Fri, 13 Jul 2001 10:03:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DE2SRX018254; Fri, 13 Jul 2001 10:02:28 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYC49CV>; Fri, 13 Jul 2001 10:03:02 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" , Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 10:03:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 6037 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: > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, July 11, 2001 2:25 PM > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Well, I'm real confused. > 1. The "automata" you are talking about -- I don't understand > what role it has in the context of this discussion. We have > "servers" that have presence information and "clients" that > want to get it. The server is an entity operating on behalf of a > presentity. The client is an entity operating on behalf of a > watcher. In > SIP terms, we have a UAC and a UAS. Its more complex than that, Brian. I'll repeat the picture I just sent in a previous email: | | | | |SUB B's pres.winfo (1)| | |<---------------------| B's client turns on | |200 OK (2)| | |--------------------->| | |NOTIFY (3)| | |--------------------->| | |200 OK (4)| | |<---------------------| | | | |SUB B's pres (5) | | |----------------->| | |202 Accepted (6)| | |<-----------------|NOTIFY "A Pending" (9)| |NOTIFY B's pres(7)|--------------------->|B learns that A |<-----------------|200 OK (10)| subscribed |200 OK (8)|<---------------------| |----------------->| | | | | | | | | |Set policy (11)| | |<---------------------| | | | | | | | | | | | | Subscriber Presence Presentity A Server B > The UAS > is the agent of the presentity, and the UAC is the agent of > the watcher. Now, where is this automata? In the UAS? > The UAS is what the protocol defines, you seem to want to deal > with something that is not the UAS but is connecting to it. There is a presence server, which is a UAC for some transactions, and UAS for others. There is a subscriber A, which is a UAC for some transactions (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a presentity application for B, which is a UAC for some transactions (SUBSCRIBE to its watcherinfo), and a UAS for others. Remember, UAC/UAS is a per transaction role. The presence server is the "agent" for B, in the sense that it accepts subscribes and generates notifies on B's behalf. How it finds out about the presence state is another orthogonal piece, not specified in the SUB/NOT mechanism. Typically, its through registrations or through direct upload of a presence document. > > At the moment, the model I'm imagining in your head is one > where the presentity and the watcher are both UACs and there > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > idea. If that is the model you are pushing, I want to push > back. The UAC is the agent of the presentity, the UAS is the > agent of the watcher, and the UAC doesn't need any protocol > to the presentity -- it "is" the presentity. I cannot map these statements to sensible definitions of UAC and UAS, presentity or watcher. Please see above. > If you want > the presentity to be a UAC, then we need more than what we > are talking about on this thread - we need to standardize > how the UAC at the presentity tells the UAS how to change its > presence, and then we get into all sorts of issues about > how this model supports rich presence information (since it > requires that two UACs AND the UAS all have the same > capabilities). How the UAC interacts with the presentity > is not the place we standardize. It could be split into > a "client" and a "server", but the interactions between those > pieces are complex, and I don't see how we could standardize > them right now. I still cannot understand any of the above based on the definitions of UAC and UAS in the bis spec, and presentity, watcher, etc. from rfc2778. > > 2. I never used Yahoo Messenger. I just loaded it. > Yes, you get a message when someone puts you in his > friend list. However, what it is asking you seems to be > whether you want to put him in YOUR buddy list. In particular, > if you reject, you are still in his friend list, and he sees > your presence. No, thats not true. When I subscribe to someone, they appear in my buddy list, and the status is marked as "pending authorization" until the time that they provide authorization. Once that happens, I see their real presence. On the other side, when someone subscribes to me, I get a screen pop, which asks for "approve", "approve and add", or "reject". Approve/reject have the meanings we've been discussing - they approve or reject the subscription. "approve and add" approves the subscription, and also sends a subscription from me back to them, adding them to my buddy list. I've been using this tool for several years. I think I can make these statements with soem confidence that they are correct. -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 From jdrosen@dynamicsoft.com Fri Jul 13 10:14:50 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15521 for ; Fri, 13 Jul 2001 10:14:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DEEBRX018437; Fri, 13 Jul 2001 10:14:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYC4917>; Fri, 13 Jul 2001 10:14:45 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" , "'Vasilis Polychronidis'" Cc: Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 10:14:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 4392 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: > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, July 13, 2001 8:17 AM > To: 'Vasilis Polychronidis' > Cc: Jonathan Rosenberg; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; > Ben Campbell; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Vasilis > > There are a couple of issues: > 1. Can you subscribe to your own something that Notifies you > when a watcher subscribes? > I say, sure, why not, fine idea. > I think the concept that you CAN get notification > when someone actually starts looking at your > presence info is a good one. As you say, it's > optional to subscribe. > Note that this has nothing to do, in my mind, with > authorization This is the piece I am most interested in doing, and previously, the piece that I thought you were objecting to. This covers 90% of what I think we need. > > 2. Can you subscribe to something that gets you Notification > that you have some authorization effort to make? I'm not proposing quite that; I'm proposing that when you get notified that a watcher subscribes, from (1) above, that notification tells you what happened to the subscription - whether it was accepted, rejected, or marked as "pending", because the presence server could not make a decision, as there was no policy specified. If the user sees that someone subscribed to them and was marked pending because there was no policy, they can go to the web page at their leisure, and provide some policy, or use an IVR system, or whatever. However, none of those allow for the application on the user's PC (assuming its runnig) to provide authorization automatically, or the the application on the user's PC to perform a screen pop that queries the user, and based on what button is pressed, provide authorization. I agree that in many cases this is NOT sufficient, since the subscriber will need to know more than who the subscriber is, and will need to give more details about the policy for handling the subscription. I agree that in such cases, it is ideally handled through user interactions like web pages or voice response. However, I think there is value in allowing the basic operation to be automated, and then requiring human interaction for the complex cases. > I say, not interesting. The process of authorization > is within an implementation of a UAS (the presence server, > as an endpoint in a SIP system, is a UAS) and is not > subject to standardization. We need standards whenever we want communications between two entities that are separated over the network. > The only way this isn't > true is if the presentity is represented as a UAC, and > the PS is a UAS, and then you need a standardized way that > the presentity's UAC conveys authorization and presence > setting information to the PS's UAS. I think that is > a bad design idea. Again, I cannot understand this based on my understanding of the terms UAC and UAS. > > 3. Is a pair of URLs the way to represent an accept/deny > authorization decision? > I'd say, no, not by a whole lot. In many cases, you are correct. I am not arguing that it be the ONLY way. I'm arguing that it be A way. > To make an authorization > decision, the presentity needs to be presented with > credentials (who are you that is asking to be authorized). > Presence information may come in several forms, and you may > need to specify what form. A decision on presence may > not be binary (it may be, for example, which form is > allowed). So to authorize, you have to present a variable > amount of information from the watcher, and you have to > accept a variable amount of information from the presentity. Agreed. But, I argue that there is a common enough case for existing applications that will allow us to provide a simple interface for the simple things, and let the more complex cases remain unstandardized through web/IVR interactions (or possibly even CPLs...). -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 From Brian.Rosen@marconi.com Fri Jul 13 10:44:04 2001 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 KAA15625 for ; Fri, 13 Jul 2001 10:44:03 -0400 (EDT) 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 KAA10556; Fri, 13 Jul 2001 10:43:49 -0400 (EDT) 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 KAA06334; Fri, 13 Jul 2001 10:43:51 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <35STY1SR>; Fri, 13 Jul 2001 10:43:51 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044657A3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 10:43:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 9693 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: Let's start over. A and B are both UAs. I think we all agree on that. You want a PS. I'll agree they are useful. If you want a PS, then its a UAS to A. I want to talk about how PS and B interact. I don't know if you would allow me to go there, but, just for a moment, indulge me and let's talk about A and B without PS. A wants to know B's presence. Okay, so A subscribes to B, and B supplies presence as NOTIFYies. This all works fine, although it ignores how B authorizes A. In particular, in order for B to authorize A, he needs credentials for A (who are you). While the standard SIP headers might be enough, in many cases, you need more information about A. How do you get that? With my example, everything (except credentials) is fine. In particular, B can send presence to A because it's really B (B's real UA) that is the source of the presence info, and we would all agree that B the human interacts with B's UA in some implementation dependent manner for B's UA to find out the actual presence state. Are we okay here? Now let's put in the PS. In your model, just for now, skip authorization, and let's just talk about how B tells PS that B's presence state changed. I can see two possibilities. The one I like is that PS subscribes to B's presence. The other is that there is a new header that is used for that purpose. My way is real simple, takes no extension, and does exactly what you want. When B changes his presence, he does so on his UA (exactly as above), and Notifies PS. PS, in turn, Notifies A. Simple, clean, effective. So what is PS? I claim it's a straightforward B2BUA. Instead of subscribing directly to B, PS subscribes to B and A (as well as any other authorized watchers) subscribe to PS. Now, you introduce watcherinfo. I'm okay with that. B subscribes to watcherinfo on PS, and PS Notifies B of subscriptions. Now, back to authorization In several posts, I've stated that I'm interested in a rich notion of presence. That covers a LOT of territory, but let me give you a small example. Suppose I have 3 states in my presence model In-Busy-Out. For some watchers, I will give them one of these three states. However, there are some people for whom I don't want them to know that I'm in, but busy. They only get two states - In/Out. This is all pretty easy stuff. However, my authorization is not binary. I have to tell PS which of the two models A gets. Two URLs are not enough. So, authorization, I claim, is complex. You need arbitrary credentials from A, and you need arbitrary outputs from B. Thus, I claim, there is no sensible way to define the authorization process between B and PS, or for that matter, between A and PS in a standardized way. One way to help would be to at least tell A where to go to at least FIND OUT how to get authorization. Simply subscribing (attempting to subscribe) is not enough. If you want to turn that around and say, fine, let's also tell B how to authorize, I can't argue. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, July 13, 2001 10:03 AM > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Wednesday, July 11, 2001 2:25 PM > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Well, I'm real confused. > > 1. The "automata" you are talking about -- I don't understand > > what role it has in the context of this discussion. We have > > "servers" that have presence information and "clients" that > > want to get it. The server is an entity operating on behalf of a > > presentity. The client is an entity operating on behalf of a > > watcher. In > > SIP terms, we have a UAC and a UAS. > > Its more complex than that, Brian. > > I'll repeat the picture I just sent in a previous email: > > > > | | | > | |SUB B's pres.winfo (1)| > | |<---------------------| B's > client turns on > | |200 OK (2)| > | |--------------------->| > | |NOTIFY (3)| > | |--------------------->| > | |200 OK (4)| > | |<---------------------| > | | | > |SUB B's pres (5) | | > |----------------->| | > |202 Accepted (6)| | > |<-----------------|NOTIFY "A Pending" (9)| > |NOTIFY B's pres(7)|--------------------->|B learns that A > |<-----------------|200 OK (10)| subscribed > |200 OK (8)|<---------------------| > |----------------->| | > | | | > | | | > | |Set policy (11)| > | |<---------------------| > | | | > | | | > | | | > | | | > > Subscriber Presence Presentity > A Server B > > > The UAS > > is the agent of the presentity, and the UAC is the agent of > > the watcher. Now, where is this automata? In the UAS? > > The UAS is what the protocol defines, you seem to want to deal > > with something that is not the UAS but is connecting to it. > > There is a presence server, which is a UAC for some > transactions, and UAS > for others. There is a subscriber A, which is a UAC for some > transactions > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a presentity > application for B, which is a UAC for some transactions > (SUBSCRIBE to its > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > per transaction > role. The presence server is the "agent" for B, in the sense > that it accepts > subscribes and generates notifies on B's behalf. How it finds > out about the > presence state is another orthogonal piece, not specified in > the SUB/NOT > mechanism. Typically, its through registrations or through > direct upload of > a presence document. > > > > > > At the moment, the model I'm imagining in your head is one > > where the presentity and the watcher are both UACs and there > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > idea. If that is the model you are pushing, I want to push > > back. The UAC is the agent of the presentity, the UAS is the > > agent of the watcher, and the UAC doesn't need any protocol > > to the presentity -- it "is" the presentity. > > I cannot map these statements to sensible definitions of UAC and UAS, > presentity or watcher. Please see above. > > > If you want > > the presentity to be a UAC, then we need more than what we > > are talking about on this thread - we need to standardize > > how the UAC at the presentity tells the UAS how to change its > > presence, and then we get into all sorts of issues about > > how this model supports rich presence information (since it > > requires that two UACs AND the UAS all have the same > > capabilities). How the UAC interacts with the presentity > > is not the place we standardize. It could be split into > > a "client" and a "server", but the interactions between those > > pieces are complex, and I don't see how we could standardize > > them right now. > > I still cannot understand any of the above based on the > definitions of UAC > and UAS in the bis spec, and presentity, watcher, etc. from rfc2778. > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > Yes, you get a message when someone puts you in his > > friend list. However, what it is asking you seems to be > > whether you want to put him in YOUR buddy list. In particular, > > if you reject, you are still in his friend list, and he sees > > your presence. > > No, thats not true. When I subscribe to someone, they appear > in my buddy > list, and the status is marked as "pending authorization" > until the time > that they provide authorization. Once that happens, I see their real > presence. On the other side, when someone subscribes to me, I > get a screen > pop, which asks for "approve", "approve and add", or "reject". > Approve/reject have the meanings we've been discussing - they > approve or > reject the subscription. "approve and add" approves the > subscription, and > also sends a subscription from me back to them, adding them > to my buddy > list. > > I've been using this tool for several years. I think I can make these > statements with soem confidence that they are correct. > > -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 > From ds708@columbia.edu Fri Jul 13 11:58:58 2001 Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.59.159]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15861 for ; Fri, 13 Jul 2001 11:58:58 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA12778; Fri, 13 Jul 2001 11:58:41 -0400 (EDT) From: "Daniel Starin" To: "'Rosen, Brian'" , "'Jonathan Rosenberg'" Cc: Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 11:59:06 -0400 Message-ID: <001f01c10bb4$bf0fb120$a1a20681@DSTARIN2> 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, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4FBEA8857476D311A03300204840E1CF044657A3@whq-msgusr-02.pit.comms.marconi.com> Importance: Normal Content-Length: 10794 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: Brian, It seems that there are two different issues you are discussing. One is whether or not A (the watcher) may access any of B's presence information (a binary decision) and the other is IF B indeed allows A to access presence information, what type of information will that be, - In/Out, In / Busy/Out, etc. Regardless of what complex presence information a user may have, there will always be an initial binary decision (yes, you can access presence or no, you cannot). Because this decision must always be made for each and every subscription request which is made, it may be reasonable to standardize how this will be done. -Dan -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Rosen, Brian Sent: Friday, July 13, 2001 10:44 AM To: 'Jonathan Rosenberg' Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Let's start over. A and B are both UAs. I think we all agree on that. You want a PS. I'll agree they are useful. If you want a PS, then its a UAS to A. I want to talk about how PS and B interact. I don't know if you would allow me to go there, but, just for a moment, indulge me and let's talk about A and B without PS. A wants to know B's presence. Okay, so A subscribes to B, and B supplies presence as NOTIFYies. This all works fine, although it ignores how B authorizes A. In particular, in order for B to authorize A, he needs credentials for A (who are you). While the standard SIP headers might be enough, in many cases, you need more information about A. How do you get that? With my example, everything (except credentials) is fine. In particular, B can send presence to A because it's really B (B's real UA) that is the source of the presence info, and we would all agree that B the human interacts with B's UA in some implementation dependent manner for B's UA to find out the actual presence state. Are we okay here? Now let's put in the PS. In your model, just for now, skip authorization, and let's just talk about how B tells PS that B's presence state changed. I can see two possibilities. The one I like is that PS subscribes to B's presence. The other is that there is a new header that is used for that purpose. My way is real simple, takes no extension, and does exactly what you want. When B changes his presence, he does so on his UA (exactly as above), and Notifies PS. PS, in turn, Notifies A. Simple, clean, effective. So what is PS? I claim it's a straightforward B2BUA. Instead of subscribing directly to B, PS subscribes to B and A (as well as any other authorized watchers) subscribe to PS. Now, you introduce watcherinfo. I'm okay with that. B subscribes to watcherinfo on PS, and PS Notifies B of subscriptions. Now, back to authorization In several posts, I've stated that I'm interested in a rich notion of presence. That covers a LOT of territory, but let me give you a small example. Suppose I have 3 states in my presence model In-Busy-Out. For some watchers, I will give them one of these three states. However, there are some people for whom I don't want them to know that I'm in, but busy. They only get two states - In/Out. This is all pretty easy stuff. However, my authorization is not binary. I have to tell PS which of the two models A gets. Two URLs are not enough. So, authorization, I claim, is complex. You need arbitrary credentials from A, and you need arbitrary outputs from B. Thus, I claim, there is no sensible way to define the authorization process between B and PS, or for that matter, between A and PS in a standardized way. One way to help would be to at least tell A where to go to at least FIND OUT how to get authorization. Simply subscribing (attempting to subscribe) is not enough. If you want to turn that around and say, fine, let's also tell B how to authorize, I can't argue. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, July 13, 2001 10:03 AM > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > 'adam.roach@ericsson.com'; Ben Campbell > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Wednesday, July 11, 2001 2:25 PM > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Well, I'm real confused. > > 1. The "automata" you are talking about -- I don't understand > > what role it has in the context of this discussion. We have > > "servers" that have presence information and "clients" that > > want to get it. The server is an entity operating on behalf of a > > presentity. The client is an entity operating on behalf of a > > watcher. In > > SIP terms, we have a UAC and a UAS. > > Its more complex than that, Brian. > > I'll repeat the picture I just sent in a previous email: > > > > | | | > | |SUB B's pres.winfo (1)| > | |<---------------------| B's > client turns on > | |200 OK (2)| > | |--------------------->| > | |NOTIFY (3)| > | |--------------------->| > | |200 OK (4)| > | |<---------------------| > | | | > |SUB B's pres (5) | | > |----------------->| | > |202 Accepted (6)| | > |<-----------------|NOTIFY "A Pending" (9)| > |NOTIFY B's pres(7)|--------------------->|B learns that A > |<-----------------|200 OK (10)| subscribed > |200 OK (8)|<---------------------| > |----------------->| | > | | | > | | | > | |Set policy (11)| > | |<---------------------| > | | | > | | | > | | | > | | | > > Subscriber Presence Presentity > A Server B > > > The UAS > > is the agent of the presentity, and the UAC is the agent of > > the watcher. Now, where is this automata? In the UAS? > > The UAS is what the protocol defines, you seem to want to deal > > with something that is not the UAS but is connecting to it. > > There is a presence server, which is a UAC for some > transactions, and UAS > for others. There is a subscriber A, which is a UAC for some > transactions > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a presentity > application for B, which is a UAC for some transactions > (SUBSCRIBE to its > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > per transaction > role. The presence server is the "agent" for B, in the sense > that it accepts > subscribes and generates notifies on B's behalf. How it finds > out about the > presence state is another orthogonal piece, not specified in > the SUB/NOT > mechanism. Typically, its through registrations or through > direct upload of > a presence document. > > > > > > At the moment, the model I'm imagining in your head is one > > where the presentity and the watcher are both UACs and there > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > idea. If that is the model you are pushing, I want to push > > back. The UAC is the agent of the presentity, the UAS is the > > agent of the watcher, and the UAC doesn't need any protocol > > to the presentity -- it "is" the presentity. > > I cannot map these statements to sensible definitions of UAC and UAS, > presentity or watcher. Please see above. > > > If you want > > the presentity to be a UAC, then we need more than what we > > are talking about on this thread - we need to standardize > > how the UAC at the presentity tells the UAS how to change its > > presence, and then we get into all sorts of issues about > > how this model supports rich presence information (since it > > requires that two UACs AND the UAS all have the same > > capabilities). How the UAC interacts with the presentity > > is not the place we standardize. It could be split into > > a "client" and a "server", but the interactions between those > > pieces are complex, and I don't see how we could standardize > > them right now. > > I still cannot understand any of the above based on the > definitions of UAC > and UAS in the bis spec, and presentity, watcher, etc. from rfc2778. > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > Yes, you get a message when someone puts you in his > > friend list. However, what it is asking you seems to be > > whether you want to put him in YOUR buddy list. In particular, > > if you reject, you are still in his friend list, and he sees > > your presence. > > No, thats not true. When I subscribe to someone, they appear > in my buddy > list, and the status is marked as "pending authorization" > until the time > that they provide authorization. Once that happens, I see their real > presence. On the other side, when someone subscribes to me, I > get a screen > pop, which asks for "approve", "approve and add", or "reject". > Approve/reject have the meanings we've been discussing - they > approve or > reject the subscription. "approve and add" approves the > subscription, and > also sends a subscription from me back to them, adding them > to my buddy > list. > > I've been using this tool for several years. I think I can make these > statements with soem confidence that they are correct. > > -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 Brian.Rosen@marconi.com Fri Jul 13 12:04:59 2001 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 MAA15914 for ; Fri, 13 Jul 2001 12:04:58 -0400 (EDT) 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 MAA19569; Fri, 13 Jul 2001 12:04:55 -0400 (EDT) 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 MAA02334; Fri, 13 Jul 2001 12:04:57 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <35STYL4B>; Fri, 13 Jul 2001 12:04:56 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044657A9@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Daniel Starin'" Cc: "'Jonathan Rosenberg'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 12:04:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 12017 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: I don't agree. Authorization is specific - who and what. You can't split it up like that, or at least there is very little value in doing so. If I gave you a standardized way to say yes/no, but don't give you a standardized way to specify what, the implementation is just as proprietary. Also don't forget the credentials part. In order to even say yes/no, you need the credentials. Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 11:59 AM > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Brian, > > It seems that there are two different issues you are discussing. > > One is whether or not A (the watcher) may access any of B's presence > information (a binary decision) and the other is IF B indeed > allows A to > access presence information, what type of information will that be, - > In/Out, In / Busy/Out, etc. > > Regardless of what complex presence information a user may have, there > will always be an initial binary decision (yes, you can > access presence > or no, you cannot). Because this decision must always be > made for each > and every subscription request which is made, it may be reasonable to > standardize how this will be done. > > -Dan > > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Rosen, Brian > Sent: Friday, July 13, 2001 10:44 AM > To: 'Jonathan Rosenberg' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > Let's start over. > > A and B are both UAs. I think we all agree on that. > You want a PS. I'll agree they are useful. If you > want a PS, then its a UAS to A. I want to talk > about how PS and B interact. > > I don't know if you would allow me to go there, but, > just for a moment, indulge me and let's talk about > A and B without PS. A wants to know B's presence. > Okay, so A subscribes to B, and B supplies > presence as NOTIFYies. This all works fine, although > it ignores how B authorizes A. In particular, > in order for B to authorize A, he needs credentials > for A (who are you). While the standard SIP headers > might be enough, in many cases, you need more > information about A. How do you get that? > > With my example, everything (except credentials) is > fine. In particular, B can send presence to A > because it's really B (B's real UA) that is the > source of the presence info, and we would all agree > that B the human interacts with B's UA in some > implementation dependent manner for B's UA to > find out the actual presence state. > > Are we okay here? > > Now let's put in the PS. In your model, just for now, > skip authorization, and let's just talk about how > B tells PS that B's presence state changed. > I can see two possibilities. The one I like is that > PS subscribes to B's presence. The other is that > there is a new header that is used for that purpose. > My way is real simple, takes no extension, and does > exactly what you want. When B changes his presence, > he does so on his UA (exactly as above), and Notifies > PS. PS, in turn, Notifies A. Simple, clean, effective. > > So what is PS? I claim it's a straightforward > B2BUA. Instead of subscribing directly to B, PS > subscribes to B and A (as well as any other authorized > watchers) subscribe to PS. > > Now, you introduce watcherinfo. I'm okay with that. > B subscribes to watcherinfo on PS, and PS Notifies B > of subscriptions. > > Now, back to authorization > > In several posts, I've stated that I'm interested in a > rich notion of presence. That covers a LOT of territory, > but let me give you a small example. Suppose I have > 3 states in my presence model In-Busy-Out. For > some watchers, I will give them one of these three > states. However, there are some people for whom I > don't want them to know that I'm in, but busy. They > only get two states - In/Out. This is all pretty easy > stuff. > > However, my authorization is not binary. I have to > tell PS which of the two models A gets. Two URLs > are not enough. > > So, authorization, I claim, is complex. You need > arbitrary credentials from A, and you need arbitrary outputs > from B. Thus, I claim, there is no sensible way to define the > authorization process between B and PS, or for that > matter, between A and PS in a standardized way. > > One way to help would be to at least tell A where > to go to at least FIND OUT how to get authorization. > Simply subscribing (attempting to subscribe) is not enough. > If you want to turn that around and say, fine, let's > also tell B how to authorize, I can't argue. > > Brian > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, July 13, 2001 10:03 AM > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > 'adam.roach@ericsson.com'; Ben Campbell > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > Well, I'm real confused. > > > 1. The "automata" you are talking about -- I don't understand > > > what role it has in the context of this discussion. We have > > > "servers" that have presence information and "clients" that > > > want to get it. The server is an entity operating on behalf of a > > > presentity. The client is an entity operating on behalf of a > > > watcher. In > > > SIP terms, we have a UAC and a UAS. > > > > Its more complex than that, Brian. > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > | | | > > | |SUB B's pres.winfo (1)| > > | |<---------------------| B's > > client turns on > > | |200 OK (2)| > > | |--------------------->| > > | |NOTIFY (3)| > > | |--------------------->| > > | |200 OK (4)| > > | |<---------------------| > > | | | > > |SUB B's pres (5) | | > > |----------------->| | > > |202 Accepted (6)| | > > |<-----------------|NOTIFY "A Pending" (9)| > > |NOTIFY B's pres(7)|--------------------->|B learns that A > > |<-----------------|200 OK (10)| subscribed > > |200 OK (8)|<---------------------| > > |----------------->| | > > | | | > > | | | > > | |Set policy (11)| > > | |<---------------------| > > | | | > > | | | > > | | | > > | | | > > > > Subscriber Presence Presentity > > A Server B > > > > > The UAS > > > is the agent of the presentity, and the UAC is the agent of > > > the watcher. Now, where is this automata? In the UAS? > > > The UAS is what the protocol defines, you seem to want to deal > > > with something that is not the UAS but is connecting to it. > > > > There is a presence server, which is a UAC for some > > transactions, and UAS > > for others. There is a subscriber A, which is a UAC for some > > transactions > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > presentity > > application for B, which is a UAC for some transactions > > (SUBSCRIBE to its > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > per transaction > > role. The presence server is the "agent" for B, in the sense > > that it accepts > > subscribes and generates notifies on B's behalf. How it finds > > out about the > > presence state is another orthogonal piece, not specified in > > the SUB/NOT > > mechanism. Typically, its through registrations or through > > direct upload of > > a presence document. > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > where the presentity and the watcher are both UACs and there > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > idea. If that is the model you are pushing, I want to push > > > back. The UAC is the agent of the presentity, the UAS is the > > > agent of the watcher, and the UAC doesn't need any protocol > > > to the presentity -- it "is" the presentity. > > > > I cannot map these statements to sensible definitions of > UAC and UAS, > > presentity or watcher. Please see above. > > > > > If you want > > > the presentity to be a UAC, then we need more than what we > > > are talking about on this thread - we need to standardize > > > how the UAC at the presentity tells the UAS how to change its > > > presence, and then we get into all sorts of issues about > > > how this model supports rich presence information (since it > > > requires that two UACs AND the UAS all have the same > > > capabilities). How the UAC interacts with the presentity > > > is not the place we standardize. It could be split into > > > a "client" and a "server", but the interactions between those > > > pieces are complex, and I don't see how we could standardize > > > them right now. > > > > I still cannot understand any of the above based on the > > definitions of UAC > > and UAS in the bis spec, and presentity, watcher, etc. > from rfc2778. > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > Yes, you get a message when someone puts you in his > > > friend list. However, what it is asking you seems to be > > > whether you want to put him in YOUR buddy list. In particular, > > > if you reject, you are still in his friend list, and he sees > > > your presence. > > > > No, thats not true. When I subscribe to someone, they appear > > in my buddy > > list, and the status is marked as "pending authorization" > > until the time > > that they provide authorization. Once that happens, I see their real > > presence. On the other side, when someone subscribes to me, I > > get a screen > > pop, which asks for "approve", "approve and add", or "reject". > > Approve/reject have the meanings we've been discussing - they > > approve or > > reject the subscription. "approve and add" approves the > > subscription, and > > also sends a subscription from me back to them, adding them > > to my buddy > > list. > > > > I've been using this tool for several years. I think I can > make these > > statements with soem confidence that they are correct. > > > > -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 ds708@columbia.edu Fri Jul 13 12:58:43 2001 Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.59.159]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16082 for ; Fri, 13 Jul 2001 12:58:43 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA04420; Fri, 13 Jul 2001 12:58:29 -0400 (EDT) From: "Daniel Starin" To: "'Rosen, Brian'" Cc: "'Jonathan Rosenberg'" , Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 12:58:54 -0400 Message-ID: <002001c10bbd$19a9fde0$a1a20681@DSTARIN2> 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, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4FBEA8857476D311A03300204840E1CF044657A9@whq-msgusr-02.pit.comms.marconi.com> Importance: Normal Content-Length: 13401 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: The difference is, when I authorize someone, the way that I interact with them may change throughout the time that the subscription exists. One minute I may want them to never see detailed presence (IN / OUT / AWAY / BUSY) while the next minute I may want them to see OUT regardless of what my actual presence is. The fact is, for the most part, these decisions are based on what is happening currently, not what happens when the request for the subscription takes place. At the time of request, all that is usually known is Yes, you may subscribe, or no, you may not. If you happen to know that you also what to give the person a specific type of presence (IN / OUT) at that time than so be it, you can. But many times, you will not know specifically how you want your presence to be distributed to those that subscribe to you at the moment they request a subscription. Thus a Yes/No authorization should be specified. Possibly a "what" should be specified as well but these two things should be distinct. As for credentials. I agree that some form of credentials must be specified for Yes / No authorization... Dan -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, July 13, 2001 12:05 PM To: 'Daniel Starin' Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization I don't agree. Authorization is specific - who and what. You can't split it up like that, or at least there is very little value in doing so. If I gave you a standardized way to say yes/no, but don't give you a standardized way to specify what, the implementation is just as proprietary. Also don't forget the credentials part. In order to even say yes/no, you need the credentials. Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 11:59 AM > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Brian, > > It seems that there are two different issues you are discussing. > > One is whether or not A (the watcher) may access any of B's presence > information (a binary decision) and the other is IF B indeed > allows A to > access presence information, what type of information will that be, - > In/Out, In / Busy/Out, etc. > > Regardless of what complex presence information a user may have, there > will always be an initial binary decision (yes, you can > access presence > or no, you cannot). Because this decision must always be > made for each > and every subscription request which is made, it may be reasonable to > standardize how this will be done. > > -Dan > > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Rosen, Brian > Sent: Friday, July 13, 2001 10:44 AM > To: 'Jonathan Rosenberg' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > Let's start over. > > A and B are both UAs. I think we all agree on that. > You want a PS. I'll agree they are useful. If you > want a PS, then its a UAS to A. I want to talk > about how PS and B interact. > > I don't know if you would allow me to go there, but, > just for a moment, indulge me and let's talk about > A and B without PS. A wants to know B's presence. > Okay, so A subscribes to B, and B supplies > presence as NOTIFYies. This all works fine, although > it ignores how B authorizes A. In particular, > in order for B to authorize A, he needs credentials > for A (who are you). While the standard SIP headers > might be enough, in many cases, you need more > information about A. How do you get that? > > With my example, everything (except credentials) is > fine. In particular, B can send presence to A > because it's really B (B's real UA) that is the > source of the presence info, and we would all agree > that B the human interacts with B's UA in some > implementation dependent manner for B's UA to > find out the actual presence state. > > Are we okay here? > > Now let's put in the PS. In your model, just for now, > skip authorization, and let's just talk about how > B tells PS that B's presence state changed. > I can see two possibilities. The one I like is that > PS subscribes to B's presence. The other is that > there is a new header that is used for that purpose. > My way is real simple, takes no extension, and does > exactly what you want. When B changes his presence, > he does so on his UA (exactly as above), and Notifies > PS. PS, in turn, Notifies A. Simple, clean, effective. > > So what is PS? I claim it's a straightforward > B2BUA. Instead of subscribing directly to B, PS > subscribes to B and A (as well as any other authorized > watchers) subscribe to PS. > > Now, you introduce watcherinfo. I'm okay with that. > B subscribes to watcherinfo on PS, and PS Notifies B > of subscriptions. > > Now, back to authorization > > In several posts, I've stated that I'm interested in a > rich notion of presence. That covers a LOT of territory, > but let me give you a small example. Suppose I have > 3 states in my presence model In-Busy-Out. For > some watchers, I will give them one of these three > states. However, there are some people for whom I > don't want them to know that I'm in, but busy. They > only get two states - In/Out. This is all pretty easy > stuff. > > However, my authorization is not binary. I have to > tell PS which of the two models A gets. Two URLs > are not enough. > > So, authorization, I claim, is complex. You need > arbitrary credentials from A, and you need arbitrary outputs > from B. Thus, I claim, there is no sensible way to define the > authorization process between B and PS, or for that > matter, between A and PS in a standardized way. > > One way to help would be to at least tell A where > to go to at least FIND OUT how to get authorization. > Simply subscribing (attempting to subscribe) is not enough. > If you want to turn that around and say, fine, let's > also tell B how to authorize, I can't argue. > > Brian > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, July 13, 2001 10:03 AM > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > 'adam.roach@ericsson.com'; Ben Campbell > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > Well, I'm real confused. > > > 1. The "automata" you are talking about -- I don't understand > > > what role it has in the context of this discussion. We have > > > "servers" that have presence information and "clients" that > > > want to get it. The server is an entity operating on behalf of a > > > presentity. The client is an entity operating on behalf of a > > > watcher. In > > > SIP terms, we have a UAC and a UAS. > > > > Its more complex than that, Brian. > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > | | | > > | |SUB B's pres.winfo (1)| > > | |<---------------------| B's > > client turns on > > | |200 OK (2)| > > | |--------------------->| > > | |NOTIFY (3)| > > | |--------------------->| > > | |200 OK (4)| > > | |<---------------------| > > | | | > > |SUB B's pres (5) | | > > |----------------->| | > > |202 Accepted (6)| | > > |<-----------------|NOTIFY "A Pending" (9)| > > |NOTIFY B's pres(7)|--------------------->|B learns that A > > |<-----------------|200 OK (10)| subscribed > > |200 OK (8)|<---------------------| > > |----------------->| | > > | | | > > | | | > > | |Set policy (11)| > > | |<---------------------| > > | | | > > | | | > > | | | > > | | | > > > > Subscriber Presence Presentity > > A Server B > > > > > The UAS > > > is the agent of the presentity, and the UAC is the agent of > > > the watcher. Now, where is this automata? In the UAS? > > > The UAS is what the protocol defines, you seem to want to deal > > > with something that is not the UAS but is connecting to it. > > > > There is a presence server, which is a UAC for some > > transactions, and UAS > > for others. There is a subscriber A, which is a UAC for some > > transactions > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > presentity > > application for B, which is a UAC for some transactions > > (SUBSCRIBE to its > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > per transaction > > role. The presence server is the "agent" for B, in the sense > > that it accepts > > subscribes and generates notifies on B's behalf. How it finds > > out about the > > presence state is another orthogonal piece, not specified in > > the SUB/NOT > > mechanism. Typically, its through registrations or through > > direct upload of > > a presence document. > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > where the presentity and the watcher are both UACs and there > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > idea. If that is the model you are pushing, I want to push > > > back. The UAC is the agent of the presentity, the UAS is the > > > agent of the watcher, and the UAC doesn't need any protocol > > > to the presentity -- it "is" the presentity. > > > > I cannot map these statements to sensible definitions of > UAC and UAS, > > presentity or watcher. Please see above. > > > > > If you want > > > the presentity to be a UAC, then we need more than what we > > > are talking about on this thread - we need to standardize > > > how the UAC at the presentity tells the UAS how to change its > > > presence, and then we get into all sorts of issues about > > > how this model supports rich presence information (since it > > > requires that two UACs AND the UAS all have the same > > > capabilities). How the UAC interacts with the presentity > > > is not the place we standardize. It could be split into > > > a "client" and a "server", but the interactions between those > > > pieces are complex, and I don't see how we could standardize > > > them right now. > > > > I still cannot understand any of the above based on the > > definitions of UAC > > and UAS in the bis spec, and presentity, watcher, etc. > from rfc2778. > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > Yes, you get a message when someone puts you in his > > > friend list. However, what it is asking you seems to be > > > whether you want to put him in YOUR buddy list. In particular, > > > if you reject, you are still in his friend list, and he sees > > > your presence. > > > > No, thats not true. When I subscribe to someone, they appear > > in my buddy > > list, and the status is marked as "pending authorization" > > until the time > > that they provide authorization. Once that happens, I see their real > > presence. On the other side, when someone subscribes to me, I > > get a screen > > pop, which asks for "approve", "approve and add", or "reject". > > Approve/reject have the meanings we've been discussing - they > > approve or > > reject the subscription. "approve and add" approves the > > subscription, and > > also sends a subscription from me back to them, adding them > > to my buddy > > list. > > > > I've been using this tool for several years. I think I can > make these > > statements with soem confidence that they are correct. > > > > -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 ds708@columbia.edu Fri Jul 13 13:04:57 2001 Received: from kachifo.cc.columbia.edu (kachifo.cc.columbia.edu [128.59.59.172]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16126 for ; Fri, 13 Jul 2001 13:04:57 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by kachifo.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA15263; Fri, 13 Jul 2001 13:05:17 -0400 (EDT) From: "Daniel Starin" To: "'Daniel Starin'" , "'Rosen, Brian'" Cc: "'Jonathan Rosenberg'" , Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 13:05:01 -0400 Message-ID: <002101c10bbd$f7857e50$a1a20681@DSTARIN2> 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, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <002001c10bbd$19a9fde0$a1a20681@DSTARIN2> Importance: Normal Content-Length: 13637 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: Revised.... I hit send by accident... The difference is, when I authorize someone, the way that I interact with them may change throughout the time that the subscription exists. One minute I may want them to see detailed presence (IN / OUT / AWAY / BUSY) while the next minute I may want them to see OUT regardless of what my actual presence is. The fact is, for the most part, these decisions are based on what is happening currently, not what happens when the request for the subscription takes place. At the time of request, all that is usually known is Yes, you may subscribe, or no, you may not. If you happen to know that you also want to give the person a specific type of presence (IN / OUT) at that time than so be it, you can (after you have said Yes to their subscription). But many times, you will not know specifically how you want your presence to be distributed to those that subscribe to you at the moment they request a subscription. Thus a Yes/No authorization should be specified. Possibly a "what" should be specified as well but these two things should be distinct. As for credentials. I agree that some form of credentials must be specified for Yes / No authorization... Dan -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, July 13, 2001 12:05 PM To: 'Daniel Starin' Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization I don't agree. Authorization is specific - who and what. You can't split it up like that, or at least there is very little value in doing so. If I gave you a standardized way to say yes/no, but don't give you a standardized way to specify what, the implementation is just as proprietary. Also don't forget the credentials part. In order to even say yes/no, you need the credentials. Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 11:59 AM > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Brian, > > It seems that there are two different issues you are discussing. > > One is whether or not A (the watcher) may access any of B's presence > information (a binary decision) and the other is IF B indeed > allows A to > access presence information, what type of information will that be, - > In/Out, In / Busy/Out, etc. > > Regardless of what complex presence information a user may have, there > will always be an initial binary decision (yes, you can > access presence > or no, you cannot). Because this decision must always be > made for each > and every subscription request which is made, it may be reasonable to > standardize how this will be done. > > -Dan > > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Rosen, Brian > Sent: Friday, July 13, 2001 10:44 AM > To: 'Jonathan Rosenberg' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > Let's start over. > > A and B are both UAs. I think we all agree on that. > You want a PS. I'll agree they are useful. If you > want a PS, then its a UAS to A. I want to talk > about how PS and B interact. > > I don't know if you would allow me to go there, but, > just for a moment, indulge me and let's talk about > A and B without PS. A wants to know B's presence. > Okay, so A subscribes to B, and B supplies > presence as NOTIFYies. This all works fine, although > it ignores how B authorizes A. In particular, > in order for B to authorize A, he needs credentials > for A (who are you). While the standard SIP headers > might be enough, in many cases, you need more > information about A. How do you get that? > > With my example, everything (except credentials) is > fine. In particular, B can send presence to A > because it's really B (B's real UA) that is the > source of the presence info, and we would all agree > that B the human interacts with B's UA in some > implementation dependent manner for B's UA to > find out the actual presence state. > > Are we okay here? > > Now let's put in the PS. In your model, just for now, > skip authorization, and let's just talk about how > B tells PS that B's presence state changed. > I can see two possibilities. The one I like is that > PS subscribes to B's presence. The other is that > there is a new header that is used for that purpose. > My way is real simple, takes no extension, and does > exactly what you want. When B changes his presence, > he does so on his UA (exactly as above), and Notifies > PS. PS, in turn, Notifies A. Simple, clean, effective. > > So what is PS? I claim it's a straightforward > B2BUA. Instead of subscribing directly to B, PS > subscribes to B and A (as well as any other authorized > watchers) subscribe to PS. > > Now, you introduce watcherinfo. I'm okay with that. > B subscribes to watcherinfo on PS, and PS Notifies B > of subscriptions. > > Now, back to authorization > > In several posts, I've stated that I'm interested in a > rich notion of presence. That covers a LOT of territory, > but let me give you a small example. Suppose I have > 3 states in my presence model In-Busy-Out. For > some watchers, I will give them one of these three > states. However, there are some people for whom I > don't want them to know that I'm in, but busy. They > only get two states - In/Out. This is all pretty easy > stuff. > > However, my authorization is not binary. I have to > tell PS which of the two models A gets. Two URLs > are not enough. > > So, authorization, I claim, is complex. You need > arbitrary credentials from A, and you need arbitrary outputs > from B. Thus, I claim, there is no sensible way to define the > authorization process between B and PS, or for that > matter, between A and PS in a standardized way. > > One way to help would be to at least tell A where > to go to at least FIND OUT how to get authorization. > Simply subscribing (attempting to subscribe) is not enough. > If you want to turn that around and say, fine, let's > also tell B how to authorize, I can't argue. > > Brian > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, July 13, 2001 10:03 AM > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > 'adam.roach@ericsson.com'; Ben Campbell > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > 'adam.roach@ericsson.com'; Ben Campbell > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > Well, I'm real confused. > > > 1. The "automata" you are talking about -- I don't understand > > > what role it has in the context of this discussion. We have > > > "servers" that have presence information and "clients" that > > > want to get it. The server is an entity operating on behalf of a > > > presentity. The client is an entity operating on behalf of a > > > watcher. In > > > SIP terms, we have a UAC and a UAS. > > > > Its more complex than that, Brian. > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > | | | > > | |SUB B's pres.winfo (1)| > > | |<---------------------| B's > > client turns on > > | |200 OK (2)| > > | |--------------------->| > > | |NOTIFY (3)| > > | |--------------------->| > > | |200 OK (4)| > > | |<---------------------| > > | | | > > |SUB B's pres (5) | | > > |----------------->| | > > |202 Accepted (6)| | > > |<-----------------|NOTIFY "A Pending" (9)| > > |NOTIFY B's pres(7)|--------------------->|B learns that A > > |<-----------------|200 OK (10)| subscribed > > |200 OK (8)|<---------------------| > > |----------------->| | > > | | | > > | | | > > | |Set policy (11)| > > | |<---------------------| > > | | | > > | | | > > | | | > > | | | > > > > Subscriber Presence Presentity > > A Server B > > > > > The UAS > > > is the agent of the presentity, and the UAC is the agent of > > > the watcher. Now, where is this automata? In the UAS? > > > The UAS is what the protocol defines, you seem to want to deal > > > with something that is not the UAS but is connecting to it. > > > > There is a presence server, which is a UAC for some > > transactions, and UAS > > for others. There is a subscriber A, which is a UAC for some > > transactions > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > presentity > > application for B, which is a UAC for some transactions > > (SUBSCRIBE to its > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > per transaction > > role. The presence server is the "agent" for B, in the sense > > that it accepts > > subscribes and generates notifies on B's behalf. How it finds > > out about the > > presence state is another orthogonal piece, not specified in > > the SUB/NOT > > mechanism. Typically, its through registrations or through > > direct upload of > > a presence document. > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > where the presentity and the watcher are both UACs and there > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > idea. If that is the model you are pushing, I want to push > > > back. The UAC is the agent of the presentity, the UAS is the > > > agent of the watcher, and the UAC doesn't need any protocol > > > to the presentity -- it "is" the presentity. > > > > I cannot map these statements to sensible definitions of > UAC and UAS, > > presentity or watcher. Please see above. > > > > > If you want > > > the presentity to be a UAC, then we need more than what we > > > are talking about on this thread - we need to standardize > > > how the UAC at the presentity tells the UAS how to change its > > > presence, and then we get into all sorts of issues about > > > how this model supports rich presence information (since it > > > requires that two UACs AND the UAS all have the same > > > capabilities). How the UAC interacts with the presentity > > > is not the place we standardize. It could be split into > > > a "client" and a "server", but the interactions between those > > > pieces are complex, and I don't see how we could standardize > > > them right now. > > > > I still cannot understand any of the above based on the > > definitions of UAC > > and UAS in the bis spec, and presentity, watcher, etc. > from rfc2778. > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > Yes, you get a message when someone puts you in his > > > friend list. However, what it is asking you seems to be > > > whether you want to put him in YOUR buddy list. In particular, > > > if you reject, you are still in his friend list, and he sees > > > your presence. > > > > No, thats not true. When I subscribe to someone, they appear > > in my buddy > > list, and the status is marked as "pending authorization" > > until the time > > that they provide authorization. Once that happens, I see their real > > presence. On the other side, when someone subscribes to me, I > > get a screen > > pop, which asks for "approve", "approve and add", or "reject". > > Approve/reject have the meanings we've been discussing - they > > approve or > > reject the subscription. "approve and add" approves the > > subscription, and > > also sends a subscription from me back to them, adding them > > to my buddy > > list. > > > > I've been using this tool for several years. I think I can > make these > > statements with soem confidence that they are correct. > > > > -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 jdrosen@dynamicsoft.com Fri Jul 13 09:48:33 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15409 for ; Fri, 13 Jul 2001 09:48:32 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6DDloRX018113; Fri, 13 Jul 2001 09:47:50 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYC49A0>; Fri, 13 Jul 2001 09:48:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'Michael Hammer'" , Jonathan Rosenberg Cc: Jonathan Rosenberg , "'Rosen, Brian'" , Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 09:48:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 5372 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: > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, July 11, 2001 1:54 PM > To: Jonathan Rosenberg > Cc: Jonathan Rosenberg; 'Rosen, Brian'; Jonathan Rosenberg; > 'Boyer, D G > (Dave)'; 'adam.roach@ericsson.com'; Ben Campbell; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > At 01:36 PM 7/11/2001 -0400, Jonathan Rosenberg wrote: > > >How does the authorizer know whether there are subscriptions > waiting to be > >authorized? Sure, the system can send the authorizer email, > or an IM, but > >that means there is no way to manage that information on the > client side > >using an automata which queries the user, or applies local policy to > >generate an authorization. I'm interested in this primarily > because that is > >what systems do today. When I start Yahoo, it tells me who > has tried to > >subscribe, and allows me to accept/reject each of those. Are > we willing to > >say that a tool cannot be written that queries the user for > this, that the > >only way is to send email or IM or something else which is only > >interpretable by a human? Not that using IM or email is bad; > just that we > >may want to enable an automata to handle the information. > > I should have described the transaction there. I believe > that is related > to the watcherinfo stuff you were working on. I was viewing > that as part > of A above. Once you log into the system, the authentication > process sends > you a message indicating who requested subscription and your response > contains the authorize/deny per request. The key is that A, > B, and C are > independent transactions only related together by the system > application. I haven't been saying anything different!!! What I am proposing is that things look like this: | | | | |SUB B's pres.winfo (1)| | |<---------------------| B's client turns on | |200 OK (2)| | |--------------------->| | |NOTIFY (3)| | |--------------------->| | |200 OK (4)| | |<---------------------| | | | |SUB B's pres (5) | | |----------------->| | |202 Accepted (6)| | |<-----------------|NOTIFY "A Pending" (9)| |NOTIFY B's pres(7)|--------------------->|B learns that A |<-----------------|200 OK (10)| subscribed |200 OK (8)|<---------------------| |----------------->| | | | | | | | | |Set policy ? (11)| | |<---------------------| | | | | | | | | | | | | Subscriber Presence Presentity A Server B The SUBSCRIBE from the subscriber A is messages 5-8. The two transactions (SUB/202 and NOT/200) are totally independent from everything else. It does NOT wait on human intervention or anything else, PERIOD. It is regular, normal, SUB/NOT for presence, with each of the two transactions completing instantly. Before this subscription, when B's client was activated, it send a subscribe to the presence server, to watch to see who subscribers to B. Thats sequence (1)-(4), two SIP transactions. Now, when A subscribes, INDEPENDENTLY of the processing that subscription, the presence server sends a NOTIFY to B, telling them of the change (messages 9-10). Now, after that there are no pending transactions, or anything like that. At some point, indefinitely into the future, B can send policy about A to the presence server, message(s) 11. I've been arguing that we should NOT specify SIP for this, but rather, view this as a web application that sets potentially complex policy. However, I have also been arguing that it would be nice to allow this to provide the most common and basic function, approval/rejection, without a web browser. This would be needed, for example, if I want the application software at B to provide a screen pop when A subscribes, with two buttons "accept" and "reject". Clicking either approves or rejects the subscription. Thats still an HTTP request, I am arguing, but it doesn't require B to have a user filling in a form. The client application at B can figure out what HTTP form POST request to send to approve or reject, based on information in the NOTIFY, message (9). -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 From Vasilis.Polychronidis@Openwave.com Fri Jul 13 13:26:24 2001 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 NAA16264 for ; Fri, 13 Jul 2001 13:26:23 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010713172553.YHXI24568.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Fri, 13 Jul 2001 12:25:53 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010713172552.DXCN9573.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Fri, 13 Jul 2001 12:25:52 -0500 Message-ID: <3B4F2F38.6116FE3B@Openwave.com> Date: Fri, 13 Jul 2001 10:26:17 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: <4FBEA8857476D311A03300204840E1CF04465798@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 14198 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: Ok I think everybody is in agreement with one (being able to subscribe to watcher info as optional feature) . In principle I agree with you on 3 --> authorization can be very complicated however Jonathan is proposing a simple use case and a simple optional way of doing this. I also understand your hesitation in 2 of using SIP operations as a notification mechanism of authorization actions. So you are asking do we want to mix SIP and authorization notifications? In order for me to answer I have to ask another question since I have not read all the SIP related RFC/IDs: Is this (authorization related notifications) being proposed (via an ID) or done in some SIP related RFC? If the answer is yes well in that case the SIP community has answered your question. If the answer is No then we may need to take this question to the SIP mailing list and ask is this a good design? BR, Vasilis Polychronidis "Rosen, Brian" wrote: > Vasilis > > There are a couple of issues: > 1. Can you subscribe to your own something that Notifies you > when a watcher subscribes? > I say, sure, why not, fine idea. > I think the concept that you CAN get notification > when someone actually starts looking at your > presence info is a good one. As you say, it's > optional to subscribe. > Note that this has nothing to do, in my mind, with > authorization > > 2. Can you subscribe to something that gets you Notification > that you have some authorization effort to make? > I say, not interesting. The process of authorization > is within an implementation of a UAS (the presence server, > as an endpoint in a SIP system, is a UAS) and is not > subject to standardization. The only way this isn't > true is if the presentity is represented as a UAC, and > the PS is a UAS, and then you need a standardized way that > the presentity's UAC conveys authorization and presence > setting information to the PS's UAS. I think that is > a bad design idea. > > 3. Is a pair of URLs the way to represent an accept/deny > authorization decision? > I'd say, no, not by a whole lot. To make an authorization > decision, the presentity needs to be presented with > credentials (who are you that is asking to be authorized). > Presence information may come in several forms, and you may > need to specify what form. A decision on presence may > not be binary (it may be, for example, which form is > allowed). So to authorize, you have to present a variable > amount of information from the watcher, and you have to > accept a variable amount of information from the presentity. > While I happen to think that a web based GUI to do this > is a very fine idea, I think that you can't standardize it, > at least now. > > Brian > > > -----Original Message----- > > From: Vasilis Polychronidis > > [mailto:Vasilis.Polychronidis@openwave.com] > > Sent: Thursday, July 12, 2001 6:38 PM > > To: Jonathan Rosenberg; 'Rosen, Brian' > > Cc: 'Boyer, D G (Dave)'; 'adam.roach@ericsson.com'; Ben Campbell; > > simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > Hi Brian, > > Looking through this issue I tend to agree with Jonathan's proposal. > > It is really important that the method described by Jonathan > > (Subscribing to > > your watcher info) > > is optional. > > As Jonathan said B has to explicitly request it (subscribe to > > his watcher info). > > > > In addition we should not mandate the Presence Server to > > accept "watcher type": subscriptions. > > So the proposed feature is an optional one. > > Is this acceptable to you Brian? > > > > I also agree with the use of URLs for accepting/rejecting a > > subscription. > > > > BR, > > > > Vasilis Polychronidis > > > > Jonathan Rosenberg wrote: > > > > > Brian, > > > > > > Now I understand what you are saying. I want there to be a > > way for B to find > > > out when someone subscribes to him, so he can, if desired, provide > > > authorization. You don't want to ever tell B when someone > > subscribes; > > > rather, you tell A that they should visit some web page, > > and maybe that > > > allows them to send email to B asking for authorization. > > > > > > So, let me make a few comments in response: > > > > > > 1. this bit about letting B know is **NOT** part of the > > main presence > > > specification whatsoever. All that specification says is > > "the server obtains > > > authorization in some fashion, not specified". The > > mechanism that allows B > > > to find out who subscribes is separate, and opt-in, not > > opt-out. That is, B > > > has to explicitly request to find out who subscribed to > > him. If B does > > > nothing, B finds out nothing. Presence servers don't have > > to provide the > > > function either. > > > > > > 2. why even worry about this? Well, all of the major IM and > > presence systems > > > do this today. We should at least be able to provide the > > same application > > > interface thats available, if users and their providers want it. > > > > > > 3. I agree with you that defining authorization policy is a back-end > > > mechanism, and typically not real time. Thats why I have > > been arguing that > > > the notification to B about the subscriber contain http > > URLs that can be > > > used to accept/reject, and those URLs are part of the > > back-end non-real-time > > > application. They facilitate a screen pop to a slim phone > > that says "approve > > > or reject?" and thus allows setting of simple policies > > right away without a > > > browser. > > > > > > The problem that has been observed with your alternate > > approach, of telling > > > A about a URL, is that this allows A to learn whether they have been > > > approved or rejected. Paul argues that this knowledge can > > be learned anyway, > > > by sending an INVITE and seeing whether the call is > > accepted or rejected. > > > Not necessarily; I can set up a service to achieve the same > > effect for > > > voice. If someone calls me, and I don't want to talk to > > them, instead of > > > them getting a "600 I hate you" response, the server can > > simply let the > > > phone ring indefinitely, so that the caller can't tell > > whether I'm not > > > there, or whether they've been rejected. > > > > > > -Jonathan R. > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Tuesday, July 10, 2001 6:18 PM > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > Cc: simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > Yes, I understand what you are proposing; I think it > > > > is not appropriate to confuse the concept of > > > > authorization (will I allow you to subscribe) from > > > > the actual subscription. You want to do that - you > > > > want the very first action to be a subscribe. > > > > If the server for B can immediately confirm a new > > > > authorization, because there is some policy in place > > > > that lets it do so, you propose to let that subscription > > > > succeed. You want to talk about what happens when > > > > it fails. > > > > > > > > I want to completely remove authorization from the protocol; > > > > Subscriptions are then only how you connect to the > > > > presentity's server. It succeeds if you are authorized, > > > > fails if you aren't (also fails for other reasons). > > > > I see no win at all to have the protocol deal with > > > > authorization. > > > > > > > > So, with that in mind, let's look at what you propose: > > > > > > > > > This is not right. The party that approves or denies the > > > > > subscription is NOT > > > > > the party that has subscribed. > > > > We all agree, B is the approver. B's server has the > > authorization. > > > > A subscribes. It succeeds only if B has given approval. > > > > > > > > > > > > > > Here is the scenario. A subsciber, A, subscribes to B. For > > > > > any subscription > > > > > to B to be approved, B has to have given authorization for > > > > > it. However, > > > > > there is currently no authorization policy specified by B > > > > > about whether A > > > > > can subscribe. So, when A's subscription is received by the > > > > server, a > > > > > response is generated, but the subscription is not activated. > > > > I claim if B has no authorization for A, then A's subscription > > > > request is denied, and that is the end of the story. > > > > So I agree you get a response, and that is fail, with > > > > a referral (URL). > > > > > > > > If A wants to get approval, he might consult the URL to find > > > > a web page that might allow him to be authorized. > > > > > > > > >Now, the > > > > > problem is that the server needs to know whether B approves this > > > > > subscription. It might just wait, hoping that someday, B sets > > > > > a policy for > > > > > user A. However, that doesn't work well. What you want is > > > > > some way to prod > > > > > B, and say to him, "hey, A tried to subscribe, please set a > > > > > policy for A". > > > > > Then, A can go to some web page, or whatver the backend > > > > > policy mechanism is, > > > > > and set up policy. > > > > Wrong end. You don't want B to take action just because > > > > A tried to subscribe. Great opportunity to drive B nuts. > > > > What you want to do is tell A how to get authorized. > > > > A is the one who wants to get authorized, and we can tell > > > > him how to do it. There is no win in telling B how to > > > > run his own authorization mechanism. Mostly, there is > > > > no win in prodding B based on a subscription attempt for A > > > > when A isn't even authorized. > > > > > > > > Importantly, the subscription request failed. > > > > If B's server eventually gets some authorization info, > > > > it has nothing to do with it but wait until A tries > > > > to subscribe again. > > > > > > > > > > > > > > So, to provide this "prodding" capability, we've agreed to > > > > > use a new event > > > > > package, called watcherinfo. The idea is that B can subscribe > > > > > to his own set > > > > > of watchers, so that when it changes (for example, when A > > > > > subscribes), B > > > > > gets notified. B can then go to the web page and upload > > approval. > > > > This seems wacky to me. Why should the protocol prod B? > > > > Why should the protocol do anything to support authorization - > > > > that is a non-real-time issue. Sending B an email may be a more > > > > appropriate thing to do, but that should be because A asks for > > > > authorization. The question is, how does A do that? The point > > > > is that since it's B's decision, B may need arbitrary information > > > > from A before he will authorize. Therefore, A needs to use B's > > > > authorization mechanism. You can't make A's user interface > > > > know how to give B what he needs to authorize. A web page that > > > > B creates is at least one way to do that. > > > > > > > > >The > > > > > additional thing we are debating, is whether there should > > > > be an actual > > > > > protocol mechanism for conveying that approval/rejection to > > > > > the server. I > > > > > have proposed that the NOTIFY that gets sent to B when A > > > > > subscribes have two > > > > > URLs specified by the server, one which approves the > > > > > subscription from A, > > > > > and one which rejects. Others have proposed that we specify a > > > > > protocol for B > > > > > to upload approval in a presence document. Others want > > to specify > > > > > SIP/SOAP/WSDL for this. > > > > Repeating myself, there is no point in having protocol support > > > > for human-in-the-loop messaging. While this might be something > > > > that is worth specifying so that B's agent can talk to B's > > > > server, I suspect that at least for now, we can safely leave this > > > > out of the spec because it has nothing to do with A and B. > > > > You are talking about how B the human interacts with B's server; > > > > not something I think is worth standardizing. > > > > > > > > > > > > > > All of this is different from what A sees when A's > > > > > subscription to B is > > > > > rejected, approved, or marked as "pending" because there is > > > > > no policy. We > > > > > have already agreed some time back that in all cases, the > > > > subscription > > > > > request is immediately responded to with a 202 and a NOTIFY > > > > > with the status. > > > > > If the subscription was accepted, the status is correct. If > > > > > the subscription > > > > > failed, or was marked as pending, the NOTIFY contains > > > > > syntactically correct > > > > > but invalid data. This way, the subscriber can't know what > > > > > happened to their > > > > > subscription. > > > > I think we are in agreement here. A doesn't get to know if > > > > he is authorized or not, subscription just fails. > > > > > > > > In particular, when B finally does authorize A, A has to > > > > "just know" to try subscribing again; we don't help him. > > > > > > > > It's always possible that the authorization mechanism tells > > > > A, say by email. > > > > > > > > Brian > > > > > > > > > > > > > > > --- > > > 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 Brian.Rosen@marconi.com Fri Jul 13 13:46:38 2001 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 NAA16348 for ; Fri, 13 Jul 2001 13:46:38 -0400 (EDT) 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 NAA27794; Fri, 13 Jul 2001 13:46:32 -0400 (EDT) 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 NAA21319; Fri, 13 Jul 2001 13:46:34 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <35STYQFZ>; Fri, 13 Jul 2001 13:46:33 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044657AA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Daniel Starin'" Cc: "'Jonathan Rosenberg'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 13:46:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 16629 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: Daniel I suppose it's a matter of semantics, but I would claim that you change authorization to change what information is revealed. Whether you do it before subscription, or after it, you are changing your authorization. I also think you made my point. Authorization is complex, and standardizing it, at this time, is unwise. Of what use is it to the PS if I give it a yes/no, and don't give it a what? So you can accept the subscription but not send a Notify? Not interesting methinks. Besides, as you observe, even yes/no is really transient (yes, at the moment, but I could change my mind). All the more reason to get it out of the protocol. Even Jonathan proposes to accept the subscription without authorization. We are talking about a complex interaction between the watcher and the PS as well as the presentity and the PS. Until there is a much greater degree of consensus on how that interaction takes place, I don't see the value in specifying any of it. Jonathan wants to standardize a simple yes/no authorization so that it can be done in the GUI of B's UA, and not take a browser. I think that such an idea is far too limiting to be useful, and encourages lowest common denominator thinking. It doesn't even give you the basic notion of presenting the name of the watcher - all you get is the existing SIP headers, which would in many cases be a cryptic email identifier. I'd much rather go the other direction and start talking about sending an XML credential in the authorization request, and an XML policy in the authorization reply. BTW, I wanted to make sure that everyone agrees that authorization is not authentication; if the PS requires authentication for the subscription (and it ought to), then authentication must take place before the subscribe will be acted upon. All authorization is dealing with is what B will let you see, and it ranges from nothing to a lot. Authentication is proving to the satisfaction of the PS that you are who you claim to be. Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 1:05 PM > To: 'Daniel Starin'; 'Rosen, Brian' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Revised.... I hit send by accident... > > The difference is, when I authorize someone, the way that I interact > with them may change throughout the time that the subscription exists. > One minute I may want them to see detailed presence (IN / OUT / > AWAY / BUSY) while the next minute I may want them to see OUT > regardless > of what my actual presence is. The fact is, for the most part, these > decisions are based on what is happening currently, not what happens > when the request for the subscription takes place. At the time of > request, all that is usually known is Yes, you may subscribe, > or no, you > may not. If you happen to know that you also want to give > the person a > specific type of presence (IN / OUT) at that time than so be it, you > can (after you have said Yes to their subscription). But many times, > you will not know specifically how you want your presence to be > distributed to those that subscribe to you at the moment they > request a > subscription. > > Thus a Yes/No authorization should be specified. Possibly a "what" > should be specified as well but these two things should be distinct. > > As for credentials. I agree that some form of credentials must be > specified for Yes / No authorization... > > Dan > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, July 13, 2001 12:05 PM > To: 'Daniel Starin' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > I don't agree. Authorization is specific - who and what. > You can't split it up like that, or at least there is very > little value in doing so. If I gave you a standardized way > to say yes/no, but don't give you a standardized way to > specify what, the implementation is just as proprietary. > > Also don't forget the credentials part. In order to even say > yes/no, you need the credentials. > > Brian > > > -----Original Message----- > > From: Daniel Starin [mailto:ds708@columbia.edu] > > Sent: Friday, July 13, 2001 11:59 AM > > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Brian, > > > > It seems that there are two different issues you are discussing. > > > > One is whether or not A (the watcher) may access any of B's presence > > information (a binary decision) and the other is IF B indeed > > allows A to > > access presence information, what type of information will > that be, - > > In/Out, In / Busy/Out, etc. > > > > Regardless of what complex presence information a user may > have, there > > will always be an initial binary decision (yes, you can > > access presence > > or no, you cannot). Because this decision must always be > > made for each > > and every subscription request which is made, it may be > reasonable to > > standardize how this will be done. > > > > -Dan > > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > Rosen, Brian > > Sent: Friday, July 13, 2001 10:44 AM > > To: 'Jonathan Rosenberg' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > Let's start over. > > > > A and B are both UAs. I think we all agree on that. > > You want a PS. I'll agree they are useful. If you > > want a PS, then its a UAS to A. I want to talk > > about how PS and B interact. > > > > I don't know if you would allow me to go there, but, > > just for a moment, indulge me and let's talk about > > A and B without PS. A wants to know B's presence. > > Okay, so A subscribes to B, and B supplies > > presence as NOTIFYies. This all works fine, although > > it ignores how B authorizes A. In particular, > > in order for B to authorize A, he needs credentials > > for A (who are you). While the standard SIP headers > > might be enough, in many cases, you need more > > information about A. How do you get that? > > > > With my example, everything (except credentials) is > > fine. In particular, B can send presence to A > > because it's really B (B's real UA) that is the > > source of the presence info, and we would all agree > > that B the human interacts with B's UA in some > > implementation dependent manner for B's UA to > > find out the actual presence state. > > > > Are we okay here? > > > > Now let's put in the PS. In your model, just for now, > > skip authorization, and let's just talk about how > > B tells PS that B's presence state changed. > > I can see two possibilities. The one I like is that > > PS subscribes to B's presence. The other is that > > there is a new header that is used for that purpose. > > My way is real simple, takes no extension, and does > > exactly what you want. When B changes his presence, > > he does so on his UA (exactly as above), and Notifies > > PS. PS, in turn, Notifies A. Simple, clean, effective. > > > > So what is PS? I claim it's a straightforward > > B2BUA. Instead of subscribing directly to B, PS > > subscribes to B and A (as well as any other authorized > > watchers) subscribe to PS. > > > > Now, you introduce watcherinfo. I'm okay with that. > > B subscribes to watcherinfo on PS, and PS Notifies B > > of subscriptions. > > > > Now, back to authorization > > > > In several posts, I've stated that I'm interested in a > > rich notion of presence. That covers a LOT of territory, > > but let me give you a small example. Suppose I have > > 3 states in my presence model In-Busy-Out. For > > some watchers, I will give them one of these three > > states. However, there are some people for whom I > > don't want them to know that I'm in, but busy. They > > only get two states - In/Out. This is all pretty easy > > stuff. > > > > However, my authorization is not binary. I have to > > tell PS which of the two models A gets. Two URLs > > are not enough. > > > > So, authorization, I claim, is complex. You need > > arbitrary credentials from A, and you need arbitrary outputs > > from B. Thus, I claim, there is no sensible way to define the > > authorization process between B and PS, or for that > > matter, between A and PS in a standardized way. > > > > One way to help would be to at least tell A where > > to go to at least FIND OUT how to get authorization. > > Simply subscribing (attempting to subscribe) is not enough. > > If you want to turn that around and say, fine, let's > > also tell B how to authorize, I can't argue. > > > > Brian > > > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Friday, July 13, 2001 10:03 AM > > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > > 'adam.roach@ericsson.com'; Ben Campbell > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > Cc: simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > Well, I'm real confused. > > > > 1. The "automata" you are talking about -- I don't understand > > > > what role it has in the context of this discussion. We have > > > > "servers" that have presence information and "clients" that > > > > want to get it. The server is an entity operating on > behalf of a > > > > presentity. The client is an entity operating on behalf of a > > > > watcher. In > > > > SIP terms, we have a UAC and a UAS. > > > > > > Its more complex than that, Brian. > > > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > > > > > | | | > > > | |SUB B's pres.winfo (1)| > > > | |<---------------------| B's > > > client turns on > > > | |200 OK (2)| > > > | |--------------------->| > > > | |NOTIFY (3)| > > > | |--------------------->| > > > | |200 OK (4)| > > > | |<---------------------| > > > | | | > > > |SUB B's pres (5) | | > > > |----------------->| | > > > |202 Accepted (6)| | > > > |<-----------------|NOTIFY "A Pending" (9)| > > > |NOTIFY B's pres(7)|--------------------->|B > learns that A > > > |<-----------------|200 OK (10)| > subscribed > > > |200 OK (8)|<---------------------| > > > |----------------->| | > > > | | | > > > | | | > > > | |Set policy (11)| > > > | |<---------------------| > > > | | | > > > | | | > > > | | | > > > | | | > > > > > > Subscriber Presence Presentity > > > A Server B > > > > > > > The UAS > > > > is the agent of the presentity, and the UAC is the agent of > > > > the watcher. Now, where is this automata? In the UAS? > > > > The UAS is what the protocol defines, you seem to want to deal > > > > with something that is not the UAS but is connecting to it. > > > > > > There is a presence server, which is a UAC for some > > > transactions, and UAS > > > for others. There is a subscriber A, which is a UAC for some > > > transactions > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > > presentity > > > application for B, which is a UAC for some transactions > > > (SUBSCRIBE to its > > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > > per transaction > > > role. The presence server is the "agent" for B, in the sense > > > that it accepts > > > subscribes and generates notifies on B's behalf. How it finds > > > out about the > > > presence state is another orthogonal piece, not specified in > > > the SUB/NOT > > > mechanism. Typically, its through registrations or through > > > direct upload of > > > a presence document. > > > > > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > > where the presentity and the watcher are both UACs and there > > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > > idea. If that is the model you are pushing, I want to push > > > > back. The UAC is the agent of the presentity, the UAS is the > > > > agent of the watcher, and the UAC doesn't need any protocol > > > > to the presentity -- it "is" the presentity. > > > > > > I cannot map these statements to sensible definitions of > > UAC and UAS, > > > presentity or watcher. Please see above. > > > > > > > If you want > > > > the presentity to be a UAC, then we need more than what we > > > > are talking about on this thread - we need to standardize > > > > how the UAC at the presentity tells the UAS how to change its > > > > presence, and then we get into all sorts of issues about > > > > how this model supports rich presence information (since it > > > > requires that two UACs AND the UAS all have the same > > > > capabilities). How the UAC interacts with the presentity > > > > is not the place we standardize. It could be split into > > > > a "client" and a "server", but the interactions between those > > > > pieces are complex, and I don't see how we could standardize > > > > them right now. > > > > > > I still cannot understand any of the above based on the > > > definitions of UAC > > > and UAS in the bis spec, and presentity, watcher, etc. > > from rfc2778. > > > > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > > Yes, you get a message when someone puts you in his > > > > friend list. However, what it is asking you seems to be > > > > whether you want to put him in YOUR buddy list. In particular, > > > > if you reject, you are still in his friend list, and he sees > > > > your presence. > > > > > > No, thats not true. When I subscribe to someone, they appear > > > in my buddy > > > list, and the status is marked as "pending authorization" > > > until the time > > > that they provide authorization. Once that happens, I see > their real > > > presence. On the other side, when someone subscribes to me, I > > > get a screen > > > pop, which asks for "approve", "approve and add", or "reject". > > > Approve/reject have the meanings we've been discussing - they > > > approve or > > > reject the subscription. "approve and add" approves the > > > subscription, and > > > also sends a subscription from me back to them, adding them > > > to my buddy > > > list. > > > > > > I've been using this tool for several years. I think I can > > make these > > > statements with soem confidence that they are correct. > > > > > > -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 ds708@columbia.edu Fri Jul 13 14:37:11 2001 Received: from menyapa.cc.columbia.edu (menyapa.cc.columbia.edu [128.59.59.38]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16564 for ; Fri, 13 Jul 2001 14:37:10 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by menyapa.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA25622; Fri, 13 Jul 2001 14:37:18 -0400 (EDT) From: "Daniel Starin" To: "'Rosen, Brian'" Cc: "'Jonathan Rosenberg'" , Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 14:37:17 -0400 Message-ID: <002a01c10bca$d9ca55e0$a1a20681@DSTARIN2> 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, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4FBEA8857476D311A03300204840E1CF044657AA@whq-msgusr-02.pit.comms.marconi.com> Importance: Normal Content-Length: 17846 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: If I understand correctly, you and Jonathan have come to a consensus that an initial Notify (specifying presence information) should be given without authorization? This seems to me to be similar to the AIM model in which user A may add user B to a buddy list without authorization. User B may later set a specific policy on user A (like blocking them). If this is the case, I disagree with both of you and I believe that rfc2779 (the presence requirements) does as well. It specifies.. "The principle controlling a PRESENTITY MUST be able to control which WATCHERS can observe that PRESENTITY's PRESENCE INFORMATION" ... By allowing any random watcher to access even one Notify without authorization, this requirement is not met... Dan -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Rosen, Brian Sent: Friday, July 13, 2001 1:46 PM To: 'Daniel Starin' Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Daniel I suppose it's a matter of semantics, but I would claim that you change authorization to change what information is revealed. Whether you do it before subscription, or after it, you are changing your authorization. I also think you made my point. Authorization is complex, and standardizing it, at this time, is unwise. Of what use is it to the PS if I give it a yes/no, and don't give it a what? So you can accept the subscription but not send a Notify? Not interesting methinks. Besides, as you observe, even yes/no is really transient (yes, at the moment, but I could change my mind). All the more reason to get it out of the protocol. Even Jonathan proposes to accept the subscription without authorization. We are talking about a complex interaction between the watcher and the PS as well as the presentity and the PS. Until there is a much greater degree of consensus on how that interaction takes place, I don't see the value in specifying any of it. Jonathan wants to standardize a simple yes/no authorization so that it can be done in the GUI of B's UA, and not take a browser. I think that such an idea is far too limiting to be useful, and encourages lowest common denominator thinking. It doesn't even give you the basic notion of presenting the name of the watcher - all you get is the existing SIP headers, which would in many cases be a cryptic email identifier. I'd much rather go the other direction and start talking about sending an XML credential in the authorization request, and an XML policy in the authorization reply. BTW, I wanted to make sure that everyone agrees that authorization is not authentication; if the PS requires authentication for the subscription (and it ought to), then authentication must take place before the subscribe will be acted upon. All authorization is dealing with is what B will let you see, and it ranges from nothing to a lot. Authentication is proving to the satisfaction of the PS that you are who you claim to be. Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 1:05 PM > To: 'Daniel Starin'; 'Rosen, Brian' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Revised.... I hit send by accident... > > The difference is, when I authorize someone, the way that I interact > with them may change throughout the time that the subscription exists. > One minute I may want them to see detailed presence (IN / OUT / > AWAY / BUSY) while the next minute I may want them to see OUT > regardless > of what my actual presence is. The fact is, for the most part, these > decisions are based on what is happening currently, not what happens > when the request for the subscription takes place. At the time of > request, all that is usually known is Yes, you may subscribe, > or no, you > may not. If you happen to know that you also want to give > the person a > specific type of presence (IN / OUT) at that time than so be it, you > can (after you have said Yes to their subscription). But many times, > you will not know specifically how you want your presence to be > distributed to those that subscribe to you at the moment they > request a > subscription. > > Thus a Yes/No authorization should be specified. Possibly a "what" > should be specified as well but these two things should be distinct. > > As for credentials. I agree that some form of credentials must be > specified for Yes / No authorization... > > Dan > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, July 13, 2001 12:05 PM > To: 'Daniel Starin' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > I don't agree. Authorization is specific - who and what. > You can't split it up like that, or at least there is very > little value in doing so. If I gave you a standardized way > to say yes/no, but don't give you a standardized way to > specify what, the implementation is just as proprietary. > > Also don't forget the credentials part. In order to even say > yes/no, you need the credentials. > > Brian > > > -----Original Message----- > > From: Daniel Starin [mailto:ds708@columbia.edu] > > Sent: Friday, July 13, 2001 11:59 AM > > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Brian, > > > > It seems that there are two different issues you are discussing. > > > > One is whether or not A (the watcher) may access any of B's presence > > information (a binary decision) and the other is IF B indeed > > allows A to > > access presence information, what type of information will > that be, - > > In/Out, In / Busy/Out, etc. > > > > Regardless of what complex presence information a user may > have, there > > will always be an initial binary decision (yes, you can > > access presence > > or no, you cannot). Because this decision must always be > > made for each > > and every subscription request which is made, it may be > reasonable to > > standardize how this will be done. > > > > -Dan > > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > Rosen, Brian > > Sent: Friday, July 13, 2001 10:44 AM > > To: 'Jonathan Rosenberg' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > Let's start over. > > > > A and B are both UAs. I think we all agree on that. > > You want a PS. I'll agree they are useful. If you > > want a PS, then its a UAS to A. I want to talk > > about how PS and B interact. > > > > I don't know if you would allow me to go there, but, > > just for a moment, indulge me and let's talk about > > A and B without PS. A wants to know B's presence. > > Okay, so A subscribes to B, and B supplies > > presence as NOTIFYies. This all works fine, although > > it ignores how B authorizes A. In particular, > > in order for B to authorize A, he needs credentials > > for A (who are you). While the standard SIP headers > > might be enough, in many cases, you need more > > information about A. How do you get that? > > > > With my example, everything (except credentials) is > > fine. In particular, B can send presence to A > > because it's really B (B's real UA) that is the > > source of the presence info, and we would all agree > > that B the human interacts with B's UA in some > > implementation dependent manner for B's UA to > > find out the actual presence state. > > > > Are we okay here? > > > > Now let's put in the PS. In your model, just for now, > > skip authorization, and let's just talk about how > > B tells PS that B's presence state changed. > > I can see two possibilities. The one I like is that > > PS subscribes to B's presence. The other is that > > there is a new header that is used for that purpose. > > My way is real simple, takes no extension, and does > > exactly what you want. When B changes his presence, > > he does so on his UA (exactly as above), and Notifies > > PS. PS, in turn, Notifies A. Simple, clean, effective. > > > > So what is PS? I claim it's a straightforward > > B2BUA. Instead of subscribing directly to B, PS > > subscribes to B and A (as well as any other authorized > > watchers) subscribe to PS. > > > > Now, you introduce watcherinfo. I'm okay with that. > > B subscribes to watcherinfo on PS, and PS Notifies B > > of subscriptions. > > > > Now, back to authorization > > > > In several posts, I've stated that I'm interested in a > > rich notion of presence. That covers a LOT of territory, > > but let me give you a small example. Suppose I have > > 3 states in my presence model In-Busy-Out. For > > some watchers, I will give them one of these three > > states. However, there are some people for whom I > > don't want them to know that I'm in, but busy. They > > only get two states - In/Out. This is all pretty easy > > stuff. > > > > However, my authorization is not binary. I have to > > tell PS which of the two models A gets. Two URLs > > are not enough. > > > > So, authorization, I claim, is complex. You need > > arbitrary credentials from A, and you need arbitrary outputs > > from B. Thus, I claim, there is no sensible way to define the > > authorization process between B and PS, or for that > > matter, between A and PS in a standardized way. > > > > One way to help would be to at least tell A where > > to go to at least FIND OUT how to get authorization. > > Simply subscribing (attempting to subscribe) is not enough. > > If you want to turn that around and say, fine, let's > > also tell B how to authorize, I can't argue. > > > > Brian > > > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Friday, July 13, 2001 10:03 AM > > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > > 'adam.roach@ericsson.com'; Ben Campbell > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > Cc: simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > Well, I'm real confused. > > > > 1. The "automata" you are talking about -- I don't understand > > > > what role it has in the context of this discussion. We have > > > > "servers" that have presence information and "clients" that > > > > want to get it. The server is an entity operating on > behalf of a > > > > presentity. The client is an entity operating on behalf of a > > > > watcher. In > > > > SIP terms, we have a UAC and a UAS. > > > > > > Its more complex than that, Brian. > > > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > > > > > | | | > > > | |SUB B's pres.winfo (1)| > > > | |<---------------------| B's > > > client turns on > > > | |200 OK (2)| > > > | |--------------------->| > > > | |NOTIFY (3)| > > > | |--------------------->| > > > | |200 OK (4)| > > > | |<---------------------| > > > | | | > > > |SUB B's pres (5) | | > > > |----------------->| | > > > |202 Accepted (6)| | > > > |<-----------------|NOTIFY "A Pending" (9)| > > > |NOTIFY B's pres(7)|--------------------->|B > learns that A > > > |<-----------------|200 OK (10)| > subscribed > > > |200 OK (8)|<---------------------| > > > |----------------->| | > > > | | | > > > | | | > > > | |Set policy (11)| > > > | |<---------------------| > > > | | | > > > | | | > > > | | | > > > | | | > > > > > > Subscriber Presence Presentity > > > A Server B > > > > > > > The UAS > > > > is the agent of the presentity, and the UAC is the agent of > > > > the watcher. Now, where is this automata? In the UAS? > > > > The UAS is what the protocol defines, you seem to want to deal > > > > with something that is not the UAS but is connecting to it. > > > > > > There is a presence server, which is a UAC for some > > > transactions, and UAS > > > for others. There is a subscriber A, which is a UAC for some > > > transactions > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > > presentity > > > application for B, which is a UAC for some transactions > > > (SUBSCRIBE to its > > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > > per transaction > > > role. The presence server is the "agent" for B, in the sense > > > that it accepts > > > subscribes and generates notifies on B's behalf. How it finds > > > out about the > > > presence state is another orthogonal piece, not specified in > > > the SUB/NOT > > > mechanism. Typically, its through registrations or through > > > direct upload of > > > a presence document. > > > > > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > > where the presentity and the watcher are both UACs and there > > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > > idea. If that is the model you are pushing, I want to push > > > > back. The UAC is the agent of the presentity, the UAS is the > > > > agent of the watcher, and the UAC doesn't need any protocol > > > > to the presentity -- it "is" the presentity. > > > > > > I cannot map these statements to sensible definitions of > > UAC and UAS, > > > presentity or watcher. Please see above. > > > > > > > If you want > > > > the presentity to be a UAC, then we need more than what we > > > > are talking about on this thread - we need to standardize > > > > how the UAC at the presentity tells the UAS how to change its > > > > presence, and then we get into all sorts of issues about > > > > how this model supports rich presence information (since it > > > > requires that two UACs AND the UAS all have the same > > > > capabilities). How the UAC interacts with the presentity > > > > is not the place we standardize. It could be split into > > > > a "client" and a "server", but the interactions between those > > > > pieces are complex, and I don't see how we could standardize > > > > them right now. > > > > > > I still cannot understand any of the above based on the > > > definitions of UAC > > > and UAS in the bis spec, and presentity, watcher, etc. > > from rfc2778. > > > > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > > Yes, you get a message when someone puts you in his > > > > friend list. However, what it is asking you seems to be > > > > whether you want to put him in YOUR buddy list. In particular, > > > > if you reject, you are still in his friend list, and he sees > > > > your presence. > > > > > > No, thats not true. When I subscribe to someone, they appear > > > in my buddy > > > list, and the status is marked as "pending authorization" > > > until the time > > > that they provide authorization. Once that happens, I see > their real > > > presence. On the other side, when someone subscribes to me, I > > > get a screen > > > pop, which asks for "approve", "approve and add", or "reject". > > > Approve/reject have the meanings we've been discussing - they > > > approve or > > > reject the subscription. "approve and add" approves the > > > subscription, and > > > also sends a subscription from me back to them, adding them > > > to my buddy > > > list. > > > > > > I've been using this tool for several years. I think I can > > make these > > > statements with soem confidence that they are correct. > > > > > > -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 Brian.Rosen@marconi.com Fri Jul 13 14:43:49 2001 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 OAA16609 for ; Fri, 13 Jul 2001 14:43:48 -0400 (EDT) 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 OAA02973; Fri, 13 Jul 2001 14:43:45 -0400 (EDT) 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 OAA04931; Fri, 13 Jul 2001 14:43:47 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <35STYTTY>; Fri, 13 Jul 2001 14:43:46 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044657AD@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Daniel Starin'" Cc: "'Jonathan Rosenberg'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 14:43:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 19595 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: I think we are agreeing that you can subscribe without authorization. I think we agree that you don't get any Notifies unless you are authorized. I do note in Jonathan's text that he used 202 for the actual presence subscription acceptance, but 200 for watcherinfo. I don't quite understand that - it seemed to be either an information leak, or some kind of a typo. We could hold a discussion on DoS. The issue is which is better - lots of subscriptions that succeed, or lots of subscriptions that silently fail? If you explicitly fail (not authorized), information leaks - not good. Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 2:37 PM > To: 'Rosen, Brian' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > If I understand correctly, you and Jonathan have come to a consensus > that an initial Notify (specifying presence information) > should be given > without authorization? This seems to me to be similar to the > AIM model > in which user A may add user B to a buddy list without authorization. > User B may later set a specific policy on user A (like blocking them). > > If this is the case, I disagree with both of you and I believe that > rfc2779 (the presence requirements) does as well. It specifies.. "The > principle controlling a PRESENTITY MUST be able to control which > WATCHERS can observe that PRESENTITY's PRESENCE INFORMATION" ... By > allowing any random watcher to access even one Notify without > authorization, this requirement is not met... > > Dan > > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Rosen, Brian > Sent: Friday, July 13, 2001 1:46 PM > To: 'Daniel Starin' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > Daniel > > I suppose it's a matter of semantics, but I would claim > that you change authorization to change what information is revealed. > Whether you do it before subscription, or after it, > you are changing your authorization. > > I also think you made my point. Authorization is complex, > and standardizing it, at this time, is unwise. > > Of what use is it to the PS if I give it a yes/no, > and don't give it a what? So you can accept the > subscription but not send a Notify? Not interesting > methinks. Besides, as you observe, even yes/no is really > transient (yes, at the moment, but I could change my mind). > All the more reason to get it out of the protocol. > Even Jonathan proposes to accept the subscription without > authorization. > > We are talking about a complex interaction between the watcher > and the PS as well as the presentity and the PS. Until > there is a much greater degree of consensus on how that > interaction takes place, I don't see the value in > specifying any of it. Jonathan wants to standardize a simple > yes/no authorization so that it can be done in the GUI of > B's UA, and not take a browser. I think that such an idea > is far too limiting to be useful, and encourages lowest > common denominator thinking. It doesn't even give you > the basic notion of presenting the name of the watcher - > all you get is the existing SIP headers, which would in > many cases be a cryptic email identifier. I'd much rather > go the other direction and start talking about sending > an XML credential in the authorization request, and an > XML policy in the authorization reply. > > BTW, I wanted to make sure that everyone agrees that > authorization is not authentication; if the PS requires > authentication for the subscription (and it ought to), > then authentication must take place before the subscribe > will be acted upon. All authorization is dealing with is > what B will let you see, and it ranges from nothing to > a lot. Authentication is proving to the satisfaction > of the PS that you are who you claim to be. > > Brian > > > -----Original Message----- > > From: Daniel Starin [mailto:ds708@columbia.edu] > > Sent: Friday, July 13, 2001 1:05 PM > > To: 'Daniel Starin'; 'Rosen, Brian' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Revised.... I hit send by accident... > > > > The difference is, when I authorize someone, the way that I interact > > with them may change throughout the time that the > subscription exists. > > One minute I may want them to see detailed presence (IN / OUT / > > AWAY / BUSY) while the next minute I may want them to see OUT > > regardless > > of what my actual presence is. The fact is, for the most > part, these > > decisions are based on what is happening currently, not what happens > > when the request for the subscription takes place. At the time of > > request, all that is usually known is Yes, you may subscribe, > > or no, you > > may not. If you happen to know that you also want to give > > the person a > > specific type of presence (IN / OUT) at that time than so be it, you > > can (after you have said Yes to their subscription). But > many times, > > you will not know specifically how you want your presence to be > > distributed to those that subscribe to you at the moment they > > request a > > subscription. > > > > Thus a Yes/No authorization should be specified. Possibly a "what" > > should be specified as well but these two things should be distinct. > > > > As for credentials. I agree that some form of credentials must be > > specified for Yes / No authorization... > > > > Dan > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Friday, July 13, 2001 12:05 PM > > To: 'Daniel Starin' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > I don't agree. Authorization is specific - who and what. > > You can't split it up like that, or at least there is very > > little value in doing so. If I gave you a standardized way > > to say yes/no, but don't give you a standardized way to > > specify what, the implementation is just as proprietary. > > > > Also don't forget the credentials part. In order to even say > > yes/no, you need the credentials. > > > > Brian > > > > > -----Original Message----- > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > Sent: Friday, July 13, 2001 11:59 AM > > > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > Brian, > > > > > > It seems that there are two different issues you are discussing. > > > > > > One is whether or not A (the watcher) may access any of > B's presence > > > information (a binary decision) and the other is IF B indeed > > > allows A to > > > access presence information, what type of information will > > that be, - > > > In/Out, In / Busy/Out, etc. > > > > > > Regardless of what complex presence information a user may > > have, there > > > will always be an initial binary decision (yes, you can > > > access presence > > > or no, you cannot). Because this decision must always be > > > made for each > > > and every subscription request which is made, it may be > > reasonable to > > > standardize how this will be done. > > > > > > -Dan > > > > > > -----Original Message----- > > > From: simple-admin@mailman.dynamicsoft.com > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > > Rosen, Brian > > > Sent: Friday, July 13, 2001 10:44 AM > > > To: 'Jonathan Rosenberg' > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Let's start over. > > > > > > A and B are both UAs. I think we all agree on that. > > > You want a PS. I'll agree they are useful. If you > > > want a PS, then its a UAS to A. I want to talk > > > about how PS and B interact. > > > > > > I don't know if you would allow me to go there, but, > > > just for a moment, indulge me and let's talk about > > > A and B without PS. A wants to know B's presence. > > > Okay, so A subscribes to B, and B supplies > > > presence as NOTIFYies. This all works fine, although > > > it ignores how B authorizes A. In particular, > > > in order for B to authorize A, he needs credentials > > > for A (who are you). While the standard SIP headers > > > might be enough, in many cases, you need more > > > information about A. How do you get that? > > > > > > With my example, everything (except credentials) is > > > fine. In particular, B can send presence to A > > > because it's really B (B's real UA) that is the > > > source of the presence info, and we would all agree > > > that B the human interacts with B's UA in some > > > implementation dependent manner for B's UA to > > > find out the actual presence state. > > > > > > Are we okay here? > > > > > > Now let's put in the PS. In your model, just for now, > > > skip authorization, and let's just talk about how > > > B tells PS that B's presence state changed. > > > I can see two possibilities. The one I like is that > > > PS subscribes to B's presence. The other is that > > > there is a new header that is used for that purpose. > > > My way is real simple, takes no extension, and does > > > exactly what you want. When B changes his presence, > > > he does so on his UA (exactly as above), and Notifies > > > PS. PS, in turn, Notifies A. Simple, clean, effective. > > > > > > So what is PS? I claim it's a straightforward > > > B2BUA. Instead of subscribing directly to B, PS > > > subscribes to B and A (as well as any other authorized > > > watchers) subscribe to PS. > > > > > > Now, you introduce watcherinfo. I'm okay with that. > > > B subscribes to watcherinfo on PS, and PS Notifies B > > > of subscriptions. > > > > > > Now, back to authorization > > > > > > In several posts, I've stated that I'm interested in a > > > rich notion of presence. That covers a LOT of territory, > > > but let me give you a small example. Suppose I have > > > 3 states in my presence model In-Busy-Out. For > > > some watchers, I will give them one of these three > > > states. However, there are some people for whom I > > > don't want them to know that I'm in, but busy. They > > > only get two states - In/Out. This is all pretty easy > > > stuff. > > > > > > However, my authorization is not binary. I have to > > > tell PS which of the two models A gets. Two URLs > > > are not enough. > > > > > > So, authorization, I claim, is complex. You need > > > arbitrary credentials from A, and you need arbitrary outputs > > > from B. Thus, I claim, there is no sensible way to define the > > > authorization process between B and PS, or for that > > > matter, between A and PS in a standardized way. > > > > > > One way to help would be to at least tell A where > > > to go to at least FIND OUT how to get authorization. > > > Simply subscribing (attempting to subscribe) is not enough. > > > If you want to turn that around and say, fine, let's > > > also tell B how to authorize, I can't argue. > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Friday, July 13, 2001 10:03 AM > > > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > Cc: simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > Well, I'm real confused. > > > > > 1. The "automata" you are talking about -- I don't understand > > > > > what role it has in the context of this discussion. We have > > > > > "servers" that have presence information and "clients" that > > > > > want to get it. The server is an entity operating on > > behalf of a > > > > > presentity. The client is an entity operating on behalf of a > > > > > watcher. In > > > > > SIP terms, we have a UAC and a UAS. > > > > > > > > Its more complex than that, Brian. > > > > > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > > > > > > > > > | | | > > > > | |SUB B's pres.winfo (1)| > > > > | |<---------------------| B's > > > > client turns on > > > > | |200 OK (2)| > > > > | |--------------------->| > > > > | |NOTIFY (3)| > > > > | |--------------------->| > > > > | |200 OK (4)| > > > > | |<---------------------| > > > > | | | > > > > |SUB B's pres (5) | | > > > > |----------------->| | > > > > |202 Accepted (6)| | > > > > |<-----------------|NOTIFY "A Pending" (9)| > > > > |NOTIFY B's pres(7)|--------------------->|B > > learns that A > > > > |<-----------------|200 OK (10)| > > subscribed > > > > |200 OK (8)|<---------------------| > > > > |----------------->| | > > > > | | | > > > > | | | > > > > | |Set policy (11)| > > > > | |<---------------------| > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > > > > > Subscriber Presence Presentity > > > > A Server B > > > > > > > > > The UAS > > > > > is the agent of the presentity, and the UAC is the agent of > > > > > the watcher. Now, where is this automata? In the UAS? > > > > > The UAS is what the protocol defines, you seem to want to deal > > > > > with something that is not the UAS but is connecting to it. > > > > > > > > There is a presence server, which is a UAC for some > > > > transactions, and UAS > > > > for others. There is a subscriber A, which is a UAC for some > > > > transactions > > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > > > presentity > > > > application for B, which is a UAC for some transactions > > > > (SUBSCRIBE to its > > > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > > > per transaction > > > > role. The presence server is the "agent" for B, in the sense > > > > that it accepts > > > > subscribes and generates notifies on B's behalf. How it finds > > > > out about the > > > > presence state is another orthogonal piece, not specified in > > > > the SUB/NOT > > > > mechanism. Typically, its through registrations or through > > > > direct upload of > > > > a presence document. > > > > > > > > > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > > > where the presentity and the watcher are both UACs and there > > > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > > > idea. If that is the model you are pushing, I want to push > > > > > back. The UAC is the agent of the presentity, the UAS is the > > > > > agent of the watcher, and the UAC doesn't need any protocol > > > > > to the presentity -- it "is" the presentity. > > > > > > > > I cannot map these statements to sensible definitions of > > > UAC and UAS, > > > > presentity or watcher. Please see above. > > > > > > > > > If you want > > > > > the presentity to be a UAC, then we need more than what we > > > > > are talking about on this thread - we need to standardize > > > > > how the UAC at the presentity tells the UAS how to change its > > > > > presence, and then we get into all sorts of issues about > > > > > how this model supports rich presence information (since it > > > > > requires that two UACs AND the UAS all have the same > > > > > capabilities). How the UAC interacts with the presentity > > > > > is not the place we standardize. It could be split into > > > > > a "client" and a "server", but the interactions between those > > > > > pieces are complex, and I don't see how we could standardize > > > > > them right now. > > > > > > > > I still cannot understand any of the above based on the > > > > definitions of UAC > > > > and UAS in the bis spec, and presentity, watcher, etc. > > > from rfc2778. > > > > > > > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > > > Yes, you get a message when someone puts you in his > > > > > friend list. However, what it is asking you seems to be > > > > > whether you want to put him in YOUR buddy list. In > particular, > > > > > if you reject, you are still in his friend list, and he sees > > > > > your presence. > > > > > > > > No, thats not true. When I subscribe to someone, they appear > > > > in my buddy > > > > list, and the status is marked as "pending authorization" > > > > until the time > > > > that they provide authorization. Once that happens, I see > > their real > > > > presence. On the other side, when someone subscribes to me, I > > > > get a screen > > > > pop, which asks for "approve", "approve and add", or "reject". > > > > Approve/reject have the meanings we've been discussing - they > > > > approve or > > > > reject the subscription. "approve and add" approves the > > > > subscription, and > > > > also sends a subscription from me back to them, adding them > > > > to my buddy > > > > list. > > > > > > > > I've been using this tool for several years. I think I can > > > make these > > > > statements with soem confidence that they are correct. > > > > > > > > -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 ds708@columbia.edu Fri Jul 13 14:57:32 2001 Received: from menyapa.cc.columbia.edu (menyapa.cc.columbia.edu [128.59.59.38]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16690 for ; Fri, 13 Jul 2001 14:57:31 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by menyapa.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA02730; Fri, 13 Jul 2001 14:57:40 -0400 (EDT) From: "Daniel Starin" To: "'Rosen, Brian'" Cc: "'Jonathan Rosenberg'" , Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 14:57:40 -0400 Message-ID: <002b01c10bcd$b1c1e4c0$a1a20681@DSTARIN2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4FBEA8857476D311A03300204840E1CF044657AD@whq-msgusr-02.pit.comms.marconi.com> Importance: Normal Content-Length: 20167 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA16690 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: That’s the thing... I think Jonathan says that an initial notify will be sent in step 7 of his diagram.... "NOTIFY B's pres"..... before authorization... as far as I can tell. I agree with his diagram in that policies should be set at any time... but I think that initial notify needs some authorization.... Dan -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, July 13, 2001 2:44 PM To: 'Daniel Starin' Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization I think we are agreeing that you can subscribe without authorization. I think we agree that you don't get any Notifies unless you are authorized. I do note in Jonathan's text that he used 202 for the actual presence subscription acceptance, but 200 for watcherinfo. I don't quite understand that - it seemed to be either an information leak, or some kind of a typo. We could hold a discussion on DoS. The issue is which is better - lots of subscriptions that succeed, or lots of subscriptions that silently fail? If you explicitly fail (not authorized), information leaks - not good. Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 2:37 PM > To: 'Rosen, Brian' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > If I understand correctly, you and Jonathan have come to a consensus > that an initial Notify (specifying presence information) > should be given > without authorization? This seems to me to be similar to the > AIM model > in which user A may add user B to a buddy list without authorization. > User B may later set a specific policy on user A (like blocking them). > > If this is the case, I disagree with both of you and I believe that > rfc2779 (the presence requirements) does as well. It specifies.. "The > principle controlling a PRESENTITY MUST be able to control which > WATCHERS can observe that PRESENTITY's PRESENCE INFORMATION" ... By > allowing any random watcher to access even one Notify without > authorization, this requirement is not met... > > Dan > > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Rosen, Brian > Sent: Friday, July 13, 2001 1:46 PM > To: 'Daniel Starin' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > Daniel > > I suppose it's a matter of semantics, but I would claim > that you change authorization to change what information is revealed. > Whether you do it before subscription, or after it, > you are changing your authorization. > > I also think you made my point. Authorization is complex, > and standardizing it, at this time, is unwise. > > Of what use is it to the PS if I give it a yes/no, > and don't give it a what? So you can accept the > subscription but not send a Notify? Not interesting > methinks. Besides, as you observe, even yes/no is really > transient (yes, at the moment, but I could change my mind). > All the more reason to get it out of the protocol. > Even Jonathan proposes to accept the subscription without > authorization. > > We are talking about a complex interaction between the watcher > and the PS as well as the presentity and the PS. Until > there is a much greater degree of consensus on how that > interaction takes place, I don't see the value in > specifying any of it. Jonathan wants to standardize a simple > yes/no authorization so that it can be done in the GUI of > B's UA, and not take a browser. I think that such an idea > is far too limiting to be useful, and encourages lowest > common denominator thinking. It doesn't even give you > the basic notion of presenting the name of the watcher - > all you get is the existing SIP headers, which would in > many cases be a cryptic email identifier. I'd much rather > go the other direction and start talking about sending > an XML credential in the authorization request, and an > XML policy in the authorization reply. > > BTW, I wanted to make sure that everyone agrees that > authorization is not authentication; if the PS requires > authentication for the subscription (and it ought to), > then authentication must take place before the subscribe > will be acted upon. All authorization is dealing with is > what B will let you see, and it ranges from nothing to > a lot. Authentication is proving to the satisfaction > of the PS that you are who you claim to be. > > Brian > > > -----Original Message----- > > From: Daniel Starin [mailto:ds708@columbia.edu] > > Sent: Friday, July 13, 2001 1:05 PM > > To: 'Daniel Starin'; 'Rosen, Brian' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Revised.... I hit send by accident... > > > > The difference is, when I authorize someone, the way that I interact > > with them may change throughout the time that the > subscription exists. > > One minute I may want them to see detailed presence (IN / OUT / > > AWAY / BUSY) while the next minute I may want them to see OUT > > regardless > > of what my actual presence is. The fact is, for the most > part, these > > decisions are based on what is happening currently, not what happens > > when the request for the subscription takes place. At the time of > > request, all that is usually known is Yes, you may subscribe, > > or no, you > > may not. If you happen to know that you also want to give > > the person a > > specific type of presence (IN / OUT) at that time than so be it, you > > can (after you have said Yes to their subscription). But > many times, > > you will not know specifically how you want your presence to be > > distributed to those that subscribe to you at the moment they > > request a > > subscription. > > > > Thus a Yes/No authorization should be specified. Possibly a "what" > > should be specified as well but these two things should be distinct. > > > > As for credentials. I agree that some form of credentials must be > > specified for Yes / No authorization... > > > > Dan > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Friday, July 13, 2001 12:05 PM > > To: 'Daniel Starin' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > I don't agree. Authorization is specific - who and what. > > You can't split it up like that, or at least there is very > > little value in doing so. If I gave you a standardized way > > to say yes/no, but don't give you a standardized way to > > specify what, the implementation is just as proprietary. > > > > Also don't forget the credentials part. In order to even say > > yes/no, you need the credentials. > > > > Brian > > > > > -----Original Message----- > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > Sent: Friday, July 13, 2001 11:59 AM > > > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > Brian, > > > > > > It seems that there are two different issues you are discussing. > > > > > > One is whether or not A (the watcher) may access any of > B's presence > > > information (a binary decision) and the other is IF B indeed > > > allows A to > > > access presence information, what type of information will > > that be, - > > > In/Out, In / Busy/Out, etc. > > > > > > Regardless of what complex presence information a user may > > have, there > > > will always be an initial binary decision (yes, you can > > > access presence > > > or no, you cannot). Because this decision must always be > > > made for each > > > and every subscription request which is made, it may be > > reasonable to > > > standardize how this will be done. > > > > > > -Dan > > > > > > -----Original Message----- > > > From: simple-admin@mailman.dynamicsoft.com > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > > Rosen, Brian > > > Sent: Friday, July 13, 2001 10:44 AM > > > To: 'Jonathan Rosenberg' > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Let's start over. > > > > > > A and B are both UAs. I think we all agree on that. > > > You want a PS. I'll agree they are useful. If you > > > want a PS, then its a UAS to A. I want to talk > > > about how PS and B interact. > > > > > > I don't know if you would allow me to go there, but, > > > just for a moment, indulge me and let's talk about > > > A and B without PS. A wants to know B's presence. > > > Okay, so A subscribes to B, and B supplies > > > presence as NOTIFYies. This all works fine, although > > > it ignores how B authorizes A. In particular, > > > in order for B to authorize A, he needs credentials > > > for A (who are you). While the standard SIP headers > > > might be enough, in many cases, you need more > > > information about A. How do you get that? > > > > > > With my example, everything (except credentials) is > > > fine. In particular, B can send presence to A > > > because it's really B (B's real UA) that is the > > > source of the presence info, and we would all agree > > > that B the human interacts with B's UA in some > > > implementation dependent manner for B's UA to > > > find out the actual presence state. > > > > > > Are we okay here? > > > > > > Now let's put in the PS. In your model, just for now, > > > skip authorization, and let's just talk about how > > > B tells PS that B's presence state changed. > > > I can see two possibilities. The one I like is that > > > PS subscribes to B's presence. The other is that > > > there is a new header that is used for that purpose. > > > My way is real simple, takes no extension, and does > > > exactly what you want. When B changes his presence, > > > he does so on his UA (exactly as above), and Notifies > > > PS. PS, in turn, Notifies A. Simple, clean, effective. > > > > > > So what is PS? I claim it's a straightforward > > > B2BUA. Instead of subscribing directly to B, PS > > > subscribes to B and A (as well as any other authorized > > > watchers) subscribe to PS. > > > > > > Now, you introduce watcherinfo. I'm okay with that. > > > B subscribes to watcherinfo on PS, and PS Notifies B > > > of subscriptions. > > > > > > Now, back to authorization > > > > > > In several posts, I've stated that I'm interested in a > > > rich notion of presence. That covers a LOT of territory, > > > but let me give you a small example. Suppose I have > > > 3 states in my presence model In-Busy-Out. For > > > some watchers, I will give them one of these three > > > states. However, there are some people for whom I > > > don't want them to know that I'm in, but busy. They > > > only get two states - In/Out. This is all pretty easy > > > stuff. > > > > > > However, my authorization is not binary. I have to > > > tell PS which of the two models A gets. Two URLs > > > are not enough. > > > > > > So, authorization, I claim, is complex. You need > > > arbitrary credentials from A, and you need arbitrary outputs > > > from B. Thus, I claim, there is no sensible way to define the > > > authorization process between B and PS, or for that > > > matter, between A and PS in a standardized way. > > > > > > One way to help would be to at least tell A where > > > to go to at least FIND OUT how to get authorization. > > > Simply subscribing (attempting to subscribe) is not enough. > > > If you want to turn that around and say, fine, let's > > > also tell B how to authorize, I can't argue. > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Friday, July 13, 2001 10:03 AM > > > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > Cc: simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > Well, I'm real confused. > > > > > 1. The "automata" you are talking about -- I don't understand > > > > > what role it has in the context of this discussion. We have > > > > > "servers" that have presence information and "clients" that > > > > > want to get it. The server is an entity operating on > > behalf of a > > > > > presentity. The client is an entity operating on behalf of a > > > > > watcher. In > > > > > SIP terms, we have a UAC and a UAS. > > > > > > > > Its more complex than that, Brian. > > > > > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > > > > > > > > > | | | > > > > | |SUB B's pres.winfo (1)| > > > > | |<---------------------| B's > > > > client turns on > > > > | |200 OK (2)| > > > > | |--------------------->| > > > > | |NOTIFY (3)| > > > > | |--------------------->| > > > > | |200 OK (4)| > > > > | |<---------------------| > > > > | | | > > > > |SUB B's pres (5) | | > > > > |----------------->| | > > > > |202 Accepted (6)| | > > > > |<-----------------|NOTIFY "A Pending" (9)| > > > > |NOTIFY B's pres(7)|--------------------->|B > > learns that A > > > > |<-----------------|200 OK (10)| > > subscribed > > > > |200 OK (8)|<---------------------| > > > > |----------------->| | > > > > | | | > > > > | | | > > > > | |Set policy (11)| > > > > | |<---------------------| > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > > > > > Subscriber Presence Presentity > > > > A Server B > > > > > > > > > The UAS > > > > > is the agent of the presentity, and the UAC is the agent of > > > > > the watcher. Now, where is this automata? In the UAS? > > > > > The UAS is what the protocol defines, you seem to want to deal > > > > > with something that is not the UAS but is connecting to it. > > > > > > > > There is a presence server, which is a UAC for some > > > > transactions, and UAS > > > > for others. There is a subscriber A, which is a UAC for some > > > > transactions > > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > > > presentity > > > > application for B, which is a UAC for some transactions > > > > (SUBSCRIBE to its > > > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > > > per transaction > > > > role. The presence server is the "agent" for B, in the sense > > > > that it accepts > > > > subscribes and generates notifies on B's behalf. How it finds > > > > out about the > > > > presence state is another orthogonal piece, not specified in > > > > the SUB/NOT > > > > mechanism. Typically, its through registrations or through > > > > direct upload of > > > > a presence document. > > > > > > > > > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > > > where the presentity and the watcher are both UACs and there > > > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > > > idea. If that is the model you are pushing, I want to push > > > > > back. The UAC is the agent of the presentity, the UAS is the > > > > > agent of the watcher, and the UAC doesn't need any protocol > > > > > to the presentity -- it "is" the presentity. > > > > > > > > I cannot map these statements to sensible definitions of > > > UAC and UAS, > > > > presentity or watcher. Please see above. > > > > > > > > > If you want > > > > > the presentity to be a UAC, then we need more than what we > > > > > are talking about on this thread - we need to standardize > > > > > how the UAC at the presentity tells the UAS how to change its > > > > > presence, and then we get into all sorts of issues about > > > > > how this model supports rich presence information (since it > > > > > requires that two UACs AND the UAS all have the same > > > > > capabilities). How the UAC interacts with the presentity > > > > > is not the place we standardize. It could be split into > > > > > a "client" and a "server", but the interactions between those > > > > > pieces are complex, and I don't see how we could standardize > > > > > them right now. > > > > > > > > I still cannot understand any of the above based on the > > > > definitions of UAC > > > > and UAS in the bis spec, and presentity, watcher, etc. > > > from rfc2778. > > > > > > > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > > > Yes, you get a message when someone puts you in his > > > > > friend list. However, what it is asking you seems to be > > > > > whether you want to put him in YOUR buddy list. In > particular, > > > > > if you reject, you are still in his friend list, and he sees > > > > > your presence. > > > > > > > > No, thats not true. When I subscribe to someone, they appear > > > > in my buddy > > > > list, and the status is marked as "pending authorization" > > > > until the time > > > > that they provide authorization. Once that happens, I see > > their real > > > > presence. On the other side, when someone subscribes to me, I > > > > get a screen > > > > pop, which asks for "approve", "approve and add", or "reject". > > > > Approve/reject have the meanings we've been discussing - they > > > > approve or > > > > reject the subscription. "approve and add" approves the > > > > subscription, and > > > > also sends a subscription from me back to them, adding them > > > > to my buddy > > > > list. > > > > > > > > I've been using this tool for several years. I think I can > > > make these > > > > statements with soem confidence that they are correct. > > > > > > > > -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 Brian.Rosen@marconi.com Fri Jul 13 15:04:35 2001 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 PAA16759 for ; Fri, 13 Jul 2001 15:04:34 -0400 (EDT) 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 PAA05300; Fri, 13 Jul 2001 15:04:31 -0400 (EDT) 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 PAA10081; Fri, 13 Jul 2001 15:04:33 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <35STY481>; Fri, 13 Jul 2001 15:04:32 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044657B1@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Daniel Starin'" , "'Jonathan Rosenberg'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 15:04:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 21652 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: Hmmm, I didn't look at Jonathan's diagram close enough. I would think that A would not get a Notify until after B authorized. So, message (7) can't happen until after (11). Is that what you mean? Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 2:58 PM > To: 'Rosen, Brian' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > That's the thing... I think Jonathan says that an initial > notify will be > sent in step 7 of his diagram.... "NOTIFY B's pres"..... before > authorization... as far as I can tell. I agree with his > diagram in that > policies should be set at any time... but I think that initial notify > needs some authorization.... > > Dan > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, July 13, 2001 2:44 PM > To: 'Daniel Starin' > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > I think we are agreeing that you can subscribe without > authorization. I think we agree that you don't get any > Notifies unless you are authorized. > > I do note in Jonathan's text that he used 202 for the > actual presence subscription acceptance, but 200 for > watcherinfo. I don't quite understand that - it seemed > to be either an information leak, or some kind of a typo. > > We could hold a discussion on DoS. The issue is which is > better - lots of subscriptions that succeed, or lots of > subscriptions that silently fail? If you explicitly fail > (not authorized), information leaks - not good. > > Brian > > > -----Original Message----- > > From: Daniel Starin [mailto:ds708@columbia.edu] > > Sent: Friday, July 13, 2001 2:37 PM > > To: 'Rosen, Brian' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > If I understand correctly, you and Jonathan have come to a > consensus > > that an initial Notify (specifying presence information) > > should be given > > without authorization? This seems to me to be similar to the > > AIM model > > in which user A may add user B to a buddy list without > authorization. > > User B may later set a specific policy on user A (like > blocking them). > > > > If this is the case, I disagree with both of you and I believe that > > rfc2779 (the presence requirements) does as well. It > specifies.. "The > > principle controlling a PRESENTITY MUST be able to control which > > WATCHERS can observe that PRESENTITY's PRESENCE INFORMATION" ... By > > allowing any random watcher to access even one Notify without > > authorization, this requirement is not met... > > > > Dan > > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > Rosen, Brian > > Sent: Friday, July 13, 2001 1:46 PM > > To: 'Daniel Starin' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > Daniel > > > > I suppose it's a matter of semantics, but I would claim > > that you change authorization to change what information is > revealed. > > Whether you do it before subscription, or after it, > > you are changing your authorization. > > > > I also think you made my point. Authorization is complex, > > and standardizing it, at this time, is unwise. > > > > Of what use is it to the PS if I give it a yes/no, > > and don't give it a what? So you can accept the > > subscription but not send a Notify? Not interesting > > methinks. Besides, as you observe, even yes/no is really > > transient (yes, at the moment, but I could change my mind). > > All the more reason to get it out of the protocol. > > Even Jonathan proposes to accept the subscription without > > authorization. > > > > We are talking about a complex interaction between the watcher > > and the PS as well as the presentity and the PS. Until > > there is a much greater degree of consensus on how that > > interaction takes place, I don't see the value in > > specifying any of it. Jonathan wants to standardize a simple > > yes/no authorization so that it can be done in the GUI of > > B's UA, and not take a browser. I think that such an idea > > is far too limiting to be useful, and encourages lowest > > common denominator thinking. It doesn't even give you > > the basic notion of presenting the name of the watcher - > > all you get is the existing SIP headers, which would in > > many cases be a cryptic email identifier. I'd much rather > > go the other direction and start talking about sending > > an XML credential in the authorization request, and an > > XML policy in the authorization reply. > > > > BTW, I wanted to make sure that everyone agrees that > > authorization is not authentication; if the PS requires > > authentication for the subscription (and it ought to), > > then authentication must take place before the subscribe > > will be acted upon. All authorization is dealing with is > > what B will let you see, and it ranges from nothing to > > a lot. Authentication is proving to the satisfaction > > of the PS that you are who you claim to be. > > > > Brian > > > > > -----Original Message----- > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > Sent: Friday, July 13, 2001 1:05 PM > > > To: 'Daniel Starin'; 'Rosen, Brian' > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > Revised.... I hit send by accident... > > > > > > The difference is, when I authorize someone, the way that > I interact > > > with them may change throughout the time that the > > subscription exists. > > > One minute I may want them to see detailed presence (IN / OUT / > > > AWAY / BUSY) while the next minute I may want them to see OUT > > > regardless > > > of what my actual presence is. The fact is, for the most > > part, these > > > decisions are based on what is happening currently, not > what happens > > > when the request for the subscription takes place. At the time of > > > request, all that is usually known is Yes, you may subscribe, > > > or no, you > > > may not. If you happen to know that you also want to give > > > the person a > > > specific type of presence (IN / OUT) at that time than so > be it, you > > > can (after you have said Yes to their subscription). But > > many times, > > > you will not know specifically how you want your presence to be > > > distributed to those that subscribe to you at the moment they > > > request a > > > subscription. > > > > > > Thus a Yes/No authorization should be specified. > Possibly a "what" > > > should be specified as well but these two things should > be distinct. > > > > > > As for credentials. I agree that some form of credentials must be > > > specified for Yes / No authorization... > > > > > > Dan > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Friday, July 13, 2001 12:05 PM > > > To: 'Daniel Starin' > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > I don't agree. Authorization is specific - who and what. > > > You can't split it up like that, or at least there is very > > > little value in doing so. If I gave you a standardized way > > > to say yes/no, but don't give you a standardized way to > > > specify what, the implementation is just as proprietary. > > > > > > Also don't forget the credentials part. In order to even say > > > yes/no, you need the credentials. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > > Sent: Friday, July 13, 2001 11:59 AM > > > > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > > > > Cc: simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > Brian, > > > > > > > > It seems that there are two different issues you are > discussing. > > > > > > > > One is whether or not A (the watcher) may access any of > > B's presence > > > > information (a binary decision) and the other is IF B indeed > > > > allows A to > > > > access presence information, what type of information will > > > that be, - > > > > In/Out, In / Busy/Out, etc. > > > > > > > > Regardless of what complex presence information a user may > > > have, there > > > > will always be an initial binary decision (yes, you can > > > > access presence > > > > or no, you cannot). Because this decision must always be > > > > made for each > > > > and every subscription request which is made, it may be > > > reasonable to > > > > standardize how this will be done. > > > > > > > > -Dan > > > > > > > > -----Original Message----- > > > > From: simple-admin@mailman.dynamicsoft.com > > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > > > Rosen, Brian > > > > Sent: Friday, July 13, 2001 10:44 AM > > > > To: 'Jonathan Rosenberg' > > > > Cc: simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > Let's start over. > > > > > > > > A and B are both UAs. I think we all agree on that. > > > > You want a PS. I'll agree they are useful. If you > > > > want a PS, then its a UAS to A. I want to talk > > > > about how PS and B interact. > > > > > > > > I don't know if you would allow me to go there, but, > > > > just for a moment, indulge me and let's talk about > > > > A and B without PS. A wants to know B's presence. > > > > Okay, so A subscribes to B, and B supplies > > > > presence as NOTIFYies. This all works fine, although > > > > it ignores how B authorizes A. In particular, > > > > in order for B to authorize A, he needs credentials > > > > for A (who are you). While the standard SIP headers > > > > might be enough, in many cases, you need more > > > > information about A. How do you get that? > > > > > > > > With my example, everything (except credentials) is > > > > fine. In particular, B can send presence to A > > > > because it's really B (B's real UA) that is the > > > > source of the presence info, and we would all agree > > > > that B the human interacts with B's UA in some > > > > implementation dependent manner for B's UA to > > > > find out the actual presence state. > > > > > > > > Are we okay here? > > > > > > > > Now let's put in the PS. In your model, just for now, > > > > skip authorization, and let's just talk about how > > > > B tells PS that B's presence state changed. > > > > I can see two possibilities. The one I like is that > > > > PS subscribes to B's presence. The other is that > > > > there is a new header that is used for that purpose. > > > > My way is real simple, takes no extension, and does > > > > exactly what you want. When B changes his presence, > > > > he does so on his UA (exactly as above), and Notifies > > > > PS. PS, in turn, Notifies A. Simple, clean, effective. > > > > > > > > So what is PS? I claim it's a straightforward > > > > B2BUA. Instead of subscribing directly to B, PS > > > > subscribes to B and A (as well as any other authorized > > > > watchers) subscribe to PS. > > > > > > > > Now, you introduce watcherinfo. I'm okay with that. > > > > B subscribes to watcherinfo on PS, and PS Notifies B > > > > of subscriptions. > > > > > > > > Now, back to authorization > > > > > > > > In several posts, I've stated that I'm interested in a > > > > rich notion of presence. That covers a LOT of territory, > > > > but let me give you a small example. Suppose I have > > > > 3 states in my presence model In-Busy-Out. For > > > > some watchers, I will give them one of these three > > > > states. However, there are some people for whom I > > > > don't want them to know that I'm in, but busy. They > > > > only get two states - In/Out. This is all pretty easy > > > > stuff. > > > > > > > > However, my authorization is not binary. I have to > > > > tell PS which of the two models A gets. Two URLs > > > > are not enough. > > > > > > > > So, authorization, I claim, is complex. You need > > > > arbitrary credentials from A, and you need arbitrary outputs > > > > from B. Thus, I claim, there is no sensible way to define the > > > > authorization process between B and PS, or for that > > > > matter, between A and PS in a standardized way. > > > > > > > > One way to help would be to at least tell A where > > > > to go to at least FIND OUT how to get authorization. > > > > Simply subscribing (attempting to subscribe) is not enough. > > > > If you want to turn that around and say, fine, let's > > > > also tell B how to authorize, I can't argue. > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > Sent: Friday, July 13, 2001 10:03 AM > > > > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > > Subject: RE: [Simple] Another idea for presence > authorization > > > > > > > > > > > > > > > > > > Well, I'm real confused. > > > > > > 1. The "automata" you are talking about -- I don't > understand > > > > > > what role it has in the context of this discussion. We have > > > > > > "servers" that have presence information and "clients" that > > > > > > want to get it. The server is an entity operating on > > > behalf of a > > > > > > presentity. The client is an entity operating on > behalf of a > > > > > > watcher. In > > > > > > SIP terms, we have a UAC and a UAS. > > > > > > > > > > Its more complex than that, Brian. > > > > > > > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > > > > > > > > > > > > > | | | > > > > > | |SUB B's pres.winfo (1)| > > > > > | |<---------------------| B's > > > > > client turns on > > > > > | |200 OK (2)| > > > > > | |--------------------->| > > > > > | |NOTIFY (3)| > > > > > | |--------------------->| > > > > > | |200 OK (4)| > > > > > | |<---------------------| > > > > > | | | > > > > > |SUB B's pres (5) | | > > > > > |----------------->| | > > > > > |202 Accepted (6)| | > > > > > |<-----------------|NOTIFY "A Pending" (9)| > > > > > |NOTIFY B's pres(7)|--------------------->|B > > > learns that A > > > > > |<-----------------|200 OK (10)| > > > subscribed > > > > > |200 OK (8)|<---------------------| > > > > > |----------------->| | > > > > > | | | > > > > > | | | > > > > > | |Set policy (11)| > > > > > | |<---------------------| > > > > > | | | > > > > > | | | > > > > > | | | > > > > > | | | > > > > > > > > > > Subscriber Presence Presentity > > > > > A Server B > > > > > > > > > > > The UAS > > > > > > is the agent of the presentity, and the UAC is the agent of > > > > > > the watcher. Now, where is this automata? In the UAS? > > > > > > The UAS is what the protocol defines, you seem to > want to deal > > > > > > with something that is not the UAS but is connecting to it. > > > > > > > > > > There is a presence server, which is a UAC for some > > > > > transactions, and UAS > > > > > for others. There is a subscriber A, which is a UAC for some > > > > > transactions > > > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > > > > presentity > > > > > application for B, which is a UAC for some transactions > > > > > (SUBSCRIBE to its > > > > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > > > > per transaction > > > > > role. The presence server is the "agent" for B, in the sense > > > > > that it accepts > > > > > subscribes and generates notifies on B's behalf. How it finds > > > > > out about the > > > > > presence state is another orthogonal piece, not specified in > > > > > the SUB/NOT > > > > > mechanism. Typically, its through registrations or through > > > > > direct upload of > > > > > a presence document. > > > > > > > > > > > > > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > > > > where the presentity and the watcher are both UACs and there > > > > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > > > > idea. If that is the model you are pushing, I want to push > > > > > > back. The UAC is the agent of the presentity, the > UAS is the > > > > > > agent of the watcher, and the UAC doesn't need any protocol > > > > > > to the presentity -- it "is" the presentity. > > > > > > > > > > I cannot map these statements to sensible definitions of > > > > UAC and UAS, > > > > > presentity or watcher. Please see above. > > > > > > > > > > > If you want > > > > > > the presentity to be a UAC, then we need more than what we > > > > > > are talking about on this thread - we need to standardize > > > > > > how the UAC at the presentity tells the UAS how to > change its > > > > > > presence, and then we get into all sorts of issues about > > > > > > how this model supports rich presence information (since it > > > > > > requires that two UACs AND the UAS all have the same > > > > > > capabilities). How the UAC interacts with the presentity > > > > > > is not the place we standardize. It could be split into > > > > > > a "client" and a "server", but the interactions > between those > > > > > > pieces are complex, and I don't see how we could standardize > > > > > > them right now. > > > > > > > > > > I still cannot understand any of the above based on the > > > > > definitions of UAC > > > > > and UAS in the bis spec, and presentity, watcher, etc. > > > > from rfc2778. > > > > > > > > > > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > > > > Yes, you get a message when someone puts you in his > > > > > > friend list. However, what it is asking you seems to be > > > > > > whether you want to put him in YOUR buddy list. In > > particular, > > > > > > if you reject, you are still in his friend list, and he sees > > > > > > your presence. > > > > > > > > > > No, thats not true. When I subscribe to someone, they appear > > > > > in my buddy > > > > > list, and the status is marked as "pending authorization" > > > > > until the time > > > > > that they provide authorization. Once that happens, I see > > > their real > > > > > presence. On the other side, when someone subscribes to me, I > > > > > get a screen > > > > > pop, which asks for "approve", "approve and add", or "reject". > > > > > Approve/reject have the meanings we've been discussing - they > > > > > approve or > > > > > reject the subscription. "approve and add" approves the > > > > > subscription, and > > > > > also sends a subscription from me back to them, adding them > > > > > to my buddy > > > > > list. > > > > > > > > > > I've been using this tool for several years. I think I can > > > > make these > > > > > statements with soem confidence that they are correct. > > > > > > > > > > -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 mhammer@cisco.com Fri Jul 13 16:26:18 2001 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 QAA17033 for ; Fri, 13 Jul 2001 16:26:17 -0400 (EDT) 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 QAA19997; Fri, 13 Jul 2001 16:26:17 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id AKY02657; Fri, 13 Jul 2001 16:26:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20010713162350.00b28258@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Jul 2001 16:28:38 -0400 To: "Rosen, Brian" From: Michael Hammer Subject: RE: [Simple] Another idea for presence authorization Cc: "'Daniel Starin'" , "'Jonathan Rosenberg'" , simple@mailman.dynamicsoft.com In-Reply-To: <4FBEA8857476D311A03300204840E1CF044657B1@whq-msgusr-02.pit .comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 23181 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: In an earlier email Dan (I think) implied that an additional transaction to complement the "Set" method would be needed, namely a "Fetch" where the PS knows that before it sends out notifications of presence it should get a policy update. Would this presume that the human has already modified the policy prior to allowing the Sub indicating presence? Actually, this could be avoided if the initial contact by B to the PS includes that policy update. Is that what was contemplated? Mike At 03:04 PM 7/13/2001 -0400, Rosen, Brian wrote: >Hmmm, I didn't look at Jonathan's diagram close enough. >I would think that A would not get a Notify until >after B authorized. So, message (7) can't happen >until after (11). Is that what you mean? > >Brian > > > -----Original Message----- > > From: Daniel Starin [mailto:ds708@columbia.edu] > > Sent: Friday, July 13, 2001 2:58 PM > > To: 'Rosen, Brian' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > That's the thing... I think Jonathan says that an initial > > notify will be > > sent in step 7 of his diagram.... "NOTIFY B's pres"..... before > > authorization... as far as I can tell. I agree with his > > diagram in that > > policies should be set at any time... but I think that initial notify > > needs some authorization.... > > > > Dan > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Friday, July 13, 2001 2:44 PM > > To: 'Daniel Starin' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > I think we are agreeing that you can subscribe without > > authorization. I think we agree that you don't get any > > Notifies unless you are authorized. > > > > I do note in Jonathan's text that he used 202 for the > > actual presence subscription acceptance, but 200 for > > watcherinfo. I don't quite understand that - it seemed > > to be either an information leak, or some kind of a typo. > > > > We could hold a discussion on DoS. The issue is which is > > better - lots of subscriptions that succeed, or lots of > > subscriptions that silently fail? If you explicitly fail > > (not authorized), information leaks - not good. > > > > Brian > > > > > -----Original Message----- > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > Sent: Friday, July 13, 2001 2:37 PM > > > To: 'Rosen, Brian' > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > If I understand correctly, you and Jonathan have come to a > > consensus > > > that an initial Notify (specifying presence information) > > > should be given > > > without authorization? This seems to me to be similar to the > > > AIM model > > > in which user A may add user B to a buddy list without > > authorization. > > > User B may later set a specific policy on user A (like > > blocking them). > > > > > > If this is the case, I disagree with both of you and I believe that > > > rfc2779 (the presence requirements) does as well. It > > specifies.. "The > > > principle controlling a PRESENTITY MUST be able to control which > > > WATCHERS can observe that PRESENTITY's PRESENCE INFORMATION" ... By > > > allowing any random watcher to access even one Notify without > > > authorization, this requirement is not met... > > > > > > Dan > > > > > > -----Original Message----- > > > From: simple-admin@mailman.dynamicsoft.com > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > > Rosen, Brian > > > Sent: Friday, July 13, 2001 1:46 PM > > > To: 'Daniel Starin' > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Daniel > > > > > > I suppose it's a matter of semantics, but I would claim > > > that you change authorization to change what information is > > revealed. > > > Whether you do it before subscription, or after it, > > > you are changing your authorization. > > > > > > I also think you made my point. Authorization is complex, > > > and standardizing it, at this time, is unwise. > > > > > > Of what use is it to the PS if I give it a yes/no, > > > and don't give it a what? So you can accept the > > > subscription but not send a Notify? Not interesting > > > methinks. Besides, as you observe, even yes/no is really > > > transient (yes, at the moment, but I could change my mind). > > > All the more reason to get it out of the protocol. > > > Even Jonathan proposes to accept the subscription without > > > authorization. > > > > > > We are talking about a complex interaction between the watcher > > > and the PS as well as the presentity and the PS. Until > > > there is a much greater degree of consensus on how that > > > interaction takes place, I don't see the value in > > > specifying any of it. Jonathan wants to standardize a simple > > > yes/no authorization so that it can be done in the GUI of > > > B's UA, and not take a browser. I think that such an idea > > > is far too limiting to be useful, and encourages lowest > > > common denominator thinking. It doesn't even give you > > > the basic notion of presenting the name of the watcher - > > > all you get is the existing SIP headers, which would in > > > many cases be a cryptic email identifier. I'd much rather > > > go the other direction and start talking about sending > > > an XML credential in the authorization request, and an > > > XML policy in the authorization reply. > > > > > > BTW, I wanted to make sure that everyone agrees that > > > authorization is not authentication; if the PS requires > > > authentication for the subscription (and it ought to), > > > then authentication must take place before the subscribe > > > will be acted upon. All authorization is dealing with is > > > what B will let you see, and it ranges from nothing to > > > a lot. Authentication is proving to the satisfaction > > > of the PS that you are who you claim to be. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > > Sent: Friday, July 13, 2001 1:05 PM > > > > To: 'Daniel Starin'; 'Rosen, Brian' > > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > Revised.... I hit send by accident... > > > > > > > > The difference is, when I authorize someone, the way that > > I interact > > > > with them may change throughout the time that the > > > subscription exists. > > > > One minute I may want them to see detailed presence (IN / OUT / > > > > AWAY / BUSY) while the next minute I may want them to see OUT > > > > regardless > > > > of what my actual presence is. The fact is, for the most > > > part, these > > > > decisions are based on what is happening currently, not > > what happens > > > > when the request for the subscription takes place. At the time of > > > > request, all that is usually known is Yes, you may subscribe, > > > > or no, you > > > > may not. If you happen to know that you also want to give > > > > the person a > > > > specific type of presence (IN / OUT) at that time than so > > be it, you > > > > can (after you have said Yes to their subscription). But > > > many times, > > > > you will not know specifically how you want your presence to be > > > > distributed to those that subscribe to you at the moment they > > > > request a > > > > subscription. > > > > > > > > Thus a Yes/No authorization should be specified. > > Possibly a "what" > > > > should be specified as well but these two things should > > be distinct. > > > > > > > > As for credentials. I agree that some form of credentials must be > > > > specified for Yes / No authorization... > > > > > > > > Dan > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Friday, July 13, 2001 12:05 PM > > > > To: 'Daniel Starin' > > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > I don't agree. Authorization is specific - who and what. > > > > You can't split it up like that, or at least there is very > > > > little value in doing so. If I gave you a standardized way > > > > to say yes/no, but don't give you a standardized way to > > > > specify what, the implementation is just as proprietary. > > > > > > > > Also don't forget the credentials part. In order to even say > > > > yes/no, you need the credentials. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > > > Sent: Friday, July 13, 2001 11:59 AM > > > > > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > Brian, > > > > > > > > > > It seems that there are two different issues you are > > discussing. > > > > > > > > > > One is whether or not A (the watcher) may access any of > > > B's presence > > > > > information (a binary decision) and the other is IF B indeed > > > > > allows A to > > > > > access presence information, what type of information will > > > > that be, - > > > > > In/Out, In / Busy/Out, etc. > > > > > > > > > > Regardless of what complex presence information a user may > > > > have, there > > > > > will always be an initial binary decision (yes, you can > > > > > access presence > > > > > or no, you cannot). Because this decision must always be > > > > > made for each > > > > > and every subscription request which is made, it may be > > > > reasonable to > > > > > standardize how this will be done. > > > > > > > > > > -Dan > > > > > > > > > > -----Original Message----- > > > > > From: simple-admin@mailman.dynamicsoft.com > > > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > > > > Rosen, Brian > > > > > Sent: Friday, July 13, 2001 10:44 AM > > > > > To: 'Jonathan Rosenberg' > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > Let's start over. > > > > > > > > > > A and B are both UAs. I think we all agree on that. > > > > > You want a PS. I'll agree they are useful. If you > > > > > want a PS, then its a UAS to A. I want to talk > > > > > about how PS and B interact. > > > > > > > > > > I don't know if you would allow me to go there, but, > > > > > just for a moment, indulge me and let's talk about > > > > > A and B without PS. A wants to know B's presence. > > > > > Okay, so A subscribes to B, and B supplies > > > > > presence as NOTIFYies. This all works fine, although > > > > > it ignores how B authorizes A. In particular, > > > > > in order for B to authorize A, he needs credentials > > > > > for A (who are you). While the standard SIP headers > > > > > might be enough, in many cases, you need more > > > > > information about A. How do you get that? > > > > > > > > > > With my example, everything (except credentials) is > > > > > fine. In particular, B can send presence to A > > > > > because it's really B (B's real UA) that is the > > > > > source of the presence info, and we would all agree > > > > > that B the human interacts with B's UA in some > > > > > implementation dependent manner for B's UA to > > > > > find out the actual presence state. > > > > > > > > > > Are we okay here? > > > > > > > > > > Now let's put in the PS. In your model, just for now, > > > > > skip authorization, and let's just talk about how > > > > > B tells PS that B's presence state changed. > > > > > I can see two possibilities. The one I like is that > > > > > PS subscribes to B's presence. The other is that > > > > > there is a new header that is used for that purpose. > > > > > My way is real simple, takes no extension, and does > > > > > exactly what you want. When B changes his presence, > > > > > he does so on his UA (exactly as above), and Notifies > > > > > PS. PS, in turn, Notifies A. Simple, clean, effective. > > > > > > > > > > So what is PS? I claim it's a straightforward > > > > > B2BUA. Instead of subscribing directly to B, PS > > > > > subscribes to B and A (as well as any other authorized > > > > > watchers) subscribe to PS. > > > > > > > > > > Now, you introduce watcherinfo. I'm okay with that. > > > > > B subscribes to watcherinfo on PS, and PS Notifies B > > > > > of subscriptions. > > > > > > > > > > Now, back to authorization > > > > > > > > > > In several posts, I've stated that I'm interested in a > > > > > rich notion of presence. That covers a LOT of territory, > > > > > but let me give you a small example. Suppose I have > > > > > 3 states in my presence model In-Busy-Out. For > > > > > some watchers, I will give them one of these three > > > > > states. However, there are some people for whom I > > > > > don't want them to know that I'm in, but busy. They > > > > > only get two states - In/Out. This is all pretty easy > > > > > stuff. > > > > > > > > > > However, my authorization is not binary. I have to > > > > > tell PS which of the two models A gets. Two URLs > > > > > are not enough. > > > > > > > > > > So, authorization, I claim, is complex. You need > > > > > arbitrary credentials from A, and you need arbitrary outputs > > > > > from B. Thus, I claim, there is no sensible way to define the > > > > > authorization process between B and PS, or for that > > > > > matter, between A and PS in a standardized way. > > > > > > > > > > One way to help would be to at least tell A where > > > > > to go to at least FIND OUT how to get authorization. > > > > > Simply subscribing (attempting to subscribe) is not enough. > > > > > If you want to turn that around and say, fine, let's > > > > > also tell B how to authorize, I can't argue. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > Sent: Friday, July 13, 2001 10:03 AM > > > > > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > > > Subject: RE: [Simple] Another idea for presence > > authorization > > > > > > > > > > > > > > > > > > > > > Well, I'm real confused. > > > > > > > 1. The "automata" you are talking about -- I don't > > understand > > > > > > > what role it has in the context of this discussion. We have > > > > > > > "servers" that have presence information and "clients" that > > > > > > > want to get it. The server is an entity operating on > > > > behalf of a > > > > > > > presentity. The client is an entity operating on > > behalf of a > > > > > > > watcher. In > > > > > > > SIP terms, we have a UAC and a UAS. > > > > > > > > > > > > Its more complex than that, Brian. > > > > > > > > > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > > > > > > > > > > > > > > > > > | | | > > > > > > | |SUB B's pres.winfo (1)| > > > > > > | |<---------------------| B's > > > > > > client turns on > > > > > > | |200 OK (2)| > > > > > > | |--------------------->| > > > > > > | |NOTIFY (3)| > > > > > > | |--------------------->| > > > > > > | |200 OK (4)| > > > > > > | |<---------------------| > > > > > > | | | > > > > > > |SUB B's pres (5) | | > > > > > > |----------------->| | > > > > > > |202 Accepted (6)| | > > > > > > |<-----------------|NOTIFY "A Pending" (9)| > > > > > > |NOTIFY B's pres(7)|--------------------->|B > > > > learns that A > > > > > > |<-----------------|200 OK (10)| > > > > subscribed > > > > > > |200 OK (8)|<---------------------| > > > > > > |----------------->| | > > > > > > | | | > > > > > > | | | > > > > > > | |Set policy (11)| > > > > > > | |<---------------------| > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > > > > > > > Subscriber Presence Presentity > > > > > > A Server B > > > > > > > > > > > > > The UAS > > > > > > > is the agent of the presentity, and the UAC is the agent of > > > > > > > the watcher. Now, where is this automata? In the UAS? > > > > > > > The UAS is what the protocol defines, you seem to > > want to deal > > > > > > > with something that is not the UAS but is connecting to it. > > > > > > > > > > > > There is a presence server, which is a UAC for some > > > > > > transactions, and UAS > > > > > > for others. There is a subscriber A, which is a UAC for some > > > > > > transactions > > > > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > > > > > presentity > > > > > > application for B, which is a UAC for some transactions > > > > > > (SUBSCRIBE to its > > > > > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > > > > > per transaction > > > > > > role. The presence server is the "agent" for B, in the sense > > > > > > that it accepts > > > > > > subscribes and generates notifies on B's behalf. How it finds > > > > > > out about the > > > > > > presence state is another orthogonal piece, not specified in > > > > > > the SUB/NOT > > > > > > mechanism. Typically, its through registrations or through > > > > > > direct upload of > > > > > > a presence document. > > > > > > > > > > > > > > > > > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > > > > > where the presentity and the watcher are both UACs and there > > > > > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > > > > > idea. If that is the model you are pushing, I want to push > > > > > > > back. The UAC is the agent of the presentity, the > > UAS is the > > > > > > > agent of the watcher, and the UAC doesn't need any protocol > > > > > > > to the presentity -- it "is" the presentity. > > > > > > > > > > > > I cannot map these statements to sensible definitions of > > > > > UAC and UAS, > > > > > > presentity or watcher. Please see above. > > > > > > > > > > > > > If you want > > > > > > > the presentity to be a UAC, then we need more than what we > > > > > > > are talking about on this thread - we need to standardize > > > > > > > how the UAC at the presentity tells the UAS how to > > change its > > > > > > > presence, and then we get into all sorts of issues about > > > > > > > how this model supports rich presence information (since it > > > > > > > requires that two UACs AND the UAS all have the same > > > > > > > capabilities). How the UAC interacts with the presentity > > > > > > > is not the place we standardize. It could be split into > > > > > > > a "client" and a "server", but the interactions > > between those > > > > > > > pieces are complex, and I don't see how we could standardize > > > > > > > them right now. > > > > > > > > > > > > I still cannot understand any of the above based on the > > > > > > definitions of UAC > > > > > > and UAS in the bis spec, and presentity, watcher, etc. > > > > > from rfc2778. > > > > > > > > > > > > > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > > > > > Yes, you get a message when someone puts you in his > > > > > > > friend list. However, what it is asking you seems to be > > > > > > > whether you want to put him in YOUR buddy list. In > > > particular, > > > > > > > if you reject, you are still in his friend list, and he sees > > > > > > > your presence. > > > > > > > > > > > > No, thats not true. When I subscribe to someone, they appear > > > > > > in my buddy > > > > > > list, and the status is marked as "pending authorization" > > > > > > until the time > > > > > > that they provide authorization. Once that happens, I see > > > > their real > > > > > > presence. On the other side, when someone subscribes to me, I > > > > > > get a screen > > > > > > pop, which asks for "approve", "approve and add", or "reject". > > > > > > Approve/reject have the meanings we've been discussing - they > > > > > > approve or > > > > > > reject the subscription. "approve and add" approves the > > > > > > subscription, and > > > > > > also sends a subscription from me back to them, adding them > > > > > > to my buddy > > > > > > list. > > > > > > > > > > > > I've been using this tool for several years. I think I can > > > > > make these > > > > > > statements with soem confidence that they are correct. > > > > > > > > > > > > -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 mhammer@cisco.com Fri Jul 13 16:04:06 2001 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 QAA16959 for ; Fri, 13 Jul 2001 16:04:06 -0400 (EDT) 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 QAA19386; Fri, 13 Jul 2001 16:04:05 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id AKY02452; Fri, 13 Jul 2001 16:04:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20010713154923.00b28a98@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Jul 2001 16:06:27 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] Another idea for presence authorization Cc: Jonathan Rosenberg , Jonathan Rosenberg , "'Rosen, Brian'" , Jonathan Rosenberg , "'Boyer, D G (Dave)'" , "'adam.roach@ericsson.com'" , Ben Campbell , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 6260 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: Jonathan, I don't think I am in disagreement, but diagram below is modified slightly to represent what I am understanding from this thread. Mike At 09:48 AM 7/13/2001 -0400, Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Wednesday, July 11, 2001 1:54 PM > > To: Jonathan Rosenberg > > Cc: Jonathan Rosenberg; 'Rosen, Brian'; Jonathan Rosenberg; > > 'Boyer, D G > > (Dave)'; 'adam.roach@ericsson.com'; Ben Campbell; > > simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > At 01:36 PM 7/11/2001 -0400, Jonathan Rosenberg wrote: > > > > >How does the authorizer know whether there are subscriptions > > waiting to be > > >authorized? Sure, the system can send the authorizer email, > > or an IM, but > > >that means there is no way to manage that information on the > > client side > > >using an automata which queries the user, or applies local policy to > > >generate an authorization. I'm interested in this primarily > > because that is > > >what systems do today. When I start Yahoo, it tells me who > > has tried to > > >subscribe, and allows me to accept/reject each of those. Are > > we willing to > > >say that a tool cannot be written that queries the user for > > this, that the > > >only way is to send email or IM or something else which is only > > >interpretable by a human? Not that using IM or email is bad; > > just that we > > >may want to enable an automata to handle the information. > > > > I should have described the transaction there. I believe > > that is related > > to the watcherinfo stuff you were working on. I was viewing > > that as part > > of A above. Once you log into the system, the authentication > > process sends > > you a message indicating who requested subscription and your response > > contains the authorize/deny per request. The key is that A, > > B, and C are > > independent transactions only related together by the system > > application. > >I haven't been saying anything different!!! > >What I am proposing is that things look like this: > > > > | | | > | |SUB B's pres.winfo (1)| > | |<---------------------| B's client turns on > | |200 OK (2)| > | |--------------------->| > | |NOTIFY (3)| > | |--------------------->| B notified of other > | |200 OK (4)| parties presence > | |<---------------------| > | | | > |SUB B's pres (5) | | > |----------------->| | > |202 Accepted (6)| | >pending |<-----------------|NOTIFY "A Pending" (9)| >state | |--------------------->|B learns that A is > | |200 OK (10)| requesting subscription > | |<---------------------| | | |Terminal-human interaction | | |to auth and set permissions > | |SET? policy (11)| > | |<---------------------|Application-specific > controls | |200 OK |uploaded | |--------------------->| > |NOTIFY B's pres(7)| | >success |<-----------------| |A gets notified if B's >control >or fail |200 OK (8) | |conditions are met, >else some >state |----------------->| |notify of status from >pending > to subsciption > success or fail > Subscriber Presence Presentity > A Server B In the previous version, it was not clear whether presence was being sent. Hope this clarifies that. Subscription pending can be assumed. No? >The SUBSCRIBE from the subscriber A is messages 5-8. The two transactions >(SUB/202 and NOT/200) are totally independent from everything else. It does >NOT wait on human intervention or anything else, PERIOD. It is regular, >normal, SUB/NOT for presence, with each of the two transactions completing >instantly. > >Before this subscription, when B's client was activated, it send a subscribe >to the presence server, to watch to see who subscribers to B. Thats sequence >(1)-(4), two SIP transactions. Now, when A subscribes, INDEPENDENTLY of the >processing that subscription, the presence server sends a NOTIFY to B, >telling them of the change (messages 9-10). > >Now, after that there are no pending transactions, or anything like that. At >some point, indefinitely into the future, B can send policy about A to the >presence server, message(s) 11. I've been arguing that we should NOT specify >SIP for this, but rather, view this as a web application that sets >potentially complex policy. However, I have also been arguing that it would >be nice to allow this to provide the most common and basic function, >approval/rejection, without a web browser. This would be needed, for >example, if I want the application software at B to provide a screen pop >when A subscribes, with two buttons "accept" and "reject". Clicking either >approves or rejects the subscription. Thats still an HTTP request, I am >arguing, but it doesn't require B to have a user filling in a form. The >client application at B can figure out what HTTP form POST request to send >to approve or reject, based on information in the NOTIFY, message (9). > >-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 From ds708@columbia.edu Fri Jul 13 17:20:13 2001 Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.59.159]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17246 for ; Fri, 13 Jul 2001 17:20:12 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA06716; Fri, 13 Jul 2001 17:19:55 -0400 (EDT) From: "Daniel Starin" To: "'Rosen, Brian'" Cc: Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 17:20:20 -0400 Message-ID: <002d01c10be1$9fa9d860$a1a20681@DSTARIN2> 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, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4FBEA8857476D311A03300204840E1CF044657B2@whq-msgusr-02.pit.comms.marconi.com> Importance: Normal Content-Length: 26175 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: There is no difference... that makes sense... IMO, required functionality with respect to this thread must allow for 1. the PS to request that B sets a policy if none exists for a given watcher who has subscribed 2. the User being watched to be able to set a policy in advance (he may wish to allow anyone from a particular domain to automatically subscribe with a particular policy) 3. the User being watched to be able to change the policy at any given time after a policy has been set 4. the User to be able to subscribe or not to any of these notifications And with respect to the Yes / No discussion I had with Brian... No policy being set on the PS by User B means to User A either that his subscription is pending or that it has been rejected, this allows User B to reject the subscription without giving away any of his presence. Dan -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, July 13, 2001 4:21 PM To: 'Daniel Starin' Subject: RE: [Simple] Another idea for presence authorization What is the difference between a yes with no policy and nothing? You send 200 OK to the subscribe before you have yes/no You don't send Notify until you get policy. If you got a no, how would you treat it differently than a yes with no policy? There is nothing you can do with the yes/no without policy except admire it. Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 4:12 PM > To: 'Rosen, Brian' > Subject: RE: [Simple] Another idea for presence authorization > > > Yes that's what I mean... > > Some authorization must occur before a Notify may be sent... > > From what I understand.... > > - Authorization must occur before notification > - Policies for the distribution of presence to a particular > Watcher from > the PS may be set or modified at any time... before or after a > subscription request and these policies could be arbitrarily > complex... > (in the before case... you may say to your PS that all of > sip:*@columbia.edu has authorization to subscribe to you with a > specified policy) > > - The only aspect of the authorization for subscription process which > can be strictly specified for any and all subscription > requests is that > the subscription will be accepted or denied. If accepted, > the accepting > UA has the responsibility to set a policy (the UA may already have a > policy in place... see above). If rejected, no notifications of > presence may be sent and it must not be possible for the requesting UA > to infer any presence information. > > From these understanding... I come to the conclusion that we > can either > specify a yes / no format and leave policies to be specified > at another > time or specify a complete policy format. > > IMO, I feel that there is something different between policy > (which can > be set or updated at any time and defines the type of > information which > will be sent to a subscribing user) and the initial yes / no response > (which specifies if any information at all will be sent to a user).... > > Comments? > > Dan > > > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, July 13, 2001 3:05 PM > To: 'Daniel Starin'; 'Jonathan Rosenberg' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > Hmmm, I didn't look at Jonathan's diagram close enough. > I would think that A would not get a Notify until > after B authorized. So, message (7) can't happen > until after (11). Is that what you mean? > > Brian > > > -----Original Message----- > > From: Daniel Starin [mailto:ds708@columbia.edu] > > Sent: Friday, July 13, 2001 2:58 PM > > To: 'Rosen, Brian' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > That's the thing... I think Jonathan says that an initial > > notify will be > > sent in step 7 of his diagram.... "NOTIFY B's pres"..... before > > authorization... as far as I can tell. I agree with his > > diagram in that > > policies should be set at any time... but I think that > initial notify > > needs some authorization.... > > > > Dan > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Friday, July 13, 2001 2:44 PM > > To: 'Daniel Starin' > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > I think we are agreeing that you can subscribe without > > authorization. I think we agree that you don't get any > > Notifies unless you are authorized. > > > > I do note in Jonathan's text that he used 202 for the > > actual presence subscription acceptance, but 200 for > > watcherinfo. I don't quite understand that - it seemed > > to be either an information leak, or some kind of a typo. > > > > We could hold a discussion on DoS. The issue is which is > > better - lots of subscriptions that succeed, or lots of > > subscriptions that silently fail? If you explicitly fail > > (not authorized), information leaks - not good. > > > > Brian > > > > > -----Original Message----- > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > Sent: Friday, July 13, 2001 2:37 PM > > > To: 'Rosen, Brian' > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > If I understand correctly, you and Jonathan have come to a > > consensus > > > that an initial Notify (specifying presence information) > > > should be given > > > without authorization? This seems to me to be similar to the > > > AIM model > > > in which user A may add user B to a buddy list without > > authorization. > > > User B may later set a specific policy on user A (like > > blocking them). > > > > > > If this is the case, I disagree with both of you and I > believe that > > > rfc2779 (the presence requirements) does as well. It > > specifies.. "The > > > principle controlling a PRESENTITY MUST be able to control which > > > WATCHERS can observe that PRESENTITY's PRESENCE > INFORMATION" ... By > > > allowing any random watcher to access even one Notify without > > > authorization, this requirement is not met... > > > > > > Dan > > > > > > -----Original Message----- > > > From: simple-admin@mailman.dynamicsoft.com > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > > Rosen, Brian > > > Sent: Friday, July 13, 2001 1:46 PM > > > To: 'Daniel Starin' > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Daniel > > > > > > I suppose it's a matter of semantics, but I would claim > > > that you change authorization to change what information is > > revealed. > > > Whether you do it before subscription, or after it, > > > you are changing your authorization. > > > > > > I also think you made my point. Authorization is complex, > > > and standardizing it, at this time, is unwise. > > > > > > Of what use is it to the PS if I give it a yes/no, > > > and don't give it a what? So you can accept the > > > subscription but not send a Notify? Not interesting > > > methinks. Besides, as you observe, even yes/no is really > > > transient (yes, at the moment, but I could change my mind). > > > All the more reason to get it out of the protocol. > > > Even Jonathan proposes to accept the subscription without > > > authorization. > > > > > > We are talking about a complex interaction between the watcher > > > and the PS as well as the presentity and the PS. Until > > > there is a much greater degree of consensus on how that > > > interaction takes place, I don't see the value in > > > specifying any of it. Jonathan wants to standardize a simple > > > yes/no authorization so that it can be done in the GUI of > > > B's UA, and not take a browser. I think that such an idea > > > is far too limiting to be useful, and encourages lowest > > > common denominator thinking. It doesn't even give you > > > the basic notion of presenting the name of the watcher - > > > all you get is the existing SIP headers, which would in > > > many cases be a cryptic email identifier. I'd much rather > > > go the other direction and start talking about sending > > > an XML credential in the authorization request, and an > > > XML policy in the authorization reply. > > > > > > BTW, I wanted to make sure that everyone agrees that > > > authorization is not authentication; if the PS requires > > > authentication for the subscription (and it ought to), > > > then authentication must take place before the subscribe > > > will be acted upon. All authorization is dealing with is > > > what B will let you see, and it ranges from nothing to > > > a lot. Authentication is proving to the satisfaction > > > of the PS that you are who you claim to be. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > > Sent: Friday, July 13, 2001 1:05 PM > > > > To: 'Daniel Starin'; 'Rosen, Brian' > > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > Revised.... I hit send by accident... > > > > > > > > The difference is, when I authorize someone, the way that > > I interact > > > > with them may change throughout the time that the > > > subscription exists. > > > > One minute I may want them to see detailed presence (IN / OUT / > > > > AWAY / BUSY) while the next minute I may want them to see OUT > > > > regardless > > > > of what my actual presence is. The fact is, for the most > > > part, these > > > > decisions are based on what is happening currently, not > > what happens > > > > when the request for the subscription takes place. At > the time of > > > > request, all that is usually known is Yes, you may subscribe, > > > > or no, you > > > > may not. If you happen to know that you also want to give > > > > the person a > > > > specific type of presence (IN / OUT) at that time than so > > be it, you > > > > can (after you have said Yes to their subscription). But > > > many times, > > > > you will not know specifically how you want your presence to be > > > > distributed to those that subscribe to you at the moment they > > > > request a > > > > subscription. > > > > > > > > Thus a Yes/No authorization should be specified. > > Possibly a "what" > > > > should be specified as well but these two things should > > be distinct. > > > > > > > > As for credentials. I agree that some form of > credentials must be > > > > specified for Yes / No authorization... > > > > > > > > Dan > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Friday, July 13, 2001 12:05 PM > > > > To: 'Daniel Starin' > > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > I don't agree. Authorization is specific - who and what. > > > > You can't split it up like that, or at least there is very > > > > little value in doing so. If I gave you a standardized way > > > > to say yes/no, but don't give you a standardized way to > > > > specify what, the implementation is just as proprietary. > > > > > > > > Also don't forget the credentials part. In order to even say > > > > yes/no, you need the credentials. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > > > Sent: Friday, July 13, 2001 11:59 AM > > > > > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > Brian, > > > > > > > > > > It seems that there are two different issues you are > > discussing. > > > > > > > > > > One is whether or not A (the watcher) may access any of > > > B's presence > > > > > information (a binary decision) and the other is IF B indeed > > > > > allows A to > > > > > access presence information, what type of information will > > > > that be, - > > > > > In/Out, In / Busy/Out, etc. > > > > > > > > > > Regardless of what complex presence information a user may > > > > have, there > > > > > will always be an initial binary decision (yes, you can > > > > > access presence > > > > > or no, you cannot). Because this decision must always be > > > > > made for each > > > > > and every subscription request which is made, it may be > > > > reasonable to > > > > > standardize how this will be done. > > > > > > > > > > -Dan > > > > > > > > > > -----Original Message----- > > > > > From: simple-admin@mailman.dynamicsoft.com > > > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > > > > Rosen, Brian > > > > > Sent: Friday, July 13, 2001 10:44 AM > > > > > To: 'Jonathan Rosenberg' > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > Let's start over. > > > > > > > > > > A and B are both UAs. I think we all agree on that. > > > > > You want a PS. I'll agree they are useful. If you > > > > > want a PS, then its a UAS to A. I want to talk > > > > > about how PS and B interact. > > > > > > > > > > I don't know if you would allow me to go there, but, > > > > > just for a moment, indulge me and let's talk about > > > > > A and B without PS. A wants to know B's presence. > > > > > Okay, so A subscribes to B, and B supplies > > > > > presence as NOTIFYies. This all works fine, although > > > > > it ignores how B authorizes A. In particular, > > > > > in order for B to authorize A, he needs credentials > > > > > for A (who are you). While the standard SIP headers > > > > > might be enough, in many cases, you need more > > > > > information about A. How do you get that? > > > > > > > > > > With my example, everything (except credentials) is > > > > > fine. In particular, B can send presence to A > > > > > because it's really B (B's real UA) that is the > > > > > source of the presence info, and we would all agree > > > > > that B the human interacts with B's UA in some > > > > > implementation dependent manner for B's UA to > > > > > find out the actual presence state. > > > > > > > > > > Are we okay here? > > > > > > > > > > Now let's put in the PS. In your model, just for now, > > > > > skip authorization, and let's just talk about how > > > > > B tells PS that B's presence state changed. > > > > > I can see two possibilities. The one I like is that > > > > > PS subscribes to B's presence. The other is that > > > > > there is a new header that is used for that purpose. > > > > > My way is real simple, takes no extension, and does > > > > > exactly what you want. When B changes his presence, > > > > > he does so on his UA (exactly as above), and Notifies > > > > > PS. PS, in turn, Notifies A. Simple, clean, effective. > > > > > > > > > > So what is PS? I claim it's a straightforward > > > > > B2BUA. Instead of subscribing directly to B, PS > > > > > subscribes to B and A (as well as any other authorized > > > > > watchers) subscribe to PS. > > > > > > > > > > Now, you introduce watcherinfo. I'm okay with that. > > > > > B subscribes to watcherinfo on PS, and PS Notifies B > > > > > of subscriptions. > > > > > > > > > > Now, back to authorization > > > > > > > > > > In several posts, I've stated that I'm interested in a > > > > > rich notion of presence. That covers a LOT of territory, > > > > > but let me give you a small example. Suppose I have > > > > > 3 states in my presence model In-Busy-Out. For > > > > > some watchers, I will give them one of these three > > > > > states. However, there are some people for whom I > > > > > don't want them to know that I'm in, but busy. They > > > > > only get two states - In/Out. This is all pretty easy > > > > > stuff. > > > > > > > > > > However, my authorization is not binary. I have to > > > > > tell PS which of the two models A gets. Two URLs > > > > > are not enough. > > > > > > > > > > So, authorization, I claim, is complex. You need > > > > > arbitrary credentials from A, and you need arbitrary outputs > > > > > from B. Thus, I claim, there is no sensible way to define the > > > > > authorization process between B and PS, or for that > > > > > matter, between A and PS in a standardized way. > > > > > > > > > > One way to help would be to at least tell A where > > > > > to go to at least FIND OUT how to get authorization. > > > > > Simply subscribing (attempting to subscribe) is not enough. > > > > > If you want to turn that around and say, fine, let's > > > > > also tell B how to authorize, I can't argue. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > Sent: Friday, July 13, 2001 10:03 AM > > > > > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D G (Dave)'; > > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > > Subject: RE: [Simple] Another idea for presence > authorization > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > > > Subject: RE: [Simple] Another idea for presence > > authorization > > > > > > > > > > > > > > > > > > > > > Well, I'm real confused. > > > > > > > 1. The "automata" you are talking about -- I don't > > understand > > > > > > > what role it has in the context of this > discussion. We have > > > > > > > "servers" that have presence information and > "clients" that > > > > > > > want to get it. The server is an entity operating on > > > > behalf of a > > > > > > > presentity. The client is an entity operating on > > behalf of a > > > > > > > watcher. In > > > > > > > SIP terms, we have a UAC and a UAS. > > > > > > > > > > > > Its more complex than that, Brian. > > > > > > > > > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > > > > > > > > > > > > > > > > > | | | > > > > > > | |SUB B's pres.winfo (1)| > > > > > > | |<---------------------| B's > > > > > > client turns on > > > > > > | |200 OK (2)| > > > > > > | |--------------------->| > > > > > > | |NOTIFY (3)| > > > > > > | |--------------------->| > > > > > > | |200 OK (4)| > > > > > > | |<---------------------| > > > > > > | | | > > > > > > |SUB B's pres (5) | | > > > > > > |----------------->| | > > > > > > |202 Accepted (6)| | > > > > > > |<-----------------|NOTIFY "A Pending" (9)| > > > > > > |NOTIFY B's pres(7)|--------------------->|B > > > > learns that A > > > > > > |<-----------------|200 OK (10)| > > > > subscribed > > > > > > |200 OK (8)|<---------------------| > > > > > > |----------------->| | > > > > > > | | | > > > > > > | | | > > > > > > | |Set policy (11)| > > > > > > | |<---------------------| > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > | | | > > > > > > > > > > > > Subscriber Presence Presentity > > > > > > A Server B > > > > > > > > > > > > > The UAS > > > > > > > is the agent of the presentity, and the UAC is > the agent of > > > > > > > the watcher. Now, where is this automata? In the UAS? > > > > > > > The UAS is what the protocol defines, you seem to > > want to deal > > > > > > > with something that is not the UAS but is > connecting to it. > > > > > > > > > > > > There is a presence server, which is a UAC for some > > > > > > transactions, and UAS > > > > > > for others. There is a subscriber A, which is a UAC > for some > > > > > > transactions > > > > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). There is a > > > > > presentity > > > > > > application for B, which is a UAC for some transactions > > > > > > (SUBSCRIBE to its > > > > > > watcherinfo), and a UAS for others. Remember, UAC/UAS is a > > > > > > per transaction > > > > > > role. The presence server is the "agent" for B, in > the sense > > > > > > that it accepts > > > > > > subscribes and generates notifies on B's behalf. > How it finds > > > > > > out about the > > > > > > presence state is another orthogonal piece, not > specified in > > > > > > the SUB/NOT > > > > > > mechanism. Typically, its through registrations or through > > > > > > direct upload of > > > > > > a presence document. > > > > > > > > > > > > > > > > > > > > > > > > > > At the moment, the model I'm imagining in your head is one > > > > > > > where the presentity and the watcher are both > UACs and there > > > > > > > is a centralized UAS - the sort of AIM/Yahoo/MSN messenger > > > > > > > idea. If that is the model you are pushing, I > want to push > > > > > > > back. The UAC is the agent of the presentity, the > > UAS is the > > > > > > > agent of the watcher, and the UAC doesn't need > any protocol > > > > > > > to the presentity -- it "is" the presentity. > > > > > > > > > > > > I cannot map these statements to sensible definitions of > > > > > UAC and UAS, > > > > > > presentity or watcher. Please see above. > > > > > > > > > > > > > If you want > > > > > > > the presentity to be a UAC, then we need more than what we > > > > > > > are talking about on this thread - we need to standardize > > > > > > > how the UAC at the presentity tells the UAS how to > > change its > > > > > > > presence, and then we get into all sorts of issues about > > > > > > > how this model supports rich presence information > (since it > > > > > > > requires that two UACs AND the UAS all have the same > > > > > > > capabilities). How the UAC interacts with the presentity > > > > > > > is not the place we standardize. It could be split into > > > > > > > a "client" and a "server", but the interactions > > between those > > > > > > > pieces are complex, and I don't see how we could > standardize > > > > > > > them right now. > > > > > > > > > > > > I still cannot understand any of the above based on the > > > > > > definitions of UAC > > > > > > and UAS in the bis spec, and presentity, watcher, etc. > > > > > from rfc2778. > > > > > > > > > > > > > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > > > > > Yes, you get a message when someone puts you in his > > > > > > > friend list. However, what it is asking you seems to be > > > > > > > whether you want to put him in YOUR buddy list. In > > > particular, > > > > > > > if you reject, you are still in his friend list, > and he sees > > > > > > > your presence. > > > > > > > > > > > > No, thats not true. When I subscribe to someone, > they appear > > > > > > in my buddy > > > > > > list, and the status is marked as "pending authorization" > > > > > > until the time > > > > > > that they provide authorization. Once that happens, I see > > > > their real > > > > > > presence. On the other side, when someone > subscribes to me, I > > > > > > get a screen > > > > > > pop, which asks for "approve", "approve and add", > or "reject". > > > > > > Approve/reject have the meanings we've been > discussing - they > > > > > > approve or > > > > > > reject the subscription. "approve and add" approves the > > > > > > subscription, and > > > > > > also sends a subscription from me back to them, adding them > > > > > > to my buddy > > > > > > list. > > > > > > > > > > > > I've been using this tool for several years. I think I can > > > > > make these > > > > > > statements with soem confidence that they are correct. > > > > > > > > > > > > -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 Brian.Rosen@marconi.com Fri Jul 13 17:52:45 2001 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 RAA17355 for ; Fri, 13 Jul 2001 17:52:45 -0400 (EDT) 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 RAA18387; Fri, 13 Jul 2001 17:52:42 -0400 (EDT) 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 RAA13669; Fri, 13 Jul 2001 17:52:45 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <35STY831>; Fri, 13 Jul 2001 17:52:44 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044657BC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Daniel Starin'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Fri, 13 Jul 2001 17:52:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 28661 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: Keep in mind that some folks want to be able to keep A in the dark about an authorization disposition. Johnathan's sequence has the subscription accepted with a 202, and subsequent receipt of a Notify without a 200. While I questioned that, if you send a 200 for the Subscribe always, or send 202 for the Subscribe always, it's okay. What you can't do if you want to keep A in the dark is to send a 202 before you get authorization, and a 200 for a subsequent Subscribe after authorization. Those who want to let A know the state could use 202 and 200 appropriately to do that. I personally would prefer to let A know when there was no policy decision by rejecting the subscription. When a policy decision was in place, I would always allow a Subscribe with a 200. I would show Presence state as constant Out, and it wouldn't change for those I did not authorize. Brian > -----Original Message----- > From: Daniel Starin [mailto:ds708@columbia.edu] > Sent: Friday, July 13, 2001 5:20 PM > To: 'Rosen, Brian' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > There is no difference... that makes sense... > > IMO, required functionality with respect to this thread must > allow for > > 1. the PS to request that B sets a policy if none exists for a given > watcher who has subscribed > 2. the User being watched to be able to set a policy in > advance (he may > wish to allow anyone from a particular domain to > automatically subscribe > with a particular policy) > 3. the User being watched to be able to change the policy at any given > time after a policy has been set > 4. the User to be able to subscribe or not to any of these > notifications > > And with respect to the Yes / No discussion I had with Brian... > > No policy being set on the PS by User B means to User A > either that his > subscription is pending or that it has been rejected, this > allows User B > to reject the subscription without giving away any of his presence. > > > Dan > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, July 13, 2001 4:21 PM > To: 'Daniel Starin' > Subject: RE: [Simple] Another idea for presence authorization > > What is the difference between a yes with no policy > and nothing? > > You send 200 OK to the subscribe before you have yes/no > You don't send Notify until you get policy. > > If you got a no, how would you treat it differently than > a yes with no policy? > > There is nothing you can do with the yes/no without > policy except admire it. > > Brian > > > -----Original Message----- > > From: Daniel Starin [mailto:ds708@columbia.edu] > > Sent: Friday, July 13, 2001 4:12 PM > > To: 'Rosen, Brian' > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Yes that's what I mean... > > > > Some authorization must occur before a Notify may be sent... > > > > From what I understand.... > > > > - Authorization must occur before notification > > - Policies for the distribution of presence to a particular > > Watcher from > > the PS may be set or modified at any time... before or after a > > subscription request and these policies could be arbitrarily > > complex... > > (in the before case... you may say to your PS that all of > > sip:*@columbia.edu has authorization to subscribe to you with a > > specified policy) > > > > - The only aspect of the authorization for subscription > process which > > can be strictly specified for any and all subscription > > requests is that > > the subscription will be accepted or denied. If accepted, > > the accepting > > UA has the responsibility to set a policy (the UA may already have a > > policy in place... see above). If rejected, no notifications of > > presence may be sent and it must not be possible for the > requesting UA > > to infer any presence information. > > > > From these understanding... I come to the conclusion that we > > can either > > specify a yes / no format and leave policies to be specified > > at another > > time or specify a complete policy format. > > > > IMO, I feel that there is something different between policy > > (which can > > be set or updated at any time and defines the type of > > information which > > will be sent to a subscribing user) and the initial yes / > no response > > (which specifies if any information at all will be sent to > a user).... > > > > Comments? > > > > Dan > > > > > > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Friday, July 13, 2001 3:05 PM > > To: 'Daniel Starin'; 'Jonathan Rosenberg' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > Hmmm, I didn't look at Jonathan's diagram close enough. > > I would think that A would not get a Notify until > > after B authorized. So, message (7) can't happen > > until after (11). Is that what you mean? > > > > Brian > > > > > -----Original Message----- > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > Sent: Friday, July 13, 2001 2:58 PM > > > To: 'Rosen, Brian' > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > That's the thing... I think Jonathan says that an initial > > > notify will be > > > sent in step 7 of his diagram.... "NOTIFY B's pres"..... before > > > authorization... as far as I can tell. I agree with his > > > diagram in that > > > policies should be set at any time... but I think that > > initial notify > > > needs some authorization.... > > > > > > Dan > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Friday, July 13, 2001 2:44 PM > > > To: 'Daniel Starin' > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > I think we are agreeing that you can subscribe without > > > authorization. I think we agree that you don't get any > > > Notifies unless you are authorized. > > > > > > I do note in Jonathan's text that he used 202 for the > > > actual presence subscription acceptance, but 200 for > > > watcherinfo. I don't quite understand that - it seemed > > > to be either an information leak, or some kind of a typo. > > > > > > We could hold a discussion on DoS. The issue is which is > > > better - lots of subscriptions that succeed, or lots of > > > subscriptions that silently fail? If you explicitly fail > > > (not authorized), information leaks - not good. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > > Sent: Friday, July 13, 2001 2:37 PM > > > > To: 'Rosen, Brian' > > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > If I understand correctly, you and Jonathan have come to a > > > consensus > > > > that an initial Notify (specifying presence information) > > > > should be given > > > > without authorization? This seems to me to be similar to the > > > > AIM model > > > > in which user A may add user B to a buddy list without > > > authorization. > > > > User B may later set a specific policy on user A (like > > > blocking them). > > > > > > > > If this is the case, I disagree with both of you and I > > believe that > > > > rfc2779 (the presence requirements) does as well. It > > > specifies.. "The > > > > principle controlling a PRESENTITY MUST be able to control which > > > > WATCHERS can observe that PRESENTITY's PRESENCE > > INFORMATION" ... By > > > > allowing any random watcher to access even one Notify without > > > > authorization, this requirement is not met... > > > > > > > > Dan > > > > > > > > -----Original Message----- > > > > From: simple-admin@mailman.dynamicsoft.com > > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > > > Rosen, Brian > > > > Sent: Friday, July 13, 2001 1:46 PM > > > > To: 'Daniel Starin' > > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > Daniel > > > > > > > > I suppose it's a matter of semantics, but I would claim > > > > that you change authorization to change what information is > > > revealed. > > > > Whether you do it before subscription, or after it, > > > > you are changing your authorization. > > > > > > > > I also think you made my point. Authorization is complex, > > > > and standardizing it, at this time, is unwise. > > > > > > > > Of what use is it to the PS if I give it a yes/no, > > > > and don't give it a what? So you can accept the > > > > subscription but not send a Notify? Not interesting > > > > methinks. Besides, as you observe, even yes/no is really > > > > transient (yes, at the moment, but I could change my mind). > > > > All the more reason to get it out of the protocol. > > > > Even Jonathan proposes to accept the subscription without > > > > authorization. > > > > > > > > We are talking about a complex interaction between the watcher > > > > and the PS as well as the presentity and the PS. Until > > > > there is a much greater degree of consensus on how that > > > > interaction takes place, I don't see the value in > > > > specifying any of it. Jonathan wants to standardize a simple > > > > yes/no authorization so that it can be done in the GUI of > > > > B's UA, and not take a browser. I think that such an idea > > > > is far too limiting to be useful, and encourages lowest > > > > common denominator thinking. It doesn't even give you > > > > the basic notion of presenting the name of the watcher - > > > > all you get is the existing SIP headers, which would in > > > > many cases be a cryptic email identifier. I'd much rather > > > > go the other direction and start talking about sending > > > > an XML credential in the authorization request, and an > > > > XML policy in the authorization reply. > > > > > > > > BTW, I wanted to make sure that everyone agrees that > > > > authorization is not authentication; if the PS requires > > > > authentication for the subscription (and it ought to), > > > > then authentication must take place before the subscribe > > > > will be acted upon. All authorization is dealing with is > > > > what B will let you see, and it ranges from nothing to > > > > a lot. Authentication is proving to the satisfaction > > > > of the PS that you are who you claim to be. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > > > Sent: Friday, July 13, 2001 1:05 PM > > > > > To: 'Daniel Starin'; 'Rosen, Brian' > > > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > Revised.... I hit send by accident... > > > > > > > > > > The difference is, when I authorize someone, the way that > > > I interact > > > > > with them may change throughout the time that the > > > > subscription exists. > > > > > One minute I may want them to see detailed presence > (IN / OUT / > > > > > AWAY / BUSY) while the next minute I may want them to see OUT > > > > > regardless > > > > > of what my actual presence is. The fact is, for the most > > > > part, these > > > > > decisions are based on what is happening currently, not > > > what happens > > > > > when the request for the subscription takes place. At > > the time of > > > > > request, all that is usually known is Yes, you may subscribe, > > > > > or no, you > > > > > may not. If you happen to know that you also want to give > > > > > the person a > > > > > specific type of presence (IN / OUT) at that time than so > > > be it, you > > > > > can (after you have said Yes to their subscription). But > > > > many times, > > > > > you will not know specifically how you want your > presence to be > > > > > distributed to those that subscribe to you at the moment they > > > > > request a > > > > > subscription. > > > > > > > > > > Thus a Yes/No authorization should be specified. > > > Possibly a "what" > > > > > should be specified as well but these two things should > > > be distinct. > > > > > > > > > > As for credentials. I agree that some form of > > credentials must be > > > > > specified for Yes / No authorization... > > > > > > > > > > Dan > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > Sent: Friday, July 13, 2001 12:05 PM > > > > > To: 'Daniel Starin' > > > > > Cc: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com > > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > I don't agree. Authorization is specific - who and what. > > > > > You can't split it up like that, or at least there is very > > > > > little value in doing so. If I gave you a standardized way > > > > > to say yes/no, but don't give you a standardized way to > > > > > specify what, the implementation is just as proprietary. > > > > > > > > > > Also don't forget the credentials part. In order to even say > > > > > yes/no, you need the credentials. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Daniel Starin [mailto:ds708@columbia.edu] > > > > > > Sent: Friday, July 13, 2001 11:59 AM > > > > > > To: 'Rosen, Brian'; 'Jonathan Rosenberg' > > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > > Subject: RE: [Simple] Another idea for presence > authorization > > > > > > > > > > > > > > > > > > Brian, > > > > > > > > > > > > It seems that there are two different issues you are > > > discussing. > > > > > > > > > > > > One is whether or not A (the watcher) may access any of > > > > B's presence > > > > > > information (a binary decision) and the other is IF > B indeed > > > > > > allows A to > > > > > > access presence information, what type of information will > > > > > that be, - > > > > > > In/Out, In / Busy/Out, etc. > > > > > > > > > > > > Regardless of what complex presence information a user may > > > > > have, there > > > > > > will always be an initial binary decision (yes, you can > > > > > > access presence > > > > > > or no, you cannot). Because this decision must always be > > > > > > made for each > > > > > > and every subscription request which is made, it may be > > > > > reasonable to > > > > > > standardize how this will be done. > > > > > > > > > > > > -Dan > > > > > > > > > > > > -----Original Message----- > > > > > > From: simple-admin@mailman.dynamicsoft.com > > > > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > > > > > Rosen, Brian > > > > > > Sent: Friday, July 13, 2001 10:44 AM > > > > > > To: 'Jonathan Rosenberg' > > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > > Subject: RE: [Simple] Another idea for presence > authorization > > > > > > > > > > > > Let's start over. > > > > > > > > > > > > A and B are both UAs. I think we all agree on that. > > > > > > You want a PS. I'll agree they are useful. If you > > > > > > want a PS, then its a UAS to A. I want to talk > > > > > > about how PS and B interact. > > > > > > > > > > > > I don't know if you would allow me to go there, but, > > > > > > just for a moment, indulge me and let's talk about > > > > > > A and B without PS. A wants to know B's presence. > > > > > > Okay, so A subscribes to B, and B supplies > > > > > > presence as NOTIFYies. This all works fine, although > > > > > > it ignores how B authorizes A. In particular, > > > > > > in order for B to authorize A, he needs credentials > > > > > > for A (who are you). While the standard SIP headers > > > > > > might be enough, in many cases, you need more > > > > > > information about A. How do you get that? > > > > > > > > > > > > With my example, everything (except credentials) is > > > > > > fine. In particular, B can send presence to A > > > > > > because it's really B (B's real UA) that is the > > > > > > source of the presence info, and we would all agree > > > > > > that B the human interacts with B's UA in some > > > > > > implementation dependent manner for B's UA to > > > > > > find out the actual presence state. > > > > > > > > > > > > Are we okay here? > > > > > > > > > > > > Now let's put in the PS. In your model, just for now, > > > > > > skip authorization, and let's just talk about how > > > > > > B tells PS that B's presence state changed. > > > > > > I can see two possibilities. The one I like is that > > > > > > PS subscribes to B's presence. The other is that > > > > > > there is a new header that is used for that purpose. > > > > > > My way is real simple, takes no extension, and does > > > > > > exactly what you want. When B changes his presence, > > > > > > he does so on his UA (exactly as above), and Notifies > > > > > > PS. PS, in turn, Notifies A. Simple, clean, effective. > > > > > > > > > > > > So what is PS? I claim it's a straightforward > > > > > > B2BUA. Instead of subscribing directly to B, PS > > > > > > subscribes to B and A (as well as any other authorized > > > > > > watchers) subscribe to PS. > > > > > > > > > > > > Now, you introduce watcherinfo. I'm okay with that. > > > > > > B subscribes to watcherinfo on PS, and PS Notifies B > > > > > > of subscriptions. > > > > > > > > > > > > Now, back to authorization > > > > > > > > > > > > In several posts, I've stated that I'm interested in a > > > > > > rich notion of presence. That covers a LOT of territory, > > > > > > but let me give you a small example. Suppose I have > > > > > > 3 states in my presence model In-Busy-Out. For > > > > > > some watchers, I will give them one of these three > > > > > > states. However, there are some people for whom I > > > > > > don't want them to know that I'm in, but busy. They > > > > > > only get two states - In/Out. This is all pretty easy > > > > > > stuff. > > > > > > > > > > > > However, my authorization is not binary. I have to > > > > > > tell PS which of the two models A gets. Two URLs > > > > > > are not enough. > > > > > > > > > > > > So, authorization, I claim, is complex. You need > > > > > > arbitrary credentials from A, and you need arbitrary outputs > > > > > > from B. Thus, I claim, there is no sensible way to > define the > > > > > > authorization process between B and PS, or for that > > > > > > matter, between A and PS in a standardized way. > > > > > > > > > > > > One way to help would be to at least tell A where > > > > > > to go to at least FIND OUT how to get authorization. > > > > > > Simply subscribing (attempting to subscribe) is not enough. > > > > > > If you want to turn that around and say, fine, let's > > > > > > also tell B how to authorize, I can't argue. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > > Sent: Friday, July 13, 2001 10:03 AM > > > > > > > To: 'Rosen, Brian'; Jonathan Rosenberg; 'Boyer, D > G (Dave)'; > > > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > > > Subject: RE: [Simple] Another idea for presence > > authorization > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > > > > > Sent: Wednesday, July 11, 2001 2:25 PM > > > > > > > > To: 'Jonathan Rosenberg'; 'Boyer, D G (Dave)'; > > > > > > > > 'adam.roach@ericsson.com'; Ben Campbell > > > > > > > > Cc: simple@mailman.dynamicsoft.com > > > > > > > > Subject: RE: [Simple] Another idea for presence > > > authorization > > > > > > > > > > > > > > > > > > > > > > > > Well, I'm real confused. > > > > > > > > 1. The "automata" you are talking about -- I don't > > > understand > > > > > > > > what role it has in the context of this > > discussion. We have > > > > > > > > "servers" that have presence information and > > "clients" that > > > > > > > > want to get it. The server is an entity operating on > > > > > behalf of a > > > > > > > > presentity. The client is an entity operating on > > > behalf of a > > > > > > > > watcher. In > > > > > > > > SIP terms, we have a UAC and a UAS. > > > > > > > > > > > > > > Its more complex than that, Brian. > > > > > > > > > > > > > > I'll repeat the picture I just sent in a previous email: > > > > > > > > > > > > > > > > > > > > > > > > > > > > | | | > > > > > > > | |SUB B's pres.winfo (1)| > > > > > > > | |<---------------------| B's > > > > > > > client turns on > > > > > > > | |200 OK (2)| > > > > > > > | |--------------------->| > > > > > > > | |NOTIFY (3)| > > > > > > > | |--------------------->| > > > > > > > | |200 OK (4)| > > > > > > > | |<---------------------| > > > > > > > | | | > > > > > > > |SUB B's pres (5) | | > > > > > > > |----------------->| | > > > > > > > |202 Accepted (6)| | > > > > > > > |<-----------------|NOTIFY "A Pending" (9)| > > > > > > > |NOTIFY B's pres(7)|--------------------->|B > > > > > learns that A > > > > > > > |<-----------------|200 OK (10)| > > > > > subscribed > > > > > > > |200 OK (8)|<---------------------| > > > > > > > |----------------->| | > > > > > > > | | | > > > > > > > | | | > > > > > > > | |Set policy (11)| > > > > > > > | |<---------------------| > > > > > > > | | | > > > > > > > | | | > > > > > > > | | | > > > > > > > | | | > > > > > > > > > > > > > > Subscriber Presence Presentity > > > > > > > A Server B > > > > > > > > > > > > > > > The UAS > > > > > > > > is the agent of the presentity, and the UAC is > > the agent of > > > > > > > > the watcher. Now, where is this automata? In the UAS? > > > > > > > > The UAS is what the protocol defines, you seem to > > > want to deal > > > > > > > > with something that is not the UAS but is > > connecting to it. > > > > > > > > > > > > > > There is a presence server, which is a UAC for some > > > > > > > transactions, and UAS > > > > > > > for others. There is a subscriber A, which is a UAC > > for some > > > > > > > transactions > > > > > > > (the SUBSCRIBE) and UAS for others (the NOTIFY). > There is a > > > > > > presentity > > > > > > > application for B, which is a UAC for some transactions > > > > > > > (SUBSCRIBE to its > > > > > > > watcherinfo), and a UAS for others. Remember, > UAC/UAS is a > > > > > > > per transaction > > > > > > > role. The presence server is the "agent" for B, in > > the sense > > > > > > > that it accepts > > > > > > > subscribes and generates notifies on B's behalf. > > How it finds > > > > > > > out about the > > > > > > > presence state is another orthogonal piece, not > > specified in > > > > > > > the SUB/NOT > > > > > > > mechanism. Typically, its through registrations > or through > > > > > > > direct upload of > > > > > > > a presence document. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At the moment, the model I'm imagining in your > head is one > > > > > > > > where the presentity and the watcher are both > > UACs and there > > > > > > > > is a centralized UAS - the sort of > AIM/Yahoo/MSN messenger > > > > > > > > idea. If that is the model you are pushing, I > > want to push > > > > > > > > back. The UAC is the agent of the presentity, the > > > UAS is the > > > > > > > > agent of the watcher, and the UAC doesn't need > > any protocol > > > > > > > > to the presentity -- it "is" the presentity. > > > > > > > > > > > > > > I cannot map these statements to sensible definitions of > > > > > > UAC and UAS, > > > > > > > presentity or watcher. Please see above. > > > > > > > > > > > > > > > If you want > > > > > > > > the presentity to be a UAC, then we need more > than what we > > > > > > > > are talking about on this thread - we need to > standardize > > > > > > > > how the UAC at the presentity tells the UAS how to > > > change its > > > > > > > > presence, and then we get into all sorts of > issues about > > > > > > > > how this model supports rich presence information > > (since it > > > > > > > > requires that two UACs AND the UAS all have the same > > > > > > > > capabilities). How the UAC interacts with the > presentity > > > > > > > > is not the place we standardize. It could be split into > > > > > > > > a "client" and a "server", but the interactions > > > between those > > > > > > > > pieces are complex, and I don't see how we could > > standardize > > > > > > > > them right now. > > > > > > > > > > > > > > I still cannot understand any of the above based on the > > > > > > > definitions of UAC > > > > > > > and UAS in the bis spec, and presentity, watcher, etc. > > > > > > from rfc2778. > > > > > > > > > > > > > > > > > > > > > > > 2. I never used Yahoo Messenger. I just loaded it. > > > > > > > > Yes, you get a message when someone puts you in his > > > > > > > > friend list. However, what it is asking you seems to be > > > > > > > > whether you want to put him in YOUR buddy list. In > > > > particular, > > > > > > > > if you reject, you are still in his friend list, > > and he sees > > > > > > > > your presence. > > > > > > > > > > > > > > No, thats not true. When I subscribe to someone, > > they appear > > > > > > > in my buddy > > > > > > > list, and the status is marked as "pending authorization" > > > > > > > until the time > > > > > > > that they provide authorization. Once that happens, I see > > > > > their real > > > > > > > presence. On the other side, when someone > > subscribes to me, I > > > > > > > get a screen > > > > > > > pop, which asks for "approve", "approve and add", > > or "reject". > > > > > > > Approve/reject have the meanings we've been > > discussing - they > > > > > > > approve or > > > > > > > reject the subscription. "approve and add" approves the > > > > > > > subscription, and > > > > > > > also sends a subscription from me back to them, > adding them > > > > > > > to my buddy > > > > > > > list. > > > > > > > > > > > > > > I've been using this tool for several years. I > think I can > > > > > > make these > > > > > > > statements with soem confidence that they are correct. > > > > > > > > > > > > > > -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 HUITEMA@windows.microsoft.com Mon Jul 16 13:27:38 2001 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01679 for ; Mon, 16 Jul 2001 13:27:37 -0400 (EDT) Received: from 157.54.9.101 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 16 Jul 2001 09:43:58 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 16 Jul 2001 09:46:16 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 16 Jul 2001 09:46:16 -0700 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(5.0.2195.2966); Mon, 16 Jul 2001 09:45:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Another idea for presence authorization Date: Mon, 16 Jul 2001 09:45:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Another idea for presence authorization Thread-Index: AcEK1h33ebIROMIFSkSszHWgvrRshwDPxEKw From: "Christian Huitema" To: "Rosen, Brian" , "Bobby Sardana" , "Subir Saha" Cc: "Jonathan Rosenberg" , X-OriginalArrivalTime: 16 Jul 2001 16:45:15.0481 (UTC) FILETIME=[B068C490:01C10E16] Content-Length: 1939 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA01679 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: > We have a presence server and a presence client. > We can standardize the interface between the presence > server and the presence client, but we can't standardize > the interface between the presence server and the presentity > (a human). I think that Brian is right on target here. In the basic implementation, there is no reason that the authorization to SUBSCRIBE be treated differently from the authorization to INVITE. Very precisely, we don't do anything specific about the authorization to INVITE because we assume that the INVITE triggers a "ringing", would get the attention of the user, and would get an explicit authorization, e.g. by lifting the handset after checking the caller-id. The basic implementation of SUBSCRIBE should do just that: the subscription goes all the way to an UA under direct control of the user, triggers some form of alerting, and is explicitly authorized by the user through some interface. The more complex scenarios occur when the UA wants to delegate publishing rights to a server in the middle of the network. This is a substantial deviation from the basic SIP architecture. The equivalent for INVITE would be to send the calls to a gateway, and to use some form of out of band mechanism such AUTH or NOTIFY in order to decide whether or not that specific call should be picked. Indeed, I am not so naïve as to believe that all implementations will be end-to-end. I am just restating the obvious: the remote control of a publisher from the edge of the network is a complex operation that allows for a variety of solutions. Which solution you use is part of the reason why you pick a specific publisher; it may involve the support of specific authorization mechanisms, special rule for merging presence information from multiple terminals, support for various authentication schemes, etc. I don't believe that we can easily standardize that, and I doubt that we should. -- Christian Huitema From jdrosen@dynamicsoft.com Mon Jul 16 23:40:37 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03276 for ; Mon, 16 Jul 2001 23:40:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6H3e0RX006830; Mon, 16 Jul 2001 23:40:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYCV174>; Mon, 16 Jul 2001 23:40:35 -0400 Message-ID: From: Jonathan Rosenberg To: "'Rosen, Brian'" , "'Daniel Starin'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Mon, 16 Jul 2001 23:40:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2780 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: > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, July 13, 2001 5:53 PM > To: 'Daniel Starin' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > Keep in mind that some folks want to be able to > keep A in the dark about an authorization disposition. > Johnathan's sequence has the subscription accepted > with a 202, and subsequent receipt of a Notify > without a 200. While I questioned that, if you > send a 200 for the Subscribe always, or send > 202 for the Subscribe always, it's okay. What > you can't do if you want to keep A in the dark > is to send a 202 before you get authorization, > and a 200 for a subsequent Subscribe after > authorization. Correct. We've discussed this issue extensively on this list, and the impp list previously. The agreement was that it should be possible for a mechanism to exist by which the subscriber cannot tell whether their subscription was approved or rejected, or neither. So, the agreed upon flow was: SUB-------> <-------202 <------NOTIFY 200------> In the case of an authorized subscription, the NOTIFY contains valid presence data. In the case of a denied or pending subscription, it contains syntactically valid, but incorrect or uninteresting information (i.e., always offline). In the case of an authorized subscription, additional NOTIFYs will come as state changes. In the case of an unauthorized or pending subscription, no further NOTIFYs will arrive (except the triggered ones on a SUBSCRIBE refresh). This guarantees that the subscriber cannot know the authorization decision. So, the NOTIFY is always sent, which is why it appeared in my flow. Now, others wanted to support applications where its OK to know that your subscription was definitely accepted or definitely rejected. In that case, a 200 or a 400 response to SUBSCRIBE can be used. Certainly different packages should be able to make differing decisions on this. So, I see no reason why the presence.watcherinfo package cannot allow explicit accept/reject responses to SUBSCRIBE, but presence always uses 202. I even think its OK that within a package, subscriptions for a particular user on a particular server can do this differently than other users on other servers. What you cannot do is have it so that a SUBSCRIBE for A gets a 200 in some cases, 202 in other cases. -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 From jdrosen@dynamicsoft.com Mon Jul 16 23:58:06 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03354 for ; Mon, 16 Jul 2001 23:58:06 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6H3vDRX006921; Mon, 16 Jul 2001 23:57:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <3YYCV188>; Mon, 16 Jul 2001 23:57:48 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christian Huitema'" , "Rosen, Brian" , Bobby Sardana , Subir Saha Cc: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Mon, 16 Jul 2001 23:57:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 4534 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id XAA03354 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: > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Monday, July 16, 2001 12:45 PM > To: Rosen, Brian; Bobby Sardana; Subir Saha > Cc: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > We have a presence server and a presence client. > > We can standardize the interface between the presence > > server and the presence client, but we can't standardize > > the interface between the presence server and the presentity > > (a human). > > The more complex scenarios occur when the UA wants to > delegate publishing rights to a server in the middle of the > network. This is a substantial deviation from the basic SIP > architecture. The equivalent for INVITE would be to send the > calls to a gateway, and to use some form of out of band > mechanism such AUTH or NOTIFY in order to decide whether or > not that specific call should be picked. You mean, like CPL? CGI? Pushing call handling logic into a server is quite common in SIP networks. Pushing policy into servers make sense when the user that makes policy decisions is not always available to make them, or their device is too stupid to ask the user (i.e., using a black phone). It also makes sense when there are multiple devices representing the user, in which case the network server is a natural aggregation point. I don't think anything in the SIP architecture makes this "deviant". > > Indeed, I am not so naïve as to believe that all > implementations will be end-to-end. I am just restating the > obvious: the remote control of a publisher from the edge of > the network is a complex operation that allows for a variety > of solutions. Which solution you use is part of the reason > why you pick a specific publisher; it may involve the support > of specific authorization mechanisms, special rule for > merging presence information from multiple terminals, support > for various authentication schemes, etc. I don't believe that > we can easily standardize that, and I doubt that we should. I think we all agree that this interface can be complex, and that we cannot standardize the full range of it. There also appears to be consensus that pure watcherinfo is useful, to tell a subscriber that wants to know, that a subscription attempt was made. They can then use a server specific approach to set policy (like a web page). The only point of contention is this: because any given authorization protocol cannot ever be sufficient for all needs, does this mean we describe nothing? Brian and Christian say yes. I say no. Lets look at publication of presence, as its a similar issue. A user can have many devices. THe means by which his presence is published to the server for distribution is outside of the basic SUBSCRIBE/NOTIFY presence protocols. The spec allows a server to use as many, or as few mechanisms as it likes. However, there are some useful ones. For example, a REGISTER conveys presence. A presence server can use that to determine some pieces of a user presence. Its not sufficient for rich presence, not by any stretch. But, does that mean that we shouldn't mention its usage? That we should disallow it? I think not. Its a very useful mechanism, and I think it will see a lot of usage. Despite the fact that this can be viewed as the interface between two pieces of a decomposed "real" presence server, the fact is that this is a protocol interface between elements. Unless we ALWAYS want that to be done with a human driving it, we will need some kind of protocol to cover a few cases. All I am proposing is that we define *a* mechanism (not *the* mechanism), which supports only the most simple-minded authorization decision - a binary yes/no that tells the server to send the actual current presence state. I am sure this will not be useful in all cases, but it solves some real requirements today. We can define other things in the future if they need to be standardized. We're not locking ourselves in to this method. We're not requiring it. We're not making it the only method. Its *a* method that can optionally be used. -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 From scoya@cnri.reston.va.us Tue Jul 17 13:43:42 2001 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 NAA05609 for ; Tue, 17 Jul 2001 13:43:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Date: Tue, 17 Jul 2001 13:16:53 -0400 Content-Length: 1142 Subject: [Simple] Note Well 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: Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From randy@psg.com Tue Jul 17 13:44:53 2001 Received: from roam.psg.com (H-135-207-10-122.research.att.com [135.207.10.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05616 for ; Tue, 17 Jul 2001 13:44:52 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Content-Length: 1143 Subject: [Simple] Note Well 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: Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. From mhammer@cisco.com Tue Jul 17 16:47:08 2001 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 QAA06197 for ; Tue, 17 Jul 2001 16:47:08 -0400 (EDT) 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 QAA27880; Tue, 17 Jul 2001 16:47:05 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ALJ10141; Tue, 17 Jul 2001 16:47:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20010717164646.00b44780@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Jul 2001 16:49:33 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] Another idea for presence authorization Cc: "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 3245 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: At 11:40 PM 7/16/2001 -0400, Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Friday, July 13, 2001 5:53 PM > > To: 'Daniel Starin' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > Keep in mind that some folks want to be able to > > keep A in the dark about an authorization disposition. > > Johnathan's sequence has the subscription accepted > > with a 202, and subsequent receipt of a Notify > > without a 200. While I questioned that, if you > > send a 200 for the Subscribe always, or send > > 202 for the Subscribe always, it's okay. What > > you can't do if you want to keep A in the dark > > is to send a 202 before you get authorization, > > and a 200 for a subsequent Subscribe after > > authorization. > >Correct. We've discussed this issue extensively on this list, and the impp >list previously. The agreement was that it should be possible for a >mechanism to exist by which the subscriber cannot tell whether their >subscription was approved or rejected, or neither. So, the agreed upon flow >was: > >SUB-------> ><-------202 > ><------NOTIFY >200------> > >In the case of an authorized subscription, the NOTIFY contains valid >presence data. In the case of a denied or pending subscription, it contains >syntactically valid, but incorrect or uninteresting information (i.e., >always offline). It's still not clear to me what value is gained by a garbage message in return for the bandwidth wasted. It only seems to add confusion to readers of call flows. >In the case of an authorized subscription, additional >NOTIFYs will come as state changes. In the case of an unauthorized or >pending subscription, no further NOTIFYs will arrive (except the triggered >ones on a SUBSCRIBE refresh). > >This guarantees that the subscriber cannot know the authorization decision. >So, the NOTIFY is always sent, which is why it appeared in my flow. > >Now, others wanted to support applications where its OK to know that your >subscription was definitely accepted or definitely rejected. In that case, a >200 or a 400 response to SUBSCRIBE can be used. Certainly different packages >should be able to make differing decisions on this. So, I see no reason why >the presence.watcherinfo package cannot allow explicit accept/reject >responses to SUBSCRIBE, but presence always uses 202. I even think its OK >that within a package, subscriptions for a particular user on a particular >server can do this differently than other users on other servers. What you >cannot do is have it so that a SUBSCRIBE for A gets a 200 in some cases, 202 >in other cases. > > >-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 jdrosen@dynamicsoft.com Tue Jul 17 16:51:15 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06234 for ; Tue, 17 Jul 2001 16:51:14 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HKoZRX013759; Tue, 17 Jul 2001 16:50:35 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 16:51:10 -0400 Message-ID: From: Jonathan Rosenberg To: "'Michael Hammer'" , Jonathan Rosenberg Cc: "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 16:51:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2694 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: > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, July 17, 2001 4:50 PM > To: Jonathan Rosenberg > Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > At 11:40 PM 7/16/2001 -0400, Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Friday, July 13, 2001 5:53 PM > > > To: 'Daniel Starin' > > > Cc: simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > Keep in mind that some folks want to be able to > > > keep A in the dark about an authorization disposition. > > > Johnathan's sequence has the subscription accepted > > > with a 202, and subsequent receipt of a Notify > > > without a 200. While I questioned that, if you > > > send a 200 for the Subscribe always, or send > > > 202 for the Subscribe always, it's okay. What > > > you can't do if you want to keep A in the dark > > > is to send a 202 before you get authorization, > > > and a 200 for a subsequent Subscribe after > > > authorization. > > > >Correct. We've discussed this issue extensively on this > list, and the impp > >list previously. The agreement was that it should be possible for a > >mechanism to exist by which the subscriber cannot tell whether their > >subscription was approved or rejected, or neither. So, the > agreed upon flow > >was: > > > >SUB-------> > ><-------202 > > > ><------NOTIFY > >200------> > > > >In the case of an authorized subscription, the NOTIFY contains valid > >presence data. In the case of a denied or pending > subscription, it contains > >syntactically valid, but incorrect or uninteresting > information (i.e., > >always offline). > > It's still not clear to me what value is gained by a garbage > message in > return for the bandwidth wasted. It only seems to add > confusion to readers > of call flows. > For privacy. I don't want subscribers to be able to determine my authorization policy. Therefore, differing protocol behavior based on authorization policy can't happen. If a NOTIFY only comes if I'm authorized, then I can use the presence, or lack thereof, of an immediate NOTIFY to determine my presence. -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 From jdrosen@dynamicsoft.com Tue Jul 17 16:54:18 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06266 for ; Tue, 17 Jul 2001 16:54:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HKrdRX013820 for ; Tue, 17 Jul 2001 16:53:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 16:54:14 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Tue, 17 Jul 2001 16:54:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 995 Subject: [Simple] new SIMPLE drafts 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: Folks, I've submitted the following drafts to the archives: "An XML Format for Watcher Information", http://www.jdrosen.net/papers/draft-ietf-simple-winfo-format-00.txt "A SIP Event Sub-Package for Watcher Information" http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-00.txt These will appear in the archives shortly, but you can pick them up from above right now. Note that I did NOT include anything on uploading authorization policies in these documents. Its just a pure event package and its data format, useful to allow someone to know that someone else has subscribed to their presence. Comments welcome. -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 From ssaha@lboard.com Tue Jul 17 16:58:14 2001 Received: from exmail.lboard.com (16.node.lboard.com [204.17.219.16] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06311 for ; Tue, 17 Jul 2001 16:58:13 -0400 (EDT) Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19) id <37M2R832>; Tue, 17 Jul 2001 13:57:38 -0700 Message-ID: From: Subir Saha To: "'Michael Hammer'" , Jonathan Rosenberg Cc: "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 13:57:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1386 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: > > Keep in mind that some folks want to be able to > > keep A in the dark about an authorization disposition. > > Johnathan's sequence has the subscription accepted > > with a 202, and subsequent receipt of a Notify > > without a 200. While I questioned that, if you > > send a 200 for the Subscribe always, or send > > 202 for the Subscribe always, it's okay. What > > you can't do if you want to keep A in the dark > > is to send a 202 before you get authorization, > > and a 200 for a subsequent Subscribe after > > authorization. > >Correct. We've discussed this issue extensively on this list, and the impp >list previously. The agreement was that it should be possible for a >mechanism to exist by which the subscriber cannot tell whether their >subscription was approved or rejected, or neither. So, the agreed upon flow >was: > >SUB-------> ><-------202 > ><------NOTIFY >200------> > >In the case of an authorized subscription, the NOTIFY contains valid >presence data. In the case of a denied or pending subscription, it contains >syntactically valid, but incorrect or uninteresting information (i.e., >always offline). It's still not clear to me what value is gained by a garbage message in return for the bandwidth wasted. It only seems to add confusion to readers of call flows. [Subir]Also this gives excelent way for DOS attack on my presence server. Subir From mhammer@cisco.com Tue Jul 17 17:12:00 2001 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 RAA06413 for ; Tue, 17 Jul 2001 17:12:00 -0400 (EDT) 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 RAA28557; Tue, 17 Jul 2001 17:11:59 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ALJ10412; Tue, 17 Jul 2001 17:11:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20010717170636.00b11c88@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Jul 2001 17:14:28 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] Another idea for presence authorization Cc: Jonathan Rosenberg , "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 3481 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: At 04:51 PM 7/17/2001 -0400, Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Tuesday, July 17, 2001 4:50 PM > > To: Jonathan Rosenberg > > Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > At 11:40 PM 7/16/2001 -0400, Jonathan Rosenberg wrote: > > > > > > > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Sent: Friday, July 13, 2001 5:53 PM > > > > To: 'Daniel Starin' > > > > Cc: simple@mailman.dynamicsoft.com > > > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > > > > > > Keep in mind that some folks want to be able to > > > > keep A in the dark about an authorization disposition. > > > > Johnathan's sequence has the subscription accepted > > > > with a 202, and subsequent receipt of a Notify > > > > without a 200. While I questioned that, if you > > > > send a 200 for the Subscribe always, or send > > > > 202 for the Subscribe always, it's okay. What > > > > you can't do if you want to keep A in the dark > > > > is to send a 202 before you get authorization, > > > > and a 200 for a subsequent Subscribe after > > > > authorization. > > > > > >Correct. We've discussed this issue extensively on this > > list, and the impp > > >list previously. The agreement was that it should be possible for a > > >mechanism to exist by which the subscriber cannot tell whether their > > >subscription was approved or rejected, or neither. So, the > > agreed upon flow > > >was: > > > > > >SUB-------> > > ><-------202 > > > > > ><------NOTIFY > > >200------> > > > > > >In the case of an authorized subscription, the NOTIFY contains valid > > >presence data. In the case of a denied or pending > > subscription, it contains > > >syntactically valid, but incorrect or uninteresting > > information (i.e., > > >always offline). > > > > It's still not clear to me what value is gained by a garbage > > message in > > return for the bandwidth wasted. It only seems to add > > confusion to readers > > of call flows. > > > >For privacy. I don't want subscribers to be able to determine my >authorization policy. Therefore, differing protocol behavior based on >authorization policy can't happen. If a NOTIFY only comes if I'm authorized, >then I can use the presence, or lack thereof, of an immediate NOTIFY to >determine my presence. But, I thought that the whole point of the protocol (specifically the Notify) is to provide me presence information if I subscribe and am authorized. I saw these two (Subscribe and Notify) transaction as separate with consistent behavior. In the Subscribe transaction, the behavior is always acknowledge receipt of request, nothing more. Same behavior whether authorized or not. The Notify transaction is only provided to authorized subscribers and always behaves according to policy rules. I didn't think there was an issue when presence was revealed when revealing presence was authorized. Mike >-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 From jdrosen@dynamicsoft.com Tue Jul 17 17:22:42 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06489 for ; Tue, 17 Jul 2001 17:22:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HLM3RX014276; Tue, 17 Jul 2001 17:22:03 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 17:22:38 -0400 Message-ID: From: Jonathan Rosenberg To: "'Michael Hammer'" , Jonathan Rosenberg Cc: Jonathan Rosenberg , "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 17:22:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 3451 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: > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, July 17, 2001 5:14 PM > To: Jonathan Rosenberg > Cc: Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel Starin'; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > At 04:51 PM 7/17/2001 -0400, Jonathan Rosenberg wrote: > > >For privacy. I don't want subscribers to be able to determine my > >authorization policy. Therefore, differing protocol behavior based on > >authorization policy can't happen. If a NOTIFY only comes if > I'm authorized, > >then I can use the presence, or lack thereof, of an > immediate NOTIFY to > >determine my presence. > > But, I thought that the whole point of the protocol (specifically the > Notify) is to provide me presence information if I subscribe and am > authorized. I saw these two (Subscribe and Notify) > transaction as separate > with consistent behavior. Of course these are separate transactions. > > In the Subscribe transaction, the behavior is always > acknowledge receipt of > request, nothing more. Same behavior whether authorized or not. Correct. > > The Notify transaction is only provided to authorized subscribers and > always behaves according to policy rules. I didn't think > there was an > issue when presence was revealed when revealing presence was > authorized. OK, let me try again. Telemarketer A decides to use presence as a great way to sell stuff. When someone logs in, they send them an IM asking to buy the latest widget. So, the telemarketer gets a huge list of addresses, and starts sending SUBSCRIBEs. Most sane people go and upload authorization policy that prohibits the subscription. However, the telemarketer responds to that in an interesting way. When the telemarketer refreshes the subscription, they detect whether a negative authorization, or no authorization has been provided. They then send an email to the user, saying "you still haven't approved subscriptions from widgets inc. Please do so now to find out the latest and greatest!". How do they do this detection? Well they send a SUBSCRIBE. THey get a 200. If a NOTIFY comes immediately, they know they are authorized. If none comes, they know that haven't been authorized, or have been rejected. In other words, since the message sequence differentiates between the case where a subscription was authorized, or was not, an attacker can ascertain authorization information. To combat this, the message sequence must always be the same. In the case of an unauthorized subscriber, the NOTIFY contains a body with something in it. That something is a syntactically valid, but incorrect piece of presence (i.e., joe is offline, no matter whether he is or isn't). Now, the subscriber has no way to determine if their subscription was authorized or not, based on message flows. Now, this issue was discussed a lot on the impp list, and I thought there was consensus that it was a good thing. I think authorization information is sensitive, and I think its important to protect 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 From jdrosen@dynamicsoft.com Tue Jul 17 17:25:38 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06527 for ; Tue, 17 Jul 2001 17:25:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HLOZRX014303; Tue, 17 Jul 2001 17:24:35 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 17:25:10 -0400 Message-ID: From: Jonathan Rosenberg To: "'Subir Saha'" , "'Michael Hammer'" , Jonathan Rosenberg Cc: "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 17:25:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2486 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: > -----Original Message----- > From: Subir Saha [mailto:ssaha@lboard.com] > Sent: Tuesday, July 17, 2001 4:58 PM > To: 'Michael Hammer'; Jonathan Rosenberg > Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > Keep in mind that some folks want to be able to > > > keep A in the dark about an authorization disposition. > > > Johnathan's sequence has the subscription accepted > > > with a 202, and subsequent receipt of a Notify > > > without a 200. While I questioned that, if you > > > send a 200 for the Subscribe always, or send > > > 202 for the Subscribe always, it's okay. What > > > you can't do if you want to keep A in the dark > > > is to send a 202 before you get authorization, > > > and a 200 for a subsequent Subscribe after > > > authorization. > > > >Correct. We've discussed this issue extensively on this > list, and the impp > >list previously. The agreement was that it should be possible for a > >mechanism to exist by which the subscriber cannot tell whether their > >subscription was approved or rejected, or neither. So, the > agreed upon flow > >was: > > > >SUB-------> > ><-------202 > > > ><------NOTIFY > >200------> > > > >In the case of an authorized subscription, the NOTIFY contains valid > >presence data. In the case of a denied or pending > subscription, it contains > >syntactically valid, but incorrect or uninteresting > information (i.e., > >always offline). > > It's still not clear to me what value is gained by a garbage > message in > return for the bandwidth wasted. It only seems to add > confusion to readers > of call flows. > > [Subir]Also this gives excelent way for DOS attack on my > presence server. > Subir > In what way? By making it send a single extra NOTIFY? You already make it send a response to the SUBSCRIBE when you're not authorized. Should we disallow responses to SUBSCRIBE as well? I don't think so. Remember, the NOTIFY is only sent if the subscriber is AUTHENTICATED, so you get traceability. That helps a lot to discourage attacks. -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 From sriramp@nortelnetworks.com Tue Jul 17 17:34:52 2001 Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06578 for ; Tue, 17 Jul 2001 17:34:52 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA06170 for ; Tue, 17 Jul 2001 16:36:40 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 17 Jul 2001 16:27:08 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <30ZQHCG3>; Tue, 17 Jul 2001 16:33:03 -0500 Message-ID: <9A9367D1556AD21182C40000F80930AB04411C91@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: "'Jonathan Rosenberg'" , "'Michael Hammer'" Cc: "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 16:32:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F08.0B1B7B70" X-Orig: Content-Length: 4098 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: 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_01C10F08.0B1B7B70 Content-Type: text/plain; charset="iso-8859-1" Quick observation/question - if you always send off-line (say) and I am indeed offline (see Jonathans email below), haven't you actually divulged presence information? I contend that this is also an information leak. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, July 17, 2001 4:23 PM To: 'Michael Hammer'; Jonathan Rosenberg Cc: Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization ><< snip>>> In other words, since the message sequence differentiates between the case where a subscription was authorized, or was not, an attacker can ascertain authorization information. To combat this, the message sequence must always be the same. In the case of an unauthorized subscriber, the NOTIFY contains a body with something in it. That something is a syntactically valid, but incorrect piece of presence (i.e., joe is offline, no matter whether he is or isn't). <> ------_=_NextPart_001_01C10F08.0B1B7B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Another idea for presence authorization

Quick observation/question - if you always send = off-line (say) and I am indeed offline (see Jonathans email below), = haven't you actually divulged presence information? I contend that this = is also an information leak.

Regards,

Sriram

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: = 972-685-3563
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, July 17, 2001 4:23 PM
To: 'Michael Hammer'; Jonathan Rosenberg
Cc: Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel = Starin';
simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Another idea for presence = authorization




 

><< snip>>>
In other words, since the message sequence = differentiates between the case
where a subscription was authorized, or was not, an = attacker can ascertain
authorization information. To combat this, the = message sequence must always
be the same. In the case of an unauthorized = subscriber, the NOTIFY contains
a body with something in it. That something is a = syntactically valid, but
incorrect piece of presence (i.e., joe is offline, = no matter whether he is
or isn't).
<<snip>>

------_=_NextPart_001_01C10F08.0B1B7B70-- From ssaha@lboard.com Tue Jul 17 17:42:33 2001 Received: from exmail.lboard.com (16.node.lboard.com [204.17.219.16] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06635 for ; Tue, 17 Jul 2001 17:42:33 -0400 (EDT) Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19) id <37M2R8Q3>; Tue, 17 Jul 2001 14:42:09 -0700 Message-ID: From: Subir Saha To: "'Jonathan Rosenberg'" , Subir Saha , "'Michael Hammer'" Cc: "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 14:42:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3196 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: My understanding of the call flow is as below: SUB-------> <-------202 <------NOTIFY 200------> <------NOTIFY 200------> <------NOTIFY 200------> This notify continues till subscription expires. Now you can always change this flow to a single notification under unaothorised condition. But then subscribers will be able to distinguise between "authorised" and "unathorised" subscription! Subir -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, July 17, 2001 2:25 PM To: 'Subir Saha'; 'Michael Hammer'; Jonathan Rosenberg Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization > -----Original Message----- > From: Subir Saha [mailto:ssaha@lboard.com] > Sent: Tuesday, July 17, 2001 4:58 PM > To: 'Michael Hammer'; Jonathan Rosenberg > Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > > > > Keep in mind that some folks want to be able to > > > keep A in the dark about an authorization disposition. > > > Johnathan's sequence has the subscription accepted > > > with a 202, and subsequent receipt of a Notify > > > without a 200. While I questioned that, if you > > > send a 200 for the Subscribe always, or send > > > 202 for the Subscribe always, it's okay. What > > > you can't do if you want to keep A in the dark > > > is to send a 202 before you get authorization, > > > and a 200 for a subsequent Subscribe after > > > authorization. > > > >Correct. We've discussed this issue extensively on this > list, and the impp > >list previously. The agreement was that it should be possible for a > >mechanism to exist by which the subscriber cannot tell whether their > >subscription was approved or rejected, or neither. So, the > agreed upon flow > >was: > > > >SUB-------> > ><-------202 > > > ><------NOTIFY > >200------> > > > >In the case of an authorized subscription, the NOTIFY contains valid > >presence data. In the case of a denied or pending > subscription, it contains > >syntactically valid, but incorrect or uninteresting > information (i.e., > >always offline). > > It's still not clear to me what value is gained by a garbage > message in > return for the bandwidth wasted. It only seems to add > confusion to readers > of call flows. > > [Subir]Also this gives excelent way for DOS attack on my > presence server. > Subir > In what way? By making it send a single extra NOTIFY? You already make it send a response to the SUBSCRIBE when you're not authorized. Should we disallow responses to SUBSCRIBE as well? I don't think so. Remember, the NOTIFY is only sent if the subscriber is AUTHENTICATED, so you get traceability. That helps a lot to discourage attacks. -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 From jdrosen@dynamicsoft.com Tue Jul 17 17:42:34 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06636 for ; Tue, 17 Jul 2001 17:42:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HLfoRX014507; Tue, 17 Jul 2001 17:41:50 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 17:42:25 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sriram Parameswar'" , Jonathan Rosenberg , "'Michael Hammer'" Cc: "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 17:42:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1825 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: -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Tuesday, July 17, 2001 5:33 PM To: 'Jonathan Rosenberg'; 'Michael Hammer' Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization >Quick observation/question - if you always send off-line (say) and I am indeed >offline (see Jonathans email below), haven't you actually divulged presence >information? I contend that this is also an information leak. Of course it doesn't! I can even mathemtically prove it. Here's the proof. Let X represent the information conveyed in the NOTIFY. For simplicity, and without loss of generality, X is a boolean random variable, which takes on the value of a 1 if I'm online, and 0 otherwise. Since the NOTIFY always contains the same value for this random variable (value 0), the probability distribution function of X is readily defined as: P(X=0) = 1 P(X=1) = 0 Now, based on Shannon's definition of information, the information conveyed in a random variable is equal to its entropy. Entropy S is defined as: S = - SUM(i=1 to N) OF (pi ln(pi)) plugging this in: 1 * ln(1) + 0 * ln(0) = 0 + 0 = 0 So, the information conveyed is ZERO. NADA. NOTHING. In non-mathematical terms, if I always tell you its sunny outside, irregardless of whether it is or isn't, can you ever know whether it really is or isnt? Have I told you anything useful? No! -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 From mhammer@cisco.com Tue Jul 17 17:46:16 2001 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 RAA06691 for ; Tue, 17 Jul 2001 17:46:16 -0400 (EDT) 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 RAA29504; Tue, 17 Jul 2001 17:46:15 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ALJ10760; Tue, 17 Jul 2001 17:46:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20010717173606.00b15830@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Jul 2001 17:48:44 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] Another idea for presence authorization Cc: Jonathan Rosenberg , Jonathan Rosenberg , "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 3880 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: At 05:22 PM 7/17/2001 -0400, Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Tuesday, July 17, 2001 5:14 PM > > To: Jonathan Rosenberg > > Cc: Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel Starin'; > > simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > At 04:51 PM 7/17/2001 -0400, Jonathan Rosenberg wrote: > > > > >For privacy. I don't want subscribers to be able to determine my > > >authorization policy. Therefore, differing protocol behavior based on > > >authorization policy can't happen. If a NOTIFY only comes if > > I'm authorized, > > >then I can use the presence, or lack thereof, of an > > immediate NOTIFY to > > >determine my presence. > > > > But, I thought that the whole point of the protocol (specifically the > > Notify) is to provide me presence information if I subscribe and am > > authorized. I saw these two (Subscribe and Notify) > > transaction as separate > > with consistent behavior. > >Of course these are separate transactions. > > > > > In the Subscribe transaction, the behavior is always > > acknowledge receipt of > > request, nothing more. Same behavior whether authorized or not. > >Correct. > > > > > The Notify transaction is only provided to authorized subscribers and > > always behaves according to policy rules. I didn't think > > there was an > > issue when presence was revealed when revealing presence was > > authorized. > >OK, let me try again. Telemarketer A decides to use presence as a great way >to sell stuff. When someone logs in, they send them an IM asking to buy the >latest widget. So, the telemarketer gets a huge list of addresses, and >starts sending SUBSCRIBEs. Most sane people go and upload authorization >policy that prohibits the subscription. However, the telemarketer responds >to that in an interesting way. When the telemarketer refreshes the >subscription, they detect whether a negative authorization, or no >authorization has been provided. They then send an email to the user, saying >"you still haven't approved subscriptions from widgets inc. Please do so now >to find out the latest and greatest!". They could just as easily do this when they notice after some time that I never seem to generate any subsequent Notify. Nothing gained. Once they recognize this behavior, it loses all credibility and value. >How do they do this detection? Well >they send a SUBSCRIBE. THey get a 200. If a NOTIFY comes immediately, they >know they are authorized. If none comes, they know that haven't been >authorized, or have been rejected. > >In other words, since the message sequence differentiates between the case >where a subscription was authorized, or was not, an attacker can ascertain >authorization information. To combat this, the message sequence must always >be the same. In the case of an unauthorized subscriber, the NOTIFY contains >a body with something in it. That something is a syntactically valid, but >incorrect piece of presence (i.e., joe is offline, no matter whether he is >or isn't). Now, the subscriber has no way to determine if their subscription >was authorized or not, based on message flows. > >Now, this issue was discussed a lot on the impp list, and I thought there >was consensus that it was a good thing. I think authorization information is >sensitive, and I think its important to protect it. Still not convinced, but if that was a consensus, I'll be quiet. >-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 From jdrosen@dynamicsoft.com Tue Jul 17 17:46:33 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06696 for ; Tue, 17 Jul 2001 17:46:32 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HLjYRX014577; Tue, 17 Jul 2001 17:45:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 17:46:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Subir Saha'" , Jonathan Rosenberg , "'Michael Hammer'" Cc: "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 17:46:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1464 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: > -----Original Message----- > From: Subir Saha [mailto:ssaha@lboard.com] > Sent: Tuesday, July 17, 2001 5:42 PM > To: 'Jonathan Rosenberg'; Subir Saha; 'Michael Hammer' > Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > My understanding of the call flow is as below: > > SUB-------> > <-------202 > > <------NOTIFY > 200------> > > <------NOTIFY > 200------> > > <------NOTIFY > 200------> > > This notify continues till subscription expires. No, that is NOT the flow for an unauthorized subscribe. > Now you can > always change > this flow to a single notification under unaothorised > condition. That is correct. > But then > subscribers will be able to distinguise between "authorised" and > "unathorised" subscription! No, they cannot. A perfectly valid scenario is that I am indeed offline for an extended period of time. An attacker cannot distinguish the unauthorized case (offline, and no change in that), from the authorized case where I really am offline, and no change in that. -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 From ssaha@lboard.com Tue Jul 17 17:50:33 2001 Received: from exmail.lboard.com (16.node.lboard.com [204.17.219.16] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06767 for ; Tue, 17 Jul 2001 17:50:33 -0400 (EDT) Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19) id <37M2R8R2>; Tue, 17 Jul 2001 14:50:09 -0700 Message-ID: From: Subir Saha To: "'Jonathan Rosenberg'" , Subir Saha , "'Michael Hammer'" Cc: "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 14:50:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1974 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: Probably we are missing one point - the NOTIFY is send by the presence server and even I am really offline - still this NOTIFY will continue on every subscription effort. Am I missing something? Subir -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, July 17, 2001 2:46 PM To: 'Subir Saha'; Jonathan Rosenberg; 'Michael Hammer' Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization > -----Original Message----- > From: Subir Saha [mailto:ssaha@lboard.com] > Sent: Tuesday, July 17, 2001 5:42 PM > To: 'Jonathan Rosenberg'; Subir Saha; 'Michael Hammer' > Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > My understanding of the call flow is as below: > > SUB-------> > <-------202 > > <------NOTIFY > 200------> > > <------NOTIFY > 200------> > > <------NOTIFY > 200------> > > This notify continues till subscription expires. No, that is NOT the flow for an unauthorized subscribe. > Now you can > always change > this flow to a single notification under unaothorised > condition. That is correct. > But then > subscribers will be able to distinguise between "authorised" and > "unathorised" subscription! No, they cannot. A perfectly valid scenario is that I am indeed offline for an extended period of time. An attacker cannot distinguish the unauthorized case (offline, and no change in that), from the authorized case where I really am offline, and no change in that. -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 From jdrosen@dynamicsoft.com Tue Jul 17 17:53:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06824 for ; Tue, 17 Jul 2001 17:53:02 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6HLqORX014659; Tue, 17 Jul 2001 17:52:24 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 17:52:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'Michael Hammer'" , Jonathan Rosenberg Cc: Jonathan Rosenberg , Jonathan Rosenberg , "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 17:52:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2450 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: > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, July 17, 2001 5:49 PM > To: Jonathan Rosenberg > Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel > Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > At 05:22 PM 7/17/2001 -0400, Jonathan Rosenberg wrote: > > >OK, let me try again. Telemarketer A decides to use presence > as a great way > >to sell stuff. When someone logs in, they send them an IM > asking to buy the > >latest widget. So, the telemarketer gets a huge list of > addresses, and > >starts sending SUBSCRIBEs. Most sane people go and upload > authorization > >policy that prohibits the subscription. However, the > telemarketer responds > >to that in an interesting way. When the telemarketer refreshes the > >subscription, they detect whether a negative authorization, or no > >authorization has been provided. They then send an email to > the user, saying > >"you still haven't approved subscriptions from widgets inc. > Please do so now > >to find out the latest and greatest!". > > They could just as easily do this when they notice after some > time that I > never seem to generate any subsequent Notify. Nothing > gained. Once they > recognize this behavior, it loses all credibility and value. Except that its still a valid real scenario. How long does the attacker wait before guessing that they weren't really authorized? No way to know. However, if you don't send a NOTIFY when the attacker is not authorized, they get an immediate, definitive piece of information on their authorization state. In the telemarketer case, it may not be important to know for sure, since they'll spam you anyway. But, there are cases where the authorization data is sensitive. So, forget the mechanism to protect it. The first question to answer is whether there is consensus here that SIMPLE should specify how to ensure the confidentiality of authorization decisions (one can always opt-out and not use it). I say we want that. -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 From pkyzivat@cisco.com Tue Jul 17 18:05:15 2001 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 SAA06921 for ; Tue, 17 Jul 2001 18:05:14 -0400 (EDT) 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 f6HM5Bv19386; Tue, 17 Jul 2001 18:05:11 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-146.cisco.com [161.44.241.146]) by cannon.cisco.com (Mirapoint) with ESMTP id AEQ00066 (AUTH pkyzivat); Tue, 17 Jul 2001 18:05:07 -0400 (EDT) Message-ID: <3B54B566.8B675340@cisco.com> Date: Tue, 17 Jul 2001 18:00:06 -0400 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: "'Sriram Parameswar'" , "'Michael Hammer'" , "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2682 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: I agree with the concept of hiding the difference between not present and not authorized. However, since an initial NOTIFY containing not-present, immediately following the SUBSCRIBE, is information free, why not just agree not to send it? Following a SUBSCRIBE, send nothing until the response is something other than not-present. Do this even if the subscriber *is* authorized and the subscribee is not present. Then everyone just needs to understand that until they do receive a notify they must assume the user in question is not present. Paul Kyzivat Cisco Systems Jonathan Rosenberg wrote: > > > -----Original Message----- > From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] > Sent: Tuesday, July 17, 2001 5:33 PM > To: 'Jonathan Rosenberg'; 'Michael Hammer' > Cc: 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > >Quick observation/question - if you always send off-line (say) and I am > indeed > >offline (see Jonathans email below), haven't you actually divulged presence > > >information? I contend that this is also an information leak. > > Of course it doesn't! I can even mathemtically prove it. Here's the proof. > > Let X represent the information conveyed in the NOTIFY. For simplicity, and > without loss of generality, X is a boolean random variable, which takes on > the value of a 1 if I'm online, and 0 otherwise. Since the NOTIFY always > contains the same value for this random variable (value 0), the probability > distribution function of X is readily defined as: > > P(X=0) = 1 > P(X=1) = 0 > > Now, based on Shannon's definition of information, the information conveyed > in a random variable is equal to its entropy. Entropy S is defined as: > > S = - SUM(i=1 to N) OF (pi ln(pi)) > > plugging this in: > > 1 * ln(1) + 0 * ln(0) = 0 + 0 = 0 > > So, the information conveyed is ZERO. NADA. NOTHING. > > In non-mathematical terms, if I always tell you its sunny outside, > irregardless of whether it is or isn't, can you ever know whether it really > is or isnt? Have I told you anything useful? No! > > -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 ds708@columbia.edu Tue Jul 17 19:01:03 2001 Received: from menyapa.cc.columbia.edu (menyapa.cc.columbia.edu [128.59.59.38]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07120 for ; Tue, 17 Jul 2001 19:01:03 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by menyapa.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA02897; Tue, 17 Jul 2001 19:01:08 -0400 (EDT) From: "Daniel Starin" To: "'Jonathan Rosenberg'" , "'Michael Hammer'" Cc: "'Rosen, Brian'" , Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 19:01:15 -0400 Message-ID: <006301c10f14$61e896c0$a1a20681@DSTARIN2> 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, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Content-Length: 5701 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: So we are all on the same level... As I understand it... there are 6 possible states when user A makes a subscription request to user B... User B is?/The response to the subscription was? 1. Present/Accepted 2. Present/Pending 3. Present/Rejected 4. Not Present/Accepted 5. Not Present/Pending 6. Not Present/Rejected If we send "Offline" notifies every time... If User A gets an Offline notifies... he knows the state is one of the following 2. Present/Pending 3. Present/Rejected 4. Not Present/Accepted 5. Not Present/Pending 6. Not Present/Rejected If User A gets an Online notify.. He knows the state is... 1. Present/Accepted The "Online" notify method does indeed hide whether User A knows whether or not his subscription was Accepted or not. BUT... mathematically, it gives User A something else to play with.... If the probability of all six options are equal... User A knows that when he gets an "Offline" notify that the percent chance that User B is really Offline is 60% (3/5). Mathematically, that is better than the 50/50 probability User A has of knowing if User B is present or not that I will prove that you get without sending any notifies at all... Without sending notifies before authorization... If User A gets No notify... he knows the state is one of the following 2. Present/Pending 3. Present/Rejected 5. Not Present/Pending 6. Not Present/Rejected if he get a Offline notify... he knows the state is.. 4. Not Present/Accepted if he gets an Online notify... he knows the state is 1. Present/Accepted When user A recieves No notifies, there is a 50% chance that User B is Present and a 50% chance that User B is not present... this truly divulges no information about User B's presence to User A.... In this scenario... Jonathans statement is valid... In non-mathematical terms, if I always tell you its sunny outside, irregardless of whether it is or isn't, can you ever know whether it really is or isn't? Have I told you anything useful? No! In the notify every time scenario... this statement does not apply...User A has a 60% chance of knowing User B's true presence REGARDLESS of whether he is authorized or not... In my mind... that makes notifying every time a bad idea... both information wise and bandwidth wise... Either way, I do understand the argument you make Jonathan. You want to exchange the knowledge of whether a subscription is granted or not for a little bit of presence information (that 10%).... I feel, though, that it is more important to protect presence than subscription authorization.... Isn't ABSOLUTELY (so that User A only has a 50/50 chance) hiding your presence what rejecting a subscription is about? -Dan -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Jonathan Rosenberg Sent: Tuesday, July 17, 2001 5:53 PM To: 'Michael Hammer'; Jonathan Rosenberg Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, July 17, 2001 5:49 PM > To: Jonathan Rosenberg > Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel > Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > At 05:22 PM 7/17/2001 -0400, Jonathan Rosenberg wrote: > > >OK, let me try again. Telemarketer A decides to use presence > as a great way > >to sell stuff. When someone logs in, they send them an IM > asking to buy the > >latest widget. So, the telemarketer gets a huge list of > addresses, and > >starts sending SUBSCRIBEs. Most sane people go and upload > authorization > >policy that prohibits the subscription. However, the > telemarketer responds > >to that in an interesting way. When the telemarketer refreshes the > >subscription, they detect whether a negative authorization, or no > >authorization has been provided. They then send an email to > the user, saying > >"you still haven't approved subscriptions from widgets inc. > Please do so now > >to find out the latest and greatest!". > > They could just as easily do this when they notice after some > time that I > never seem to generate any subsequent Notify. Nothing > gained. Once they > recognize this behavior, it loses all credibility and value. Except that its still a valid real scenario. How long does the attacker wait before guessing that they weren't really authorized? No way to know. However, if you don't send a NOTIFY when the attacker is not authorized, they get an immediate, definitive piece of information on their authorization state. In the telemarketer case, it may not be important to know for sure, since they'll spam you anyway. But, there are cases where the authorization data is sensitive. So, forget the mechanism to protect it. The first question to answer is whether there is consensus here that SIMPLE should specify how to ensure the confidentiality of authorization decisions (one can always opt-out and not use it). I say we want that. -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 ds708@columbia.edu Tue Jul 17 19:09:06 2001 Received: from apakabar.cc.columbia.edu (apakabar.cc.columbia.edu [128.59.59.159]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07174 for ; Tue, 17 Jul 2001 19:09:06 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by apakabar.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA26316; Tue, 17 Jul 2001 19:08:48 -0400 (EDT) From: "Daniel Starin" To: "'Jonathan Rosenberg'" , "'Michael Hammer'" Cc: "'Rosen, Brian'" , Subject: RE: [Simple] Another idea for presence authorization Date: Tue, 17 Jul 2001 19:09:19 -0400 Message-ID: <006401c10f15$82b27d70$a1a20681@DSTARIN2> 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, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Content-Length: 5808 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: PLEASE disregard the other message and read this one... I missed a typo which could ruin my argument... So we are all on the same level... As I understand it... there are 6 possible states when user A makes a subscription request to user B... User B is?/The response to the subscription was? 1. Present/Accepted 2. Present/Pending 3. Present/Rejected 4. Not Present/Accepted 5. Not Present/Pending 6. Not Present/Rejected If we send "Offline" notifies every time... If User A gets an Offline notifies... he knows the state is one of the following 2. Present/Pending 3. Present/Rejected 4. Not Present/Accepted 5. Not Present/Pending 6. Not Present/Rejected If User A gets an Online notify.. He knows the state is... 1. Present/Accepted The "Offline" notify method does indeed hide whether User A knows whether or not his subscription was Accepted or not. BUT... mathematically, it gives User A something else to play with.... If the probability of all six options are equal... User A knows that when he gets an "Offline" notify that the percent chance that User B is really Offline is 60% (3/5). Mathematically, that is better than the 50/50 probability User A has of knowing if User B is present or not that I will prove that you get without sending any notifies at all... Without sending notifies before authorization... If User A gets No notify... he knows the state is one of the following 2. Present/Pending 3. Present/Rejected 5. Not Present/Pending 6. Not Present/Rejected if he gets an Offline notify... he knows the state is.. 4. Not Present/Accepted if he gets an Online notify... he knows the state is 1. Present/Accepted When user A receives No notifies, there is a 50% chance that User B is Present and a 50% chance that User B is not present... this truly divulges no information about User B's presence to User A.... In this scenario... Jonathans statement is valid... In non-mathematical terms, if I always tell you its sunny outside, irregardless of whether it is or isn't, can you ever know whether it really is or isn't? Have I told you anything useful? No! In the notify every time scenario... this statement does not apply...User A has a 60% chance of knowing User B's true presence REGARDLESS of whether he is authorized or not... In my mind... that makes notifying every time a bad idea... both information wise and bandwidth wise... Either way, I do understand the argument you make Jonathan. You want to exchange the knowledge of whether a subscription is granted or not for a little bit of presence information (that 10%).... I feel, though, that it is more important to protect presence than subscription authorization.... Isn't ABSOLUTELY (so that User A only has a 50/50 chance) hiding your presence what rejecting a subscription is about? -Dan -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Jonathan Rosenberg Sent: Tuesday, July 17, 2001 5:53 PM To: 'Michael Hammer'; Jonathan Rosenberg Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel Starin'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, July 17, 2001 5:49 PM > To: Jonathan Rosenberg > Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel > Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > At 05:22 PM 7/17/2001 -0400, Jonathan Rosenberg wrote: > > >OK, let me try again. Telemarketer A decides to use presence > as a great way > >to sell stuff. When someone logs in, they send them an IM > asking to buy the > >latest widget. So, the telemarketer gets a huge list of > addresses, and > >starts sending SUBSCRIBEs. Most sane people go and upload > authorization > >policy that prohibits the subscription. However, the > telemarketer responds > >to that in an interesting way. When the telemarketer refreshes the > >subscription, they detect whether a negative authorization, or no > >authorization has been provided. They then send an email to > the user, saying > >"you still haven't approved subscriptions from widgets inc. > Please do so now > >to find out the latest and greatest!". > > They could just as easily do this when they notice after some > time that I > never seem to generate any subsequent Notify. Nothing > gained. Once they > recognize this behavior, it loses all credibility and value. Except that its still a valid real scenario. How long does the attacker wait before guessing that they weren't really authorized? No way to know. However, if you don't send a NOTIFY when the attacker is not authorized, they get an immediate, definitive piece of information on their authorization state. In the telemarketer case, it may not be important to know for sure, since they'll spam you anyway. But, there are cases where the authorization data is sensitive. So, forget the mechanism to protect it. The first question to answer is whether there is consensus here that SIMPLE should specify how to ensure the confidentiality of authorization decisions (one can always opt-out and not use it). I say we want that. -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 jundery@ubiquity.net Wed Jul 18 04:21:09 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA08598 for ; Wed, 18 Jul 2001 04:21:08 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 18 Jul 2001 08:21:07 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Jul 2001 09:21:11 +0100 Message-ID: <3B5546D4.BA2DE17C@ubiquity.net> Date: Wed, 18 Jul 2001 09:20:36 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , "'Sriram Parameswar'" , "'Michael Hammer'" , "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: <3B54B566.8B675340@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2001 08:21:11.0824 (UTC) FILETIME=[9A9C7100:01C10F62] Content-Length: 728 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: Paul Kyzivat wrote: > I agree with the concept of hiding the difference between not present > and not authorized. However, since an initial NOTIFY containing > not-present, immediately following the SUBSCRIBE, is information free, > why not just agree not to send it? Following a SUBSCRIBE, send nothing > until the response is something other than not-present. Do this even if > the subscriber *is* authorized and the subscribee is not present. Then > everyone just needs to understand that until they do receive a notify > they must assume the user in question is not present. > The trouble is CPIM which says a successful SUBSCRIBE must be followed by a NOTIFY, and it would be CPIM that needed to change. James Undery From jundery@ubiquity.net Wed Jul 18 04:36:44 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA08670 for ; Wed, 18 Jul 2001 04:36:43 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 18 Jul 2001 08:36:43 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Jul 2001 09:36:48 +0100 Message-ID: <3B554A7D.B94A9A60@ubiquity.net> Date: Wed, 18 Jul 2001 09:36:13 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Starin CC: "'Jonathan Rosenberg'" , "'Michael Hammer'" , "'Rosen, Brian'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: <006401c10f15$82b27d70$a1a20681@DSTARIN2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2001 08:36:48.0776 (UTC) FILETIME=[C913F880:01C10F64] Content-Length: 6670 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: Daniel Starin wrote: > PLEASE disregard the other message and read this one... I missed a typo > which could ruin my argument... > > So we are all on the same level... > > As I understand it... there are 6 possible states when user A makes a > subscription request to user B... > > User B is?/The response to the subscription was? > > 1. Present/Accepted > 2. Present/Pending > 3. Present/Rejected > 4. Not Present/Accepted > 5. Not Present/Pending > 6. Not Present/Rejected > > If we send "Offline" notifies every time... > > If User A gets an Offline notifies... > he knows the state is one of the following > > 2. Present/Pending > 3. Present/Rejected > 4. Not Present/Accepted > 5. Not Present/Pending > 6. Not Present/Rejected > 6 is not an option a rejected subscription will not generate a NOTIFY > > If User A gets an Online notify.. > He knows the state is... > > 1. Present/Accepted > > The "Offline" notify method does indeed hide whether User A knows > whether or not his subscription was Accepted or not. BUT... > mathematically, it gives User A something else to play with.... If the > probability of all six options are equal... User A knows that when he > gets an "Offline" notify that the percent chance that User B is really > Offline is 60% (3/5). But the probabilities are nowhere near equal (and you are still wrong about 6), assuming there are 1 million people in the world, the fraction of them I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a presentity at random to subscribe to, giving a 50/50 chance. > Mathematically, that is better than the 50/50 > probability User A has of knowing if User B is present or not that I > will prove that you get without sending any notifies at all... > > Without sending notifies before authorization... > > If User A gets No notify... > he knows the state is one of the following > > 2. Present/Pending > 3. Present/Rejected > 5. Not Present/Pending > 6. Not Present/Rejected > > if he gets an Offline notify... > > he knows the state is.. > 4. Not Present/Accepted > > if he gets an Online notify... > > he knows the state is > 1. Present/Accepted > > When user A receives No notifies, there is a 50% chance that User B is > Present and a 50% chance that User B is not present... this truly > divulges no information about User B's presence to User A.... > > In this scenario... Jonathans statement is valid... > > In non-mathematical terms, if I always tell you its sunny outside, > irregardless of whether it is or isn't, can you ever know whether it > really is or isn't? Have I told you anything useful? No! > > In the notify every time scenario... this statement does not > apply...User A has a 60% chance of knowing User B's true presence > REGARDLESS of whether he is authorized or not... > > In my mind... that makes notifying every time a bad idea... both > information wise and bandwidth wise... A CPIM decision not a SIMPLE one. > > > Either way, I do understand the argument you make Jonathan. You want to > exchange the knowledge of whether a subscription is granted or not for a > little bit of presence information (that 10%).... I feel, though, that > it is more important to protect presence than subscription > authorization.... Isn't ABSOLUTELY (so that User A only has a 50/50 > chance) hiding your presence what rejecting a subscription is about? > > -Dan > > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Jonathan > Rosenberg > Sent: Tuesday, July 17, 2001 5:53 PM > To: 'Michael Hammer'; Jonathan Rosenberg > Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel > Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Tuesday, July 17, 2001 5:49 PM > > To: Jonathan Rosenberg > > Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel > > Starin'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > At 05:22 PM 7/17/2001 -0400, Jonathan Rosenberg wrote: > > > > >OK, let me try again. Telemarketer A decides to use presence > > as a great way > > >to sell stuff. When someone logs in, they send them an IM > > asking to buy the > > >latest widget. So, the telemarketer gets a huge list of > > addresses, and > > >starts sending SUBSCRIBEs. Most sane people go and upload > > authorization > > >policy that prohibits the subscription. However, the > > telemarketer responds > > >to that in an interesting way. When the telemarketer refreshes the > > >subscription, they detect whether a negative authorization, or no > > >authorization has been provided. They then send an email to > > the user, saying > > >"you still haven't approved subscriptions from widgets inc. > > Please do so now > > >to find out the latest and greatest!". > > > > They could just as easily do this when they notice after some > > time that I > > never seem to generate any subsequent Notify. Nothing > > gained. Once they > > recognize this behavior, it loses all credibility and value. > > Except that its still a valid real scenario. How long does the attacker > wait > before guessing that they weren't really authorized? No way to know. > However, if you don't send a NOTIFY when the attacker is not authorized, > they get an immediate, definitive piece of information on their > authorization state. In the telemarketer case, it may not be important > to > know for sure, since they'll spam you anyway. But, there are cases where > the > authorization data is sensitive. > > So, forget the mechanism to protect it. The first question to answer is > whether there is consensus here that SIMPLE should specify how to ensure > the > confidentiality of authorization decisions (one can always opt-out and > not > use it). I say we want that. > > -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 pkyzivat@cisco.com Wed Jul 18 10:57:47 2001 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 KAA09748 for ; Wed, 18 Jul 2001 10:57:47 -0400 (EDT) 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 f6IEvbv04721; Wed, 18 Jul 2001 10:57:37 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-146.cisco.com [161.44.241.146]) by cannon.cisco.com (Mirapoint) with ESMTP id AET00139 (AUTH pkyzivat); Wed, 18 Jul 2001 10:57:34 -0400 (EDT) Message-ID: <3B55A2AE.26EFD912@cisco.com> Date: Wed, 18 Jul 2001 10:52:30 -0400 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: James Undery CC: Jonathan Rosenberg , "'Sriram Parameswar'" , "'Michael Hammer'" , "'Rosen, Brian'" , "'Daniel Starin'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: <3B54B566.8B675340@cisco.com> <3B5546D4.BA2DE17C@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1134 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: See below. James Undery wrote: > > Paul Kyzivat wrote: > > > I agree with the concept of hiding the difference between not present > > and not authorized. However, since an initial NOTIFY containing > > not-present, immediately following the SUBSCRIBE, is information free, > > why not just agree not to send it? Following a SUBSCRIBE, send nothing > > until the response is something other than not-present. Do this even if > > the subscriber *is* authorized and the subscribee is not present. Then > > everyone just needs to understand that until they do receive a notify > > they must assume the user in question is not present. > > > > The trouble is CPIM which says a successful SUBSCRIBE must be followed by a > NOTIFY, and it would be CPIM that needed to change. Yes, I was more or less expecting that answer. In reality, this entire discussion about what to divulge ought to take place wrt CPIM, because it is applicable to any IM or presence system. Alternately, one could argue that it is not really a subject for standardization at all, but is merely a quality-of-implementation issue. Paul Kyzivat Cisco Systems From jdrosen@dynamicsoft.com Wed Jul 18 12:30:18 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10043 for ; Wed, 18 Jul 2001 12:30:15 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IGTWRX020186; Wed, 18 Jul 2001 12:29:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 12:30:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Daniel Starin Cc: Jonathan Rosenberg , "'Michael Hammer'" , "'Rosen, Brian'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 18 Jul 2001 12:30:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2513 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: > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Wednesday, July 18, 2001 4:36 AM > To: Daniel Starin > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Another idea for presence authorization > > > > > Daniel Starin wrote: > > > PLEASE disregard the other message and read this one... I > missed a typo > > which could ruin my argument... > > > > So we are all on the same level... > > > > As I understand it... there are 6 possible states when user > A makes a > > subscription request to user B... > > > > User B is?/The response to the subscription was? > > > > 1. Present/Accepted > > 2. Present/Pending > > 3. Present/Rejected > > 4. Not Present/Accepted > > 5. Not Present/Pending > > 6. Not Present/Rejected > > > > If we send "Offline" notifies every time... > > > > If User A gets an Offline notifies... > > he knows the state is one of the following > > > > 2. Present/Pending > > 3. Present/Rejected > > 4. Not Present/Accepted > > 5. Not Present/Pending > > 6. Not Present/Rejected > > > > 6 is not an option a rejected subscription will not generate a NOTIFY > > > > > If User A gets an Online notify.. > > He knows the state is... > > > > 1. Present/Accepted > > > > The "Offline" notify method does indeed hide whether User A knows > > whether or not his subscription was Accepted or not. BUT... > > mathematically, it gives User A something else to play > with.... If the > > probability of all six options are equal... User A knows > that when he > > gets an "Offline" notify that the percent chance that User > B is really > > Offline is 60% (3/5). > > But the probabilities are nowhere near equal (and you are > still wrong about > 6), assuming there are 1 million people in the world, the > fraction of them > I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a > presentity at random to subscribe to, giving a 50/50 chance. Even better, the presence server can randomly change whether the first NOTIFY contains an "offline" or "online" status. This also pushes you back to 50/50. -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 From jundery@ubiquity.net Wed Jul 18 12:38:01 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA10091 for ; Wed, 18 Jul 2001 12:38:00 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 18 Jul 2001 16:37:59 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Jul 2001 17:38:03 +0100 Message-ID: <3B55BB48.D3262484@ubiquity.net> Date: Wed, 18 Jul 2001 17:37:28 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Daniel Starin , "'Michael Hammer'" , "'Rosen, Brian'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2001 16:38:03.0380 (UTC) FILETIME=[03AEE340:01C10FA8] Content-Length: 2409 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: Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Sent: Wednesday, July 18, 2001 4:36 AM > > To: Daniel Starin > > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > > simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > > > > > Daniel Starin wrote: > > > > > PLEASE disregard the other message and read this one... I > > missed a typo > > > which could ruin my argument... > > > > > > So we are all on the same level... > > > > > > As I understand it... there are 6 possible states when user > > A makes a > > > subscription request to user B... > > > > > > User B is?/The response to the subscription was? > > > > > > 1. Present/Accepted > > > 2. Present/Pending > > > 3. Present/Rejected > > > 4. Not Present/Accepted > > > 5. Not Present/Pending > > > 6. Not Present/Rejected > > > > > > If we send "Offline" notifies every time... > > > > > > If User A gets an Offline notifies... > > > he knows the state is one of the following > > > > > > 2. Present/Pending > > > 3. Present/Rejected > > > 4. Not Present/Accepted > > > 5. Not Present/Pending > > > 6. Not Present/Rejected > > > > > > > 6 is not an option a rejected subscription will not generate a NOTIFY > > > > > > > > If User A gets an Online notify.. > > > He knows the state is... > > > > > > 1. Present/Accepted > > > > > > The "Offline" notify method does indeed hide whether User A knows > > > whether or not his subscription was Accepted or not. BUT... > > > mathematically, it gives User A something else to play > > with.... If the > > > probability of all six options are equal... User A knows > > that when he > > > gets an "Offline" notify that the percent chance that User > > B is really > > > Offline is 60% (3/5). > > > > But the probabilities are nowhere near equal (and you are > > still wrong about > > 6), assuming there are 1 million people in the world, the > > fraction of them > > I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a > > presentity at random to subscribe to, giving a 50/50 chance. > > Even better, the presence server can randomly change whether the first > NOTIFY contains an "offline" or "online" status. This also pushes you back > to 50/50. I'd rather not ever send "online" as they then might expect responses from MESSAGEs ;-) James Undery From jdrosen@dynamicsoft.com Wed Jul 18 12:39:24 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10120 for ; Wed, 18 Jul 2001 12:39:23 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6IGcgRX020303; Wed, 18 Jul 2001 12:38:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 12:39:18 -0400 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Jonathan Rosenberg Cc: Daniel Starin , "'Michael Hammer'" , "'Rosen, Brian'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 18 Jul 2001 12:39:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 3359 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: > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Wednesday, July 18, 2001 12:37 PM > To: Jonathan Rosenberg > Cc: Daniel Starin; 'Michael Hammer'; 'Rosen, Brian'; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Another idea for presence authorization > > > > > Jonathan Rosenberg wrote: > > > > > > > > -----Original Message----- > > > From: James Undery [mailto:jundery@ubiquity.net] > > > Sent: Wednesday, July 18, 2001 4:36 AM > > > To: Daniel Starin > > > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > > > simple@mailman.dynamicsoft.com > > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > Daniel Starin wrote: > > > > > > > PLEASE disregard the other message and read this one... I > > > missed a typo > > > > which could ruin my argument... > > > > > > > > So we are all on the same level... > > > > > > > > As I understand it... there are 6 possible states when user > > > A makes a > > > > subscription request to user B... > > > > > > > > User B is?/The response to the subscription was? > > > > > > > > 1. Present/Accepted > > > > 2. Present/Pending > > > > 3. Present/Rejected > > > > 4. Not Present/Accepted > > > > 5. Not Present/Pending > > > > 6. Not Present/Rejected > > > > > > > > If we send "Offline" notifies every time... > > > > > > > > If User A gets an Offline notifies... > > > > he knows the state is one of the following > > > > > > > > 2. Present/Pending > > > > 3. Present/Rejected > > > > 4. Not Present/Accepted > > > > 5. Not Present/Pending > > > > 6. Not Present/Rejected > > > > > > > > > > 6 is not an option a rejected subscription will not > generate a NOTIFY > > > > > > > > > > > If User A gets an Online notify.. > > > > He knows the state is... > > > > > > > > 1. Present/Accepted > > > > > > > > The "Offline" notify method does indeed hide whether > User A knows > > > > whether or not his subscription was Accepted or not. BUT... > > > > mathematically, it gives User A something else to play > > > with.... If the > > > > probability of all six options are equal... User A knows > > > that when he > > > > gets an "Offline" notify that the percent chance that User > > > B is really > > > > Offline is 60% (3/5). > > > > > > But the probabilities are nowhere near equal (and you are > > > still wrong about > > > 6), assuming there are 1 million people in the world, the > > > fraction of them > > > I'd authorise is minimal, meaning only 2 and 5 are likely > if I pick a > > > presentity at random to subscribe to, giving a 50/50 chance. > > > > Even better, the presence server can randomly change > whether the first > > NOTIFY contains an "offline" or "online" status. This also > pushes you back > > to 50/50. > > I'd rather not ever send "online" as they then might expect > responses from > MESSAGEs ;-) Actually, I'm online all the time and don't respond to messages.. I've walked away from my desk, 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 From jundery@ubiquity.net Wed Jul 18 12:47:49 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA10189 for ; Wed, 18 Jul 2001 12:47:48 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 18 Jul 2001 16:47:47 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 18 Jul 2001 17:47:54 +0100 Message-ID: <3B55BD97.831E2B5E@ubiquity.net> Date: Wed, 18 Jul 2001 17:47:19 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Daniel Starin , "'Michael Hammer'" , "'Rosen, Brian'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2001 16:47:54.0258 (UTC) FILETIME=[63DFB720:01C10FA9] Content-Length: 3355 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: Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Sent: Wednesday, July 18, 2001 12:37 PM > > To: Jonathan Rosenberg > > Cc: Daniel Starin; 'Michael Hammer'; 'Rosen, Brian'; > > simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > -----Original Message----- > > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > Sent: Wednesday, July 18, 2001 4:36 AM > > > > To: Daniel Starin > > > > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > > > > simple@mailman.dynamicsoft.com > > > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > > > > > > > > > > > > > > > Daniel Starin wrote: > > > > > > > > > PLEASE disregard the other message and read this one... I > > > > missed a typo > > > > > which could ruin my argument... > > > > > > > > > > So we are all on the same level... > > > > > > > > > > As I understand it... there are 6 possible states when user > > > > A makes a > > > > > subscription request to user B... > > > > > > > > > > User B is?/The response to the subscription was? > > > > > > > > > > 1. Present/Accepted > > > > > 2. Present/Pending > > > > > 3. Present/Rejected > > > > > 4. Not Present/Accepted > > > > > 5. Not Present/Pending > > > > > 6. Not Present/Rejected > > > > > > > > > > If we send "Offline" notifies every time... > > > > > > > > > > If User A gets an Offline notifies... > > > > > he knows the state is one of the following > > > > > > > > > > 2. Present/Pending > > > > > 3. Present/Rejected > > > > > 4. Not Present/Accepted > > > > > 5. Not Present/Pending > > > > > 6. Not Present/Rejected > > > > > > > > > > > > > 6 is not an option a rejected subscription will not > > generate a NOTIFY > > > > > > > > > > > > > > If User A gets an Online notify.. > > > > > He knows the state is... > > > > > > > > > > 1. Present/Accepted > > > > > > > > > > The "Offline" notify method does indeed hide whether > > User A knows > > > > > whether or not his subscription was Accepted or not. BUT... > > > > > mathematically, it gives User A something else to play > > > > with.... If the > > > > > probability of all six options are equal... User A knows > > > > that when he > > > > > gets an "Offline" notify that the percent chance that User > > > > B is really > > > > > Offline is 60% (3/5). > > > > > > > > But the probabilities are nowhere near equal (and you are > > > > still wrong about > > > > 6), assuming there are 1 million people in the world, the > > > > fraction of them > > > > I'd authorise is minimal, meaning only 2 and 5 are likely > > if I pick a > > > > presentity at random to subscribe to, giving a 50/50 chance. > > > > > > Even better, the presence server can randomly change > > whether the first > > > NOTIFY contains an "offline" or "online" status. This also > > pushes you back > > > to 50/50. > > > > I'd rather not ever send "online" as they then might expect > > responses from > > MESSAGEs ;-) > > Actually, I'm online all the time and don't respond to messages.. I've > walked away from my desk, for example. Well I'd rather have "offline" but I am unconvinced by Daniel's argument, so it's a moot point about the random answer in my view. James Undery From ds708@columbia.edu Wed Jul 18 14:28:59 2001 Received: from kachifo.cc.columbia.edu (kachifo.cc.columbia.edu [128.59.59.172]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10507 for ; Wed, 18 Jul 2001 14:28:58 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by kachifo.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA20696; Wed, 18 Jul 2001 14:29:11 -0400 (EDT) From: "Daniel Starin" To: "'James Undery'" Cc: "'Jonathan Rosenberg'" , "'Michael Hammer'" , "'Rosen, Brian'" , Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 18 Jul 2001 14:29:03 -0400 Message-ID: <007101c10fb7$86bcb370$a1a20681@DSTARIN2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3B554A7D.B94A9A60@ubiquity.net> Importance: Normal Content-Length: 8578 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: -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of James Undery Sent: Wednesday, July 18, 2001 4:36 AM To: Daniel Starin Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization Daniel Starin wrote: > PLEASE disregard the other message and read this one... I missed a typo > which could ruin my argument... > > So we are all on the same level... > > As I understand it... there are 6 possible states when user A makes a > subscription request to user B... > > User B is?/The response to the subscription was? > > 1. Present/Accepted > 2. Present/Pending > 3. Present/Rejected > 4. Not Present/Accepted > 5. Not Present/Pending > 6. Not Present/Rejected > > If we send "Offline" notifies every time... > > If User A gets an Offline notifies... > he knows the state is one of the following > > 2. Present/Pending > 3. Present/Rejected > 4. Not Present/Accepted > 5. Not Present/Pending > 6. Not Present/Rejected > >6 is not an option a rejected subscription will not generate a NOTIFY I Wasn't the whole idea of sending a random notify every time to make it so User A does not know whether or not his subscription has been accepted or not? According to Jonathans diagram previously posted in the thread a Notify is sent every time... That would include the times when User B is not present and has set a policy on his PS to reject the subscription... Wouldn't a notify still be sent?.... If a notify is not sent doesn't User A know that his subscription is rejected and then we are back to the telemarketer problem Jonathan described?.... I hold that 6 is an option.... > > If User A gets an Online notify.. > He knows the state is... > > 1. Present/Accepted > > The "Offline" notify method does indeed hide whether User A knows > whether or not his subscription was Accepted or not. BUT... > mathematically, it gives User A something else to play with.... If the > probability of all six options are equal... User A knows that when he > gets an "Offline" notify that the percent chance that User B is really > Offline is 60% (3/5). > But the probabilities are nowhere near equal (and you are still wrong about > 6), assuming there are 1 million people in the world, the fraction of them > I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a > presentity at random to subscribe to, giving a 50/50 chance. Yes, out of the 1 million people, the ones you would authorize is minimal... the people who would request to subscribe to you is minimal as well... User A knows nothing about User B until a subscription is made... thus he has no way of knowing anything about User B's policies with respect to subscription authorization... the only thing he does know is that if he gets an offline notify that there are 5 possible status' and 3 of them specify that User A is offline... > Mathematically, that is better than the 50/50 > probability User A has of knowing if User B is present or not that I > will prove that you get without sending any notifies at all... > > Without sending notifies before authorization... > > If User A gets No notify... > he knows the state is one of the following > > 2. Present/Pending > 3. Present/Rejected > 5. Not Present/Pending > 6. Not Present/Rejected > > if he gets an Offline notify... > > he knows the state is.. > 4. Not Present/Accepted > > if he gets an Online notify... > > he knows the state is > 1. Present/Accepted > > When user A receives No notifies, there is a 50% chance that User B is > Present and a 50% chance that User B is not present... this truly > divulges no information about User B's presence to User A.... > > In this scenario... Jonathans statement is valid... > > In non-mathematical terms, if I always tell you its sunny outside, > irregardless of whether it is or isn't, can you ever know whether it > really is or isn't? Have I told you anything useful? No! > > In the notify every time scenario... this statement does not > apply...User A has a 60% chance of knowing User B's true presence > REGARDLESS of whether he is authorized or not... > > In my mind... that makes notifying every time a bad idea... both > information wise and bandwidth wise... > A CPIM decision not a SIMPLE one. Fine, but I think we have to come to some consensus on the matter... and Jonathan just brought up another idea... sending random online/offline status'..... I am willing to back off if everyone disagrees with me but I think that the "information leak" others have mentioned is because of the reason described above.... Dan > > > Either way, I do understand the argument you make Jonathan. You want to > exchange the knowledge of whether a subscription is granted or not for a > little bit of presence information (that 10%).... I feel, though, that > it is more important to protect presence than subscription > authorization.... Isn't ABSOLUTELY (so that User A only has a 50/50 > chance) hiding your presence what rejecting a subscription is about? > > -Dan > > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Jonathan > Rosenberg > Sent: Tuesday, July 17, 2001 5:53 PM > To: 'Michael Hammer'; Jonathan Rosenberg > Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel > Starin'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Another idea for presence authorization > > > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Tuesday, July 17, 2001 5:49 PM > > To: Jonathan Rosenberg > > Cc: Jonathan Rosenberg; Jonathan Rosenberg; 'Rosen, Brian'; 'Daniel > > Starin'; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Another idea for presence authorization > > > > > > At 05:22 PM 7/17/2001 -0400, Jonathan Rosenberg wrote: > > > > >OK, let me try again. Telemarketer A decides to use presence > > as a great way > > >to sell stuff. When someone logs in, they send them an IM > > asking to buy the > > >latest widget. So, the telemarketer gets a huge list of > > addresses, and > > >starts sending SUBSCRIBEs. Most sane people go and upload > > authorization > > >policy that prohibits the subscription. However, the > > telemarketer responds > > >to that in an interesting way. When the telemarketer refreshes the > > >subscription, they detect whether a negative authorization, or no > > >authorization has been provided. They then send an email to > > the user, saying > > >"you still haven't approved subscriptions from widgets inc. > > Please do so now > > >to find out the latest and greatest!". > > > > They could just as easily do this when they notice after some > > time that I > > never seem to generate any subsequent Notify. Nothing > > gained. Once they > > recognize this behavior, it loses all credibility and value. > > Except that its still a valid real scenario. How long does the attacker > wait > before guessing that they weren't really authorized? No way to know. > However, if you don't send a NOTIFY when the attacker is not authorized, > they get an immediate, definitive piece of information on their > authorization state. In the telemarketer case, it may not be important > to > know for sure, since they'll spam you anyway. But, there are cases where > the > authorization data is sensitive. > > So, forget the mechanism to protect it. The first question to answer is > whether there is consensus here that SIMPLE should specify how to ensure > the > confidentiality of authorization decisions (one can always opt-out and > not > use it). I say we want that. > > -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 ds708@columbia.edu Wed Jul 18 14:48:00 2001 Received: from menyapa.cc.columbia.edu (menyapa.cc.columbia.edu [128.59.59.38]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10598 for ; Wed, 18 Jul 2001 14:47:58 -0400 (EDT) Received: from DSTARIN2 ([129.6.162.161]) by menyapa.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA04279; Wed, 18 Jul 2001 14:47:53 -0400 (EDT) From: "Daniel Starin" To: "'Jonathan Rosenberg'" , "'James Undery'" Cc: "'Michael Hammer'" , "'Rosen, Brian'" , Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 18 Jul 2001 14:48:00 -0400 Message-ID: <007201c10fba$2bf00b10$a1a20681@DSTARIN2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Content-Length: 1091 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA10598 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: > > Even better, the presence server can randomly change > whether the first > > NOTIFY contains an "offline" or "online" status. This also > pushes you back > > to 50/50. > > I'd rather not ever send "online" as they then might expect > responses from > MESSAGEs ;-) > Actually, I'm online all the time and don't respond to messages.. I've > walked away from my desk, for example. So now we are going to send out a random online or offline notify whether or not a subscription is accepted?? This makes the whole point of an accepted subscription (if User B accepts User A's subscription request) moot... Even if you start getting online notifys, you don’t know if they are real or fake... isnt the whole point of presence to let other users know your status... not whether or not you are currently sending messages.... If I accept a subscription request from someone, I want them to know without a doubt my current presence.... I want them to know this regardless of if I am at my desk or not.... This is another argument I could make against the "offline notify" method.... Dan+ From mhammer@cisco.com Wed Jul 18 17:40:03 2001 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 RAA11160 for ; Wed, 18 Jul 2001 17:40:03 -0400 (EDT) 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 RAA00924; Wed, 18 Jul 2001 17:40:01 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ALJ17414; Wed, 18 Jul 2001 17:40:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20010718174003.00b08660@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jul 2001 17:42:30 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] Another idea for presence authorization Cc: "'James Undery'" , Daniel Starin , Jonathan Rosenberg , "'Rosen, Brian'" , simple@mailman.dynamicsoft.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 3164 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: At 12:30 PM 7/18/2001 -0400, Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Sent: Wednesday, July 18, 2001 4:36 AM > > To: Daniel Starin > > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > > simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > > > > > Daniel Starin wrote: > > > > > PLEASE disregard the other message and read this one... I > > missed a typo > > > which could ruin my argument... > > > > > > So we are all on the same level... > > > > > > As I understand it... there are 6 possible states when user > > A makes a > > > subscription request to user B... > > > > > > User B is?/The response to the subscription was? > > > > > > 1. Present/Accepted > > > 2. Present/Pending > > > 3. Present/Rejected > > > 4. Not Present/Accepted > > > 5. Not Present/Pending > > > 6. Not Present/Rejected > > > > > > If we send "Offline" notifies every time... > > > > > > If User A gets an Offline notifies... > > > he knows the state is one of the following > > > > > > 2. Present/Pending > > > 3. Present/Rejected > > > 4. Not Present/Accepted > > > 5. Not Present/Pending > > > 6. Not Present/Rejected > > > > > > > 6 is not an option a rejected subscription will not generate a NOTIFY > > > > > > > > If User A gets an Online notify.. > > > He knows the state is... > > > > > > 1. Present/Accepted > > > > > > The "Offline" notify method does indeed hide whether User A knows > > > whether or not his subscription was Accepted or not. BUT... > > > mathematically, it gives User A something else to play > > with.... If the > > > probability of all six options are equal... User A knows > > that when he > > > gets an "Offline" notify that the percent chance that User > > B is really > > > Offline is 60% (3/5). > > > > But the probabilities are nowhere near equal (and you are > > still wrong about > > 6), assuming there are 1 million people in the world, the > > fraction of them > > I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a > > presentity at random to subscribe to, giving a 50/50 chance. > >Even better, the presence server can randomly change whether the first >NOTIFY contains an "offline" or "online" status. This also pushes you back >to 50/50. Jonathan, I would contend that you were at 50/50 when you sent no messages after the 202 to the subscription. The fact that you are still at 50/50 with random garbage messages means that you have not changed the probability. No knowledge + no knowledge = no knowledge. Even simpler math. Mike >-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 jundery@ubiquity.net Thu Jul 19 04:16:25 2001 Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA12850 for ; Thu, 19 Jul 2001 04:16:24 -0400 (EDT) Received: from no.name.available by drago1.ubiquity.net via smtpd (for [216.173.40.35]) with SMTP; 19 Jul 2001 08:16:24 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 09:16:32 +0100 Message-ID: <3B56973D.5AAAB93B@ubiquity.net> Date: Thu, 19 Jul 2001 09:15:58 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Starin CC: "'Jonathan Rosenberg'" , "'Michael Hammer'" , "'Rosen, Brian'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Another idea for presence authorization References: <007101c10fb7$86bcb370$a1a20681@DSTARIN2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2001 08:16:32.0932 (UTC) FILETIME=[1ECAA640:01C1102B] Content-Length: 5754 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: Daniel Starin wrote: > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of James Undery > Sent: Wednesday, July 18, 2001 4:36 AM > To: Daniel Starin > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Another idea for presence authorization > > Daniel Starin wrote: > > > PLEASE disregard the other message and read this one... I missed a > typo > > which could ruin my argument... > > > > So we are all on the same level... > > > > As I understand it... there are 6 possible states when user A makes a > > subscription request to user B... > > > > User B is?/The response to the subscription was? > > > > 1. Present/Accepted > > 2. Present/Pending > > 3. Present/Rejected > > 4. Not Present/Accepted > > 5. Not Present/Pending > > 6. Not Present/Rejected > > > > If we send "Offline" notifies every time... > > > > If User A gets an Offline notifies... > > he knows the state is one of the following > > > > 2. Present/Pending > > 3. Present/Rejected > > 4. Not Present/Accepted > > 5. Not Present/Pending > > 6. Not Present/Rejected > > > > >6 is not an option a rejected subscription will not generate a NOTIFY > I > > Wasn't the whole idea of sending a random notify every time to make it > so User A does not know whether or not his subscription has been > accepted or not? According to Jonathans diagram previously posted in > the thread a Notify is sent every time... That would include the times > when User B is not present and has set a policy on his PS to reject the > subscription... Wouldn't a notify still be sent?.... If a notify is not > sent doesn't User A know that his subscription is rejected and then we > are back to the telemarketer problem Jonathan described?.... I hold that > 6 is an option.... well I contend there is option 7 present / appearing offline, back to 50/50 > > > > > > If User A gets an Online notify.. > > He knows the state is... > > > > 1. Present/Accepted > > > > The "Offline" notify method does indeed hide whether User A knows > > whether or not his subscription was Accepted or not. BUT... > > mathematically, it gives User A something else to play with.... If the > > probability of all six options are equal... User A knows that when he > > gets an "Offline" notify that the percent chance that User B is really > > Offline is 60% (3/5). > > > But the probabilities are nowhere near equal (and you are still wrong > about > > 6), assuming there are 1 million people in the world, the fraction of > them > > I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a > > presentity at random to subscribe to, giving a 50/50 chance. > > Yes, out of the 1 million people, the ones you would authorize is > minimal... the people who would request to subscribe to you is minimal > as well... User A knows nothing about User B until a subscription is > made... thus he has no way of knowing anything about User B's policies > with respect to subscription authorization... the only thing he does > know is that if he gets an offline notify that there are 5 possible > status' and 3 of them specify that User A is offline... My main point is the very little I remember about Probability is for complex situations it is easy to make assumptions to get the answer you want, I content the argument is flawed as I could say based on the time of day I can make a better than 50/50 guess, for instance as I write this email, I'd bet you're at home probably asleep as it is 5am in New York. > > > > Mathematically, that is better than the 50/50 > > probability User A has of knowing if User B is present or not that I > > will prove that you get without sending any notifies at all... > > > > Without sending notifies before authorization... > > > > If User A gets No notify... > > he knows the state is one of the following > > > > 2. Present/Pending > > 3. Present/Rejected > > 5. Not Present/Pending > > 6. Not Present/Rejected > > > > if he gets an Offline notify... > > > > he knows the state is.. > > 4. Not Present/Accepted > > > > if he gets an Online notify... > > > > he knows the state is > > 1. Present/Accepted > > > > When user A receives No notifies, there is a 50% chance that User B is > > Present and a 50% chance that User B is not present... this truly > > divulges no information about User B's presence to User A.... > > > > In this scenario... Jonathans statement is valid... > > > > In non-mathematical terms, if I always tell you its sunny outside, > > irregardless of whether it is or isn't, can you ever know whether it > > really is or isn't? Have I told you anything useful? No! > > > > In the notify every time scenario... this statement does not > > apply...User A has a 60% chance of knowing User B's true presence > > REGARDLESS of whether he is authorized or not... > > > > In my mind... that makes notifying every time a bad idea... both > > information wise and bandwidth wise... > > > A CPIM decision not a SIMPLE one. > > Fine, but I think we have to come to some consensus on the matter... and > Jonathan just brought up another idea... sending random online/offline > status'..... I am willing to back off if everyone disagrees with me but > I think that the "information leak" others have mentioned is because of > the reason described above.... Well on the information leak I'd disagree, some times the lack of information is information i.e. the other person doesn't want to or can't due to lack of presence respond. The idea of using subscribes from multiple locations breaks the random answer idea. A lie is no good unless it is a consistent lie and I generally prefer just saying offline. James Undery From nsyracus@cnri.reston.va.us Thu Jul 19 07:03:30 2001 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 HAA13304 for ; Thu, 19 Jul 2001 07:03:27 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27164; Thu, 19 Jul 2001 07:02:16 -0400 (EDT) Message-Id: <200107191102.HAA27164@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 Date: Thu, 19 Jul 2001 07:02:16 -0400 Content-Length: 2771 Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-format-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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An XML Based Format for Watcher Information Author(s) : J. Rosenberg Filename : draft-ietf-simple-winfo-format-00.txt Pages : 7 Date : 18-Jul-01 Watchers are defined as entities that request (i.e., subscribe to) information about a user. There is fairly complex state associated with an event subscription, and this state is dynamic. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular subscriber. In order to enable this, a format is needed to describe the state of watchers. This specification describes an XML document format for such state. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-winfo-format-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-winfo-format-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: <20010718142905.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-format-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-format-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142905.I-D@ietf.org> --OtherAccess-- --NextPart-- From nsyracus@cnri.reston.va.us Thu Jul 19 07:07:28 2001 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 HAA13336 for ; Thu, 19 Jul 2001 07:07:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28658; Thu, 19 Jul 2001 07:06:31 -0400 (EDT) Message-Id: <200107191106.HAA28658@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 Date: Thu, 19 Jul 2001 07:06:30 -0400 Content-Length: 2627 Subject: [Simple] I-D ACTION:draft-ietf-simple-im-sdp-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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SDP Extensions for SIP Instant Message Sessions Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-simple-im-sdp-00.txt Pages : 7 Date : 18-Jul-01 SIP instant messages currently follow a pager model, where there is no concept of a message session. It has been proposed that we also need a session based model, where the user experience would be more like a text conference or chat room. This draft proposes an extension to SDP that could be used to describe message sessions A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-im-sdp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-im-sdp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-im-sdp-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: <20010718142401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-im-sdp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-im-sdp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142401.I-D@ietf.org> --OtherAccess-- --NextPart-- From nsyracus@cnri.reston.va.us Thu Jul 19 07:07:32 2001 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 HAA13341 for ; Thu, 19 Jul 2001 07:07:32 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28698; Thu, 19 Jul 2001 07:06:35 -0400 (EDT) Message-Id: <200107191106.HAA28698@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 Date: Thu, 19 Jul 2001 07:06:35 -0400 Content-Length: 2791 Subject: [Simple] I-D ACTION:draft-ietf-simple-im-session-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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Instant Message Sessions Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-simple-im-session-00.txt Pages : 12 Date : 18-Jul-01 The current specification for the SIP MESSAGE request method indicates that SIP instant messages according to a model similar to that of a text pager, in that each message stands alone. There is no concept of a chat session or a text conference where there is a stream of messages that are grouped into a session. This memo proposes a method of describing MESSAGE sessions by treating the message session just like any other media session described in an SDP body in an INVITE request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-im-session-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-im-session-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-im-session-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: <20010718142412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-im-session-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-im-session-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142412.I-D@ietf.org> --OtherAccess-- --NextPart-- From bpenfield@acmepacket.com Thu Jul 19 10:33:43 2001 Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13939 for ; Thu, 19 Jul 2001 10:33:42 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AEF595B01C8; Thu, 19 Jul 2001 10:30:13 -0400 Message-ID: <00c101c1105f$9e05c3c0$2300000a@acmepacket.com> From: "Bob Penfield" To: "James Undery" , "Daniel Starin" Cc: "'Jonathan Rosenberg'" , "'Michael Hammer'" , "'Rosen, Brian'" , References: <007101c10fb7$86bcb370$a1a20681@DSTARIN2> <3B56973D.5AAAB93B@ubiquity.net> Subject: Re: [Simple] Another idea for presence authorization Date: Thu, 19 Jul 2001 10:32:16 -0400 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 Content-Length: 8227 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: The idea of sending a random online/offline NOTIFY when authorization is pending or rejected seems rather strange to me. What happens if they receive an "online" and then attempt to contact that user? Wouldn't the subsequent failure tell the requestor they were not authorized (or at least give them a clue)? Why should we encourage more message traffic half the time? In my mind, personal privacy is paramount and the most sensitive piece of information that should not be divulged is whether or not the authorization is pending or rejected. I think that sending "offline", unless the requestor is authorized and the target user is online is, the right thing to do. The only thing that the requestor has been told is that they cannot reach the target user, they have not been told exactly why. All these probability number being thrown around don't really make sense to me. If I subscribe to Jonathan's presence for the first time, and I get back "offline", I would assume that the authorization is pending or rejected since I have never contacted him before. If I have previously had an IM session with him, I assume "offline" means "offline". The response to the subscription with either a notify (or lack thereof) divulges some information. I think the least sensitive piece of information is saying the target user is "offline". If that state has a greater than 50% probability of being correct, so what? Until I accept your subscription to my presence, I am "offline" to you. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "James Undery" To: "Daniel Starin" Cc: "'Jonathan Rosenberg'" ; "'Michael Hammer'" ; "'Rosen, Brian'" ; Sent: Thursday, July 19, 2001 4:15 AM Subject: Re: [Simple] Another idea for presence authorization > > > Daniel Starin wrote: > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of James Undery > > Sent: Wednesday, July 18, 2001 4:36 AM > > To: Daniel Starin > > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > > simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] Another idea for presence authorization > > > > Daniel Starin wrote: > > > > > PLEASE disregard the other message and read this one... I missed a > > typo > > > which could ruin my argument... > > > > > > So we are all on the same level... > > > > > > As I understand it... there are 6 possible states when user A makes a > > > subscription request to user B... > > > > > > User B is?/The response to the subscription was? > > > > > > 1. Present/Accepted > > > 2. Present/Pending > > > 3. Present/Rejected > > > 4. Not Present/Accepted > > > 5. Not Present/Pending > > > 6. Not Present/Rejected > > > > > > If we send "Offline" notifies every time... > > > > > > If User A gets an Offline notifies... > > > he knows the state is one of the following > > > > > > 2. Present/Pending > > > 3. Present/Rejected > > > 4. Not Present/Accepted > > > 5. Not Present/Pending > > > 6. Not Present/Rejected > > > > > > > >6 is not an option a rejected subscription will not generate a NOTIFY > > I > > > > Wasn't the whole idea of sending a random notify every time to make it > > so User A does not know whether or not his subscription has been > > accepted or not? According to Jonathans diagram previously posted in > > the thread a Notify is sent every time... That would include the times > > when User B is not present and has set a policy on his PS to reject the > > subscription... Wouldn't a notify still be sent?.... If a notify is not > > sent doesn't User A know that his subscription is rejected and then we > > are back to the telemarketer problem Jonathan described?.... I hold that > > 6 is an option.... > > well I contend there is option 7 present / appearing offline, back to 50/50 > > > > > > > > > > > If User A gets an Online notify.. > > > He knows the state is... > > > > > > 1. Present/Accepted > > > > > > The "Offline" notify method does indeed hide whether User A knows > > > whether or not his subscription was Accepted or not. BUT... > > > mathematically, it gives User A something else to play with.... If the > > > probability of all six options are equal... User A knows that when he > > > gets an "Offline" notify that the percent chance that User B is really > > > Offline is 60% (3/5). > > > > > But the probabilities are nowhere near equal (and you are still wrong > > about > > > 6), assuming there are 1 million people in the world, the fraction of > > them > > > I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a > > > presentity at random to subscribe to, giving a 50/50 chance. > > > > Yes, out of the 1 million people, the ones you would authorize is > > minimal... the people who would request to subscribe to you is minimal > > as well... User A knows nothing about User B until a subscription is > > made... thus he has no way of knowing anything about User B's policies > > with respect to subscription authorization... the only thing he does > > know is that if he gets an offline notify that there are 5 possible > > status' and 3 of them specify that User A is offline... > > My main point is the very little I remember about Probability is for complex > situations it is easy to make assumptions to get the answer you want, I > content the argument is flawed as I could say based on the time of day I can > make a better than 50/50 guess, for instance as I write this email, I'd bet > you're at home probably asleep as it is 5am in New York. > > > > > > > > Mathematically, that is better than the 50/50 > > > probability User A has of knowing if User B is present or not that I > > > will prove that you get without sending any notifies at all... > > > > > > Without sending notifies before authorization... > > > > > > If User A gets No notify... > > > he knows the state is one of the following > > > > > > 2. Present/Pending > > > 3. Present/Rejected > > > 5. Not Present/Pending > > > 6. Not Present/Rejected > > > > > > if he gets an Offline notify... > > > > > > he knows the state is.. > > > 4. Not Present/Accepted > > > > > > if he gets an Online notify... > > > > > > he knows the state is > > > 1. Present/Accepted > > > > > > When user A receives No notifies, there is a 50% chance that User B is > > > Present and a 50% chance that User B is not present... this truly > > > divulges no information about User B's presence to User A.... > > > > > > In this scenario... Jonathans statement is valid... > > > > > > In non-mathematical terms, if I always tell you its sunny outside, > > > irregardless of whether it is or isn't, can you ever know whether it > > > really is or isn't? Have I told you anything useful? No! > > > > > > In the notify every time scenario... this statement does not > > > apply...User A has a 60% chance of knowing User B's true presence > > > REGARDLESS of whether he is authorized or not... > > > > > > In my mind... that makes notifying every time a bad idea... both > > > information wise and bandwidth wise... > > > > > A CPIM decision not a SIMPLE one. > > > > Fine, but I think we have to come to some consensus on the matter... and > > Jonathan just brought up another idea... sending random online/offline > > status'..... I am willing to back off if everyone disagrees with me but > > I think that the "information leak" others have mentioned is because of > > the reason described above.... > > Well on the information leak I'd disagree, some times the lack of > information is information i.e. the other person doesn't want to or can't > due to lack of presence respond. The idea of using subscribes from multiple > locations breaks the random answer idea. A lie is no good unless it is a > consistent lie and I generally prefer just saying offline. > > James Undery > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From mhammer@cisco.com Thu Jul 19 10:52:07 2001 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 KAA14013 for ; Thu, 19 Jul 2001 10:52:06 -0400 (EDT) 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 KAA24090; Thu, 19 Jul 2001 10:52:04 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82]) by cia.cisco.com (Mirapoint) with ESMTP id ALO00141; Thu, 19 Jul 2001 10:52:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20010719105353.00b10c50@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 10:54:36 -0400 To: "Bob Penfield" From: Michael Hammer Subject: Re: [Simple] Another idea for presence authorization Cc: "James Undery" , "Daniel Starin" , "'Jonathan Rosenberg'" , "'Rosen, Brian'" , In-Reply-To: <00c101c1105f$9e05c3c0$2300000a@acmepacket.com> References: <007101c10fb7$86bcb370$a1a20681@DSTARIN2> <3B56973D.5AAAB93B@ubiquity.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 8766 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: Bob, My only complaint is that this can be assumed and does not require extra message traffic to tell you that. Mike At 10:32 AM 7/19/2001 -0400, Bob Penfield wrote: >The idea of sending a random online/offline NOTIFY when authorization is >pending or rejected seems rather strange to me. What happens if they receive >an "online" and then attempt to contact that user? Wouldn't the subsequent >failure tell the requestor they were not authorized (or at least give them a >clue)? Why should we encourage more message traffic half the time? > >In my mind, personal privacy is paramount and the most sensitive piece of >information that should not be divulged is whether or not the authorization >is pending or rejected. I think that sending "offline", unless the requestor >is authorized and the target user is online is, the right thing to do. The >only thing that the requestor has been told is that they cannot reach the >target user, they have not been told exactly why. > >All these probability number being thrown around don't really make sense to >me. If I subscribe to Jonathan's presence for the first time, and I get back >"offline", I would assume that the authorization is pending or rejected >since I have never contacted him before. If I have previously had an IM >session with him, I assume "offline" means "offline". > >The response to the subscription with either a notify (or lack thereof) >divulges some information. I think the least sensitive piece of information >is saying the target user is "offline". If that state has a greater than 50% >probability of being correct, so what? Until I accept your subscription to >my presence, I am "offline" to you. > >(-:bob > >Robert F. Penfield >Chief Software Architect >Acme Packet, Inc. >130 New Boston Street >Woburn, MA 01801 >bpenfield@acmepacket.com > >----- Original Message ----- >From: "James Undery" >To: "Daniel Starin" >Cc: "'Jonathan Rosenberg'" ; "'Michael Hammer'" >; "'Rosen, Brian'" ; > >Sent: Thursday, July 19, 2001 4:15 AM >Subject: Re: [Simple] Another idea for presence authorization > > > > > > > > Daniel Starin wrote: > > > > > -----Original Message----- > > > From: simple-admin@mailman.dynamicsoft.com > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of James Undery > > > Sent: Wednesday, July 18, 2001 4:36 AM > > > To: Daniel Starin > > > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > > > simple@mailman.dynamicsoft.com > > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > Daniel Starin wrote: > > > > > > > PLEASE disregard the other message and read this one... I missed a > > > typo > > > > which could ruin my argument... > > > > > > > > So we are all on the same level... > > > > > > > > As I understand it... there are 6 possible states when user A makes a > > > > subscription request to user B... > > > > > > > > User B is?/The response to the subscription was? > > > > > > > > 1. Present/Accepted > > > > 2. Present/Pending > > > > 3. Present/Rejected > > > > 4. Not Present/Accepted > > > > 5. Not Present/Pending > > > > 6. Not Present/Rejected > > > > > > > > If we send "Offline" notifies every time... > > > > > > > > If User A gets an Offline notifies... > > > > he knows the state is one of the following > > > > > > > > 2. Present/Pending > > > > 3. Present/Rejected > > > > 4. Not Present/Accepted > > > > 5. Not Present/Pending > > > > 6. Not Present/Rejected > > > > > > > > > > >6 is not an option a rejected subscription will not generate a NOTIFY > > > I > > > > > > Wasn't the whole idea of sending a random notify every time to make it > > > so User A does not know whether or not his subscription has been > > > accepted or not? According to Jonathans diagram previously posted in > > > the thread a Notify is sent every time... That would include the times > > > when User B is not present and has set a policy on his PS to reject the > > > subscription... Wouldn't a notify still be sent?.... If a notify is not > > > sent doesn't User A know that his subscription is rejected and then we > > > are back to the telemarketer problem Jonathan described?.... I hold that > > > 6 is an option.... > > > > well I contend there is option 7 present / appearing offline, back to >50/50 > > > > > > > > > > > > > > > > If User A gets an Online notify.. > > > > He knows the state is... > > > > > > > > 1. Present/Accepted > > > > > > > > The "Offline" notify method does indeed hide whether User A knows > > > > whether or not his subscription was Accepted or not. BUT... > > > > mathematically, it gives User A something else to play with.... If the > > > > probability of all six options are equal... User A knows that when he > > > > gets an "Offline" notify that the percent chance that User B is really > > > > Offline is 60% (3/5). > > > > > > > But the probabilities are nowhere near equal (and you are still wrong > > > about > > > > 6), assuming there are 1 million people in the world, the fraction of > > > them > > > > I'd authorise is minimal, meaning only 2 and 5 are likely if I pick a > > > > presentity at random to subscribe to, giving a 50/50 chance. > > > > > > Yes, out of the 1 million people, the ones you would authorize is > > > minimal... the people who would request to subscribe to you is minimal > > > as well... User A knows nothing about User B until a subscription is > > > made... thus he has no way of knowing anything about User B's policies > > > with respect to subscription authorization... the only thing he does > > > know is that if he gets an offline notify that there are 5 possible > > > status' and 3 of them specify that User A is offline... > > > > My main point is the very little I remember about Probability is for >complex > > situations it is easy to make assumptions to get the answer you want, I > > content the argument is flawed as I could say based on the time of day I >can > > make a better than 50/50 guess, for instance as I write this email, I'd >bet > > you're at home probably asleep as it is 5am in New York. > > > > > > > > > > > > Mathematically, that is better than the 50/50 > > > > probability User A has of knowing if User B is present or not that I > > > > will prove that you get without sending any notifies at all... > > > > > > > > Without sending notifies before authorization... > > > > > > > > If User A gets No notify... > > > > he knows the state is one of the following > > > > > > > > 2. Present/Pending > > > > 3. Present/Rejected > > > > 5. Not Present/Pending > > > > 6. Not Present/Rejected > > > > > > > > if he gets an Offline notify... > > > > > > > > he knows the state is.. > > > > 4. Not Present/Accepted > > > > > > > > if he gets an Online notify... > > > > > > > > he knows the state is > > > > 1. Present/Accepted > > > > > > > > When user A receives No notifies, there is a 50% chance that User B is > > > > Present and a 50% chance that User B is not present... this truly > > > > divulges no information about User B's presence to User A.... > > > > > > > > In this scenario... Jonathans statement is valid... > > > > > > > > In non-mathematical terms, if I always tell you its sunny outside, > > > > irregardless of whether it is or isn't, can you ever know whether it > > > > really is or isn't? Have I told you anything useful? No! > > > > > > > > In the notify every time scenario... this statement does not > > > > apply...User A has a 60% chance of knowing User B's true presence > > > > REGARDLESS of whether he is authorized or not... > > > > > > > > In my mind... that makes notifying every time a bad idea... both > > > > information wise and bandwidth wise... > > > > > > > A CPIM decision not a SIMPLE one. > > > > > > Fine, but I think we have to come to some consensus on the matter... and > > > Jonathan just brought up another idea... sending random online/offline > > > status'..... I am willing to back off if everyone disagrees with me but > > > I think that the "information leak" others have mentioned is because of > > > the reason described above.... > > > > Well on the information leak I'd disagree, some times the lack of > > information is information i.e. the other person doesn't want to or can't > > due to lack of presence respond. The idea of using subscribes from >multiple > > locations breaks the random answer idea. A lie is no good unless it is a > > consistent lie and I generally prefer just saying offline. > > > > James Undery > > > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > From dgboyer@avaya.com Thu Jul 19 11:51:39 2001 Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14213 for ; Thu, 19 Jul 2001 11:51:39 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05295 for ; Thu, 19 Jul 2001 11:50:41 -0400 (EDT) Received: from NJ7460CLUSTER.usae.avaya.com (h135-8-7-232.avaya.com [135.8.7.232]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05259 for ; Thu, 19 Jul 2001 11:50:40 -0400 (EDT) Received: by nj7460cluster.usae.avaya.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 11:50:00 -0400 Message-ID: <1EB06B0C0D7B484BAECBFACCE290B39F892140@nj7460cluster.usae.avaya.com> From: "Boyer, D G (Dave)" To: "'Bob Penfield'" , James Undery , Daniel Starin Cc: "'Jonathan Rosenberg'" , "'Michael Hammer'" , "'Rosen, Brian'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Thu, 19 Jul 2001 11:49:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1106A.7501BAF0" Content-Length: 29404 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: 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_01C1106A.7501BAF0 Content-Type: text/plain; charset="iso-8859-1" James, I agree, doesn't make sense to me to send a random message when a user is not authorized. Why not just return a message - presence information "Unavailable". The presence information may be unavailable for a number of reasons - not authorized, network problem, etc. Dave Boyer Avaya Labs Collaborative Applications Research > -----Original Message----- > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > Sent: Thursday, July 19, 2001 10:32 AM > To: James Undery; Daniel Starin > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Another idea for presence authorization > > > The idea of sending a random online/offline NOTIFY when > authorization is > pending or rejected seems rather strange to me. What happens > if they receive > an "online" and then attempt to contact that user? Wouldn't > the subsequent > failure tell the requestor they were not authorized (or at > least give them a > clue)? Why should we encourage more message traffic half the time? > > In my mind, personal privacy is paramount and the most > sensitive piece of > information that should not be divulged is whether or not the > authorization > is pending or rejected. I think that sending "offline", > unless the requestor > is authorized and the target user is online is, the right > thing to do. The > only thing that the requestor has been told is that they > cannot reach the > target user, they have not been told exactly why. > > All these probability number being thrown around don't really > make sense to > me. If I subscribe to Jonathan's presence for the first time, > and I get back > "offline", I would assume that the authorization is pending > or rejected > since I have never contacted him before. If I have previously > had an IM > session with him, I assume "offline" means "offline". > > The response to the subscription with either a notify (or > lack thereof) > divulges some information. I think the least sensitive piece > of information > is saying the target user is "offline". If that state has a > greater than 50% > probability of being correct, so what? Until I accept your > subscription to > my presence, I am "offline" to you. > > (-:bob > > Robert F. Penfield > Chief Software Architect > Acme Packet, Inc. > 130 New Boston Street > Woburn, MA 01801 > bpenfield@acmepacket.com > > ----- Original Message ----- > From: "James Undery" > To: "Daniel Starin" > Cc: "'Jonathan Rosenberg'" ; > "'Michael Hammer'" > ; "'Rosen, Brian'" ; > > Sent: Thursday, July 19, 2001 4:15 AM > Subject: Re: [Simple] Another idea for presence authorization > > > > > > > > Daniel Starin wrote: > > > > > -----Original Message----- > > > From: simple-admin@mailman.dynamicsoft.com > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf > Of James Undery > > > Sent: Wednesday, July 18, 2001 4:36 AM > > > To: Daniel Starin > > > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian'; > > > simple@mailman.dynamicsoft.com > > > Subject: Re: [Simple] Another idea for presence authorization > > > > > > Daniel Starin wrote: > > > > > > > PLEASE disregard the other message and read this one... > I missed a > > > typo > > > > which could ruin my argument... > > > > > > > > So we are all on the same level... > > > > > > > > As I understand it... there are 6 possible states when > user A makes a > > > > subscription request to user B... > > > > > > > > User B is?/The response to the subscription was? > > > > > > > > 1. Present/Accepted > > > > 2. Present/Pending > > > > 3. Present/Rejected > > > > 4. Not Present/Accepted > > > > 5. Not Present/Pending > > > > 6. Not Present/Rejected > > > > > > > > If we send "Offline" notifies every time... > > > > > > > > If User A gets an Offline notifies... > > > > he knows the state is one of the following > > > > > > > > 2. Present/Pending > > > > 3. Present/Rejected > > > > 4. Not Present/Accepted > > > > 5. Not Present/Pending > > > > 6. Not Present/Rejected > > > > > > > > > > >6 is not an option a rejected subscription will not > generate a NOTIFY > > > I > > > > > > Wasn't the whole idea of sending a random notify every > time to make it > > > so User A does not know whether or not his subscription has been > > > accepted or not? According to Jonathans diagram > previously posted in > > > the thread a Notify is sent every time... That would > include the times > > > when User B is not present and has set a policy on his PS > to reject the > > > subscription... Wouldn't a notify still be sent?.... If a > notify is not > > > sent doesn't User A know that his subscription is > rejected and then we > > > are back to the telemarketer problem Jonathan > described?.... I hold that > > > 6 is an option.... > > > > well I contend there is option 7 present / appearing > offline, back to > 50/50 > > > > > > > > > > > > > > > > If User A gets an Online notify.. > > > > He knows the state is... > > > > > > > > 1. Present/Accepted > > > > > > > > The "Offline" notify method does indeed hide whether > User A knows > > > > whether or not his subscription was Accepted or not. BUT... > > > > mathematically, it gives User A something else to play > with.... If the > > > > probability of all six options are equal... User A > knows that when he > > > > gets an "Offline" notify that the percent chance that > User B is really > > > > Offline is 60% (3/5). > > > > > > > But the probabilities are nowhere near equal (and you > are still wrong > > > about > > > > 6), assuming there are 1 million people in the world, > the fraction of > > > them > > > > I'd authorise is minimal, meaning only 2 and 5 are > likely if I pick a > > > > presentity at random to subscribe to, giving a 50/50 chance. > > > > > > Yes, out of the 1 million people, the ones you would authorize is > > > minimal... the people who would request to subscribe to > you is minimal > > > as well... User A knows nothing about User B until a > subscription is > > > made... thus he has no way of knowing anything about User > B's policies > > > with respect to subscription authorization... the only > thing he does > > > know is that if he gets an offline notify that there are > 5 possible > > > status' and 3 of them specify that User A is offline... > > > > My main point is the very little I remember about Probability is for > complex > > situations it is easy to make assumptions to get the answer > you want, I > > content the argument is flawed as I could say based on the > time of day I > can > > make a better than 50/50 guess, for instance as I write > this email, I'd > bet > > you're at home probably asleep as it is 5am in New York. > > > > > > > > > > > > Mathematically, that is better than the 50/50 > > > > probability User A has of knowing if User B is present > or not that I > > > > will prove that you get without sending any notifies at all... > > > > > > > > Without sending notifies before authorization... > > > > > > > > If User A gets No notify... > > > > he knows the state is one of the following > > > > > > > > 2. Present/Pending > > > > 3. Present/Rejected > > > > 5. Not Present/Pending > > > > 6. Not Present/Rejected > > > > > > > > if he gets an Offline notify... > > > > > > > > he knows the state is.. > > > > 4. Not Present/Accepted > > > > > > > > if he gets an Online notify... > > > > > > > > he knows the state is > > > > 1. Present/Accepted > > > > > > > > When user A receives No notifies, there is a 50% chance > that User B is > > > > Present and a 50% chance that User B is not present... > this truly > > > > divulges no information about User B's presence to User A.... > > > > > > > > In this scenario... Jonathans statement is valid... > > > > > > > > In non-mathematical terms, if I always tell you its > sunny outside, > > > > irregardless of whether it is or isn't, can you ever > know whether it > > > > really is or isn't? Have I told you anything useful? No! > > > > > > > > In the notify every time scenario... this statement does not > > > > apply...User A has a 60% chance of knowing User B's > true presence > > > > REGARDLESS of whether he is authorized or not... > > > > > > > > In my mind... that makes notifying every time a bad idea... both > > > > information wise and bandwidth wise... > > > > > > > A CPIM decision not a SIMPLE one. > > > > > > Fine, but I think we have to come to some consensus on > the matter... and > > > Jonathan just brought up another idea... sending random > online/offline > > > status'..... I am willing to back off if everyone > disagrees with me but > > > I think that the "information leak" others have mentioned > is because of > > > the reason described above.... > > > > Well on the information leak I'd disagree, some times the lack of > > information is information i.e. the other person doesn't > want to or can't > > due to lack of presence respond. The idea of using subscribes from > multiple > > locations breaks the random answer idea. A lie is no good > unless it is a > > consistent lie and I generally prefer just saying offline. > > > > James Undery > > > > _______________________________________________ > > 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_01C1106A.7501BAF0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Another idea for presence authorization

James,

I agree, doesn't make sense to me to send a random message
when a user is not authorized.
Why not just return a message - presence information "Unavailable". 
The presence information may be unavailable for a number of reasons -
not authorized, network problem, etc.

Dave Boyer
Avaya Labs
Collaborative Applications Research

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: Thursday, July 19, 2001 10:32 AM
> To: James Undery; Daniel Starin
> Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian';
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Another idea for presence authorization
>
>
> The idea of sending a random online/offline NOTIFY when
> authorization is
> pending or rejected seems rather strange to me. What happens
> if they receive
> an "online" and then attempt to contact that user? Wouldn't
> the subsequent
> failure tell the requestor they were not authorized (or at
> least give them a
> clue)? Why should we encourage more message traffic half the time?
>
> In my mind, personal privacy is paramount and the most
> sensitive piece of
> information that should not be divulged is whether or not the
> authorization
> is pending or rejected. I think that sending "offline",
> unless the requestor
> is authorized and the target user is online is, the right
> thing to do. The
> only thing that the requestor has been told is that they
> cannot reach the
> target user, they have not been told exactly why.
>
> All these probability number being thrown around don't really
> make sense to
> me. If I subscribe to Jonathan's presence for the first time,
> and I get back
> "offline", I would assume that the authorization is pending
> or rejected
> since I have never contacted him before. If I have previously
> had an IM
> session with him, I assume "offline" means "offline".
>
> The response to the subscription with either a notify (or
> lack thereof)
> divulges some information. I think the least sensitive piece
> of information
> is saying the target user is "offline". If that state has a
> greater than 50%
> probability of being correct, so what? Until I accept your
> subscription to
> my presence, I am "offline" to you.
>
> (-:bob
>
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
>
> ----- Original Message -----
> From: "James Undery" <jundery@ubiquity.net>
> To: "Daniel Starin" <ds708@columbia.edu>
> Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>;
> "'Michael Hammer'"
> <mhammer@cisco.com>; "'Rosen, Brian'" <Brian.Rosen@marconi.com>;
> <simple@mailman.dynamicsoft.com>
> Sent: Thursday, July 19, 2001 4:15 AM
> Subject: Re: [Simple] Another idea for presence authorization
>
>
> >
> >
> > Daniel Starin wrote:
> >
> > > -----Original Message-----
> > > From: simple-admin@mailman.dynamicsoft.com
> > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf
> Of James Undery
> > > Sent: Wednesday, July 18, 2001 4:36 AM
> > > To: Daniel Starin
> > > Cc: 'Jonathan Rosenberg'; 'Michael Hammer'; 'Rosen, Brian';
> > > simple@mailman.dynamicsoft.com
> > > Subject: Re: [Simple] Another idea for presence authorization
> > >
> > > Daniel Starin wrote:
> > >
> > > > PLEASE disregard the other message and read this one...
> I missed a
> > > typo
> > > > which could ruin my argument...
> > > >
> > > > So we are all on the same level...
> > > >
> > > > As I understand it... there are 6 possible states when
> user A makes a
> > > > subscription request to user B...
> > > >
> > > > User B is?/The response to the subscription was?
> > > >
> > > > 1. Present/Accepted
> > > > 2. Present/Pending
> > > > 3. Present/Rejected
> > > > 4. Not Present/Accepted
> > > > 5. Not Present/Pending
> > > > 6. Not Present/Rejected
> > > >
> > > > If we send "Offline" notifies every time...
> > > >
> > > > If User A gets an Offline notifies...
> > > > he knows the state is one of the following
> > > >
> > > > 2. Present/Pending
> > > > 3. Present/Rejected
> > > > 4. Not Present/Accepted
> > > > 5. Not Present/Pending
> > > > 6. Not Present/Rejected
> > > >
> > >
> > > >6 is not an option a rejected subscription will not
> generate a NOTIFY
> > > I
> > >
> > > Wasn't the whole idea of sending a random notify every
> time to make it
> > > so User A does not know whether or not his subscription has been
> > > accepted or not?  According to Jonathans diagram
> previously posted in
> > > the thread a Notify is sent every time... That would
> include the times
> > > when User B is not present and has set a policy on his PS
> to reject the
> > > subscription... Wouldn't a notify still be sent?.... If a
> notify is not
> > > sent doesn't User A know that his subscription is
> rejected and then we
> > > are back to the telemarketer problem Jonathan
> described?.... I hold that
> > > 6 is an option....
> >
> > well I contend there is option 7 present / appearing
> offline, back to
> 50/50
> >
> > >
> > >
> > > >
> > > > If User A gets an Online notify..
> > > > He knows the state is...
> > > >
> > > > 1. Present/Accepted
> > > >
> > > > The "Offline" notify method does indeed hide whether
> User A knows
> > > > whether or not his subscription was Accepted or not.  BUT...
> > > > mathematically, it gives User A something else to play
> with.... If the
> > > > probability of all six options are equal... User A
> knows that when he
> > > > gets an "Offline" notify that the percent chance that
> User B is really
> > > > Offline is 60% (3/5).
> > >
> > > > But the probabilities are nowhere near equal (and you
> are still wrong
> > > about
> > > > 6), assuming there are 1 million people in the world,
> the fraction of
> > > them
> > > > I'd authorise is minimal, meaning only 2 and 5 are
> likely if I pick a
> > > > presentity at random to subscribe to, giving a 50/50 chance.
> > >
> > > Yes, out of the 1 million people, the ones you would authorize is
> > > minimal... the people who would request to subscribe to
> you is minimal
> > > as well... User A knows nothing about User B until a
> subscription is
> > > made... thus he has no way of knowing anything about User
> B's policies
> > > with respect to subscription authorization... the only
> thing he does
> > > know is that if he gets an offline notify that there are
> 5 possible
> > > status' and 3 of them specify that User A is offline...
> >
> > My main point is the very little I remember about Probability is for
> complex
> > situations it is easy to make assumptions to get the answer
> you want, I
> > content the argument is flawed as I could say based on the
> time of day I
> can
> > make a better than 50/50 guess, for instance as I write
> this email, I'd
> bet
> > you're at home probably asleep as it is 5am in New York.
> >
> > >
> > >
> > > > Mathematically, that is better than the 50/50
> > > > probability User A has of knowing if User B is present
> or not that I
> > > > will prove that you get without sending any notifies at all...
> > > >
> > > > Without sending notifies before authorization...
> > > >
> > > > If User A gets No notify...
> > > > he knows the state is one of the following
> > > >
> > > > 2. Present/Pending
> > > > 3. Present/Rejected
> > > > 5. Not Present/Pending
> > > > 6. Not Present/Rejected
> > > >
> > > > if he gets an Offline notify...
> > > >
> > > > he knows the state is..
> > > > 4. Not Present/Accepted
> > > >
> > > > if he gets an Online notify...
> > > >
> > > > he knows the state is
> > > > 1. Present/Accepted
> > > >
> > > > When user A receives No notifies, there is a 50% chance
> that User B is
> > > > Present and a 50% chance that User B is not present...
> this truly
> > > > divulges no information about User B's presence to User A....
> > > >
> > > > In this scenario... Jonathans statement is valid...
> > > >
> > > > In non-mathematical terms, if I always tell you its
> sunny outside,
> > > > irregardless of whether it is or isn't, can you ever
> know whether it
> > > > really is or isn't? Have I told you anything useful? No!
> > > >
> > > > In the notify every time scenario... this statement does not
> > > > apply...User A has a 60% chance of knowing User B's
> true presence
> > > > REGARDLESS of whether he is authorized or not...
> > > >
> > > > In my mind... that makes notifying every time a bad idea... both
> > > > information wise and bandwidth wise...
> > >
> > > > A CPIM decision not a SIMPLE one.
> > >
> > > Fine, but I think we have to come to some consensus on
> the matter... and
> > > Jonathan just brought up another idea... sending random
> online/offline
> > > status'..... I am willing to back off if everyone
> disagrees with me but
> > > I think that the "information leak" others have mentioned
> is because of
> > > the reason described above....
> >
> > Well on the information leak I'd disagree, some times the lack of
> > information is information i.e. the other person doesn't
> want to or can't
> > due to lack of presence respond. The idea of using subscribes from
> multiple
> > locations breaks the random answer idea. A lie is no good
> unless it is a
> > consistent lie and I generally prefer just saying offline.
> >
> > James Undery
> >
> > _______________________________________________
> > 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_01C1106A.7501BAF0-- From nsyracus@cnri.reston.va.us Fri Jul 20 05:39:12 2001 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 FAA17033 for ; Fri, 20 Jul 2001 05:39:06 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06915; Fri, 20 Jul 2001 05:38:05 -0400 (EDT) Message-Id: <200107200938.FAA06915@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 Date: Fri, 20 Jul 2001 05:38:05 -0400 Content-Length: 2822 Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-package-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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : A SIP Event Sub-Package for Watcher Information Author(s) : J. Rosenberg Filename : draft-ietf-simple-winfo-package-00.txt Pages : 12 Date : 19-Jul-01 This document defines the watcher information sub-package for the SIP event infrastructure. Watcher information refers to the set of users subcribed to a particular resource within a particular event package. This set changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A subscriber can subscribe to this information, and therefore learn about changes to it. This event package is a sub-package because it can be applied to any event package, including itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-winfo-package-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-winfo-package-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: <20010719150219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-package-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-package-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719150219.I-D@ietf.org> --OtherAccess-- --NextPart-- From saosax@yahoo.it Fri Jul 20 07:59:49 2001 Received: from web14602.mail.yahoo.com (web14602.mail.yahoo.com [216.136.224.82]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id HAA17463 for ; Fri, 20 Jul 2001 07:59:48 -0400 (EDT) Message-ID: <20010720115945.62173.qmail@web14602.mail.yahoo.com> Received: from [212.177.57.193] by web14602.mail.yahoo.com via HTTP; Fri, 20 Jul 2001 13:59:45 CEST Date: Fri, 20 Jul 2001 13:59:45 +0200 (CEST) From: =?iso-8859-1?q?saosax?= To: geopriv@mail.apps.ietf.org, simple@mailman.dynamicsoft.com, sip-implementors@cs.columbia.edu MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 719 Subject: [Simple] positioning; 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: Hi, i'm new in the mailing list, but i'm very interested to the positioning on IP. I have a first question, of base. As it is possible to carry out positioning on a network full IP. Which is the architettuara that it allows me to make positioning. In UMTS already outline of architecture for the positizioning exists one on IP: it is the same one of the positioning in gsm, gprs? can someone send me some document and/or link where to be able to find information on this? it is possible to make positioning on IP with sip? if yes, like is it possible... ______________________________________________________________________ Do You Yahoo!? Il tuo indirizzo gratis e per sempre @yahoo.it su http://mail.yahoo.it From pkyzivat@cisco.com Fri Jul 20 16:49:20 2001 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 QAA18861 for ; Fri, 20 Jul 2001 16:49:20 -0400 (EDT) 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 f6KKn4507864; Fri, 20 Jul 2001 16:49:04 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-146.cisco.com [161.44.241.146]) by cannon.cisco.com (Mirapoint) with ESMTP id AEY01770 (AUTH pkyzivat); Fri, 20 Jul 2001 16:49:04 -0400 (EDT) Message-ID: <3B58980A.DE01ED13@cisco.com> Date: Fri, 20 Jul 2001 16:43:54 -0400 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: Internet-Drafts@ietf.org CC: IETF-Announce:@cisco.com, ";"@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt References: <200107191106.HAA28698@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2508 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: This is a great improvement to the SIMPLE stuff, because it begins redraw the line between session initiation and media that was muddled with the addition of MESSAGE to SIP. There clearly needs to be a way to negotiate text messaging as one medium of a SIP call, and this provides that. I have a few questions/comments: - how does one negotiate a oneway session? Presumably if alice wants to receive but not sent, she can send the following in an invite: m=message 5060 sip sip:alice@alicepc a=recvonly but what does bob send in return? perhaps something like: m=message ??? sip ??? a=sendonly And whatever this is, does it also work in an invite if the person inviting wants to be sendonly? (I believe comedia used port 9 to indicate a sink. I suppose that could be adopted here - perhaps: m=message 9 sip a=sendonly but I don't find the use of the magic number 9 very appealing.) Similarly, what do I do to refuse the media stream? Do I still use port zero for this purpose, even though the port in this m= line is gratuitous? - does there need to be any notion of HOLD in the sense that is used for voice? To go on hold, should I send a reinvite with c=0.0.0.0 even though the c= line is irrelevant here? Or should I reinvite as sendonly? (The general case of this has been discussed elsewhere. I favor a=sendonly as the media independent way to go on hold, with the c=0 being an optional step for media where it makes sense.) - section 4 forbids no-SDP invites, using the excuse that the UAS will not know to offer the message medium. This shows a strong voice bias. If you don't offer media in an invite, you ought to expect the UAS to offer whatever it thinks appropriate, which could be any medium if you haven't expressed any preference. If I don't want to specify any specific media values, but I do want to indicate what I might be interested in using, then callerprefs provides a way to do that: I can include a media= parameter to the Contact header in my INVITE. - in draft-ietf-simple-im-sdp-00 there is mention of the possibility of other transports than sip. That is fine as far as the SDP syntax goes. But how would that work in practice with SIP? Unlike codecs, I can't offer multiple transports with the same m= line. So it is difficult to see how I might negotiate which transport a pair of UAs might wish to use to exchange messages. Thanks, Paul Kyzivat Cisco Systems From petkos@cs.columbia.edu Sun Jul 22 19:49:43 2001 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 TAA26716 for ; Sun, 22 Jul 2001 19:49:43 -0400 (EDT) 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 TAA13976 for ; Sun, 22 Jul 2001 19:49:28 -0400 (EDT) Received: (from petkos@localhost) by diamond.cs.columbia.edu (8.9.3+Sun/8.9.3) id TAA11256 for simple@mailman.dynamicsoft.com; Sun, 22 Jul 2001 19:49:28 -0400 (EDT) From: "Petri K. Koskelainen" Message-Id: <200107222349.TAA11256@diamond.cs.columbia.edu> To: simple@mailman.dynamicsoft.com Date: Sun, 22 Jul 2001 19:49:28 -0400 (EDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 780 Subject: [Simple] Re: I-D ACTION:draft-ietf-simple-im-session-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: Hi, This draft defines how a SIP session exchanging MESSAGE requests is signaled but what about non-MESSAGE sessions.. Would it be possible to add a short statement to the draft defining how non-MESSAGE sessions are established? For example, I may setup a SIP session and use DO or MYOWNREQUEST methods inside the session (for whatever reason). Currently SDP m line looks something like this for MESSAGE: m=message 5061 sip sip:user@mypc Best way to establish a non-MESSAGE session seems to be like this: m=message 5062 sip sip:user@mypc;method=DO It would be nice to generalize this draft further and add something like this to the draft: "The default method, if not otherwise specified, is the MESSAGE but other requests may be specified in the SIP URL." BR, Petri From nsyracus@cnri.reston.va.us Mon Jul 23 06:41:14 2001 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 GAA00660 for ; Mon, 23 Jul 2001 06:41:08 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09293; Mon, 23 Jul 2001 06:39:59 -0400 (EDT) Message-Id: <200107231039.GAA09293@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 Date: Mon, 23 Jul 2001 06:39:58 -0400 Content-Length: 2791 Subject: [Simple] I-D ACTION:draft-ietf-simple-im-session-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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Instant Message Sessions Author(s) : B. Campbell, J. Rosenberg Filename : draft-ietf-simple-im-session-00.txt Pages : 12 Date : 18-Jul-01 The current specification for the SIP MESSAGE request method indicates that SIP instant messages according to a model similar to that of a text pager, in that each message stands alone. There is no concept of a chat session or a text conference where there is a stream of messages that are grouped into a session. This memo proposes a method of describing MESSAGE sessions by treating the message session just like any other media session described in an SDP body in an INVITE request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-im-session-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-im-session-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-im-session-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: <20010718142412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-im-session-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-im-session-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010718142412.I-D@ietf.org> --OtherAccess-- --NextPart-- From sean.olson@ericsson.com Mon Jul 23 10:29:27 2001 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 KAA01247 for ; Mon, 23 Jul 2001 10:29:24 -0400 (EDT) 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 f6NETE514672 for ; Mon, 23 Jul 2001 09:29:14 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f6NETE716400 for ; Mon, 23 Jul 2001 09:29:14 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jul 23 09:28:44 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPJFA8F>; Mon, 23 Jul 2001 09:28:44 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Paul Kyzivat'" , "'Internet-Drafts@ietf.org'" Cc: "'@cisco.com'" <@cisco.com>, "'\";\"@cisco.com'" <";"@cisco.com>, "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt Date: Mon, 23 Jul 2001 09:28:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11383.C5BA29C0" Content-Length: 2528 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: 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_01C11383.C5BA29C0 Content-Type: text/plain; charset="iso-8859-1" >- how does one negotiate a oneway session? Presumably if alice wants > to receive but not sent, she can send the following in an invite: > > m=message 5060 sip sip:alice@alicepc > a=recvonly > > but what does bob send in return? perhaps something like: > > m=message ??? sip ??? > a=sendonly > > And whatever this is, does it also work in an invite if the person > inviting wants to be sendonly? I'm curious what a one-way SIP signalling session would mean? You can receive an INVITE, but not send the 200 OK? No flame intended, I just don't understand the application you are thinking of. /sean ------_=_NextPart_001_01C11383.C5BA29C0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt

>- how does one negotiate a oneway session? Presumably if alice wants
>  to receive but not sent, she can send the following in an invite:
>
>      m=message 5060 sip sip:alice@alicepc
>      a=recvonly
>
>  but what does bob send in return? perhaps something like:
>
>      m=message ??? sip ???
>      a=sendonly
>
>  And whatever this is, does it also work in an invite if the person
>  inviting wants to be sendonly?

I'm curious what a one-way SIP signalling session would
mean? You can receive an INVITE, but not send the 200 OK?
No flame intended, I just don't understand the application
you are thinking of.

/sean

------_=_NextPart_001_01C11383.C5BA29C0-- From dgboyer@avaya.com Mon Jul 23 10:35:26 2001 Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01285 for ; Mon, 23 Jul 2001 10:35:25 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18495 for ; Mon, 23 Jul 2001 10:34:30 -0400 (EDT) Received: from NJ7460CLUSTER.usae.avaya.com (h135-8-7-232.avaya.com [135.8.7.232]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18470 for ; Mon, 23 Jul 2001 10:34:29 -0400 (EDT) Received: by nj7460cluster.usae.avaya.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Jul 2001 10:33:44 -0400 Message-ID: <1EB06B0C0D7B484BAECBFACCE290B39F89216D@nj7460cluster.usae.avaya.com> From: "Boyer, D G (Dave)" To: "'Sean Olson (EUS)'" , "'Paul Kyzivat'" , "'Internet-Drafts@ietf.org'" Cc: "'@cisco.com'" <@cisco.com@iere.net.avaya.com>, "'\";\"@cisco.com'" <";"@cisco.com>, "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt Date: Mon, 23 Jul 2001 10:33:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11384.7531E6E0" Content-Length: 3933 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: 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_01C11384.7531E6E0 Content-Type: text/plain; charset="iso-8859-1" Isn't this a two way signalling session and one way media session? Dave Boyer -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Monday, July 23, 2001 10:29 AM To: 'Paul Kyzivat'; 'Internet-Drafts@ietf.org' Cc: '@cisco.com'; '";"@cisco.com'; 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt >- how does one negotiate a oneway session? Presumably if alice wants > to receive but not sent, she can send the following in an invite: > > m=message 5060 sip sip:alice@alicepc > a=recvonly > > but what does bob send in return? perhaps something like: > > m=message ??? sip ??? > a=sendonly > > And whatever this is, does it also work in an invite if the person > inviting wants to be sendonly? I'm curious what a one-way SIP signalling session would mean? You can receive an INVITE, but not send the 200 OK? No flame intended, I just don't understand the application you are thinking of. /sean ------_=_NextPart_001_01C11384.7531E6E0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt
Isn't this a two way signalling session and one way media session?
 
Dave Boyer
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Monday, July 23, 2001 10:29 AM
To: 'Paul Kyzivat'; 'Internet-Drafts@ietf.org'
Cc: '@cisco.com'; '";"@cisco.com'; 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt

>- how does one negotiate a oneway session? Presumably if alice wants
>  to receive but not sent, she can send the following in an invite:
>
>      m=message 5060 sip sip:alice@alicepc
>      a=recvonly
>
>  but what does bob send in return? perhaps something like:
>
>      m=message ??? sip ???
>      a=sendonly
>
>  And whatever this is, does it also work in an invite if the person
>  inviting wants to be sendonly?

I'm curious what a one-way SIP signalling session would
mean? You can receive an INVITE, but not send the 200 OK?
No flame intended, I just don't understand the application
you are thinking of.

/sean

------_=_NextPart_001_01C11384.7531E6E0-- From Avshalom@ubique.com Mon Jul 23 13:44:04 2001 Received: from ubqgate02.lotus.com (outbound-pat-address.lotus.co.uk [194.196.39.50]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01818 for ; Mon, 23 Jul 2001 13:44:03 -0400 (EDT) From: Avshalom@ubique.com To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 23 Jul 2001 20:42:43 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 07/23/2001 08:42:49 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 88 Subject: [Simple] Scalability numbers or analysis for SIMPLE 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: Are there any scalability numbers or any scalability analysis for SIMPLE? avshalom From jdrosen@dynamicsoft.com Tue Jul 24 11:04:50 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05173 for ; Tue, 24 Jul 2001 11:04:50 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6OF4Hki029773; Tue, 24 Jul 2001 11:04:18 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 11:04:49 -0400 Message-ID: From: Jonathan Rosenberg To: "'Avshalom@ubique.com'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Scalability numbers or analysis for SIMPLE Date: Tue, 24 Jul 2001 11:04:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 1016 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: > -----Original Message----- > From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] > Sent: Monday, July 23, 2001 1:43 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Scalability numbers or analysis for SIMPLE > > > Are there any scalability numbers or any scalability analysis > for SIMPLE? > > avshalom > I haven't seen any published documents. However, the scalability is potentially huge, because simple can push the PA function for presence back to the clients. Similarly, instant messages can be handled end-to-end when set up as a session (see draft-ietf-simple-im-session) which also results in excellent scalability. -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 From Avshalom@ubique.com Tue Jul 24 13:05:27 2001 Received: from ubqgate02.lotus.com (outbound-pat-address.lotus.co.uk [194.196.39.50]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05547 for ; Tue, 24 Jul 2001 13:05:26 -0400 (EDT) From: Avshalom@ubique.com Subject: RE: [Simple] Scalability numbers or analysis for SIMPLE To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Tue, 24 Jul 2001 20:03:56 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 07/24/2001 08:04:12 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 2750 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: Does it not assume a peer to peer model for scalability? I wonder what the scalability will be when clients are not able to connect peer to peer. avshalom Jonathan Rosenberg To: "'Avshalom@ubique.com'" , Sent by: simple@mailman.dynamicsoft.com simple-admin@mailman.dynam cc: icsoft.com Subject: RE: [Simple] Scalability numbers or analysis for SIMPLE 24/07/2001 18:04 > -----Original Message----- > From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] > Sent: Monday, July 23, 2001 1:43 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Scalability numbers or analysis for SIMPLE > > > Are there any scalability numbers or any scalability analysis > for SIMPLE? > > avshalom > I haven't seen any published documents. However, the scalability is potentially huge, because simple can push the PA function for presence back to the clients. Similarly, instant messages can be handled end-to-end when set up as a session (see draft-ietf-simple-im-session) which also results in excellent scalability. -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 aoki@netscape.com Tue Jul 24 14:32:16 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05802 for ; Tue, 24 Jul 2001 14:32:16 -0400 (EDT) Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id f6OIWDB14879 for ; Tue, 24 Jul 2001 11:32:13 -0700 (PDT) Received: from netscape.com ([208.12.35.68]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GGZQ5P02.9QU; Tue, 24 Jul 2001 11:32:13 -0700 Message-ID: <3B5DBE43.6FFB82E9@netscape.com> Date: Tue, 24 Jul 2001 11:28:19 -0700 From: aoki@netscape.com (Edwin Aoki) Reply-To: aoki@aol.net Organization: Netscape Communications Corporation X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com References: <200107241600.MAA05364@mailman.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1348 Subject: [Simple] Re: Scalability at a macro level 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: Jonathan, I agree that by virtue of SIMPLE's design in allowing UAs to communicate directly with each other that SIMPLE can scale from a processing load standpoint, but I'd also be interested in seeing some analysis of SIMPLE, or, in fact, SIP itself in terms of the bandwidth overhead that the protocol adds on top of the actual message data. Even though an individual's bandwidth requirement may be relatively small, eventually, all of that bandwidth gets aggregated at an ISP. If there are a hundred simultaneous clients receiving bandwidth from a given ISP (or, in AOL, Earthlink, or MS's case, millions) which are routinely sending and receiving presence notifications and messages in a real-time basis to/from each of their presentities/watchers, eventually that adds up to a lot of data which flows out of the ISP - in many cases many times greater than the existing proprietary messaging protocols in use today. Have any of the other SIP-based media WGs looked at this issue? -Edwin > > I haven't seen any published documents. However, the scalability is > potentially huge, because simple can push the PA function for presence back > to the clients. Similarly, instant messages can be handled end-to-end when > set up as a session (see draft-ietf-simple-im-session) which also results in > excellent scalability. > > -Jonathan R. > From Vasilis.Polychronidis@Openwave.com Tue Jul 24 19:13:54 2001 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 TAA06535 for ; Tue, 24 Jul 2001 19:13:53 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010724231215.CVZQ23098.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Tue, 24 Jul 2001 18:12:15 -0500 Received: from Openwave.com ([64.14.128.39]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010724231341.DWAD3658.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Tue, 24 Jul 2001 18:13:41 -0500 Message-ID: <3B5E0121.D7E66A5C@Openwave.com> Date: Tue, 24 Jul 2001 16:13:38 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aoki@aol.net CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: Scalability at a macro level References: <200107241600.MAA05364@mailman.dynamicsoft.com> <3B5DBE43.6FFB82E9@netscape.com> Content-Type: multipart/alternative; boundary="------------A55F65CBC8C5F7F3C8C61507" Content-Length: 15813 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: --------------A55F65CBC8C5F7F3C8C61507 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan and Edwin, Please see my comments below: BR, -Vasilis Edwin Aoki wrote: > Jonathan, > > I agree that by virtue of SIMPLE's design in allowing UAs to communicate > directly with each other Only in the peer to peer mode. Peer to peer is not working very well in the current NAT environment. > that SIMPLE can scale from a processing load > standpoint, > but I'd also be interested in seeing some analysis of SIMPLE, or, in fact, SIP > itself in terms of the bandwidth overhead that the protocol adds on top of the > actual message data. Even though an individual's bandwidth requirement may > be relatively small, eventually, all of that bandwidth gets aggregated at an > ISP. This is a valid concern but I am more concerned when messages transverse SIP proxies (VoIP signaling infrastructure) The aggregate effect of a successful IM service will severely hinder the call control signaling (e.g.. call originations and call terminations). That is the reason I was proposing for separation of IM traffic from IM signaling traffic. Unfortunately the current drafts they barely mention such possibility. > > If there are a hundred simultaneous clients receiving bandwidth from a given ISP > > (or, in AOL, Earthlink, or MS's case, millions) which are routinely sending and > receiving presence notifications and messages in a real-time basis to/from each > of their presentities/watchers, eventually that adds up to a lot of data which > flows > out of the ISP Very true. Separating Presence events from signaling (SIP proxies) is an idea that should be seriously considered in this case (i am not referring to Peer to Peer model). Maybe deploying a separate SIP infrastructure (SIP proxies) just for Presence events decoupling it from call control signaling? > - in many cases many times greater than the existing proprietary > messaging protocols in use today. > > Have any of the other SIP-based media WGs looked at this issue? > > -Edwin > > > > > I haven't seen any published documents. However, the scalability is > > potentially huge, because simple can push the PA function for presence back > > to the clients. Similarly, instant messages can be handled end-to-end when > > set up as a session (see draft-ietf-simple-im-session) which also results in > > excellent scalability. Here is a quote from a previous E-mail that I posted in the list. The draft-ietf-simple-im-session did not address any of the issues raised in this E-mail: I think there was consensus that we would move forward with: JR> 1. defining MESSAGE as a sessionless page mechanism I would prefer if this becomes a separate ID (Notification/paging service based on SIP). Notifications/Pages should be described in a more generic framework. (the same way SIP Events are more general than the presence service). In any rate I do not have any strong feelings about this. On another issue I am always hesitant of using signaling infrastructure (SIP proxies) for transporting user messaging. The signaling infrastructure (SIP proxies) has completely different requirements (QOS, reliability, availability, etc.) than your messaging or your transport (RTP, etc.) infrastructure. IMO mixing signaling data (session initiation) with application data is not a very good idea. You do not want the SIP proxies to start dropping INVITE messages (VoIP call set up) because your signaling infrastructure is congested from user notification/pages. SMS which is a huge commercial success was a technical nightmare for the operators for exactly the above mentioned reason (mixing signaling in this case SS7 with messaging data). I hope we will learn from examples like this and will not repeat similar technical mistakes. JR> 2. allow for INVITE/BYE to establish an IM session This is an excellent idea. I will list some of the most important (IMO) benefits of doing this (Jonathan mentioned many of them in previous e-mails): 1. Unification of Multimedia sessions (VoIP, Video with the Instant Messaging Service). Control all sessions (IM, Voice, Multimedia) in a unified method using the same signaling protocol. 2. forking actually works 3. you can actually clean up state in end systems which are automata (like an IM conference server, which you cannot build without this!) This is a huge benefit. Multiparty chat sessions is very natural (easy) with SIP. 4. you can avoid sending 5meg MP3 "IMs" over proxies This is very important. Separate signaling from transport. Follow similar architecture as VoIP. Actually by introducing the concept of a chat (IM) server you can solve the NAT issues associated with IM 4. you can reuse alot of the sip tools we have constructed for sessions - transfers, multiparty conferencing, etc. Again you unify the user experience. User is presented with the same features/options regardless the session (IM, Voice, etc.) JR> I think we still have a bit more thinking to do on exactly how the JR> IM-as-a-session will work. I had proposed including a SIP URL in the SDP, JR> which will work in many cases, but there are still some record-routing JR> issues, like the one Robert points out. I don't think those details were yet JR> ironed out, though. The session description should be flexible enough to allow different message transport protocols as well as peer to peer and client-server (IM server or chat Server) communication models: c = IN IP4 FQDN or IP Address m = message [ "/" MP integer] where: FQDN or IP Address = the address/identifier of expected data source or data relay or data sink port = port number protocol = udp | tcp | http | rtp | sip/udp | sip/tcp sip/udp and sip/tcp should not be used to transport messages over SIP proxies (signaling) IM-identifier = im:user@domain (CPIM IM identifier) MP stands for message profile for example MP 0 may mean CPIM MP 1 may represent some type of XML type message etc. The beauty of this format is that is extensible. Also this approach allow us to separate the signaling addressing from the transport addressing > > > > > > -Jonathan R. > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple --------------A55F65CBC8C5F7F3C8C61507 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan and Edwin,
Please see my comments below:

BR,

-Vasilis

Edwin Aoki wrote:

Jonathan,

I agree that by virtue of SIMPLE's design in allowing UAs to communicate
directly with each other

Only in the peer to peer mode. Peer to peer is not working very well in the current NAT environment.
that SIMPLE can scale from a processing load
standpoint,
but I'd also be interested in seeing some analysis of SIMPLE, or, in fact, SIP
itself in terms of the bandwidth overhead that the protocol adds on top of the
actual message data.  Even though an individual's bandwidth requirement may
be relatively small, eventually, all of that bandwidth gets aggregated at an
ISP.
This is a valid concern but I am more concerned when messages transverse SIP proxies (VoIP signaling infrastructure)
The aggregate effect of a successful IM service will severely hinder the call control signaling (e.g.. call originations and
call terminations).
That is the reason I was proposing for separation of IM traffic from IM signaling traffic.
Unfortunately the current drafts they barely mention such possibility.
 
If there are a hundred simultaneous clients receiving bandwidth from a given ISP

(or, in AOL, Earthlink, or MS's case, millions) which are routinely sending and
receiving presence notifications and messages in a real-time basis to/from each
of their presentities/watchers, eventually that adds up to a lot of data which
flows
out of the ISP

Very true. Separating Presence events from signaling (SIP proxies) is an idea that should be
seriously considered in this case (i am not referring to Peer to Peer model).
Maybe deploying a separate SIP infrastructure (SIP proxies) just for Presence events decoupling
it from call control signaling?
- in many cases many times greater than the existing proprietary
messaging protocols in use today.

Have any of the other SIP-based media WGs looked at this issue?

-Edwin

>
> I haven't seen any published documents. However, the scalability is
> potentially huge, because simple can push the PA function for presence back
> to the clients. Similarly, instant messages can be handled end-to-end when
> set up as a session (see draft-ietf-simple-im-session) which also results in
> excellent scalability.

Here is a quote from a previous E-mail that I posted in the list. The draft-ietf-simple-im-session
did not address any of the issues raised in this E-mail:
I think there was consensus that we would move forward with:

JR>  1. defining MESSAGE as a sessionless page mechanism

I would prefer if this becomes a separate ID (Notification/paging service based on SIP).
Notifications/Pages should be described in a more generic framework. (the same way SIP
Events
are more general than the presence service).
In any rate I do not have any strong feelings about this.
On another issue I am always hesitant of using signaling infrastructure (SIP proxies) for
transporting user messaging.
The signaling infrastructure (SIP proxies) has completely different requirements (QOS,
reliability, availability, etc.) than
your messaging or your transport (RTP, etc.) infrastructure.
IMO mixing signaling data (session initiation) with application data is not a very good idea.

You do not want the SIP proxies to start dropping INVITE messages (VoIP call set up)
because your signaling infrastructure is congested from user notification/pages.
SMS which is a huge commercial success was a technical nightmare for the operators for
exactly
the above mentioned reason (mixing signaling in this case SS7 with messaging data).
I hope we will learn from examples like this and will not repeat similar technical mistakes.

 
JR>  2. allow for INVITE/BYE to establish an IM session

This is an excellent idea.
I will list some of the most important (IMO) benefits of doing this (Jonathan mentioned
many of them in previous e-mails):
1. Unification of Multimedia sessions (VoIP, Video with the Instant Messaging Service).
Control all sessions (IM, Voice, Multimedia) in a unified method using the same signaling
protocol.
2. forking actually works
3. you can actually clean up state in end systems which are
automata (like an IM conference server, which you cannot build without this!)
This is a huge benefit. Multiparty chat sessions is very natural (easy) with SIP.
4. you can avoid sending 5meg MP3 "IMs" over proxies
This is very important. Separate signaling from transport. Follow similar architecture as
VoIP.
Actually by introducing the concept of a chat (IM) server you can solve the NAT issues
associated with IM
4. you can reuse alot of the sip tools we have constructed for
sessions - transfers, multiparty conferencing, etc.
Again you unify the user experience. User is presented with the same features/options
regardless
the session (IM, Voice, etc.)

 

JR>  I think we still have a bit more thinking to do on exactly how the
JR>  IM-as-a-session will work. I had proposed including a SIP URL in the SDP,
JR>  which will work in many cases, but there are still some record-routing
JR>  issues, like the one Robert points out. I don't think those details were yet
JR>  ironed out, though.

The session description should be flexible enough to allow different message transport
protocols as well as
peer to peer and client-server (IM server or chat Server) communication models:

c = IN IP4 FQDN or IP Address
m = message <port> <protocol> [ "/" MP integer] <IM-identifier>

where:
FQDN or IP Address = the address/identifier of expected data source or data relay or
data sink
port = port number
protocol = udp | tcp | http | rtp | sip/udp | sip/tcp
    sip/udp and sip/tcp should not be used to transport messages over SIP proxies
(signaling)
IM-identifier = im:user@domain (CPIM IM identifier)
MP stands for message profile
for example MP 0 may mean CPIM
MP 1 may represent some type of XML type message
etc.
The beauty of this format is that is extensible.
Also this approach allow us to separate the signaling addressing from the transport
addressing
 

 
 
>
> -Jonathan R.
>

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

--------------A55F65CBC8C5F7F3C8C61507-- From nsyracus@cnri.reston.va.us Wed Jul 25 06:41:40 2001 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 GAA08327 for ; Wed, 25 Jul 2001 06:41:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08339; Wed, 25 Jul 2001 06:40:29 -0400 (EDT) Message-Id: <200107251040.GAA08339@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 Date: Wed, 25 Jul 2001 06:40:28 -0400 Content-Length: 2357 Subject: [Simple] I-D ACTION:draft-ietf-simple-im-01.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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Instant Messaging Author(s) : J. Rosenberg et al. Filename : draft-ietf-simple-im-01.txt Pages : 23 Date : 24-Jul-01 This document defines a SIP extension (a single new method) that supports Instant Messaging (IM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-im-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-im-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-im-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-im-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-im-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132809.I-D@ietf.org> --OtherAccess-- --NextPart-- From nsyracus@cnri.reston.va.us Wed Jul 25 06:41:40 2001 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 GAA08326 for ; Wed, 25 Jul 2001 06:41:38 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08361; Wed, 25 Jul 2001 06:40:36 -0400 (EDT) Message-Id: <200107251040.GAA08361@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 Date: Wed, 25 Jul 2001 06:40:36 -0400 Content-Length: 2852 Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-01.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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-01.txt Pages : 40 Date : 24-Jul-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132819.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132819.I-D@ietf.org> --OtherAccess-- --NextPart-- From c-Dai.Ngo@WCOM.Com Wed Jul 25 11:31:15 2001 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 LAA09141 for ; Wed, 25 Jul 2001 11:31:15 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GH1000JSCEL5W@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Wed, 25 Jul 2001 15:30:21 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GH100K01CEDJM@dgismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 25 Jul 2001 15:30:20 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GH100K0ACDXDE@dgismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 25 Jul 2001 15:29:58 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 15:29:57 +0000 Content-return: allowed Date: Wed, 25 Jul 2001 15:29:54 +0000 From: "Ngo, Dai (c)" Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-presence-01.txt To: simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E11C61B@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_LWkLbTDZ72s0C1F3gIV+xQ)" Content-Length: 9916 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: 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_LWkLbTDZ72s0C1F3gIV+xQ) Content-type: text/plain; charset=iso-8859-1 Hi All, In section 6.3 Uploading Presence Documents of this draft it states, "Subsequent uploads replace the current active presence document". Does this statement mean every time a new REGISTER is received, it completely replaces the current REGISTER info? With a replacement (registration) process it facilitates the migration, meaning making the migration of the PA easier. However it makes the registration of additional devices (PAs) harder (one has to know up front how many PAs to register). Please help clarifying. Thanks. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 25, 2001 5:41 AM Cc: simple@mailman.dynamicsoft.com Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-01.txt Pages : 40 Date : 24-Jul-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_LWkLbTDZ72s0C1F3gIV+xQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: [Simple] I-D = ACTION:draft-ietf-simple-presence-01.txt

Hi All,

In section 6.3 Uploading Presence Documents of this = draft it states, "Subsequent uploads replace the current active = presence document". Does this statement mean every time a  = new REGISTER is received, it completely replaces the current REGISTER = info?

With a replacement (registration) process it = facilitates the migration, meaning making the migration of the PA = easier. However it makes the registration of additional devices (PAs) = harder (one has to know up front how many PAs to register).

Please help clarifying.

Thanks.

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Wednesday, July 25, 2001 5:41 AM
Cc: simple@mailman.dynamicsoft.com
Subject: [Simple] I-D = ACTION:draft-ietf-simple-presence-01.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the SIP for Instant = Messaging and Presence Leveraging Extensions Working Group of the = IETF.

        Title           : = SIP Extensions for Presence
        Author(s)       : J. = Rosenberg
        Filename        : = draft-ietf-simple-presence-01.txt
        Pages           : = 40
        Date    =         : 24-Jul-01
       =20
This document proposes an extension to SIP for = subscriptions and
notifications of user presence. User presence is = defined as the
willingness and ability of a user to communicate = with other users on
the network. Historically, presence has been limited = to 'on-line' and
'off-line' indicators; the notion of presence here = is broader.
Subscriptions and notifications of user presence are = supported by
defining an event package within the general SIP = event notification
framework. This protocol is also compliant with the = Common Presence
and Instant Messaging (CPIM) framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-= presence-01.txt

Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
        "get = draft-ietf-simple-presence-01.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-simple-presence-01.txt".
       =20
NOTE:   The mail server at ietf.org can = return the document in
        MIME-encoded form by using the "mpack" = utility.  To use this
        feature, = insert the command "ENCODING mime" before the = "FILE"
        command.  To decode the response(s), you will need = "munpack" or
        a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
        exhibit = different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have = been split
        up into = multiple messages), so check your local documentation on
        how to = manipulate these messages.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

--Boundary_(ID_LWkLbTDZ72s0C1F3gIV+xQ)-- From c-Dai.Ngo@WCOM.Com Wed Jul 25 11:41:38 2001 Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09212 for ; Wed, 25 Jul 2001 11:41:37 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GH100ABXCX94D@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Wed, 25 Jul 2001 15:41:33 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GH100F01CWTYE@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 25 Jul 2001 15:41:33 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GH100CH6CWRZY@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 25 Jul 2001 15:41:15 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id <31QZ5BZL>; Wed, 25 Jul 2001 15:41:15 +0000 Content-return: allowed Date: Wed, 25 Jul 2001 15:41:13 +0000 From: "Ngo, Dai (c)" Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-presence-01.txt To: "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E11C61C@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_2XpBCA/sp2E0gOXc5v53Bw)" Content-Length: 9886 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: 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_2XpBCA/sp2E0gOXc5v53Bw) Content-type: text/plain; charset=ISO-8859-1 Hi All, In the examples of the draft (draft-ietf-simple-presence-01.txt) the NOTIFY request specifies Content-Type: application/xpidf+xml but the xml body does not follow the draft "A Data Format for Presence Using XML" (draft-rosenberg-impp-pidf-00.txt, expires December, 2000). There are "presence entifyInfo" and "tuple destination" elements which were not defined in the draft-rosenberg-impp-pidf-00.txt. Which xml (DTD) format that the draft-ietf-simple-presence-01.txt follows? Thanks. -- Dai -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 25, 2001 5:41 AM Cc: simple@mailman.dynamicsoft.com Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-01.txt Pages : 40 Date : 24-Jul-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_2XpBCA/sp2E0gOXc5v53Bw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable RE: [Simple] I-D = ACTION:draft-ietf-simple-presence-01.txt

Hi All,

In the examples of the draft = (draft-ietf-simple-presence-01.txt) the NOTIFY request specifies = Content-Type: application/xpidf+xml but the xml body does  not = follow the draft "A Data Format for Presence Using XML" = (draft-rosenberg-impp-pidf-00.txt, expires December, 2000). There are = "presence entifyInfo" and "tuple destination" = elements which were not defined in the = draft-rosenberg-impp-pidf-00.txt.

Which xml (DTD) format that the = draft-ietf-simple-presence-01.txt follows?

Thanks.

-- Dai

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Wednesday, July 25, 2001 5:41 AM
Cc: simple@mailman.dynamicsoft.com
Subject: [Simple] I-D = ACTION:draft-ietf-simple-presence-01.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the SIP for Instant = Messaging and Presence Leveraging Extensions Working Group of the = IETF.

        Title           : = SIP Extensions for Presence
        Author(s)       : J. = Rosenberg
        Filename        : = draft-ietf-simple-presence-01.txt
        Pages           : = 40
        Date    =         : 24-Jul-01
       =20
This document proposes an extension to SIP for = subscriptions and
notifications of user presence. User presence is = defined as the
willingness and ability of a user to communicate = with other users on
the network. Historically, presence has been limited = to 'on-line' and
'off-line' indicators; the notion of presence here = is broader.
Subscriptions and notifications of user presence are = supported by
defining an event package within the general SIP = event notification
framework. This protocol is also compliant with the = Common Presence
and Instant Messaging (CPIM) framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-= presence-01.txt

Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
        "get = draft-ietf-simple-presence-01.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-simple-presence-01.txt".
       =20
NOTE:   The mail server at ietf.org can = return the document in
        MIME-encoded form by using the "mpack" = utility.  To use this
        feature, = insert the command "ENCODING mime" before the = "FILE"
        command.  To decode the response(s), you will need = "munpack" or
        a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
        exhibit = different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have = been split
        up into = multiple messages), so check your local documentation on
        how to = manipulate these messages.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

--Boundary_(ID_2XpBCA/sp2E0gOXc5v53Bw)-- From jdrosen@dynamicsoft.com Wed Jul 25 14:02:57 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09620 for ; Wed, 25 Jul 2001 14:02:57 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6PI2Nki005412; Wed, 25 Jul 2001 14:02:24 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:02:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-presence-01.txt Date: Wed, 25 Jul 2001 14:02:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1512 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: -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Wednesday, July 25, 2001 11:41 AM To: 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-presence-01.txt >Hi All, >In the examples of the draft (draft-ietf-simple-presence-01.txt) the NOTIFY >request specifies Content-Type: application/xpidf+xml but the xml body does >not follow the draft "A Data Format for Presence Using XML" (draft-rosenberg- >impp-pidf-00.txt, expires December, 2000). There are "presence entifyInfo" and >"tuple destination" elements which were not defined in the draft-rosenberg- >impp-pidf-00.txt. > >Which xml (DTD) format that the draft-ietf-simple-presence-01.txt follows? The work on the presence document format is happening in impp. THere is a current proposal for it: http://search.ietf.org/internet-drafts/draft-sugano-cpim-pidf-00.txt this proposal includes both XML presence data, and also rfc822 metadata that would go along with it. I happen to think we only need the presence doc, since the transport (i.e., sip) would provide the rest. But, I seem to be losing that battle in impp. -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 From jdrosen@dynamicsoft.com Wed Jul 25 15:15:14 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09854 for ; Wed, 25 Jul 2001 15:15:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6PJEdki005921; Wed, 25 Jul 2001 15:14:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 15:15:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Cc: "'impp@iastate.edu'" Date: Wed, 25 Jul 2001 15:15:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 650 Subject: [Simple] AOL chooses SIP! 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: Folks, In case you haven't heard, it seems that AOL has chosen to go with SIP for presence (SIMPLE) as part of its FCC mandate towards opening up its network. You can read a press article about this at: http://iwsun4.infoworld.com/articles/hn/xml/01/07/23/010723hnaolmessanger.xm l -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 From jdrosen@dynamicsoft.com Wed Jul 25 17:19:00 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10215 for ; Wed, 25 Jul 2001 17:18:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6PLINki006609; Wed, 25 Jul 2001 17:18:23 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 17:18:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'Michael Hammer'" , Bob Penfield Cc: James Undery , Daniel Starin , "'Rosen, Brian'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Another idea for presence authorization Date: Wed, 25 Jul 2001 17:18:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 1286 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: > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Thursday, July 19, 2001 10:55 AM > To: Bob Penfield > Cc: James Undery; Daniel Starin; 'Jonathan Rosenberg'; 'Rosen, Brian'; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Another idea for presence authorization > > > Bob, > > My only complaint is that this can be assumed and does not > require extra > message traffic to tell you that. This doesn't work. If no NOTIFY is sent if the subscriber isn't authorized, but a NOTIFY (with valid data) is sent if they are authorized, a subscriber can tell immediately whether they are authorized or not. I'll back off from the random selection of the status in the case where the subscriber was rejected or not authorized. However, I still think that a notification has to be sent with a syntactically valid, but useless status that is uncorrelated with actual status. -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 From jdrosen@dynamicsoft.com Thu Jul 26 00:08:07 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11354 for ; Thu, 26 Jul 2001 00:08:07 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6Q47Xki007331; Thu, 26 Jul 2001 00:07:33 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 00:08:06 -0400 Message-ID: From: Jonathan Rosenberg To: "'Vasilis Polychronidis'" , aoki@aol.net Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Re: Scalability at a macro level Date: Thu, 26 Jul 2001 00:08:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 4153 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: -----Original Message----- From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com] Sent: Tuesday, July 24, 2001 7:14 PM To: aoki@aol.net Cc: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: Scalability at a macro level >Hi Jonathan and Edwin, >Please see my comments below: >BR, >-Vasilis >Edwin Aoki wrote: >>Jonathan, >> >>I agree that by virtue of SIMPLE's design in allowing UAs to communicate >>directly with each other > >Only in the peer to peer mode. Peer to peer is not working very well in the >current NAT environment. > >>that SIMPLE can scale from a processing load >>standpoint, >>but I'd also be interested in seeing some analysis of SIMPLE, or, in fact, >>SIP >>itself in terms of the bandwidth overhead that the protocol adds on top of >>the >>actual message data. Even though an individual's bandwidth requirement may >>be relatively small, eventually, all of that bandwidth gets aggregated at an >>ISP. > >This is a valid concern but I am more concerned when messages transverse SIP >proxies (VoIP signaling infrastructure) > >The aggregate effect of a successful IM service will severely hinder the call >control signaling (e.g.. call originations and >call terminations). > >That is the reason I was proposing for separation of IM traffic from IM >signaling traffic. > >Unfortunately the current drafts they barely mention such possibility. Vasilis, one of the important things to understand about the SIP model is that we specify protocols, not architectures. The current mechanism described in the draft-ietf-simple-im-sdp-00.txt allows each side to provide a SIP URL. This SIP URL can be anything, so long as that anything gets routed to me. So, a valid usage case is to make use of a dedicated IM relay service whose proxies are used soley for that purpose. Lets say, for example, I am a customer of foo.com that provides relays for IM (for nat traversal) at imrelay.foo.com. Lets say my client detects its behind a NAT (see draft-rosenberg-sip-entfw-02.txt on how to do that). It would open a TCP connection to imrelay.foo.com and send a REGISTER: REGISTER sip:imrelay.foo.com SIP/2.0 From: sip:jdrosen@foo.com To: sip:jdrosen@imrelay.foo.com Contact: sip:jdrosen@10.0.1.1:9433;transport=tcp Translate: sip:jdrosen@10.0.1.1:9433;transport=tcp (the Translate header is described in draft-rosenberg-sip-entfw-02.txt; its the new version of the Contact cookie I have described previously). Now, this REGISTER creates a binding between an incoming request for sip:jdrosen@imrelay.foo.com and that TCP connection I have just sent the register over. So, when I send an INVITE to someone for an IM session, the SDP in the INVITE looks like: m=message 5060 sip sip:jdrosen@imrelay.foo.com Which will cause the IMs to me to be routed through this TCP connection I have opened to the IM relay, and this relay is a proxy used only for this purpose. >>If there are a hundred simultaneous clients receiving bandwidth from a given >>ISP >>(or, in AOL, Earthlink, or MS's case, millions) which are routinely sending >>and >>receiving presence notifications and messages in a real-time basis to/from >>each >>of their presentities/watchers, eventually that adds up to a lot of data >>which flows out of the ISP > >Very true. Separating Presence events from signaling (SIP proxies) is an idea >that should be >seriously considered in this case (i am not referring to Peer to Peer model). >Maybe deploying a separate SIP infrastructure (SIP proxies) just for Presence >events decoupling it from call control signaling? I don't think this is needed for presence, since presence is really control traffic. IM can contain content, and thats really the source of the problem for using existing proxy networks. -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 From Vasilis.Polychronidis@Openwave.com Thu Jul 26 01:30:16 2001 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 BAA11603 for ; Thu, 26 Jul 2001 01:30:15 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010726052846.IUJK1398.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Thu, 26 Jul 2001 00:28:46 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010726053013.FYZL3658.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Thu, 26 Jul 2001 00:30:13 -0500 Message-ID: <3B5FAAD9.E854AFD5@Openwave.com> Date: Wed, 25 Jul 2001 22:30:02 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: aoki@aol.net, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: Scalability at a macro level References: Content-Type: multipart/alternative; boundary="------------2535EAF8E7C864A64757C6EE" Content-Length: 6791 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: --------------2535EAF8E7C864A64757C6EE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > > >Unfortunately the current drafts they barely mention such possibility. > > Vasilis, one of the important things to understand about the SIP model is > that we specify protocols, not architectures. The current mechanism > described in the draft-ietf-simple-im-sdp-00.txt allows each side to provide > a SIP URL. This SIP URL can be anything, so long as that anything gets > routed to me. So, a valid usage case is to make use of a dedicated IM relay > service whose proxies are used soley for that purpose. Lets say, for > example, I am a customer of foo.com that provides relays for IM (for nat > traversal) at imrelay.foo.com. Lets say my client detects its behind a NAT > (see draft-rosenberg-sip-entfw-02.txt on how to do that). It would open a > TCP connection to imrelay.foo.com and send a REGISTER: > > REGISTER sip:imrelay.foo.com SIP/2.0 > From: sip:jdrosen@foo.com > To: sip:jdrosen@imrelay.foo.com > Contact: sip:jdrosen@10.0.1.1:9433;transport=tcp > Translate: sip:jdrosen@10.0.1.1:9433;transport=tcp > > (the Translate header is described in draft-rosenberg-sip-entfw-02.txt; its > the new version of the Contact cookie I have described previously). Now, > this REGISTER creates a binding between an incoming request for > sip:jdrosen@imrelay.foo.com and that TCP connection I have just sent the > register over. So, when I send an INVITE to someone for an IM session, the > SDP in the INVITE looks like: > > m=message 5060 sip sip:jdrosen@imrelay.foo.com > > Which will cause the IMs to me to be routed through this TCP connection I > have opened to the IM relay, and this relay is a proxy used only for this > purpose. Jonathan thank you for the informative explanation. I wish this case was mentioned in the draft-ietf-simple-im-session as an example My question is with your SDP definition which I believe is very restrictive and does not allow for any other transport than SIP. The session description should be flexible enough to allow different message transport protocols. For example I am proposing something like the following: c = IN IP4 FQDN or IP Address m = message [ "/" MP integer] where: FQDN or IP Address = the address/identifier of expected data source or data relay or data sink port = port number protocol = udp | tcp | http | rtp | sip/udp | sip/tcp sip/udp and sip/tcp should not be used to transport messages over SIP proxies (signaling) IM-identifier = im:user@domain (CPIM IM identifier) MP stands for message profile for example MP 0 may mean CPIM MP 1 may represent some type of XML type message etc. I was wondering if you are planning to extend your ID to include this case? BR, -Vasilis Polychronidis --------------2535EAF8E7C864A64757C6EE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
 
>
>Unfortunately the current drafts they barely mention such possibility.

Vasilis, one of the important things to understand about the SIP model is
that we specify protocols, not architectures. The current mechanism
described in the draft-ietf-simple-im-sdp-00.txt allows each side to provide
a SIP URL. This SIP URL can be anything, so long as that anything gets
routed to me. So, a valid usage case is to make use of a dedicated IM relay
service whose proxies are used soley for that purpose. Lets say, for
example, I am a customer of foo.com that provides relays for IM (for nat
traversal) at imrelay.foo.com. Lets say my client detects its behind a NAT
(see draft-rosenberg-sip-entfw-02.txt on how to do that). It would open a
TCP connection to imrelay.foo.com and send a REGISTER:

REGISTER sip:imrelay.foo.com SIP/2.0
From: sip:jdrosen@foo.com
To: sip:jdrosen@imrelay.foo.com
Contact: sip:jdrosen@10.0.1.1:9433;transport=tcp
Translate: sip:jdrosen@10.0.1.1:9433;transport=tcp

(the Translate header is described in draft-rosenberg-sip-entfw-02.txt; its
the new version of the Contact cookie I have described previously). Now,
this REGISTER creates a binding between an incoming request for
sip:jdrosen@imrelay.foo.com and that TCP connection I have just sent the
register over. So, when I send an INVITE to someone for an IM session, the
SDP in the INVITE looks like:

m=message 5060 sip sip:jdrosen@imrelay.foo.com

Which will cause the IMs to me to be routed through this TCP connection I
have opened to the IM relay, and this relay is a proxy used only for this
purpose.

Jonathan thank you for the informative explanation. I wish this case was mentioned
in the draft-ietf-simple-im-session as an example
My question is with your SDP definition which I believe is very restrictive and
does not allow for any other transport than SIP.
The session description should be flexible enough to allow different message
transport protocols.
For example I am proposing something like the following:

c = IN IP4 FQDN or IP Address
m = message <port> <protocol> [ "/" MP integer] <IM-identifier>

where:
FQDN or IP Address = the address/identifier of expected data source or data
relay or
data sink
port = port number
protocol = udp | tcp | http | rtp | sip/udp | sip/tcp
    sip/udp and sip/tcp should not be used to transport messages over SIP proxies
(signaling)
IM-identifier = im:user@domain (CPIM IM identifier)
MP stands for message profile
for example MP 0 may mean CPIM
MP 1 may represent some type of XML type message
etc.
I was wondering if you are planning to extend your ID to include this case?

BR,

-Vasilis Polychronidis
  --------------2535EAF8E7C864A64757C6EE-- From zane@mabry.com Thu Jul 26 01:31:17 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11621 for ; Thu, 26 Jul 2001 01:31:16 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6Q5VFK00543 for ; Wed, 25 Jul 2001 22:31:15 -0700 (PDT) Message-ID: <034b01c11594$778088e0$1d00a8c0@toophat> From: "Zane Thomas" To: References: Subject: Re: [Simple] Another idea for presence authorization Date: Wed, 25 Jul 2001 22:33:14 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 377 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: Jonathan, > Remember, the > NOTIFY is only sent if the subscriber is AUTHENTICATED, so you get > traceability. That helps a lot to discourage attacks. It seems to me to be susceptible to the sorts of distributed DoS attacks we've seen recently. In those sorts of attacks the attacker doesn't really care if the attack is traced, it won't find him directly that way. Zane From zane@mabry.com Thu Jul 26 01:31:18 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11625 for ; Thu, 26 Jul 2001 01:31:18 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6Q5V6K00459 for ; Wed, 25 Jul 2001 22:31:06 -0700 (PDT) Message-ID: <034a01c11594$724e1ef0$1d00a8c0@toophat> From: "Zane Thomas" To: References: Subject: Re: [Simple] Another idea for presence authorization Date: Wed, 25 Jul 2001 22:33:05 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 1293 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: Jonathan et al, I spent a number of hours today reading through the messages posted since the end of April. Thanks to all for the effort you put into discussing the issues, hopefully I understand them at least well enough now to participate in some way. After reading all the discussion I'm inclined towards the view that a SUBSCRIBE by A when A is not authorized should not cause B to have to do anything. Mixing the authorization and subscription requirements into a single multistep process seems to be an unnecessary coupling of what should be loosely related functionality. The result would be, it seems to me, difficulties in implementation and lack of flexibility - as has been well pointed out by Brian. It also seems to me that embedding urls for accept/reject into the protocol might unnecessarily cause implementation headaches for some. Related to the url concern I also have some concerns about the idea of using HTTP as *the* way of 'uploading' information. I think that's fine if that's what some implementations find convenient. But I also see the need for a SIP alternative. For instance, I might like to run a PS on a small mobile device or on a server which doesn't allow me access to port 80. Zane --- Zane Thomas President - Mabry Software Inc. www.mabry.com From zane@mabry.com Thu Jul 26 01:31:22 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11630 for ; Thu, 26 Jul 2001 01:31:22 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6Q5VLK00591 for ; Wed, 25 Jul 2001 22:31:21 -0700 (PDT) Message-ID: <034c01c11594$7b3a3580$1d00a8c0@toophat> From: "Zane Thomas" To: References: Subject: Re: [Simple] Another idea for presence authorization Date: Wed, 25 Jul 2001 22:33:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 898 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: Jonathan, > ... telemarketer ... > they send a SUBSCRIBE. THey get a 200. If a NOTIFY comes immediately, they > know they are authorized. If none comes, they know that haven't been > authorized, or have been rejected. Forgive me if this has already been discussed, but what's the situation if the possible replies to SUBSCRIBE are 200 (followed by NOTIFY, of course) or Silence? If there's no reply at all it's not clear to me that any useful information has been obtained by T. Before the SUBSCRIBE T already knew that it wasn't authorized, and after Silence it still knows that. What it doesn't know is whether it was actively rejected or simply not heard. If the Subscribe was accepted and NOTIFY follows then there's no problem since B apparently intended to provide information to T. > Now, this issue was discussed a lot on the impp list ... Another list to join, great. :-) Zane From zane@mabry.com Thu Jul 26 01:46:46 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11786 for ; Thu, 26 Jul 2001 01:46:45 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6Q5kiK08047 for ; Wed, 25 Jul 2001 22:46:44 -0700 (PDT) Message-ID: <03b801c11596$a1658ff0$1d00a8c0@toophat> From: "Zane Thomas" To: References: Subject: Re: [Simple] AOL chooses SIP! Date: Wed, 25 Jul 2001 22:48:43 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 729 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: Jonathan, > In case you haven't heard, it seems that AOL has chosen to go with SIP for > presence (SIMPLE) ... SIMPLE is done already? "AOL has largely completed its development of the necessary technology, has recently begun internal testing of that technology, and remains on schedule to begin testing server-to-server interoperability with a leading technology company later this summer," the report states. ... AOL's interoperability framework builds upon the IETF's (Internet Engineering Task Force) SIP for Instant Messaging and Presence Leverage (SIMPLE) messaging protocol ... Hmm, "builds upon", isn't there usually a red-flag attached to those words? Does anyone here know what AOL did? Zane From c-Dai.Ngo@WCOM.Com Thu Jul 26 10:29:37 2001 Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13242 for ; Thu, 26 Jul 2001 10:29:36 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GH300AAR48TJC@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Thu, 26 Jul 2001 14:29:17 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GH30010148Q68@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 26 Jul 2001 14:29:17 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GH300MAS48HIL@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 26 Jul 2001 14:29:05 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id <31QZ6KCX>; Thu, 26 Jul 2001 14:29:04 +0000 Content-return: allowed Date: Thu, 26 Jul 2001 14:29:00 +0000 From: "Ngo, Dai (c)" To: simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E11C61E@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_TjjpPlPFXghgCjBjMrsLCg)" Content-Length: 2479 Subject: [Simple] Request URI 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: 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_TjjpPlPFXghgCjBjMrsLCg) Content-type: text/plain; charset=ISO-8859-1 Adam et al, In section 5.2.2 of the SIP-Specific Event Notification (draft-ietf-sip-events-00.txt) it states that "The Request URI of a NOTIFY request contains enough information to route the request to the party which is subscribed to receive notifications. It is derived from the "Contact" header present in the corresponding SUBSCRIBE request.". I think this statement is only true in general, except in the following case: In the case of the Presentity, who is being subscribed to be watched, has registered with a contact specified with a Methods=NOTIFY, the address location specified with a Methods=NOTIFY in the Contact header should be used as the Request URI instead. Have I missed something? Please clarify. Thanks. -- Dai --Boundary_(ID_TjjpPlPFXghgCjBjMrsLCg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Request URI in NOTIFY

Adam et al,

In section 5.2.2 of the SIP-Specific = Event Notification (draft-ietf-sip-events-00.txt) it states that = "The Request URI of a NOTIFY request contains enough information = to route the request to the party which is subscribed to receive = notifications. It is derived from the "Contact" header = present in the corresponding SUBSCRIBE request.". I think this = statement is only true in general, except in the following = case:

In the case of the Presentity, who is = being subscribed to be watched, has registered with a contact specified = with a Methods=3DNOTIFY, the address location specified with a = Methods=3DNOTIFY in the Contact header should be used as the Request = URI instead.

Have I missed something?

Please clarify. Thanks.

-- Dai

--Boundary_(ID_TjjpPlPFXghgCjBjMrsLCg)-- From Tina.Iliff@WCOM.Com Thu Jul 26 10:50:45 2001 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 KAA13338 for ; Thu, 26 Jul 2001 10:50:45 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GH300D5I57NGQ@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Thu, 26 Jul 2001 14:50:11 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GH300E01574D0@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 26 Jul 2001 14:50:11 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GH300D4F56XIW@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 26 Jul 2001 14:49:45 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id <31QZ6L3Y>; Thu, 26 Jul 2001 14:49:45 +0000 Content-return: allowed Date: Thu, 26 Jul 2001 14:49:42 +0000 From: "Iliff, Tina" Subject: RE: [Simple] Request URI in NOTIFY To: "Ngo, Dai (c)" , simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E3F5AAE@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_bVC2NInjctnwjMsSqaEZeQ)" Content-Length: 10493 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: 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_bVC2NInjctnwjMsSqaEZeQ) Content-type: text/plain; charset=ISO-8859-1 Just my little 2 cents worth....I would assume that the Presentity when acting as a watcher would use the same address in the Contact header of the Subscribe as it uses in the REGISTER Contact header with Methods=Notify parameter. Is this a correct assumption? Tina Iliff -----Original Message----- From: Ngo, Dai (c) Sent: Thursday, July 26, 2001 9:29 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] Request URI in NOTIFY Adam et al, In section 5.2.2 of the SIP-Specific Event Notification (draft-ietf-sip-events-00.txt) it states that "The Request URI of a NOTIFY request contains enough information to route the request to the party which is subscribed to receive notifications. It is derived from the "Contact" header present in the corresponding SUBSCRIBE request.". I think this statement is only true in general, except in the following case: In the case of the Presentity, who is being subscribed to be watched, has registered with a contact specified with a Methods=NOTIFY, the address location specified with a Methods=NOTIFY in the Contact header should be used as the Request URI instead. Have I missed something? Please clarify. Thanks. -- Dai --Boundary_(ID_bVC2NInjctnwjMsSqaEZeQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Request URI in NOTIFY

Just my little 2 cents worth….I would assume that the = Presentity when acting as a watcher would use the same address in the Contact header of = the Subscribe as it uses in the REGISTER Contact header with = Methods=3DNotify parameter.

 

=

Is this a correct assumption?

 

=

Tina Iliff

 

=  

=

-----Original Message-----
From: Ngo, Dai (c)
Sent: Thursday, July 26, = 2001 9:29 AM
To: = simple@mailman.dynamicsoft.com
Subject: [Simple] = Request URI in NOTIFY

 

Adam et = al, =

In section = 5.2.2 of the SIP-Specific Event Notification (draft-ietf-sip-events-00.txt) it = states that "The Request URI of a NOTIFY request contains enough information = to route the request to the party which is subscribed to receive notifications. = It is derived from the "Contact" header present in the = corresponding SUBSCRIBE request.". I think this statement is only true in = general, except in the following case:=

In the case of = the Presentity, who is being subscribed to be watched, has registered with = a contact specified with a Methods=3DNOTIFY, the address location = specified with a Methods=3DNOTIFY in the Contact header should be used as the Request = URI instead.=

Have I missed = something? =

Please = clarify. Thanks. =

-- = Dai =

--Boundary_(ID_bVC2NInjctnwjMsSqaEZeQ)-- From zane@mabry.com Thu Jul 26 14:28:23 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13986 for ; Thu, 26 Jul 2001 14:28:22 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6QISIK24215 for ; Thu, 26 Jul 2001 11:28:18 -0700 (PDT) Message-ID: <050401c11601$063b9130$1d00a8c0@toophat> From: "Zane Thomas" To: References: <492EB4A3F68CD411ABE800508B69362E3F5AAE@RIPEXCH002.wcomnet.com> Subject: [Simple] SIP & Presence - Joined@Hip? Date: Thu, 26 Jul 2001 11:30:18 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0501_01C115C6.5922DF10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 7808 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: This is a multi-part message in MIME format. ------=_NextPart_000_0501_01C115C6.5922DF10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Request URI in NOTIFY Hmm, I'm reticent to raise this issue since I'm sure that it has been = beaten to death in the past - I must have missed something in the = archives. However ... Could someone explain to me why modifying SIP to support Presence etc is = being considered? There have been some instances in the archived = discussions where proposed solutions for handling authorization lists, = for instance, have become discussions about what's the best SIP-way to = handle the problems being discussed. The net result, for me, has been = the impression that SIP has its own simple and reasonably well-defined = goals which are distinct *for the most part* from those of Presence, and = that trying to merge the two sets of goals will limit and complicate = both. I wonder, for instance, why it's not simply good enough to add something = like: to the Contact header and then have a seperate and unconstrained = discussion of presence subscriptions and related issues. Zane ------=_NextPart_000_0501_01C115C6.5922DF10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Request URI in = NOTIFY <= ![if !supportEmptyParas]>
 
Hmm, I'm reticent=20 to raise this issue since I'm sure that it has been beaten to death in = the past=20 - I must have missed something in the archives.  However=20 ...
 
Could someone = explain to me=20 why modifying SIP to support Presence etc is being = considered?  There=20 have been some instances in the archived discussions where proposed = solutions=20 for handling authorization lists, for instance, have become discussions = about=20 what's the best SIP-way to handle the problems being discussed.  = The net=20 result, for me, has been the impression that SIP has its own simple and=20 reasonably well-defined goals which are distinct *for the most part* = from those=20 of Presence, and that trying to merge the two sets of goals will = limit and=20 complicate both.
 
I wonder, for = instance, why=20 it's not simply good enough to add something = like:
 
   =20 <pres:me@foo.bar>
 
to the Contact = header and=20 then have a seperate and unconstrained discussion of presence = subscriptions and=20 related issues.
 
Zane
 
------=_NextPart_000_0501_01C115C6.5922DF10-- From jdrosen@dynamicsoft.com Thu Jul 26 15:18:09 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14160 for ; Thu, 26 Jul 2001 15:18:08 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6QJHXki009721; Thu, 26 Jul 2001 15:17:33 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 15:18:06 -0400 Message-ID: From: Jonathan Rosenberg To: "'Zane Thomas'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] SIP & Presence - Joined@Hip? Date: Thu, 26 Jul 2001 15:18:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2261 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: Nothing in the archives? The entire history of the impp -> {simple,prim,apex} split center around these issues exactly. There are countless posts over years of impp discussions, not to mention talks and presentations, on this topic. BRIEFLY, its because (1) sip networks already have presence as its needed for session intitiaton, (2) delivery of presence and notificaiton messages to people is supported on top of existing proxy networks, (3) presence and IM are both parts of a broader communications service that also includes voice, video, etc., and it would be nice to smoothly integtrate those together, (4) when doing a requirements analysis on the protocols we found that much of whats needed is already provided by SIP. -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: Zane Thomas [mailto:zane@mabry.com] Sent: Thursday, July 26, 2001 2:30 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] SIP & Presence - Joined@Hip? Hmm, I'm reticent to raise this issue since I'm sure that it has been beaten to death in the past - I must have missed something in the archives. However ... Could someone explain to me why modifying SIP to support Presence etc is being considered? There have been some instances in the archived discussions where proposed solutions for handling authorization lists, for instance, have become discussions about what's the best SIP-way to handle the problems being discussed. The net result, for me, has been the impression that SIP has its own simple and reasonably well-defined goals which are distinct *for the most part* from those of Presence, and that trying to merge the two sets of goals will limit and complicate both. I wonder, for instance, why it's not simply good enough to add something like: to the Contact header and then have a seperate and unconstrained discussion of presence subscriptions and related issues. Zane From jdrosen@dynamicsoft.com Thu Jul 26 15:22:53 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14203 for ; Thu, 26 Jul 2001 15:22:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6QJMHki009788; Thu, 26 Jul 2001 15:22:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 15:22:50 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Request URI in NOTIFY Date: Thu, 26 Jul 2001 15:22:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1745 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: -----Original Message----- >From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] >Sent: Thursday, July 26, 2001 10:29 AM >To: simple@mailman.dynamicsoft.com >Subject: [Simple] Request URI in NOTIFY > > >Adam et al, > >In section 5.2.2 of the SIP-Specific Event Notification (draft-ietf-sip- >events-00.txt) it states that "The Request URI of a NOTIFY request contains >enough information to route the request to the party which is subscribed to >receive notifications. It is derived from the "Contact" header present in the >corresponding SUBSCRIBE request.". I think this statement is only true in >general, except in the following case: >In the case of the Presentity, who is being subscribed to be watched, has >registered with a contact specified with a Methods=NOTIFY, the address >location specified with a Methods=NOTIFY in the Contact header should be used >as the Request URI instead. You've got things in the wrong direction. If A subscribes to B, B is the presentity. The NOTIFY is sent to A. That NOTIFY has to have a request URI which routes back to A. To do that, we have agreed, I believe, to have SUBSCRIBE use INVITE semantics for record-routing. THis means that if no proxies record-route, the NOTIFY to A is sent to the Contact that A provided in their SUBSCRIBE. This has nothing to do with any registrations of any sort that the presentity has made. -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 From c-Dai.Ngo@WCOM.Com Thu Jul 26 15:34:19 2001 Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14262 for ; Thu, 26 Jul 2001 15:34:18 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GH30093PID4FH@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Thu, 26 Jul 2001 19:34:16 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GH300L01IC1Y7@dgismtp04.wcomnet.com>; Thu, 26 Jul 2001 19:34:15 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GH300IN4IBZLO@dgismtp04.wcomnet.com>; Thu, 26 Jul 2001 19:33:35 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 19:33:34 +0000 Content-return: allowed Date: Thu, 26 Jul 2001 19:33:32 +0000 From: "Ngo, Dai (c)" Subject: RE: [Simple] Request URI in NOTIFY To: "'Jonathan Rosenberg'" , simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E11C622@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_tGGp3FFR//7s/D++UI5U9g)" Content-Length: 8626 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: 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_tGGp3FFR//7s/D++UI5U9g) Content-type: text/plain; charset=iso-8859-1 Jonathan, You're right that I have made an error in stating the question. Here is the scenario: A (watcher) subscribes to watch B (the Presentity) There is a contact header in the SUBSCRIBE from A: A@host2.com. A also has previously registered with a contact, which specified Methods=NOTIFY, i.e. A@host1.com;Methods=NOTIFY B now needs to send a NOTIFY to A. Which address is to be specified in the Request URI for the NOTIFY: The address in the Contact header of the SUBSCRIBE, or the address with Methods=NOTIFY in the registrar database? Thanks. Dai -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, July 26, 2001 2:23 PM To: Ngo, Dai (c); simple@mailman.dynamicsoft.com Subject: RE: [Simple] Request URI in NOTIFY -----Original Message----- >From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] >Sent: Thursday, July 26, 2001 10:29 AM >To: simple@mailman.dynamicsoft.com >Subject: [Simple] Request URI in NOTIFY > > >Adam et al, > >In section 5.2.2 of the SIP-Specific Event Notification (draft-ietf-sip- >events-00.txt) it states that "The Request URI of a NOTIFY request contains >enough information to route the request to the party which is subscribed to >receive notifications. It is derived from the "Contact" header present in the >corresponding SUBSCRIBE request.". I think this statement is only true in >general, except in the following case: >In the case of the Presentity, who is being subscribed to be watched, has >registered with a contact specified with a Methods=NOTIFY, the address >location specified with a Methods=NOTIFY in the Contact header should be used >as the Request URI instead. You've got things in the wrong direction. If A subscribes to B, B is the presentity. The NOTIFY is sent to A. That NOTIFY has to have a request URI which routes back to A. To do that, we have agreed, I believe, to have SUBSCRIBE use INVITE semantics for record-routing. THis means that if no proxies record-route, the NOTIFY to A is sent to the Contact that A provided in their SUBSCRIBE. This has nothing to do with any registrations of any sort that the presentity has made. -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 --Boundary_(ID_tGGp3FFR//7s/D++UI5U9g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: [Simple] Request URI in NOTIFY

Jonathan,

You're right that I have made an error in stating the = question. Here is the scenario:

A (watcher) subscribes to watch B (the = Presentity)
There is a contact header in the SUBSCRIBE from A: = A@host2.com.
A also has previously registered with a contact, = which specified Methods=3DNOTIFY, i.e. = A@host1.com;Methods=3DNOTIFY

B now needs to send a NOTIFY to A.

Which address is to be specified in the Request URI = for the NOTIFY: The address in the Contact header of the SUBSCRIBE, or = the address with Methods=3DNOTIFY in the registrar database?

Thanks.

Dai

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, July 26, 2001 2:23 PM
To: Ngo, Dai (c); = simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Request URI in NOTIFY




 
-----Original Message-----
>From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com]=
>Sent: Thursday, July 26, 2001 10:29 AM
>To: simple@mailman.dynamicsoft.com
>Subject: [Simple] Request URI in NOTIFY
>
>
>Adam et al,
>
>In section 5.2.2 of the SIP-Specific Event = Notification (draft-ietf-sip-
>events-00.txt) it states that "The Request = URI of a NOTIFY request contains

>enough information to route the request to the = party which is subscribed to

>receive notifications. It is derived from the = "Contact" header present in
the
>corresponding SUBSCRIBE request.". I think = this statement is only true in
>general, except in the following case:

>In the case of the Presentity, who is being = subscribed to be watched, has
>registered with a contact specified with a = Methods=3DNOTIFY, the address
>location specified with a Methods=3DNOTIFY in = the Contact header should be
used
>as the Request URI instead.


You've got things in the wrong direction. If A = subscribes to B, B is the
presentity. The NOTIFY is sent to A. That NOTIFY has = to have a request URI
which routes back to A. To do that, we have agreed, = I believe, to have
SUBSCRIBE use INVITE semantics for record-routing. = THis means that if no
proxies record-route, the NOTIFY to A is sent to the = Contact that A provided
in their SUBSCRIBE. This has nothing to do with any = registrations of any
sort that the presentity has made.

-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=

--Boundary_(ID_tGGp3FFR//7s/D++UI5U9g)-- From jdrosen@dynamicsoft.com Thu Jul 26 15:46:21 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14339 for ; Thu, 26 Jul 2001 15:46:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6QJjkki010048; Thu, 26 Jul 2001 15:45:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 15:46:20 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Request URI in NOTIFY Date: Thu, 26 Jul 2001 15:46:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1547 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: -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] Sent: Thursday, July 26, 2001 3:34 PM To: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Request URI in NOTIFY >Jonathan, >You're right that I have made an error in stating the question. Here is the >scenario: >A (watcher) subscribes to watch B (the Presentity) > >There is a contact header in the SUBSCRIBE from A: A@host2.com. > >A also has previously registered with a contact, which specified >Methods=NOTIFY, i.e. A@host1.com;Methods=NOTIFY > >B now needs to send a NOTIFY to A. >Which address is to be specified in the Request URI for the NOTIFY: The >address in the Contact header of the SUBSCRIBE, or the address with >Methods=NOTIFY in the registrar database? How would B know whats in the registration database for A, who is some client in some provider on the other side of the planet? We use standard SIP record-routing techniques. If no proxies record-route, the request URI in the NOTIFY is from the Contact in the SUBSCRIBE. If proxies record-route, the request URI in the NOTIFY is the top record-route entry (ie, that of the proxy closest to B). -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 From c-Dai.Ngo@WCOM.Com Thu Jul 26 15:56:19 2001 Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14400 for ; Thu, 26 Jul 2001 15:56:19 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GH300IBMJCTB0@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Thu, 26 Jul 2001 19:55:41 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GH300A01JC34K@dgismtp04.wcomnet.com>; Thu, 26 Jul 2001 19:55:40 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GH30094NJAC4U@dgismtp04.wcomnet.com>; Thu, 26 Jul 2001 19:54:13 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 19:54:12 +0000 Content-return: allowed Date: Thu, 26 Jul 2001 19:54:10 +0000 From: "Ngo, Dai (c)" Subject: RE: [Simple] Request URI in NOTIFY To: "'Jonathan Rosenberg'" , simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E11C623@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_XTdXHi5Q/lfh/oBX3iCgBw)" Content-Length: 6931 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: 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_XTdXHi5Q/lfh/oBX3iCgBw) Content-type: text/plain; charset=iso-8859-1 Jonathan, A and B both use the same Presence Server/Registrar therefore the PS knows of A and B. Since B changes status the PS needs to send NOTIFY to A. Maybe I'm still confusing about the purpose of using "Methods=NOTIFY". Could you please summarize it then? -- Dai -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, July 26, 2001 2:46 PM To: Ngo, Dai (c); Jonathan Rosenberg; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Request URI in NOTIFY -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] Sent: Thursday, July 26, 2001 3:34 PM To: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Request URI in NOTIFY >Jonathan, >You're right that I have made an error in stating the question. Here is the >scenario: >A (watcher) subscribes to watch B (the Presentity) > >There is a contact header in the SUBSCRIBE from A: A@host2.com. > >A also has previously registered with a contact, which specified >Methods=NOTIFY, i.e. A@host1.com;Methods=NOTIFY > >B now needs to send a NOTIFY to A. >Which address is to be specified in the Request URI for the NOTIFY: The >address in the Contact header of the SUBSCRIBE, or the address with >Methods=NOTIFY in the registrar database? How would B know whats in the registration database for A, who is some client in some provider on the other side of the planet? We use standard SIP record-routing techniques. If no proxies record-route, the request URI in the NOTIFY is from the Contact in the SUBSCRIBE. If proxies record-route, the request URI in the NOTIFY is the top record-route entry (ie, that of the proxy closest to B). -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 --Boundary_(ID_XTdXHi5Q/lfh/oBX3iCgBw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable RE: [Simple] Request URI in NOTIFY

Jonathan,

A and B both use the same Presence Server/Registrar = therefore the PS knows of A and B. Since B changes status the PS needs = to send NOTIFY to A.

Maybe I'm still confusing about the purpose of using = "Methods=3DNOTIFY". Could you please summarize it = then?

-- Dai

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, July 26, 2001 2:46 PM
To: Ngo, Dai (c); Jonathan Rosenberg; = simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Request URI in NOTIFY




 
-----Original Message-----
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com]=
Sent: Thursday, July 26, 2001 3:34 PM
To: 'Jonathan Rosenberg'; = simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Request URI in NOTIFY


>Jonathan,
>You're right that I have made an error in = stating the question. Here is the

>scenario:

>A (watcher) subscribes to watch B (the = Presentity)
>
>There is a contact header in the SUBSCRIBE from = A: A@host2.com.
>
>A also has previously registered with a contact, = which specified
>Methods=3DNOTIFY, i.e. = A@host1.com;Methods=3DNOTIFY
>
>B now needs to send a NOTIFY to A.
>Which address is to be specified in the Request = URI for the NOTIFY: The
>address in the Contact header of the SUBSCRIBE, = or the address with
>Methods=3DNOTIFY in the registrar = database?

How would B know whats in the registration database = for A, who is some
client in some provider on the other side of the = planet? We use standard SIP
record-routing techniques. If no proxies = record-route, the request URI in
the NOTIFY is from the Contact in the SUBSCRIBE. If = proxies record-route,
the request URI in the NOTIFY is the top = record-route entry (ie, that of the
proxy closest to B).

-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

--Boundary_(ID_XTdXHi5Q/lfh/oBX3iCgBw)-- From bcampbell@dynamicsoft.com Thu Jul 26 16:10:07 2001 Received: from localhost.localdomain ([63.110.3.239]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14487 for ; Thu, 26 Jul 2001 16:10:07 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6QK1is09007; Thu, 26 Jul 2001 15:01:44 -0500 Message-ID: <3B607728.2070708@dynamicsoft.com> Date: Thu, 26 Jul 2001 15:01:44 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Vasilis Polychronidis CC: Jonathan Rosenberg , aoki@aol.net, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: Scalability at a macro level References: <3B5FAAD9.E854AFD5@Openwave.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1460 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: Vasilis Polychronidis wrote: [snip] > My question is with your SDP definition which I believe is very > restrictive and > does not allow for any other transport than SIP. > The session description should be flexible enough to allow different > message > transport protocols. The sdp draft was intended to define the sdp for IM over SIP. That is the purpose of the protocol field in the m-line. If others wish to define sdp for IM over other protocols, they are welcome to do so with a different protocol field value. > For example I am proposing something like the following: > > c = IN IP4 FQDN or IP Address > m = message [ "/" MP integer] > > where: > FQDN or IP Address = the address/identifier of expected data source or data > relay or > data sink > port = port number > protocol = udp | tcp | http | rtp | sip/udp | sip/tcp > sip/udp and sip/tcp should not be used to transport messages over > SIP proxies > (signaling) > IM-identifier = im:user@domain (CPIM IM identifier) > MP stands for message profile > for example MP 0 may mean CPIM > MP 1 may represent some type of XML type message > etc. > I was wondering if you are planning to extend your ID to include this case? The c-line is somewhat problematic, in that we want to user a rich URL form of addressing, not simply a fqdn or address. The port to be used and the transport protocol is also fully described by the URL. Thanks! Ben. From bcampbell@dynamicsoft.com Thu Jul 26 16:19:33 2001 Received: from localhost.localdomain ([63.110.3.239]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14543 for ; Thu, 26 Jul 2001 16:19:32 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6QKBFs09267; Thu, 26 Jul 2001 15:11:16 -0500 Message-ID: <3B607963.9000808@dynamicsoft.com> Date: Thu, 26 Jul 2001 15:11:15 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Request URI in NOTIFY References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1418 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: > >>A (watcher) subscribes to watch B (the Presentity) >> >>There is a contact header in the SUBSCRIBE from A: A@host2.com. >> >>A also has previously registered with a contact, which specified >>Methods=NOTIFY, i.e. A@host1.com;Methods=NOTIFY >> >>B now needs to send a NOTIFY to A. >>Which address is to be specified in the Request URI for the NOTIFY: The >>address in the Contact header of the SUBSCRIBE, or the address with >>Methods=NOTIFY in the registrar database? >> > > How would B know whats in the registration database for A, who is some > client in some provider on the other side of the planet? We use standard SIP > record-routing techniques. If no proxies record-route, the request URI in > the NOTIFY is from the Contact in the SUBSCRIBE. If proxies record-route, > the request URI in the NOTIFY is the top record-route entry (ie, that of the > proxy closest to B). > What if the contact header in the SUBSCRIBE that A sent actually points to a proxy/registrar, which A has registered to point to somewhere else? For example, A sends a register to the proxy/registrar P with a From: of A@P and a Contact: ;methods=NOTIFY. A then sends a SUBSCRIBE to B with a Contact: sip:A@P. It would seem to me that the NOTIFY would go via A@P, and get proxied or redirected to A&A (if the absense of a record-route, of course.) I suspect this is the sort of scenario that Dai intended. From bcampbell@dynamicsoft.com Thu Jul 26 16:22:31 2001 Received: from localhost.localdomain ([63.110.3.239]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14583 for ; Thu, 26 Jul 2001 16:22:31 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6QKEKs09283; Thu, 26 Jul 2001 15:14:21 -0500 Message-ID: <3B607A1C.3040308@dynamicsoft.com> Date: Thu, 26 Jul 2001 15:14:20 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Zane Thomas CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIP & Presence - Joined@Hip? References: <492EB4A3F68CD411ABE800508B69362E3F5AAE@RIPEXCH002.wcomnet.com> <050401c11601$063b9130$1d00a8c0@toophat> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1166 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: Zane Thomas wrote: > > > Hmm, I'm reticent to raise this issue since I'm sure that it has been > beaten to death in the past - I must have missed something in the > archives. However ... > > > > Could someone explain to me why modifying SIP to support Presence etc is > being considered? There have been some instances in the archived > discussions where proposed solutions for handling authorization lists, > for instance, have become discussions about what's the best SIP-way to > handle the problems being discussed. The net result, for me, has been > the impression that SIP has its own simple and reasonably well-defined > goals which are distinct *for the most part* from those of Presence, and > that trying to merge the two sets of goals will limit and complicate both. > > > > I wonder, for instance, why it's not simply good enough to add something > like: > > > > > > > > to the Contact header and then have a seperate and unconstrained > discussion of presence subscriptions and related issues. > > > Well, the SIMPLE working group charter mandates presence and instant messaging over SIP. From Vasilis.Polychronidis@Openwave.com Thu Jul 26 16:25:19 2001 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 QAA14622 for ; Thu, 26 Jul 2001 16:25:18 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010726202443.KHXL11012.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Thu, 26 Jul 2001 15:24:43 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010726202431.GTAA1691.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Thu, 26 Jul 2001 15:24:31 -0500 Message-ID: <3B607C9D.90B03FE0@Openwave.com> Date: Thu, 26 Jul 2001 13:25:02 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ben Campbell CC: Jonathan Rosenberg , aoki@aol.net, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Re: Scalability at a macro level References: <3B5FAAD9.E854AFD5@Openwave.com> <3B607728.2070708@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1797 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: Ben thank you for your prompt and informative answer. BR, -Vasilis Polychronidis Ben Campbell wrote: > Vasilis Polychronidis wrote: > > [snip] > > > My question is with your SDP definition which I believe is very > > restrictive and > > does not allow for any other transport than SIP. > > The session description should be flexible enough to allow different > > message > > transport protocols. > > The sdp draft was intended to define the sdp for IM over SIP. That is > the purpose of the protocol field in the m-line. If others wish to > define sdp for IM over other protocols, they are welcome to do so with a > different protocol field value. > > > For example I am proposing something like the following: > > > > c = IN IP4 FQDN or IP Address > > m = message [ "/" MP integer] > > > > where: > > FQDN or IP Address = the address/identifier of expected data source or data > > relay or > > data sink > > port = port number > > protocol = udp | tcp | http | rtp | sip/udp | sip/tcp > > sip/udp and sip/tcp should not be used to transport messages over > > SIP proxies > > (signaling) > > IM-identifier = im:user@domain (CPIM IM identifier) > > MP stands for message profile > > for example MP 0 may mean CPIM > > MP 1 may represent some type of XML type message > > etc. > > I was wondering if you are planning to extend your ID to include this case? > > The c-line is somewhat problematic, in that we want to user a rich URL > form of addressing, not simply a fqdn or address. The port to be used > and the transport protocol is also fully described by the URL. > > Thanks! > > Ben. > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From zane@mabry.com Thu Jul 26 17:09:29 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14806 for ; Thu, 26 Jul 2001 17:09:28 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6QL9RK07842 for ; Thu, 26 Jul 2001 14:09:27 -0700 (PDT) Message-ID: <059b01c11617$892c5f50$1d00a8c0@toophat> From: "Zane Thomas" To: References: Subject: Re: [Simple] SIP & Presence - Joined@Hip? Date: Thu, 26 Jul 2001 14:11:27 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 3001 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: Jonathan, Thanks for the reply. > Nothing in the archives? I certainly didn't mean to imply that there *was* nothing in the archives. What I meant to say was that I spent many hours yesterday reading the SIMPLE archives and *I* didn't see the background material - I went back and looked some more this morning before posting. I realize it can be annoying when newbies come along so late in the discussion and ask what can be rather fundamental questions, so I made an effort. If you would like to direct my attention to other relevant archives and etc I will be *more than happy* to take a look - feel free to make any such suggestions as preliminary (or conclusive) replies to my further questions/comments. > (1) sip networks already have presence as its needed > for session intitiaton Yes, as it's needed for Initiation. But apparently not as needed in the more general sense - otherwise there wouldn't be any discussion about extending it. > (2) delivery of presence and notificaiton messages > to people is supported on top of existing proxy networks Yes, I understand that. > (3) presence and > IM are both parts of a broader communications service that also includes > voice, video, etc., and it would be nice to smoothly integtrate those > together You're losing me there. I see that there are things like RTP for carrying "real time" data. That makes sense to me, you use SIP to initiate a session and SDP to specify RTP, for instance. What I don't understand is why IM is being handled differently. Also from draft-rosenberg-impp-im-01.htm I see the following: "Instant messaging is defined as the exchange of content between a set of participants in real time. Generally, the content is short textual messages, although that need not be the case." Aside from the admittedly not insignificant differences between the different types of "real time" data represented by IMs and audio, for instance, it's not clear to me what is so *fundamentally* different that IM should have special status in SIP. I realize there is some difficulty in defining exactly what a Session is with IM but it seems to me that any particular IM application might choose to define one in a number of different ways. For instance, I might define a Session (from the SIP perspective) as two peers knowing each other are online and establishing UDP ports to use for exchanging messages. Above that - in my application - I might further define another type of Session which consisted some sequences of message-reply pairs, for the purpose of providing convenient views of message history. Another thing that occured to me is that if you provide an arbitrarily large MESSAGE which can be sent over SIP proxys then it won't be long before the SIP servers are carrying a lot of traffic containing MP3 files. >(4) when doing a requirements analysis on the protocols we found > that much of whats needed is already provided by SIP. Is that information available on the web somewhere? Tia, Zane From zane@mabry.com Thu Jul 26 17:19:32 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14876 for ; Thu, 26 Jul 2001 17:19:31 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6QLJSK14486 for ; Thu, 26 Jul 2001 14:19:28 -0700 (PDT) Message-ID: <05ad01c11618$f04367a0$1d00a8c0@toophat> From: "Zane Thomas" To: References: <492EB4A3F68CD411ABE800508B69362E3F5AAE@RIPEXCH002.wcomnet.com> <050401c11601$063b9130$1d00a8c0@toophat> <3B607A1C.3040308@dynamicsoft.com> Subject: Re: [Simple] SIP & Presence - Joined@Hip? Date: Thu, 26 Jul 2001 14:21:28 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 516 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: Ben, > Well, the SIMPLE working group charter mandates presence and instant > messaging over SIP. I'd like to make it clear that I'm not *arguing* that the charter is problematic, however it could be the case that it just doesn't work out in the long run. That - correct or not - was the impression I got as I read the past few months emails. Well, however it works out, here's one of my favorite all-time sayings: "The nice thing about standards is that there are so many of them to choose from." Zane From bcampbell@dynamicsoft.com Thu Jul 26 17:34:17 2001 Received: from localhost.localdomain ([63.110.3.239]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14949 for ; Thu, 26 Jul 2001 17:34:16 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6QLPNs24388; Thu, 26 Jul 2001 16:25:23 -0500 Message-ID: <3B608AC3.9010808@dynamicsoft.com> Date: Thu, 26 Jul 2001 16:25:23 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Kyzivat CC: Internet-Drafts@ietf.org, IETF-Announce:@cisco.com, ";"@cisco.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt References: <200107191106.HAA28698@ietf.org> <3B58980A.DE01ED13@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 3548 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: Paul Kyzivat wrote: > This is a great improvement to the SIMPLE stuff, because it begins > redraw the line between session initiation and media that was muddled > with the addition of MESSAGE to SIP. There clearly needs to be a way to > negotiate text messaging as one medium of a SIP call, and this provides > that. > > I have a few questions/comments: > > - how does one negotiate a oneway session? Presumably if alice wants > to receive but not sent, she can send the following in an invite: > > m=message 5060 sip sip:alice@alicepc > a=recvonly > > but what does bob send in return? perhaps something like: > > m=message ??? sip ??? > a=sendonly > Presumably it would be something like that. Since it is sendonly and we are not worrying about things like RTCP, the port and URL fields are meaningless. > And whatever this is, does it also work in an invite if the person > inviting wants to be sendonly? > > (I believe comedia used port 9 to indicate a sink. I suppose that > could be adopted here - perhaps: > > m=message 9 sip > a=sendonly > > but I don't find the use of the magic number 9 very appealing.) > Again, if the stream is sendonly, then I don't see that it matters what goes into the port and URL. > Similarly, what do I do to refuse the media stream? > Do I still use port zero for this purpose, even though the port > in this m= line is gratuitous? That's a good question. We could do something simular by specifying a zero port in the URL. However, I lean towards putting zero in the port field, with the realization that the receiver must now pay attention to that field, at least to check for zeros. > > - does there need to be any notion of HOLD in the sense that is > used for voice? To go on hold, should I send a reinvite with > c=0.0.0.0 even though the c= line is irrelevant here? Or should > I reinvite as sendonly? (The general case of this has been > discussed elsewhere. I favor a=sendonly as the media independent > way to go on hold, with the c=0 being an optional step for media > where it makes sense.) I think I agree with you. > > - section 4 forbids no-SDP invites, using the excuse that the > UAS will not know to offer the message medium. This shows a strong > voice bias. If you don't offer media in an invite, you ought to > expect the UAS to offer whatever it thinks appropriate, which > could be any medium if you haven't expressed any preference. > You will notice that one is in the open issue section. I waffled in both directions, and will be glad to accept the wg consensus. > If I don't want to specify any specific media values, but I do > want to indicate what I might be interested in using, then > callerprefs provides a way to do that: I can include a media= > parameter to the Contact header in my INVITE. > > - in draft-ietf-simple-im-sdp-00 there is mention of the possibility > of other transports than sip. That is fine as far as the SDP > syntax goes. But how would that work in practice with SIP? > Unlike codecs, I can't offer multiple transports with the same > m= line. So it is difficult to see how I might negotiate which > transport a pair of UAs might wish to use to exchange messages. > I suppose one could offer multiple media streams, and the receiver could decline those it was not interested in. This could of course result in multiple simultaneous message sessions. I'm not sure if that is a problem or not. Thanks! Ben. From bcampbell@dynamicsoft.com Thu Jul 26 17:48:30 2001 Received: from localhost.localdomain ([63.110.3.239]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15025 for ; Thu, 26 Jul 2001 17:48:29 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6QLeFs07803; Thu, 26 Jul 2001 16:40:15 -0500 Message-ID: <3B608E3F.5020909@dynamicsoft.com> Date: Thu, 26 Jul 2001 16:40:15 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Zane Thomas CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIP & Presence - Joined@Hip? References: <059b01c11617$892c5f50$1d00a8c0@toophat> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1040 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: Zane Thomas wrote: > Jonathan, > > Thanks for the reply. > > >>Nothing in the archives? >> > > I certainly didn't mean to imply that there *was* nothing in the archives. > What I meant to say was that I spent many hours yesterday reading the SIMPLE > archives and *I* didn't see the background material - I went back and looked > some more this morning before posting. I realize it can be annoying when > newbies come along so late in the discussion and ask what can be rather > fundamental questions, so I made an effort. > > If you would like to direct my attention to other relevant archives and etc > I will be *more than happy* to take a look - feel free to make any such > suggestions as preliminary (or conclusive) replies to my further > questions/comments. > The discussions Jonathan refers to would be in the IMPP archives, not the SIMPLE archives. These discussions predated the formation of the SIMPLE group (and in fact led directly to its formation.) You will probably need to go back about a year to find them. From zane@mabry.com Thu Jul 26 18:10:50 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15123 for ; Thu, 26 Jul 2001 18:10:49 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6QMAlK18332 for ; Thu, 26 Jul 2001 15:10:47 -0700 (PDT) Message-ID: <05d701c11620$1ac383f0$1d00a8c0@toophat> From: "Zane Thomas" To: References: <059b01c11617$892c5f50$1d00a8c0@toophat> <3B608E3F.5020909@dynamicsoft.com> Subject: Re: [Simple] SIP & Presence - Joined@Hip? Date: Thu, 26 Jul 2001 15:12:47 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 135 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: Ben, > The discussions Jonathan refers to would be in the IMPP archives ... Thanks for the tip, I'll go look for the archive. Zane From dgboyer@avaya.com Fri Jul 27 11:48:00 2001 Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17852 for ; Fri, 27 Jul 2001 11:48:00 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6RFlDj04169 for ; Fri, 27 Jul 2001 11:47:13 -0400 (EDT) Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f6RFlDR04162 for ; Fri, 27 Jul 2001 11:47:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C116B3.8348C168" Subject: RE: [Simple] SIP & Presence - Joined@Hip? Date: Fri, 27 Jul 2001 11:48:00 -0400 Message-ID: <8CA1128D59AD27429985B397118CEDDF39109B@nj7460avexu1.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] SIP & Presence - Joined@Hip? Thread-Index: AcEWGMow4HVglducS9WjZ5JrtylwfQAmkr0A From: "Boyer, David G (Dave)" To: "Zane Thomas" , Content-Length: 4911 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C116B3.8348C168 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zane, Included in the SIP architecture is a Presence Server. It seems likely that the Presence Server will get messages from other sources besides SIP endpoints. A face recognition system might register my presence with a Presence Server. It doesn't make sense to register the camera associated with this capability with the SIP Registrar since it can't be used for communications. Dave > -----Original Message----- > From: Zane Thomas [mailto:zane@mabry.com] > Sent: Thursday, July 26, 2001 5:21 PM > To: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] SIP & Presence - Joined@Hip? >=20 >=20 > Ben, >=20 > > Well, the SIMPLE working group charter mandates presence and instant > > messaging over SIP. >=20 > I'd like to make it clear that I'm not *arguing* that the charter is > problematic, however it could be the case that it just=20 > doesn't work out in > the long run. That - correct or not - was the impression I=20 > got as I read > the past few months emails. >=20 > Well, however it works out, here's one of my favorite=20 > all-time sayings: >=20 > "The nice thing about standards is that there are so many=20 > of them to > choose from." >=20 >=20 > Zane >=20 >=20 > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple >=20 ------_=_NextPart_001_01C116B3.8348C168 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] SIP & Presence - Joined@Hip?

Hi Zane,

Included in the SIP architecture is a Presence = Server.
It seems likely that the Presence Server will get = messages
from other sources besides SIP endpoints.  A = face recognition
system might register my presence with a Presence = Server.
It doesn't make sense to register the camera = associated with
this capability with the SIP Registrar since it can't = be
used for communications.

Dave
 > -----Original Message-----
> From: Zane Thomas [mailto:zane@mabry.com]
> Sent: Thursday, July 26, 2001 5:21 PM
> To: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] SIP & Presence - = Joined@Hip?
>
>
> Ben,
>
> > Well, the SIMPLE working group charter = mandates presence and instant
> > messaging over SIP.
>
> I'd like to make it clear that I'm not *arguing* = that the charter is
> problematic,  however it could be the case = that it just
> doesn't work out in
> the long run.  That - correct or not - was = the impression I
> got as I read
> the past few months emails.
>
> Well, however it works out, here's one of my = favorite
> all-time sayings:
>
>    "The nice thing about = standards is that there are so many
> of them to
> choose from."
>
>
> Zane
>
>
> = _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple
>

------_=_NextPart_001_01C116B3.8348C168-- From jon.peterson@NeuStar.com Fri Jul 27 13:31:45 2001 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18174 for ; Fri, 27 Jul 2001 13:31:45 -0400 (EDT) Received: from chi02.npac.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f6RHVh319566 for ; Fri, 27 Jul 2001 13:31:43 -0400 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2653.19) id <317JZ82X>; Fri, 27 Jul 2001 12:29:37 -0500 Message-ID: <70565611B164D511957A001083FCDD564789B2@va02.va.neustar.com> From: "Peterson, Jon" To: "'simple@mailman.dynamicsoft.com'" Date: Fri, 27 Jul 2001 12:31:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 257 Subject: [Simple] new contact 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: As some of you are already aware, I have recently changed employers; this email reflects my current contact information. Please direct all further correspondence to me at this address. Jon Peterson (jon.peterson@neustar.com) NeuStar, Inc. SIMPLE co-chair From zane@mabry.com Fri Jul 27 14:04:36 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18285 for ; Fri, 27 Jul 2001 14:04:35 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6RI4XK10856 for ; Fri, 27 Jul 2001 11:04:33 -0700 (PDT) Message-ID: <07c501c116c6$e0a61140$1d00a8c0@toophat> From: "Zane Thomas" To: References: <8CA1128D59AD27429985B397118CEDDF39109B@nj7460avexu1.global.avaya.com> Subject: Re: [Simple] SIP & Presence - Joined@Hip? Date: Fri, 27 Jul 2001 11:06:36 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C2_01C1168C.33DE6550" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 4285 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: This is a multi-part message in MIME format. ------=_NextPart_000_07C2_01C1168C.33DE6550 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] SIP & Presence - Joined@Hip?Hi David, Included in the SIP architecture is a Presence Server. If you're refering to SIMPLE then I agree that the effort is to = introduce presence into SIP. However I don't read the current SIP spec = as providing *presence* information, what it does provide is Contact = information. Knowing how to contact someone does not tell you whether = they are actually present - at least until they accept the initiation of = a session; the current contact information could be a voicemail box, = email, or even a fax - if I read 10.14 of SIP correctly. =20 It seems likely that the Presence Server will get messages=20 from other sources besides SIP endpoints.=20 That seems to me to argue that Presence is fundamentally distinct from = SIP ... A face recognition=20 system might register my presence with a Presence Server.=20 It doesn't make sense to register the camera associated with=20 this capability with the SIP Registrar since it can't be=20 used for communications.=20 For instance, a face recognition system could be used to track the = presence of people in secure facilities and that has nothing to do with = initiating a Session, unless an armed guard is going to be dispatched = for that purpose. :-)=20 Zane ------=_NextPart_000_07C2_01C1168C.33DE6550 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] SIP & Presence - Joined@Hip?
Hi David,
 

Included in the SIP architecture is a Presence=20 Server.

If you're refering to SIMPLE then I agree = that the=20 effort is to introduce presence into SIP.  However I don't read the = current=20 SIP spec as providing *presence* information, what it does provide is = Contact=20 information.  Knowing how to contact someone does not tell you=20 whether they are actually present - at least until they accept = the=20 initiation of a session; the current contact information could be a = voicemail box, email, or even a fax - if I read 10.14 of SIP=20 correctly.

 
It seems likely that the Presence Server = will get=20 messages
from other sources besides SIP=20 endpoints. 

That seems to me to argue that Presence is = fundamentally=20 distinct from SIP ...

A face recognition
system = might=20 register my presence with a Presence Server.
It=20 doesn't make sense to register the camera associated with =
this capability with the SIP Registrar since it can't = be=20
used for communications.

For instance, a face recognition system = could be used to=20 track the presence of people in secure facilities and that has nothing = to do=20 with initiating a Session, unless an armed guard is going to be = dispatched for=20 that purpose. :-) 

Zane

 

------=_NextPart_000_07C2_01C1168C.33DE6550-- From jdrosen@dynamicsoft.com Fri Jul 27 18:09:55 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19014 for ; Fri, 27 Jul 2001 18:09:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6RM9Kki015132; Fri, 27 Jul 2001 18:09:20 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 18:09:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'Zane Thomas'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] SIP & Presence - Joined@Hip? Date: Fri, 27 Jul 2001 18:09:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2269 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: > -----Original Message----- > From: Zane Thomas [mailto:zane@mabry.com] > Sent: Thursday, July 26, 2001 5:11 PM > To: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] SIP & Presence - Joined@Hip? > > > "Instant messaging is defined as the exchange of content > between a set of > participants in real time. Generally, the content is short > textual messages, > although that need not be the case." > > Aside from the admittedly not insignificant differences between the > different types of "real time" data represented by IMs and audio, for > instance, it's not clear to me what is so *fundamentally* > different that IM > should have special status in SIP. Indeed, which would explain why the group is using SIP to establish IM exchanges as a session described in the SDP. This has been discussed on the simple list, and is reflected in two drafts which sit on the SIMPLE web page. I recommend you peruse them: http://www.ietf.org/internet-drafts/draft-ietf-simple-im-sdp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-im-session-00.txt > > I realize there is some difficulty in defining exactly what a > Session is > with IM but it seems to me that any particular IM application > might choose > to define one in a number of different ways. For instance, I > might define a > Session (from the SIP perspective) as two peers knowing each other are > online and establishing UDP ports to use for exchanging > messages. Sounds like you are arguing that presence and session initiation are related. > Another thing that occured to me is that if you provide an > arbitrarily large > MESSAGE which can be sent over SIP proxys then it won't be > long before the > SIP servers are carrying a lot of traffic containing MP3 files. Which is why the current drafts discuss establishing message transport e2e (nats and firewalls permitting), over TCP for such things. -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 From Vasilis.Polychronidis@Openwave.com Fri Jul 27 18:32:21 2001 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 SAA19112 for ; Fri, 27 Jul 2001 18:32:20 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010727223037.POEC12909.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Fri, 27 Jul 2001 17:30:37 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010727223204.JBUC3658.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Fri, 27 Jul 2001 17:32:04 -0500 Message-ID: <3B61EBD8.617C95F0@Openwave.com> Date: Fri, 27 Jul 2001 15:31:52 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Zane Thomas'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] SIP & Presence - Joined@Hip? References: Content-Type: multipart/alternative; boundary="------------09134EA5E8FDDAA102D40543" Content-Length: 6962 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: --------------09134EA5E8FDDAA102D40543 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Zane Thomas [mailto:zane@mabry.com] > > Sent: Thursday, July 26, 2001 5:11 PM > > To: simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] SIP & Presence - Joined@Hip? > > > > > > "Instant messaging is defined as the exchange of content > > between a set of > > participants in real time. Generally, the content is short > > textual messages, > > although that need not be the case." > > > > Aside from the admittedly not insignificant differences between the > > different types of "real time" data represented by IMs and audio, for > > instance, it's not clear to me what is so *fundamentally* > > different that IM > > should have special status in SIP. > > Indeed, which would explain why the group is using SIP to establish IM > exchanges as a session described in the SDP. This has been discussed on the > simple list, and is reflected in two drafts which sit on the SIMPLE web > page. I recommend you peruse them: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-im-sdp-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-im-session-00.txt > > > > > I realize there is some difficulty in defining exactly what a > > Session is > > with IM but it seems to me that any particular IM application > > might choose > > to define one in a number of different ways. For instance, I > > might define a > > Session (from the SIP perspective) as two peers knowing each other are > > online and establishing UDP ports to use for exchanging > > messages. > > Sounds like you are arguing that presence and session initiation are > related. > > > Another thing that occured to me is that if you provide an > > arbitrarily large > > MESSAGE which can be sent over SIP proxys then it won't be > > long before the > > SIP servers are carrying a lot of traffic containing MP3 files. > > Which is why the current drafts discuss establishing message transport e2e > (nats and firewalls permitting), over TCP for such things. Do you mean over TCP or over SIP/TCP? I definitely support the first case over TCP or UDP for that matter. I do not see the value of extra overhead of using SIP as transport. Do you? > > > -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 --------------09134EA5E8FDDAA102D40543 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote:
 

> -----Original Message-----
> From: Zane Thomas [mailto:zane@mabry.com]
> Sent: Thursday, July 26, 2001 5:11 PM
> To: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] SIP & Presence - Joined@Hip?
>
>
> "Instant messaging is defined as the exchange of content
> between a set of
> participants in real time. Generally, the content is short
> textual messages,
> although that need not be the case."
>
> Aside from the admittedly not insignificant differences between the
> different types of "real time" data represented by IMs and audio, for
> instance, it's not clear to me what is so *fundamentally*
> different that IM
> should have special status in SIP.

Indeed, which would explain why the group is using SIP to establish IM
exchanges as a session described in the SDP. This has been discussed on the
simple list, and is reflected in two drafts which sit on the SIMPLE web
page. I recommend you peruse them:

http://www.ietf.org/internet-drafts/draft-ietf-simple-im-sdp-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-im-session-00.txt

>
> I realize there is some difficulty in defining exactly what a
> Session is
> with IM but it seems to me that any particular IM application
> might choose
> to define one in a number of different ways.  For instance, I
> might define a
> Session (from the SIP perspective) as two peers knowing each other are
> online and establishing UDP ports to use for exchanging
> messages.

Sounds like you are arguing that presence and session initiation are
related.

> Another thing that occured to me is that if you provide an
> arbitrarily large
> MESSAGE which can be sent over SIP proxys then it won't be
> long before the
> SIP servers are carrying a lot of traffic containing MP3 files.

Which is why the current drafts discuss establishing message transport e2e
(nats and firewalls permitting), over TCP for such things.

Do you mean over TCP or over SIP/TCP?
I definitely support the first case over TCP or UDP for that matter.
I do not see the value of extra overhead of using SIP as transport.
Do you?
 

-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

--------------09134EA5E8FDDAA102D40543-- From zane@mabry.com Fri Jul 27 20:27:00 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19448 for ; Fri, 27 Jul 2001 20:27:00 -0400 (EDT) Received: from toophat (pppoe1877.gh.centurytel.net [64.91.51.138]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f6S0QwI28550 for ; Fri, 27 Jul 2001 17:26:58 -0700 (PDT) Message-ID: <096d01c116fc$4d36c810$1d00a8c0@toophat> From: "Zane Thomas" To: References: Subject: Re: [Simple] SIP & Presence - Joined@Hip? Date: Fri, 27 Jul 2001 17:29:01 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 1675 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: Jonathan, > I recommend you peruse them: > > http://www.ietf.org/internet-drafts/draft-ietf-simple-im-sdp-00.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-im-session-00.txt Thanks. > > ... I might define a > > Session (from the SIP perspective) as two peers knowing each other are > > online and establishing UDP ports to use for exchanging > > messages. > > Sounds like you are arguing that presence and session initiation are > related. They're certainly related, but the question in my mind is to what extent and whether they should be tightly coupled in a protocol. I like SIP - maybe even a lot - for its ability to provide contact information and for its elegant architecture and relative simplicity. It seems to me that a similarly focused Presence Server would be really great to have, since it could be used in conjuction with SIP or on its own. Sorry if this is ancient history for you, but in the future as other newbies arrive on the scene some may have the same concerns. > Which is why the current drafts discuss establishing message transport e2e > (nats and firewalls permitting), over TCP for such things. Got it - but the MESSAGE method does provide for using SIP as a transport, and if it's there it will be used. I might like to provide a SIP server, and network with others, but I don't think I like the idea of it being used for arbitrarily large MESSAGEs, or any messages at all really. I think the issue of providing proxy support for handling NATs and firewalls when it comes to transporting content is another seperate issue, one which will have associated bandwidth costs and will need a sustainable revenue model. Zane From Internet-Drafts@ietf.org Sun Jul 29 01:41:38 2001 Received: from public.szptt.net.cn (mail2-smtp.szptt.net.cn [202.96.136.222]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id BAA23931 for ; Sun, 29 Jul 2001 01:41:32 -0400 (EDT) From: Internet-Drafts@ietf.org Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm23b63dc2a; Sun, 29 Jul 2001 05:38:22 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm3c3b605ecf; Thu, 26 Jul 2001 10:26:45 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03671 for ietf-123-outbound.01@ietf.org; Wed, 25 Jul 2001 15:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25768 for ; Wed, 25 Jul 2001 06:40:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08339; Wed, 25 Jul 2001 06:40:29 -0400 (EDT) Message-Id: <200107251040.GAA08339@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@mailman.dynamicsoft.com Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:28 -0400 Content-Length: 2357 Subject: [Simple] I-D ACTION:draft-ietf-simple-im-01.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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Instant Messaging Author(s) : J. Rosenberg et al. Filename : draft-ietf-simple-im-01.txt Pages : 23 Date : 24-Jul-01 This document defines a SIP extension (a single new method) that supports Instant Messaging (IM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-im-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-im-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-im-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-im-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-im-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132809.I-D@ietf.org> --OtherAccess-- --NextPart-- From jdrosen@dynamicsoft.com Sun Jul 29 23:14:08 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27284 for ; Sun, 29 Jul 2001 23:14:08 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6U3DWki016593; Sun, 29 Jul 2001 23:13:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Jul 2001 23:14:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'Paul Kyzivat'" , Internet-Drafts@ietf.org Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt Date: Sun, 29 Jul 2001 23:14:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 5019 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: Paul, Some excellent questions. I believe that, in general, until we are at the point where the answer is "you do X the same way for messaging as for voice", we still have more work to do. So, I had thought about the SDP usage some more since the draft was released, and think I may have an even better way. Really, the URL represents an address, and so it belongs in a c line. Its not of type IP4, but rather a new address space, of type URL. In that case, the SDP might look like: m=message 5060 sip message/cpim text/plain text/html c=IN URL sip:jdrosen@10.2.1.3 This indicates that the media type message can be received at the URL address sip:jdrosen@10.2.1.3, and that the transport is sip, with allowed formats message/cpim, text/plain and text/html. I think this is pretty consistent with the meaning of these paramteres in SDP, and it even allows us to apply SDP negotiation to the selection of message content types. So, based on that: 1. to disable a stream, the port is set to zero, as it is for all media types 2. to hold a stream, you can set the address in the c line to IN IP4 0.0.0.0, but the preferred means is a=sendonly, as it is for other media types. 3. oneway sessions use a=recvonly or a=sendonly as for other media types 4. it becomes clear on how other transports might work. For example, to use "foo" as an alternate transport: m=message 334 foo message/cpim text/plain text/html c=IN URL foo:jdrosen@10.2.1.3 very simple. I prefer this approach to what is currently documented in draft-ietf-simple-im-sdp. Comments? -Jonathan R. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, July 20, 2001 4:44 PM > To: Internet-Drafts@ietf.org > Cc: @cisco.com; ";"@cisco.com; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt > > > This is a great improvement to the SIMPLE stuff, because it begins > redraw the line between session initiation and media that was muddled > with the addition of MESSAGE to SIP. There clearly needs to > be a way to > negotiate text messaging as one medium of a SIP call, and > this provides > that. > > I have a few questions/comments: > > - how does one negotiate a oneway session? Presumably if alice wants > to receive but not sent, she can send the following in an invite: > > m=message 5060 sip sip:alice@alicepc > a=recvonly > > but what does bob send in return? perhaps something like: > > m=message ??? sip ??? > a=sendonly > > And whatever this is, does it also work in an invite if the person > inviting wants to be sendonly? > > (I believe comedia used port 9 to indicate a sink. I suppose that > could be adopted here - perhaps: > > m=message 9 sip > a=sendonly > > but I don't find the use of the magic number 9 very appealing.) > > Similarly, what do I do to refuse the media stream? > Do I still use port zero for this purpose, even though the port > in this m= line is gratuitous? > > - does there need to be any notion of HOLD in the sense that is > used for voice? To go on hold, should I send a reinvite with > c=0.0.0.0 even though the c= line is irrelevant here? Or should > I reinvite as sendonly? (The general case of this has been > discussed elsewhere. I favor a=sendonly as the media independent > way to go on hold, with the c=0 being an optional step for media > where it makes sense.) > > - section 4 forbids no-SDP invites, using the excuse that the > UAS will not know to offer the message medium. This shows a strong > voice bias. If you don't offer media in an invite, you ought to > expect the UAS to offer whatever it thinks appropriate, which > could be any medium if you haven't expressed any preference. > > If I don't want to specify any specific media values, but I do > want to indicate what I might be interested in using, then > callerprefs provides a way to do that: I can include a media= > parameter to the Contact header in my INVITE. > > - in draft-ietf-simple-im-sdp-00 there is mention of the possibility > of other transports than sip. That is fine as far as the SDP > syntax goes. But how would that work in practice with SIP? > Unlike codecs, I can't offer multiple transports with the same > m= line. So it is difficult to see how I might negotiate which > transport a pair of UAs might wish to use to exchange messages. > > Thanks, > Paul Kyzivat > Cisco Systems > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com From jdrosen@dynamicsoft.com Sun Jul 29 23:38:10 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27365 for ; Sun, 29 Jul 2001 23:38:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6U3bYki016650; Sun, 29 Jul 2001 23:37:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Jul 2001 23:38:09 -0400 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Jonathan Rosenberg Cc: "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Request URI in NOTIFY Date: Sun, 29 Jul 2001 23:38:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2452 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: > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Thursday, July 26, 2001 4:11 PM > To: Jonathan Rosenberg > Cc: 'Ngo, Dai (c)'; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Request URI in NOTIFY > > > > > How would B know whats in the registration database for A, > who is some > > client in some provider on the other side of the planet? We > use standard SIP > > record-routing techniques. If no proxies record-route, the > request URI in > > the NOTIFY is from the Contact in the SUBSCRIBE. If proxies > record-route, > > the request URI in the NOTIFY is the top record-route entry > (ie, that of the > > proxy closest to B). > > > > What if the contact header in the SUBSCRIBE that A sent > actually points > to a proxy/registrar, which A has registered to point to > somewhere else? > > For example, A sends a register to the proxy/registrar P with > a From: of > A@P and a Contact: ;methods=NOTIFY. A then sends a > SUBSCRIBE to > B with a Contact: sip:A@P. It would seem to me that the > NOTIFY would go > via A@P, and get proxied or redirected to A&A (if the absense of a > record-route, of course.) Things get confused, in general, when a UA puts an address in the Contact which doesn't actually point to itself. I can work in some cases, but it needs coordinated agreement amongst several entities. Specifically, the proxy that the SUBSCRIBE went through initially might very well be the same that the user registers with. In that case, it if record-routes the SUBSCRIBE, the NOTIFY will loop through this proxy, and thus be rejected. So, if the UA places an address that resolves to a proxy inside of Contact, that proxy cannot record-route. Also, any record-routes in the NOTIFY would need to be ignored by the UA (this is the case right now for presence, but not necessarily all event packages). Why bother, though? If the subscriber moves, re-subscribe with an updated local contact. Thats how it works with INVITE, and SUBSCRIBE is supposed to mirror INVITE behavior in this regard. -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 From bcampbell@dynamicsoft.com Mon Jul 30 00:46:28 2001 Received: from localhost.localdomain (dsl081-162-189.sea1.dsl.speakeasy.net [64.81.162.189]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27582 for ; Mon, 30 Jul 2001 00:46:23 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f6U3eQt01620; Sun, 29 Jul 2001 22:40:31 -0500 Message-ID: <3B64D72A.3010106@dynamicsoft.com> Date: Sun, 29 Jul 2001 22:40:26 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Paul Kyzivat'" , Internet-Drafts@ietf.org, simple@mailman.dynamicsoft.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 6088 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: I agree that a URL in the c-line would be a better approach, and we even added it in the open issue section in the im-sdp draft. I am uncertain, though, that this is permissible, as the SDP definition explicitly says IPv4 address (in the descriptive text section. The BNF actually says (IP4|IP6)) for that field. It seems pretty clear the authors intended that as a network address, not a URI. (in contrast to the m-line definition, which specifically describes how to extend it.) So, if we do that, is it still SDP? Can we make that change without updating the SDP RFC? I can see extended it to other network address types, but extending to URIs seems like a change in philosophy. Again, I think it would be a good extension if we can do it. Jonathan Rosenberg wrote: > Paul, > > Some excellent questions. I believe that, in general, until we are at the > point where the answer is "you do X the same way for messaging as for > voice", we still have more work to do. > > So, I had thought about the SDP usage some more since the draft was > released, and think I may have an even better way. Really, the URL > represents an address, and so it belongs in a c line. Its not of type IP4, > but rather a new address space, of type URL. In that case, the SDP might > look like: > > m=message 5060 sip message/cpim text/plain text/html > c=IN URL sip:jdrosen@10.2.1.3 > > > This indicates that the media type message can be received at the URL > address sip:jdrosen@10.2.1.3, and that the transport is sip, with allowed > formats message/cpim, text/plain and text/html. I think this is pretty > consistent with the meaning of these paramteres in SDP, and it even allows > us to apply SDP negotiation to the selection of message content types. > > So, based on that: > > 1. to disable a stream, the port is set to zero, as it is for all media > types > 2. to hold a stream, you can set the address in the c line to IN IP4 > 0.0.0.0, but the preferred means is a=sendonly, as it is for other media > types. > 3. oneway sessions use a=recvonly or a=sendonly as for other media types > 4. it becomes clear on how other transports might work. For example, to use > "foo" as an alternate transport: > > m=message 334 foo message/cpim text/plain text/html > c=IN URL foo:jdrosen@10.2.1.3 > > very simple. > > I prefer this approach to what is currently documented in > draft-ietf-simple-im-sdp. > > Comments? > > -Jonathan R. > > > > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Friday, July 20, 2001 4:44 PM >>To: Internet-Drafts@ietf.org >>Cc: @cisco.com; ";"@cisco.com; simple@mailman.dynamicsoft.com >>Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt >> >> >>This is a great improvement to the SIMPLE stuff, because it begins >>redraw the line between session initiation and media that was muddled >>with the addition of MESSAGE to SIP. There clearly needs to >>be a way to >>negotiate text messaging as one medium of a SIP call, and >>this provides >>that. >> >>I have a few questions/comments: >> >>- how does one negotiate a oneway session? Presumably if alice wants >> to receive but not sent, she can send the following in an invite: >> >> m=message 5060 sip sip:alice@alicepc >> a=recvonly >> >> but what does bob send in return? perhaps something like: >> >> m=message ??? sip ??? >> a=sendonly >> >> And whatever this is, does it also work in an invite if the person >> inviting wants to be sendonly? >> >> (I believe comedia used port 9 to indicate a sink. I suppose that >> could be adopted here - perhaps: >> >> m=message 9 sip >> a=sendonly >> >> but I don't find the use of the magic number 9 very appealing.) >> >> Similarly, what do I do to refuse the media stream? >> Do I still use port zero for this purpose, even though the port >> in this m= line is gratuitous? >> >>- does there need to be any notion of HOLD in the sense that is >> used for voice? To go on hold, should I send a reinvite with >> c=0.0.0.0 even though the c= line is irrelevant here? Or should >> I reinvite as sendonly? (The general case of this has been >> discussed elsewhere. I favor a=sendonly as the media independent >> way to go on hold, with the c=0 being an optional step for media >> where it makes sense.) >> >>- section 4 forbids no-SDP invites, using the excuse that the >> UAS will not know to offer the message medium. This shows a strong >> voice bias. If you don't offer media in an invite, you ought to >> expect the UAS to offer whatever it thinks appropriate, which >> could be any medium if you haven't expressed any preference. >> >> If I don't want to specify any specific media values, but I do >> want to indicate what I might be interested in using, then >> callerprefs provides a way to do that: I can include a media= >> parameter to the Contact header in my INVITE. >> >>- in draft-ietf-simple-im-sdp-00 there is mention of the possibility >> of other transports than sip. That is fine as far as the SDP >> syntax goes. But how would that work in practice with SIP? >> Unlike codecs, I can't offer multiple transports with the same >> m= line. So it is difficult to see how I might negotiate which >> transport a pair of UAs might wish to use to exchange messages. >> >> Thanks, >> Paul Kyzivat >> Cisco Systems >>_______________________________________________ >>simple mailing list >>simple@mailman.dynamicsoft.com >>http://mailman.dynamicsoft.com/mailman/listinfo/simple >> >> > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From Vasilis.Polychronidis@Openwave.com Mon Jul 30 05:56:08 2001 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 FAA00481 for ; Mon, 30 Jul 2001 05:56:08 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010730095521.LWJR11012.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Mon, 30 Jul 2001 04:55:21 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010730095509.JYLZ1691.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Mon, 30 Jul 2001 04:55:09 -0500 Message-ID: <3B652F25.9AFF3734@Openwave.com> Date: Mon, 30 Jul 2001 02:55:50 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Paul Kyzivat'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 5644 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: Jonathan Rosenberg wrote: > Paul, > > Some excellent questions. I believe that, in general, until we are at the > point where the answer is "you do X the same way for messaging as for > voice", we still have more work to do. > > So, I had thought about the SDP usage some more since the draft was > released, and think I may have an even better way. Really, the URL > represents an address, and so it belongs in a c line. Its not of type IP4, > but rather a new address space, of type URL. In that case, the SDP might > look like: > > m=message 5060 sip message/cpim text/plain text/html > c=IN URL sip:jdrosen@10.2.1.3 > > This indicates that the media type message can be received at the URL > address sip:jdrosen@10.2.1.3, and that the transport is sip, with allowed > formats message/cpim, text/plain and text/html. I think this is pretty > consistent with the meaning of these paramteres in SDP, and it even allows > us to apply SDP negotiation to the selection of message content types. > > So, based on that: > > 1. to disable a stream, the port is set to zero, as it is for all media > types > 2. to hold a stream, you can set the address in the c line to IN IP4 > 0.0.0.0, but the preferred means is a=sendonly, as it is for other media > types. > 3. oneway sessions use a=recvonly or a=sendonly as for other media types > 4. it becomes clear on how other transports might work. For example, to use > "foo" as an alternate transport: > > m=message 334 foo message/cpim text/plain text/html > c=IN URL foo:jdrosen@10.2.1.3 > > very simple. > > I prefer this approach to what is currently documented in > draft-ietf-simple-im-sdp. > > Comments? I like it too it is closer to the VoIP model. One small question: In your above example (SDP) how do you distinguish between sip/tcp or sip/udp? or more general foo/tcp, foo/udp, foo/sctp, etc. ? > > > -Jonathan R. > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, July 20, 2001 4:44 PM > > To: Internet-Drafts@ietf.org > > Cc: @cisco.com; ";"@cisco.com; simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt > > > > > > This is a great improvement to the SIMPLE stuff, because it begins > > redraw the line between session initiation and media that was muddled > > with the addition of MESSAGE to SIP. There clearly needs to > > be a way to > > negotiate text messaging as one medium of a SIP call, and > > this provides > > that. > > > > I have a few questions/comments: > > > > - how does one negotiate a oneway session? Presumably if alice wants > > to receive but not sent, she can send the following in an invite: > > > > m=message 5060 sip sip:alice@alicepc > > a=recvonly > > > > but what does bob send in return? perhaps something like: > > > > m=message ??? sip ??? > > a=sendonly > > > > And whatever this is, does it also work in an invite if the person > > inviting wants to be sendonly? > > > > (I believe comedia used port 9 to indicate a sink. I suppose that > > could be adopted here - perhaps: > > > > m=message 9 sip > > a=sendonly > > > > but I don't find the use of the magic number 9 very appealing.) > > > > Similarly, what do I do to refuse the media stream? > > Do I still use port zero for this purpose, even though the port > > in this m= line is gratuitous? > > > > - does there need to be any notion of HOLD in the sense that is > > used for voice? To go on hold, should I send a reinvite with > > c=0.0.0.0 even though the c= line is irrelevant here? Or should > > I reinvite as sendonly? (The general case of this has been > > discussed elsewhere. I favor a=sendonly as the media independent > > way to go on hold, with the c=0 being an optional step for media > > where it makes sense.) > > > > - section 4 forbids no-SDP invites, using the excuse that the > > UAS will not know to offer the message medium. This shows a strong > > voice bias. If you don't offer media in an invite, you ought to > > expect the UAS to offer whatever it thinks appropriate, which > > could be any medium if you haven't expressed any preference. > > > > If I don't want to specify any specific media values, but I do > > want to indicate what I might be interested in using, then > > callerprefs provides a way to do that: I can include a media= > > parameter to the Contact header in my INVITE. > > > > - in draft-ietf-simple-im-sdp-00 there is mention of the possibility > > of other transports than sip. That is fine as far as the SDP > > syntax goes. But how would that work in practice with SIP? > > Unlike codecs, I can't offer multiple transports with the same > > m= line. So it is difficult to see how I might negotiate which > > transport a pair of UAs might wish to use to exchange messages. > > > > Thanks, > > Paul Kyzivat > > Cisco Systems > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From jdrosen@dynamicsoft.com Mon Jul 30 08:51:15 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00990 for ; Mon, 30 Jul 2001 08:51:15 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6UCoeki017771; Mon, 30 Jul 2001 08:50:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 08:51:14 -0400 Message-ID: From: Jonathan Rosenberg To: Ben Campbell Cc: "'Paul Kyzivat'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt Date: Mon, 30 Jul 2001 08:51:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 1847 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: > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Sunday, July 29, 2001 11:40 PM > To: Jonathan Rosenberg > Cc: 'Paul Kyzivat'; Internet-Drafts@ietf.org; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt > > > I agree that a URL in the c-line would be a better approach, > and we even > added it in the open issue section in the im-sdp draft. I am > uncertain, > though, that this is permissible, as the SDP definition > explicitly says > IPv4 address (in the descriptive text section. The BNF actually says > (IP4|IP6)) for that field. It seems pretty clear the authors intended > that as a network address, not a URI. (in contrast to the m-line > definition, which specifically describes how to extend it.) There is already an RFC extension to SIP that defines a new address family. RFC 3108 (Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections) defines "ATM" as a new address type. So, we are following an existing practice. > > So, if we do that, is it still SDP? Can we make that change without > updating the SDP RFC? I can see extended it to other network address > types, but extending to URIs seems like a change in philosophy. Whether its a change in philosophy is indeed a good question (I don't think so, but its worth getting input from Mark and co.), but apparently its allowed to define new address types. -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 From jdrosen@dynamicsoft.com Mon Jul 30 09:28:18 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01106 for ; Mon, 30 Jul 2001 09:28:18 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f6UDRhki017980; Mon, 30 Jul 2001 09:27:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 09:28:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Vasilis Polychronidis'" Cc: "'Paul Kyzivat'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt Date: Mon, 30 Jul 2001 09:28:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2840 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: > -----Original Message----- > From: Vasilis Polychronidis > [mailto:Vasilis.Polychronidis@Openwave.com] > Sent: Monday, July 30, 2001 5:56 AM > To: Jonathan Rosenberg > Cc: 'Paul Kyzivat'; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt > > > Jonathan Rosenberg wrote: > > > Paul, > > > > Some excellent questions. I believe that, in general, until > we are at the > > point where the answer is "you do X the same way for > messaging as for > > voice", we still have more work to do. > > > > So, I had thought about the SDP usage some more since the draft was > > released, and think I may have an even better way. Really, the URL > > represents an address, and so it belongs in a c line. Its > not of type IP4, > > but rather a new address space, of type URL. In that case, > the SDP might > > look like: > > > > m=message 5060 sip message/cpim text/plain text/html > > c=IN URL sip:jdrosen@10.2.1.3 > > > > This indicates that the media type message can be received > at the URL > > address sip:jdrosen@10.2.1.3, and that the transport is > sip, with allowed > > formats message/cpim, text/plain and text/html. I think > this is pretty > > consistent with the meaning of these paramteres in SDP, and > it even allows > > us to apply SDP negotiation to the selection of message > content types. > > > > So, based on that: > > > > 1. to disable a stream, the port is set to zero, as it is > for all media > > types > > 2. to hold a stream, you can set the address in the c line to IN IP4 > > 0.0.0.0, but the preferred means is a=sendonly, as it is > for other media > > types. > > 3. oneway sessions use a=recvonly or a=sendonly as for > other media types > > 4. it becomes clear on how other transports might work. For > example, to use > > "foo" as an alternate transport: > > > > m=message 334 foo message/cpim text/plain text/html > > c=IN URL foo:jdrosen@10.2.1.3 > > > > very simple. > > > > I prefer this approach to what is currently documented in > > draft-ietf-simple-im-sdp. > > > > Comments? > > I like it too it is closer to the VoIP model. > One small question: > In your above example (SDP) how do you distinguish > between sip/tcp or sip/udp? > or more general foo/tcp, foo/udp, foo/sctp, etc. ? Same way done for other things: m=message 334 foo/TCP message/cpim text/plain text/html c=IN URL foo:jdrosen@10.2.1.3 This is consistent with draft-ietf-mmusic-comedia, 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 From hisham.khartabil@hotsip.com Mon Jul 30 10:05:29 2001 Received: from hs004.hotsip.com ([212.28.214.197]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01230 for ; Mon, 30 Jul 2001 10:05:25 -0400 (EDT) Received: from Hash ([195.238.204.173]) by hs004.hotsip.com (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id f6UE1n223498 for ; Mon, 30 Jul 2001 16:01:49 +0200 X-Authentication-Warning: hs004.hotsip.com: Host [195.238.204.173] claimed to be Hash From: "Hisham Khartabil" To: Date: Mon, 30 Jul 2001 17:02:30 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 742 Subject: [Simple] NOTIFY and application/cpim-pidf+xml 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: Hi, The example of NOTIFY in draft-ietf-simple-presence-01.txt does not use content-type: message/cpim nor application/cpim-pidf+xml. I can understand why. The question is: In application/cpim-pidf+xml has the elements and . Which one is represented by the description attribute in the contact header? and how do you represent the other? If the Presence Server is treating the GW as just another PUA (presence server only accepts SUBSCRIBE and REGISTER requests, it sends out NOTIFY), then the GW needs to map the cpim notify into a SIP REGISTER. does it not? The same questions about the elements in application/cpim-pidf+xml applies here. Should there be an example of this in the draft? Thanks Hisham www.hotsip.com From pkyzivat@cisco.com Mon Jul 30 15:00:40 2001 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 PAA02122 for ; Mon, 30 Jul 2001 15:00:35 -0400 (EDT) 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 f6UJ0O509464; Mon, 30 Jul 2001 15:00:25 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AFU02877 (AUTH pkyzivat); Mon, 30 Jul 2001 15:00:27 -0400 (EDT) Message-ID: <3B65AD96.F246E65D@cisco.com> Date: Mon, 30 Jul 2001 14:55:18 -0400 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: "Sean Olson (EUS)" CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1144 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: sendonly could be used by an automated device sending status messages. I might use recvonly when I will be away from my desk but willing to have messages pile up to read when I return. Of course this isn't much different than sendrecv with me never actually sending. But the knowledge that I am recvonly can be used by the other end to not expect a response. Conversely, I could negotiate sendonly as an equivalent to hold for voice calls. Paul > "Sean Olson (EUS)" wrote: > > >- how does one negotiate a oneway session? Presumably if alice wants > > to receive but not sent, she can send the following in an invite: > > > > m=message 5060 sip sip:alice@alicepc > > a=recvonly > > > > but what does bob send in return? perhaps something like: > > > > m=message ??? sip ??? > > a=sendonly > > > > And whatever this is, does it also work in an invite if the person > > inviting wants to be sendonly? > > I'm curious what a one-way SIP signalling session would > mean? You can receive an INVITE, but not send the 200 OK? > No flame intended, I just don't understand the application > you are thinking of. > > /sean From pkyzivat@cisco.com Mon Jul 30 15:14:16 2001 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 PAA02182 for ; Mon, 30 Jul 2001 15:14:15 -0400 (EDT) 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 f6UJE6510385; Mon, 30 Jul 2001 15:14:07 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AFU02970 (AUTH pkyzivat); Mon, 30 Jul 2001 15:14:08 -0400 (EDT) Message-ID: <3B65B0CC.71A8E7FC@cisco.com> Date: Mon, 30 Jul 2001 15:09:00 -0400 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: Ben Campbell CC: Internet-Drafts@ietf.org, simple@mailman.dynamicsoft.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt References: <200107191106.HAA28698@ietf.org> <3B58980A.DE01ED13@cisco.com> <3B608AC3.9010808@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2582 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: The revisions Johnathon has proposed affect this. I will comment on them separately. But some of the points here are still relevant to discuss. See below. Paul Ben Campbell wrote: > > > I have a few questions/comments: > > > > - how does one negotiate a oneway session? Presumably if alice wants > > to receive but not sent, she can send the following in an invite: > > > > m=message 5060 sip sip:alice@alicepc > > a=recvonly > > > > but what does bob send in return? perhaps something like: > > > > m=message ??? sip ??? > > a=sendonly > > > > Presumably it would be something like that. Since it is sendonly and we > are not worrying about things like RTCP, the port and URL fields are > meaningless. I think it is bad to make a specification and leave things like this undefined. It can lead to all sorts of interoperability problems. The acceptable values should be specified. Perhaps the port field can be any in the range 1:2^16-1, and perhaps the url should be omitted. > > Similarly, what do I do to refuse the media stream? > > Do I still use port zero for this purpose, even though the port > > in this m= line is gratuitous? > > That's a good question. We could do something simular by specifying a > zero port in the URL. However, I lean towards putting zero in the port > field, with the realization that the receiver must now pay attention to > that field, at least to check for zeros. Yep, just goes to show that something has to be said. > > - in draft-ietf-simple-im-sdp-00 there is mention of the possibility > > of other transports than sip. That is fine as far as the SDP > > syntax goes. But how would that work in practice with SIP? > > Unlike codecs, I can't offer multiple transports with the same > > m= line. So it is difficult to see how I might negotiate which > > transport a pair of UAs might wish to use to exchange messages. > > > > I suppose one could offer multiple media streams, and the receiver could > decline those it was not interested in. This could of course result in > multiple simultaneous message sessions. I'm not sure if that is a > problem or not. Clearly this is just a special case of a broader problem in SIP. There are lots of problems with offering multiple media sessions. You really want to indicate they are alternatives rather than independent sessions, and you would prefer not to have to allocate resources for more than one. Maybe there is no simple solution to this without SDP-ng. But I am afraid there is going to be need for it sooner for use with IM. Paul From pkyzivat@cisco.com Mon Jul 30 15:34:41 2001 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 PAA02262 for ; Mon, 30 Jul 2001 15:34:41 -0400 (EDT) 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 f6UJYW511673; Mon, 30 Jul 2001 15:34:32 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AFU03146 (AUTH pkyzivat); Mon, 30 Jul 2001 15:34:34 -0400 (EDT) Message-ID: <3B65B595.396DBBFD@cisco.com> Date: Mon, 30 Jul 2001 15:29:25 -0400 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] I-D ACTION:draft-ietf-simple-im-session-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 6555 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: I think the proposed revisions are a good improvement. Comments below. Paul Jonathan Rosenberg wrote: > > Paul, > > Some excellent questions. I believe that, in general, until we are at the > point where the answer is "you do X the same way for messaging as for > voice", we still have more work to do. Yes, I think so too. But some of that work probably has to be done on voice rather than on messaging. > > So, I had thought about the SDP usage some more since the draft was > released, and think I may have an even better way. Really, the URL > represents an address, and so it belongs in a c line. Its not of type IP4, > but rather a new address space, of type URL. This does seem like the right way to go, if it is deemed valid SDP. Are there SDP gods who must bless this usage? > In that case, the SDP might look like: > > m=message 5060 sip message/cpim text/plain text/html > c=IN URL sip:jdrosen@10.2.1.3 > > This indicates that the media type message can be received at the URL > address sip:jdrosen@10.2.1.3, and that the transport is sip, with allowed > formats message/cpim, text/plain and text/html. I think this is pretty > consistent with the meaning of these paramteres in SDP, and it even allows > us to apply SDP negotiation to the selection of message content types. In this example, you have put the sip port in the m= line, but not in the url in the c= line. Its not clear what you would do if the port was not the default. Would you put it both places? m=message 5061 sip message/cpim text/plain text/html c=IN URL sip:jdrosen@10.2.1.3:5061 or would you only put it in the m= line? I hate it when the same value *must* appear in two places. That always opens up the question of what happens when it doesn't. But I also hate the idea of removing data from the url that has to be put back to use it. To me the preferred solution would be to omit the port from the m= line. The m= syntax is too rtp or udp centric, and there ought to be provision for omitting a field when it isn't relevant. Perhaps simply permitting a "*" as a placeholder. > > So, based on that: > > 1. to disable a stream, the port is set to zero, as it is for all media > types ok > 2. to hold a stream, you can set the address in the c line to IN IP4 > 0.0.0.0, but the preferred means is a=sendonly, as it is for other media > types. ok. But in that case it should be specified how all the irrelevant fields should be filled in. In particular, with a=sendonly, what should be in the port field of the m=? > 3. oneway sessions use a=recvonly or a=sendonly as for other media types > 4. it becomes clear on how other transports might work. For example, to use > "foo" as an alternate transport: > > m=message 334 foo message/cpim text/plain text/html > c=IN URL foo:jdrosen@10.2.1.3 > > very simple. > > I prefer this approach to what is currently documented in > draft-ietf-simple-im-sdp. > > Comments? > > -Jonathan R. > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, July 20, 2001 4:44 PM > > To: Internet-Drafts@ietf.org > > Cc: @cisco.com; ";"@cisco.com; simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt > > > > > > This is a great improvement to the SIMPLE stuff, because it begins > > redraw the line between session initiation and media that was muddled > > with the addition of MESSAGE to SIP. There clearly needs to > > be a way to > > negotiate text messaging as one medium of a SIP call, and > > this provides > > that. > > > > I have a few questions/comments: > > > > - how does one negotiate a oneway session? Presumably if alice wants > > to receive but not sent, she can send the following in an invite: > > > > m=message 5060 sip sip:alice@alicepc > > a=recvonly > > > > but what does bob send in return? perhaps something like: > > > > m=message ??? sip ??? > > a=sendonly > > > > And whatever this is, does it also work in an invite if the person > > inviting wants to be sendonly? > > > > (I believe comedia used port 9 to indicate a sink. I suppose that > > could be adopted here - perhaps: > > > > m=message 9 sip > > a=sendonly > > > > but I don't find the use of the magic number 9 very appealing.) > > > > Similarly, what do I do to refuse the media stream? > > Do I still use port zero for this purpose, even though the port > > in this m= line is gratuitous? > > > > - does there need to be any notion of HOLD in the sense that is > > used for voice? To go on hold, should I send a reinvite with > > c=0.0.0.0 even though the c= line is irrelevant here? Or should > > I reinvite as sendonly? (The general case of this has been > > discussed elsewhere. I favor a=sendonly as the media independent > > way to go on hold, with the c=0 being an optional step for media > > where it makes sense.) > > > > - section 4 forbids no-SDP invites, using the excuse that the > > UAS will not know to offer the message medium. This shows a strong > > voice bias. If you don't offer media in an invite, you ought to > > expect the UAS to offer whatever it thinks appropriate, which > > could be any medium if you haven't expressed any preference. > > > > If I don't want to specify any specific media values, but I do > > want to indicate what I might be interested in using, then > > callerprefs provides a way to do that: I can include a media= > > parameter to the Contact header in my INVITE. > > > > - in draft-ietf-simple-im-sdp-00 there is mention of the possibility > > of other transports than sip. That is fine as far as the SDP > > syntax goes. But how would that work in practice with SIP? > > Unlike codecs, I can't offer multiple transports with the same > > m= line. So it is difficult to see how I might negotiate which > > transport a pair of UAs might wish to use to exchange messages. > > > > Thanks, > > Paul Kyzivat > > Cisco Systems > > _______________________________________________ > > simple mailing list > > simple@mailman.dynamicsoft.com > > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com From Diana.Rawlins@wcom.com Tue Jul 31 21:15:35 2001 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 VAA06848 for ; Tue, 31 Jul 2001 21:15:35 -0400 (EDT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GHD004IE7GE6S@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Wed, 1 Aug 2001 01:14:38 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GHD00L017GCDU@dgismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 01 Aug 2001 01:14:38 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GHD00L3H7GB0A@dgismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 01 Aug 2001 01:14:35 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Wed, 01 Aug 2001 01:14:35 +0000 Content-return: allowed Date: Wed, 01 Aug 2001 01:14:34 +0000 From: "Rawlins, Diana" To: "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E6476F5@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_eMD84WzeOWrX63AhuP1pgw)" Content-Length: 1773 Subject: [Simple] simple-im-01 Section 7 Proxy processing 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: 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_eMD84WzeOWrX63AhuP1pgw) Content-type: text/plain; charset=ISO-8859-1 Section 7.4 states that proxies must not insert record-route headers. Couldn't this record-route restriction could interfere with some firewall / NAT traversal schemes ? It seems too limiting. Also, why is there the limitation that if the proxy is not the home domain (registration), that a 404 is returned (rather than forwarding on the MESSAGE) ? -Diana --Boundary_(ID_eMD84WzeOWrX63AhuP1pgw) Content-type: text/html; charset=ISO-8859-1 simple-im-01 Section 7 Proxy processing

Section 7.4 states that proxies must not insert
record-route headers. Couldn't this record-route
restriction could interfere with some firewall
/ NAT traversal schemes ? It seems too limiting.

Also, why is there the limitation that if the
proxy is not the home domain (registration),
that a 404 is returned (rather than forwarding
on the MESSAGE) ?

-Diana

--Boundary_(ID_eMD84WzeOWrX63AhuP1pgw)-- From petkos@cs.columbia.edu Wed Aug 1 14:56:29 2001 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 OAA19665 for ; Wed, 1 Aug 2001 14:56:29 -0400 (EDT) Received: from dynamo.cs.columbia.edu (dynamo.cs.columbia.edu [128.59.16.4]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA24872 for ; Wed, 1 Aug 2001 14:56:28 -0400 (EDT) Received: (from petkos@localhost) by dynamo.cs.columbia.edu (8.9.3+Sun/8.9.3) id OAA03317 for simple@mailman.dynamicsoft.com; Wed, 1 Aug 2001 14:56:28 -0400 (EDT) From: "Petri K. Koskelainen" Message-Id: <200108011856.OAA03317@dynamo.cs.columbia.edu> To: simple@mailman.dynamicsoft.com Date: Wed, 1 Aug 2001 14:56:27 -0400 (EDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2405 Subject: [Simple] I-D ACTION:draft-ietf-simple-im-session-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: Hi, The use of this scheme for non-MESSAGE sessions is still somewhat unclear.. There seems to be several ways to define it, for example: 1: Method name in SIP URL in c line, like c=IN URL sip:jdrosen@10.2.1.3;method=DO. However, this seems to be partly conflicting with the idea that only the address is in c line. 2: New media type for new SIP methods, such as "appliance" or "control" for DO, like: m=appliance 5061 sip text/plain application/dmp However, this scheme requires new media type for each new method (I can establish a foobar media session using SIP FOOBAR method..) 3: Put SIP method name somewhere else in SDP. For example, m=message 5061 sip DO application/dmp 4: Method name is defined in SIP To header. Option 3 seems to be the most logical way.. -- Petri ------------------------------------- Paul, Some excellent questions. I believe that, in general, until we are at the point where the answer is "you do X the same way for messaging as for voice", we still have more work to do. So, I had thought about the SDP usage some more since the draft was released, and think I may have an even better way. Really, the URL represents an address, and so it belongs in a c line. Its not of type IP4, but rather a new address space, of type URL. In that case, the SDP might look like: m=message 5060 sip message/cpim text/plain text/html c=IN URL sip:jdrosen@10.2.1.3 This indicates that the media type message can be received at the URL address sip:jdrosen@10.2.1.3, and that the transport is sip, with allowed formats message/cpim, text/plain and text/html. I think this is pretty consistent with the meaning of these paramteres in SDP, and it even allows us to apply SDP negotiation to the selection of message content types. So, based on that: 1. to disable a stream, the port is set to zero, as it is for all media types 2. to hold a stream, you can set the address in the c line to IN IP4 0.0.0.0, but the preferred means is a=sendonly, as it is for other media types. 3. oneway sessions use a=recvonly or a=sendonly as for other media types 4. it becomes clear on how other transports might work. For example, to use "foo" as an alternate transport: m=message 334 foo message/cpim text/plain text/html c=IN URL foo:jdrosen@10.2.1.3 very simple. I prefer this approach to what is currently documented in draft-ietf-simple-im-sdp. Comments? -Jonathan R. From sean.olson@ericsson.com Wed Aug 1 16:22:43 2001 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 QAA19904 for ; Wed, 1 Aug 2001 16:22:41 -0400 (EDT) From: sean.olson@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 f71KMdp00276; Wed, 1 Aug 2001 15:22:39 -0500 (CDT) 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 f71KMd617826; Wed, 1 Aug 2001 15:22:39 -0500 (CDT) Received: from e0000865ab2db (pc050200.exu.ericsson.se [138.85.50.200]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id PAA16373; Wed, 1 Aug 2001 15:22:38 -0500 (CDT) Reply-To: To: "'Petri K. Koskelainen'" , Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt Date: Wed, 1 Aug 2001 15:22:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <200108011856.OAA03317@dynamo.cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 3217 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id QAA19904 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: I don't see this as a real problem. The IM session should really be a SIP signalling session. If you don't support a request that you receive within this signalling session, return a 501. Limiting this SIP signalling session to just a single method doesn't buy you anything. Regards, Sean Olson Ericsson Inc. >-----Original Message----- >From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu] >Sent: Wednesday, August 01, 2001 1:56 PM >To: simple@mailman.dynamicsoft.com >Subject: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt > > > >Hi, > > >The use of this scheme for non-MESSAGE sessions is still >somewhat unclear.. > >There seems to be several ways to define it, >for example: > >1: Method name in SIP URL in c line, like >c=IN URL sip:jdrosen@10.2.1.3;method=DO. >However, this seems to be partly conflicting with >the idea that only the address is in c line. > >2: New media type for new SIP methods, >such as "appliance" or "control" for DO, like: >m=appliance 5061 sip text/plain application/dmp >However, this scheme requires new media type >for each new method (I can establish a foobar media >session using SIP FOOBAR method..) > >3: Put SIP method name somewhere else in SDP. >For example, >m=message 5061 sip DO application/dmp > >4: Method name is defined in SIP To header. > > >Option 3 seems to be the most logical way.. > > >-- >Petri > > >------------------------------------- > > > >Paul, > >Some excellent questions. I believe that, in general, until we >are at the >point where the answer is "you do X the same way for messaging as for >voice", we still have more work to do. > >So, I had thought about the SDP usage some more since the draft was >released, and think I may have an even better way. Really, the URL >represents an address, and so it belongs in a c line. Its not >of type IP4, >but rather a new address space, of type URL. In that case, the >SDP might >look like: > >m=message 5060 sip message/cpim text/plain text/html >c=IN URL sip:jdrosen@10.2.1.3 > > >This indicates that the media type message can be received at the URL >address sip:jdrosen@10.2.1.3, and that the transport is sip, >with allowed >formats message/cpim, text/plain and text/html. I think this is pretty >consistent with the meaning of these paramteres in SDP, and it >even allows >us to apply SDP negotiation to the selection of message content types. > >So, based on that: > >1. to disable a stream, the port is set to zero, as it is for all media >types >2. to hold a stream, you can set the address in the c line to IN IP4 >0.0.0.0, but the preferred means is a=sendonly, as it is for >other media >types. >3. oneway sessions use a=recvonly or a=sendonly as for other >media types >4. it becomes clear on how other transports might work. For >example, to use >"foo" as an alternate transport: > >m=message 334 foo message/cpim text/plain text/html >c=IN URL foo:jdrosen@10.2.1.3 > >very simple. > >I prefer this approach to what is currently documented in >draft-ietf-simple-im-sdp. > >Comments? > >-Jonathan R. > > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple > From petkos@cs.columbia.edu Wed Aug 1 18:56:42 2001 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 SAA20335 for ; Wed, 1 Aug 2001 18:56:41 -0400 (EDT) Received: from dynamo.cs.columbia.edu (dynamo.cs.columbia.edu [128.59.16.4]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA09207; Wed, 1 Aug 2001 18:56:41 -0400 (EDT) Received: (from petkos@localhost) by dynamo.cs.columbia.edu (8.9.3+Sun/8.9.3) id SAA05532; Wed, 1 Aug 2001 18:56:40 -0400 (EDT) From: "Petri K. Koskelainen" Message-Id: <200108012256.SAA05532@dynamo.cs.columbia.edu> Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt To: sean.olson@ericsson.com Date: Wed, 1 Aug 2001 18:56:40 -0400 (EDT) Cc: petkos@cs.columbia.edu ('Petri K. Koskelainen'), simple@mailman.dynamicsoft.com In-Reply-To: from "sean.olson@ericsson.com" at Aug 01, 2001 03:22:36 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3997 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: I agree that it make no sense to limit the scheme to one method only. However, this is the case with the current draft. It is specifically meant for MESSAGE method (of course applying it to other methods is possible). MESSAGE method should be the default method unless otherwise specified. It sounds a bit clumsy to set up an appliance control (or whatever) session and get 501 inside a session. This should work just like voice session setup in which you agree on codecs and codec options beforehand in SIP signaling. Petri > > I don't see this as a real problem. > The IM session should really be a > SIP signalling session. If you > don't support a request that you > receive within this signalling > session, return a 501. Limiting > this SIP signalling session to > just a single method doesn't buy > you anything. > > Regards, > Sean Olson > Ericsson Inc. > > >-----Original Message----- > >From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu] > >Sent: Wednesday, August 01, 2001 1:56 PM > >To: simple@mailman.dynamicsoft.com > >Subject: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt > > > > > > > >Hi, > > > > > >The use of this scheme for non-MESSAGE sessions is still > >somewhat unclear.. > > > >There seems to be several ways to define it, > >for example: > > > >1: Method name in SIP URL in c line, like > >c=IN URL sip:jdrosen@10.2.1.3;method=DO. > >However, this seems to be partly conflicting with > >the idea that only the address is in c line. > > > >2: New media type for new SIP methods, > >such as "appliance" or "control" for DO, like: > >m=appliance 5061 sip text/plain application/dmp > >However, this scheme requires new media type > >for each new method (I can establish a foobar media > >session using SIP FOOBAR method..) > > > >3: Put SIP method name somewhere else in SDP. > >For example, > >m=message 5061 sip DO application/dmp > > > >4: Method name is defined in SIP To header. > > > > > >Option 3 seems to be the most logical way.. > > > > > >-- > >Petri > > > > > >------------------------------------- > > > > > > > >Paul, > > > >Some excellent questions. I believe that, in general, until we > >are at the > >point where the answer is "you do X the same way for messaging as for > >voice", we still have more work to do. > > > >So, I had thought about the SDP usage some more since the draft was > >released, and think I may have an even better way. Really, the URL > >represents an address, and so it belongs in a c line. Its not > >of type IP4, > >but rather a new address space, of type URL. In that case, the > >SDP might > >look like: > > > >m=message 5060 sip message/cpim text/plain text/html > >c=IN URL sip:jdrosen@10.2.1.3 > > > > > >This indicates that the media type message can be received at the URL > >address sip:jdrosen@10.2.1.3, and that the transport is sip, > >with allowed > >formats message/cpim, text/plain and text/html. I think this is pretty > >consistent with the meaning of these paramteres in SDP, and it > >even allows > >us to apply SDP negotiation to the selection of message content types. > > > >So, based on that: > > > >1. to disable a stream, the port is set to zero, as it is for all media > >types > >2. to hold a stream, you can set the address in the c line to IN IP4 > >0.0.0.0, but the preferred means is a=sendonly, as it is for > >other media > >types. > >3. oneway sessions use a=recvonly or a=sendonly as for other > >media types > >4. it becomes clear on how other transports might work. For > >example, to use > >"foo" as an alternate transport: > > > >m=message 334 foo message/cpim text/plain text/html > >c=IN URL foo:jdrosen@10.2.1.3 > > > >very simple. > > > >I prefer this approach to what is currently documented in > >draft-ietf-simple-im-sdp. > > > >Comments? > > > >-Jonathan R. > > > > > >_______________________________________________ > >simple mailing list > >simple@mailman.dynamicsoft.com > >http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > From adam.roach@ericsson.com Wed Aug 1 21:25:14 2001 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 VAA20751 for ; Wed, 1 Aug 2001 21:25:14 -0400 (EDT) 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 f721PDp08859; Wed, 1 Aug 2001 20:25:13 -0500 (CDT) 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 f721PC827945; Wed, 1 Aug 2001 20:25:12 -0500 (CDT) Received: from pc050163 (pc050206.exu.ericsson.se [138.85.50.206]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id UAA27419; Wed, 1 Aug 2001 20:25:12 -0500 (CDT) Reply-To: To: "'Zane Thomas'" , Subject: RE: [Simple] AOL chooses SIP! Date: Wed, 1 Aug 2001 20:25:10 -0500 Message-ID: <61D824C63B99D311975E00508B0CC98502251A29@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: <03b801c11596$a1658ff0$1d00a8c0@toophat> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Length: 520 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: > -----Original Message----- > From: Zane Thomas [mailto:zane@mabry.com] > > ... > > AOL's interoperability framework builds upon the IETF's (Internet > Engineering Task Force) SIP for Instant Messaging and > Presence Leverage > (SIMPLE) messaging protocol ... > > > Hmm, "builds upon", isn't there usually a red-flag attached > to those words? I spotted the exact same thing, even before reading your message. That's typical newspeak for "embrace and extend." I'm not sure this bodes well. /a From scotte@excitehome.net Thu Aug 2 14:37:05 2001 Received: from fep1.excitehome.net (fep1.excitehome.net [24.0.26.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23441 for ; Thu, 2 Aug 2001 14:37:04 -0400 (EDT) Received: from steep ([24.16.17.69]) by fep1.excitehome.net (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20010802183616.QUAM5275.fep1.excitehome.net@steep>; Thu, 2 Aug 2001 11:36:16 -0700 From: "Scott Eikenberry" To: , "'Zane Thomas'" , Subject: RE: [Simple] AOL chooses SIP! Date: Thu, 2 Aug 2001 11:35:03 -0700 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.00.3018.1300 In-Reply-To: <61D824C63B99D311975E00508B0CC98502251A29@eamrcnt717.exu.ericsson.se> Importance: Normal Content-Length: 1961 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: From the FCC filing (http://www.fcc.gov/csb/aolim1.pdf) on AOL's progress towards Instant Messaging Interoperability they give a very basic overview of what they plan to extend. Here is the quote relating directly to SIMPLE. "Because the SIMPLE working group has not finalized these protocols, however, AOL has had to resolve certain unsettled issues in the few functionals areas where the working froup has yet to make its final decisions. In particular, the comprehensive approach to interoperability AOL is working to complete will specify: * That IM systs may setablish dedicated, high-speed connections between their networks, thereby minimizing any bandwidth-related threats to the "instant" nature of IM; * A quality of service level which participating systems shall perform; and * A standardized approach to privacy and security, including measures to protect users from spam and harassment." --Scott > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of > adam.roach@ericsson.com > Sent: Wednesday, August 01, 2001 6:25 PM > To: 'Zane Thomas'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] AOL chooses SIP! > > > > -----Original Message----- > > From: Zane Thomas [mailto:zane@mabry.com] > > > > > ... > > > > AOL's interoperability framework builds upon the IETF's (Internet > > Engineering Task Force) SIP for Instant Messaging and > > Presence Leverage > > (SIMPLE) messaging protocol ... > > > > > > Hmm, "builds upon", isn't there usually a red-flag attached > > to those words? > > I spotted the exact same thing, even before reading your message. > That's typical newspeak for "embrace and extend." I'm not sure > this bodes well. > > /a > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From zane@mabry.com Thu Aug 2 15:04:58 2001 Received: from gig.centurytel.net (gig.centurytel.net [209.206.160.248]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23553 for ; Thu, 2 Aug 2001 15:04:56 -0400 (EDT) Received: from toophat (pppoe0308.gh.centurytel.net [209.206.249.91]) by gig.centurytel.net (8.11.4/8.11.4) with ESMTP id f72J4ei17810; Thu, 2 Aug 2001 12:04:41 -0700 (PDT) Message-ID: <013c01c11b86$5047b990$4500a8c0@toophat> From: "Zane Thomas" To: "Scott Eikenberry" , , References: Subject: Re: [Simple] AOL chooses SIP! Date: Thu, 2 Aug 2001 12:06:58 -0700 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.2462.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 185 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: Scott, > >From the FCC filing (http://www.fcc.gov/csb/aolim1.pdf) ... Thanks for the pointer, read it, too bad it was short on details. Do you know if details are available? Zane From scotte@excitehome.net Thu Aug 2 17:01:54 2001 Received: from fep1.excitehome.net (fep1.excitehome.net [24.0.26.112]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23922 for ; Thu, 2 Aug 2001 17:01:53 -0400 (EDT) Received: from steep ([24.16.17.69]) by fep1.excitehome.net (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20010802210111.RKLF5275.fep1.excitehome.net@steep>; Thu, 2 Aug 2001 14:01:11 -0700 From: "Scott Eikenberry" To: "Zane Thomas" , Subject: RE: [Simple] AOL chooses SIP! Date: Thu, 2 Aug 2001 13:59:58 -0700 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.00.3018.1300 In-Reply-To: <013c01c11b86$5047b990$4500a8c0@toophat> Importance: Normal Content-Length: 400 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: Sorry, I don't have the details. I have been hoping someone from AOL would post them here. Sure would be nice to see a detailed specification of their extensions. --Scott > -----Original Message----- > Scott, > > > >From the FCC filing (http://www.fcc.gov/csb/aolim1.pdf) ... > > Thanks for the pointer, read it, too bad it was short on details. Do you > know if details are available? > > Zane From postadm@postoffice.sarnoff.com Thu Aug 2 22:20:10 2001 Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24791 for ; Thu, 2 Aug 2001 22:20:09 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYSE00.5CJ for ; Thu, 2 Aug 2001 21:57:50 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXO00.EAY; Fri, 27 Jul 2001 19:51:24 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA13431; Wed, 25 Jul 2001 15:48:38 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03675 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25768 for ; Wed, 25 Jul 2001 06:40:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08339; Wed, 25 Jul 2001 06:40:29 -0400 (EDT) Message-Id: <200107251040.GAA08339@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 Date: Wed, 25 Jul 2001 06:40:28 -0400 Content-Length: 2357 Subject: [Simple] I-D ACTION:draft-ietf-simple-im-01.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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Instant Messaging Author(s) : J. Rosenberg et al. Filename : draft-ietf-simple-im-01.txt Pages : 23 Date : 24-Jul-01 This document defines a SIP extension (a single new method) that supports Instant Messaging (IM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-im-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-im-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-im-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-im-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-im-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132809.I-D@ietf.org> --OtherAccess-- --NextPart-- From postadm@postoffice.sarnoff.com Thu Aug 2 22:20:10 2001 Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24795 for ; Thu, 2 Aug 2001 22:20:10 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYYP00.PCL for ; Thu, 2 Aug 2001 22:01:37 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PS300.OCQ; Fri, 27 Jul 2001 20:09:39 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA12797; Wed, 25 Jul 2001 15:31:30 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03516 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:05:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25766 for ; Wed, 25 Jul 2001 06:40:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08361; Wed, 25 Jul 2001 06:40:36 -0400 (EDT) Message-Id: <200107251040.GAA08361@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 Date: Wed, 25 Jul 2001 06:40:36 -0400 Content-Length: 2852 Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-01.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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-01.txt Pages : 40 Date : 24-Jul-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132819.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132819.I-D@ietf.org> --OtherAccess-- --NextPart-- From postadm@postoffice.sarnoff.com Fri Aug 3 04:56:34 2001 Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25836 for ; Fri, 3 Aug 2001 04:56:34 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF7O00.HQH for ; Fri, 3 Aug 2001 03:52:36 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXO00.EAY; Fri, 27 Jul 2001 19:51:24 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA13431; Wed, 25 Jul 2001 15:48:38 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03675 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25768 for ; Wed, 25 Jul 2001 06:40:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08339; Wed, 25 Jul 2001 06:40:29 -0400 (EDT) Message-Id: <200107251040.GAA08339@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 Date: Wed, 25 Jul 2001 06:40:28 -0400 Content-Length: 2357 Subject: [Simple] I-D ACTION:draft-ietf-simple-im-01.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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Instant Messaging Author(s) : J. Rosenberg et al. Filename : draft-ietf-simple-im-01.txt Pages : 23 Date : 24-Jul-01 This document defines a SIP extension (a single new method) that supports Instant Messaging (IM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-im-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-im-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-im-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-im-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-im-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132809.I-D@ietf.org> --OtherAccess-- --NextPart-- From postadm@postoffice.sarnoff.com Fri Aug 3 04:56:35 2001 Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25840 for ; Fri, 3 Aug 2001 04:56:34 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFCE00.OR9 for ; Fri, 3 Aug 2001 03:55:26 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PS300.OCQ; Fri, 27 Jul 2001 20:09:39 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA12797; Wed, 25 Jul 2001 15:31:30 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03516 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:05:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25766 for ; Wed, 25 Jul 2001 06:40:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08361; Wed, 25 Jul 2001 06:40:36 -0400 (EDT) Message-Id: <200107251040.GAA08361@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 Date: Wed, 25 Jul 2001 06:40:36 -0400 Content-Length: 2852 Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-01.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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-01.txt Pages : 40 Date : 24-Jul-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132819.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132819.I-D@ietf.org> --OtherAccess-- --NextPart-- From aoki@netscape.com Fri Aug 3 12:50:34 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27107 for ; Fri, 3 Aug 2001 12:50:33 -0400 (EDT) Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.10.0/8.10.0) with ESMTP id f73GoCZ01490 for ; Fri, 3 Aug 2001 09:50:12 -0700 (PDT) Received: from netscape.com ([206.222.238.133]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GHI43O00.F92; Fri, 3 Aug 2001 09:50:12 -0700 Message-ID: <3B6AD6DA.AF9D434E@netscape.com> Date: Fri, 03 Aug 2001 09:52:43 -0700 From: aoki@netscape.com (Edwin Aoki) Reply-To: aoki@aol.net Organization: Netscape X-Mailer: Mozilla 4.77C- (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com References: <200108031601.MAA26973@mailman.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Length: 2056 Subject: [Simple] Re:AOL chooses SIP! 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: Scott, I think you're reading too much into this. When you read the word "extensions", you shouldn't think of extensions in the standard SIP sense of the word. The specific areas where we differ from SIMPLE (in particular im-00 and presence-00, since later versions have only recently been published) and from the various proposals being developed for CPIM in IMPP have to do with protocols and formats that are still in flux and yet to be finalized. Among these are: - XML presence document format (ongoing discussion in the IMPP WG) - Pre-authorization of presence watching (some discussion here) - Operational issues having to do with identifying and blockin SPAM and otherwise objectionable content (part of the broader SIP security issue) - DNS/SRV/NAPTR lookup for services (ongoing discussion in the IMPP WG) We will continue to monitor and participate in all of these discussions and - once they become a little firmer - we'll look at what it is we might need to change. We also will be watching our tests pretty vigiliently to make sure that we can keep the system running efficiently; as you are no doubt aware, SIP + CPIM can be quite expensive (bandwidth-wise) for simple presence state-transitions, and this is something that continues to be of some concern to us. Other areas mentioned in the FCC update (such as dedicated circuits and QoS agreements) are related more to the business end rather than being part of any specific technology. For QoS, for example, you could measure QoS through a protocol, but enforcement of QoS would likely come through policy rather than protocol. Thanks for your interest, -Edwin Aoki -aoki@aol.net > > From: "Scott Eikenberry" > To: "Zane Thomas" , > Subject: RE: [Simple] AOL chooses SIP! > Date: Thu, 2 Aug 2001 13:59:58 -0700 > > Sorry, I don't have the details. I have been hoping someone from AOL would > post them here. Sure would be nice to see a detailed specification of their > extensions. > > --Scott > > From 200.dist@wanadoo.es Fri Aug 3 23:23:18 2001 Received: from distancia.20 ([213.98.118.212]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id XAA28788 for ; Fri, 3 Aug 2001 23:23:05 -0400 (EDT) Message-Id: <200108040323.XAA28788@mailman.dynamicsoft.com> Reply-To: "cursos"<200.dist@wanadoo.es> From: "cursos"<200.dist@wanadoo.es> To: "" Organization: Enseñanza X-Priority: 3 X-MSMail-Priority: Normal Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 1 Aug 2001 16:40:38 +0200 Content-Length: 2313 Subject: [Simple] De su alto interes 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: 1.8.2001.Publicidad/Enseñanza a Distancia Hola que tal: El motivo de la presente carta es informarte de la posibilidad de poder realizar algún curso a distancia de tu interés, cursos relacionados con tu trabajo inquietudes y ocio.ect.El conocimiento es el mayor patrimonio de que podemos disponer. Nos dedicamos desde 1996.a impartir cursos a distancia disponemos de una amplia variedad de cursos sencillos para poder seguirlos comodamente desde cualquier parte del mundo y a unos precios muy competitivos. NET ------------ Redes y Sistemas Sistemas Servers Diseño Web BUSSINES ------------ Gestion Comercial y Marketing Relaciones Publicas Recursos Humanos Comercio Exterior Direccion Comercial Gestión Medio Ambiental SALUD SUPERACION PERSONAL ------------------------------------- Psicoterapia Psicologia Practica Nutrí terapia y Salud Monitor Yoga Tai-Chi Hipnoterapia Quiromasaje y Reflexoterapia Aromaterapia Cosmética Natural Hierbas Medicinales -------------------------------------- CURSOS BECADOS: Los cursos son de 200.horas lectivas el precio standar por curso es de 35.000.pts(Despues de beca)España a plazos.Iberoamerica 150.usa dolar aplazados.(Despues de beca) El Diploma: "Técnico Especialista" El tiempo aproximado por curso dependiendo de los conocimientos en areas similares de que se disponga,es entre 2-6.meses.aprox. Si desean que les ampliemos información pueden enviar un e-mail les contestaremos con la mayor brevedad y les indicaremos nuestro espacio web que se encuentra en reformas.No lo pienses mas y envia un e-mail y recibiras todo tipo de informes y detalles muy en breve. Envie e-mail: COTFORTR@terra.es Sin otra que rogarte me envies un e-mail si estas interesado/a Te enviamos un saludo. Si desea no recibir mas e-mail. remove/mail CUERRT@terra.es distancia.20@wanadoo.es Jose Garceran Broker-COFOR Gestion Integral 1.SL C/Constitucion.34 03310-Alicante España ------------------ From bcampbell@dynamicsoft.com Sun Aug 5 12:52:31 2001 Received: from localhost.localdomain (host217-33-136-176.ietf.ignite.net [217.33.136.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04514 for ; Sun, 5 Aug 2001 12:52:31 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f75Grlt01097; Sun, 5 Aug 2001 11:53:48 -0500 Message-ID: <3B6D7A1B.9080302@dynamicsoft.com> Date: Sun, 05 Aug 2001 11:53:47 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: "Rawlins, Diana" CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] simple-im-01 Section 7 Proxy processing References: <492EB4A3F68CD411ABE800508B69362E6476F5@RIPEXCH002.wcomnet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1693 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: Rawlins, Diana wrote: > > Section 7.4 states that proxies must not insert > record-route headers. Couldn't this record-route > restriction could interfere with some firewall > / NAT traversal schemes ? It seems too limiting. The point behind this is that a MESSAGE request, in itself, implies no concept of a session or call leg. There is nothing to record-route. This is like REGISTER, where each request stands alone. If a proxy _did_ insert a record-route header, the UAC would have nothing to do, as there are no further requests associated with the original MESSAGE for it to insert a Route header into. > > Also, why is there the limitation that if the > proxy is not the home domain (registration), > that a 404 is returned (rather than forwarding > on the MESSAGE) ? > In this case, we are talking about proxies that use REGISTER messages to set up routing. The text could be a little clearer, in that we are talking about proxies that _only_ route via REGISTERS. For example, if the proxy example.com receives a MESSAGE request for sip:bob@example.com, but the proxy (or the registrar it uses) has no registration for sip:bob@example.com, it returns a 404. I more clear way of stating this would be if a proxy receives a MESSAGE request where the domain part of the request-URI refers to itself, and the user part of the request-URI refers to a user that the proxy has no knowledge of, then it should return a 404. This should not be confused with the situation where a proxy receives a request and the _domain_ part of the request-uri does not refer to itself. In that case, it should forward the request to the domain in the request-URI. > -Diana > From jdrosen@dynamicsoft.com Sun Aug 5 18:06:31 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05350 for ; Sun, 5 Aug 2001 18:06:31 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f75M5qw3013817; Sun, 5 Aug 2001 18:05:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sun, 5 Aug 2001 18:06:28 -0400 Message-ID: From: Jonathan Rosenberg To: "'Petri K. Koskelainen'" , Sean Olson Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt Date: Sun, 5 Aug 2001 18:06:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 5292 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: > -----Original Message----- > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu] > Sent: Wednesday, August 01, 2001 6:57 PM > To: sean.olson@ericsson.com > Cc: petkos@cs.columbia.edu; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt > > > > I agree that it make no sense to limit the scheme > to one method only. > However, this is the case with the current draft. > It is specifically meant for MESSAGE method > (of course applying it to other methods is possible). > > MESSAGE method should be the default method unless > otherwise specified. > It sounds a bit clumsy to set up an appliance control > (or whatever) session and get 501 inside a session. > This should work just like voice session setup > in which you agree on codecs and codec options beforehand > in SIP signaling. I think MESSAGE is implied by the fact that the media type is message. I agree with Sean that setting up method-specific sessions makes little 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 > > > > Petri > > > > > > > I don't see this as a real problem. > > The IM session should really be a > > SIP signalling session. If you > > don't support a request that you > > receive within this signalling > > session, return a 501. Limiting > > this SIP signalling session to > > just a single method doesn't buy > > you anything. > > > > Regards, > > Sean Olson > > Ericsson Inc. > > > > >-----Original Message----- > > >From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu] > > >Sent: Wednesday, August 01, 2001 1:56 PM > > >To: simple@mailman.dynamicsoft.com > > >Subject: [Simple] I-D ACTION:draft-ietf-simple-im-session-00.txt > > > > > > > > > > > >Hi, > > > > > > > > >The use of this scheme for non-MESSAGE sessions is still > > >somewhat unclear.. > > > > > >There seems to be several ways to define it, > > >for example: > > > > > >1: Method name in SIP URL in c line, like > > >c=IN URL sip:jdrosen@10.2.1.3;method=DO. > > >However, this seems to be partly conflicting with > > >the idea that only the address is in c line. > > > > > >2: New media type for new SIP methods, > > >such as "appliance" or "control" for DO, like: > > >m=appliance 5061 sip text/plain application/dmp > > >However, this scheme requires new media type > > >for each new method (I can establish a foobar media > > >session using SIP FOOBAR method..) > > > > > >3: Put SIP method name somewhere else in SDP. > > >For example, > > >m=message 5061 sip DO application/dmp > > > > > >4: Method name is defined in SIP To header. > > > > > > > > >Option 3 seems to be the most logical way.. > > > > > > > > >-- > > >Petri > > > > > > > > >------------------------------------- > > > > > > > > > > > >Paul, > > > > > >Some excellent questions. I believe that, in general, until we > > >are at the > > >point where the answer is "you do X the same way for > messaging as for > > >voice", we still have more work to do. > > > > > >So, I had thought about the SDP usage some more since the draft was > > >released, and think I may have an even better way. Really, the URL > > >represents an address, and so it belongs in a c line. Its not > > >of type IP4, > > >but rather a new address space, of type URL. In that case, the > > >SDP might > > >look like: > > > > > >m=message 5060 sip message/cpim text/plain text/html > > >c=IN URL sip:jdrosen@10.2.1.3 > > > > > > > > >This indicates that the media type message can be received > at the URL > > >address sip:jdrosen@10.2.1.3, and that the transport is sip, > > >with allowed > > >formats message/cpim, text/plain and text/html. I think > this is pretty > > >consistent with the meaning of these paramteres in SDP, and it > > >even allows > > >us to apply SDP negotiation to the selection of message > content types. > > > > > >So, based on that: > > > > > >1. to disable a stream, the port is set to zero, as it is > for all media > > >types > > >2. to hold a stream, you can set the address in the c line > to IN IP4 > > >0.0.0.0, but the preferred means is a=sendonly, as it is for > > >other media > > >types. > > >3. oneway sessions use a=recvonly or a=sendonly as for other > > >media types > > >4. it becomes clear on how other transports might work. For > > >example, to use > > >"foo" as an alternate transport: > > > > > >m=message 334 foo message/cpim text/plain text/html > > >c=IN URL foo:jdrosen@10.2.1.3 > > > > > >very simple. > > > > > >I prefer this approach to what is currently documented in > > >draft-ietf-simple-im-sdp. > > > > > >Comments? > > > > > >-Jonathan R. > > > > > > > > >_______________________________________________ > > >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 rampe@cs.tut.fi Mon Aug 6 03:35:57 2001 Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06792 for ; Mon, 6 Aug 2001 03:35:55 -0400 (EDT) Received: from rami (root@varis.cs.tut.fi [130.230.4.42]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id KAA05060 for ; Mon, 6 Aug 2001 10:35:40 +0300 (EET DST) From: "Rami Lehtonen" To: Date: Mon, 6 Aug 2001 10:36:32 +0300 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Length: 649 Subject: [Simple] New drafts on Instant Messaging - Question 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: According to new drafts on Instant Messaging (e.g. SIP Extensions for Instant Messaging) it is forbidden to include a body in the 200 OK messages, which are sent after MESSAGE. Does this also apply to Instant Message Sessions? If yes, what's the reason for that? We have designed a negotiation mechanism based on Instant Messaging (MESSAGE), and we use currently a body in the 200 OK messages. The negotiation mechanism works for both models on Instant Messaging (with or without session). So it would be nice to see the body in response to MESSAGE at least in session based model if that does not create any unwanted behaviour. -- Rami Lehtonen From rsparks@dynamicsoft.com Mon Aug 6 03:53:18 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06862 for ; Mon, 6 Aug 2001 03:53:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f767qew3014644; Mon, 6 Aug 2001 03:52:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 03:53:17 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A9CB@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Rami Lehtonen'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] New drafts on Instant Messaging - Question Date: Mon, 6 Aug 2001 03:53:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1235 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: If the body is meant to be interpreted as a reciprocal message, there is no way to get it across a CPIM interface (since there is no way to respond to it). RjS > -----Original Message----- > From: Rami Lehtonen [mailto:rampe@cs.tut.fi] > Sent: Monday, August 06, 2001 2:37 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] New drafts on Instant Messaging - Question > > > According to new drafts on Instant Messaging (e.g. SIP Extensions for > Instant Messaging) it is forbidden to include a body in the > 200 OK messages, > which are sent after MESSAGE. Does this also apply to Instant Message > Sessions? If yes, what's the reason for that? > > We have designed a negotiation mechanism based on Instant Messaging > (MESSAGE), and we use currently a body in the 200 OK messages. The > negotiation mechanism works for both models on Instant > Messaging (with or > without session). So it would be nice to see the body in > response to MESSAGE > at least in session based model if that does not create any unwanted > behaviour. > > -- Rami Lehtonen > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From bcampbell@dynamicsoft.com Mon Aug 6 05:39:41 2001 Received: from localhost.localdomain (host217-33-136-176.ietf.ignite.net [217.33.136.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00516 for ; Mon, 6 Aug 2001 05:39:39 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f769et301454; Mon, 6 Aug 2001 04:40:55 -0500 Message-ID: <3B6E6627.30007@dynamicsoft.com> Date: Mon, 06 Aug 2001 04:40:55 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Sparks CC: "'Rami Lehtonen'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] New drafts on Instant Messaging - Question References: <9BF66EBF6BEFD942915B4D4D45C051F314A9CB@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1754 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: Right. I am curious as to what sort of negotiation the original note refers to. I can accept the idea of negotiating things using MESSAGE, but I would expect that to be an exchange of MESSAGE transactions, not a MESSAGE/200 OK negotiation. Any body in a 200 OK will be lost if this crosses a CPIM gateway. Robert Sparks wrote: > If the body is meant to be interpreted as a reciprocal message, > there is no way to get it across a CPIM interface (since there > is no way to respond to it). > > RjS > > >>-----Original Message----- >>From: Rami Lehtonen [mailto:rampe@cs.tut.fi] >>Sent: Monday, August 06, 2001 2:37 AM >>To: simple@mailman.dynamicsoft.com >>Subject: [Simple] New drafts on Instant Messaging - Question >> >> >>According to new drafts on Instant Messaging (e.g. SIP Extensions for >>Instant Messaging) it is forbidden to include a body in the >>200 OK messages, >>which are sent after MESSAGE. Does this also apply to Instant Message >>Sessions? If yes, what's the reason for that? >> >>We have designed a negotiation mechanism based on Instant Messaging >>(MESSAGE), and we use currently a body in the 200 OK messages. The >>negotiation mechanism works for both models on Instant >>Messaging (with or >>without session). So it would be nice to see the body in >>response to MESSAGE >>at least in session based model if that does not create any unwanted >>behaviour. >> >>-- Rami Lehtonen >> >>_______________________________________________ >>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 jdrosen@dynamicsoft.com Mon Aug 6 11:17:55 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01488 for ; Mon, 6 Aug 2001 11:17:55 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f76FHJw3015705; Mon, 6 Aug 2001 11:17:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 11:17:55 -0400 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Robert Sparks Cc: "'Rami Lehtonen'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] New drafts on Instant Messaging - Question Date: Mon, 6 Aug 2001 11:17:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2999 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: Well, also note that a response to the MESSAGE is sent so long as it is received. You cannot wait for the human to type a response before sending a SIP response message (i.e., 200 OK), as you will get unending retransmissions followed by a transaction timeout. I too am curious about this "negotiation" mechanism. Details? -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: Monday, August 06, 2001 10:41 AM > To: Robert Sparks > Cc: 'Rami Lehtonen'; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] New drafts on Instant Messaging - Question > > > Right. I am curious as to what sort of negotiation the original note > refers to. I can accept the idea of negotiating things using MESSAGE, > but I would expect that to be an exchange of MESSAGE > transactions, not a > MESSAGE/200 OK negotiation. Any body in a 200 OK will be lost if this > crosses a CPIM gateway. > > Robert Sparks wrote: > > > If the body is meant to be interpreted as a reciprocal message, > > there is no way to get it across a CPIM interface (since there > > is no way to respond to it). > > > > RjS > > > > > >>-----Original Message----- > >>From: Rami Lehtonen [mailto:rampe@cs.tut.fi] > >>Sent: Monday, August 06, 2001 2:37 AM > >>To: simple@mailman.dynamicsoft.com > >>Subject: [Simple] New drafts on Instant Messaging - Question > >> > >> > >>According to new drafts on Instant Messaging (e.g. SIP > Extensions for > >>Instant Messaging) it is forbidden to include a body in the > >>200 OK messages, > >>which are sent after MESSAGE. Does this also apply to > Instant Message > >>Sessions? If yes, what's the reason for that? > >> > >>We have designed a negotiation mechanism based on Instant Messaging > >>(MESSAGE), and we use currently a body in the 200 OK messages. The > >>negotiation mechanism works for both models on Instant > >>Messaging (with or > >>without session). So it would be nice to see the body in > >>response to MESSAGE > >>at least in session based model if that does not create any unwanted > >>behaviour. > >> > >>-- Rami Lehtonen > >> > >>_______________________________________________ > >>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 interscan@mailrelay2.lge.com Wed Aug 8 02:11:01 2001 Received: from mailrelay2.lge.com ([156.147.1.148]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07625 for ; Wed, 8 Aug 2001 02:10:59 -0400 (EDT) From: interscan@mailrelay2.lge.com Received: from localhost (root@localhost) by mailrelay2.lge.com (8.11.3/8.11.3) with SMTP id f786A9g24320 for ; Wed, 8 Aug 2001 15:10:09 +0900 (KST) Date: Wed, 8 Aug 2001 15:10:09 +0900 (KST) Message-Id: <200108080610.f786A9g24320@mailrelay2.lge.com> To: simple@mailman.dynamicsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 106 Subject: [Simple] Virus Alert 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: Have detected a virus (TROJ_SIRCAM.A) in your mail traffic on 08/08/2001 15:09:19 with an action deleted. From greatpolaris@xinhuanet.com Wed Aug 8 03:28:50 2001 Received: from xinhuanet.com ([202.84.17.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id DAA07874 for ; Wed, 8 Aug 2001 03:25:46 -0400 (EDT) Received: from ([202.106.106.100]) by xinhuanet.com(JetMail 2.5.3.0) with SMTP id jm23b7129fe; Wed, 8 Aug 2001 07:17:00 -0000 Date: Wed, 08 Aug 2001 15:26:17 +0800 From: Simon To: simple@mailman.dynamicsoft.com Message-Id: <20010808151800.8F1A.GREATPOLARIS@xinhuanet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.03 Content-Length: 253 Subject: [Simple] Why do we need Presence Caching? 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: Hi, In the section 3.3 of RFC 2779, there are some requirements about presence caching and replication. But I cannot understand when we need to cache the PRESENCE INFORMATION. Would you like to give me some explantions? Thanks. Regards, Simon Young From Arnaud.Weil@winwise.com Wed Aug 8 08:19:58 2001 Received: from pikachu.winwise.home ([194.98.12.74]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id IAA08660 for ; Wed, 8 Aug 2001 08:19:56 -0400 (EDT) Received: from 172.17.1.250 by pikachu.winwise.home (InterScan E-Mail VirusWall NT); Wed, 08 Aug 2001 14:19:41 +0200 (Romance Daylight Time) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Why do we need Presence Caching? X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Wed, 8 Aug 2001 14:19:54 +0200 Message-ID: <98D95D87610EA04296C7C3006888EA08391085@milou.winwise.home> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Why do we need Presence Caching? Thread-Index: AcEf3BtfvXEOB6OVSha+iArpGRyW0QAJ32+A From: "Arnaud Weil" To: "Simon" , Content-Length: 1114 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA08660 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: Hi Simon, It seems to me that caching presence information would allow for a more sensible use of the available resources. The idea is that if B knows about A's presence, it can give it to C without the need for C to ask it to A. This relieves the pressure on A. And this will be quite interesting in the case of servers handling thousands of subscriptions. Of course, as part of CPIM, a timing mechanism has been set up so that B doesn't give to C any inacurate presence info about A. Regards, Arnaud Weil -----Original Message----- From: Simon [mailto:greatpolaris@xinhuanet.com] Sent: mercredi 8 août 2001 09:26 To: simple@mailman.dynamicsoft.com Subject: [Simple] Why do we need Presence Caching? Hi, In the section 3.3 of RFC 2779, there are some requirements about presence caching and replication. But I cannot understand when we need to cache the PRESENCE INFORMATION. Would you like to give me some explantions? Thanks. Regards, Simon Young _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From oran@cisco.com Wed Aug 8 09:20:54 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08842 for ; Wed, 8 Aug 2001 09:20:54 -0400 (EDT) Received: from oranlt (rtp-vpn1-30.cisco.com [10.82.80.30]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f78DL2Y06787 for ; Wed, 8 Aug 2001 06:21:02 -0700 (PDT) From: "David R. Oran" To: Subject: RE: [Simple] Why do we need Presence Caching? Date: Wed, 8 Aug 2001 09:23:50 -0400 Organization: Cisco Systems Message-ID: <000c01c1200d$5e4c0ab0$d58821d9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <98D95D87610EA04296C7C3006888EA08391085@milou.winwise.home> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 1853 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA08842 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: How do you secure this without transitive trust among A, B and C? Or are you happy with requiring C to trust B to properly represent A's state and not be a "man in the middle" > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Arnaud Weil > Sent: Wednesday, August 08, 2001 8:20 AM > To: Simon; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Why do we need Presence Caching? > > > Hi Simon, > > It seems to me that caching presence information would allow > for a more sensible use of the available resources. The idea > is that if B knows about A's presence, it can give it to C > without the need for C to ask it to A. This relieves the > pressure on A. And this will be quite interesting in the case > of servers handling thousands of subscriptions. > > Of course, as part of CPIM, a timing mechanism has been set > up so that B doesn't give to C any inacurate presence info about A. > > Regards, > Arnaud Weil > > -----Original Message----- > From: Simon [mailto:greatpolaris@xinhuanet.com] > Sent: mercredi 8 août 2001 09:26 > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Why do we need Presence Caching? > > > Hi, > > In the section 3.3 of RFC 2779, there are some requirements > about presence caching and replication. But I cannot > understand when we need to cache the PRESENCE INFORMATION. > Would you like to give me some explantions? > > Thanks. > > Regards, > Simon Young > > _______________________________________________ > 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/listinf> o/simple > From Arnaud.Weil@winwise.com Wed Aug 8 09:45:30 2001 Received: from pikachu.winwise.home ([194.98.12.74]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA08933 for ; Wed, 8 Aug 2001 09:45:29 -0400 (EDT) Received: from 172.17.1.250 by pikachu.winwise.home (InterScan E-Mail VirusWall NT); Wed, 08 Aug 2001 15:45:23 +0200 (Romance Daylight Time) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Why do we need Presence Caching? X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Wed, 8 Aug 2001 15:45:36 +0200 Message-ID: <98D95D87610EA04296C7C3006888EA0839109F@milou.winwise.home> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Why do we need Presence Caching? Thread-Index: AcEgDbear5ex0BKaRcSgQu5fhmpN9wAACDPA From: "Arnaud Weil" To: "David R. Oran" , Content-Length: 3125 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA08933 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: How this should be secured is another part of the CPIM requirements, as stated in the following parts of RFC 2779: 2.5.1. The protocol MUST provide means to ensure confidence that a received message (NOTIFICATION or INSTANT MESSAGE) has not been corrupted or tampered with. 3.3.3 The protocol caching facilities MUST NOT circumvent established ACCESS RULES or restrict choice of authentication/encryption mechanisms. 5.3.1. The protocol MUST provide A means of verifying that the presence information is accurate, as sent by B. 5.3.3. The protocol MUST provide A means of verifying that the notification was sent by B. However, I'like to point out that these are the requirements that SIMPLE is supposed to meet as a protocol that conforms with CPIM. I'm too new to SIMPLE to tell you how they are effectively met by SIMPLE, and hope someone more experienced could answer this. Arnaud -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: mercredi 8 août 2001 15:24 To: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Why do we need Presence Caching? How do you secure this without transitive trust among A, B and C? Or are you happy with requiring C to trust B to properly represent A's state and not be a "man in the middle" > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Arnaud Weil > Sent: Wednesday, August 08, 2001 8:20 AM > To: Simon; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Why do we need Presence Caching? > > > Hi Simon, > > It seems to me that caching presence information would allow > for a more sensible use of the available resources. The idea > is that if B knows about A's presence, it can give it to C > without the need for C to ask it to A. This relieves the > pressure on A. And this will be quite interesting in the case > of servers handling thousands of subscriptions. > > Of course, as part of CPIM, a timing mechanism has been set > up so that B doesn't give to C any inacurate presence info about A. > > Regards, > Arnaud Weil > > -----Original Message----- > From: Simon [mailto:greatpolaris@xinhuanet.com] > Sent: mercredi 8 août 2001 09:26 > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Why do we need Presence Caching? > > > Hi, > > In the section 3.3 of RFC 2779, there are some requirements > about presence caching and replication. But I cannot > understand when we need to cache the PRESENCE INFORMATION. > Would you like to give me some explantions? > > Thanks. > > Regards, > Simon Young > > _______________________________________________ > 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/listinf> o/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From oran@cisco.com Wed Aug 8 09:49:41 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08962 for ; Wed, 8 Aug 2001 09:49:36 -0400 (EDT) Received: from oranlt (rtp-vpn1-30.cisco.com [10.82.80.30]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f78DnjY20150; Wed, 8 Aug 2001 06:49:45 -0700 (PDT) From: "David R. Oran" To: "'Arnaud Weil'" , Subject: RE: [Simple] Why do we need Presence Caching? Date: Wed, 8 Aug 2001 09:52:33 -0400 Organization: Cisco Systems Message-ID: <001a01c12011$61b37bd0$d58821d9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <98D95D87610EA04296C7C3006888EA0839109F@milou.winwise.home> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 3676 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA08962 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: Unfortunately, none of this tells you HOW to secure it; it tells you what security you're supposed to have. > -----Original Message----- > From: Arnaud Weil [mailto:Arnaud.Weil@winwise.com] > Sent: Wednesday, August 08, 2001 9:46 AM > To: David R. Oran; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Why do we need Presence Caching? > > > How this should be secured is another part of the CPIM > requirements, as stated in the following parts of RFC 2779: > > 2.5.1. The protocol MUST provide means to ensure confidence that a > received message (NOTIFICATION or INSTANT MESSAGE) has not been > corrupted or tampered with. > > 3.3.3 The protocol caching facilities MUST NOT circumvent > established > ACCESS RULES or restrict choice of authentication/encryption > mechanisms. > > 5.3.1. The protocol MUST provide A means of verifying that the > presence information is accurate, as sent by B. > > 5.3.3. The protocol MUST provide A means of verifying that the > notification was sent by B. > > However, I'like to point out that these are the requirements > that SIMPLE is supposed to meet as a protocol that conforms > with CPIM. I'm too new to SIMPLE to tell you how they are > effectively met by SIMPLE, and hope someone more experienced > could answer this. > > Arnaud > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: mercredi 8 août 2001 15:24 > To: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Why do we need Presence Caching? > > > How do you secure this without transitive trust among A, B > and C? Or are you happy with requiring C to trust B to > properly represent A's state and not be a "man in the middle" > > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Arnaud Weil > > Sent: Wednesday, August 08, 2001 8:20 AM > > To: Simon; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Why do we need Presence Caching? > > > > > > Hi Simon, > > > > It seems to me that caching presence information would allow > > for a more sensible use of the available resources. The idea > > is that if B knows about A's presence, it can give it to C > > without the need for C to ask it to A. This relieves the > > pressure on A. And this will be quite interesting in the case > > of servers handling thousands of subscriptions. > > > > Of course, as part of CPIM, a timing mechanism has been set > > up so that B doesn't give to C any inacurate presence info about A. > > > > Regards, > > Arnaud Weil > > > > -----Original Message----- > > From: Simon [mailto:greatpolaris@xinhuanet.com] > > Sent: mercredi 8 août 2001 09:26 > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] Why do we need Presence Caching? > > > > > > Hi, > > > > In the section 3.3 of RFC 2779, there are some requirements > > about presence caching and replication. But I cannot > > understand when we need to cache the PRESENCE INFORMATION. > > Would you like to give me some explantions? > > > > Thanks. > > > > Regards, > > Simon Young > > > > _______________________________________________ > > 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/listinf> o/simple > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From Arnaud.Weil@winwise.com Wed Aug 8 09:53:12 2001 Received: from pikachu.winwise.home ([194.98.12.74]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA08994 for ; Wed, 8 Aug 2001 09:53:11 -0400 (EDT) Received: from 172.17.1.250 by pikachu.winwise.home (InterScan E-Mail VirusWall NT); Wed, 08 Aug 2001 15:53:05 +0200 (Romance Daylight Time) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Why do we need Presence Caching? X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Wed, 8 Aug 2001 15:53:17 +0200 Message-ID: <98D95D87610EA04296C7C3006888EA083910A1@milou.winwise.home> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Why do we need Presence Caching? Thread-Index: AcEgEQBbn63azvinSbiv1Aahn1sE3QAACP/Q From: "Arnaud Weil" To: "David R. Oran" , Content-Length: 4076 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA08994 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: Errr... yes, that's what I just wrote at the end of my previous reply. Just like you I'd like to know how this is effectively implemented by SIMPLE. It might even already be secured by SIP. -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: mercredi 8 août 2001 15:53 To: Arnaud Weil; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Why do we need Presence Caching? Unfortunately, none of this tells you HOW to secure it; it tells you what security you're supposed to have. > -----Original Message----- > From: Arnaud Weil [mailto:Arnaud.Weil@winwise.com] > Sent: Wednesday, August 08, 2001 9:46 AM > To: David R. Oran; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Why do we need Presence Caching? > > > How this should be secured is another part of the CPIM > requirements, as stated in the following parts of RFC 2779: > > 2.5.1. The protocol MUST provide means to ensure confidence that a > received message (NOTIFICATION or INSTANT MESSAGE) has not been > corrupted or tampered with. > > 3.3.3 The protocol caching facilities MUST NOT circumvent > established > ACCESS RULES or restrict choice of authentication/encryption > mechanisms. > > 5.3.1. The protocol MUST provide A means of verifying that the > presence information is accurate, as sent by B. > > 5.3.3. The protocol MUST provide A means of verifying that the > notification was sent by B. > > However, I'like to point out that these are the requirements > that SIMPLE is supposed to meet as a protocol that conforms > with CPIM. I'm too new to SIMPLE to tell you how they are > effectively met by SIMPLE, and hope someone more experienced > could answer this. > > Arnaud > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: mercredi 8 août 2001 15:24 > To: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Why do we need Presence Caching? > > > How do you secure this without transitive trust among A, B > and C? Or are you happy with requiring C to trust B to > properly represent A's state and not be a "man in the middle" > > > > -----Original Message----- > > From: simple-admin@mailman.dynamicsoft.com > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Arnaud Weil > > Sent: Wednesday, August 08, 2001 8:20 AM > > To: Simon; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Why do we need Presence Caching? > > > > > > Hi Simon, > > > > It seems to me that caching presence information would allow > > for a more sensible use of the available resources. The idea > > is that if B knows about A's presence, it can give it to C > > without the need for C to ask it to A. This relieves the > > pressure on A. And this will be quite interesting in the case > > of servers handling thousands of subscriptions. > > > > Of course, as part of CPIM, a timing mechanism has been set > > up so that B doesn't give to C any inacurate presence info about A. > > > > Regards, > > Arnaud Weil > > > > -----Original Message----- > > From: Simon [mailto:greatpolaris@xinhuanet.com] > > Sent: mercredi 8 août 2001 09:26 > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] Why do we need Presence Caching? > > > > > > Hi, > > > > In the section 3.3 of RFC 2779, there are some requirements > > about presence caching and replication. But I cannot > > understand when we need to cache the PRESENCE INFORMATION. > > Would you like to give me some explantions? > > > > Thanks. > > > > Regards, > > Simon Young > > > > _______________________________________________ > > 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/listinf> o/simple > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From tony@att.com Wed Aug 8 10:08:54 2001 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 KAA09077 for ; Wed, 8 Aug 2001 10:08:53 -0400 (EDT) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f78E8UO21894 for ; Wed, 8 Aug 2001 10:08:30 -0400 (EDT) Received: from att.com ([135.76.80.16]) by maillennium.att.com (labmail) with SMTP id <20010808140823099004n5vpe> (Authid: tony@maillennium.att.com); Wed, 8 Aug 2001 14:08:24 +0000 Message-ID: <3B7147A1.ABF1A4F8@att.com> Date: Wed, 08 Aug 2001 10:07:29 -0400 From: Tony Hansen X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Why do we need Presence Caching? References: <98D95D87610EA04296C7C3006888EA083910A1@milou.winwise.home> Content-Type: text/plain; charset=iso-8859-1 Content-Length: 5062 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA09077 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: You have to establish a trust relationship with some systems. THESE systems you believe to be giving you good data. And you can use their system certificate via TLS to verify their identity, or use some other mechanism of server identity verification. For example, do you feel you can trust xyz.com to act as a proxy server for watchers on XYZ's system? If yes, and you can verify that it really is xyz.com that's sending you a subscription request, then you can consider that to be a trusted subscription. If the answer to either question is no, then it's untrusted information. Tony Hansen tony@att.com Arnaud Weil wrote: > > Errr... yes, that's what I just wrote at the end of my previous reply. > Just like you I'd like to know how this is effectively implemented by > SIMPLE. It might even already be secured by SIP. > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: mercredi 8 août 2001 15:53 > To: Arnaud Weil; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Why do we need Presence Caching? > > Unfortunately, none of this tells you HOW to secure it; it tells you > what security you're supposed to have. > > > -----Original Message----- > > From: Arnaud Weil [mailto:Arnaud.Weil@winwise.com] > > Sent: Wednesday, August 08, 2001 9:46 AM > > To: David R. Oran; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Why do we need Presence Caching? > > > > > > How this should be secured is another part of the CPIM > > requirements, as stated in the following parts of RFC 2779: > > > > 2.5.1. The protocol MUST provide means to ensure confidence that a > > received message (NOTIFICATION or INSTANT MESSAGE) has not been > > corrupted or tampered with. > > > > 3.3.3 The protocol caching facilities MUST NOT circumvent > > established > > ACCESS RULES or restrict choice of authentication/encryption > > mechanisms. > > > > 5.3.1. The protocol MUST provide A means of verifying that the > > presence information is accurate, as sent by B. > > > > 5.3.3. The protocol MUST provide A means of verifying that the > > notification was sent by B. > > > > However, I'like to point out that these are the requirements > > that SIMPLE is supposed to meet as a protocol that conforms > > with CPIM. I'm too new to SIMPLE to tell you how they are > > effectively met by SIMPLE, and hope someone more experienced > > could answer this. > > > > Arnaud > > > > -----Original Message----- > > From: David R. Oran [mailto:oran@cisco.com] > > Sent: mercredi 8 août 2001 15:24 > > To: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Why do we need Presence Caching? > > > > > > How do you secure this without transitive trust among A, B > > and C? Or are you happy with requiring C to trust B to > > properly represent A's state and not be a "man in the middle" > > > > > > > -----Original Message----- > > > From: simple-admin@mailman.dynamicsoft.com > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > Arnaud Weil > > > Sent: Wednesday, August 08, 2001 8:20 AM > > > To: Simon; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Why do we need Presence Caching? > > > > > > > > > Hi Simon, > > > > > > It seems to me that caching presence information would allow > > > for a more sensible use of the available resources. The idea > > > is that if B knows about A's presence, it can give it to C > > > without the need for C to ask it to A. This relieves the > > > pressure on A. And this will be quite interesting in the case > > > of servers handling thousands of subscriptions. > > > > > > Of course, as part of CPIM, a timing mechanism has been set > > > up so that B doesn't give to C any inacurate presence info about A. > > > > > > Regards, > > > Arnaud Weil > > > > > > -----Original Message----- > > > From: Simon [mailto:greatpolaris@xinhuanet.com] > > > Sent: mercredi 8 août 2001 09:26 > > > To: simple@mailman.dynamicsoft.com > > > Subject: [Simple] Why do we need Presence Caching? > > > > > > > > > Hi, > > > > > > In the section 3.3 of RFC 2779, there are some requirements > > > about presence caching and replication. But I cannot > > > understand when we need to cache the PRESENCE INFORMATION. > > > Would you like to give me some explantions? > > > > > > Thanks. > > > > > > Regards, > > > Simon Young > > > > > > _______________________________________________ > > > 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/listinf> o/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 ksethare@genuity.com Wed Aug 8 13:08:59 2001 Received: from cam-po2.genuity.com (cam-po2.genuity.com [171.78.68.9]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09588 for ; Wed, 8 Aug 2001 13:08:56 -0400 (EDT) Received: from ksethare_2 (dhcp113-156.genuity.com [171.78.113.156]) by cam-po2.genuity.com (8.11.3/8.11.2) with SMTP id f78H8h903491 for ; Wed, 8 Aug 2001 13:08:43 -0400 (EDT) Message-Id: <200108081708.f78H8h903491@cam-po2.genuity.com> X-Recipient: X-Sender: ksethare@po3.Genuity.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 08 Aug 2001 13:01:24 -0400 To: simple@mailman.dynamicsoft.com From: Elliot Eichen (by way of Kerry Sethares ) Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Length: 2911 Subject: [Simple] Symposium on IP Telephony: ICC 2002 / IPTel 2002 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: Dear Colleague:

As part of the IEEE Conference on Communications (ICC 2002), and
in combination with IPTel 2002, a symposium on IP Telephony and
Voice Over IP will be held in New York City, 28 April - 2 May,
2002.=A0 This symposium is part of Symposium G: Multimedia Services and
VoIP - Services and Technologies.=A0 Participation in this symposium is
open to all registrants of ICC 2002 (i.e., separate registration is=20
not required).=A0 Please note that the paper submission deadline for the
symposium has been extended to 3 September 2001.

Papers submitted for consideration should focus on topics
related to IP Telephony services, and the technologies needed to
implement those services.=A0 Examples of topics of interest
include:

Architecture and Protocols:
- Advanced Feature/Call Routing
- Protocol Interoperability
- Network Scalability and Reliability

Network Interworking
- 3G Wireless
- PSTN

Applications and Services
- IP-PBX / IP-Centrex
- Messaging and Presence
- Call Centers
- Conferencing
- IP-Telephone over Broadband Access
- Desktop Integration and IP Telephony
- Internet Gaming

Security
- Privacy and Encryption
- Authorization and Authentication
- Firewalls
- Regulatory Requirements

Operations Support Systems
- Network Configuration and Management
- Service Creation and Provisioning
- Accounting

Pilots and Deployments
- Advanced Applications
- Performance/Scalability/Robustness
- User Experience

Quality of Service
- WAN/LAN/Application Layer QoS
- Voice/Video Coding and Transmission

The paper submission schedule and process is the same as for the
general ICC 2002 conference.=A0 When submitting your paper through the
Automated Paper Submission System (all papers must be submitted
electronically), please note that themes for IP Telephony and VoIP are
G10 through G16 on the drop down menu.

Important Sites:
----------------

Call for Papers, Symposium on Multimedia and VoIP:
http://www.icc2002.com/MultimediaSymp.html

Instructions for Authors:
http://www.icc2002.com/InfoForAuthors.html

ICC 2002:
http://www.icc2002.com/

IPTel 2002
http://www.iptel.org/2002/


Best Regards:

Elliot Eichen
Co-Chair, Symposium on Multimedia and VoIP - Services and
Technologies



 From hisham.khartabil@hotsip.com Wed Aug 8 14:00:26 2001 Received: from open1.hotsip.com ([212.28.212.211]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09748 for ; Wed, 8 Aug 2001 14:00:24 -0400 (EDT) Received: from Hash (root@[212.28.214.198]) by open1.hotsip.com (8.11.0/8.11.0) with SMTP id f78JQpu26153 for ; Wed, 8 Aug 2001 21:26:51 +0200 (CEST) From: "Hisham Khartabil" To: Subject: RE: [Simple] NOTIFY and application/cpim-pidf+xml Date: Wed, 8 Aug 2001 20:57:28 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Length: 1259 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: I thought I send this again > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Hisham > Khartabil > Sent: Monday, 30 July 2001 5:03 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] NOTIFY and application/cpim-pidf+xml > > > Hi, > > The example of NOTIFY in draft-ietf-simple-presence-01.txt does not use > content-type: message/cpim nor application/cpim-pidf+xml. I can understand > why. The question is: > > In application/cpim-pidf+xml has the elements and . Which > one is represented by the description attribute in the contact header? and > how do you represent the other? > > If the Presence Server is treating the GW as just another PUA (presence > server only accepts SUBSCRIBE and REGISTER requests, it sends out NOTIFY), > then the GW needs to map the cpim notify into a SIP REGISTER. does it not? > The same questions about the elements in application/cpim-pidf+xml applies > here. Should there be an example of this in the draft? > > Thanks > Hisham > www.hotsip.com > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From hisham.khartabil@hotsip.com Wed Aug 8 14:02:40 2001 Received: from open1.hotsip.com ([212.28.212.211]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09773 for ; Wed, 8 Aug 2001 14:02:38 -0400 (EDT) Received: from Hash (root@[212.28.214.198]) by open1.hotsip.com (8.11.0/8.11.0) with SMTP id f78JTGu15024 for ; Wed, 8 Aug 2001 21:29:16 +0200 (CEST) From: "Hisham Khartabil" To: Date: Wed, 8 Aug 2001 20:59:53 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Length: 130 Subject: [Simple] Expires in REGISTER 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: Hi, What is the significance of the Expires header in a REGISTER request sent by the PUA to a PS? Thanks Hisham www.hotsip.com From Tina.Iliff@WCOM.Com Wed Aug 8 15:28:25 2001 Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10037 for ; Wed, 8 Aug 2001 15:28:24 -0400 (EDT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0GHR00MKCKRB22@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Wed, 8 Aug 2001 19:28:23 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GHR00A01KOYT4@pmismtp04.wcomnet.com>; Wed, 08 Aug 2001 19:28:20 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GHR006PAKONOR@pmismtp04.wcomnet.com>; Wed, 08 Aug 2001 19:26:48 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Wed, 08 Aug 2001 19:26:47 +0000 Content-return: allowed Date: Wed, 08 Aug 2001 19:26:45 +0000 From: "Iliff, Tina" Subject: RE: [Simple] Expires in REGISTER To: "'Hisham Khartabil'" , simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E3F5B15@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain; charset=ISO-8859-1 Content-Length: 1028 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: Hisham, It provides an indication as to when the location specified by the Contact header value will no longer be a valid location to contact the presentity. It also provides the time window in which the PUA must re-register if it wants the location to remain valid. In the case of Presence, if the watcher was notified of this location and the Registration expires for the presentity due to the presentity failing to re-register prior to the expiration, then it will be notified that the contact location is no longer valid. Tina Iliff -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] Sent: Wednesday, August 08, 2001 1:00 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] Expires in REGISTER Hi, What is the significance of the Expires header in a REGISTER request sent by the PUA to a PS? Thanks Hisham www.hotsip.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From jdrosen@dynamicsoft.com Wed Aug 8 16:46:33 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10258 for ; Wed, 8 Aug 2001 16:46:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f78Kjqw3024686; Wed, 8 Aug 2001 16:45:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 16:46:30 -0400 Message-ID: From: Jonathan Rosenberg To: "'Hisham Khartabil'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] NOTIFY and application/cpim-pidf+xml Date: Wed, 8 Aug 2001 16:46:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2491 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: > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > Sent: Monday, July 30, 2001 3:03 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] NOTIFY and application/cpim-pidf+xml > > > Hi, > > The example of NOTIFY in draft-ietf-simple-presence-01.txt > does not use > content-type: message/cpim nor application/cpim-pidf+xml. I > can understand > why. At the time of writing, these were not available. > The question is: > > In application/cpim-pidf+xml has the elements and > . Which > one is represented by the description attribute in the > contact header? and > how do you represent the other? I actually think that the description attribute of the contact header would map to the note tag, not detail. The value would be set by whether the contact is active or not. I had a conversation with a few folks about this today. Normally, if you have a registered contact, its going to be "open". When it expires, instead of being closed, it simply disappears. So, the "closed" attribute is never used. Another possibility is that if the contact is registered with a q value of zero, that means "closed". No, there is a higher level issue here, which is what we do and don't want to say about constructing pidf documents from registers. To a large extent, its a local implementation choice, since it doesn't impact interoperability. For example, choosing never to use closed, or using it when a q value of zero is used, are both reasonable choices. Any sane mapping will do fine. So, on one extreme, we can leave the entire mapping up to the implementation. At the other extreme, we specify the entire thing. I'm not sure where in there is the right answer, but I suspect its closer to specifying nothing, as opposed to the entire mapping. Comments? > > If the Presence Server is treating the GW as just another PUA > (presence > server only accepts SUBSCRIBE and REGISTER requests, it sends > out NOTIFY), > then the GW needs to map the cpim notify into a SIP REGISTER. > does it not? No; cpim is server to server, not server to client. -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 From bcampbell@dynamicsoft.com Thu Aug 9 05:25:42 2001 Received: from localhost.localdomain (host217-33-136-176.ietf.ignite.net [217.33.136.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12295 for ; Thu, 9 Aug 2001 05:25:41 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f794P7901400; Wed, 8 Aug 2001 23:25:07 -0500 Message-ID: <3B7210A2.2070904@dynamicsoft.com> Date: Wed, 08 Aug 2001 23:25:06 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Hisham Khartabil'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] NOTIFY and application/cpim-pidf+xml References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1026 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: Jonathan Rosenberg wrote: [snip] > No, there is a higher level issue here, which is what we do and don't want > to say about constructing pidf documents from registers. To a large extent, > its a local implementation choice, since it doesn't impact interoperability. > For example, choosing never to use closed, or using it when a q value of > zero is used, are both reasonable choices. Any sane mapping will do fine. > So, on one extreme, we can leave the entire mapping up to the > implementation. > > At the other extreme, we specify the entire thing. > > I'm not sure where in there is the right answer, but I suspect its closer to > specifying nothing, as opposed to the entire mapping. > I lean toward saying it is a matter of local implementation. There may be many ways to synthesis presence data from various sources, and I can easily imagine a service that maps registers to presence in a less direct way. At most, it might be worth an informational draft when we don't have more important work to do :-p From hisham.khartabil@hotsip.com Thu Aug 9 05:35:38 2001 Received: from open1.hotsip.com ([212.28.212.211]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12349 for ; Thu, 9 Aug 2001 05:35:37 -0400 (EDT) Received: from Hash (root@[212.28.214.198]) by open1.hotsip.com (8.11.0/8.11.0) with SMTP id f79B1uu31849; Thu, 9 Aug 2001 13:01:56 +0200 (CEST) From: "Hisham Khartabil" To: "Jonathan Rosenberg" , Subject: RE: [Simple] NOTIFY and application/cpim-pidf+xml Date: Thu, 9 Aug 2001 12:32:30 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Length: 3474 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: > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan > Rosenberg > Sent: Wednesday, 8 August 2001 11:47 PM > To: 'Hisham Khartabil'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] NOTIFY and application/cpim-pidf+xml > > > > > > > > -----Original Message----- > > From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > > Sent: Monday, July 30, 2001 3:03 PM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] NOTIFY and application/cpim-pidf+xml > > > > > > Hi, > > > > The example of NOTIFY in draft-ietf-simple-presence-01.txt > > does not use > > content-type: message/cpim nor application/cpim-pidf+xml. I > > can understand > > why. > > At the time of writing, these were not available. > > > > The question is: > > > > In application/cpim-pidf+xml has the elements and > > . Which > > one is represented by the description attribute in the > > contact header? and > > how do you represent the other? > > I actually think that the description attribute of the contact > header would > map to the note tag, not detail. > > The value would be set by whether the contact is active or not. I had a > conversation with a few folks about this today. Normally, if you have a > registered contact, its going to be "open". When it expires, instead of > being closed, it simply disappears. So, the "closed" attribute is never > used. > > Another possibility is that if the contact is registered with a q value of > zero, that means "closed". > > No, there is a higher level issue here, which is what we do and don't want > to say about constructing pidf documents from registers. To a > large extent, > its a local implementation choice, since it doesn't impact > interoperability. > For example, choosing never to use closed, or using it when a q value of > zero is used, are both reasonable choices. Any sane mapping will do fine. > So, on one extreme, we can leave the entire mapping up to the > implementation. > > At the other extreme, we specify the entire thing. > > I'm not sure where in there is the right answer, but I suspect > its closer to > specifying nothing, as opposed to the entire mapping. > > Comments? I have a client that sends REGISTER with q value of 0 in the contact to indicate "closed", and my Presence Server only understands "closed" when the registration has expired. The NOTIFY sent to my watchers in that case would have value "open" in . This is simply because the PS does not interpret the q value as "closed". Is that an interoperability issue? > > > > > > If the Presence Server is treating the GW as just another PUA > > (presence > > server only accepts SUBSCRIBE and REGISTER requests, it sends > > out NOTIFY), > > then the GW needs to map the cpim notify into a SIP REGISTER. > > does it not? > > No; cpim is server to server, not server to client. > > -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 Arnaud.Weil@winwise.com Thu Aug 9 05:44:41 2001 Received: from pikachu.winwise.home ([194.98.12.74]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA12443 for ; Thu, 9 Aug 2001 05:44:35 -0400 (EDT) Received: from 172.17.1.250 by pikachu.winwise.home (InterScan E-Mail VirusWall NT); Thu, 09 Aug 2001 11:44:22 +0200 (Romance Daylight Time) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Why do we need Presence Caching? X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 9 Aug 2001 11:44:34 +0200 Message-ID: <98D95D87610EA04296C7C3006888EA083910E7@milou.winwise.home> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Why do we need Presence Caching? Thread-Index: AcEgE+R07XcWRMZdS2iZrcxfPJSicwAo2zXA From: "Arnaud Weil" To: "Tony Hansen" , Content-Length: 5932 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA12443 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: Still, this answer doesn't seem very satisfying to me. RFC 2779 states that: 5.3.1. The protocol MUST provide A means of verifying that the presence information is accurate, as sent by B. 5.3.3. The protocol MUST provide A means of verifying that the notification was sent by B. To me, this means that such functionnalities must be implemented in the protocol itself, so your idea of SIMPLE relying on a pre-existent trust relationship doesn't meet such requirements. Am I wrong about this? Regards, Arnaud -----Original Message----- From: Tony Hansen [mailto:tony@att.com] Sent: mercredi 8 août 2001 16:07 To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Why do we need Presence Caching? You have to establish a trust relationship with some systems. THESE systems you believe to be giving you good data. And you can use their system certificate via TLS to verify their identity, or use some other mechanism of server identity verification. For example, do you feel you can trust xyz.com to act as a proxy server for watchers on XYZ's system? If yes, and you can verify that it really is xyz.com that's sending you a subscription request, then you can consider that to be a trusted subscription. If the answer to either question is no, then it's untrusted information. Tony Hansen tony@att.com Arnaud Weil wrote: > > Errr... yes, that's what I just wrote at the end of my previous reply. > Just like you I'd like to know how this is effectively implemented by > SIMPLE. It might even already be secured by SIP. > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: mercredi 8 août 2001 15:53 > To: Arnaud Weil; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Why do we need Presence Caching? > > Unfortunately, none of this tells you HOW to secure it; it tells you > what security you're supposed to have. > > > -----Original Message----- > > From: Arnaud Weil [mailto:Arnaud.Weil@winwise.com] > > Sent: Wednesday, August 08, 2001 9:46 AM > > To: David R. Oran; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Why do we need Presence Caching? > > > > > > How this should be secured is another part of the CPIM > > requirements, as stated in the following parts of RFC 2779: > > > > 2.5.1. The protocol MUST provide means to ensure confidence that a > > received message (NOTIFICATION or INSTANT MESSAGE) has not been > > corrupted or tampered with. > > > > 3.3.3 The protocol caching facilities MUST NOT circumvent > > established > > ACCESS RULES or restrict choice of authentication/encryption > > mechanisms. > > > > 5.3.1. The protocol MUST provide A means of verifying that the > > presence information is accurate, as sent by B. > > > > 5.3.3. The protocol MUST provide A means of verifying that the > > notification was sent by B. > > > > However, I'like to point out that these are the requirements > > that SIMPLE is supposed to meet as a protocol that conforms > > with CPIM. I'm too new to SIMPLE to tell you how they are > > effectively met by SIMPLE, and hope someone more experienced > > could answer this. > > > > Arnaud > > > > -----Original Message----- > > From: David R. Oran [mailto:oran@cisco.com] > > Sent: mercredi 8 août 2001 15:24 > > To: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Why do we need Presence Caching? > > > > > > How do you secure this without transitive trust among A, B > > and C? Or are you happy with requiring C to trust B to > > properly represent A's state and not be a "man in the middle" > > > > > > > -----Original Message----- > > > From: simple-admin@mailman.dynamicsoft.com > > > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > > Arnaud Weil > > > Sent: Wednesday, August 08, 2001 8:20 AM > > > To: Simon; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Why do we need Presence Caching? > > > > > > > > > Hi Simon, > > > > > > It seems to me that caching presence information would allow > > > for a more sensible use of the available resources. The idea > > > is that if B knows about A's presence, it can give it to C > > > without the need for C to ask it to A. This relieves the > > > pressure on A. And this will be quite interesting in the case > > > of servers handling thousands of subscriptions. > > > > > > Of course, as part of CPIM, a timing mechanism has been set > > > up so that B doesn't give to C any inacurate presence info about A. > > > > > > Regards, > > > Arnaud Weil > > > > > > -----Original Message----- > > > From: Simon [mailto:greatpolaris@xinhuanet.com] > > > Sent: mercredi 8 août 2001 09:26 > > > To: simple@mailman.dynamicsoft.com > > > Subject: [Simple] Why do we need Presence Caching? > > > > > > > > > Hi, > > > > > > In the section 3.3 of RFC 2779, there are some requirements > > > about presence caching and replication. But I cannot > > > understand when we need to cache the PRESENCE INFORMATION. > > > Would you like to give me some explantions? > > > > > > Thanks. > > > > > > Regards, > > > Simon Young > > > > > > _______________________________________________ > > > 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/listinf> o/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 c-Dai.Ngo@WCOM.Com Fri Aug 10 15:36:26 2001 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 PAA17767 for ; Fri, 10 Aug 2001 15:36:24 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GHV00C0TAG8JN@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Fri, 10 Aug 2001 19:36:08 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GHV00L01AFQ26@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Fri, 10 Aug 2001 19:36:07 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GHV00HD3AFOIQ@pmismtp01.wcomnet.com> for simple@mailman.dynamicsoft.com; Fri, 10 Aug 2001 19:35:48 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 19:35:47 +0000 Content-return: allowed Date: Fri, 10 Aug 2001 19:35:40 +0000 From: "Ngo, Dai (c)" To: simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E6C4DB4@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_VzrheXvZYtXHzg91SykdQw)" Content-Length: 4959 Subject: [Simple] Preference for Individual URI 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: 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_VzrheXvZYtXHzg91SykdQw) Content-type: text/plain; charset=ISO-8859-1 All, In section "5.1 Contact, Accept-Contact and Reject-Contact Parameters" of the draft-ietf-sip-callerprefs-04.txt it states that the Methods parameter, Description parameter, and priority parameter for a contact header are NOT used in the matching operation described in Section 6.4.1 of the same draft. In addition, the contact URI comparison is based on SIP URI matching rules. This implies that in the following example described in the draft-ietf-simple-presence-01.txt, the second contact: ;methods="SUBSCRIBE" will completely *REPLACE* the first contact: ;methods=MESSAGE;description="open" due to the fact that the contact URI is the same for both: REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2818@pua.example.com CSeq: 1 REGISTER Contact: ;methods="MESSAGE" ;description="open" Contact: ;methods="SUBSCRIBE" Expires: 600 So if I'm login into a computer and have one SIP URI , the only choice I have is to send a REGISTER with: contact: ;methods="MESSAGE, SUBSCRIBE";description="open". Now, later, I want to continue receiving SUBSCRIBEs (description="open") but not to receive MESSAGEs (description="close"). What options do I have besides having to have two different sip contact URIs? Thanks for helping. -- Dai --Boundary_(ID_VzrheXvZYtXHzg91SykdQw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Preference for Individual URI

All,

In section "5.1 Contact, Accept-Contact and = Reject-Contact Parameters" of the = draft-ietf-sip-callerprefs-04.txt it states that the Methods parameter, = Description parameter, and priority parameter for a contact header are = NOT used in the matching operation described in Section 6.4.1 of the = same draft. In addition, the contact URI comparison is based on SIP URI = matching rules. This implies that in the following example described in = the draft-ietf-simple-presence-01.txt, the second contact: = <sip:id@pua.example.com>;methods=3D"SUBSCRIBE" will = completely *REPLACE* the first contact: = <sip:id@pua.example.com>;methods=3DMESSAGE;description=3D"ope= n" due to the fact that the contact URI = <sip:id@pua.example.com> is the same for both:

        REGISTER = sip:example.com SIP/2.0
       Via: = SIP/2.0/UDP pua.example.com:5060
       To: = <sip:resource@example.com>
       From: = <sip:resource@example.com>
       Call-ID: = 2818@pua.example.com
       CSeq: 1 = REGISTER
       Contact: = <sip:id@pua.example.com>;methods=3D"MESSAGE"
          &nb= sp;      = ;description=3D"open"
       Contact: = <sip:id@pua.example.com>;methods=3D"SUBSCRIBE"
       Expires: = 600

So if I'm login into a computer and have one SIP URI = <sip:id@pua.example.com>, the only choice I have is to send a = REGISTER with:

        contact: = <sip:id@pua.example.com>;methods=3D"MESSAGE, = SUBSCRIBE";description=3D"open".

Now, later, I want to continue receiving SUBSCRIBEs = (description=3D"open") but not to receive MESSAGEs = (description=3D"close"). What options do I have besides = having to have two different sip contact URIs?

Thanks for helping.

-- Dai

--Boundary_(ID_VzrheXvZYtXHzg91SykdQw)-- From thesuperpromoter2001@yahoo.com Sat Aug 11 15:39:35 2001 Received: from ns.thesuperpromoter.com (ns.thesuperpromoter.com [64.65.15.89]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21513 for ; Sat, 11 Aug 2001 15:39:34 -0400 (EDT) From: thesuperpromoter2001@yahoo.com Received: from yahoo.com (ns [64.65.15.89]) by ns.thesuperpromoter.com (8.9.3/8.9.3) with SMTP id PAA32208 for ; Sat, 11 Aug 2001 15:57:26 -0400 Message-Id: <200108111957.PAA32208@ns.thesuperpromoter.com> Date: Sat, 11 Aug 2001 15:57:27 -0400 To: simple@mailman.dynamicsoft.com Precedence: List X-GetYours: http://www.elitescripts.com Reply-to: thesuperpromoter2001@yahoo.com Content-Length: 977 Subject: [Simple] FREE SAFELIST with ONLINE EMAILERS! Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: We were notified that simple@mailman.dynamicsoft.com would be interested in using our service to help your online business succeed. If this is a mistake please accept our apologies and click on the remove link at the end of this email and we will NEVER send you another email! FREE SAFELIST with ONLINE EMAILERS! Send 100% Spam Free Email Instantly From Your Browser! Fast Online Mailers With Hundreds Of New Prospects Added Daily! All Emails Show From Our Email Address Not Yours! 100% Compatible With All Systems! http://themailblaster.com/cgi-bin/MailerPro/MoneyMail.cgi Aol To unsubscribe from this list copy and paste the following URL into your browser. If it appears as a link, just click it. Note: If you remove your address it will be removed and added to our banned address file. http://64.65.15.89/cgi-bin/MailerPro/unsubscribe.cgi?action=unsub&email=simple@mailman.dynamicsoft.com From cards@chargecards2go.com Sat Aug 11 23:48:53 2001 Received: from mail.chargecards2go.com (chargecards2go.com [207.0.63.16]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22849 for ; Sat, 11 Aug 2001 23:48:53 -0400 (EDT) From: cards@chargecards2go.com Received: from web-script(nobody).chargecards2go.com (207.0.63.16) by mail.chargecards2go.com (8.9.3/8.9.3) with SMTP id f7C3jiV24900 for ; Sat, 11 Aug 2001 23:45:44 -0400 To: simple@mailman.dynamicsoft.com Date: Sat, 11 Aug 2001 20:52:05 Message-Id: <300.151778.415604@unknown> Reply-To: cards@chargecards2go.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 1924 Subject: [Simple] ADV:CREDIT CARD PROCESSING 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: ********************************************************* To be removed from from further mailings respond to this message with "remove" in the subject line. ********************************************************* Dear Friend, Discover how you can accept credit cards directly from your website, telephone or fax for your products and services and never need to purchase or lease expensive credit card equipment or pay a large monthly fee for online ordering capabilities or real time processing transactions. **Brand New** Merchant Credit Card acceptance program allows you to apply online and receive an instant live credit card processing account in 60 seconds. No need to fill out applications and go through a lengthy approval process. Your account is live and your website can start taking orders immediately. We approve 99% of all applicants. If you are interested in an easy way to accept Visa, MasterCard, Amex and Discover any TIME,any WHERE through phone, fax or internet without the need to purchase or lease expensive credit card equipment, this brand new program is for you! All credit card funds are transferred into the checking account of your choice within 2 business days. Before you spend any money on a credit card merchant program LOOK at this new program! We have a 99.9% approval rate for most business types regardless of past credit history! If you have an interest in learning more about a Merchant Account for yourself or your business please email your Name, PHONE NUMBER (Don't forget your area code) and best time to call to: mailto:inquiry@chargecards2go.com A representative will return your call within 24hrs. Or feel free to call us on our 24 hour voicemail at: 1-800-288-7363 This offer only applies to U.S. Residents only and some Canadians with valid U.S. Social Security #'s. IBS/PBS a registered agent for CSPI 7657 Winnetka Ave Canoga Park Ca. 91306 From travelincentives@aol.com Sun Aug 12 01:00:34 2001 Received: from mail.sdarts.com.cn ([202.102.163.163]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id BAA23080 for ; Sun, 12 Aug 2001 01:00:33 -0400 (EDT) Received: from plain (unverified [211.154.160.8]) by mail.sdarts.com.cn (EMWAC SMTPRS 0.83) with SMTP id ; Sun, 12 Aug 2001 12:41:29 +0800 Message-ID: From: michael0323@hotmail.com To: simple@mailman.dynamicsoft.com Date: Sun, 12 Aug 2001 12:36:32 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Length: 527 Subject: [Simple] Win One of 25 Dream Vacation Getaways!! . 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: You have been specially selected to qualify for the following: Premium Vacation Package and Pentium PC Giveaway To review the details of the please click on the link with the confirmation number below: http://vacation.1xin.net Confirmation Number#Lh340 Please confirm your entry within 24 hours of receipt of this confirmation. Wishing you a fun filled vacation! If you should have any additional questions or cann't connect to the site do not hesitate to contact me direct: mailto:vacation@btamail.net.cn?subject=Help! From thesuperpromoter2001@yahoo.com Sun Aug 12 12:40:25 2001 Received: from ns.thesuperpromoter.com (ns.thesuperpromoter.com [64.65.15.89]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24988 for ; Sun, 12 Aug 2001 12:40:24 -0400 (EDT) From: thesuperpromoter2001@yahoo.com Received: from yahoo.com (ns [64.65.15.89]) by ns.thesuperpromoter.com (8.9.3/8.9.3) with SMTP id MAA30750 for ; Sun, 12 Aug 2001 12:58:24 -0400 Message-Id: <200108121658.MAA30750@ns.thesuperpromoter.com> Date: Sun, 12 Aug 2001 12:58:24 -0400 To: simple@mailman.dynamicsoft.com Precedence: List X-GetYours: http://www.elitescripts.com Reply-to: thesuperpromoter2001@yahoo.com Content-Length: 616 Subject: [Simple] Send 50,000 Emails Monthly 100% Spam Free! Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Send 50,000 Emails Monthly 100% Spam Free! Blast Your Sites To 2.3 Million Websites Daily! Send ALL Mail Through Our Mail Servers! 3 Email Blasters For Pro Users! Join FREE and send mail to all new users once per week! http://thesuperpromoter.com AOL To unsubscribe from this list copy and paste the following URL into your browser. If it appears as a link, just click it. Note: If you remove your address it will be removed and added to our banned address file. http://64.65.15.89/cgi-bin/MailerPro/unsubscribe.cgi?action=unsub&email=simple@mailman.dynamicsoft.com From 200.dist@wanadoo.es Sun Aug 12 15:27:05 2001 Received: from distancia.20 ([213.98.118.212]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA25468 for ; Sun, 12 Aug 2001 15:26:59 -0400 (EDT) Message-Id: <200108121926.PAA25468@mailman.dynamicsoft.com> Reply-To: "cursos"<200.dist@wanadoo.es> From: "cursos"<200.dist@wanadoo.es> To: "" Organization: Enseñanza X-Priority: 3 X-MSMail-Priority: Normal Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 10 Aug 2001 08:44:31 +0200 Content-Length: 2637 Subject: [Simple] PUBLI.CURSOS. 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: 8.8.2001.Publicidad/Enseñanza a Distancia COFOR-Gestion Integral.1.SL Hola que tal: El motivo de la presente carta es informarle de la posibilidad de poder realizar algún curso a distancia de tu interés, cursos relacionados con tu trabajo inquietudes y ocio.ect.El conocimiento es el mayor patrimonio de que podemos disponer. Nos dedicamos desde 1996.a impartir cursos a distancia disponemos de una amplia variedad de cursos sencillos para poder seguirlos comodamente desde cualquier parte del mundo y a unos precios muy competitivos. Con amplias indicaciones sobre bolsa de trabajo salidas laborales ect. NET ------------ Redes y Sistemas Sistemas Servers Diseño Web BUSSINES ------------ Gestion Comercial y Marketing Relaciones Publicas Recursos Humanos Comercio Exterior Dirección Comercial Gestión Medio Ambiental Dirección de Restaurantes SALUD SUPERACION PERSONAL ------------------------------------- Psicoterapia Psicologia Practica Nutrí terapia y Salud Monitor Yoga Tai-Chi Hipnoterapia Quiromasaje y Reflexoterapia Aromaterapia Cosmética Natural Hierbas Medicinales -------------------------------------- CURSOS BECADOS: Los cursos son de 200.horas lectivas el precio standar por curso es de 35.000.pts(Despues de beca)España a plazos.Iberoamerica 150.usa dolar aplazados.(Despues de beca) El Diploma: "Técnico Especialista" El tiempo aproximado por curso dependiendo de los conocimientos en areas similares de que se disponga,es entre 2-6.meses.aprox. Si desean que les ampliemos información pueden enviar un e-mail les contestaremos con la mayor brevedad y les indicaremos nuestro espacio web que se encuentra en reformas(El dia 16.de Agosto Inaguramos la web).No lo piensen mas y envien un e-mail y recibiran todo tipo de informes y detalles muy en breve,estos cursos suponen una inteligente INVERSION POR SU PARTE. Envie e-mail: CURFDIRECC@terra.es Sin otra que rogarle me envien un e-mail si estan interesados/as Te enviamos un saludo. Si desea no recibir mas e-mail. remove/mail CUR.MEDI@terra.es Jose Navarro Broker-COFOR Gestion Integral 1.SL Isaac Albeniz 16. 30009-MURCIA España ------------------ From skyward_7@yahoo.com Sun Aug 12 23:51:14 2001 Received: from smtp2.ns.sympatico.ca (smtp1.ns.sympatico.ca [142.177.1.91]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26791 for ; Sun, 12 Aug 2001 23:51:13 -0400 (EDT) From: skyward_7@yahoo.com Received: from smtp1.ns.sympatico.ca ([142.177.87.17]) by smtp2.ns.sympatico.ca (Post.Office MTA v3.5.3 release 223 ID# 0-68925U141000L141000S0V35) with SMTP id ca for ; Mon, 13 Aug 2001 00:47:40 -0300 Date: Sun, 12 Aug 01 07:40:21 EST To: simple@mailman.dynamicsoft.com Message-ID: <> Content-Length: 15273 Subject: [Simple] ADV 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: Dear simple@mailman.dynamicsoft.com, Dear Friends & Future Millionaire: YOU REALLY OWE IT TO YOURSELF TO LOOK AT THIS!! AS SEEN ON NATIONAL TV: ''Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time'' THANKS TO THE COMPUTER AGE AND THE INTERNET! BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say ''YEAH RIGHT'' , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO. Laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. -------------------------------------------------------------------------------- Here is another testimonial: ''This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything .'' More testimonials later but first, *** PRINT THIS NOW FOR YOUR FUTURE REFERENCE *** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: **** Order all 5 reports shown on the list below. **** For each report, send $5.00 U.S CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. **** When you place your order, make sure you order each of the 5 reports from the person whose name is next to the REPORT. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5X 5 = $25.00. **** Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****.IMPORTANT -DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. Move the name & address in REPORT #4down TO REPORT #5. Move the name & address in REPORT #3 down TO REPORT #4. Move the name & address in REPORT #2 down TO REPORT #3. Move the name & address in REPORT #1 down TO REPORT #2 Insert YOUR name & address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! -------------------------------------------------------------------------------- Take this entire letter, with the modified list of names (with your name now in position #1, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the Internet, the 5 REPORTS you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1 : BY SENDING TARGETED BULK E-MAIL LEGALLY let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only targeted 5,000 e-mails each. Targeted email is to persons interested in business opportunities. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for REPORT #1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered REPORT #2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for REPORT #3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for REPORT #4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million)e-mails. The 0.2% response to that is 100,000 orders for REPORT # 5. THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: $50+ $500+ $5,000 + $50,000+ $500,000.........Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY! -------------------------------------------------------------------------------- REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD #2 : BY PLACING FREE ADS ON THE INTERNET Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD #2 as you go along. Study the REPORTS (#1-5) to help with your marketing. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. _______________ AVAILABLE REPORTS__________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ------------------------------------------------------------------------------- REPORT #1:"The Bulk Email Survival Guide #1 from: T. Crowe P.O. Box 2546 Springhill, NS Canada, B0M 1X0 -------------------------------------------------------------------------------- REPORT #2: "Inside Secrets To Wealth On The Web #2 from: JD P.O. Box 1114 Des Plaines, Illinois 60017, USA -------------------------------------------------------------------------------- REPORT #3:"The Secret to Multilevel marketing on the Net" Order REPORT #3 from: R. P. P.O. Box 191 St-Calixte, Quebec Canada J0K1Z0 -------------------------------------------------------------------------------- REPORT #4:"How to become a millionaire utilizing MLM & the Net" Order REPORT #4 from: J Santi 833 Walter Ave Des Plaines, IL 60016 USA -------------------------------------------------------------------------------- REPORT #5:"HOW TO SEND 1 MILLION E-MAILS FOR FREE" Order REPORT #5 from: Aaron Croft 1037 Charlela Ln. #206 Elk Grove Village, IL 60007 USA $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ (A note on mailing to Canada. It's just as easy as to the US. Follow same procedure but use 60 cents postage) Follow these guidelines to guarantee your success: If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. DO NOT QUIT, you do not know how close you are to success if you quit, it may be the next mailing. THIS IS YOUR WINNING LOTTERY. After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT #2. If you did not, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for Report #2, YOU CAN RELAX, because the system is already working for you , and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER :Every time your name is moved down on the list, you are placed in front of a different report. You can KEEP Track of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAIL SAND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: "You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2...........#5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on everyone of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! JUST DO IT!!!!!! ************** MORE TESTIMONIALS**************** '' My name is Mitchell. My wife , Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received a total of $ 147,200.00 all cash!I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf, M.D. , Chicago, Illinois -------------------------------------------------------------------------------- ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''. Dan Sondstrom, Alberta, Canada -------------------------------------------------------------------------------- ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e- mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''. Susan De Suza, New York, N.Y. -------------------------------------------------------------------------------- '' It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20,560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to Internet''. Fred Dellaca, Westport, New Zealand -------------------------------------------------------------------------------- ORDER YOUR REPORTS TODAY AND GET STARTED ON OUR ROAD TO FINANCIAL FREEDOM! -------------------------------------------------------------------------------- If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- I apologise if you have been offended. If you'd like to be removed, simply reply with REMOVE in the subject line and you will be removed immediately and receive no further mailings. This message is sent in compliance of the new email Bill HR 1910. Under Bill HR 1910 passed by the 106th US Congress on May 24, 1999, this message cannot be considered SPAM as long as I include a valid return address and the way to be removed. From jon.peterson@NeuStar.com Mon Aug 13 22:14:24 2001 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03021 for ; Mon, 13 Aug 2001 22:14:20 -0400 (EDT) Received: from chi02.npac.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f7E2EKv28321 for ; Mon, 13 Aug 2001 22:14:20 -0400 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 21:11:27 -0500 Message-ID: <70565611B164D511957A001083FCDD56478A2C@va02.va.neustar.com> From: "Peterson, Jon" To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 13 Aug 2001 21:14:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 6507 Subject: [Simple] draft SIMPLE minutes from 51st IETF 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: Thanks very much to the invaluable Mr. Dean Willis for taking these minutes in London this past Monday. If any amendations to these minutes are required, please let us know in the not-too-distant future. Jon Peterson NeuStar, Inc. SIMPLE co-chair --- SIMPLE Charter Changes: Proposed Aug01 -- IM document set to IESG Sep01 -- Presence extension to IESG Jonathan Rosenberg (JDR) suggests swapping these dates as presence is running ahead of messaging. IM Session Open Issues -- Ben Campbell -------------------------------------------- Ovelapping MESSAGEs -- overlapping transactions prohibited by 2543bis. JDR: Three approaches 1) declare non problem 2) allow overlapping transactions by overruling spec using ordering in the content. 3) Define a message transport Dave Oran: 4) Telnet approach -- additive transmissions until ACKed. Question : Can we discard solution 1? This could be a real issue for machine-driven systems. Much discussion on whether this is really a problem. The difference is in waiting for the ACK, and where reordering is done. There may also be a question of rate-liimiting. The real issue is delay from ping-pong effect. Poll: Can we live with no overlap? General response: no. Question: Do we want to fix SIP for this or use something not-SIP for message transport. Question: : For session-mode, SIP has a lot of overhead. We could do something more stream-lined. What? Question: Would text-rtp work for this? We need to do an analysis and determine if it meets requirements. There are likely to be real challenges with NATs. There are also problems with non-reliability as text-RTP is not acknowledged. What about delimiters and framing with RTP? Is this an issue for CPIM conversion? We may need a message delimiter in-body. Question: Is ability to cross a CPIM boundary a requirement -- consensus yes. It is probably acceptable to make the CPIM gateway session stateful. Question: Why are we limiting the "signaling session" to MESSAGEs? Could this be generalized? Can a SIP session running messages transport other messages, like OPTIONS or INVITE? Arguments in both directions presented. Proposal: Always use ";method=MESSAGE" when referencing the URL. Question: Should we move URL out of m= line and into c= line. Will SDP support this? SDP seems to define c=values as addresses, not URIs. ATM uses ATM addresses, so it might be possible. PINT did something similar, and the SDP guys haven't complained loudly. Consensus: yes, may need clarification from MMUSIC. Question: How to get MESSAGE request to follow same signal path as enclosing INVITE? Do we require this ability? Proposal: save this for later. Question: MESSAGEs hitting forking proxied will fork. Is this a problem? This says a couple of things: 1) using SIP for message transport is using a very large hammer for a small nail. This may be further cause for finding a different transport for messages in streams. Discussion postponed. Followup: We'd need alternative proposals -- and must make sure that it gets through NATs. Suggestion: We should keep in mind that session and page based messaging are separate, split the deliverables, and go ahead and get message mode into the IESG. Session mode is to be delegated to design teams to generate real proposals (goal three weeks). Ben Campbell volunteered for non-SIP. Sean Olson olunteered for SIP transport. Question: Currently, MESSAGE follows initial path. This may be very strange if original INVITE follows non-optimal path. We will insert new text to recommend this not happen. Question: Current proposal uses two one-way streams where persistent connections are used. Okay? It appears that commedia (in MMUSIC) will resolve this in general. Presence Open Issues -- Jonathan Rosenberg ----------------------------------------------- Privacy of Auth Policy: Basic question: If a party subscribes, is there an issue with revealing whether they have been accepted or declined. Is this a problem? Should we solve it? Arguments on both sides. This adds complexity, and may not be doable in many implementation domains. Perhaps a set of guidelines for "authorization policy hiding" can be provided to allow specific domains to implement local policy. There are two problems here: leakage of policy (the "hurt feelings" problem) and leakage of presence (rapid vs. slow denials might indicate whether they are there). Proposal : Don't solve, and add cautionary/implementation guidance text to the document. Remote-Party-ID: Predicts that much authentication will be based on transitive trust. SIP. Remote-Party-ID may be useful for this. Question: Should we reference it? Consenus: yes. Presence Doc Format: Open issues with presence document composition and upload. REGISTER may not be the right thing. Do we want to solve these? Consensus: yes. Dicsusion: It is important to be able to feed in presence document components from multiple sources using a common interface method. This is required to be able to composite presence information. Question: How do we want to upload presence? New method? Is there a general purpose uploading method that would work for CPL, etc.? How to prevent madness? Proposal: Property-value management mechanism based on content-disposition. This might actually be able to replace the whole registration payload work, which is currently on-charter for SIPPING. Consenus to explore this line of work. Triggered Authorizations: Background: Use of user-supplied authorization policy, and notification of the lack of authorization policy. Proposal: watcherinfo package with data set for each subscription. Poll for dissenters: none. Discussion: Do we wish to include type or class of authorization in the data set? Consensus no due to complexity. Audience requested to folloow up with more consideration of mechanism and proposed FSM. Settting Authorization Policy: Proposals: 1) Say nothing -- app specific 2) Include approve/reject URLs in wathcerinfo to allow GUI processing at client 3) Define policy doc and upload mehod Much discussion. If policy is semantically self-contained, this would allow a great deal of interoperability. The URL suggestion requires web servers and HTML renderers. Proposals: 1) Leave the solution to the implementaion, potentially using other-defined "upload" procedure, and leave open the option of defining a policy document in the future. 2) Punt to IMPP for a policy document format. Probably no result. Consensus seems to favor proposal 1. From greatpolaris@xinhuanet.com Tue Aug 14 21:24:40 2001 Received: from xinhuanet.com ([202.84.17.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id VAA06682 for ; Tue, 14 Aug 2001 21:24:38 -0400 (EDT) Received: from ([202.106.106.100]) by xinhuanet.com(JetMail 2.5.3.0) with SMTP id jm293b7a03af; Wed, 15 Aug 2001 01:15:56 -0000 Date: Wed, 15 Aug 2001 09:25:18 +0800 From: Simon To: simple@mailman.dynamicsoft.com Message-Id: <20010815090624.E7DC.GREATPOLARIS@xinhuanet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.03 Content-Length: 425 Subject: [Simple] Can I sent a message to him/her when he/she is off line? 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: I did not find any statement about this in the instant message protocol requirement. But I enjoy sending messages to my friends while they are off line, since it is much more convenient than composing a email. To enable this, the messages need to be stored in the server and to be forwarded as soon as possible when the receiptor comes to be online. It is not difficult to implement this function but it can bring us a lot. From jdrosen@dynamicsoft.com Wed Aug 15 02:30:52 2001 Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07502 for ; Wed, 15 Aug 2001 02:30:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7F6UAxX013554; Wed, 15 Aug 2001 02:30:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 02:30:49 -0400 Message-ID: From: Jonathan Rosenberg To: "'Simon'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Can I sent a message to him/her when he/she is off l ine? Date: Wed, 15 Aug 2001 02:30:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 1216 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: > -----Original Message----- > From: Simon [mailto:greatpolaris@xinhuanet.com] > Sent: Tuesday, August 14, 2001 9:25 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Can I sent a message to him/her when he/she is off > line? > > > I did not find any statement about this in the instant > message protocol > requirement. But I enjoy sending messages to my friends while they are > off line, since it is much more convenient than composing a email. > To enable this, the messages need to be stored in the server and to be > forwarded as soon as possible when the receiptor comes to be > online. It > is not difficult to implement this function but it can bring us a lot. Sure, storage and forwarding of messages later on is possible. It is an implementation choice that requires no protocol mechanisms beyond what is already there. -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 From Avshalom@ubique.com Wed Aug 15 05:50:50 2001 Received: from ubqgate02.lotus.com (outbound-pat-address.lotus.co.uk [194.196.39.50]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00462 for ; Wed, 15 Aug 2001 05:50:49 -0400 (EDT) From: Avshalom@ubique.com Subject: Re: [Simple] Can I sent a message to him/her when he/she is off line? To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 15 Aug 2001 12:49:10 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 15/08/2001 12:49:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 2329 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: Should this be part of the protocol? It seems more architectural issue. The IMPP model does not seem to indicate that receiving a message from a presence indicates it being online. avshalom Simon cc: Sent by: Subject: [Simple] Can I sent a message to him/her when he/she is off simple-admin@mailman.dynam line? icsoft.com 15/08/2001 04:25 I did not find any statement about this in the instant message protocol requirement. But I enjoy sending messages to my friends while they are off line, since it is much more convenient than composing a email. To enable this, the messages need to be stored in the server and to be forwarded as soon as possible when the receiptor comes to be online. It is not difficult to implement this function but it can bring us a lot. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From rana@vayusphere.com Mon Aug 20 09:07:31 2001 Received: from hermes.vayusphere.com (hermes.vayusphere.com [216.37.98.147]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00205 for ; Mon, 20 Aug 2001 09:07:30 -0400 (EDT) Received: from vayusphere.com (216-37-101-20.vayusphere.vayusphere.com [216.37.101.20] (may be forged)) by hermes.vayusphere.com (SendmailServer-1.0.1/8.11.1) with ESMTP id f7FMxPQ21921 for ; Wed, 15 Aug 2001 15:59:26 -0700 (PDT) Message-ID: <3B7AFF06.18E5855B@vayusphere.com> Date: Wed, 15 Aug 2001 16:00:23 -0700 From: Hemendra Rana Organization: Vayusphere Inc. X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; 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 Content-Length: 368 Subject: [Simple] How to 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: How to subscribe to this list. The URL at IETF site for mailing list is http://mailman.dynamicsoft.com/mailman/listinfo/simple which somehow is not working. Neither am I able to access archives at http://mailman.dynamicsoft.com/pipermail/simple. Any help will be highly apprecaited. Thanks, Hemendra PS: Please send me a personal mail since I am not on the list. From mhammer@cisco.com Mon Aug 20 09:16:17 2001 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 JAA00283 for ; Mon, 20 Aug 2001 09:16:15 -0400 (EDT) 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 QAA24040; Wed, 15 Aug 2001 16:42:31 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-90.cisco.com [161.44.87.90]) by cia.cisco.com (Mirapoint) with ESMTP id ANT07090; Wed, 15 Aug 2001 16:42:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20010815164039.00b7d788@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Aug 2001 16:45:41 -0400 To: Simon From: Michael Hammer Subject: Re: [Simple] Can I sent a message to him/her when he/she is off line? Cc: simple@mailman.dynamicsoft.com In-Reply-To: <20010815090624.E7DC.GREATPOLARIS@xinhuanet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 943 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: Simon, While we're at it why don't we enable file attachments too???? I'm not sure reinventing all the nuances of an email system are worth it. Besides, when I am waiting for an "instant" message, don't we expect an instant response? For me, the value is lost if the other side is not "on-line." Mike At 09:25 AM 8/15/2001 +0800, Simon wrote: >I did not find any statement about this in the instant message protocol >requirement. But I enjoy sending messages to my friends while they are >off line, since it is much more convenient than composing a email. >To enable this, the messages need to be stored in the server and to be >forwarded as soon as possible when the receiptor comes to be online. It >is not difficult to implement this function but it can bring us a lot. > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple From bcampbell@dynamicsoft.com Mon Aug 20 10:29:17 2001 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 KAA00248 for ; Mon, 20 Aug 2001 10:29:16 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7KERWt07540; Mon, 20 Aug 2001 09:27:32 -0500 Message-ID: <3B811E54.2020604@dynamicsoft.com> Date: Mon, 20 Aug 2001 09:27:32 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Avshalom@ubique.com CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Can I sent a message to him/her when he/she is off line? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1651 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: I don't think it belongs in protocol. There are a lot of ways an application can accomplish this, if they wish. For example, you could set your presence info to point to a store and forward server. You might even put a mailto: url in your presence info when offline. Receiving a message does not imply anything at all about your presence state. Avshalom@ubique.com wrote: > Should this be part of the protocol? It seems more architectural issue. The > IMPP model does not seem to indicate that receiving a message from a > presence indicates it being online. > > avshalom > > > > [snip] > > > > > I did not find any statement about this in the instant message protocol > requirement. But I enjoy sending messages to my friends while they are > off line, since it is much more convenient than composing a email. > To enable this, the messages need to be stored in the server and to be > forwarded as soon as possible when the receiptor comes to be online. It > is not difficult to implement this function but it can bring us a lot. > > _______________________________________________ > 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 jon.peterson@NeuStar.com Mon Aug 20 10:43:06 2001 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00314 for ; Mon, 20 Aug 2001 10:43:06 -0400 (EDT) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f7KEh6k03414 for ; Mon, 20 Aug 2001 10:43:06 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 09:41:44 -0500 Message-ID: <70565611B164D511957A001083FCDD56478A4E@va02.va.neustar.com> From: "Peterson, Jon" To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 20 Aug 2001 09:42:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2226 Subject: [Simple] Charter revisions 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: Greetings to you all, At the meeting in London we premiered a new version of the charter, and received a few comments from various parties on its scope and deliverables. Most significantly, the IESG has decreed that all proposals for the addition of new methods to the SIP standard must be worked through the SIP WG. This means that our current document detailing the MESSAGE method (draft-ietf-simple-im-01) will have to go to the IESG through the SIP WG, and that therefore our deliverables have changed to reflect this new target. I don't believe that the content of the MESSAGE draft will require any unforeseen modifications in order to transition out of the SIMPLE WG. Note that this pertains only to the draft that defines the MESSAGE method; the other drafts in the IM document set (draft-ietf-simple-im-session-00 and draft-ietf-simple-im-sdp-00) will continue to be developed here in SIMPLE. Also, if the definition of any new method is required for presence publication, this too would become the prerogative of the SIP WG. I understand that part of the reason why the IESG has moved method development into the SIP WG is to ensure that each SIP extension doesn't develop its own methods to address a generalizable problem; this suggests that a more general approach to the problem of uploading configuration data from the user agent to various servers may be favored. However, we have kept a deliverable on our charter below to reflect any possible upload mechanism work (some of which may transfer to the SIP WG) including a policy document on the application of a general upload mechanism to the presence publication problem. Jonathan Rosenberg also suggested that we re-order things a bit, as reflected below. Aug 01 Submission of extension for presence to IESG Sep 01 Transfer of MESSAGE definition draft to SIP WG Sep 01 Submission of instant messaging session drafts to IESG Oct 01 Submission of extensions for watcher information to IESG Nov 01 Submission of extension for presence publication to IESG Comments? Suggestions? We'd like to dispatch a final version of this revised charter to the ADs for review before the end of the month. Jon Peterson NeuStar, Inc. SIMPLE co-chair From jon.peterson@NeuStar.com Mon Aug 20 10:48:27 2001 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00358 for ; Mon, 20 Aug 2001 10:48:26 -0400 (EDT) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f7KEmQk03491 for ; Mon, 20 Aug 2001 10:48:26 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 09:47:05 -0500 Message-ID: <70565611B164D511957A001083FCDD56478A4F@va02.va.neustar.com> From: "Peterson, Jon" To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 20 Aug 2001 09:47:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2306 Subject: [Simple] Sessions of MESSAGEs 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: After the SIMPLE session last week in London, the SIMPLE chairs received some feedback from the IESG with regards to the use of the MESSAGE method end-to-end when an IM session has been established with an INVITE (as described in draft-ietf-simple-im-session-00). The IESG has some concerns that this mechanism constitutes the use of SIP as a transport protocol. In other words, once the session has been established between the two endpoints by the INVITE, if the MESSAGEs can only go directly end-to-end, then their headers and related protocol apparatus are entirely superfluous and may do more harm than good. We saw during the meeting last week that there were definitely some pitfalls to allowing methods other than MESSAGE across the IM stream (as well as questions about overlapping transactions, redirection, forking, and so forth), and it isn't clear that the overhead is justified if MESSAGE is just an envelope for its encapsulated MIME payload. The IESG was particularly concerned, in addition to the protocol overhead, with congestion characteristics of the messaging session and with the precedent that could be set by using SIP in this fashion. For these reasons, the IESG is not inclined to look favorably on that direction for our protocol work. They also weren't enthusiastic about the potential use of RTP text for message transmission (significant concerns were also raised on the floor in London about message framing, especially at CPIM gateways). The recommendation we've been given is to focus on a standard transport protocol with understood congestion properties such as TCP or SCTP. In London, Ben Campbell took an action item to begin investigating alternatives along these lines given the significant concerns that arose on the floor with regards to the other approaches. It seems that the primary question about this approach is what runs over the transport protocol in question; i.e. MIME headers and bodies, pure message/cpim, BEEP, plain text, etc. If anyone feels strongly that we should continue to pursue the use of the MESSAGE method for direct end-to-end IM signaling, or has input about how the transport should operate, let's get this discussion underway promptly so we can meet our projected September deliverables. Jon Peterson NeuStar, Inc SIMPLE co-chair From sriramp@nortelnetworks.com Mon Aug 20 10:55:57 2001 Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00407 for ; Mon, 20 Aug 2001 10:55:56 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA13634 for ; Mon, 20 Aug 2001 09:55:30 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 20 Aug 2001 09:55:16 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 09:54:38 -0500 Message-ID: <9A9367D1556AD21182C40000F80930AB04411D30@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF Date: Mon, 20 Aug 2001 09:54:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12988.031F2B70" Content-Length: 4275 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: 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_01C12988.031F2B70 Content-Type: text/plain; charset="iso-8859-1" Problems with the list...my email did not get through -----Original Message----- From: Parameswar, Sriram [NGB:B658:EXCH] Sent: Friday, August 17, 2001 11:04 AM To: 'Peterson, Jon'; 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF Hi All, With regards to the following question and answer (see below) - and my not being there at the IETF 51, I would be extremely grateful if somebody could explain the term 'Property-value management mechanism based on content-disposition.' I also want to know how this applies to the question of publishing presence via methods other than REGISTER. Thanks in advance, Sriram --------------------------------------------- Question: How do we want to upload presence? New method? Is there a general purpose uploading method that would work for CPL, etc.? How to prevent madness? Proposal: Property-value management mechanism based on content-disposition. This might actually be able to replace the whole registration payload work, which is currently on-charter for SIPPING. Consenus to explore this line of work. __________________________________________ Sriram Parameswar Phone: 972-685-8540 Wireless IP MultiMedia (WIPMM) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C12988.031F2B70 Content-Type: text/html; charset="iso-8859-1" FW: [Simple] draft SIMPLE minutes from 51st IETF
Problems with the list...my email did not get through 

-----Original Message-----
From: Parameswar, Sriram [NGB:B658:EXCH]
Sent: Friday, August 17, 2001 11:04 AM
To: 'Peterson, Jon'; 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF


Hi All,

With regards to the following question and answer (see below) - and my not being there at the IETF 51, I would be extremely grateful if somebody could explain the term 'Property-value management mechanism based on content-disposition.'

I also want to know how this applies to the question of publishing presence via methods other than REGISTER.

Thanks in advance,

Sriram

---------------------------------------------

Question: How do we want to upload presence? New method? Is there a general
purpose uploading method that would work for CPL, etc.? How to prevent
madness?

Proposal:  Property-value management mechanism based on
content-disposition. This might actually be able to replace the whole
registration payload work, which is currently on-charter for SIPPING.
Consenus to explore this line of work.

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


------_=_NextPart_001_01C12988.031F2B70-- From bcampbell@dynamicsoft.com Mon Aug 20 10:58:17 2001 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 KAA00440 for ; Mon, 20 Aug 2001 10:58:16 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7KEuvt07554; Mon, 20 Aug 2001 09:56:58 -0500 Message-ID: <3B812539.4090304@dynamicsoft.com> Date: Mon, 20 Aug 2001 09:56:57 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: "Peterson, Jon" CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Sessions of MESSAGEs References: <70565611B164D511957A001083FCDD56478A4F@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 2964 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: I assume we would still keep MESSAGE for non-session messaging. After writing the draft on using MESSAGE in sessions, I am probably its biggest critic. I think we should abandon that effort completely. As far as the message stream itself, I have heard some support for the idea of doing pure message/cpim over TCP and TLS. Personally, this sounds better the more I think about it. Peterson, Jon wrote: > After the SIMPLE session last week in London, the SIMPLE chairs received > some feedback from the IESG with regards to the use of the MESSAGE method > end-to-end when an IM session has been established with an INVITE (as > described in draft-ietf-simple-im-session-00). > > The IESG has some concerns that this mechanism constitutes the use of SIP as > a transport protocol. In other words, once the session has been established > between the two endpoints by the INVITE, if the MESSAGEs can only go > directly end-to-end, then their headers and related protocol apparatus are > entirely superfluous and may do more harm than good. We saw during the > meeting last week that there were definitely some pitfalls to allowing > methods other than MESSAGE across the IM stream (as well as questions about > overlapping transactions, redirection, forking, and so forth), and it isn't > clear that the overhead is justified if MESSAGE is just an envelope for its > encapsulated MIME payload. The IESG was particularly concerned, in addition > to the protocol overhead, with congestion characteristics of the messaging > session and with the precedent that could be set by using SIP in this > fashion. > > For these reasons, the IESG is not inclined to look favorably on that > direction for our protocol work. They also weren't enthusiastic about the > potential use of RTP text for message transmission (significant concerns > were also raised on the floor in London about message framing, especially at > CPIM gateways). The recommendation we've been given is to focus on a > standard transport protocol with understood congestion properties such as > TCP or SCTP. In London, Ben Campbell took an action item to begin > investigating alternatives along these lines given the significant concerns > that arose on the floor with regards to the other approaches. It seems that > the primary question about this approach is what runs over the transport > protocol in question; i.e. MIME headers and bodies, pure message/cpim, BEEP, > plain text, etc. > > If anyone feels strongly that we should continue to pursue the use of the > MESSAGE method for direct end-to-end IM signaling, or has input about how > the transport should operate, let's get this discussion underway promptly so > we can meet our projected September deliverables. > > Jon Peterson > NeuStar, Inc > SIMPLE co-chair > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From jon.peterson@NeuStar.com Mon Aug 20 11:03:48 2001 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00493 for ; Mon, 20 Aug 2001 11:03:47 -0400 (EDT) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f7KF3bk03872; Mon, 20 Aug 2001 11:03:37 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 10:02:16 -0500 Message-ID: <70565611B164D511957A001083FCDD56478A50@va02.va.neustar.com> From: "Peterson, Jon" To: "'Ben Campbell'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 10:03:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3269 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: Yes, we will still keep MESSAGE for non-session messaging. Jon Peterson NeuStar, Inc -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Monday, August 20, 2001 8:57 AM To: Peterson, Jon Cc: 'simple@mailman.dynamicsoft.com' Subject: Re: [Simple] Sessions of MESSAGEs I assume we would still keep MESSAGE for non-session messaging. After writing the draft on using MESSAGE in sessions, I am probably its biggest critic. I think we should abandon that effort completely. As far as the message stream itself, I have heard some support for the idea of doing pure message/cpim over TCP and TLS. Personally, this sounds better the more I think about it. Peterson, Jon wrote: > After the SIMPLE session last week in London, the SIMPLE chairs received > some feedback from the IESG with regards to the use of the MESSAGE method > end-to-end when an IM session has been established with an INVITE (as > described in draft-ietf-simple-im-session-00). > > The IESG has some concerns that this mechanism constitutes the use of SIP as > a transport protocol. In other words, once the session has been established > between the two endpoints by the INVITE, if the MESSAGEs can only go > directly end-to-end, then their headers and related protocol apparatus are > entirely superfluous and may do more harm than good. We saw during the > meeting last week that there were definitely some pitfalls to allowing > methods other than MESSAGE across the IM stream (as well as questions about > overlapping transactions, redirection, forking, and so forth), and it isn't > clear that the overhead is justified if MESSAGE is just an envelope for its > encapsulated MIME payload. The IESG was particularly concerned, in addition > to the protocol overhead, with congestion characteristics of the messaging > session and with the precedent that could be set by using SIP in this > fashion. > > For these reasons, the IESG is not inclined to look favorably on that > direction for our protocol work. They also weren't enthusiastic about the > potential use of RTP text for message transmission (significant concerns > were also raised on the floor in London about message framing, especially at > CPIM gateways). The recommendation we've been given is to focus on a > standard transport protocol with understood congestion properties such as > TCP or SCTP. In London, Ben Campbell took an action item to begin > investigating alternatives along these lines given the significant concerns > that arose on the floor with regards to the other approaches. It seems that > the primary question about this approach is what runs over the transport > protocol in question; i.e. MIME headers and bodies, pure message/cpim, BEEP, > plain text, etc. > > If anyone feels strongly that we should continue to pursue the use of the > MESSAGE method for direct end-to-end IM signaling, or has input about how > the transport should operate, let's get this discussion underway promptly so > we can meet our projected September deliverables. > > Jon Peterson > NeuStar, Inc > SIMPLE co-chair > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From jdrosen@dynamicsoft.com Mon Aug 20 11:32:27 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00617 for ; Mon, 20 Aug 2001 11:32:26 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KFVcrN029221 for ; Mon, 20 Aug 2001 11:31:38 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 11:32:25 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 20 Aug 2001 11:32:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 606 Subject: [Simple] List is back up... 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: Folks, You may have noticed that the simple list was out of commission for a bit. Turns out that a processor on the machine hosting the list had failed. This has been fixed, and the list is now back up. Sorry for the inconvenience. 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 From rrroy@att.com Mon Aug 20 11:37:44 2001 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 LAA00660 for ; Mon, 20 Aug 2001 11:37:39 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f7KFbUp23446; Mon, 20 Aug 2001 11:37:30 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id LAA05738; Mon, 20 Aug 2001 11:36:08 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 11:37:29 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: "Peterson, Jon" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Charter revisions Date: Mon, 20 Aug 2001 11:37:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3254 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: Hi, Jon: I believe that the SIMPLE WG did a very thorough analysis why the method like MESSAGE is needed in SIP. Following this example, we would expect that this group will do the same in the future for any enhancements in SIP or other protocols. I wonder whether the charter of this group will also include to develop the requirements for any future enhancements that may be needed in SIP or others. Moreover, the requirement documents will help the SIP or other WG members to understand why new extensions are needed without starting the debate all over again. (By the way I do NOT mean that we have to do the same for the MESSAGE method.) Best regards, Radhika R. Roy -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.com] Sent: Monday, August 20, 2001 10:43 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] Charter revisions Greetings to you all, At the meeting in London we premiered a new version of the charter, and received a few comments from various parties on its scope and deliverables. Most significantly, the IESG has decreed that all proposals for the addition of new methods to the SIP standard must be worked through the SIP WG. This means that our current document detailing the MESSAGE method (draft-ietf-simple-im-01) will have to go to the IESG through the SIP WG, and that therefore our deliverables have changed to reflect this new target. I don't believe that the content of the MESSAGE draft will require any unforeseen modifications in order to transition out of the SIMPLE WG. Note that this pertains only to the draft that defines the MESSAGE method; the other drafts in the IM document set (draft-ietf-simple-im-session-00 and draft-ietf-simple-im-sdp-00) will continue to be developed here in SIMPLE. Also, if the definition of any new method is required for presence publication, this too would become the prerogative of the SIP WG. I understand that part of the reason why the IESG has moved method development into the SIP WG is to ensure that each SIP extension doesn't develop its own methods to address a generalizable problem; this suggests that a more general approach to the problem of uploading configuration data from the user agent to various servers may be favored. However, we have kept a deliverable on our charter below to reflect any possible upload mechanism work (some of which may transfer to the SIP WG) including a policy document on the application of a general upload mechanism to the presence publication problem. Jonathan Rosenberg also suggested that we re-order things a bit, as reflected below. Aug 01 Submission of extension for presence to IESG Sep 01 Transfer of MESSAGE definition draft to SIP WG Sep 01 Submission of instant messaging session drafts to IESG Oct 01 Submission of extensions for watcher information to IESG Nov 01 Submission of extension for presence publication to IESG Comments? Suggestions? We'd like to dispatch a final version of this revised charter to the ADs for review before the end of the month. Jon Peterson NeuStar, Inc. SIMPLE co-chair _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From Avshalom@ubique.com Mon Aug 20 12:33:23 2001 Received: from ubqgate02.lotus.com ([194.196.39.62]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00848 for ; Mon, 20 Aug 2001 12:33:18 -0400 (EDT) From: Avshalom@ubique.com Subject: Re: [Simple] Sessions of MESSAGEs To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 20 Aug 2001 19:31:55 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 20/08/2001 19:32:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 4670 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: Assuming that the SIMPLE protocol will develop over time to give the same functionality as current IM systems, the restrictions imposed by inheritance from SIP bother me. What I am bothered about is that SIMPLE inherits the separation between signaling and media of SIP. It assumes a different transport for the signaling and the media. For example, in a conference the signaling (INVITEs/REFERs) should be done on a single TCP connection while a new TCP connection should be created for sending the text messages of the conference. I am not sure if creating a new TCP connection for each IM (when it is done by a session) or conference will scale. Maybe MESSAGE should be allowed to be carried on the same transport as the INVITE message was sent on? -Avshalom Sametime/Lotus "Peterson, Jon" To: "'simple@mailman.dynamicsoft.com'" Sent by: simple-admin@mailman.dynam cc: icsoft.com Subject: [Simple] Sessions of MESSAGEs 20/08/2001 17:47 After the SIMPLE session last week in London, the SIMPLE chairs received some feedback from the IESG with regards to the use of the MESSAGE method end-to-end when an IM session has been established with an INVITE (as described in draft-ietf-simple-im-session-00). The IESG has some concerns that this mechanism constitutes the use of SIP as a transport protocol. In other words, once the session has been established between the two endpoints by the INVITE, if the MESSAGEs can only go directly end-to-end, then their headers and related protocol apparatus are entirely superfluous and may do more harm than good. We saw during the meeting last week that there were definitely some pitfalls to allowing methods other than MESSAGE across the IM stream (as well as questions about overlapping transactions, redirection, forking, and so forth), and it isn't clear that the overhead is justified if MESSAGE is just an envelope for its encapsulated MIME payload. The IESG was particularly concerned, in addition to the protocol overhead, with congestion characteristics of the messaging session and with the precedent that could be set by using SIP in this fashion. For these reasons, the IESG is not inclined to look favorably on that direction for our protocol work. They also weren't enthusiastic about the potential use of RTP text for message transmission (significant concerns were also raised on the floor in London about message framing, especially at CPIM gateways). The recommendation we've been given is to focus on a standard transport protocol with understood congestion properties such as TCP or SCTP. In London, Ben Campbell took an action item to begin investigating alternatives along these lines given the significant concerns that arose on the floor with regards to the other approaches. It seems that the primary question about this approach is what runs over the transport protocol in question; i.e. MIME headers and bodies, pure message/cpim, BEEP, plain text, etc. If anyone feels strongly that we should continue to pursue the use of the MESSAGE method for direct end-to-end IM signaling, or has input about how the transport should operate, let's get this discussion underway promptly so we can meet our projected September deliverables. Jon Peterson NeuStar, Inc SIMPLE co-chair _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From jdrosen@dynamicsoft.com Mon Aug 20 12:50:32 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00922 for ; Mon, 20 Aug 2001 12:50:31 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KGndrN029909; Mon, 20 Aug 2001 12:49:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 12:50:27 -0400 Message-ID: From: Jonathan Rosenberg To: "'Avshalom@ubique.com'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 12:50:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2041 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: > -----Original Message----- > From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] > Sent: Monday, August 20, 2001 12:32 PM > To: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Sessions of MESSAGEs > > > > Assuming that the SIMPLE protocol will develop over time to > give the same > functionality as current IM systems, the > restrictions imposed by inheritance from SIP bother me. > > What I am bothered about is that SIMPLE inherits the > separation between > signaling and media of SIP. It assumes a different transport for the > signaling and the media. For example, in a conference the signaling > (INVITEs/REFERs) should be done on a single TCP connection > while a new TCP > connection should be created for sending the text messages of the > conference. > > I am not sure if creating a new TCP connection for each IM > (when it is done > by a session) or conference will scale. Maybe MESSAGE should > be allowed to > be carried on the same transport as the INVITE message was sent on? Why would you create a new TCP connection for each IM? No one is advocating that. Rather, one would set up an IM "session" with INVITE, just as you would setup an audio session. A TCP/SCTP connection is then established to carry all the IMs within that session, and then torn down when its done. The benefits of such a separation between data and signaling are well known, and include scalability (signaling servers no longer need to see all that voluminous IM traffic, so they scale better), better congestion control, better latency, etc. This is why all other media types are done that way. Can you point out a specific problem with this separation? -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 From zane@mabry.com Mon Aug 20 12:54:38 2001 Received: from mailnw.centurytel.net (mailnw.centurytel.net [209.206.160.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00961 for ; Mon, 20 Aug 2001 12:54:37 -0400 (EDT) Received: from toophat (dsl-209-206-250-63.rb.gh.centurytel.net [209.206.250.63]) by mailnw.centurytel.net (8.11.4/8.11.4) with ESMTP id f7KGsMc25889 for ; Mon, 20 Aug 2001 09:54:22 -0700 (PDT) Message-ID: <0da001c12999$36ebe950$aa00a8c0@toophat> From: "Zane Thomas" To: References: Subject: Re: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 09:57:36 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 1175 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: Avshalom, > What I am bothered about is that SIMPLE inherits the separation between > signaling and media of SIP. From my perspective that's a virtue. It seems to me that SIP has a well-defined purpose; locating peers for the purpose of establishing one or more sessions. I've never liked the idea of extending SIP to serve as a transport for IMs, and particularly as a potential provider of a SIP server I would simply refuse to carry MESSAGEs which may be arbitrarily large and numerous. I'm not interested in paying the costs to carry that traffic for others. I am interested in paying the price required to participate in a distributed peer location system. > I am not sure if creating a new TCP connection for each IM (when it is done > by a session) or conference will scale. You don't *have* to use TCP, it's possible to use UDP with some extra logic layered on top. But when it comes to scaling I wonder exactly what potential problem you're refering to. Any given system can create *many* connections, and when I look at the number of people on my ICQ buddy list the number of TCP connections I'm actually using for IM falls well below that limit. Zane From jdrosen@dynamicsoft.com Mon Aug 20 12:55:35 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00980 for ; Mon, 20 Aug 2001 12:55:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KGskrN029953; Mon, 20 Aug 2001 12:54:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 12:55:34 -0400 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , "Peterson, Jon" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 12:55:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 1930 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: > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, August 20, 2001 10:57 AM > To: Peterson, Jon > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] Sessions of MESSAGEs > > > I assume we would still keep MESSAGE for non-session messaging. After > writing the draft on using MESSAGE in sessions, I am probably its > biggest critic. I think we should abandon that effort completely. I agree. > > As far as the message stream itself, I have heard some > support for the > idea of doing pure message/cpim over TCP and TLS. Personally, this > sounds better the more I think about it. Even that is wasteful, IMHO. CPIM will carry things like the From/To fields, which are superfluous within a session. I think there is only one sensible way to solve this problem. Rather than starting from protocols, lets start from requirements. What do we need this transport to do for us? From there, we can select the option which best meets the requirements. Here is my start: 1. reliable, sequenced delivery of messages 2. support for messages of arbitrary size, from 1 byte to megabytes (think aimster) 3. congestion control 4. framing 5. content typing (text/html, text/plain, etc.) 6. support for e2e privacy, authentication, integrity 7. natability (i.e., can be made to work through nats without major headaches) 8. rapid delivery (one the order of hundreds of milliseconds to a second) 9. relatively lightweight (will need to be implemented in phones and other smaller devices) others, anyone? -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 From ROBERTO@windows.microsoft.com Mon Aug 20 12:56:08 2001 Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA00987 for ; Mon, 20 Aug 2001 12:56:08 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 09:55:15 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 09:55:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 09:55:12 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 09:55:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 09:54:59 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1460F57@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs thread-index: AcEplmsDeTNcLwC8Rn+f8YY9Doiu5AAAaQuQ From: "Robert Osborne" To: , X-OriginalArrivalTime: 20 Aug 2001 16:55:00.0014 (UTC) FILETIME=[D946ACE0:01C12998] Content-Length: 5587 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA00987 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: Hi, I agree with Avshalom that MESSAGE should be allowed to be carried over the normal SIP signalling transport, for several reasons * Creating a seperate TCP connection for a IM Session would be expensive, especially when going across firewalls * Allowing for the MESSAGE to travel along the normal signalling channel improves the authentication and security between domains Rob O >-----Original Message----- >From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] >Sent: Monday, August 20, 2001 9:32 AM >To: simple@mailman.dynamicsoft.com >Subject: Re: [Simple] Sessions of MESSAGEs > > > >Assuming that the SIMPLE protocol will develop over time to >give the same >functionality as current IM systems, the >restrictions imposed by inheritance from SIP bother me. > >What I am bothered about is that SIMPLE inherits the separation between >signaling and media of SIP. It assumes a different transport for the >signaling and the media. For example, in a conference the signaling >(INVITEs/REFERs) should be done on a single TCP connection >while a new TCP >connection should be created for sending the text messages of the >conference. > >I am not sure if creating a new TCP connection for each IM >(when it is done >by a session) or conference will scale. Maybe MESSAGE should >be allowed to >be carried on the same transport as the INVITE message was sent on? > >-Avshalom >Sametime/Lotus > > > > > > "Peterson, Jon" > > To: >"'simple@mailman.dynamicsoft.com'" > Sent by: > > > simple-admin@mailman.dynam cc: > > icsoft.com Subject: > [Simple] Sessions of MESSAGEs > > > > > 20/08/2001 17:47 > > > > > > > > > >After the SIMPLE session last week in London, the SIMPLE >chairs received >some feedback from the IESG with regards to the use of the >MESSAGE method >end-to-end when an IM session has been established with an INVITE (as >described in draft-ietf-simple-im-session-00). > >The IESG has some concerns that this mechanism constitutes the >use of SIP >as >a transport protocol. In other words, once the session has >been established >between the two endpoints by the INVITE, if the MESSAGEs can only go >directly end-to-end, then their headers and related protocol >apparatus are >entirely superfluous and may do more harm than good. We saw during the >meeting last week that there were definitely some pitfalls to allowing >methods other than MESSAGE across the IM stream (as well as >questions about >overlapping transactions, redirection, forking, and so forth), >and it isn't >clear that the overhead is justified if MESSAGE is just an >envelope for its >encapsulated MIME payload. The IESG was particularly >concerned, in addition >to the protocol overhead, with congestion characteristics of >the messaging >session and with the precedent that could be set by using SIP in this >fashion. > >For these reasons, the IESG is not inclined to look favorably on that >direction for our protocol work. They also weren't >enthusiastic about the >potential use of RTP text for message transmission >(significant concerns >were also raised on the floor in London about message framing, >especially >at >CPIM gateways). The recommendation we've been given is to focus on a >standard transport protocol with understood congestion >properties such as >TCP or SCTP. In London, Ben Campbell took an action item to begin >investigating alternatives along these lines given the >significant concerns >that arose on the floor with regards to the other approaches. >It seems that >the primary question about this approach is what runs over the >transport >protocol in question; i.e. MIME headers and bodies, pure message/cpim, >BEEP, >plain text, etc. > >If anyone feels strongly that we should continue to pursue the >use of the >MESSAGE method for direct end-to-end IM signaling, or has >input about how >the transport should operate, let's get this discussion >underway promptly >so >we can meet our projected September deliverables. > >Jon Peterson >NeuStar, Inc >SIMPLE co-chair > >_______________________________________________ >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 bcampbell@dynamicsoft.com Mon Aug 20 13:05:46 2001 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 NAA01083 for ; Mon, 20 Aug 2001 13:05:45 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7KH47t07666; Mon, 20 Aug 2001 12:04:07 -0500 Message-ID: <3B814307.8090904@dynamicsoft.com> Date: Mon, 20 Aug 2001 12:04:07 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Peterson, Jon" , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Sessions of MESSAGEs References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 2140 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: Do we need to select MIME type on a per-message basis, or just once per session? Jonathan Rosenberg wrote: > > > > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, August 20, 2001 10:57 AM >>To: Peterson, Jon >>Cc: 'simple@mailman.dynamicsoft.com' >>Subject: Re: [Simple] Sessions of MESSAGEs >> >> >>I assume we would still keep MESSAGE for non-session messaging. After >>writing the draft on using MESSAGE in sessions, I am probably its >>biggest critic. I think we should abandon that effort completely. >> > > I agree. > > >>As far as the message stream itself, I have heard some >>support for the >>idea of doing pure message/cpim over TCP and TLS. Personally, this >>sounds better the more I think about it. >> > > Even that is wasteful, IMHO. CPIM will carry things like the From/To > fields, which are superfluous within a session. > > I think there is only one sensible way to solve this problem. Rather > than starting from protocols, lets start from requirements. What do we > need this transport to do for us? From there, we can select the option > which best meets the requirements. > > Here is my start: > > 1. reliable, sequenced delivery of messages > 2. support for messages of arbitrary size, from 1 byte to megabytes > (think aimster) > 3. congestion control > 4. framing > 5. content typing (text/html, text/plain, etc.) > 6. support for e2e privacy, authentication, integrity > 7. natability (i.e., can be made to work through nats without major > headaches) > 8. rapid delivery (one the order of hundreds of milliseconds to a > second) > 9. relatively lightweight (will need to be implemented in phones and > other smaller devices) > > others, anyone? > > -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 > > From jon.peterson@NeuStar.com Mon Aug 20 13:11:52 2001 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01131 for ; Mon, 20 Aug 2001 13:11:51 -0400 (EDT) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f7KHAik06234; Mon, 20 Aug 2001 13:10:44 -0400 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 12:09:23 -0500 Message-ID: <70565611B164D511957A001083FCDD56478A56@va02.va.neustar.com> From: "Peterson, Jon" To: "'Robert Osborne'" , Avshalom@ubique.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 12:10:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 6604 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: Again, please do understand that this is not an argument for deprecating the original intended use of MESSAGE within the signaling stream - rather, the consensus of the group (and the will of the IESG) seems to be that the use of MESSAGE directly end-to-end between SIP user agents outside of the conventional signaling stream (aka sessions of MESSAGEs) is wasteful since an INVITE will have already been used to establish a persistent session. Outside of sessions established with an INVITE, MESSAGE will still be permitted in the 'paging' mode for precisely the sorts of architectures that you list below. Jon Peterson NeuStar, Inc -----Original Message----- From: Robert Osborne [mailto:roberto@windows.microsoft.com] Sent: Monday, August 20, 2001 10:55 AM To: Avshalom@ubique.com; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Hi, I agree with Avshalom that MESSAGE should be allowed to be carried over the normal SIP signalling transport, for several reasons * Creating a seperate TCP connection for a IM Session would be expensive, especially when going across firewalls * Allowing for the MESSAGE to travel along the normal signalling channel improves the authentication and security between domains Rob O >-----Original Message----- >From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] >Sent: Monday, August 20, 2001 9:32 AM >To: simple@mailman.dynamicsoft.com >Subject: Re: [Simple] Sessions of MESSAGEs > > > >Assuming that the SIMPLE protocol will develop over time to >give the same >functionality as current IM systems, the >restrictions imposed by inheritance from SIP bother me. > >What I am bothered about is that SIMPLE inherits the separation between >signaling and media of SIP. It assumes a different transport for the >signaling and the media. For example, in a conference the signaling >(INVITEs/REFERs) should be done on a single TCP connection >while a new TCP >connection should be created for sending the text messages of the >conference. > >I am not sure if creating a new TCP connection for each IM >(when it is done >by a session) or conference will scale. Maybe MESSAGE should >be allowed to >be carried on the same transport as the INVITE message was sent on? > >-Avshalom >Sametime/Lotus > > > > > > "Peterson, Jon" > > To: >"'simple@mailman.dynamicsoft.com'" > Sent by: > > > simple-admin@mailman.dynam cc: > > icsoft.com Subject: > [Simple] Sessions of MESSAGEs > > > > > 20/08/2001 17:47 > > > > > > > > > >After the SIMPLE session last week in London, the SIMPLE >chairs received >some feedback from the IESG with regards to the use of the >MESSAGE method >end-to-end when an IM session has been established with an INVITE (as >described in draft-ietf-simple-im-session-00). > >The IESG has some concerns that this mechanism constitutes the >use of SIP >as >a transport protocol. In other words, once the session has >been established >between the two endpoints by the INVITE, if the MESSAGEs can only go >directly end-to-end, then their headers and related protocol >apparatus are >entirely superfluous and may do more harm than good. We saw during the >meeting last week that there were definitely some pitfalls to allowing >methods other than MESSAGE across the IM stream (as well as >questions about >overlapping transactions, redirection, forking, and so forth), >and it isn't >clear that the overhead is justified if MESSAGE is just an >envelope for its >encapsulated MIME payload. The IESG was particularly >concerned, in addition >to the protocol overhead, with congestion characteristics of >the messaging >session and with the precedent that could be set by using SIP in this >fashion. > >For these reasons, the IESG is not inclined to look favorably on that >direction for our protocol work. They also weren't >enthusiastic about the >potential use of RTP text for message transmission >(significant concerns >were also raised on the floor in London about message framing, >especially >at >CPIM gateways). The recommendation we've been given is to focus on a >standard transport protocol with understood congestion >properties such as >TCP or SCTP. In London, Ben Campbell took an action item to begin >investigating alternatives along these lines given the >significant concerns >that arose on the floor with regards to the other approaches. >It seems that >the primary question about this approach is what runs over the >transport >protocol in question; i.e. MIME headers and bodies, pure message/cpim, >BEEP, >plain text, etc. > >If anyone feels strongly that we should continue to pursue the >use of the >MESSAGE method for direct end-to-end IM signaling, or has >input about how >the transport should operate, let's get this discussion >underway promptly >so >we can meet our projected September deliverables. > >Jon Peterson >NeuStar, Inc >SIMPLE co-chair > >_______________________________________________ >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 ROBERTO@windows.microsoft.com Mon Aug 20 13:18:13 2001 Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01233 for ; Mon, 20 Aug 2001 13:18:13 -0400 (EDT) Received: from 157.54.9.100 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 10:17:27 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 10:17:24 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 10:17:16 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 10:17:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 10:17:01 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1460F58@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs thread-index: AcEpmwsonWwFEYCYQ/ey7bMBGl2RmwAAGBjQ From: "Robert Osborne" To: "Peterson, Jon" , , X-OriginalArrivalTime: 20 Aug 2001 17:17:02.0016 (UTC) FILETIME=[ED402C00:01C1299B] Content-Length: 7488 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA01233 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: Actually I was referring to the session of MESSAGEs and not the paging of MESSAGEs. The scenario that always strikes me as being a priority is that a employee of Company A, wishes to communicate with an employee of Company X, who supplies parts to Company A. Irrespective of wether this IM session is paging or not, both employees will want to ensure that it is secure, encrypted and authenticated session that easily traverses firewalls. Rob O >-----Original Message----- >From: Peterson, Jon [mailto:jon.peterson@NeuStar.com] >Sent: Monday, August 20, 2001 10:10 AM >To: Robert Osborne; Avshalom@ubique.com; simple@mailman.dynamicsoft.com >Subject: RE: [Simple] Sessions of MESSAGEs > > >Again, please do understand that this is not an argument for >deprecating the >original intended use of MESSAGE within the signaling stream - >rather, the >consensus of the group (and the will of the IESG) seems to be >that the use >of MESSAGE directly end-to-end between SIP user agents outside of the >conventional signaling stream (aka sessions of MESSAGEs) is >wasteful since >an INVITE will have already been used to establish a >persistent session. >Outside of sessions established with an INVITE, MESSAGE will still be >permitted in the 'paging' mode for precisely the sorts of >architectures that >you list below. > >Jon Peterson >NeuStar, Inc > >-----Original Message----- >From: Robert Osborne [mailto:roberto@windows.microsoft.com] >Sent: Monday, August 20, 2001 10:55 AM >To: Avshalom@ubique.com; simple@mailman.dynamicsoft.com >Subject: RE: [Simple] Sessions of MESSAGEs > > >Hi, > >I agree with Avshalom that MESSAGE should be allowed to be >carried over the normal SIP signalling transport, for several reasons > >* Creating a seperate TCP connection for a IM Session would > be expensive, especially when going across firewalls >* Allowing for the MESSAGE to travel along the normal > signalling channel improves the authentication and > security between domains > >Rob O > >>-----Original Message----- >>From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] >>Sent: Monday, August 20, 2001 9:32 AM >>To: simple@mailman.dynamicsoft.com >>Subject: Re: [Simple] Sessions of MESSAGEs >> >> >> >>Assuming that the SIMPLE protocol will develop over time to >>give the same >>functionality as current IM systems, the >>restrictions imposed by inheritance from SIP bother me. >> >>What I am bothered about is that SIMPLE inherits the >separation between >>signaling and media of SIP. It assumes a different transport for the >>signaling and the media. For example, in a conference the signaling >>(INVITEs/REFERs) should be done on a single TCP connection >>while a new TCP >>connection should be created for sending the text messages of the >>conference. >> >>I am not sure if creating a new TCP connection for each IM >>(when it is done >>by a session) or conference will scale. Maybe MESSAGE should >>be allowed to >>be carried on the same transport as the INVITE message was sent on? >> >>-Avshalom >>Sametime/Lotus >> >> >> >> >> >> "Peterson, Jon" >> >> To: >>"'simple@mailman.dynamicsoft.com'" >> Sent by: >> >> >> simple-admin@mailman.dynam cc: >> >> icsoft.com Subject: >> [Simple] Sessions of MESSAGEs >> >> >> >> >> 20/08/2001 17:47 >> >> >> >> >> >> >> >> >> >>After the SIMPLE session last week in London, the SIMPLE >>chairs received >>some feedback from the IESG with regards to the use of the >>MESSAGE method >>end-to-end when an IM session has been established with an INVITE (as >>described in draft-ietf-simple-im-session-00). >> >>The IESG has some concerns that this mechanism constitutes the >>use of SIP >>as >>a transport protocol. In other words, once the session has >>been established >>between the two endpoints by the INVITE, if the MESSAGEs can only go >>directly end-to-end, then their headers and related protocol >>apparatus are >>entirely superfluous and may do more harm than good. We saw during the >>meeting last week that there were definitely some pitfalls to allowing >>methods other than MESSAGE across the IM stream (as well as >>questions about >>overlapping transactions, redirection, forking, and so forth), >>and it isn't >>clear that the overhead is justified if MESSAGE is just an >>envelope for its >>encapsulated MIME payload. The IESG was particularly >>concerned, in addition >>to the protocol overhead, with congestion characteristics of >>the messaging >>session and with the precedent that could be set by using SIP in this >>fashion. >> >>For these reasons, the IESG is not inclined to look favorably on that >>direction for our protocol work. They also weren't >>enthusiastic about the >>potential use of RTP text for message transmission >>(significant concerns >>were also raised on the floor in London about message framing, >>especially >>at >>CPIM gateways). The recommendation we've been given is to focus on a >>standard transport protocol with understood congestion >>properties such as >>TCP or SCTP. In London, Ben Campbell took an action item to begin >>investigating alternatives along these lines given the >>significant concerns >>that arose on the floor with regards to the other approaches. >>It seems that >>the primary question about this approach is what runs over the >>transport >>protocol in question; i.e. MIME headers and bodies, pure message/cpim, >>BEEP, >>plain text, etc. >> >>If anyone feels strongly that we should continue to pursue the >>use of the >>MESSAGE method for direct end-to-end IM signaling, or has >>input about how >>the transport should operate, let's get this discussion >>underway promptly >>so >>we can meet our projected September deliverables. >> >>Jon Peterson >>NeuStar, Inc >>SIMPLE co-chair >> >>_______________________________________________ >>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 mhammer@cisco.com Mon Aug 20 13:19:10 2001 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 NAA01250 for ; Mon, 20 Aug 2001 13:19:10 -0400 (EDT) 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 NAA09333; Mon, 20 Aug 2001 13:19:09 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-90.cisco.com [161.44.87.90]) by cia.cisco.com (Mirapoint) with ESMTP id AOY00928; Mon, 20 Aug 2001 13:19:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20010820132004.00b2fe18@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Aug 2001 13:22:24 -0400 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] Sessions of MESSAGEs Cc: Ben Campbell , "Peterson, Jon" , "'simple@mailman.dynamicsoft.com'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Length: 2545 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: Jonathan, Based on the other comments about sending MESSAGE over SIP signaling paths, it would then be necessary to segregate and prioritize SIP traffic to prevent 1M IM messages from delaying SIP session setup traffic. We don't need to repeat the problems that GSM systems had with SMS traffic interfering with call setup! Mike At 12:55 PM 8/20/2001 -0400, Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Monday, August 20, 2001 10:57 AM > > To: Peterson, Jon > > Cc: 'simple@mailman.dynamicsoft.com' > > Subject: Re: [Simple] Sessions of MESSAGEs > > > > > > I assume we would still keep MESSAGE for non-session messaging. After > > writing the draft on using MESSAGE in sessions, I am probably its > > biggest critic. I think we should abandon that effort completely. > >I agree. > > > > > As far as the message stream itself, I have heard some > > support for the > > idea of doing pure message/cpim over TCP and TLS. Personally, this > > sounds better the more I think about it. > >Even that is wasteful, IMHO. CPIM will carry things like the From/To fields, >which are superfluous within a session. > >I think there is only one sensible way to solve this problem. Rather than >starting from protocols, lets start from requirements. What do we need this >transport to do for us? From there, we can select the option which best >meets the requirements. > >Here is my start: > >1. reliable, sequenced delivery of messages >2. support for messages of arbitrary size, from 1 byte to megabytes (think >aimster) >3. congestion control >4. framing >5. content typing (text/html, text/plain, etc.) >6. support for e2e privacy, authentication, integrity >7. natability (i.e., can be made to work through nats without major >headaches) >8. rapid delivery (one the order of hundreds of milliseconds to a second) >9. relatively lightweight (will need to be implemented in phones and other >smaller devices) > >others, anyone? > >-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 ajaych@windows.microsoft.com Mon Aug 20 13:44:40 2001 Received: from inet-vrs-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01380 for ; Mon, 20 Aug 2001 13:44:39 -0400 (EDT) Received: from 157.54.1.52 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 10:44:13 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 10:44:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 10:44:12 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 10:44:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 20 Aug 2001 10:44:00 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10145930F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Serializing MESSAGE requests in a session thread-index: AcEmyxhkPuV5FAX2QpKv+biCfgX76ABZcC9wAFu1mcA= From: "Ajay Chitturi" To: X-OriginalArrivalTime: 20 Aug 2001 17:44:00.0498 (UTC) FILETIME=[B1F0ED20:01C1299F] Content-Length: 577 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA01380 Subject: [Simple] Serializing MESSAGE requests in a session 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: Hi, The SIP IM Sessions draft says that MESSAGE requests within message session MUST NOT overlap. I believe this restriction is to prevent the problem where the messages could reach the recipient out of order. Please correct me if I am wrong. The performance issue with this approach is listed as an open issue. Has there been any subsequent discussion on this issue ? Have other approaches to solve this problem been discussed ? Also, this problem is present for other requests such as INFO as well. Are there any such restrictions for such methods as well ? Thanks Ajay. From jdrosen@dynamicsoft.com Mon Aug 20 13:48:48 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01416 for ; Mon, 20 Aug 2001 13:48:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KHlvrN000372; Mon, 20 Aug 2001 13:47:57 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 13:48:45 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Osborne'" , "Peterson, Jon" , Avshalom@ubique.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 13:48:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1567 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: > -----Original Message----- > From: Robert Osborne [mailto:roberto@windows.microsoft.com] > Sent: Monday, August 20, 2001 1:17 PM > To: Peterson, Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > Actually I was referring to the session of MESSAGEs and not the > paging of MESSAGEs. > > The scenario that always strikes me as being a priority is > that a employee > of Company A, wishes to communicate with an employee of > Company X, who supplies > parts to Company A. Irrespective of wether this IM session is > paging or not, > both employees will want to ensure that it is secure, encrypted and > authenticated session that easily traverses firewalls. I agree with those requirements (and in fact included them in my list of requirement), but I do not see why the solution has to be "send IM over the proxy networks". The security story is probably better with the session model, using a separate transport, since you can negotiate session keys e2e for the stream. I agree that the fw/nat traversal is important; I think there are sensible ways to deal with it which do not require using the SIP proxies for message transport. -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 From jdrosen@dynamicsoft.com Mon Aug 20 13:50:04 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01437 for ; Mon, 20 Aug 2001 13:50:04 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KHnFrN000383; Mon, 20 Aug 2001 13:49:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 13:50:03 -0400 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Jonathan Rosenberg Cc: "Peterson, Jon" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 13:50:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 826 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: > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, August 20, 2001 1:04 PM > To: Jonathan Rosenberg > Cc: Peterson, Jon; 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] Sessions of MESSAGEs > > > Do we need to select MIME type on a per-message basis, or > just once per > session? Definitely per-message. Within a conversation, people should be able to send a picture or something like that. -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 From jdrosen@dynamicsoft.com Mon Aug 20 13:52:31 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01471 for ; Mon, 20 Aug 2001 13:52:31 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KHpUrN000409; Mon, 20 Aug 2001 13:51:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 13:52:18 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ajay Chitturi'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Serializing MESSAGE requests in a session Date: Mon, 20 Aug 2001 13:52:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1620 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: > -----Original Message----- > From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] > Sent: Monday, August 20, 2001 1:44 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Serializing MESSAGE requests in a session > > > Hi, > > The SIP IM Sessions draft says that MESSAGE requests within > message session MUST NOT overlap. I believe this restriction > is to prevent the problem where the messages could reach the > recipient out of order. Please correct me if I am wrong. Right; SIP in general has a restriction on non-overlapping non-INVITEs for this reason. > > The performance issue with this approach is listed as an open > issue. Has there been any subsequent discussion on this issue > ? Have other approaches to solve this problem been discussed ? Well, it would seem that the point is more or less moot, if we are not using MESSAGE as a transport for the session model. > > Also, this problem is present for other requests such as INFO > as well. Are there any such restrictions for such methods as well ? We discussed this during the SIP meeting. It was debated whether or not to relax this constraint in general. However, the sequencing becomes harder, and there was no consensus on whether to do this or not. -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 From sdonovan@dynamicsoft.com Mon Aug 20 13:55:13 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01511 for ; Mon, 20 Aug 2001 13:55:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KHsMrN000448; Mon, 20 Aug 2001 13:54:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 13:55:10 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3371E12@DYN-TX-EXCH-001.dynamicsoft.com> From: Steve Donovan To: "'Ajay Chitturi'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Serializing MESSAGE requests in a session Date: Mon, 20 Aug 2001 13:55:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1298 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: The current direction of the group is to not follow the approach defined in the IM session draft. See the thread http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000574.html. The MESSAGE request will still be used for the page like IM, but not for chat sessions. Steve > -----Original Message----- > From: Ajay Chitturi [mailto:ajaych@windows.microsoft.com] > Sent: Monday, August 20, 2001 12:44 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Serializing MESSAGE requests in a session > > > Hi, > > The SIP IM Sessions draft says that MESSAGE requests within > message session MUST NOT overlap. I believe this restriction > is to prevent the problem where the messages could reach the > recipient out of order. Please correct me if I am wrong. > > The performance issue with this approach is listed as an open > issue. Has there been any subsequent discussion on this issue > ? Have other approaches to solve this problem been discussed ? > > Also, this problem is present for other requests such as INFO > as well. Are there any such restrictions for such methods as well ? > > Thanks > Ajay. > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From pkyzivat@cisco.com Mon Aug 20 13:58:04 2001 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 NAA01544 for ; Mon, 20 Aug 2001 13:58:03 -0400 (EDT) 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 f7KHviB01015; Mon, 20 Aug 2001 13:57:44 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAD01607 (AUTH pkyzivat); Mon, 20 Aug 2001 13:58:55 -0400 (EDT) Message-ID: <3B814E34.49D2434F@cisco.com> Date: Mon, 20 Aug 2001 13:51:48 -0400 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 , "Peterson, Jon" , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Sessions of MESSAGEs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1764 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: Comments below. Paul Kyzivat Cisco Systems Jonathan Rosenberg wrote: > > Even that is wasteful, IMHO. CPIM will carry things like the From/To fields, > which are superfluous within a session. > > I think there is only one sensible way to solve this problem. Rather than > starting from protocols, lets start from requirements. What do we need this > transport to do for us? From there, we can select the option which best > meets the requirements. > > Here is my start: > > 1. reliable, sequenced delivery of messages > 2. support for messages of arbitrary size, from 1 byte to megabytes (think aimster) > 3. congestion control > 4. framing > 5. content typing (text/html, text/plain, etc.) > 6. support for e2e privacy, authentication, integrity > 7. natability (i.e., can be made to work through nats without major headaches) > 8. rapid delivery (one the order of hundreds of milliseconds to a second) > 9. relatively lightweight (will need to be implemented in phones and other > smaller devices) > > others, anyone? 10. provision for IM conferences. A primary need here is to permit a media endpoint to act as a mixer. This in turn requires the ability to send messages attributed to others. Encoding the messages as CPIM would seem to provide this capability, while sending raw MIME content would not. Ben Campbell wrote: > > Do we need to select MIME type on a per-message basis, or just once per > session? I think per-message. You may want to intersperse pictures with text, or encoded meta-messages with real text messages. Of course, if you have a rich enough MIME type it can be good enough. For instance, CPIM is rich enough because it can include any other type. But that isn't really any different than selecting MIME type per-message. From jdrosen@dynamicsoft.com Mon Aug 20 14:00:13 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01570 for ; Mon, 20 Aug 2001 14:00:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KHxJrN000510; Mon, 20 Aug 2001 13:59:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 14:00:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'Sriram Parameswar'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF Date: Mon, 20 Aug 2001 14:00:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1796 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: -----Original Message----- >From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] >Sent: Monday, August 20, 2001 10:54 AM >To: 'simple@mailman.dynamicsoft.com' >Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF > > >Hi All, >With regards to the following question and answer (see below) - and my not >being there at the IETF 51, I would be extremely grateful if somebody could >explain the term 'Property-value management mechanism based on content- >disposition.' What this means is that users in a system have configuration parameters that define the service delivered to them. Some of these parameters are values settable by the end user themselves. Examples of such "properties" are the user's CPL script, the presence doc they desire for distribution, their authorization policy, etc. So, it was proposed (and I think there was consensus on) to have a general purpose mechanism in SIP that allows a client to set a particular property. The current CPL upload draft uses Content-Disposition header to indicate the purpose of the upload - setting a CPL script, for example. This could be generalized to support other things, like presence doc uploads. > >I also want to know how this applies to the question of publishing presence >via methods other than REGISTER. Yes, this mechanism would presumably be used for that purpose as well (or, at least, it is my recollection that this was the proposal). -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 From jdrosen@dynamicsoft.com Mon Aug 20 14:04:07 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01615 for ; Mon, 20 Aug 2001 14:04:07 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KI38rN000555; Mon, 20 Aug 2001 14:03:08 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 14:03:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'Paul Kyzivat'" , Jonathan Rosenberg Cc: Ben Campbell , "Peterson, Jon" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 14:03:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2238 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: > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, August 20, 2001 1:52 PM > To: Jonathan Rosenberg > Cc: Ben Campbell; Peterson, Jon; 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] Sessions of MESSAGEs > > > Comments below. > > Paul Kyzivat > Cisco Systems > > Jonathan Rosenberg wrote: > > > > Even that is wasteful, IMHO. CPIM will carry things like > the From/To fields, > > which are superfluous within a session. > > > > I think there is only one sensible way to solve this > problem. Rather than > > starting from protocols, lets start from requirements. What > do we need this > > transport to do for us? From there, we can select the > option which best > > meets the requirements. > > > > Here is my start: > > > > 1. reliable, sequenced delivery of messages > > 2. support for messages of arbitrary size, from 1 byte to > megabytes (think aimster) > > 3. congestion control > > 4. framing > > 5. content typing (text/html, text/plain, etc.) > > 6. support for e2e privacy, authentication, integrity > > 7. natability (i.e., can be made to work through nats > without major headaches) > > 8. rapid delivery (one the order of hundreds of > milliseconds to a second) > > 9. relatively lightweight (will need to be implemented in > phones and other > > smaller devices) > > > > others, anyone? > > 10. provision for IM conferences. A primary need here is to permit a > media endpoint to act as a mixer. This in turn requires the ability to > send messages attributed to others. Encoding the messages as > CPIM would > seem to provide this capability, while sending raw MIME content would > not. Excellent point. This is a capability provided for audio/video through RTCP (the CSRC within the RTP packet indicates who sent the data). We need a rough equivalent here as well, for certain. -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 From roberbr@microsoft.com Mon Aug 20 14:19:41 2001 Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA01694 for ; Mon, 20 Aug 2001 14:19:37 -0400 (EDT) Received: from 157.54.1.52 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 11:18:36 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 11:18:36 -0700 content-class: urn:content-classes:message Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF MIME-Version: 1.0 Date: Mon, 20 Aug 2001 11:18:35 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_004A_01C12969.D8E25120"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320D142@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] draft SIMPLE minutes from 51st IETF Thread-Index: AcEpomiFbAhN9DKlQLCsXHiNFMaBogAAg5fQ From: "Robert Brown" To: "Jonathan Rosenberg" , "Sriram Parameswar" , X-OriginalArrivalTime: 20 Aug 2001 18:18:36.0069 (UTC) FILETIME=[8713ED50:01C129A4] Content-Length: 18742 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: This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C12969.D8E25120 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Would this also be used to authorise watchers? > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, August 20, 2001 11:00 AM > To: 'Sriram Parameswar'; 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF > > > > > -----Original Message----- > >From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] > >Sent: Monday, August 20, 2001 10:54 AM > >To: 'simple@mailman.dynamicsoft.com' > >Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF > > > > > >Hi All, > >With regards to the following question and answer (see below) - and my > not > >being there at the IETF 51, I would be extremely grateful if somebody > could > > >explain the term 'Property-value management mechanism based on content- > >disposition.' > > What this means is that users in a system have configuration parameters > that > define the service delivered to them. Some of these parameters are values > settable by the end user themselves. Examples of such "properties" are the > user's CPL script, the presence doc they desire for distribution, their > authorization policy, etc. So, it was proposed (and I think there was > consensus on) to have a general purpose mechanism in SIP that allows a > client to set a particular property. The current CPL upload draft uses > Content-Disposition header to indicate the purpose of the upload - setting > a > CPL script, for example. This could be generalized to support other > things, > like presence doc uploads. > > > > >I also want to know how this applies to the question of publishing > presence > > >via methods other than REGISTER. > > Yes, this mechanism would presumably be used for that purpose as well (or, > at least, it is my recollection that this was the proposal). > > -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_000_004A_01C12969.D8E25120 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIqDDCCB2ww ggZUoAMCAQICCYpKzgAEAAAa6DANBgkqhkiG9w0BAQUFADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJ VEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1v bmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQg UGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcwOTE3MjUzMVoXDTAyMDEwOTE3MzUzMVowUTES MBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lw aWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtjTd65Df 8iVrq5iSbSg30njDljwoXqEMCBpqB4JdWZ5k+9IF3ordwToVAGxs5mXM9jFcWY8cfbnP6oGtPXcQ f+YzDMwQqQARaxDQ9QFLax8Rw16r5pg3tCK0ZQpOw/M7iegz6I1frUG9VXQGrrnZNYnHmBFNS7Ru lYSKKGoGedMCAwEAAaOCBH4wggR6MB0GA1UdDgQWBBTsnqGiMVuxHoTJ7iR5ApXP/KrDITAfBgNV HSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNVHREEGTAXgRVyb2JlcmJyQG1pY3Jvc29m dC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIw UGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJFRElUR0NBQjA1LENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAs REM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0 Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSggfGGge5sZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUyMEUtTWFpbCUyMENBJTIwMSxDTj1SRURJ VEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDmgN6A1hjNo dHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvbXNwZWNhMS5jcmwwggGDBggr BgEFBQcBAQSCAXUwggFxMIHQBggrBgEFBQcwAoaBw2xkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVy c29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB mwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUucmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5j b20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25kLmNvcnAubWljcm9zb2Z0LmNvbV9NaWNy b3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUyMDEoNCkuY3J0MAwGA1UdEwEB/wQCMAAw CwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAnBgkrBgEEAYI3FAIE Gh4YAEUAeABjAGgAYQBuAGcAZQBVAHMAZQByMA0GCSqGSIb3DQEBBQUAA4IBAQCB0k+uJDbp1E68 bsO+sLj9ByQF3esISCGiP9n7eO6WA/V5sLna4+7wGhOSK+ELvI+muBia4Ib1WrwsXcjE1edy3FGE UTmmOYQhMOeyLwapIHIOEGkDHgWEhEIsrtbUIApMqsl/RmYJoCVI8LFP8cTECqqlkfLOxVW195tT T3fikwuF8xr7Z+NgxzjmbYBWJkabiaoS+H7Kwaodb6HCPJ3TcHVZbbzZPK2nF22Yuj6eOueGwK5U lC/gK5l2kvbMRT9uwS24xt9JoyTJNqSZArCXKB/M3gS4x0oiYtBAI+yzAYRftqXBQGXVtULOaMmx 0lPUeToT57JkGC/vfxj6/WXBMIIHvDCCBqSgAwIBAgIKEDC/8QAEAAAcNzANBgkqhkiG9w0BAQUF ADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcxMjE4 MjE0MFoXDTAyMDExMjE4MzE0MFowUTESMBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0 aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lwaWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAy3lm9JALv4LDed1mg36iAOZHpioL2XED76qNShMdiMcC8i3W+Q03 3J+hxN6yfyoENRVl1tLIWQWVgrQZBtVDnD9LdZMSbER/fKez4FhYcjXdS9YSuAjL7iWAy6H4RGFe /xkNzk+o01J6SxXXbSBIsvF65SHKW8TKNlFmYRjYQD0CAwEAAaOCBM0wggTJMB0GA1UdDgQWBBRK yxFbaT9TWPH1DkqLLMGS8C7kCzAfBgNVHSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNV HREEGTAXgRVyb2JlcmJyQG1pY3Jvc29mdC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB 3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJF RElUR0NBQjA1LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSg gfGGge5sZGFwOi8vY29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUy MEUtTWFpbCUyMENBJTIwMSxDTj1SRURJVEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDmgN6A1hjNodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNwZWNhMS5jcmwwggHABggrBgEFBQcBAQSCAbIwggGuMIHQBggrBgEFBQcwAoaBw2xk YXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBmwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUu cmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25k LmNvcnAubWljcm9zb2Z0LmNvbV9NaWNyb3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUy MDEoNCkuY3J0MDsGCCsGAQUFBzAChi9odHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9tc3BlY2ExLmNydDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwOQYJKwYBBAGCNxQCBCweKgBFAHgAYwBoAGEAbgBnAGUAVQBzAGUAcgBT AGkAZwBuAGEAdAB1AHIAZTANBgkqhkiG9w0BAQUFAAOCAQEAMv7T9pvrp6UXB7O9RFnTSsBuvTBo V97TVmsMf5v4Jex00ggBPBAEDxY+uwryYrQaXCNQk2aIyty7G3/i9M7bK9oynIVzDhjQb48y68t7 MwD2wGC5BhUBuAFs4rIqHIDFoTRPceCLXYDmsx/9P3rzMACc4NO2jshuiwITMHDjrvO1UFvo+Y7y wVrId5WSMbIhvm5xTXvQGbrvDujSKpAkIMLESfXN+2VhWbbH07p1ysQKEv/aUFKHf5zsdDwqCw5+ hOrbCVplYWbbwVLkXicSFWybh11sDt87tM+RM/1ctf8dP6dLibR6PkAEK54+nUVx2MZRxoMgy/Py XsEjvi7M7jCCCFAwggc4oAMCAQICECqYqHcDdOezQZXr4E2bF/YwDQYJKoZIhvcNAQEFBQAwgZ4x ITAfBgkqhkiG9w0BCQEWEnBraXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AldBMRAwDgYDVQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEr MCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0ZSBSb290IEF1dGhvcml0eTAeFw0wMDAyMjUwMTM0 MzlaFw0wODAyMjUwMTQxNTJaMIGeMSEwHwYJKoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20x CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWlj cm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNVBAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBB dXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC271QaJR4cS4M/pGAtU7D1 BUUuMAdaiSwV6lV1OnZ9mLjutGhOXmbiIcestCD1d9hpTOOl6e2TuRo65o4UWEUTAASMUtmLPj9V PVsIP4kx32lW6BhLI6DiAFvL/BrkjOSAibamfUXp/AbCwbX7RQLSf4jZwiQtAYlrPwBr24pMI/WM nJxXlMx/KUsYt627dWkJFkXKVOopS0MdIuYXfz0K6WuSmrLsAbbbuC/kIPBF/SAYJsIs/BGyRmuw yUiWoHDJgi83ZTXSQ1rzSgYhZO9xPL9ZjdI4jeQXIDoCTlIzZyUVbulHzBn58jWbnrSIi2OP7wI/ rxxuBwqjimQlPGZjAgMBAAGjggSGMIIEgjALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQUOYnU1B9o8UWwxpwWxCw6fJ0T50AwggIjBgNVHR8EggIaMIICFjCB5qCB46CB4IaB 3WxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIwUm9vdCUyMEF1dGhvcml0eSxDTj1S RURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMs Q049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIH4oIH1 oIHyhoHvbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUl MjBSb290JTIwQXV0aG9yaXR5LENOPVJFRElUR0NBQTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9z b2Z0LERDPUNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JM RGlzdHJpYnV0aW9uUG9pbnQwMKAuoCyGKmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9tc2NvcnAv bXNjcmExLmNybDAQBgkrBgEEAYI3FQEEAwIBADCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsG AQUFBzAChoHEbGRhcDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9y aXR5LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m aWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8v Y29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRo b3JpdHksQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNv bmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8v d3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IB AQBKfYPOd/2gS3ac9J2sylBGHBlas8dYp6nk+zq3Ml1Pm4L7UkUHTeJW82aPadYbjeWsiHwJgb3A W+YB2iLlKEvvLExH0MOaitwxX5rKDW4G607Yx8KhjE0fK0q3mRd8Xf5zymaxSpKBFSTvh1YI3+WT AiVMSasIr7DuGU0MR4j0DqBE1lHKi60FqCW4kY18oU+jGRQ557DWNi6273zBjY+HH7pB54n8CCFq RNSiStQdu8jlzUCO3eDrEVz9fxRq8T5qrQFod8viyFWLZUZYzWQHibYvKf+aGMGFlRYW2ZP304zI gWcvThTryPsupiHOXGzJZVcybRojwaWdkEkgk7K0MIIIZjCCB06gAwIBAgIKYSDXogAAAAAACjAN BgkqhkiG9w0BAQUFADCBnjEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYD VQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29m dDEMMAoGA1UECxMDSVRHMSswKQYDVQQDEyJNaWNyb3NvZnQgQ29ycG9yYXRlIFJvb3QgQXV0aG9y aXR5MB4XDTAxMDYxODE5NDg0MFoXDTA1MDYxODE5NTg0MFowgZExITAfBgkqhkiG9w0BCQEWEnBr aXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdSZWRt b25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEeMBwGA1UEAxMVTWljcm9zb2Z0 IEV4dHJhbmV0IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw3ayeYZALL1YGLjj t7gEAWw1o2LudM5WWMFCaQtx3gdr4HrZG5064i+ls4UKHjoq8RIz4lnNt/y2qpqpbdT2y8HXICqq SALswJM93//mjtitRwKKKxSd11W1dtKzfbX699za1gP8PUz603wUx+Ojdtwb9HrZcprXAVVt7l+s B+slMjw2el0zqjhUguXbaTbdadMso291Vv3AS3pe+zahIj4RUe8FSu0Rvu5dT91JzDEdPhzC192O PbsQYerq3JDGTBo2dhzkCxolFLjicRmEh48t1PJTR7Tg/QSR/uegAirS/TAg0PJk6Fu7hWepBHzL 80wErx0lqpICzfkUMX2FjwIDAQABo4IErzCCBKswEAYJKwYBBAGCNxUBBAMCAQIwHQYDVR0OBBYE FJl9crx76x52nNzEuwP1X0U2aZX0MAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8EBTADAQH/MB8GA1Ud IwQYMBaAFDmJ1NQfaPFFsMacFsQsOnydE+dAMIICKwYDVR0fBIICIjCCAh4wgeaggeOggeCGgd1s ZGFwOi8vL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049UkVE SVRHQ0FBMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENO PUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCB+KCB9aCB 8oaB72xkYXA6Ly9jb3JwLm1pY3Jvc29mdC5jb20vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIw Um9vdCUyMEF1dGhvcml0eSxDTj1SRURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDigNqA0hjJodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNjcmExLmNybDCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsGAQUFBzAChoHEbGRh cDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9yaXR5LENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049QUlB LENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s REM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8vd3d3Lm1pY3Jvc29m dC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBi7uqxBueATj3M DPlmswvqlWKeuEtaKkI8RKBbFHMAeUIJ+AGoszsUIFsJ3k98kIB29ozHXl7sZoy0zbMMKhOdcyDS 32PvaRwZsFDMF3Kn/uSZjfCrRzB2O/x14j9Oo+fU17IfEBWi7r0Z4wzg/ms0AiVIhbC0a3TBF+uS +e+87SOjXi4FYs9xQPsK5xO0AXVNyyRRzF28eKrdhjCcluby2Vt/OSVutyJE2Nj5ZsrxJjKmLwFy uYojzq6CPdc/BpqOcuyYx6PxKNAR66IM74kIUGkIGdbtyHUxgKfu8c5cQ7UkjtKx1LOLaBQNd0z0 uqvBNce9nkNYFgGECVITNDmvMIIKGjCCCQKgAwIBAgIKYTjfmwACAAAAGjANBgkqhkiG9w0BAQUF ADCBkTEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMR4wHAYDVQQDExVNaWNyb3NvZnQgRXh0cmFuZXQgQ0EwHhcNMDEwNzI3MTc0MDQ1WhcNMDMw NzI3MTc1MDQ1WjCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQG EwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEM MAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxqxYOZd4wOX59OpErK12dai5zHESruOslnVp AWtviLjQJbVRHK5JyZtR4bASg+KWKkcoMXbsqANh1f3laCzfyOcVSb5ks4bMC9CTJZx2L4x4YcWO sJUbJ+xo7QmkxxRde2OBz8xRFSIbqBofj1KwG1LAshnY1qzmW89XHsGfVTkJYlAyH3SUOvV5QMM1 utbONj9A4ibYYeHG+M2qu62dkScRyUZ/yMRPBbivaxINPMnPv0Ni85cgFGfUMvA4yuDuvFaCp0Vp C5Y5WbwK66yZJP3gdPOsmSdHHALlFX02o9MESdpBIrSkz74jpSX0QfmbFx3tHEg1wOurhYd0Ivec vQIDAQABo4IGZjCCBmIwEAYJKwYBBAGCNxUBBAMCAQYwHQYDVR0OBBYEFCenFOBSLgMVjcaskkNk 8J02/IOOMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8E BTADAQH/MIHUBgNVHSMEgcwwgcmAFJl9crx76x52nNzEuwP1X0U2aZX0oYGkpIGhMIGeMSEwHwYJ KoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQ MA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNV BAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBBdXRob3JpdHmCCmEg16IAAAAAAAowggJ9BgNV HR8EggJ0MIICcDCCAmygggJooIICZIaBzmxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwRXh0cmFuZXQl MjBDQSxDTj1SRURJVEdDQUEwMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2Vy dGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50hoHgbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLENOPVJFRElUR0NBQTAzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1T ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnSGMmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL2NybC9tc2VjYTEuY3Jshjto dHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLmNy bIY9ZmlsZTovL1xccmVkaXRnY2FhMDNcQ2VydEVucm9sbFxNaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLmNybDCCApwGCCsGAQUFBwEBBIICjjCCAoowgdQGCCsGAQUFBzAChoHHbGRhcDovL2NvcnAu bWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLENOPUFJQSxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAs REM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPU1pY3Jvc29mdCUyMEV4 dHJhbmV0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5o dHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2VjYTEuY3J0MFYGCCsGAQUFBzAC hkpodHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9yZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBF eHRyYW5ldCUyMENBKDIpLmNydDBYBggrBgEFBQcwAoZMZmlsZTovL1xccmVkaXRnY2FhMDNcQ2Vy dEVucm9sbFxyZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBKDIpLmNydDANBgkq hkiG9w0BAQUFAAOCAQEAPxiA/UabVI27oO7Ub0XffwiBJUPrYCH444I7YLvqfL/cQTMZNUd8g8zc DMntbJRN5fkVFZXma5T8UVXGEFVtrysc5PB63HPbyzBWnGT3U+dHWhkFbUxcuFtCe+s/1Gw2p8rN dUVfhX2IZ4qcS1e7Iydt7OvkIyWlRC/8unOPSVlJGdw1N7wIObuZahO1UIvlNUJjpGoXZ5Q1vW6v D6/QpVx2u/RjlrzfdBapGRC4e8erzwiwrHeQtVUW25QkYyzZvOEc5DHS27YA4OyBkY8cdohq14co O/RNlMpg5orc5DJMLGNNiixwxLnJejf9ldfpGdfXQncaPXgiFtoXvUapuDGCA+cwggPjAgEBMIGq MIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJ VEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25uZWwgRS1NYWlsIENBIDECChAwv/EABAAAHDcw CQYFKw4DAhoFAKCCApIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDEwODIwMTgxODMzWjAjBgkqhkiG9w0BCQQxFgQUwkUCotIH9qYoZ/EBzQLqhpUeaR4wTgYLKoZI hvcNAQkQAgExPzA9BB0AAAAAEAAAAHHBIZ0TzWtHl9PWjtXrXm0BAAAAAIABADAZMBeBFXJvYmVy YnJAbWljcm9zb2Z0LmNvbTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggq hkiG9w0CBTCBugYJKwYBBAGCNxAEMYGsMIGpMIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jv c29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAG A1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25u ZWwgRS1NYWlsIENBIDECCYpKzgAEAAAa6DCBvAYLKoZIhvcNAQkQAgsxgayggakwgZsxITAfBgkq hkiG9w0BCQEWElBLSVRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAw DgYDVQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEoMCYGA1UE AxMfTWljcm9zb2Z0IFBlcnNvbm5lbCBFLU1haWwgQ0EgMQIJikrOAAQAABroMA0GCSqGSIb3DQEB AQUABIGAHXPPa+M7+ARA/qM7RE3jMbUJQoiHYlGtoeaLT8bh5xrMjxv4RRX21yIEe7bTvVrScL4x QgE6ltUUg2HbV70q1b+sH6LENUsjtyRavBxbe7bq+R3UYgI7DyyeDHo4YXwNrWnXCIShghPA+X2p lMjLAWOwyU5wrAGG/nCWw11dV8AAAAAAAAA= ------=_NextPart_000_004A_01C12969.D8E25120-- From ROBERTO@windows.microsoft.com Mon Aug 20 15:47:08 2001 Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA01946 for ; Mon, 20 Aug 2001 15:47:08 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 12:46:06 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 12:46:05 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 12:46:04 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 12:45:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 12:45:51 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC101CFE19F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs thread-index: AcEpoF4CElNN305pR5K/zuQCzV19GwAD44sg From: "Robert Osborne" To: "Jonathan Rosenberg" , "Peterson, Jon" , , X-OriginalArrivalTime: 20 Aug 2001 19:45:52.0060 (UTC) FILETIME=[B7F8BFC0:01C129B0] Content-Length: 2802 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA01946 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: Hi, I still do not understand why we need to force sessions of MESSAGEs to have to go via a special media channel. Using the current draft if you wish to avoid congestion or server load, it is possible for the MESSAGEs to go peer to peer. If there is a firewall in between the peers, then the traffic can be forced to go through the signalling path. By forcing MESSAGEs to always go via a seperate connection we are introducing severe constraints that will block deployment of IM solutions. Why would a company deploy a server to allow for federated presence, have to deploy another server to get the IM through the firewall? In reality they shouldnt need to, they should be able to use the same server. In reality the amount of traffic caused by an IM session is insignificant when compared with that of presence, so why is there such a major concern? Why not force a NOTIFY to have it's own connection? Rob O >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: Monday, August 20, 2001 10:49 AM >To: Robert Osborne; Peterson, Jon; Avshalom@ubique.com; >simple@mailman.dynamicsoft.com >Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > >> -----Original Message----- >> From: Robert Osborne [mailto:roberto@windows.microsoft.com] >> Sent: Monday, August 20, 2001 1:17 PM >> To: Peterson, Jon; Avshalom@ubique.com; >simple@mailman.dynamicsoft.com >> Subject: RE: [Simple] Sessions of MESSAGEs >> >> >> Actually I was referring to the session of MESSAGEs and not the >> paging of MESSAGEs. >> >> The scenario that always strikes me as being a priority is >> that a employee >> of Company A, wishes to communicate with an employee of >> Company X, who supplies >> parts to Company A. Irrespective of wether this IM session is >> paging or not, >> both employees will want to ensure that it is secure, encrypted and >> authenticated session that easily traverses firewalls. > >I agree with those requirements (and in fact included them in >my list of >requirement), but I do not see why the solution has to be >"send IM over the >proxy networks". The security story is probably better with the session >model, using a separate transport, since you can negotiate >session keys e2e >for the stream. I agree that the fw/nat traversal is important; I think >there are sensible ways to deal with it which do not require >using the SIP >proxies for message transport. > >-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 > From zane@mabry.com Mon Aug 20 15:54:51 2001 Received: from mailnw.centurytel.net (mailnw.centurytel.net [209.206.160.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01990 for ; Mon, 20 Aug 2001 15:54:51 -0400 (EDT) Received: from toophat (dsl-209-206-250-63.rb.gh.centurytel.net [209.206.250.63]) by mailnw.centurytel.net (8.11.4/8.11.4) with ESMTP id f7KJslc17771 for ; Mon, 20 Aug 2001 12:54:48 -0700 (PDT) Message-ID: <0ec901c129b2$6b948ea0$aa00a8c0@toophat> From: "Zane Thomas" To: References: <2E33960095B58E40A4D3345AB9F65EC101CFE19F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 12:58:02 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 643 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: Robert, > By forcing MESSAGEs to always go via a seperate connection we are > introducing severe constraints that will block deployment of IM > solutions. Why would a company deploy a server to allow for > federated presence, have to deploy another server to get the IM > through the firewall? In reality they shouldnt need to, they should > be able to use the same server. You're assuming a server-centric model, presence and IM could be carried directly by a peer network having its own builtin firewall solutions. The one thing p2p solutions need is some way to find at least one peer, SIP seems to me to serve that goal nicely. Zane From ROBERTO@windows.microsoft.com Mon Aug 20 17:07:05 2001 Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA02226 for ; Mon, 20 Aug 2001 17:07:04 -0400 (EDT) Received: from 157.54.9.100 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 14:06:43 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 14:06:38 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 14:06:38 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 14:06:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 14:06:25 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC101CFE1A5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs thread-index: AcEpsl0dDrPFTXFaQwGSd9Gupv/QjwACSNwA From: "Robert Osborne" To: "Zane Thomas" , X-OriginalArrivalTime: 20 Aug 2001 21:06:25.0782 (UTC) FILETIME=[F9183160:01C129BB] Content-Length: 1946 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA02226 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: Hi, what peer network are you referring to? I know of no organization that would like the idea of its internal clients IP addresses being revealed to the outside world. Therefore there has to be a server (that may be acting as a proxy) to cross firewalls. If this server has to be there, it might as well be a SIP proxy that allows for the IM traffic to flow using any authenticated connections it has to the destination domain. Of course it could be argued that audio and video have the same issues. However IM is different in that the amount of traffic is causes is significantly less, and users have come accustomed due to MSN Messenger, Yahoo and AOL, that it is possible to send IMs between users within different companies. Therefore I favour the approach that makes it easier for IMs to be sent between domains in a simple fashion. I do not believe creating a special connection for each IM session is simple. Rob O >-----Original Message----- >From: Zane Thomas [mailto:zane@mabry.com] >Sent: Monday, August 20, 2001 12:58 PM >To: simple@mailman.dynamicsoft.com >Subject: Re: [Simple] Sessions of MESSAGEs > > >Robert, > >> By forcing MESSAGEs to always go via a seperate connection we are >> introducing severe constraints that will block deployment of IM >> solutions. Why would a company deploy a server to allow for >> federated presence, have to deploy another server to get the IM >> through the firewall? In reality they shouldnt need to, they should >> be able to use the same server. > >You're assuming a server-centric model, presence and IM could >be carried >directly by a peer network having its own builtin firewall >solutions. The >one thing p2p solutions need is some way to find at least one peer, SIP >seems to me to serve that goal nicely. > >Zane > > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple > From Vasilis.Polychronidis@Openwave.com Mon Aug 20 17:12:33 2001 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 RAA02274 for ; Mon, 20 Aug 2001 17:12:32 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010820211037.TALZ3988.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Mon, 20 Aug 2001 16:10:37 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010820211220.QQAH26952.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Mon, 20 Aug 2001 16:12:20 -0500 Message-ID: <3B817D2F.2B73984F@Openwave.com> Date: Mon, 20 Aug 2001 14:12:15 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Osborne CC: Jonathan Rosenberg , "Peterson, Jon" , Avshalom@ubique.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: <2E33960095B58E40A4D3345AB9F65EC101CFE19F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3750 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: Hi Rob, Reading the mailing list is apparent to me that the consensus in the group is not to use the MESSAGE method and consequently SIP as the transport protocol for IM sessions. I hope the above answer your first question. As far as your second question (about presence events) it seems to me that presence events are more closely related to signaling (SIP) however I agree that they may create congestion issues. I think the group should seriously consider the proposal put forward by Michael Hammer. Personally I think assigning different priorities to presence messages is an excellent idea. BR, -Vasilis Polychronidis Robert Osborne wrote: > Hi, > > I still do not understand why we need to force sessions of > MESSAGEs to have to go via a special media channel. Using the current > draft if you wish to avoid congestion or server load, it is possible > for the MESSAGEs to go peer to peer. If there is a firewall in > between the peers, then the traffic can be forced to go through > the signalling path. > > By forcing MESSAGEs to always go via a seperate connection we are > introducing severe constraints that will block deployment of IM > solutions. Why would a company deploy a server to allow for > federated presence, have to deploy another server to get the IM > through the firewall? In reality they shouldnt need to, they should > be able to use the same server. > > In reality the amount of traffic caused by an IM session is > insignificant when compared with that of presence, so why is there > such a major concern? Why not force a NOTIFY to have it's own > connection? > > Rob O > > >-----Original Message----- > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >Sent: Monday, August 20, 2001 10:49 AM > >To: Robert Osborne; Peterson, Jon; Avshalom@ubique.com; > >simple@mailman.dynamicsoft.com > >Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > > > > > > > > >> -----Original Message----- > >> From: Robert Osborne [mailto:roberto@windows.microsoft.com] > >> Sent: Monday, August 20, 2001 1:17 PM > >> To: Peterson, Jon; Avshalom@ubique.com; > >simple@mailman.dynamicsoft.com > >> Subject: RE: [Simple] Sessions of MESSAGEs > >> > >> > >> Actually I was referring to the session of MESSAGEs and not the > >> paging of MESSAGEs. > >> > >> The scenario that always strikes me as being a priority is > >> that a employee > >> of Company A, wishes to communicate with an employee of > >> Company X, who supplies > >> parts to Company A. Irrespective of wether this IM session is > >> paging or not, > >> both employees will want to ensure that it is secure, encrypted and > >> authenticated session that easily traverses firewalls. > > > >I agree with those requirements (and in fact included them in > >my list of > >requirement), but I do not see why the solution has to be > >"send IM over the > >proxy networks". The security story is probably better with the session > >model, using a separate transport, since you can negotiate > >session keys e2e > >for the stream. I agree that the fw/nat traversal is important; I think > >there are sensible ways to deal with it which do not require > >using the SIP > >proxies for message transport. > > > >-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 Vasilis.Polychronidis@Openwave.com Mon Aug 20 17:25:06 2001 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 RAA02348 for ; Mon, 20 Aug 2001 17:25:06 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010820212310.TNOT3988.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Mon, 20 Aug 2001 16:23:10 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010820212453.QQOS26952.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Mon, 20 Aug 2001 16:24:53 -0500 Message-ID: <3B818021.F5A5BCC9@Openwave.com> Date: Mon, 20 Aug 2001 14:24:49 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Osborne CC: Zane Thomas , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: <2E33960095B58E40A4D3345AB9F65EC101CFE1A5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2494 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: Robert Osborne wrote: > Hi, > > what peer network are you referring to? I know of no organization > that would like the idea of its internal clients IP addresses being > revealed to the outside world. Therefore there has to be a server > (that may be acting as a proxy) to cross firewalls. If this server > has to be there, it might as well be a SIP proxy that allows for > the IM traffic to flow using any authenticated connections it has > to the destination domain. > > Of course it could be argued that audio and video have the same > issues. However IM is different in that the amount of traffic is > causes is significantly less, and users have come accustomed due > to MSN Messenger, Yahoo and AOL, that it is possible to send IMs > between users within different companies. Therefore I favour the > approach that makes it easier for IMs to be sent between domains > in a simple fashion. I do not believe creating a special connection > for each IM session is simple. Why? Hmmm.... TCP or HTTP is not simple?? Most of the commercially deployed IM systems are using TCP or HTTP as their transport. Using TCP or HTTP solves all your firewall issues. IM as a session with a TCP or HTTP transport is the right way moving forward. > > > Rob O > > >-----Original Message----- > >From: Zane Thomas [mailto:zane@mabry.com] > >Sent: Monday, August 20, 2001 12:58 PM > >To: simple@mailman.dynamicsoft.com > >Subject: Re: [Simple] Sessions of MESSAGEs > > > > > >Robert, > > > >> By forcing MESSAGEs to always go via a seperate connection we are > >> introducing severe constraints that will block deployment of IM > >> solutions. Why would a company deploy a server to allow for > >> federated presence, have to deploy another server to get the IM > >> through the firewall? In reality they shouldnt need to, they should > >> be able to use the same server. > > > >You're assuming a server-centric model, presence and IM could > >be carried > >directly by a peer network having its own builtin firewall > >solutions. The > >one thing p2p solutions need is some way to find at least one peer, SIP > >seems to me to serve that goal nicely. > > > >Zane > > > > > >_______________________________________________ > >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 zane@mabry.com Mon Aug 20 18:09:25 2001 Received: from mailnw.centurytel.net (mailnw.centurytel.net [209.206.160.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02507 for ; Mon, 20 Aug 2001 18:09:25 -0400 (EDT) Received: from toophat (dsl-209-206-250-63.rb.gh.centurytel.net [209.206.250.63]) by mailnw.centurytel.net (8.11.4/8.11.4) with ESMTP id f7KM9Ic28266; Mon, 20 Aug 2001 15:09:18 -0700 (PDT) Message-ID: <0f3301c129c5$364f0910$aa00a8c0@toophat> From: "Zane Thomas" To: "Robert Osborne" , References: <2E33960095B58E40A4D3345AB9F65EC101CFE1A5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 15:12:33 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 1775 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: Robert, > what peer network are you referring to? There are a number of p2p networking systems in development, they sometimes have different requirements and goals than server-centric solutions. > I know of no organization > that would like the idea of its internal clients IP addresses being > revealed to the outside world. Knowing internal NATed addresses isn't particularly useful in those situations anyway, because if you're behind one you can't generally arrange to accept incoming connections. However in any self-selected set of cooperating peers there will be some who are not behind organizational firewalls and they can provide proxy services for those who are inside. And there may be simple application-specific proxys which exist as some sort of commercial scheme. The wants of organizations are, of couse, no more important to me then when they wanted to prevent PCs from being widely used. > Therefore there has to be a server > (that may be acting as a proxy) to cross firewalls. If this server > has to be there, it might as well be a SIP proxy that allows for > the IM traffic to flow using any authenticated connections it has > to the destination domain. I understand that as an issue, however I just don't see that opening SIP up as a solution is the right answer. A more generalized proxy scheme which could be used on a box by SIP and by other protocols might make more sense, or so it seems to me. > Of course it could be argued that audio and video have the same > issues. However IM is different in that the amount of traffic is > causes is significantly less ... Each IM requires less bandwidth, but there are a whole lot of them. Does anyone here know how many servers ICQ requires because of its server-centric nature? ZAne From theodore.havinis@openwave.com Mon Aug 20 18:17:15 2001 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 SAA02554 for ; Mon, 20 Aug 2001 18:17:15 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010820221634.CKHY1393.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Mon, 20 Aug 2001 17:16:34 -0500 Received: from tharvinis ([206.35.147.89]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with SMTP id <20010820221610.BFQJ16324.oe-ismta2.bizmailsrvcs.net@tharvinis>; Mon, 20 Aug 2001 17:16:10 -0500 From: "Theodore Havinis" To: "Michael Hammer" , "Jonathan Rosenberg" Cc: "Ben Campbell" , "Peterson, Jon" , Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 15:20:39 -0700 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) In-Reply-To: <4.3.2.7.2.20010820132004.00b2fe18@cia.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Length: 3820 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: One could over-provision with extra C7 signalling trunks and handle the extra traffic created by sms. I think the problem of failure, in my mind arose from the fact, given a single switch, the same connection management software in that same switch handled both call setup and sms setup. That caused congestion, slowing down switches, before anything else. Unfortunately in mobile telephony (GSM) one switch has to handle both sms and calls due to user mobility and also because mobility and connection management is tightly coupled. I think whatever the solution may be, if a single SIP server is used to handle both IM traffic+whatever else, it will inevitably experience congestion. Cheers Theo >-----Original Message----- >From: simple-admin@mailman.dynamicsoft.com >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer >Sent: Monday, August 20, 2001 10:22 AM >To: Jonathan Rosenberg >Cc: Ben Campbell; Peterson, Jon; 'simple@mailman.dynamicsoft.com' >Subject: RE: [Simple] Sessions of MESSAGEs > > >Jonathan, > >Based on the other comments about sending MESSAGE over SIP >signaling paths, >it would then be necessary to segregate and prioritize SIP traffic to >prevent 1M IM messages from delaying SIP session setup traffic. > >We don't need to repeat the problems that GSM systems had with SMS traffic >interfering with call setup! > >Mike > > >At 12:55 PM 8/20/2001 -0400, Jonathan Rosenberg wrote: > > >> >> >> > -----Original Message----- >> > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >> > Sent: Monday, August 20, 2001 10:57 AM >> > To: Peterson, Jon >> > Cc: 'simple@mailman.dynamicsoft.com' >> > Subject: Re: [Simple] Sessions of MESSAGEs >> > >> > >> > I assume we would still keep MESSAGE for non-session messaging. After >> > writing the draft on using MESSAGE in sessions, I am probably its >> > biggest critic. I think we should abandon that effort completely. >> >>I agree. >> >> > >> > As far as the message stream itself, I have heard some >> > support for the >> > idea of doing pure message/cpim over TCP and TLS. Personally, this >> > sounds better the more I think about it. >> >>Even that is wasteful, IMHO. CPIM will carry things like the >From/To fields, >>which are superfluous within a session. >> >>I think there is only one sensible way to solve this problem. Rather than >>starting from protocols, lets start from requirements. What do we >need this >>transport to do for us? From there, we can select the option which best >>meets the requirements. >> >>Here is my start: >> >>1. reliable, sequenced delivery of messages >>2. support for messages of arbitrary size, from 1 byte to megabytes (think >>aimster) >>3. congestion control >>4. framing >>5. content typing (text/html, text/plain, etc.) >>6. support for e2e privacy, authentication, integrity >>7. natability (i.e., can be made to work through nats without major >>headaches) >>8. rapid delivery (one the order of hundreds of milliseconds to a second) >>9. relatively lightweight (will need to be implemented in phones and other >>smaller devices) >> >>others, anyone? >> >>-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 ROBERTO@windows.microsoft.com Mon Aug 20 18:33:23 2001 Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA02619 for ; Mon, 20 Aug 2001 18:33:22 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 15:33:05 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 15:33:05 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 15:32:55 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 15:32:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 15:32:42 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1460F59@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs thread-index: AcEpvo3V1K5gSBlnS568FtWFY1j4zQAB5MVw From: "Robert Osborne" To: "Vasilis Polychronidis" Cc: "Zane Thomas" , X-OriginalArrivalTime: 20 Aug 2001 22:32:42.0795 (UTC) FILETIME=[06D5AFB0:01C129C8] Content-Length: 4152 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA02619 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: >-----Original Message----- >From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com] >Sent: Monday, August 20, 2001 2:25 PM >To: Robert Osborne >Cc: Zane Thomas; simple@mailman.dynamicsoft.com >Subject: Re: [Simple] Sessions of MESSAGEs > > >Robert Osborne wrote: > >> Hi, >> >> what peer network are you referring to? I know of no organization >> that would like the idea of its internal clients IP addresses being >> revealed to the outside world. Therefore there has to be a server >> (that may be acting as a proxy) to cross firewalls. If this server >> has to be there, it might as well be a SIP proxy that allows for >> the IM traffic to flow using any authenticated connections it has >> to the destination domain. >> >> Of course it could be argued that audio and video have the same >> issues. However IM is different in that the amount of traffic is >> causes is significantly less, and users have come accustomed due >> to MSN Messenger, Yahoo and AOL, that it is possible to send IMs >> between users within different companies. Therefore I favour the >> approach that makes it easier for IMs to be sent between domains >> in a simple fashion. I do not believe creating a special connection >> for each IM session is simple. > >Why? >Hmmm.... >TCP or HTTP is not simple?? >Most of the commercially deployed IM systems are using TCP or >HTTP as their >transport. I was not referring to TCP or HTTP causing any complexity (any fool can write Winsock code to create a TCP connection in 5 mins and it would be insulting to suggest that this is complex), but instead to deployment issues that create complexity, such as firewalls. Most deployed IM systems (MSN, Yahoo, AOL) today rely upon one huge cloud living out on the Internet. All clients create an outbound connection to this cloud. I am not an expert in all solutions are out there, but I doubt if there are any that rely upon creating a connection into the client. >Using TCP or HTTP solves all your firewall issues. Actually TCP or HTTP does not solve all my firewall issues in itself. If I wanted to send an IM to yourself, I would first have to negotiate past my local firewall, and then your firewall. I should easily be able to get outside of my firewall (some organizations lock the firewall down on everything but port 80, but lets ignore that for the moment). However, I would be suprised if OpenWave trusts any TCP connection that comes from the internet. I would also be suprised if I am able to directly connect to your client. Therefore there has to be some trusted server that I can connect to within the OpenWave DMZ, which can proxy my IM to yourself. Though it is always possible to create such a "media" proxy I would not call it a simple solution. >IM as a session with a TCP or HTTP transport is the right way moving >forward. > >> >> >> Rob O >> >> >-----Original Message----- >> >From: Zane Thomas [mailto:zane@mabry.com] >> >Sent: Monday, August 20, 2001 12:58 PM >> >To: simple@mailman.dynamicsoft.com >> >Subject: Re: [Simple] Sessions of MESSAGEs >> > >> > >> >Robert, >> > >> >> By forcing MESSAGEs to always go via a seperate connection we are >> >> introducing severe constraints that will block deployment of IM >> >> solutions. Why would a company deploy a server to allow for >> >> federated presence, have to deploy another server to get the IM >> >> through the firewall? In reality they shouldnt need to, >they should >> >> be able to use the same server. >> > >> >You're assuming a server-centric model, presence and IM could >> >be carrid >> >directly by a peer network having its own builtin firewall >> >solutions. The >> >one thing p2p solutions need is some way to find at least >one peer, SIP >> >seems to me to serve that goal nicely. >> > >> >Zane >> > >> > >> >_______________________________________________ >> >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 jdrosen@dynamicsoft.com Mon Aug 20 18:36:21 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02653 for ; Mon, 20 Aug 2001 18:36:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7KMZQrN003045; Mon, 20 Aug 2001 18:35:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 18:36:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'Zane Thomas'" , Robert Osborne , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 18:36:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2983 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: > -----Original Message----- > From: Zane Thomas [mailto:zane@mabry.com] > Sent: Monday, August 20, 2001 6:13 PM > To: Robert Osborne; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Sessions of MESSAGEs > > > > Therefore there has to be a server > > (that may be acting as a proxy) to cross firewalls. If this server > > has to be there, it might as well be a SIP proxy that allows for > > the IM traffic to flow using any authenticated connections it has > > to the destination domain. > > I understand that as an issue, however I just don't see that > opening SIP up > as a solution is the right answer. A more generalized proxy > scheme which > could be used on a box by SIP and by other protocols might > make more sense, > or so it seems to me. Indeed. What you really want is something thats a cross between SOCKS and the "nat detection and allocation protocol" described in draft-rosenberg-sip-entfw-02. Ideally, the client would open a tcp connection to a "refector" server like those described in entfw. After the connection is opened, the client is passed, over that connection, and IP address and TCP port that can be used to receive packets over that connection. The client places that IP address/port in the SDP in their INVITE. If the server receives a TCP connection on the IP/port it passed to the client, it "connects" the two connections, forwarding data on one to the other. Such a server is very simple to build; all it does is pass data from sets of TCP connections that it holds onto. Such a server is reusable for all tcp applications that a provider will want to offer to its customers, including IM but other things as well. Its performance will likely way exceed a SIP proxy, since its doing NOTHING but pure data shuffling. You'd need some capabilities for authentication, so that only users who are really you're customers can connect. But, thats not too hard. Perhaps I should extend the protocol in draft-rosenberg-sip-entfw-02 to cover TCP as well, to provide this service.... Integration with that would be nice. THis way, the intermediary "TCP shuffler" is used only when both are behind a nat. Otherwise, direct communication without any servers can take place. The "detection" bit of the protocol will take care of that case. Another alternative is just a standard VPN, which does the same kind of thing, but at the IP layer. Managing these things at the IP layer is a bit of a pain, though, since the app has no easy way to know to determine which interface is the virtual interface of the vpn, as thats the one whose IP/port it needs to put into the SDP. -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 From zane@mabry.com Mon Aug 20 18:55:24 2001 Received: from mailnw.centurytel.net (mailnw.centurytel.net [209.206.160.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02726 for ; Mon, 20 Aug 2001 18:55:24 -0400 (EDT) Received: from toophat (dsl-209-206-250-63.rb.gh.centurytel.net [209.206.250.63]) by mailnw.centurytel.net (8.11.4/8.11.4) with ESMTP id f7KMtLc02307 for ; Mon, 20 Aug 2001 15:55:21 -0700 (PDT) Message-ID: <0f8a01c129cb$a4ea4140$aa00a8c0@toophat> From: "Zane Thomas" To: References: Subject: Re: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 15:58:36 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 1073 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: Jonathan, > What you really want is something thats a cross between SOCKS and the "nat > detection and allocation protocol" described in > draft-rosenberg-sip-entfw-02. Right, that's in my favorites->programming->protocols->sip and ...->p2p folders. I've been a devoted follower of your work for a while, without of course always agreeing with everything you say. :-) > Such a server is very simple to build; all it does is pass data from sets of > TCP connections that it holds onto. Piece of cake, I wrote one using c# in less than a day a while back. At that time I was just sorta fooling around and decided to conserve resources on the server by including routing headers in my messages so that I could multiplex many-to-one connections internally. Each peer connects to the proxy once, and can then pass messages to all other connected peers. > Perhaps I should extend the protocol in draft-rosenberg-sip-entfw-02 to > cover TCP as well, to provide this service.... Integration with that would > be nice. ... tap, tap, tap ... I'm waiting. Thanks, Zane From Vasilis.Polychronidis@Openwave.com Mon Aug 20 19:54:05 2001 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 TAA02894 for ; Mon, 20 Aug 2001 19:54:00 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010820235214.ZFRH3988.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Mon, 20 Aug 2001 18:52:14 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010820235357.QXBT26952.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Mon, 20 Aug 2001 18:53:57 -0500 Message-ID: <3B81A310.94D06301@Openwave.com> Date: Mon, 20 Aug 2001 16:53:52 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Osborne CC: Zane Thomas , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: <2E33960095B58E40A4D3345AB9F65EC1460F59@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: multipart/alternative; boundary="------------98183B5E397F6E1A92F46F6E" Content-Length: 11081 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: --------------98183B5E397F6E1A92F46F6E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert, Thank you for taking the time to explain to me the NAT issues related to the existing IM systems. I do not disagree with your analysis below however I disagree with you statement that this is not a simple solution. please see my comments below: BR, -Vasilis Polychronidis Robert Osborne wrote: > >-----Original Message----- > >From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com] > >Sent: Monday, August 20, 2001 2:25 PM > >To: Robert Osborne > >Cc: Zane Thomas; simple@mailman.dynamicsoft.com > >Subject: Re: [Simple] Sessions of MESSAGEs > > > > > >Robert Osborne wrote: > > > >> Hi, > >> > >> what peer network are you referring to? I know of no organization > >> that would like the idea of its internal clients IP addresses being > >> revealed to the outside world. Therefore there has to be a server > >> (that may be acting as a proxy) to cross firewalls. If this server > >> has to be there, it might as well be a SIP proxy that allows for > >> the IM traffic to flow using any authenticated connections it has > >> to the destination domain. > >> > >> Of course it could be argued that audio and video have the same > >> issues. However IM is different in that the amount of traffic is > >> causes is significantly less, and users have come accustomed due > >> to MSN Messenger, Yahoo and AOL, that it is possible to send IMs > >> between users within different companies. Therefore I favour the > >> approach that makes it easier for IMs to be sent between domains > >> in a simple fashion. I do not believe creating a special connection > >> for each IM session is simple. > > > >Why? > >Hmmm.... > >TCP or HTTP is not simple?? > >Most of the commercially deployed IM systems are using TCP or > >HTTP as their > >transport. > > I was not referring to TCP or HTTP causing any complexity (any fool > can write Winsock code to create a TCP connection in 5 mins and it > would be insulting to suggest that this is complex), but instead to > deployment issues that create complexity, such as firewalls. > > Most deployed IM systems (MSN, Yahoo, AOL) today rely upon one huge > cloud living out on the Internet. All clients create an outbound > connection to this cloud. I am not an expert in all solutions are out > there, but I doubt if there are any that rely upon creating a connection > into the client. > > >Using TCP or HTTP solves all your firewall issues. > > Actually TCP or HTTP does not solve all my firewall issues in itself. > If I wanted to send an IM to yourself, I would first have to negotiate > past my local firewall, and then your firewall. I should easily be able > to get outside of my firewall (some organizations lock the firewall > down on everything but port 80, but lets ignore that for the moment). > > However, I would be suprised if OpenWave trusts any TCP connection > that comes from the internet. I would also be suprised if I am able > to directly connect to your client. Therefore there has to be > some trusted server that I can connect to within the OpenWave > DMZ, which can proxy my IM to yourself. > > Though it is always possible to create such a "media" proxy I would > not call it a simple solution. Well I do :-) What is simple or is not as objective as we would like to think. After all most of the commercial systems today include (as you clearly explained above) an IM Server (trusted server) and this is how the overcome the NAT issues. > > > >IM as a session with a TCP or HTTP transport is the right way moving > >forward. > > > >> > >> > >> Rob O > >> > >> >-----Original Message----- > >> >From: Zane Thomas [mailto:zane@mabry.com] > >> >Sent: Monday, August 20, 2001 12:58 PM > >> >To: simple@mailman.dynamicsoft.com > >> >Subject: Re: [Simple] Sessions of MESSAGEs > >> > > >> > > >> >Robert, > >> > > >> >> By forcing MESSAGEs to always go via a seperate connection we are > >> >> introducing severe constraints that will block deployment of IM > >> >> solutions. Why would a company deploy a server to allow for > >> >> federated presence, have to deploy another server to get the IM > >> >> through the firewall? In reality they shouldnt need to, > >they should > >> >> be able to use the same server. > >> > > >> >You're assuming a server-centric model, presence and IM could > >> >be carrid > >> >directly by a peer network having its own builtin firewall > >> >solutions. The > >> >one thing p2p solutions need is some way to find at least > >one peer, SIP > >> >seems to me to serve that goal nicely. > >> > > >> >Zane > >> > > >> > > >> >_______________________________________________ > >> >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 > > > > > > > > --------------98183B5E397F6E1A92F46F6E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert,
Thank you for taking the time to explain to me the NAT issues related to the existing IM systems.
I do not disagree with your analysis below however I disagree with you statement
that this is not a simple solution.
please see my comments below:

BR,

-Vasilis Polychronidis

Robert Osborne wrote:

>-----Original Message-----
>From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com]
>Sent: Monday, August 20, 2001 2:25 PM
>To: Robert Osborne
>Cc: Zane Thomas; simple@mailman.dynamicsoft.com
>Subject: Re: [Simple] Sessions of MESSAGEs
>
>
>Robert Osborne wrote:
>
>> Hi,
>>
>> what peer network are you referring to? I know of no organization
>> that would like the idea of its internal clients IP addresses being
>> revealed to the outside world. Therefore there has to be a server
>> (that may be acting as a proxy) to cross firewalls. If this server
>> has to be there, it might as well be a SIP proxy that allows for
>> the IM traffic to flow using any authenticated connections it has
>> to the destination domain.
>>
>> Of course it could be argued that audio and video have the same
>> issues. However IM is different in that the amount of traffic is
>> causes is significantly less, and users have come accustomed due
>> to MSN Messenger, Yahoo and AOL, that it is possible to send IMs
>> between users within different companies. Therefore I favour the
>> approach that makes it easier for IMs to be sent between domains
>> in a simple fashion. I do not believe creating a special connection
>> for each IM session is simple.
>
>Why?
>Hmmm....
>TCP or HTTP is not simple??
>Most of the commercially deployed IM systems are using TCP or
>HTTP as their
>transport.

I was not referring to TCP or HTTP causing any complexity (any fool
can write Winsock code to create a TCP connection in 5 mins and it
would be insulting to suggest that this is complex), but instead to
deployment issues that create complexity, such as firewalls.

Most deployed IM systems (MSN, Yahoo, AOL) today rely upon one huge
cloud living out on the Internet. All clients create an outbound
connection to this cloud. I am not an expert in all solutions are out
there, but I doubt if there are any that rely upon creating a connection
into the client.

>Using TCP or HTTP solves all your firewall issues.

Actually TCP or HTTP does not solve all my firewall issues in itself.
If I wanted to send an IM to yourself, I would first have to negotiate
past my local firewall, and then your firewall. I should easily be able
to get outside of my firewall (some organizations lock the firewall
down on everything but port 80, but lets ignore that for the moment).

However, I would be suprised if OpenWave trusts any TCP connection
that comes from the internet. I would also be suprised if I am able
to directly connect to your client. Therefore there has to be
some trusted server that I can connect to within the OpenWave
DMZ, which can proxy my IM to yourself.

Though it is always possible to create such a "media" proxy I would
not call it a simple solution.

Well I do :-)
What is simple or is not as objective as we would like to think.
After all most of the commercial systems today include (as you clearly explained above)
an IM Server (trusted server) and this is how the overcome the NAT issues.
 

>IM as a session with a TCP or HTTP transport is the right way moving
>forward.
>
>>
>>
>> Rob O
>>
>> >-----Original Message-----
>> >From: Zane Thomas [mailto:zane@mabry.com]
>> >Sent: Monday, August 20, 2001 12:58 PM
>> >To: simple@mailman.dynamicsoft.com
>> >Subject: Re: [Simple] Sessions of MESSAGEs
>> >
>> >
>> >Robert,
>> >
>> >> By forcing MESSAGEs to always go via a seperate connection we are
>> >> introducing severe constraints that will block deployment of IM
>> >> solutions. Why would a company deploy a server to allow for
>> >> federated presence, have to deploy another server to get the IM
>> >> through the firewall? In reality they shouldnt need to,
>they should
>> >> be able to use the same server.
>> >
>> >You're assuming a server-centric model, presence and IM could
>> >be carrid
>> >directly by a peer network having its own builtin firewall
>> >solutions.  The
>> >one thing p2p solutions need is some way to find at least
>one peer, SIP
>> >seems to me to serve that goal nicely.
>> >
>> >Zane
>> >
>> >
>> >_______________________________________________
>> >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
>
>
>
>

--------------98183B5E397F6E1A92F46F6E-- From cjjj012001@hotmail.comrrq Mon Aug 20 20:43:52 2001 Received: from ips-city.com (dmn217.radiks.net [205.216.90.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id UAA03062 for ; Mon, 20 Aug 2001 20:43:47 -0400 (EDT) Message-Id: <200108210043.UAA03062@mailman.dynamicsoft.com> From: "Joel Jeffries" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 20 Aug 2001 19:41:46 -0500 Content-Transfer-Encoding: 8bit Content-Length: 15051 Subject: [Simple] (no subject) 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: YOU MUST READ THIS!!!!--Pleasd don't delete till you Read It!--adv If you do not wish to receive further emails of this type, please send a blank email with remove in the subject line to: jcppoorman2001@hotmail.com Hi, I hope this will be of interest to you..... Dear Friend and Future Millionaire, AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time THANKS TO THE COMPUTER AGE AND THE INTERNET! ===================================================== = BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money.\\~ The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can -follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: '' Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required.To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. ===================================================== == Here is another testimonial: ''' this program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, ===== PRINT THIS NOW FOR YOUR FUTUREREFERENCE ======== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$ $ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: =====Order all 5 reports shown on the list below ===== For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person  whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURNADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. === When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your disk in case something happens to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will lose out on the majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, andif you alter it, it will NOT work !!! People have tried to puttheir friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2. 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ===================================================== ======== **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you lose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally,where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1: BY SENDING BULK E-MAIL LEGALLY ===================================================== ======== Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that through mailing you receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands of e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That is:100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3.....$5,000 + 4..... $50,000 + 5..... $500,000 ........ .....Grand Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ===================================================== ======== REMEMBER, THIS IS ASSUMING ONLY 10 PEOPLE ORDER OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if  half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET ===================================================== ======== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. ===========AVAILABLE REPORTS ==================== ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ===================================================== ===== REPORT # 1: 'The Insider's Guide to Advertising for Free on the Net Order Report #1 from: J. Jeffries 4515 Franklin ave. Des Moines, IA 50310 USA _____________________________________________________ ___ REPORT # 2: The Insider's Guide to Sending Bulk e-mail on the Net Order Report # 2 from: D. WARKE 15 Porritt Avenue Mt Victoria Wellington New Zealand _____________________________________________________ ____________ REPORT # 3: Secret to Multilevel marketing on the net Order Report # 3 from : D. FERNANDEZ 414 Phillip St Vallejo, CA 94590 USA _____________________________________________________ ____________ REPORT # 4: How to become a millionaire utilizing MLM & the Net Order Report # 4 from:   S. Williams 1025 River Road Modesto, CA  95351-4107 USA _____________________________________________________ ___________ REPORT #5: How to send out one Million e-mails for free Order Report # 5 From: S. Gabriel P.O.Box 818 Vallejo, CA  94590 USA _____________________________________________________ ___________ If you would like to contact me with any questions, you can at cjjj012001@hotmail.com $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. === Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCES AGAIN. There is NO LIMIT to the income you can generate from this business !!! ===================================================== ======== FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! ======================== MORE TESTIMONIALS =================== '' My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ===================================================== ======== '' Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''. Dan Sondstrom, Alberta, Canada ===================================================== ======== '' I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''. Susan De Suza, New York, N.Y. ===================================================== ======== '' It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20, 560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful,Thanx to internet''. Fred Dellaca, Westport, New Zealand ===================================================== ======== ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ===================================================== ======== If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices,Federal Trade Commission,Bureau of Consumer Protection, Washington, D.C. From jdrosen@dynamicsoft.com Mon Aug 20 23:07:38 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03478 for ; Mon, 20 Aug 2001 23:07:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7L36SrN003808; Mon, 20 Aug 2001 23:06:29 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 23:07:15 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Jonathan Rosenberg , Sriram Parameswar , simple@mailman.dynamicsoft.com Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF Date: Mon, 20 Aug 2001 23:07:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 1320 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Monday, August 20, 2001 2:19 PM > To: Jonathan Rosenberg; Sriram Parameswar; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF > > > Would this also be used to authorise watchers? It would be used to upload authorization documents, yes. -Jonathan R. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Monday, August 20, 2001 11:00 AM > > To: 'Sriram Parameswar'; 'simple@mailman.dynamicsoft.com' > > Subject: RE: [Simple] draft SIMPLE minutes from 51st IETF > > > > > > > >I also want to know how this applies to the question of publishing > > presence > > > > >via methods other than REGISTER. > > > > Yes, this mechanism would presumably be used for that > purpose as well > (or, > > at least, it is my recollection that this was the proposal). > > > > -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 From jdrosen@dynamicsoft.com Mon Aug 20 23:48:28 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03605 for ; Mon, 20 Aug 2001 23:48:27 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7L3lbrN003917; Mon, 20 Aug 2001 23:47:38 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 23:48:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Preference for Individual URI Date: Mon, 20 Aug 2001 23:48:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3923 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: -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Friday, August 10, 2001 3:36 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] Preference for Individual URI >All, >In section "5.1 Contact, Accept-Contact and Reject-Contact Parameters" of the >draft-ietf-sip-callerprefs-04.txt it states that the Methods parameter, >Description parameter, and priority parameter for a contact header are NOT >used in the matching operation described in Section 6.4.1 of the same draft. >In addition, the contact URI comparison is based on SIP URI matching rules. >This implies that in the following example described in the draft-ietf-simple- >presence-01.txt, the second contact: >;methods="SUBSCRIBE" will completely *REPLACE* the >first contact: ;methods=MESSAGE;description="open" due >to the fact that the contact URI is the same for >both: > REGISTER sip:example.com SIP/2.0 > Via: SIP/2.0/UDP pua.example.com:5060 > To: > From: > Call-ID: 2818@pua.example.com > CSeq: 1 REGISTER > Contact: ;methods="MESSAGE" > ;description="open" > Contact: ;methods="SUBSCRIBE" > Expires: 600 Excellent observation. You are correct. > >So if I'm login into a computer and have one SIP URI , >the only choice I have is to send a REGISTER with: > contact: ;methods="MESSAGE, >SUBSCRIBE";description="open". Yes. > >Now, later, I want to continue receiving SUBSCRIBEs (description="open") but >not to receive MESSAGEs (description="close"). What options do I have besides >having to have two different sip contact URIs? Well, this depends on whether you interpret the description param as indicating open/closed. I don't think thats the right mapping, since description is a textual phrase. I think that maps to the element in draft-ietf-impp-cpim-pidf-00.txt. So, if you want to cease receiving IM, you would REGISTER the following: REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: From: Call-ID: 2818@pua.example.com CSeq: 1 REGISTER Contact: ;methods="SUBSCRIBE" Expires: 600 i.e., MESSAGE is no longer listed as an allowed method. Now, there is an important process question here to be answered. What do we, or do we not, say about mapping registered information to presence documents? Is this purely implementation choice? Is this part of the core presence specification? I think that we should not say anything about it. Presence documents can be constructed from a large variety of sources, only one of which is registrations. How the document is constructed is really a local implementation choice. Now, interop issues do arise when a client wants to achieve a particular effect in the presence document. For example, Dai is concerned above about how a client can achieve the result of indicating a particular communications means is closed. I think that if a client wants direct controls over presence documents, it should directly control them. That is, it should upload a presence document directly, rather than guessing at server interpretation of the registered contacts and its impact on the presence document. -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 From ROBERTO@windows.microsoft.com Mon Aug 20 23:53:45 2001 Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id XAA03643 for ; Mon, 20 Aug 2001 23:53:44 -0400 (EDT) Received: from 157.54.1.52 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 20:53:31 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 20:53:31 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 20:53:30 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 20:53:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 20:53:17 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1460F5A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs thread-index: AcEp016YZehlXJmEQo6QXnJeByw/jQAHs7Fg From: "Robert Osborne" To: "Vasilis Polychronidis" Cc: "Zane Thomas" , X-OriginalArrivalTime: 21 Aug 2001 03:53:17.0701 (UTC) FILETIME=[CFBB6B50:01C129F4] Content-Length: 16995 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: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C129F4.CF696A54" ------_=_NextPart_001_01C129F4.CF696A54 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com] Sent: Monday, August 20, 2001 4:54 PM To: Robert Osborne Cc: Zane Thomas; simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs Hi Robert,=20 Thank you for taking the time to explain to me the NAT issues related to = the existing IM systems.=20 I do not disagree with your analysis below however I disagree with you = statement=20 that this is not a simple solution. =20 [Robert Osborne] I assume you meant you agree with my analysis, but not = statement on simplicity please see my comments below:=20 BR,=20 -Vasilis Polychronidis=20 Robert Osborne wrote:=20 >-----Original Message-----=20 >From: Vasilis Polychronidis [ = mailto:Vasilis.Polychronidis@Openwave.com]=20 >Sent: Monday, August 20, 2001 2:25 PM=20 >To: Robert Osborne=20 >Cc: Zane Thomas; simple@mailman.dynamicsoft.com=20 >Subject: Re: [Simple] Sessions of MESSAGEs=20 >=20 >=20 >Robert Osborne wrote:=20 >=20 >> Hi,=20 >>=20 >> what peer network are you referring to? I know of no organization=20 >> that would like the idea of its internal clients IP addresses being=20 >> revealed to the outside world. Therefore there has to be a server=20 >> (that may be acting as a proxy) to cross firewalls. If this server=20 >> has to be there, it might as well be a SIP proxy that allows for=20 >> the IM traffic to flow using any authenticated connections it has=20 >> to the destination domain.=20 >>=20 >> Of course it could be argued that audio and video have the same=20 >> issues. However IM is different in that the amount of traffic is=20 >> causes is significantly less, and users have come accustomed due=20 >> to MSN Messenger, Yahoo and AOL, that it is possible to send IMs=20 >> between users within different companies. Therefore I favour the=20 >> approach that makes it easier for IMs to be sent between domains=20 >> in a simple fashion. I do not believe creating a special connection=20 >> for each IM session is simple.=20 >=20 >Why?=20 >Hmmm....=20 >TCP or HTTP is not simple??=20 >Most of the commercially deployed IM systems are using TCP or=20 >HTTP as their=20 >transport.=20 I was not referring to TCP or HTTP causing any complexity (any fool=20 can write Winsock code to create a TCP connection in 5 mins and it=20 would be insulting to suggest that this is complex), but instead to=20 deployment issues that create complexity, such as firewalls.=20 Most deployed IM systems (MSN, Yahoo, AOL) today rely upon one huge=20 cloud living out on the Internet. All clients create an outbound=20 connection to this cloud. I am not an expert in all solutions are out=20 there, but I doubt if there are any that rely upon creating a connection = into the client.=20 >Using TCP or HTTP solves all your firewall issues.=20 Actually TCP or HTTP does not solve all my firewall issues in itself.=20 If I wanted to send an IM to yourself, I would first have to negotiate=20 past my local firewall, and then your firewall. I should easily be able=20 to get outside of my firewall (some organizations lock the firewall=20 down on everything but port 80, but lets ignore that for the moment).=20 However, I would be suprised if OpenWave trusts any TCP connection=20 that comes from the internet. I would also be suprised if I am able=20 to directly connect to your client. Therefore there has to be=20 some trusted server that I can connect to within the OpenWave=20 DMZ, which can proxy my IM to yourself.=20 Though it is always possible to create such a "media" proxy I would=20 not call it a simple solution. Well I do :-)=20 What is simple or is not as objective as we would like to think.=20 After all most of the commercial systems today include (as you clearly = explained above)=20 an IM Server (trusted server) and this is how the overcome the NAT = issues.=20 =20 [Robert Osborne] Ok, so lets agree to disagree on the simplicity, but = agree that a server is required at the domain's edge. =20 My question is, how would you expect this server to work, particularly = in the following area: =20 1) How would user X within domain X ensure that the local server is = aware that a session with user A in domain A has been created. 2) How would the server know that a particular TCP connection from = domain A actually maps into a session with user X within the domain 3) How would the server authenticate that the TCP connection is = actually from user A within domain A 4) How does the server become aware that user X no longer wishes to = receive traffic for this session (ie user has closed IM window =20 >IM as a session with a TCP or HTTP transport is the right way moving=20 >forward.=20 >=20 >>=20 >>=20 >> Rob O=20 >>=20 >> >-----Original Message-----=20 >> >From: Zane Thomas [ mailto:zane@mabry.com]=20 >> >Sent: Monday, August 20, 2001 12:58 PM=20 >> >To: simple@mailman.dynamicsoft.com=20 >> >Subject: Re: [Simple] Sessions of MESSAGEs=20 >> >=20 >> >=20 >> >Robert,=20 >> >=20 >> >> By forcing MESSAGEs to always go via a seperate connection we are=20 >> >> introducing severe constraints that will block deployment of IM=20 >> >> solutions. Why would a company deploy a server to allow for=20 >> >> federated presence, have to deploy another server to get the IM=20 >> >> through the firewall? In reality they shouldnt need to,=20 >they should=20 >> >> be able to use the same server.=20 >> >=20 >> >You're assuming a server-centric model, presence and IM could=20 >> >be carrid=20 >> >directly by a peer network having its own builtin firewall=20 >> >solutions. The=20 >> >one thing p2p solutions need is some way to find at least=20 >one peer, SIP=20 >> >seems to me to serve that goal nicely.=20 >> >=20 >> >Zane=20 >> >=20 >> >=20 >> >_______________________________________________=20 >> >simple mailing list=20 >> >simple@mailman.dynamicsoft.com=20 >> > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20 >> >=20 >> _______________________________________________=20 >> simple mailing list=20 >> simple@mailman.dynamicsoft.com=20 >> http://mailman.dynamicsoft.com/mailman/listinfo/simple=20 >=20 >=20 >=20 > ------_=_NextPart_001_01C129F4.CF696A54 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
-----Original Message-----
From: Vasilis = Polychronidis=20 [mailto:Vasilis.Polychronidis@Openwave.com]
Sent: Monday, = August 20,=20 2001 4:54 PM
To: Robert Osborne
Cc: Zane Thomas;=20 simple@mailman.dynamicsoft.com
Subject: Re: [Simple] = Sessions of=20 MESSAGEs

Hi Robert,
Thank you=20 for taking the time to explain to me the NAT issues related to the = existing IM=20 systems.
I do not disagree with your = analysis=20 below however I disagree with you statement
that this is not a simple solution.
 
[Robert Osborne]  I = assume you meant=20 you agree with my analysis, but not statement on=20 simplicity

please see my = comments=20 below:

BR,=20

-Vasilis Polychronidis=20

Robert Osborne wrote:=20

>-----Original Message-----
>From: = Vasilis=20 Polychronidis [mailto:Vasilis.Polychr= onidis@Openwave.com]=20
>Sent: Monday, August 20, 2001 2:25 PM
>To: Robert = Osborne=20
>Cc: Zane Thomas; simple@mailman.dynamicsoft.com =
>Subject: Re:=20 [Simple] Sessions of MESSAGEs
>
>
>Robert = Osborne=20 wrote:
>
>> Hi,
>>
>> what peer = network=20 are you referring to? I know of no organization
>> that = would like=20 the idea of its internal clients IP addresses being
>> = revealed to=20 the outside world. Therefore there has to be a server
>> = (that may=20 be acting as a proxy) to cross firewalls. If this server =
>> has to=20 be there, it might as well be a SIP proxy that allows for =
>> the=20 IM traffic to flow using any authenticated connections it has =
>>=20 to the destination domain.
>>
>> Of course it = could be=20 argued that audio and video have the same
>> issues. = However IM is=20 different in that the amount of traffic is
>> causes is=20 significantly less, and users have come accustomed due
>> = to MSN=20 Messenger, Yahoo and AOL, that it is possible to send IMs =
>>=20 between users within different companies. Therefore I favour the=20
>> approach that makes it easier for IMs to be sent = between=20 domains
>> in a simple fashion. I do not believe creating = a=20 special connection
>> for each IM session is simple. =
>=20
>Why?
>Hmmm....
>TCP or HTTP is not simple??=20
>Most of the commercially deployed IM systems are using TCP = or=20
>HTTP as their
>transport.=20

I was not referring to TCP or HTTP causing any complexity (any = fool=20
can write Winsock code to create a TCP connection in 5 mins and = it=20
would be insulting to suggest that this is complex), but instead = to=20
deployment issues that create complexity, such as firewalls.=20

Most deployed IM systems (MSN, Yahoo, AOL) today rely upon one = huge=20
cloud living out on the Internet. All clients create an outbound =
connection to this cloud. I am not an expert in all solutions = are out=20
there, but I doubt if there are any that rely upon creating a = connection=20
into the client.=20

>Using TCP or HTTP solves all your firewall issues.=20

Actually TCP or HTTP does not solve all my firewall issues in = itself.=20
If I wanted to send an IM to yourself, I would first have to = negotiate=20
past my local firewall, and then your firewall. I should easily = be able=20
to get outside of my firewall (some organizations lock the = firewall=20
down on everything but port 80, but lets ignore that for the = moment).=20

However, I would be suprised if OpenWave trusts any TCP = connection=20
that comes from the internet. I would also be suprised if I am = able=20
to directly connect to your client. Therefore there has to be =
some=20 trusted server that I can connect to within the OpenWave
DMZ, = which can=20 proxy my IM to yourself.=20

Though it is always possible to create such a "media" proxy I = would=20
not call it a simple solution.

Well I do :-)
What is=20 simple or is not as objective as we would like to think. =
After all most of the commercial systems today include = (as you=20 clearly explained above)
an IM Server = (trusted=20 server) and this is how the overcome the NAT = issues. 
 
[Robert Osborne]  Ok, so lets agree = to disagree=20 on the simplicity, but agree that a server is required at the domain's = edge.
 
My=20 question is, how would you expect this server to work, particularly in = the=20 following area:
 
1)    How would user X within domain X ensure = that the=20 local server is aware that a session with user A in domain A has been=20 created.
2)    How would the server know that = a=20 particular TCP connection from domain A actually maps into a session = with user=20 X within the domain
3)    How would the = server authenticate that=20 the TCP connection is actually from user A within domain = A
4)    How does the server become aware that = user X no=20 longer wishes to receive traffic for this session (ie user has closed = IM=20 window 

>IM as a session with a TCP or HTTP transport is the right way = moving=20
>forward.
>
>>
>>
>> Rob = O=20
>>
>> >-----Original Message----- =
>>=20 >From: Zane Thomas [mailto:zane@mabry.com] =
>>=20 >Sent: Monday, August 20, 2001 12:58 PM
>> >To:=20 simple@mailman.dynamicsoft.com
>> >Subject: Re: = [Simple]=20 Sessions of MESSAGEs
>> >
>> > =
>>=20 >Robert,
>> >
>> >> By forcing = MESSAGEs to=20 always go via a seperate connection we are
>> >> = introducing=20 severe constraints that will block deployment of IM
>> = >>=20 solutions. Why would a company deploy a server to allow for =
>>=20 >> federated presence, have to deploy another server to get = the IM=20
>> >> through the firewall? In reality they shouldnt = need=20 to,
>they should
>> >> be able to use the = same=20 server.
>> >
>> >You're assuming a = server-centric=20 model, presence and IM could
>> >be carrid
>> = >directly by a peer network having its own builtin firewall =
>>=20 >solutions.  The
>> >one thing p2p solutions = need is=20 some way to find at least
>one peer, SIP
>> = >seems to me=20 to serve that goal nicely.
>> >
>> >Zane=20
>> >
>> >
>>=20 >_______________________________________________
>> = >simple=20 mailing list
>> >simple@mailman.dynamicsoft.com =
>>=20 >http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple=20
>> >
>>=20 _______________________________________________
>> simple = mailing=20 list
>> simple@mailman.dynamicsoft.com
>> http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple=20
>
>
> =
>

------_=_NextPart_001_01C129F4.CF696A54-- --------------InterScan_NT_MIME_Boundary-- From jdrosen@dynamicsoft.com Mon Aug 20 23:55:19 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03664 for ; Mon, 20 Aug 2001 23:55:18 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7L3sLrN003937; Mon, 20 Aug 2001 23:54:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 23:55:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Arnaud Weil'" , Tony Hansen , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Why do we need Presence Caching? Date: Mon, 20 Aug 2001 23:55:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1885 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: > -----Original Message----- > From: Arnaud Weil [mailto:Arnaud.Weil@winwise.com] > Sent: Thursday, August 09, 2001 5:45 AM > To: Tony Hansen; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Why do we need Presence Caching? > > > Still, this answer doesn't seem very satisfying to me. RFC 2779 states > that: > > 5.3.1. The protocol MUST provide A means of verifying that the > presence information is accurate, as sent by B. > > 5.3.3. The protocol MUST provide A means of verifying that the > notification was sent by B. > > To me, this means that such functionnalities must be > implemented in the > protocol itself, so your idea of SIMPLE relying on a > pre-existent trust > relationship doesn't meet such requirements. Am I wrong about this? No, I think the requirements do point to a need for e2e authentication and message integrity. RFC2543 can provide such a thing using PGP, which does convey authentication and integrity information e2e. However, PGP usage has been deprecated in the bis version of rfc2543, in favor of a more usable and broadly applicable security mechanism. That mechanism is still being ironed out in the sip wg. The first cut is described in: http://search.ietf.org/internet-drafts/draft-thomas-sip-sec-framework-00.txt e2e authentication and encryption between end users is a really, really hard problem, for which a usefully deployable solution is quite elusive. Thats true for SIP and for all other protocols in a similar boat, as far as I can tell. -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 From dean.willis@softarmor.com Tue Aug 21 00:23:48 2001 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 AAA03790 for ; Tue, 21 Aug 2001 00:23:46 -0400 (EDT) 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 f7L4OWR13401 for ; Mon, 20 Aug 2001 23:24:32 -0500 Message-ID: <01ab01c129f8$c9a0ee80$55fa403f@blazer> From: "Dean Willis" To: References: <2E33960095B58E40A4D3345AB9F65EC1460F57@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: [Simple] Sessions of MESSAGEs Date: Mon, 20 Aug 2001 23:21:44 -0500 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Length: 6494 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: Ok, there's THREE topics: 1) MESSAGE sessions established directly between two nodes using SIP which is routed by proxies. 2) MESSAGE transmissions outside of a session routed by proxies ("Pager mode") 3) MESSAGE sessions between two nodes, where those messages are routed by proxies using the routing semantics of any other SIP message. Oddly enough, this begins to look a lot like BXXP. We're debating #1 here. #2 is still in the work plan. As for #3, I like it -- I think it has a lot of advantages, and Robert has definitely hit on some of them. But not all .For example, at some point, we'll have the same kind of "privacy" concerns with message routing as we now have with call routing. We'll want suppression of source location information, network-authenticated remote-party-ID, the Privacy: header and its accompanying semantics, etc. Guess what? We've already figured those out for SIP "system" messaging, for the most part. Why not re-use the infrastructure for "user" messaging? Sure it'll create server overhead. But it will work the way we need it to work. You get what you pay for. On the other hand, do we really need a "message session", or are serialized "pager messages" with retransmission and in-order assembly by the application good enough? -- Dean ----- Original Message ----- From: "Robert Osborne" To: ; Sent: Monday, August 20, 2001 11:54 AM Subject: RE: [Simple] Sessions of MESSAGEs > Hi, > > I agree with Avshalom that MESSAGE should be allowed to be > carried over the normal SIP signalling transport, for several reasons > > * Creating a seperate TCP connection for a IM Session would > be expensive, especially when going across firewalls > * Allowing for the MESSAGE to travel along the normal > signalling channel improves the authentication and > security between domains > > Rob O > > >-----Original Message----- > >From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] > >Sent: Monday, August 20, 2001 9:32 AM > >To: simple@mailman.dynamicsoft.com > >Subject: Re: [Simple] Sessions of MESSAGEs > > > > > > > >Assuming that the SIMPLE protocol will develop over time to > >give the same > >functionality as current IM systems, the > >restrictions imposed by inheritance from SIP bother me. > > > >What I am bothered about is that SIMPLE inherits the separation between > >signaling and media of SIP. It assumes a different transport for the > >signaling and the media. For example, in a conference the signaling > >(INVITEs/REFERs) should be done on a single TCP connection > >while a new TCP > >connection should be created for sending the text messages of the > >conference. > > > >I am not sure if creating a new TCP connection for each IM > >(when it is done > >by a session) or conference will scale. Maybe MESSAGE should > >be allowed to > >be carried on the same transport as the INVITE message was sent on? > > > >-Avshalom > >Sametime/Lotus > > > > > > > > > > > > "Peterson, Jon" > > > > To: > >"'simple@mailman.dynamicsoft.com'" > > Sent by: > > > > > > simple-admin@mailman.dynam cc: > > > > icsoft.com Subject: > > [Simple] Sessions of MESSAGEs > > > > > > > > > > 20/08/2001 17:47 > > > > > > > > > > > > > > > > > > > >After the SIMPLE session last week in London, the SIMPLE > >chairs received > >some feedback from the IESG with regards to the use of the > >MESSAGE method > >end-to-end when an IM session has been established with an INVITE (as > >described in draft-ietf-simple-im-session-00). > > > >The IESG has some concerns that this mechanism constitutes the > >use of SIP > >as > >a transport protocol. In other words, once the session has > >been established > >between the two endpoints by the INVITE, if the MESSAGEs can only go > >directly end-to-end, then their headers and related protocol > >apparatus are > >entirely superfluous and may do more harm than good. We saw during the > >meeting last week that there were definitely some pitfalls to allowing > >methods other than MESSAGE across the IM stream (as well as > >questions about > >overlapping transactions, redirection, forking, and so forth), > >and it isn't > >clear that the overhead is justified if MESSAGE is just an > >envelope for its > >encapsulated MIME payload. The IESG was particularly > >concerned, in addition > >to the protocol overhead, with congestion characteristics of > >the messaging > >session and with the precedent that could be set by using SIP in this > >fashion. > > > >For these reasons, the IESG is not inclined to look favorably on that > >direction for our protocol work. They also weren't > >enthusiastic about the > >potential use of RTP text for message transmission > >(significant concerns > >were also raised on the floor in London about message framing, > >especially > >at > >CPIM gateways). The recommendation we've been given is to focus on a > >standard transport protocol with understood congestion > >properties such as > >TCP or SCTP. In London, Ben Campbell took an action item to begin > >investigating alternatives along these lines given the > >significant concerns > >that arose on the floor with regards to the other approaches. > >It seems that > >the primary question about this approach is what runs over the > >transport > >protocol in question; i.e. MIME headers and bodies, pure message/cpim, > >BEEP, > >plain text, etc. > > > >If anyone feels strongly that we should continue to pursue the > >use of the > >MESSAGE method for direct end-to-end IM signaling, or has > >input about how > >the transport should operate, let's get this discussion > >underway promptly > >so > >we can meet our projected September deliverables. > > > >Jon Peterson > >NeuStar, Inc > >SIMPLE co-chair > > > >_______________________________________________ > >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 Vasilis.Polychronidis@Openwave.com Tue Aug 21 01:11:05 2001 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 BAA03952 for ; Tue, 21 Aug 2001 01:11:04 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010821050918.KVTU3988.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Tue, 21 Aug 2001 00:09:18 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010821051100.RENQ26952.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Tue, 21 Aug 2001 00:11:00 -0500 Message-ID: <3B81ED5F.7D51163D@Openwave.com> Date: Mon, 20 Aug 2001 22:10:55 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: <2E33960095B58E40A4D3345AB9F65EC1460F57@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <01ab01c129f8$c9a0ee80$55fa403f@blazer> Content-Type: multipart/alternative; boundary="------------87431C8792B56BEF6A7C2DF1" Content-Length: 26348 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: --------------87431C8792B56BEF6A7C2DF1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok I am a little confused here. Here is a quote from Jon Peterson's previous E-mail: Dean please read my comments below: After the SIMPLE session last week in London, the SIMPLE chairs received some feedback from the IESG with regards to the use of the MESSAGE method end-to-end when an IM session has been established with an INVITE (as described in draft-ietf-simple-im-session-00). The IESG has some concerns that this mechanism constitutes the use of SIP as a transport protocol. In other words, once the session has been established between the two endpoints by the INVITE, if the MESSAGEs can only go directly end-to-end, then their headers and related protocol apparatus are entirely superfluous and may do more harm than good. Dean which of the above statements up to this point did not understand? We saw during the meeting last week that there were definitely some pitfalls to allowing methods other than MESSAGE across the IM stream (as well as questions about overlapping transactions, redirection, forking, and so forth), and it isn't clear that the overhead is justified if MESSAGE is just an envelope for its encapsulated MIME payload. The IESG was particularly concerned, in addition to the protocol overhead, with congestion characteristics of the messaging session and with the precedent that could be set by using SIP in this fashion. For these reasons, the IESG is not inclined to look favorably on that direction for our protocol work. They also weren't enthusiastic about the potential use of RTP text for message transmission (significant concerns were also raised on the floor in London about message framing, especially at CPIM gateways). The recommendation we've been given is to focus on a standard transport protocol with understood congestion properties such as TCP or SCTP. So we will have to work with standard transport protocol such as TCP, SCTP, etc. Dean is this clear to you? In London, Ben Campbell took an action item to begin investigating alternatives along these lines given the significant concerns that arose on the floor with regards to the other approaches. It seems that the primary question about this approach is what runs over the transport protocol in question; i.e. MIME headers and bodies, pure message/cpim, BEEP, plain text, etc. If anyone feels strongly that we should continue to pursue the use of the MESSAGE method for direct end-to-end IM signaling, or has input about how the transport should operate, let's get this discussion underway promptly so we can meet our projected September deliverables. Dean are you proposing to use SIP as the transport in the IM Session case? Jon Peterson NeuStar, Inc SIMPLE co-chair Dean Willis wrote: > Ok, there's THREE topics: > > 1) MESSAGE sessions established directly between two nodes using SIP which > is routed by proxies. MESSAGE method assumes SIP as the underlying transport method. The consensus is not to do that. Please see above > > 2) MESSAGE transmissions outside of a session routed by proxies ("Pager > mode") > 3) MESSAGE sessions between two nodes, where those messages are routed by > proxies using the routing semantics of any other SIP message. Oddly enough, > this begins to look a lot like BXXP. MESSAGE method assumes SIP as the underlying transport manhood. The consensus is not to do that. Please see above > > > We're debating #1 here. Correct. Robert initiated the debate. I am planning to answer all of his concerns in a later E-mail. > > > #2 is still in the work plan. > > As for #3, I like it -- I think it has a lot of advantages, and Robert has > definitely hit on some of them. But not all .For example, at some point, > we'll have the same kind of "privacy" concerns with message routing as we > now have with call routing. We'll want suppression of source location > information, network-authenticated remote-party-ID, the Privacy: header and > its accompanying semantics, etc. Guess what? We've already figured those out > for SIP "system" messaging, for the most part. Why not re-use the > infrastructure for "user" messaging? Sure it'll create server overhead. But > it will work the way we need it to work. You get what you pay for. > > On the other hand, do we really need a "message session", or are serialized > "pager messages" with retransmission and in-order assembly by the > application good enough? Why the same topic arises again and again. Here is a quote from a previous E-mail: Jonathan, Based on the other comments about sending MESSAGE over SIP signaling paths, it would then be necessary to segregate and prioritize SIP traffic to prevent 1M IM messages from delaying SIP session setup traffic. We don't need to repeat the problems that GSM systems had with SMS traffic interfering with call setup! Mike > > > -- > Dean > > ----- Original Message ----- > From: "Robert Osborne" > To: ; > Sent: Monday, August 20, 2001 11:54 AM > Subject: RE: [Simple] Sessions of MESSAGEs > > > Hi, > > > > I agree with Avshalom that MESSAGE should be allowed to be > > carried over the normal SIP signalling transport, for several reasons > > > > * Creating a seperate TCP connection for a IM Session would > > be expensive, especially when going across firewalls > > * Allowing for the MESSAGE to travel along the normal > > signalling channel improves the authentication and > > security between domains > > > > Rob O > > > > >-----Original Message----- > > >From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] > > >Sent: Monday, August 20, 2001 9:32 AM > > >To: simple@mailman.dynamicsoft.com > > >Subject: Re: [Simple] Sessions of MESSAGEs > > > > > > > > > > > >Assuming that the SIMPLE protocol will develop over time to > > >give the same > > >functionality as current IM systems, the > > >restrictions imposed by inheritance from SIP bother me. > > > > > >What I am bothered about is that SIMPLE inherits the separation between > > >signaling and media of SIP. It assumes a different transport for the > > >signaling and the media. For example, in a conference the signaling > > >(INVITEs/REFERs) should be done on a single TCP connection > > >while a new TCP > > >connection should be created for sending the text messages of the > > >conference. > > > > > >I am not sure if creating a new TCP connection for each IM > > >(when it is done > > >by a session) or conference will scale. Maybe MESSAGE should > > >be allowed to > > >be carried on the same transport as the INVITE message was sent on? > > > > > >-Avshalom > > >Sametime/Lotus > > > > > > > > > > > > > > > > > > "Peterson, Jon" > > > > > > To: > > >"'simple@mailman.dynamicsoft.com'" > > > Sent by: > > > > > > > > > simple-admin@mailman.dynam cc: > > > > > > icsoft.com Subject: > > > [Simple] Sessions of MESSAGEs > > > > > > > > > > > > > > > 20/08/2001 17:47 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >After the SIMPLE session last week in London, the SIMPLE > > >chairs received > > >some feedback from the IESG with regards to the use of the > > >MESSAGE method > > >end-to-end when an IM session has been established with an INVITE (as > > >described in draft-ietf-simple-im-session-00). > > > > > >The IESG has some concerns that this mechanism constitutes the > > >use of SIP > > >as > > >a transport protocol. In other words, once the session has > > >been established > > >between the two endpoints by the INVITE, if the MESSAGEs can only go > > >directly end-to-end, then their headers and related protocol > > >apparatus are > > >entirely superfluous and may do more harm than good. We saw during the > > >meeting last week that there were definitely some pitfalls to allowing > > >methods other than MESSAGE across the IM stream (as well as > > >questions about > > >overlapping transactions, redirection, forking, and so forth), > > >and it isn't > > >clear that the overhead is justified if MESSAGE is just an > > >envelope for its > > >encapsulated MIME payload. The IESG was particularly > > >concerned, in addition > > >to the protocol overhead, with congestion characteristics of > > >the messaging > > >session and with the precedent that could be set by using SIP in this > > >fashion. > > > > > >For these reasons, the IESG is not inclined to look favorably on that > > >direction for our protocol work. They also weren't > > >enthusiastic about the > > >potential use of RTP text for message transmission > > >(significant concerns > > >were also raised on the floor in London about message framing, > > >especially > > >at > > >CPIM gateways). The recommendation we've been given is to focus on a > > >standard transport protocol with understood congestion > > >properties such as > > >TCP or SCTP. In London, Ben Campbell took an action item to begin > > >investigating alternatives along these lines given the > > >significant concerns > > >that arose on the floor with regards to the other approaches. > > >It seems that > > >the primary question about this approach is what runs over the > > >transport > > >protocol in question; i.e. MIME headers and bodies, pure message/cpim, > > >BEEP, > > >plain text, etc. > > > > > >If anyone feels strongly that we should continue to pursue the > > >use of the > > >MESSAGE method for direct end-to-end IM signaling, or has > > >input about how > > >the transport should operate, let's get this discussion > > >underway promptly > > >so > > >we can meet our projected September deliverables. > > > > > >Jon Peterson > > >NeuStar, Inc > > >SIMPLE co-chair > > > > > >_______________________________________________ > > >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 --------------87431C8792B56BEF6A7C2DF1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ok I am a little confused here.
Here is a quote from Jon Peterson's previous E-mail:
Dean please read my comments below:

After the SIMPLE session last week in London, the
SIMPLE chairs received
some feedback from the IESG with regards to the use of
the MESSAGE method
end-to-end when an IM session has been established with
an INVITE (as
described in draft-ietf-simple-im-session-00).

The IESG has some concerns that this mechanism
constitutes the use of SIP as
a transport protocol. In other words, once the session
has been established
between the two endpoints by the INVITE, if the
MESSAGEs can only go
directly end-to-end, then their headers and related
protocol apparatus are
entirely superfluous and may do more harm than good.

Dean which of the above statements up to this point did not understand?

We
saw during the
meeting last week that there were definitely some
pitfalls to allowing
methods other than MESSAGE across the IM stream (as
well as questions about
overlapping transactions, redirection, forking, and so
forth), and it isn't
clear that the overhead is justified if MESSAGE is just
an envelope for its
encapsulated MIME payload. The IESG was particularly
concerned, in addition
to the protocol overhead, with congestion
characteristics of the messaging
session and with the precedent that could be set by
using SIP in this
fashion.

For these reasons, the IESG is not inclined to look
favorably on that
direction for our protocol work. They also weren't
enthusiastic about the
potential use of RTP text for message transmission
(significant concerns
were also raised on the floor in London about message
framing, especially at
CPIM gateways). The recommendation we've been given is
to focus on a
standard transport protocol with understood congestion
properties such as
TCP or SCTP.

So we will have to work with standard transport protocol
such as TCP, SCTP, etc.
Dean is this clear to you?

In London, Ben Campbell took an action
item to begin
investigating alternatives along these lines given the
significant concerns
that arose on the floor with regards to the other
approaches. It seems that
the primary question about this approach is what runs
over the transport
protocol in question; i.e. MIME headers and bodies,
pure message/cpim, BEEP,
plain text, etc.

If anyone feels strongly that we should continue to
pursue the use of the
MESSAGE method for direct end-to-end IM signaling, or
has input about how
the transport should operate, let's get this discussion
underway promptly so
we can meet our projected September deliverables.

Dean are you proposing to use SIP as the transport in the IM Session case?

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

Dean Willis wrote:

Ok, there's THREE topics:

1) MESSAGE sessions established directly between two nodes using SIP which
is routed by proxies.

MESSAGE method assumes SIP as the underlying transport method.
The consensus is not to do that. Please see above
 
2) MESSAGE transmissions outside of a session routed by proxies ("Pager
mode")
3) MESSAGE sessions between two nodes, where those messages are routed by
proxies using the routing semantics of any other SIP message. Oddly enough,
this begins to look a lot like BXXP.
MESSAGE method assumes SIP as the underlying transport manhood.
The consensus is not to do that. Please see above
 

We're debating #1 here.

Correct. Robert initiated the debate. I am planning to answer all of his concerns in a later E-mail.
 

#2 is still in the work plan.

As for #3, I like it -- I think it has a lot of advantages, and Robert has
definitely hit on some of them. But not all .For example, at some point,
we'll have the same kind of "privacy" concerns with message routing as we
now have with call routing. We'll want suppression of source location
information, network-authenticated remote-party-ID, the Privacy: header and
its accompanying semantics, etc. Guess what? We've already figured those out
for SIP "system" messaging, for the most part. Why not re-use the
infrastructure for "user" messaging? Sure it'll create server overhead. But
it will work the way we need it to work. You get what you pay for.

On the other hand, do we really need a "message session", or are serialized
"pager messages" with retransmission and in-order assembly by the
application good enough?

Why the same topic arises again and again.
Here is a quote from a previous E-mail:

Jonathan,

Based on the other comments about sending MESSAGE over SIP signaling
paths,
it would then be necessary to segregate and prioritize SIP traffic to
prevent 1M IM messages from delaying SIP session setup traffic.

We don't need to repeat the problems that GSM systems had with SMS
traffic
interfering with call setup!

Mike

 

--
Dean

----- Original Message -----
From: "Robert Osborne" <roberto@windows.microsoft.com>
To: <Avshalom@ubique.com>; <simple@mailman.dynamicsoft.com>
Sent: Monday, August 20, 2001 11:54 AM
Subject: RE: [Simple] Sessions of MESSAGEs

> Hi,
>
> I agree with Avshalom that MESSAGE should be allowed to be
> carried over the normal SIP signalling transport, for several reasons
>
> * Creating a seperate TCP connection for a IM Session would
> be expensive, especially when going across firewalls
> * Allowing for the MESSAGE to travel along the normal
> signalling channel improves the authentication and
> security between domains
>
> Rob O
>
> >-----Original Message-----
> >From: Avshalom@ubique.com [mailto:Avshalom@ubique.com]
> >Sent: Monday, August 20, 2001 9:32 AM
> >To: simple@mailman.dynamicsoft.com
> >Subject: Re: [Simple] Sessions of MESSAGEs
> >
> >
> >
> >Assuming that the SIMPLE protocol will develop over time to
> >give the same
> >functionality as current IM systems, the
> >restrictions imposed by inheritance from SIP bother me.
> >
> >What I am bothered about is that SIMPLE inherits the separation between
> >signaling and media of SIP. It assumes a different transport for the
> >signaling and the media. For example, in a conference the signaling
> >(INVITEs/REFERs) should be done on a single TCP connection
> >while a new TCP
> >connection should be created for sending the text messages of the
> >conference.
> >
> >I am not sure if creating a new TCP connection for each IM
> >(when it is done
> >by a session) or conference will scale. Maybe MESSAGE should
> >be allowed to
> >be carried on the same transport as the INVITE message was sent on?
> >
> >-Avshalom
> >Sametime/Lotus
> >
> >
> >
> >
> >
> >                    "Peterson, Jon"
> >
> >                    <jon.peterson@neustar.com>        To:
> >"'simple@mailman.dynamicsoft.com'"
> >                    Sent by:
> ><simple@mailman.dynamicsoft.com>
> >
> >                    simple-admin@mailman.dynam        cc:
> >
> >                    icsoft.com                        Subject:
> >    [Simple] Sessions of MESSAGEs
> >
> >
> >
> >
> >                    20/08/2001 17:47
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >After the SIMPLE session last week in London, the SIMPLE
> >chairs received
> >some feedback from the IESG with regards to the use of the
> >MESSAGE method
> >end-to-end when an IM session has been established with an INVITE (as
> >described in draft-ietf-simple-im-session-00).
> >
> >The IESG has some concerns that this mechanism constitutes the
> >use of SIP
> >as
> >a transport protocol. In other words, once the session has
> >been established
> >between the two endpoints by the INVITE, if the MESSAGEs can only go
> >directly end-to-end, then their headers and related protocol
> >apparatus are
> >entirely superfluous and may do more harm than good. We saw during the
> >meeting last week that there were definitely some pitfalls to allowing
> >methods other than MESSAGE across the IM stream (as well as
> >questions about
> >overlapping transactions, redirection, forking, and so forth),
> >and it isn't
> >clear that the overhead is justified if MESSAGE is just an
> >envelope for its
> >encapsulated MIME payload. The IESG was particularly
> >concerned, in addition
> >to the protocol overhead, with congestion characteristics of
> >the messaging
> >session and with the precedent that could be set by using SIP in this
> >fashion.
> >
> >For these reasons, the IESG is not inclined to look favorably on that
> >direction for our protocol work. They also weren't
> >enthusiastic about the
> >potential use of RTP text for message transmission
> >(significant concerns
> >were also raised on the floor in London about message framing,
> >especially
> >at
> >CPIM gateways). The recommendation we've been given is to focus on a
> >standard transport protocol with understood congestion
> >properties such as
> >TCP or SCTP. In London, Ben Campbell took an action item to begin
> >investigating alternatives along these lines given the
> >significant concerns
> >that arose on the floor with regards to the other approaches.
> >It seems that
> >the primary question about this approach is what runs over the
> >transport
> >protocol in question; i.e. MIME headers and bodies, pure message/cpim,
> >BEEP,
> >plain text, etc.
> >
> >If anyone feels strongly that we should continue to pursue the
> >use of the
> >MESSAGE method for direct end-to-end IM signaling, or has
> >input about how
> >the transport should operate, let's get this discussion
> >underway promptly
> >so
> >we can meet our projected September deliverables.
> >
> >Jon Peterson
> >NeuStar, Inc
> >SIMPLE co-chair
> >
> >_______________________________________________
> >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

--------------87431C8792B56BEF6A7C2DF1-- From Vasilis.Polychronidis@Openwave.com Tue Aug 21 05:37:52 2001 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 FAA04805 for ; Tue, 21 Aug 2001 05:37:51 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010821093605.UNGE3988.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Tue, 21 Aug 2001 04:36:05 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010821093747.RKAM26952.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Tue, 21 Aug 2001 04:37:47 -0500 Message-ID: <3B822BE5.E4FD0848@Openwave.com> Date: Tue, 21 Aug 2001 02:37:41 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Osborne CC: Zane Thomas , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: <2E33960095B58E40A4D3345AB9F65EC1460F5A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: multipart/alternative; boundary="------------5BC2C69F46876A3AACA5A1F2" Content-Length: 38652 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: --------------5BC2C69F46876A3AACA5A1F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert, The following is just a rough proposal but I hope will answer your questions. Obviously we need a couple of IDs in order to completely specify the functionality of the IM session proposal. Please see my comments below: Kind Regards, -Vasilis Polychronidis Robert Osborne wrote: > Well I do :-) > What is simple or is not as objective as we would like to > think. > After all most of the commercial systems today include (as > you clearly explained above) > an IM Server (trusted server) and this is how the overcome > the NAT issues. > > [Robert Osborne] Ok, so lets agree to disagree on the > simplicity, but agree that a server is required at the > domain's edge. > Well first let me provide some background information that will make this discussion more precise: 1. For simplicity lets assume the IM Service providers under discussion deployed only IM systems that initiate IM sessions via "normal" SIP operations (Similar way as it is done for VoIP). For other cases please refer to IMPP and CPIM gatewaying. 2. Let us assume that we have two such IM service providers: IM provider X IM provider Y 3. For simplicity lets assume that each provider has each one domain that servers all of its users IM provider X --> simple.OperatorX.net IM provider Y --> simple.OperatorY.net 4. Each user can be addressed by a SIP URL. It is assumed that the operators have deployed a SIP proxy infrastructure for establishing VoIP sessions. Now under these assumptions each operator will have its own IM Server in order to solve the following issues: 1. NAT issues 2. Universal access (mobile, PDA, PC, etc.) 3. Consistency and synchronization 4. Authorization/Authentication 5. "Mobility" of buddy lists 6. Security Operators are very reluctant to deploy a peer to peer model for various reasons that I will not analyze here. Treating IM as a session does not preclude the use of the peer to peer model. So under the above logic and assuming that the operators do not wish to deploy a peer to peer IM system I would agree that each operator will have its own IM Server. Now let me analyze the case where IM User A that is being served by OperatorX wants to set up an IM session with IM User B and start the chat. The following diagram is a rough example that depicts the message flow for establishment of the IM session. The SDP documents carried by the appropriate SIP messages can indicate to B (or A) client to connect to the IM Server X (or IM Server Y) A Client can reside behind Openwave's firewall. B client can reside behind Microsoft's firewall. There is the issue of the OperatorX to allow incoming TCP connections from subscribers other than its own (for example like MSN subs). For additional security OperatorX can deploy a gateway IM Server X' in order to allow interoperability with other Operators. Please view in a fixed-width font such as Courier. +-----+ +-------+ +-------+ +-------+ +-----+ |A | |IM | |SIP | |SIP | |B | | | |Srv X | |proxy X| |proxy Y| | | +-----+ +-------+ +-------+ +-------+ +-----+ | TCP connection | | | | 1 |<-------------->| | | | | INVITE | | | |--------------------------->| INVITE | | | 100 |--------------->| INVITE | |<---------------------------| |-------------->| | |<-----100-------| | | | | | | | | | | | 180 |<-----180------| | 180 |<---------------| | |<---------------------------| | | | | | 200 | | | 200 |<--------------| | 200 |<---------------| | |<---------------------------| | | | | | | |----------ACK-------------->| | | | |------ACK------>| ACK | | | |-------------->| | TCP to home IM | Initiate TCP connection with IM Srv X | |<-------------->|<----------+----------------+---------------| | | | | | | TCP to home IM | TCP connection is established | |<-------------->|<----------+----------------+-------------->| | | | | | | | | | | | | | | | | BYE | | | |--------------------------->| BYE | | | |--------------->| BYE | | | |-------------->| | | | | | | |<----200-------| | 200 |<------200------| | |<---------------------------| | | | | | | This is is the most complicated case so for any other case you should be able to analyze it using the above mentioned analysis. Now let me answer your questions: 1) How would client A within domain X ensure that the local server (IM Server X) is aware that a session with client B in domain Y has been created? After the SIP exchange the client A will convey the session information (Call-ID:, IP address, Port # in SDP, etc.) to its local IM Server via its TCP connection. I know this answer is vague but the details should be specified in the upcoming ID for the IM session. 2) How would the server know that a particular TCP connection from domain Y actually maps into a session with client A within the domain? Well since the IM Server X is aware of the session information (see above answer) it can map the TCP connections. 3) How would the server authenticate that the TCP connection is actually from client B within domain Y? When the client B connects to the IM Server X uses the information received via the INVITE message in order to authenticate. 4) How does the server become aware that client A no longer wishes to receive traffic for this session (i.e. user has closed IM window)? The client A sends a BYE to the client B and tears down the TCP connection. For another implementation (taken from draft-ietf-sip-call-flows-05.txt) please see the diagram below: I wish I knew about it before I wrote the above "rough" scenario :-) 3.1.5 Successful SIP to SIP through SIP Firewall Proxy Please view in a fixed-width font such as Courier. User A IM Server Proxy 1 User B | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | (100) F3 |--------------->| INVITE F4 | |<---------------| (100) F5 |--------------->| | |<---------------| 180 F6 | | | 180 F7 |<---------------| | 180 F8 |<---------------| | |<---------------| | 200 F9 | | | 200 F10 |<---------------| | 200 F11 |<---------------| | |<---------------| | | | ACK F12 | | | |--------------->| ACK F13 | | | |--------------->| ACK F14 | | | |--------------->| | IM Media | Both Way IM Media | |<==============>|<===============================>| | BYE F15 | | | |--------------->| BYE F16 | | | |--------------->| BYE F17 | | | |--------------->| | | | 200 F18 | | | 200 F19 |<---------------| | 200 F20 |<---------------| | |<---------------| | | | | | | Where in the above picture I changed Firewall Proxy to IM Server :-) and RTP Media to IM Media :-) I think this case scenario provides for more specific answers to your questions. I agree with you that we need an Internet draft that will specify all the details of how to initialize IM sessions with SIP and carry IM messages over TCP, SCTP or HTTP. The above examples indicate that such IM system is relatively easy to design. I would be more than happy to help with the production of such ID. > My question is, how would you expect this server to work, > particularly in the following area:1) How would user X > within domain X ensure that the local server is aware that a > session with user A in domain A has been created.2) How > would the server know that a particular TCP connection from > domain A actually maps into a session with user X within the > domain3) How would the server authenticate that the TCP > connection is actually from user A within domain A4) How > does the server become aware that user X no longer wishes to > receive traffic for this session (ie user has closed IM > window > > > >IM as a session with a TCP or HTTP transport is the right > > way moving > > >forward. > > > > > >> > > >> > > >> Rob O > > >> > --------------5BC2C69F46876A3AACA5A1F2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Robert,
The following is just a rough proposal but I hope will
answer your questions.
Obviously we need a couple of IDs in order to completely specify the
functionality of the IM session proposal.
Please see my comments below:

Kind Regards,

-Vasilis Polychronidis

Robert Osborne wrote:

Well I do :-)
What is simple or is not as objective as we would like to think.
After all most of the commercial systems today include (as you clearly explained above)
an IM Server (trusted server) and this is how the overcome the NAT issues.

[Robert Osborne]  Ok, so lets agree to disagree on the simplicity, but agree that a server is required at the domain's edge.
Well first let me provide some background information that will make this discussion more precise:
1. For simplicity lets assume the IM Service providers under discussion deployed only IM systems that initiate IM sessions via
    "normal" SIP operations (Similar way as it is done for VoIP). For other cases please refer to IMPP and CPIM gatewaying.
2. Let us assume that we have two such IM service providers:
    IM provider X
    IM provider Y
3. For simplicity lets assume that each provider has each one domain that servers all of its users
    IM provider X --> simple.OperatorX.net
    IM provider Y --> simple.OperatorY.net
4. Each user can be addressed by a SIP URL. It is assumed that the operators have deployed a SIP
    proxy infrastructure for establishing VoIP sessions.
Now under these assumptions each operator will have its own IM Server in order to solve the following issues:
1. NAT issues
2. Universal access (mobile, PDA, PC, etc.)
3. Consistency and synchronization
4. Authorization/Authentication
5. "Mobility" of buddy lists
6. Security
Operators are very reluctant to deploy a peer to peer model for various reasons that I will not analyze here.
Treating IM as a session does not preclude the use of the peer to peer model.
So under the above logic and assuming that the operators do not wish to deploy a peer to peer IM system
I would agree that each operator will have its own IM Server.
Now let me analyze the case where IM User A<x> that is being served by OperatorX wants to set up an IM
session with IM User B<y> and start the chat.
The following diagram is a rough example that depicts the message flow for establishment of the IM session.
The SDP documents carried by the appropriate SIP messages can indicate to B<y>
(or A<x>) client to connect to the IM Server X (or IM Server Y)
A<x> Client can reside behind Openwave's firewall.
B<y> client can reside behind Microsoft's firewall.
There is the issue of the OperatorX to allow incoming TCP connections
from subscribers other than its own (for example like MSN subs).
For additional security OperatorX can deploy a gateway IM Server X' in order to allow
interoperability with other Operators.
 

Please view in a fixed-width font such as Courier.

 +-----+        +-------+    +-------+        +-------+        +-----+
 |A<x> |        |IM     |    |SIP    |        |SIP    |        |B<y> |
 |     |        |Srv X  |    |proxy X|        |proxy Y|        |     |
 +-----+        +-------+    +-------+        +-------+        +-----+
    | TCP connection |           |                |               |
  1 |<-------------->|           |                |               |
    |       INVITE               |                |               |
    |--------------------------->|     INVITE     |               |
    |        100                 |--------------->|   INVITE      |
    |<---------------------------|                |-------------->|
    |                            |<-----100-------|               |
    |                            |                |               |
    |                            |                |               |
    |                            |      180       |<-----180------|
    |          180               |<---------------|               |
    |<---------------------------|                |               |
    |                            |                |      200      |
    |                            |      200       |<--------------|
    |          200               |<---------------|               |
    |<---------------------------|                |               |
    |                            |                |               |
    |----------ACK-------------->|                |               |
    |                            |------ACK------>|      ACK      |
    |                            |                |-------------->|
    | TCP to home IM |  Initiate TCP connection with IM Srv X     |
    |<-------------->|<----------+----------------+---------------|
    |                |           |                |               |
    | TCP to home IM |    TCP connection is established           |
    |<-------------->|<----------+----------------+-------------->|
    |                |           |                |               |
    |                |           |                |               |
    |                |           |                |               |
    |        BYE                 |                |               |
    |--------------------------->|       BYE      |               |
    |                            |--------------->|     BYE       |
    |                            |                |-------------->|
    |                            |                |               |
    |                            |                |<----200-------|
    |         200                |<------200------|               |
    |<---------------------------|                |               |
    |                            |                |               |
 

This is is the most complicated case so for any other case you should be able to analyze it using the above mentioned analysis.
Now let me answer your questions:

1) How would client A<x> within domain X ensure that the local server (IM Server X) is aware that a session with client B<y> in domain Y
    has been created?
After the SIP exchange the client A<x> will convey the session information (Call-ID:, IP address, Port # in SDP, etc.) to its local IM Server
via its TCP connection.
I know this answer is vague but the details should be specified in the upcoming ID for the IM session.
2) How would the server know that a particular TCP connection from domain Y actually maps into a session with client A<x> within the domain?
Well since the IM Server X is aware of the session information (see above answer) it can map the TCP connections.
3) How would the server authenticate that the TCP connection is actually from client B<y> within domain Y?
When the client B<y> connects to the IM Server X uses the information received via the INVITE message in order to authenticate.
4) How does the server become aware that client A<x> no longer wishes to receive traffic for this session (i.e. user has closed IM window)?
The client A<x> sends a BYE to the client B<y> and tears down the TCP connection.

For another implementation (taken from draft-ietf-sip-call-flows-05.txt) please see the diagram below:
I wish I knew about it before I wrote the above "rough" scenario :-)

3.1.5 Successful SIP to SIP through SIP Firewall Proxy

Please view in a fixed-width font such as Courier.

   User A          IM Server         Proxy 1          User B
     |                |                |                |
     |   INVITE F1    |                |                |
     |--------------->|   INVITE F2    |                |
     |    (100) F3    |--------------->|   INVITE F4    |
     |<---------------|    (100) F5    |--------------->|
     |                |<---------------|      180 F6    |
     |                |     180 F7     |<---------------|
     |     180 F8     |<---------------|                |
     |<---------------|                |      200 F9    |
     |                |    200 F10     |<---------------|
     |     200 F11    |<---------------|                |
     |<---------------|                |                |
     |     ACK F12    |                |                |
     |--------------->|     ACK F13    |                |
     |                |--------------->|     ACK F14    |
     |                |                |--------------->|
     |     IM Media   |         Both Way IM Media       |
     |<==============>|<===============================>|
     |     BYE F15    |                |                |
     |--------------->|     BYE F16    |                |
     |                |--------------->|     BYE F17    |
     |                |                |--------------->|
     |                |                |     200 F18    |
     |                |     200 F19    |<---------------|
     |     200 F20    |<---------------|                |
     |<---------------|                |                |
     |                |                |                |

Where in the above picture I changed Firewall Proxy to IM Server :-)
and RTP Media to IM Media :-)
I think this case scenario provides for more specific answers to your questions.

I agree with you that we need an Internet draft that will specify all the details of
how to initialize IM sessions with SIP and carry IM messages over TCP, SCTP or HTTP.
The above examples indicate that such IM system is relatively easy to design.
I would be more than happy to help with the production of such ID.

My question is, how would you expect this server to work, particularly in the following area:1)    How would user X within domain X ensure that the local server is aware that a session with user A in domain A has been created.2)    How would the server know that a particular TCP connection from domain A actually maps into a session with user X within the domain3)    How would the server authenticate that the TCP connection is actually from user A within domain A4)    How does the server become aware that user X no longer wishes to receive traffic for this session (ie user has closed IM window
>IM as a session with a TCP or HTTP transport is the right way moving
>forward.
>
>>
>>
>> Rob O
>>
--------------5BC2C69F46876A3AACA5A1F2-- From sales@seebex.com Tue Aug 21 07:13:03 2001 Received: from rafi ([213.8.76.34]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05126 for ; Tue, 21 Aug 2001 07:12:57 -0400 (EDT) From: sales@seebex.com Received: from mail pickup service by rafi with Microsoft SMTPSVC; Tue, 21 Aug 2001 14:13:08 +0200 To: Date: Tue, 21 Aug 2001 14:13:08 +0200 Message-ID: <128d01c12a3a$a36cf0a0$0200a8c0@rafi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcEqOqNs23uxUU0lS8OtrSesqBfVXw== Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 21 Aug 2001 12:13:08.0188 (UTC) FILETIME=[A37491C0:01C12A3A] Content-Length: 859 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id HAA05126 Subject: [Simple] Instant Messaging platform at your Web site is now a few clicks away 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: Instant Messaging platform at your Web site is now a few clicks away ---------------------------------------------------------------------- Install a FREE Instant Messaging server at your Web site. Use it as is or customize to meet your specific branding. Cross platform servers line support 25 and up to 1000 concurrent users All servers offered can be secured with RSA 512Bit (and higher) encryption!! Download free 10 concurrent users server at: http://www.seebex.com/download/get_server.asp It is easier, faster and affordable than ever!! For further information please check seebex Web site at: http://www.seebex.com or contact our Marketing & Sales department at sales@seebex.com First 50 Web sites to download and embed the free 10 concurrent users server are entitled to a free 100 concurrent users server and will be listed on Seebex Web site. From jdrosen@dynamicsoft.com Tue Aug 21 09:31:07 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05536 for ; Tue, 21 Aug 2001 09:31:06 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7LDMlrN005764; Tue, 21 Aug 2001 09:22:47 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 09:23:35 -0400 Message-ID: From: Jonathan Rosenberg To: "'Vasilis Polychronidis'" , Robert Osborne Cc: Zane Thomas , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Tue, 21 Aug 2001 09:23:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 11583 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: Vasilis, I made a concrete proposal on a mechanism for TCP transport of IM, using a TCP version of the reflector protocol documented in draft-rosenberg-sip-entfw-02.txt. I discussed it in the email yesterday: http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html you seem to be proposing an alternate mechanism (not entirely sure, though). Is there any reason you do not support the above approach? As I mentioned in the email, by using the discovery/negotiation mechanisms in entfw, we get the benefit of using direct tcp whenever possible (at least one of the users has a direct connection to the Internet (i.e., not natted)), but we work through nats even in the hard case where both users are natted. -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: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com] Sent: Tuesday, August 21, 2001 5:38 AM To: Robert Osborne Cc: Zane Thomas; simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs Hi Robert, The following is just a rough proposal but I hope will answer your questions. Obviously we need a couple of IDs in order to completely specify the functionality of the IM session proposal. Please see my comments below: Kind Regards, -Vasilis Polychronidis Robert Osborne wrote: Well I do :-) What is simple or is not as objective as we would like to think. After all most of the commercial systems today include (as you clearly explained above) an IM Server (trusted server) and this is how the overcome the NAT issues. [Robert Osborne] Ok, so lets agree to disagree on the simplicity, but agree that a server is required at the domain's edge. Well first let me provide some background information that will make this discussion more precise: 1. For simplicity lets assume the IM Service providers under discussion deployed only IM systems that initiate IM sessions via "normal" SIP operations (Similar way as it is done for VoIP). For other cases please refer to IMPP and CPIM gatewaying. 2. Let us assume that we have two such IM service providers: IM provider X IM provider Y 3. For simplicity lets assume that each provider has each one domain that servers all of its users IM provider X --> simple.OperatorX.net IM provider Y --> simple.OperatorY.net 4. Each user can be addressed by a SIP URL. It is assumed that the operators have deployed a SIP proxy infrastructure for establishing VoIP sessions. Now under these assumptions each operator will have its own IM Server in order to solve the following issues: 1. NAT issues 2. Universal access (mobile, PDA, PC, etc.) 3. Consistency and synchronization 4. Authorization/Authentication 5. "Mobility" of buddy lists 6. Security Operators are very reluctant to deploy a peer to peer model for various reasons that I will not analyze here. Treating IM as a session does not preclude the use of the peer to peer model. So under the above logic and assuming that the operators do not wish to deploy a peer to peer IM system I would agree that each operator will have its own IM Server. Now let me analyze the case where IM User A that is being served by OperatorX wants to set up an IM session with IM User B and start the chat. The following diagram is a rough example that depicts the message flow for establishment of the IM session. The SDP documents carried by the appropriate SIP messages can indicate to B (or A) client to connect to the IM Server X (or IM Server Y) A Client can reside behind Openwave's firewall. B client can reside behind Microsoft's firewall. There is the issue of the OperatorX to allow incoming TCP connections from subscribers other than its own (for example like MSN subs). For additional security OperatorX can deploy a gateway IM Server X' in order to allow interoperability with other Operators. Please view in a fixed-width font such as Courier. +-----+ +-------+ +-------+ +-------+ +-----+ |A | |IM | |SIP | |SIP | |B | | | |Srv X | |proxy X| |proxy Y| | | +-----+ +-------+ +-------+ +-------+ +-----+ | TCP connection | | | | 1 |<-------------->| | | | | INVITE | | | |--------------------------->| INVITE | | | 100 |--------------->| INVITE | |<---------------------------| |-------------->| | |<-----100-------| | | | | | | | | | | | 180 |<-----180------| | 180 |<---------------| | |<---------------------------| | | | | | 200 | | | 200 |<--------------| | 200 |<---------------| | |<---------------------------| | | | | | | |----------ACK-------------->| | | | |------ACK------>| ACK | | | |-------------->| | TCP to home IM | Initiate TCP connection with IM Srv X | |<-------------->|<----------+----------------+---------------| | | | | | | TCP to home IM | TCP connection is established | |<-------------->|<----------+----------------+-------------->| | | | | | | | | | | | | | | | | BYE | | | |--------------------------->| BYE | | | |--------------->| BYE | | | |-------------->| | | | | | | |<----200-------| | 200 |<------200------| | |<---------------------------| | | | | | | This is is the most complicated case so for any other case you should be able to analyze it using the above mentioned analysis. Now let me answer your questions: 1) How would client A within domain X ensure that the local server (IM Server X) is aware that a session with client B in domain Y has been created? After the SIP exchange the client A will convey the session information (Call-ID:, IP address, Port # in SDP, etc.) to its local IM Server via its TCP connection. I know this answer is vague but the details should be specified in the upcoming ID for the IM session. 2) How would the server know that a particular TCP connection from domain Y actually maps into a session with client A within the domain? Well since the IM Server X is aware of the session information (see above answer) it can map the TCP connections. 3) How would the server authenticate that the TCP connection is actually from client B within domain Y? When the client B connects to the IM Server X uses the information received via the INVITE message in order to authenticate. 4) How does the server become aware that client A no longer wishes to receive traffic for this session (i.e. user has closed IM window)? The client A sends a BYE to the client B and tears down the TCP connection. For another implementation (taken from draft-ietf-sip-call-flows-05.txt) please see the diagram below: I wish I knew about it before I wrote the above "rough" scenario :-) 3.1.5 Successful SIP to SIP through SIP Firewall Proxy Please view in a fixed-width font such as Courier. User A IM Server Proxy 1 User B | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | (100) F3 |--------------->| INVITE F4 | |<---------------| (100) F5 |--------------->| | |<---------------| 180 F6 | | | 180 F7 |<---------------| | 180 F8 |<---------------| | |<---------------| | 200 F9 | | | 200 F10 |<---------------| | 200 F11 |<---------------| | |<---------------| | | | ACK F12 | | | |--------------->| ACK F13 | | | |--------------->| ACK F14 | | | |--------------->| | IM Media | Both Way IM Media | |<==============>|<===============================>| | BYE F15 | | | |--------------->| BYE F16 | | | |--------------->| BYE F17 | | | |--------------->| | | | 200 F18 | | | 200 F19 |<---------------| | 200 F20 |<---------------| | |<---------------| | | | | | | Where in the above picture I changed Firewall Proxy to IM Server :-) and RTP Media to IM Media :-) I think this case scenario provides for more specific answers to your questions. I agree with you that we need an Internet draft that will specify all the details of how to initialize IM sessions with SIP and carry IM messages over TCP, SCTP or HTTP. The above examples indicate that such IM system is relatively easy to design. I would be more than happy to help with the production of such ID. My question is, how would you expect this server to work, particularly in the following area:1) How would user X within domain X ensure that the local server is aware that a session with user A in domain A has been created.2) How would the server know that a particular TCP connection from domain A actually maps into a session with user X within the domain3) How would the server authenticate that the TCP connection is actually from user A within domain A4) How does the server become aware that user X no longer wishes to receive traffic for this session (ie user has closed IM window >IM as a session with a TCP or HTTP transport is the right way moving >forward. > >> >> >> Rob O >> From jdrosen@dynamicsoft.com Tue Aug 21 09:31:20 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05541 for ; Tue, 21 Aug 2001 09:31:19 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7LDUPrN005829; Tue, 21 Aug 2001 09:30:25 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 09:31:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'Dean Willis'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Tue, 21 Aug 2001 09:31:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1994 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: > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, August 21, 2001 12:22 AM > To: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Sessions of MESSAGEs > > As for #3, I like it -- I think it has a lot of advantages, > and Robert has > definitely hit on some of them. But not all .For example, at > some point, > we'll have the same kind of "privacy" concerns with message > routing as we > now have with call routing. We'll want suppression of source location > information, network-authenticated remote-party-ID, the > Privacy: header and > its accompanying semantics, etc. Guess what? We've already > figured those out > for SIP "system" messaging, for the most part. These are all arguments for the session model. You still get all of that - privacy protection, network authenticated R-PID, privacy, etc., independently of how the media is transported. The only real argument for SIP transport of the IMs themselves is that you can get nat traversal using proxies. This does not seem to be a strong enough reason, given the other technical problems, and the fact that this traversal is possible with other means, such as the TCP version of the entfw traversal draft. > On the other hand, do we really need a "message session", or > are serialized > "pager messages" with retransmission and in-order assembly by the > application good enough? There are numerous advantages to the session model, which include ease of multiparty conferencing, reduction of the load on the proxy network, ease of transfer, hold, and other sip-supported services, and so on. -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 From bcampbell@dynamicsoft.com Tue Aug 21 11:04:32 2001 Received: from localhost.localdomain ([63.110.3.177]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05869 for ; Tue, 21 Aug 2001 11:04:32 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7LF3XX01208; Tue, 21 Aug 2001 10:03:34 -0500 Message-ID: <3B827845.5030604@dynamicsoft.com> Date: Tue, 21 Aug 2001 10:03:33 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Willis CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: <2E33960095B58E40A4D3345AB9F65EC1460F57@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <01ab01c129f8$c9a0ee80$55fa403f@blazer> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1346 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: Dean Willis wrote: > Ok, there's THREE topics: > > 1) MESSAGE sessions established directly between two nodes using SIP which > is routed by proxies. > 2) MESSAGE transmissions outside of a session routed by proxies ("Pager > mode") > 3) MESSAGE sessions between two nodes, where those messages are routed by > proxies using the routing semantics of any other SIP message. Oddly enough, > this begins to look a lot like BXXP. > Maybe it is to early in the morning for me, but I do not grasp the distinction between 1 and 3. Both appear to reduce to "message sessions over SIP routed by proxies". Perhaps the "routed by proxies" clause in 1 was unintended? [snip] > On the other hand, do we really need a "message session", or are serialized > "pager messages" with retransmission and in-order assembly by the > application good enough? > In all honesty, I hope we do not see a lot of 2 party messsage conversations invoking message sessions. The page model with a little intelligence on the client software's part is usually sufficient. You usually only invoke a session when you need something more than a two party conversation. You use it for N party conversation, or when you want to add and additional media type such as voice or video. For those cases, treating messaging like any other media stream has advantages. From ROBERTO@windows.microsoft.com Tue Aug 21 14:22:40 2001 Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA06557 for ; Tue, 21 Aug 2001 14:22:35 -0400 (EDT) Received: from 157.54.9.101 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 11:21:34 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 11:21:31 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 11:21:30 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 11:21:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Sessions of MESSAGEs Date: Tue, 21 Aug 2001 11:21:16 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1460F5D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs thread-index: AcEqJO4mo3fw1y3VTRy8+hCwUgckEgAR48Vg From: "Robert Osborne" To: "Vasilis Polychronidis" Cc: "Zane Thomas" , X-OriginalArrivalTime: 21 Aug 2001 18:21:17.0047 (UTC) FILETIME=[1170F870:01C12A6E] Content-Length: 9686 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA06557 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: Questions below! -----Original Message----- From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com] Sent: Tuesday, August 21, 2001 2:38 AM To: Robert Osborne Cc: Zane Thomas; simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs Hi Robert, The following is just a rough proposal but I hope will answer your questions. Obviously we need a couple of IDs in order to completely specify the functionality of the IM session proposal. Please see my comments below: Kind Regards, -Vasilis Polychronidis Robert Osborne wrote: Well I do :-) What is simple or is not as objective as we would like to think. After all most of the commercial systems today include (as you clearly explained above) an IM Server (trusted server) and this is how the overcome the NAT issues. [Robert Osborne] Ok, so lets agree to disagree on the simplicity, but agree that a server is required at the domain's edge. Well first let me provide some background information that will make this discussion more precise: 1. For simplicity lets assume the IM Service providers under discussion deployed only IM systems that initiate IM sessions via "normal" SIP operations (Similar way as it is done for VoIP). For other cases please refer to IMPP and CPIM gatewaying. 2. Let us assume that we have two such IM service providers: IM provider X IM provider Y 3. For simplicity lets assume that each provider has each one domain that servers all of its users IM provider X --> simple.OperatorX.net IM provider Y --> simple.OperatorY.net 4. Each user can be addressed by a SIP URL. It is assumed that the operators have deployed a SIP proxy infrastructure for establishing VoIP sessions. Now under these assumptions each operator will have its own IM Server in order to solve the following issues: 1. NAT issues 2. Universal access (mobile, PDA, PC, etc.) 3. Consistency and synchronization 4. Authorization/Authentication 5. "Mobility" of buddy lists 6. Security Operators are very reluctant to deploy a peer to peer model for various reasons that I will not analyze here. Treating IM as a session does not preclude the use of the peer to peer model. So under the above logic and assuming that the operators do not wish to deploy a peer to peer IM system I would agree that each operator will have its own IM Server. Now let me analyze the case where IM User A that is being served by OperatorX wants to set up an IM session with IM User B and start the chat. The following diagram is a rough example that depicts the message flow for establishment of the IM session. The SDP documents carried by the appropriate SIP messages can indicate to B (or A) client to connect to the IM Server X (or IM Server Y) A Client can reside behind Openwave's firewall. B client can reside behind Microsoft's firewall. There is the issue of the OperatorX to allow incoming TCP connections from subscribers other than its own (for example like MSN subs). For additional security OperatorX can deploy a gateway IM Server X' in order to allow interoperability with other Operators. Please view in a fixed-width font such as Courier. +-----+ +-------+ +-------+ +-------+ +-----+ |A | |IM | |SIP | |SIP | |B | | | |Srv X | |proxy X| |proxy Y| | | +-----+ +-------+ +-------+ +-------+ +-----+ | TCP connection | | | | 1 |<-------------->| | | | | INVITE | | | |--------------------------->| INVITE | | | 100 |--------------->| INVITE | |<---------------------------| |-------------->| | |<-----100-------| | | | | | | | | | | | 180 |<-----180------| | 180 |<---------------| | |<---------------------------| | | | | | 200 | | | 200 |<--------------| | 200 |<---------------| | |<---------------------------| | | | | | | |----------ACK-------------->| | | | |------ACK------>| ACK | | | |-------------->| | TCP to home IM | Initiate TCP connection with IM Srv X | |<-------------->|<----------+----------------+---------------| [Robert Osborne] How does B know to connect to IM Srv X? My assumption is that SIP Proxy X would intercept the INVITE and modify the SDP? | | | | | | TCP to home IM | TCP connection is established | |<-------------->|<----------+----------------+-------------->| [Robert Osborne] Actually, in order to get through Y's firewall I would assume there would be an IM Srv Y for that B would connect to, and there would be a connection between IM Srv X and IM Srv Y. This adds to the complexity ;-). | | | | | | | | | | | | | | | | BYE | | | |--------------------------->| BYE | | | |--------------->| BYE | | | |-------------->| | | | | | | |<----200-------| | 200 |<------200------| | |<---------------------------| | | | | | | [Robert Osborne] I also assume there would need to be some communication between the end points and the relevant IM Srv to ensure the session is terminated? This is is the most complicated case so for any other case you should be able to analyze it using the above mentioned analysis. Now let me answer your questions: 1) How would client A within domain X ensure that the local server (IM Server X) is aware that a session with client B in domain Y has been created? After the SIP exchange the client A will convey the session information (Call-ID:, IP address, Port # in SDP, etc.) to its local IM Server via its TCP connection. [Robert Osborne] So basically would this mean sending another form of INVITE with almost the same set of information? I know this answer is vague but the details should be specified in the upcoming ID for the IM session. 2) How would the server know that a particular TCP connection from domain Y actually maps into a session with client A within the domain? Well since the IM Server X is aware of the session information (see above answer) it can map the TCP connections. [Robert Osborne] As per comment above, wouldnt it require all the information that has previously been sent to the SIP Srv? 3) How would the server authenticate that the TCP connection is actually from client B within domain Y? When the client B connects to the IM Server X uses the information received via the INVITE message in order to authenticate. [Robert Osborne] How does IM Srv X know this authentication information, as it was not part of the original INVITE? I assume that A would need to forward everything it receives via the session initiation? 4) How does the server become aware that client A no longer wishes to receive traffic for this session (i.e. user has closed IM window)? The client A sends a BYE to the client B and tears down the TCP connection. [Robert Osborne] I assume that it would not just tear down the connection as there would need to be a chain of servers (IM Srvr X, IM Srvr Y) that would need to tear down the relevant connection? Therefore it would need to send an equivalant of a BYE to IM Srv X, which would send an equivalant of a BYE to IM Srvr Y. I agree with you that we need an Internet draft that will specify all the details of how to initialize IM sessions with SIP and carry IM messages over TCP, SCTP or HTTP. The above examples indicate that such IM system is relatively easy to design. [Robert Osborne] At the high level it appears easy to design, but I still have a lot of reservations about how the "media servers" understand that a session has been created, authenticate any users attempting to connect to this "media server", ensure security, allow clients to communicate session information etc. My belief is that as you have to solve these issues at the signalling layer, why re-invent the wheel. I admit there is a concern that MESSAGEs could become large and therefore clog the server, but these could easily be solved by introducing a limit. Also this problem still exists if you allow paging of MESSAGEs, where a client could just send large MESSAGEs without establishing a session previously. Rob O From roberbr@microsoft.com Tue Aug 21 14:58:43 2001 Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA06687 for ; Tue, 21 Aug 2001 14:58:41 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 11:58:11 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 11:57:46 -0700 content-class: urn:content-classes:message Subject: RE: [Simple] Sessions of MESSAGEs MIME-Version: 1.0 Date: Tue, 21 Aug 2001 11:57:45 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_005A_01C12A38.7D3958D0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320D165@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs Thread-Index: AcEqRrUB+P64c3swT6yFqjCQsIvOagALA7nQ From: "Robert Brown" To: "Jonathan Rosenberg" , "Vasilis Polychronidis" , "Robert Osborne" Cc: "Zane Thomas" , X-OriginalArrivalTime: 21 Aug 2001 18:57:46.0500 (UTC) FILETIME=[2A74FC40:01C12A73] Content-Length: 28837 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: This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C12A38.7D3958D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit One of the other possible issues with this approach is that if TLS is desired, end points will need server certificates so they can terminate TLS connections. I suspect this will be a considerable deployment limitation. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, August 21, 2001 6:24 AM > To: 'Vasilis Polychronidis'; Robert Osborne > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > Vasilis, > > I made a concrete proposal on a mechanism for TCP transport of IM, using a > TCP version of the reflector protocol documented in > draft-rosenberg-sip-entfw-02.txt. I discussed it in the email yesterday: > > http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html > > you seem to be proposing an alternate mechanism (not entirely sure, > though). > Is there any reason you do not support the above approach? As I mentioned > in > the email, by using the discovery/negotiation mechanisms in entfw, we get > the benefit of using direct tcp whenever possible (at least one of the > users > has a direct connection to the Internet (i.e., not natted)), but we work > through nats even in the hard case where both users are natted. > > -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: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com] > Sent: Tuesday, August 21, 2001 5:38 AM > To: Robert Osborne > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Sessions of MESSAGEs > > > Hi Robert, > The following is just a rough proposal but I hope will > answer your questions. > Obviously we need a couple of IDs in order to completely specify the > functionality of the IM session proposal. > Please see my comments below: > Kind Regards, > -Vasilis Polychronidis > Robert Osborne wrote: > Well I do :-) > What is simple or is not as objective as we would like to think. > After all most of the commercial systems today include (as you clearly > explained above) > an IM Server (trusted server) and this is how the overcome the NAT issues. > > [Robert Osborne] Ok, so lets agree to disagree on the simplicity, but > agree > that a server is required at the domain's edge. > Well first let me provide some background information that will make this > discussion more precise: > 1. For simplicity lets assume the IM Service providers under discussion > deployed only IM systems that initiate IM sessions via > "normal" SIP operations (Similar way as it is done for VoIP). For > other > cases please refer to IMPP and CPIM gatewaying. > 2. Let us assume that we have two such IM service providers: > IM provider X > IM provider Y > 3. For simplicity lets assume that each provider has each one domain that > servers all of its users > IM provider X --> simple.OperatorX.net > IM provider Y --> simple.OperatorY.net > 4. Each user can be addressed by a SIP URL. It is assumed that the > operators > have deployed a SIP > proxy infrastructure for establishing VoIP sessions. > Now under these assumptions each operator will have its own IM Server in > order to solve the following issues: > 1. NAT issues > 2. Universal access (mobile, PDA, PC, etc.) > 3. Consistency and synchronization > 4. Authorization/Authentication > 5. "Mobility" of buddy lists > 6. Security > Operators are very reluctant to deploy a peer to peer model for various > reasons that I will not analyze here. > Treating IM as a session does not preclude the use of the peer to peer > model. > So under the above logic and assuming that the operators do not wish to > deploy a peer to peer IM system > I would agree that each operator will have its own IM Server. > Now let me analyze the case where IM User A that is being served by > OperatorX wants to set up an IM > session with IM User B and start the chat. > The following diagram is a rough example that depicts the message flow for > establishment of the IM session. > The SDP documents carried by the appropriate SIP messages can indicate to > B > (or A) client to connect to the IM Server X (or IM Server Y) > A Client can reside behind Openwave's firewall. > B client can reside behind Microsoft's firewall. > There is the issue of the OperatorX to allow incoming TCP connections > from subscribers other than its own (for example like MSN subs). > For additional security OperatorX can deploy a gateway IM Server X' in > order > to allow > interoperability with other Operators. > > Please view in a fixed-width font such as Courier. > +-----+ +-------+ +-------+ +-------+ +-----+ > |A | |IM | |SIP | |SIP | |B | > | | |Srv X | |proxy X| |proxy Y| | | > +-----+ +-------+ +-------+ +-------+ +-----+ > | TCP connection | | | | > 1 |<-------------->| | | | > | INVITE | | | > |--------------------------->| INVITE | | > | 100 |--------------->| INVITE | > |<---------------------------| |-------------->| > | |<-----100-------| | > | | | | > | | | | > | | 180 |<-----180------| > | 180 |<---------------| | > |<---------------------------| | | > | | | 200 | > | | 200 |<--------------| > | 200 |<---------------| | > |<---------------------------| | | > | | | | > |----------ACK-------------->| | | > | |------ACK------>| ACK | > | | |-------------->| > | TCP to home IM | Initiate TCP connection with IM Srv X | > |<-------------->|<----------+----------------+---------------| > | | | | | > | TCP to home IM | TCP connection is established | > |<-------------->|<----------+----------------+-------------->| > | | | | | > | | | | | > | | | | | > | BYE | | | > |--------------------------->| BYE | | > | |--------------->| BYE | > | | |-------------->| > | | | | > | | |<----200-------| > | 200 |<------200------| | > |<---------------------------| | | > | | | | > > This is is the most complicated case so for any other case you should be > able to analyze it using the above mentioned analysis. > Now let me answer your questions: > 1) How would client A within domain X ensure that the local server (IM > Server X) is aware that a session with client B in domain Y > has been created? > After the SIP exchange the client A will convey the session information > (Call-ID:, IP address, Port # in SDP, etc.) to its local IM Server > via its TCP connection. > I know this answer is vague but the details should be specified in the > upcoming ID for the IM session. > 2) How would the server know that a particular TCP connection from domain > Y > actually maps into a session with client A within the domain? > Well since the IM Server X is aware of the session information (see above > answer) it can map the TCP connections. > 3) How would the server authenticate that the TCP connection is actually > from client B within domain Y? > When the client B connects to the IM Server X uses the information > received via the INVITE message in order to authenticate. > 4) How does the server become aware that client A no longer wishes to > receive traffic for this session (i.e. user has closed IM window)? > The client A sends a BYE to the client B and tears down the TCP > connection. > For another implementation (taken from draft-ietf-sip-call-flows-05.txt) > please see the diagram below: > I wish I knew about it before I wrote the above "rough" scenario :-) > 3.1.5 Successful SIP to SIP through SIP Firewall Proxy > Please view in a fixed-width font such as Courier. > User A IM Server Proxy 1 User B > | | | | > | INVITE F1 | | | > |--------------->| INVITE F2 | | > | (100) F3 |--------------->| INVITE F4 | > |<---------------| (100) F5 |--------------->| > | |<---------------| 180 F6 | > | | 180 F7 |<---------------| > | 180 F8 |<---------------| | > |<---------------| | 200 F9 | > | | 200 F10 |<---------------| > | 200 F11 |<---------------| | > |<---------------| | | > | ACK F12 | | | > |--------------->| ACK F13 | | > | |--------------->| ACK F14 | > | | |--------------->| > | IM Media | Both Way IM Media | > |<==============>|<===============================>| > | BYE F15 | | | > |--------------->| BYE F16 | | > | |--------------->| BYE F17 | > | | |--------------->| > | | | 200 F18 | > | | 200 F19 |<---------------| > | 200 F20 |<---------------| | > |<---------------| | | > | | | | > Where in the above picture I changed Firewall Proxy to IM Server :-) > and RTP Media to IM Media :-) > I think this case scenario provides for more specific answers to your > questions. > I agree with you that we need an Internet draft that will specify all the > details of > how to initialize IM sessions with SIP and carry IM messages over TCP, > SCTP > or HTTP. > The above examples indicate that such IM system is relatively easy to > design. > I would be more than happy to help with the production of such ID. > My question is, how would you expect this server to work, particularly in > the following area:1) How would user X within domain X ensure that the > local server is aware that a session with user A in domain A has been > created.2) How would the server know that a particular TCP connection > from domain A actually maps into a session with user X within the domain3) > How would the server authenticate that the TCP connection is actually from > user A within domain A4) How does the server become aware that user X > no > longer wishes to receive traffic for this session (ie user has closed IM > window > >IM as a session with a TCP or HTTP transport is the right way moving > >forward. > > > >> > >> > >> Rob O > >> > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple ------=_NextPart_000_005A_01C12A38.7D3958D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIqDDCCB2ww ggZUoAMCAQICCYpKzgAEAAAa6DANBgkqhkiG9w0BAQUFADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJ VEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1v bmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQg UGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcwOTE3MjUzMVoXDTAyMDEwOTE3MzUzMVowUTES MBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lw aWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtjTd65Df 8iVrq5iSbSg30njDljwoXqEMCBpqB4JdWZ5k+9IF3ordwToVAGxs5mXM9jFcWY8cfbnP6oGtPXcQ f+YzDMwQqQARaxDQ9QFLax8Rw16r5pg3tCK0ZQpOw/M7iegz6I1frUG9VXQGrrnZNYnHmBFNS7Ru lYSKKGoGedMCAwEAAaOCBH4wggR6MB0GA1UdDgQWBBTsnqGiMVuxHoTJ7iR5ApXP/KrDITAfBgNV HSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNVHREEGTAXgRVyb2JlcmJyQG1pY3Jvc29m dC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIw UGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJFRElUR0NBQjA1LENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAs REM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0 Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSggfGGge5sZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUyMEUtTWFpbCUyMENBJTIwMSxDTj1SRURJ VEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDmgN6A1hjNo dHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvbXNwZWNhMS5jcmwwggGDBggr BgEFBQcBAQSCAXUwggFxMIHQBggrBgEFBQcwAoaBw2xkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVy c29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB mwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUucmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5j b20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25kLmNvcnAubWljcm9zb2Z0LmNvbV9NaWNy b3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUyMDEoNCkuY3J0MAwGA1UdEwEB/wQCMAAw CwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAnBgkrBgEEAYI3FAIE Gh4YAEUAeABjAGgAYQBuAGcAZQBVAHMAZQByMA0GCSqGSIb3DQEBBQUAA4IBAQCB0k+uJDbp1E68 bsO+sLj9ByQF3esISCGiP9n7eO6WA/V5sLna4+7wGhOSK+ELvI+muBia4Ib1WrwsXcjE1edy3FGE UTmmOYQhMOeyLwapIHIOEGkDHgWEhEIsrtbUIApMqsl/RmYJoCVI8LFP8cTECqqlkfLOxVW195tT T3fikwuF8xr7Z+NgxzjmbYBWJkabiaoS+H7Kwaodb6HCPJ3TcHVZbbzZPK2nF22Yuj6eOueGwK5U lC/gK5l2kvbMRT9uwS24xt9JoyTJNqSZArCXKB/M3gS4x0oiYtBAI+yzAYRftqXBQGXVtULOaMmx 0lPUeToT57JkGC/vfxj6/WXBMIIHvDCCBqSgAwIBAgIKEDC/8QAEAAAcNzANBgkqhkiG9w0BAQUF ADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcxMjE4 MjE0MFoXDTAyMDExMjE4MzE0MFowUTESMBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0 aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lwaWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAy3lm9JALv4LDed1mg36iAOZHpioL2XED76qNShMdiMcC8i3W+Q03 3J+hxN6yfyoENRVl1tLIWQWVgrQZBtVDnD9LdZMSbER/fKez4FhYcjXdS9YSuAjL7iWAy6H4RGFe /xkNzk+o01J6SxXXbSBIsvF65SHKW8TKNlFmYRjYQD0CAwEAAaOCBM0wggTJMB0GA1UdDgQWBBRK yxFbaT9TWPH1DkqLLMGS8C7kCzAfBgNVHSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNV HREEGTAXgRVyb2JlcmJyQG1pY3Jvc29mdC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB 3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJF RElUR0NBQjA1LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSg gfGGge5sZGFwOi8vY29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUy MEUtTWFpbCUyMENBJTIwMSxDTj1SRURJVEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDmgN6A1hjNodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNwZWNhMS5jcmwwggHABggrBgEFBQcBAQSCAbIwggGuMIHQBggrBgEFBQcwAoaBw2xk YXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBmwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUu cmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25k LmNvcnAubWljcm9zb2Z0LmNvbV9NaWNyb3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUy MDEoNCkuY3J0MDsGCCsGAQUFBzAChi9odHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9tc3BlY2ExLmNydDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwOQYJKwYBBAGCNxQCBCweKgBFAHgAYwBoAGEAbgBnAGUAVQBzAGUAcgBT AGkAZwBuAGEAdAB1AHIAZTANBgkqhkiG9w0BAQUFAAOCAQEAMv7T9pvrp6UXB7O9RFnTSsBuvTBo V97TVmsMf5v4Jex00ggBPBAEDxY+uwryYrQaXCNQk2aIyty7G3/i9M7bK9oynIVzDhjQb48y68t7 MwD2wGC5BhUBuAFs4rIqHIDFoTRPceCLXYDmsx/9P3rzMACc4NO2jshuiwITMHDjrvO1UFvo+Y7y wVrId5WSMbIhvm5xTXvQGbrvDujSKpAkIMLESfXN+2VhWbbH07p1ysQKEv/aUFKHf5zsdDwqCw5+ hOrbCVplYWbbwVLkXicSFWybh11sDt87tM+RM/1ctf8dP6dLibR6PkAEK54+nUVx2MZRxoMgy/Py XsEjvi7M7jCCCFAwggc4oAMCAQICECqYqHcDdOezQZXr4E2bF/YwDQYJKoZIhvcNAQEFBQAwgZ4x ITAfBgkqhkiG9w0BCQEWEnBraXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AldBMRAwDgYDVQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEr MCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0ZSBSb290IEF1dGhvcml0eTAeFw0wMDAyMjUwMTM0 MzlaFw0wODAyMjUwMTQxNTJaMIGeMSEwHwYJKoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20x CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWlj cm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNVBAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBB dXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC271QaJR4cS4M/pGAtU7D1 BUUuMAdaiSwV6lV1OnZ9mLjutGhOXmbiIcestCD1d9hpTOOl6e2TuRo65o4UWEUTAASMUtmLPj9V PVsIP4kx32lW6BhLI6DiAFvL/BrkjOSAibamfUXp/AbCwbX7RQLSf4jZwiQtAYlrPwBr24pMI/WM nJxXlMx/KUsYt627dWkJFkXKVOopS0MdIuYXfz0K6WuSmrLsAbbbuC/kIPBF/SAYJsIs/BGyRmuw yUiWoHDJgi83ZTXSQ1rzSgYhZO9xPL9ZjdI4jeQXIDoCTlIzZyUVbulHzBn58jWbnrSIi2OP7wI/ rxxuBwqjimQlPGZjAgMBAAGjggSGMIIEgjALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQUOYnU1B9o8UWwxpwWxCw6fJ0T50AwggIjBgNVHR8EggIaMIICFjCB5qCB46CB4IaB 3WxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIwUm9vdCUyMEF1dGhvcml0eSxDTj1S RURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMs Q049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIH4oIH1 oIHyhoHvbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUl MjBSb290JTIwQXV0aG9yaXR5LENOPVJFRElUR0NBQTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9z b2Z0LERDPUNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JM RGlzdHJpYnV0aW9uUG9pbnQwMKAuoCyGKmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9tc2NvcnAv bXNjcmExLmNybDAQBgkrBgEEAYI3FQEEAwIBADCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsG AQUFBzAChoHEbGRhcDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9y aXR5LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m aWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8v Y29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRo b3JpdHksQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNv bmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8v d3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IB AQBKfYPOd/2gS3ac9J2sylBGHBlas8dYp6nk+zq3Ml1Pm4L7UkUHTeJW82aPadYbjeWsiHwJgb3A W+YB2iLlKEvvLExH0MOaitwxX5rKDW4G607Yx8KhjE0fK0q3mRd8Xf5zymaxSpKBFSTvh1YI3+WT AiVMSasIr7DuGU0MR4j0DqBE1lHKi60FqCW4kY18oU+jGRQ557DWNi6273zBjY+HH7pB54n8CCFq RNSiStQdu8jlzUCO3eDrEVz9fxRq8T5qrQFod8viyFWLZUZYzWQHibYvKf+aGMGFlRYW2ZP304zI gWcvThTryPsupiHOXGzJZVcybRojwaWdkEkgk7K0MIIIZjCCB06gAwIBAgIKYSDXogAAAAAACjAN BgkqhkiG9w0BAQUFADCBnjEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYD VQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29m dDEMMAoGA1UECxMDSVRHMSswKQYDVQQDEyJNaWNyb3NvZnQgQ29ycG9yYXRlIFJvb3QgQXV0aG9y aXR5MB4XDTAxMDYxODE5NDg0MFoXDTA1MDYxODE5NTg0MFowgZExITAfBgkqhkiG9w0BCQEWEnBr aXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdSZWRt b25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEeMBwGA1UEAxMVTWljcm9zb2Z0 IEV4dHJhbmV0IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw3ayeYZALL1YGLjj t7gEAWw1o2LudM5WWMFCaQtx3gdr4HrZG5064i+ls4UKHjoq8RIz4lnNt/y2qpqpbdT2y8HXICqq SALswJM93//mjtitRwKKKxSd11W1dtKzfbX699za1gP8PUz603wUx+Ojdtwb9HrZcprXAVVt7l+s B+slMjw2el0zqjhUguXbaTbdadMso291Vv3AS3pe+zahIj4RUe8FSu0Rvu5dT91JzDEdPhzC192O PbsQYerq3JDGTBo2dhzkCxolFLjicRmEh48t1PJTR7Tg/QSR/uegAirS/TAg0PJk6Fu7hWepBHzL 80wErx0lqpICzfkUMX2FjwIDAQABo4IErzCCBKswEAYJKwYBBAGCNxUBBAMCAQIwHQYDVR0OBBYE FJl9crx76x52nNzEuwP1X0U2aZX0MAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8EBTADAQH/MB8GA1Ud IwQYMBaAFDmJ1NQfaPFFsMacFsQsOnydE+dAMIICKwYDVR0fBIICIjCCAh4wgeaggeOggeCGgd1s ZGFwOi8vL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049UkVE SVRHQ0FBMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENO PUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCB+KCB9aCB 8oaB72xkYXA6Ly9jb3JwLm1pY3Jvc29mdC5jb20vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIw Um9vdCUyMEF1dGhvcml0eSxDTj1SRURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDigNqA0hjJodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNjcmExLmNybDCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsGAQUFBzAChoHEbGRh cDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9yaXR5LENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049QUlB LENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s REM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8vd3d3Lm1pY3Jvc29m dC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBi7uqxBueATj3M DPlmswvqlWKeuEtaKkI8RKBbFHMAeUIJ+AGoszsUIFsJ3k98kIB29ozHXl7sZoy0zbMMKhOdcyDS 32PvaRwZsFDMF3Kn/uSZjfCrRzB2O/x14j9Oo+fU17IfEBWi7r0Z4wzg/ms0AiVIhbC0a3TBF+uS +e+87SOjXi4FYs9xQPsK5xO0AXVNyyRRzF28eKrdhjCcluby2Vt/OSVutyJE2Nj5ZsrxJjKmLwFy uYojzq6CPdc/BpqOcuyYx6PxKNAR66IM74kIUGkIGdbtyHUxgKfu8c5cQ7UkjtKx1LOLaBQNd0z0 uqvBNce9nkNYFgGECVITNDmvMIIKGjCCCQKgAwIBAgIKYTjfmwACAAAAGjANBgkqhkiG9w0BAQUF ADCBkTEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMR4wHAYDVQQDExVNaWNyb3NvZnQgRXh0cmFuZXQgQ0EwHhcNMDEwNzI3MTc0MDQ1WhcNMDMw NzI3MTc1MDQ1WjCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQG EwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEM MAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxqxYOZd4wOX59OpErK12dai5zHESruOslnVp AWtviLjQJbVRHK5JyZtR4bASg+KWKkcoMXbsqANh1f3laCzfyOcVSb5ks4bMC9CTJZx2L4x4YcWO sJUbJ+xo7QmkxxRde2OBz8xRFSIbqBofj1KwG1LAshnY1qzmW89XHsGfVTkJYlAyH3SUOvV5QMM1 utbONj9A4ibYYeHG+M2qu62dkScRyUZ/yMRPBbivaxINPMnPv0Ni85cgFGfUMvA4yuDuvFaCp0Vp C5Y5WbwK66yZJP3gdPOsmSdHHALlFX02o9MESdpBIrSkz74jpSX0QfmbFx3tHEg1wOurhYd0Ivec vQIDAQABo4IGZjCCBmIwEAYJKwYBBAGCNxUBBAMCAQYwHQYDVR0OBBYEFCenFOBSLgMVjcaskkNk 8J02/IOOMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8E BTADAQH/MIHUBgNVHSMEgcwwgcmAFJl9crx76x52nNzEuwP1X0U2aZX0oYGkpIGhMIGeMSEwHwYJ KoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQ MA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNV BAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBBdXRob3JpdHmCCmEg16IAAAAAAAowggJ9BgNV HR8EggJ0MIICcDCCAmygggJooIICZIaBzmxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwRXh0cmFuZXQl MjBDQSxDTj1SRURJVEdDQUEwMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2Vy dGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50hoHgbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLENOPVJFRElUR0NBQTAzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1T ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnSGMmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL2NybC9tc2VjYTEuY3Jshjto dHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLmNy bIY9ZmlsZTovL1xccmVkaXRnY2FhMDNcQ2VydEVucm9sbFxNaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLmNybDCCApwGCCsGAQUFBwEBBIICjjCCAoowgdQGCCsGAQUFBzAChoHHbGRhcDovL2NvcnAu bWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLENOPUFJQSxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAs REM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPU1pY3Jvc29mdCUyMEV4 dHJhbmV0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5o dHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2VjYTEuY3J0MFYGCCsGAQUFBzAC hkpodHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9yZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBF eHRyYW5ldCUyMENBKDIpLmNydDBYBggrBgEFBQcwAoZMZmlsZTovL1xccmVkaXRnY2FhMDNcQ2Vy dEVucm9sbFxyZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBKDIpLmNydDANBgkq hkiG9w0BAQUFAAOCAQEAPxiA/UabVI27oO7Ub0XffwiBJUPrYCH444I7YLvqfL/cQTMZNUd8g8zc DMntbJRN5fkVFZXma5T8UVXGEFVtrysc5PB63HPbyzBWnGT3U+dHWhkFbUxcuFtCe+s/1Gw2p8rN dUVfhX2IZ4qcS1e7Iydt7OvkIyWlRC/8unOPSVlJGdw1N7wIObuZahO1UIvlNUJjpGoXZ5Q1vW6v D6/QpVx2u/RjlrzfdBapGRC4e8erzwiwrHeQtVUW25QkYyzZvOEc5DHS27YA4OyBkY8cdohq14co O/RNlMpg5orc5DJMLGNNiixwxLnJejf9ldfpGdfXQncaPXgiFtoXvUapuDGCA5cwggOTAgEBMIGq MIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJ VEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25uZWwgRS1NYWlsIENBIDECChAwv/EABAAAHDcw CQYFKw4DAhoFAKCCAkIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDEwODIxMTg1NzQ1WjAjBgkqhkiG9w0BCQQxFgQULgWZjTELE9n8Tgs1lUMIvtq6rPkwZwYJKoZI hvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgboGCSsGAQQBgjcQBDGB rDCBqTCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzEL MAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UE CxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxAgmKSs4ABAAA GugwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jvc29m dC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UE ChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25uZWwg RS1NYWlsIENBIDECCYpKzgAEAAAa6DANBgkqhkiG9w0BAQEFAASBgL7lMBGQz5+OP2zMUZKxXrt6 ef72XhyHPsN9xavBzg1YxTxh7YuWGPyd9UAi58sb0uFnCVKavd8JhWkjfHlnhi5aiiiROvnxvZ8D NFITuwGOXY8tt58aCs/GqBz6gxjHwfBBIvzkuWlWYngKNuQ8nWb4BlgHs6vhml/y8/dFSY2vAAAA AAAA ------=_NextPart_000_005A_01C12A38.7D3958D0-- From jdrosen@dynamicsoft.com Tue Aug 21 15:08:11 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06770 for ; Tue, 21 Aug 2001 15:08:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7LJ79rN009540; Tue, 21 Aug 2001 15:07:09 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 15:07:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Jonathan Rosenberg , Vasilis Polychronidis , Robert Osborne Cc: Zane Thomas , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Tue, 21 Aug 2001 15:07:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2486 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Tuesday, August 21, 2001 2:58 PM > To: Jonathan Rosenberg; Vasilis Polychronidis; Robert Osborne > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > One of the other possible issues with this approach is that if TLS is > desired, end points will need server certificates so they can > terminate > TLS connections. I suspect this will be a considerable deployment > limitation. Huh? TLS does not require me to have the cert of the server I'm connecting to. It only requires that we share a common root CA. The certs are exchanged during the initial handshakes. If you think thats not deployable, then you must conclude that the web is not deployable, since this is exactly how it works there. I don't see how TLS cert management differs in what I am proposing from any other approach which uses a server in the public net for routing traffic. -Jonathan R. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, August 21, 2001 6:24 AM > > To: 'Vasilis Polychronidis'; Robert Osborne > > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Sessions of MESSAGEs > > > > Vasilis, > > > > I made a concrete proposal on a mechanism for TCP transport of IM, > using a > > TCP version of the reflector protocol documented in > > draft-rosenberg-sip-entfw-02.txt. I discussed it in the email > yesterday: > > > > > http://mailman.dynamicsoft.com/pipermail/simple/2001-August/00 > 0606.html > > > > you seem to be proposing an alternate mechanism (not entirely sure, > > though). > > Is there any reason you do not support the above approach? As I > mentioned > > in > > the email, by using the discovery/negotiation mechanisms in > entfw, we > get > > the benefit of using direct tcp whenever possible (at least > one of the > > users > > has a direct connection to the Internet (i.e., not natted)), but we > work > > through nats even in the hard case where both users are natted. > > > > -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 From roberbr@microsoft.com Tue Aug 21 15:13:42 2001 Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA06814 for ; Tue, 21 Aug 2001 15:13:41 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 12:13:19 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 12:12:56 -0700 content-class: urn:content-classes:message Subject: RE: [Simple] Sessions of MESSAGEs MIME-Version: 1.0 Date: Tue, 21 Aug 2001 12:12:55 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_0067_01C12A3A.9BEB6690"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320D169@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs Thread-Index: AcEqdLKYprdbkEapTvWYKre06QVG3wAABRag From: "Robert Brown" To: "Jonathan Rosenberg" , "Vasilis Polychronidis" , "Robert Osborne" Cc: "Zane Thomas" , X-OriginalArrivalTime: 21 Aug 2001 19:12:56.0832 (UTC) FILETIME=[490EA000:01C12A75] Content-Length: 19566 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: This is a multi-part message in MIME format. ------=_NextPart_000_0067_01C12A3A.9BEB6690 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Huh? I don't see how this is anything like how the web works. Very few web users have certs for TLS, except for a very few specialized cases where they are used for user auth. A TLS server cert is the cert that must be at the terminating node of the TLS connection. Are you suggesting that each client have a server cert so it can terminate TLS? > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, August 21, 2001 12:08 PM > To: Robert Brown; Jonathan Rosenberg; Vasilis Polychronidis; Robert > Osborne > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > > -----Original Message----- > > From: Robert Brown [mailto:roberbr@microsoft.com] > > Sent: Tuesday, August 21, 2001 2:58 PM > > To: Jonathan Rosenberg; Vasilis Polychronidis; Robert Osborne > > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > One of the other possible issues with this approach is that if TLS is > > desired, end points will need server certificates so they can > > terminate > > TLS connections. I suspect this will be a considerable deployment > > limitation. > > Huh? TLS does not require me to have the cert of the server I'm connecting > to. It only requires that we share a common root CA. The certs are > exchanged > during the initial handshakes. If you think thats not deployable, then you > must conclude that the web is not deployable, since this is exactly how it > works there. > > I don't see how TLS cert management differs in what I am proposing from > any > other approach which uses a server in the public net for routing traffic. > > -Jonathan R. > > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Tuesday, August 21, 2001 6:24 AM > > > To: 'Vasilis Polychronidis'; Robert Osborne > > > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > Vasilis, > > > > > > I made a concrete proposal on a mechanism for TCP transport of IM, > > using a > > > TCP version of the reflector protocol documented in > > > draft-rosenberg-sip-entfw-02.txt. I discussed it in the email > > yesterday: > > > > > > > > http://mailman.dynamicsoft.com/pipermail/simple/2001-August/00 > > 0606.html > > > > > > you seem to be proposing an alternate mechanism (not entirely sure, > > > though). > > > Is there any reason you do not support the above approach? As I > > mentioned > > > in > > > the email, by using the discovery/negotiation mechanisms in > > entfw, we > > get > > > the benefit of using direct tcp whenever possible (at least > > one of the > > > users > > > has a direct connection to the Internet (i.e., not natted)), but we > > work > > > through nats even in the hard case where both users are natted. > > > > > > -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_000_0067_01C12A3A.9BEB6690 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIqDDCCB2ww ggZUoAMCAQICCYpKzgAEAAAa6DANBgkqhkiG9w0BAQUFADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJ VEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1v bmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQg UGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcwOTE3MjUzMVoXDTAyMDEwOTE3MzUzMVowUTES MBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lw aWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtjTd65Df 8iVrq5iSbSg30njDljwoXqEMCBpqB4JdWZ5k+9IF3ordwToVAGxs5mXM9jFcWY8cfbnP6oGtPXcQ f+YzDMwQqQARaxDQ9QFLax8Rw16r5pg3tCK0ZQpOw/M7iegz6I1frUG9VXQGrrnZNYnHmBFNS7Ru lYSKKGoGedMCAwEAAaOCBH4wggR6MB0GA1UdDgQWBBTsnqGiMVuxHoTJ7iR5ApXP/KrDITAfBgNV HSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNVHREEGTAXgRVyb2JlcmJyQG1pY3Jvc29m dC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIw UGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJFRElUR0NBQjA1LENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAs REM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0 Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSggfGGge5sZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUyMEUtTWFpbCUyMENBJTIwMSxDTj1SRURJ VEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDmgN6A1hjNo dHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvbXNwZWNhMS5jcmwwggGDBggr BgEFBQcBAQSCAXUwggFxMIHQBggrBgEFBQcwAoaBw2xkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVy c29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB mwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUucmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5j b20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25kLmNvcnAubWljcm9zb2Z0LmNvbV9NaWNy b3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUyMDEoNCkuY3J0MAwGA1UdEwEB/wQCMAAw CwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAnBgkrBgEEAYI3FAIE Gh4YAEUAeABjAGgAYQBuAGcAZQBVAHMAZQByMA0GCSqGSIb3DQEBBQUAA4IBAQCB0k+uJDbp1E68 bsO+sLj9ByQF3esISCGiP9n7eO6WA/V5sLna4+7wGhOSK+ELvI+muBia4Ib1WrwsXcjE1edy3FGE UTmmOYQhMOeyLwapIHIOEGkDHgWEhEIsrtbUIApMqsl/RmYJoCVI8LFP8cTECqqlkfLOxVW195tT T3fikwuF8xr7Z+NgxzjmbYBWJkabiaoS+H7Kwaodb6HCPJ3TcHVZbbzZPK2nF22Yuj6eOueGwK5U lC/gK5l2kvbMRT9uwS24xt9JoyTJNqSZArCXKB/M3gS4x0oiYtBAI+yzAYRftqXBQGXVtULOaMmx 0lPUeToT57JkGC/vfxj6/WXBMIIHvDCCBqSgAwIBAgIKEDC/8QAEAAAcNzANBgkqhkiG9w0BAQUF ADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcxMjE4 MjE0MFoXDTAyMDExMjE4MzE0MFowUTESMBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0 aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lwaWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAy3lm9JALv4LDed1mg36iAOZHpioL2XED76qNShMdiMcC8i3W+Q03 3J+hxN6yfyoENRVl1tLIWQWVgrQZBtVDnD9LdZMSbER/fKez4FhYcjXdS9YSuAjL7iWAy6H4RGFe /xkNzk+o01J6SxXXbSBIsvF65SHKW8TKNlFmYRjYQD0CAwEAAaOCBM0wggTJMB0GA1UdDgQWBBRK yxFbaT9TWPH1DkqLLMGS8C7kCzAfBgNVHSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNV HREEGTAXgRVyb2JlcmJyQG1pY3Jvc29mdC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB 3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJF RElUR0NBQjA1LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSg gfGGge5sZGFwOi8vY29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUy MEUtTWFpbCUyMENBJTIwMSxDTj1SRURJVEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDmgN6A1hjNodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNwZWNhMS5jcmwwggHABggrBgEFBQcBAQSCAbIwggGuMIHQBggrBgEFBQcwAoaBw2xk YXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBmwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUu cmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25k LmNvcnAubWljcm9zb2Z0LmNvbV9NaWNyb3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUy MDEoNCkuY3J0MDsGCCsGAQUFBzAChi9odHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9tc3BlY2ExLmNydDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwOQYJKwYBBAGCNxQCBCweKgBFAHgAYwBoAGEAbgBnAGUAVQBzAGUAcgBT AGkAZwBuAGEAdAB1AHIAZTANBgkqhkiG9w0BAQUFAAOCAQEAMv7T9pvrp6UXB7O9RFnTSsBuvTBo V97TVmsMf5v4Jex00ggBPBAEDxY+uwryYrQaXCNQk2aIyty7G3/i9M7bK9oynIVzDhjQb48y68t7 MwD2wGC5BhUBuAFs4rIqHIDFoTRPceCLXYDmsx/9P3rzMACc4NO2jshuiwITMHDjrvO1UFvo+Y7y wVrId5WSMbIhvm5xTXvQGbrvDujSKpAkIMLESfXN+2VhWbbH07p1ysQKEv/aUFKHf5zsdDwqCw5+ hOrbCVplYWbbwVLkXicSFWybh11sDt87tM+RM/1ctf8dP6dLibR6PkAEK54+nUVx2MZRxoMgy/Py XsEjvi7M7jCCCFAwggc4oAMCAQICECqYqHcDdOezQZXr4E2bF/YwDQYJKoZIhvcNAQEFBQAwgZ4x ITAfBgkqhkiG9w0BCQEWEnBraXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AldBMRAwDgYDVQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEr MCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0ZSBSb290IEF1dGhvcml0eTAeFw0wMDAyMjUwMTM0 MzlaFw0wODAyMjUwMTQxNTJaMIGeMSEwHwYJKoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20x CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWlj cm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNVBAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBB dXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC271QaJR4cS4M/pGAtU7D1 BUUuMAdaiSwV6lV1OnZ9mLjutGhOXmbiIcestCD1d9hpTOOl6e2TuRo65o4UWEUTAASMUtmLPj9V PVsIP4kx32lW6BhLI6DiAFvL/BrkjOSAibamfUXp/AbCwbX7RQLSf4jZwiQtAYlrPwBr24pMI/WM nJxXlMx/KUsYt627dWkJFkXKVOopS0MdIuYXfz0K6WuSmrLsAbbbuC/kIPBF/SAYJsIs/BGyRmuw yUiWoHDJgi83ZTXSQ1rzSgYhZO9xPL9ZjdI4jeQXIDoCTlIzZyUVbulHzBn58jWbnrSIi2OP7wI/ rxxuBwqjimQlPGZjAgMBAAGjggSGMIIEgjALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQUOYnU1B9o8UWwxpwWxCw6fJ0T50AwggIjBgNVHR8EggIaMIICFjCB5qCB46CB4IaB 3WxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIwUm9vdCUyMEF1dGhvcml0eSxDTj1S RURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMs Q049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIH4oIH1 oIHyhoHvbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUl MjBSb290JTIwQXV0aG9yaXR5LENOPVJFRElUR0NBQTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9z b2Z0LERDPUNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JM RGlzdHJpYnV0aW9uUG9pbnQwMKAuoCyGKmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9tc2NvcnAv bXNjcmExLmNybDAQBgkrBgEEAYI3FQEEAwIBADCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsG AQUFBzAChoHEbGRhcDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9y aXR5LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m aWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8v Y29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRo b3JpdHksQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNv bmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8v d3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IB AQBKfYPOd/2gS3ac9J2sylBGHBlas8dYp6nk+zq3Ml1Pm4L7UkUHTeJW82aPadYbjeWsiHwJgb3A W+YB2iLlKEvvLExH0MOaitwxX5rKDW4G607Yx8KhjE0fK0q3mRd8Xf5zymaxSpKBFSTvh1YI3+WT AiVMSasIr7DuGU0MR4j0DqBE1lHKi60FqCW4kY18oU+jGRQ557DWNi6273zBjY+HH7pB54n8CCFq RNSiStQdu8jlzUCO3eDrEVz9fxRq8T5qrQFod8viyFWLZUZYzWQHibYvKf+aGMGFlRYW2ZP304zI gWcvThTryPsupiHOXGzJZVcybRojwaWdkEkgk7K0MIIIZjCCB06gAwIBAgIKYSDXogAAAAAACjAN BgkqhkiG9w0BAQUFADCBnjEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYD VQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29m dDEMMAoGA1UECxMDSVRHMSswKQYDVQQDEyJNaWNyb3NvZnQgQ29ycG9yYXRlIFJvb3QgQXV0aG9y aXR5MB4XDTAxMDYxODE5NDg0MFoXDTA1MDYxODE5NTg0MFowgZExITAfBgkqhkiG9w0BCQEWEnBr aXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdSZWRt b25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEeMBwGA1UEAxMVTWljcm9zb2Z0 IEV4dHJhbmV0IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw3ayeYZALL1YGLjj t7gEAWw1o2LudM5WWMFCaQtx3gdr4HrZG5064i+ls4UKHjoq8RIz4lnNt/y2qpqpbdT2y8HXICqq SALswJM93//mjtitRwKKKxSd11W1dtKzfbX699za1gP8PUz603wUx+Ojdtwb9HrZcprXAVVt7l+s B+slMjw2el0zqjhUguXbaTbdadMso291Vv3AS3pe+zahIj4RUe8FSu0Rvu5dT91JzDEdPhzC192O PbsQYerq3JDGTBo2dhzkCxolFLjicRmEh48t1PJTR7Tg/QSR/uegAirS/TAg0PJk6Fu7hWepBHzL 80wErx0lqpICzfkUMX2FjwIDAQABo4IErzCCBKswEAYJKwYBBAGCNxUBBAMCAQIwHQYDVR0OBBYE FJl9crx76x52nNzEuwP1X0U2aZX0MAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8EBTADAQH/MB8GA1Ud IwQYMBaAFDmJ1NQfaPFFsMacFsQsOnydE+dAMIICKwYDVR0fBIICIjCCAh4wgeaggeOggeCGgd1s ZGFwOi8vL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049UkVE SVRHQ0FBMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENO PUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCB+KCB9aCB 8oaB72xkYXA6Ly9jb3JwLm1pY3Jvc29mdC5jb20vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIw Um9vdCUyMEF1dGhvcml0eSxDTj1SRURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDigNqA0hjJodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNjcmExLmNybDCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsGAQUFBzAChoHEbGRh cDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9yaXR5LENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049QUlB LENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s REM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8vd3d3Lm1pY3Jvc29m dC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBi7uqxBueATj3M DPlmswvqlWKeuEtaKkI8RKBbFHMAeUIJ+AGoszsUIFsJ3k98kIB29ozHXl7sZoy0zbMMKhOdcyDS 32PvaRwZsFDMF3Kn/uSZjfCrRzB2O/x14j9Oo+fU17IfEBWi7r0Z4wzg/ms0AiVIhbC0a3TBF+uS +e+87SOjXi4FYs9xQPsK5xO0AXVNyyRRzF28eKrdhjCcluby2Vt/OSVutyJE2Nj5ZsrxJjKmLwFy uYojzq6CPdc/BpqOcuyYx6PxKNAR66IM74kIUGkIGdbtyHUxgKfu8c5cQ7UkjtKx1LOLaBQNd0z0 uqvBNce9nkNYFgGECVITNDmvMIIKGjCCCQKgAwIBAgIKYTjfmwACAAAAGjANBgkqhkiG9w0BAQUF ADCBkTEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMR4wHAYDVQQDExVNaWNyb3NvZnQgRXh0cmFuZXQgQ0EwHhcNMDEwNzI3MTc0MDQ1WhcNMDMw NzI3MTc1MDQ1WjCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQG EwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEM MAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxqxYOZd4wOX59OpErK12dai5zHESruOslnVp AWtviLjQJbVRHK5JyZtR4bASg+KWKkcoMXbsqANh1f3laCzfyOcVSb5ks4bMC9CTJZx2L4x4YcWO sJUbJ+xo7QmkxxRde2OBz8xRFSIbqBofj1KwG1LAshnY1qzmW89XHsGfVTkJYlAyH3SUOvV5QMM1 utbONj9A4ibYYeHG+M2qu62dkScRyUZ/yMRPBbivaxINPMnPv0Ni85cgFGfUMvA4yuDuvFaCp0Vp C5Y5WbwK66yZJP3gdPOsmSdHHALlFX02o9MESdpBIrSkz74jpSX0QfmbFx3tHEg1wOurhYd0Ivec vQIDAQABo4IGZjCCBmIwEAYJKwYBBAGCNxUBBAMCAQYwHQYDVR0OBBYEFCenFOBSLgMVjcaskkNk 8J02/IOOMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8E BTADAQH/MIHUBgNVHSMEgcwwgcmAFJl9crx76x52nNzEuwP1X0U2aZX0oYGkpIGhMIGeMSEwHwYJ KoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQ MA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNV BAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBBdXRob3JpdHmCCmEg16IAAAAAAAowggJ9BgNV HR8EggJ0MIICcDCCAmygggJooIICZIaBzmxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwRXh0cmFuZXQl MjBDQSxDTj1SRURJVEdDQUEwMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2Vy dGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50hoHgbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLENOPVJFRElUR0NBQTAzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1T ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnSGMmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL2NybC9tc2VjYTEuY3Jshjto dHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLmNy bIY9ZmlsZTovL1xccmVkaXRnY2FhMDNcQ2VydEVucm9sbFxNaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLmNybDCCApwGCCsGAQUFBwEBBIICjjCCAoowgdQGCCsGAQUFBzAChoHHbGRhcDovL2NvcnAu bWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLENOPUFJQSxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAs REM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPU1pY3Jvc29mdCUyMEV4 dHJhbmV0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5o dHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2VjYTEuY3J0MFYGCCsGAQUFBzAC hkpodHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9yZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBF eHRyYW5ldCUyMENBKDIpLmNydDBYBggrBgEFBQcwAoZMZmlsZTovL1xccmVkaXRnY2FhMDNcQ2Vy dEVucm9sbFxyZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBKDIpLmNydDANBgkq hkiG9w0BAQUFAAOCAQEAPxiA/UabVI27oO7Ub0XffwiBJUPrYCH444I7YLvqfL/cQTMZNUd8g8zc DMntbJRN5fkVFZXma5T8UVXGEFVtrysc5PB63HPbyzBWnGT3U+dHWhkFbUxcuFtCe+s/1Gw2p8rN dUVfhX2IZ4qcS1e7Iydt7OvkIyWlRC/8unOPSVlJGdw1N7wIObuZahO1UIvlNUJjpGoXZ5Q1vW6v D6/QpVx2u/RjlrzfdBapGRC4e8erzwiwrHeQtVUW25QkYyzZvOEc5DHS27YA4OyBkY8cdohq14co O/RNlMpg5orc5DJMLGNNiixwxLnJejf9ldfpGdfXQncaPXgiFtoXvUapuDGCA5cwggOTAgEBMIGq MIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJ VEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25uZWwgRS1NYWlsIENBIDECChAwv/EABAAAHDcw CQYFKw4DAhoFAKCCAkIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDEwODIxMTkxMjU1WjAjBgkqhkiG9w0BCQQxFgQUN5cgLDAHye19oonp7xOhXS3DuqEwZwYJKoZI hvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgboGCSsGAQQBgjcQBDGB rDCBqTCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzEL MAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UE CxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxAgmKSs4ABAAA GugwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jvc29m dC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UE ChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25uZWwg RS1NYWlsIENBIDECCYpKzgAEAAAa6DANBgkqhkiG9w0BAQEFAASBgF2d70iJghimZ+FkUNAcz6HF Y9DwgqVGoi+gc5w9qmVNi4WA/k2KZH5unT/1sXehs1Iypi7Z/wx8GahMTUf+sfegYiZGqcDTD8cF 26BLSs4kFc2YGkq+t42kL0XrTshkumcXVAFNH2a7RecM6Nvtvn2khy3FLjXxTlHdLG8aibTwAAAA AAAA ------=_NextPart_000_0067_01C12A3A.9BEB6690-- From jdrosen@dynamicsoft.com Tue Aug 21 15:23:01 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06874 for ; Tue, 21 Aug 2001 15:23:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7LJM6rN009750; Tue, 21 Aug 2001 15:22:06 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 15:22:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'Robert Brown'" , Jonathan Rosenberg , Vasilis Polychronidis , Robert Osborne Cc: Zane Thomas , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Tue, 21 Aug 2001 15:22:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 2030 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Tuesday, August 21, 2001 3:13 PM > To: Jonathan Rosenberg; Vasilis Polychronidis; Robert Osborne > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > Huh? > > I don't see how this is anything like how the web works. Very few web > users have certs for TLS, except for a very few specialized > cases where > they are used for user auth. I think we are talking past each other. In my proposal, there *is* a server in the public network. This server is needed for nat traversal if both are behind a nat. In that case, each client would have a tls connection to that server, and it is only the server which needs to have a cert. This is standard web stuff, and thats what I was talking about. In the case of direct communication between clients, yes, this will be an issue for TLS as it would require client certs, which is not that common. This is a problem shared by all e2e encryption/authentication mechanisms. There is work on defining SDP extensions for negotiation of session keys (primarily for SRTP), and some of the key management mechanisms don't require certs, but rather, just shared secrets. It would be nice to be able to use that key management stuff for transport beyond SRTP, such as whatever we define for IM. However, if you want secure IM and trust that server in the cloud, you can simply elect not to use direct communications even if possible. The signaling mechanisms in entfw and the drafts it depends on (i.e., comedia) support that. So, you get best of both worlds, from what I can tell.... -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 From roberbr@microsoft.com Tue Aug 21 20:27:27 2001 Received: from INET-VRS-06.redmond.corp.microsoft.com ([131.107.3.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id UAA07743 for ; Tue, 21 Aug 2001 20:27:23 -0400 (EDT) Received: from 157.54.7.67 by INET-VRS-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 17:27:01 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 17:27:00 -0700 content-class: urn:content-classes:message Subject: RE: [Simple] Sessions of MESSAGEs MIME-Version: 1.0 Date: Tue, 21 Aug 2001 17:27:00 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_0123_01C12A66.7825AB90"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320D17B@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs Thread-Index: AcEqdsU+G6jSae78TyezPTHZ8QYeNAAJlgCg From: "Robert Brown" To: "Jonathan Rosenberg" , "Vasilis Polychronidis" , "Robert Osborne" Cc: "Zane Thomas" , X-OriginalArrivalTime: 22 Aug 2001 00:27:00.0797 (UTC) FILETIME=[28EF7ED0:01C12AA1] Content-Length: 19465 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: This is a multi-part message in MIME format. ------=_NextPart_000_0123_01C12A66.7825AB90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit OK. I understand your proposal. Yes, I think we were talking past each other. However, I am concerned that such an approach will not be widely deployed, as it also requires deployment of a firewall/NAT traversal server (such as draft-rosenberg-sip-entfw-02) adjacent to every firewall/NAT that exists between two end points. In other words, if the assumption is that there is a server in the public network, this will only work for Internet-based services (like MSN and AOL) or for organizations with liberal-minded firewall administrators (rare by definition). An in-band solution will be far more deployable, as it requires all the common problems (like routing, authentication, firewall configuration, etc) to be solved only once. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, August 21, 2001 12:23 PM > To: Robert Brown; Jonathan Rosenberg; Vasilis Polychronidis; Robert > Osborne > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > > -----Original Message----- > > From: Robert Brown [mailto:roberbr@microsoft.com] > > Sent: Tuesday, August 21, 2001 3:13 PM > > To: Jonathan Rosenberg; Vasilis Polychronidis; Robert Osborne > > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > Huh? > > > > I don't see how this is anything like how the web works. Very few web > > users have certs for TLS, except for a very few specialized > > cases where > > they are used for user auth. > > I think we are talking past each other. > > In my proposal, there *is* a server in the public network. This server is > needed for nat traversal if both are behind a nat. In that case, each > client > would have a tls connection to that server, and it is only the server > which > needs to have a cert. This is standard web stuff, and thats what I was > talking about. > > In the case of direct communication between clients, yes, this will be an > issue for TLS as it would require client certs, which is not that common. > This is a problem shared by all e2e encryption/authentication mechanisms. > There is work on defining SDP extensions for negotiation of session keys > (primarily for SRTP), and some of the key management mechanisms don't > require certs, but rather, just shared secrets. It would be nice to be > able > to use that key management stuff for transport beyond SRTP, such as > whatever > we define for IM. > > However, if you want secure IM and trust that server in the cloud, you can > simply elect not to use direct communications even if possible. The > signaling mechanisms in entfw and the drafts it depends on (i.e., comedia) > support that. > > So, you get best of both worlds, from what I can tell.... > > -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_000_0123_01C12A66.7825AB90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIqDDCCB2ww ggZUoAMCAQICCYpKzgAEAAAa6DANBgkqhkiG9w0BAQUFADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJ VEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1v bmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQg UGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcwOTE3MjUzMVoXDTAyMDEwOTE3MzUzMVowUTES MBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lw aWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtjTd65Df 8iVrq5iSbSg30njDljwoXqEMCBpqB4JdWZ5k+9IF3ordwToVAGxs5mXM9jFcWY8cfbnP6oGtPXcQ f+YzDMwQqQARaxDQ9QFLax8Rw16r5pg3tCK0ZQpOw/M7iegz6I1frUG9VXQGrrnZNYnHmBFNS7Ru lYSKKGoGedMCAwEAAaOCBH4wggR6MB0GA1UdDgQWBBTsnqGiMVuxHoTJ7iR5ApXP/KrDITAfBgNV HSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNVHREEGTAXgRVyb2JlcmJyQG1pY3Jvc29m dC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIw UGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJFRElUR0NBQjA1LENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAs REM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0 Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSggfGGge5sZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUyMEUtTWFpbCUyMENBJTIwMSxDTj1SRURJ VEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDmgN6A1hjNo dHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvbXNwZWNhMS5jcmwwggGDBggr BgEFBQcBAQSCAXUwggFxMIHQBggrBgEFBQcwAoaBw2xkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVy c29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB mwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUucmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5j b20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25kLmNvcnAubWljcm9zb2Z0LmNvbV9NaWNy b3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUyMDEoNCkuY3J0MAwGA1UdEwEB/wQCMAAw CwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAnBgkrBgEEAYI3FAIE Gh4YAEUAeABjAGgAYQBuAGcAZQBVAHMAZQByMA0GCSqGSIb3DQEBBQUAA4IBAQCB0k+uJDbp1E68 bsO+sLj9ByQF3esISCGiP9n7eO6WA/V5sLna4+7wGhOSK+ELvI+muBia4Ib1WrwsXcjE1edy3FGE UTmmOYQhMOeyLwapIHIOEGkDHgWEhEIsrtbUIApMqsl/RmYJoCVI8LFP8cTECqqlkfLOxVW195tT T3fikwuF8xr7Z+NgxzjmbYBWJkabiaoS+H7Kwaodb6HCPJ3TcHVZbbzZPK2nF22Yuj6eOueGwK5U lC/gK5l2kvbMRT9uwS24xt9JoyTJNqSZArCXKB/M3gS4x0oiYtBAI+yzAYRftqXBQGXVtULOaMmx 0lPUeToT57JkGC/vfxj6/WXBMIIHvDCCBqSgAwIBAgIKEDC/8QAEAAAcNzANBgkqhkiG9w0BAQUF ADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcxMjE4 MjE0MFoXDTAyMDExMjE4MzE0MFowUTESMBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0 aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lwaWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAy3lm9JALv4LDed1mg36iAOZHpioL2XED76qNShMdiMcC8i3W+Q03 3J+hxN6yfyoENRVl1tLIWQWVgrQZBtVDnD9LdZMSbER/fKez4FhYcjXdS9YSuAjL7iWAy6H4RGFe /xkNzk+o01J6SxXXbSBIsvF65SHKW8TKNlFmYRjYQD0CAwEAAaOCBM0wggTJMB0GA1UdDgQWBBRK yxFbaT9TWPH1DkqLLMGS8C7kCzAfBgNVHSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNV HREEGTAXgRVyb2JlcmJyQG1pY3Jvc29mdC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB 3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJF RElUR0NBQjA1LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSg gfGGge5sZGFwOi8vY29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUy MEUtTWFpbCUyMENBJTIwMSxDTj1SRURJVEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDmgN6A1hjNodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNwZWNhMS5jcmwwggHABggrBgEFBQcBAQSCAbIwggGuMIHQBggrBgEFBQcwAoaBw2xk YXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBmwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUu cmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25k LmNvcnAubWljcm9zb2Z0LmNvbV9NaWNyb3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUy MDEoNCkuY3J0MDsGCCsGAQUFBzAChi9odHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9tc3BlY2ExLmNydDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwOQYJKwYBBAGCNxQCBCweKgBFAHgAYwBoAGEAbgBnAGUAVQBzAGUAcgBT AGkAZwBuAGEAdAB1AHIAZTANBgkqhkiG9w0BAQUFAAOCAQEAMv7T9pvrp6UXB7O9RFnTSsBuvTBo V97TVmsMf5v4Jex00ggBPBAEDxY+uwryYrQaXCNQk2aIyty7G3/i9M7bK9oynIVzDhjQb48y68t7 MwD2wGC5BhUBuAFs4rIqHIDFoTRPceCLXYDmsx/9P3rzMACc4NO2jshuiwITMHDjrvO1UFvo+Y7y wVrId5WSMbIhvm5xTXvQGbrvDujSKpAkIMLESfXN+2VhWbbH07p1ysQKEv/aUFKHf5zsdDwqCw5+ hOrbCVplYWbbwVLkXicSFWybh11sDt87tM+RM/1ctf8dP6dLibR6PkAEK54+nUVx2MZRxoMgy/Py XsEjvi7M7jCCCFAwggc4oAMCAQICECqYqHcDdOezQZXr4E2bF/YwDQYJKoZIhvcNAQEFBQAwgZ4x ITAfBgkqhkiG9w0BCQEWEnBraXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AldBMRAwDgYDVQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEr MCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0ZSBSb290IEF1dGhvcml0eTAeFw0wMDAyMjUwMTM0 MzlaFw0wODAyMjUwMTQxNTJaMIGeMSEwHwYJKoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20x CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWlj cm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNVBAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBB dXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC271QaJR4cS4M/pGAtU7D1 BUUuMAdaiSwV6lV1OnZ9mLjutGhOXmbiIcestCD1d9hpTOOl6e2TuRo65o4UWEUTAASMUtmLPj9V PVsIP4kx32lW6BhLI6DiAFvL/BrkjOSAibamfUXp/AbCwbX7RQLSf4jZwiQtAYlrPwBr24pMI/WM nJxXlMx/KUsYt627dWkJFkXKVOopS0MdIuYXfz0K6WuSmrLsAbbbuC/kIPBF/SAYJsIs/BGyRmuw yUiWoHDJgi83ZTXSQ1rzSgYhZO9xPL9ZjdI4jeQXIDoCTlIzZyUVbulHzBn58jWbnrSIi2OP7wI/ rxxuBwqjimQlPGZjAgMBAAGjggSGMIIEgjALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQUOYnU1B9o8UWwxpwWxCw6fJ0T50AwggIjBgNVHR8EggIaMIICFjCB5qCB46CB4IaB 3WxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIwUm9vdCUyMEF1dGhvcml0eSxDTj1S RURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMs Q049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIH4oIH1 oIHyhoHvbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUl MjBSb290JTIwQXV0aG9yaXR5LENOPVJFRElUR0NBQTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9z b2Z0LERDPUNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JM RGlzdHJpYnV0aW9uUG9pbnQwMKAuoCyGKmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9tc2NvcnAv bXNjcmExLmNybDAQBgkrBgEEAYI3FQEEAwIBADCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsG AQUFBzAChoHEbGRhcDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9y aXR5LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m aWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8v Y29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRo b3JpdHksQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNv bmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8v d3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IB AQBKfYPOd/2gS3ac9J2sylBGHBlas8dYp6nk+zq3Ml1Pm4L7UkUHTeJW82aPadYbjeWsiHwJgb3A W+YB2iLlKEvvLExH0MOaitwxX5rKDW4G607Yx8KhjE0fK0q3mRd8Xf5zymaxSpKBFSTvh1YI3+WT AiVMSasIr7DuGU0MR4j0DqBE1lHKi60FqCW4kY18oU+jGRQ557DWNi6273zBjY+HH7pB54n8CCFq RNSiStQdu8jlzUCO3eDrEVz9fxRq8T5qrQFod8viyFWLZUZYzWQHibYvKf+aGMGFlRYW2ZP304zI gWcvThTryPsupiHOXGzJZVcybRojwaWdkEkgk7K0MIIIZjCCB06gAwIBAgIKYSDXogAAAAAACjAN BgkqhkiG9w0BAQUFADCBnjEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYD VQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29m dDEMMAoGA1UECxMDSVRHMSswKQYDVQQDEyJNaWNyb3NvZnQgQ29ycG9yYXRlIFJvb3QgQXV0aG9y aXR5MB4XDTAxMDYxODE5NDg0MFoXDTA1MDYxODE5NTg0MFowgZExITAfBgkqhkiG9w0BCQEWEnBr aXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdSZWRt b25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEeMBwGA1UEAxMVTWljcm9zb2Z0 IEV4dHJhbmV0IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw3ayeYZALL1YGLjj t7gEAWw1o2LudM5WWMFCaQtx3gdr4HrZG5064i+ls4UKHjoq8RIz4lnNt/y2qpqpbdT2y8HXICqq SALswJM93//mjtitRwKKKxSd11W1dtKzfbX699za1gP8PUz603wUx+Ojdtwb9HrZcprXAVVt7l+s B+slMjw2el0zqjhUguXbaTbdadMso291Vv3AS3pe+zahIj4RUe8FSu0Rvu5dT91JzDEdPhzC192O PbsQYerq3JDGTBo2dhzkCxolFLjicRmEh48t1PJTR7Tg/QSR/uegAirS/TAg0PJk6Fu7hWepBHzL 80wErx0lqpICzfkUMX2FjwIDAQABo4IErzCCBKswEAYJKwYBBAGCNxUBBAMCAQIwHQYDVR0OBBYE FJl9crx76x52nNzEuwP1X0U2aZX0MAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8EBTADAQH/MB8GA1Ud IwQYMBaAFDmJ1NQfaPFFsMacFsQsOnydE+dAMIICKwYDVR0fBIICIjCCAh4wgeaggeOggeCGgd1s ZGFwOi8vL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049UkVE SVRHQ0FBMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENO PUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCB+KCB9aCB 8oaB72xkYXA6Ly9jb3JwLm1pY3Jvc29mdC5jb20vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIw Um9vdCUyMEF1dGhvcml0eSxDTj1SRURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDigNqA0hjJodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNjcmExLmNybDCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsGAQUFBzAChoHEbGRh cDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9yaXR5LENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049QUlB LENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s REM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8vd3d3Lm1pY3Jvc29m dC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBi7uqxBueATj3M DPlmswvqlWKeuEtaKkI8RKBbFHMAeUIJ+AGoszsUIFsJ3k98kIB29ozHXl7sZoy0zbMMKhOdcyDS 32PvaRwZsFDMF3Kn/uSZjfCrRzB2O/x14j9Oo+fU17IfEBWi7r0Z4wzg/ms0AiVIhbC0a3TBF+uS +e+87SOjXi4FYs9xQPsK5xO0AXVNyyRRzF28eKrdhjCcluby2Vt/OSVutyJE2Nj5ZsrxJjKmLwFy uYojzq6CPdc/BpqOcuyYx6PxKNAR66IM74kIUGkIGdbtyHUxgKfu8c5cQ7UkjtKx1LOLaBQNd0z0 uqvBNce9nkNYFgGECVITNDmvMIIKGjCCCQKgAwIBAgIKYTjfmwACAAAAGjANBgkqhkiG9w0BAQUF ADCBkTEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMR4wHAYDVQQDExVNaWNyb3NvZnQgRXh0cmFuZXQgQ0EwHhcNMDEwNzI3MTc0MDQ1WhcNMDMw NzI3MTc1MDQ1WjCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQG EwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEM MAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxqxYOZd4wOX59OpErK12dai5zHESruOslnVp AWtviLjQJbVRHK5JyZtR4bASg+KWKkcoMXbsqANh1f3laCzfyOcVSb5ks4bMC9CTJZx2L4x4YcWO sJUbJ+xo7QmkxxRde2OBz8xRFSIbqBofj1KwG1LAshnY1qzmW89XHsGfVTkJYlAyH3SUOvV5QMM1 utbONj9A4ibYYeHG+M2qu62dkScRyUZ/yMRPBbivaxINPMnPv0Ni85cgFGfUMvA4yuDuvFaCp0Vp C5Y5WbwK66yZJP3gdPOsmSdHHALlFX02o9MESdpBIrSkz74jpSX0QfmbFx3tHEg1wOurhYd0Ivec vQIDAQABo4IGZjCCBmIwEAYJKwYBBAGCNxUBBAMCAQYwHQYDVR0OBBYEFCenFOBSLgMVjcaskkNk 8J02/IOOMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8E BTADAQH/MIHUBgNVHSMEgcwwgcmAFJl9crx76x52nNzEuwP1X0U2aZX0oYGkpIGhMIGeMSEwHwYJ KoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQ MA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNV BAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBBdXRob3JpdHmCCmEg16IAAAAAAAowggJ9BgNV HR8EggJ0MIICcDCCAmygggJooIICZIaBzmxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwRXh0cmFuZXQl MjBDQSxDTj1SRURJVEdDQUEwMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2Vy dGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50hoHgbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLENOPVJFRElUR0NBQTAzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1T ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnSGMmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL2NybC9tc2VjYTEuY3Jshjto dHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLmNy bIY9ZmlsZTovL1xccmVkaXRnY2FhMDNcQ2VydEVucm9sbFxNaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLmNybDCCApwGCCsGAQUFBwEBBIICjjCCAoowgdQGCCsGAQUFBzAChoHHbGRhcDovL2NvcnAu bWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLENOPUFJQSxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAs REM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPU1pY3Jvc29mdCUyMEV4 dHJhbmV0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5o dHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2VjYTEuY3J0MFYGCCsGAQUFBzAC hkpodHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9yZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBF eHRyYW5ldCUyMENBKDIpLmNydDBYBggrBgEFBQcwAoZMZmlsZTovL1xccmVkaXRnY2FhMDNcQ2Vy dEVucm9sbFxyZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBKDIpLmNydDANBgkq hkiG9w0BAQUFAAOCAQEAPxiA/UabVI27oO7Ub0XffwiBJUPrYCH444I7YLvqfL/cQTMZNUd8g8zc DMntbJRN5fkVFZXma5T8UVXGEFVtrysc5PB63HPbyzBWnGT3U+dHWhkFbUxcuFtCe+s/1Gw2p8rN dUVfhX2IZ4qcS1e7Iydt7OvkIyWlRC/8unOPSVlJGdw1N7wIObuZahO1UIvlNUJjpGoXZ5Q1vW6v D6/QpVx2u/RjlrzfdBapGRC4e8erzwiwrHeQtVUW25QkYyzZvOEc5DHS27YA4OyBkY8cdohq14co O/RNlMpg5orc5DJMLGNNiixwxLnJejf9ldfpGdfXQncaPXgiFtoXvUapuDGCA5cwggOTAgEBMIGq MIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJ VEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25uZWwgRS1NYWlsIENBIDECChAwv/EABAAAHDcw CQYFKw4DAhoFAKCCAkIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDEwODIyMDAyNjUzWjAjBgkqhkiG9w0BCQQxFgQUkXNabIRPy0UlxE6c+2KfD+i7ka0wZwYJKoZI hvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgboGCSsGAQQBgjcQBDGB rDCBqTCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzEL MAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UE CxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxAgmKSs4ABAAA GugwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jvc29m dC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UE ChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25uZWwg RS1NYWlsIENBIDECCYpKzgAEAAAa6DANBgkqhkiG9w0BAQEFAASBgId75VIgtuJ1B3X72j/eWUtt PpxV2lLwQVg+ILcxA9zkps+pYi+q0Q+BPeaqWrC0ySRTFpHl+kV1PdzFJoIDyEhywbuOJbqo5950 +EU8RqtYjajIbo8Ki7lFGU0OIQXlGrBhY/7UmTMhROZDX6B4sKEHGu9mFSF3SSL9U2XitmjvAAAA AAAA ------=_NextPart_000_0123_01C12A66.7825AB90-- From Avshalom@ubique.com Wed Aug 22 06:28:41 2001 Received: from ubqgate02.lotus.com (outbound-pat-address.lotus.co.uk [194.196.39.50]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09375 for ; Wed, 22 Aug 2001 06:28:39 -0400 (EDT) From: Avshalom@ubique.com Subject: RE: [Simple] Sessions of MESSAGEs To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 22 Aug 2001 13:27:21 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 22/08/2001 13:27:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 5832 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: I agree with Robert. If we want SIMPLE to be widely deployed and not remain in the PR pages we must learn from the experience of existing communities. If SIMPLE will not be optimized, I assume that pure SIMPLE will be implemented only between communities while the client will remain proprietary in order to be able to create communities that really work. SIP was built for negotiating media (usually heavy) sessions. Trying to leverage SIP into the awareness/IM area will require some adjustment in SIP in order to be deployed in very large communities. One very important requirement in large deployments is limiting the number of TCP connections that server farm has to handle. Additionally when the protocol is tunneled over HTTP it is not always possible to create many connections from the client to the server, as the server and proxies limit the number of simultaneous connections from a client. Consider the case where a user is on several chats. Not enabling MESSAGE on the control protocol will require creating a different TCP connection for each chat I am in. I am assuming that the chat is handled by a chat server. It might be acceptable for small communities but not for big ones. avshalom Sametime/Lotus/IBM "Robert Brown" To: "Jonathan Rosenberg" , "Vasilis Sent by: Polychronidis" , "Robert Osborne" simple-admin@mailman.dynam icsoft.com cc: "Zane Thomas" , Subject: RE: [Simple] Sessions of MESSAGEs 22/08/2001 03:27 OK. I understand your proposal. Yes, I think we were talking past each other. However, I am concerned that such an approach will not be widely deployed, as it also requires deployment of a firewall/NAT traversal server (such as draft-rosenberg-sip-entfw-02) adjacent to every firewall/NAT that exists between two end points. In other words, if the assumption is that there is a server in the public network, this will only work for Internet-based services (like MSN and AOL) or for organizations with liberal-minded firewall administrators (rare by definition). An in-band solution will be far more deployable, as it requires all the common problems (like routing, authentication, firewall configuration, etc) to be solved only once. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, August 21, 2001 12:23 PM > To: Robert Brown; Jonathan Rosenberg; Vasilis Polychronidis; Robert > Osborne > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > > -----Original Message----- > > From: Robert Brown [mailto:roberbr@microsoft.com] > > Sent: Tuesday, August 21, 2001 3:13 PM > > To: Jonathan Rosenberg; Vasilis Polychronidis; Robert Osborne > > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > Huh? > > > > I don't see how this is anything like how the web works. Very few web > > users have certs for TLS, except for a very few specialized > > cases where > > they are used for user auth. > > I think we are talking past each other. > > In my proposal, there *is* a server in the public network. This server is > needed for nat traversal if both are behind a nat. In that case, each > client > would have a tls connection to that server, and it is only the server > which > needs to have a cert. This is standard web stuff, and thats what I was > talking about. > > In the case of direct communication between clients, yes, this will be an > issue for TLS as it would require client certs, which is not that common. > This is a problem shared by all e2e encryption/authentication mechanisms. > There is work on defining SDP extensions for negotiation of session keys > (primarily for SRTP), and some of the key management mechanisms don't > require certs, but rather, just shared secrets. It would be nice to be > able > to use that key management stuff for transport beyond SRTP, such as > whatever > we define for IM. > > However, if you want secure IM and trust that server in the cloud, you can > simply elect not to use direct communications even if possible. The > signaling mechanisms in entfw and the drafts it depends on (i.e., comedia) > support that. > > So, you get best of both worlds, from what I can tell.... > > -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 From pkyzivat@cisco.com Wed Aug 22 09:38:13 2001 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 JAA09955 for ; Wed, 22 Aug 2001 09:38:13 -0400 (EDT) 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 f7MDbiB06952 for ; Wed, 22 Aug 2001 09:37:44 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAI00107 (AUTH pkyzivat); Wed, 22 Aug 2001 09:38:55 -0400 (EDT) Message-ID: <3B83B43D.8EB47265@cisco.com> Date: Wed, 22 Aug 2001 09:31:41 -0400 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: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1026 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: There is a related issue that I have not seen discussed much: how a Session of MESSAGEs is established and managed in the context of call control. draft-ietf-simple-im-sdp-00 proposed some SDP extensions so that a Session of MESSAGEs could be negotiated like any other medium. But I have seen no further discussion of that in this context. Do the proponents of Sessions of MESSAGEs agree that use of draft-ietf-simple-im-sdp-00 or something similar should be required to establish a session? Regardless of whether IM Sessions are carried via Sessions of Messages or some other way, I think there is a essential requirement that those sessions be established via a standard INVITE sequence exchanging a session description in SDP. Paul Kyzivat Cisco Systems P.S. I think the title of this thread is wrong - it ought to be something like "IM Sessions". A Session of MESSAGEs" is one way to realize an IM Session, and this thread seems to be discussing the pros and cons of that vs. other ways of realizing an IM Session. From jdrosen@dynamicsoft.com Wed Aug 22 09:52:40 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10033 for ; Wed, 22 Aug 2001 09:52:39 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MDphrN014591; Wed, 22 Aug 2001 09:51:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 09:52:32 -0400 Message-ID: From: Jonathan Rosenberg To: "'Vasilis Polychronidis'" , Jonathan Rosenberg Cc: Robert Osborne , Zane Thomas , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Wed, 22 Aug 2001 09:52:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 7490 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: -----Original Message----- >From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com] >Sent: Wednesday, August 22, 2001 5:45 AM >To: Jonathan Rosenberg >Cc: Robert Osborne; Zane Thomas; simple@mailman.dynamicsoft.com >Subject: Re: [Simple] Sessions of MESSAGEs > > >Hi Jonathan, >I finally browsed through your ID (draft-rosenberg-sip-entfw-02.txt) and I >have the following comments: > >This ID is solving the NAT issues related to SIP. >However IMO we should first specify how a SIP based IM service will work with >an IM/conferencing Server >and then analyze the NAT associated issues. >IMO it is not a good idea to mix these two topics since it will only create >additional confusion. Huh?? Conferencing has nothing to do with it. IM conferencing is easy in the session model. The whole point of using the session model is that we can reuse media conferencing mechanisms defined for other media types, and apply them to IM just as easily. draft-rosenberg-sip-conferencing-models goes through several different conferencing mechanisms. I see no reason why any of these aren't applicable to IM. Establishing conferences is also orthogonal to the use of NAT. I don't see what they have to do with each other. The server used for NAT traversal is not a conferencing server; it is much simpler than a conferencing server. Also, unlike conferencing, where you direct your call at some kind of group ID ultimately, there is no notion of a group here. > >The following diagram describes the architecture and protocols that we want to >use in order to >define IM as a session protocol: > Please view in a fixed-width font such as Courier. > +---------+ > |SIP Proxy| > | | > / +---------+ \\ > // | \\ > // | \\ > // | \\ > SIP for IM signaling | SIP for IM signaling > // | \\ > / |???? \\ > // |How do we \\ > // |correlate transport \\ > // |Sessions in the \\ > // |IM Server? \\ > // | \\ > / | \ > +-----+ +---------+ +-----+ > |IM UA| |IM Server| |IM UA| > | 1 |<---IM-Transport----->| |<----IM-Trasport-------| 2 | > +-----+ +---------+ +-----+ >As it was pointed out by Robert Osborne in the above case we need to specify >the binding for the IM transport legs. >One obvious solution is depicted in the following diagram: This picture above does not correlate with the models in EITHER draft-rosenberg-sip-entfw or draft-rosenberg-sip-conferencing-models. For nat traversal, the proxy plays no role. IM UA1 would communicate directly with the IM server, and obtain a binding. This binding is passed in the SDP in the INVITE from IM UA1 to IM UA2, which would then initiate a connection to the address provided. Since the IM server gave out the binding in the first place, correlation is easy. As far as conferencing is concerned, creating a two party conference call through a conferencing server is possible, but doesn't work the way you describe. IM UA1 would INVITE to the conferencing server with a uniquely chosen conference ID (in the request URI). It would then REFER IM UA2 to contact this conference server. Alternately, it can use 3pcc to INVITE to IM UA2 and provide a conference port to it directly. The model you draw above is possible (as I describe below), but its not a proxy there, rather a B2BUA. That communications protocol can be SIP, MGCP/megaco or midcom, depending on how you implement the "conferecing" box. I am not a fan of this model, as it has issues with scale and fault tolerance. >In addition we will need to address the following case scenario: > Please view in a fixed-width font such as Courier. >+-----+ +----------+ +----------+ +-----+ >|IM UA| |IM Server | |IM Server | |IM UA| >| 1 |<-------->|Provider X|<--------->|Provider Y|<--------->| 2 | >+-----+ +----------+ +----------+ +-----+ >How do we set IM media sessions between two different IM providers? >IMO it is critical for the protocol to allow for an IM Server (gateway or >conferencing server) in case the IM provider >chooses to deploy such architecture.. Generally, I find the argument "yes, but this is how existing systems work" less than compelling. Most of these systems are built on large centralized servers with no interdomain operation or security, and limited scalability (or at least, not cost effective scalability). The SIP model is that media streams go end to end whenever possible. This has very, very good scaling properties, and it is something that is accepted as a good thing for voice and video. There seems to be pushback for this for text, but beyond the slightly relaxed real time requirements, if we view IM as a media stream (and there is agreement on that, right?), why all of a sudden does every design decision get thrown out? The big idea with SIP is that we can use the signaling infrastructure to set up all kinds of media sessions, including audio, video, games, and so on (I have seen SIP used to set up quake deathmatches). Now, it seems people want to say, "no, just kidding about that session independence. Text sessions are different, and we need to re-engineer SIP for them". I don't think so. Is it possible in SIP for a provide to route media traffic through an intermediary that they control? Sure, of course it is. Its possible for a B2BUA (NOT a proxy) to get media routed through an intermediary of its own choice. That can be done with 3pcc, and it has also been proposed to have the B2BUA control the intermediary with MGCP and midcom. Both are workable, but what the relative costs are is a different story. One of the benefits of SIP and the session model is that all of the thinking thats happened for these things for other media types is available for IM. Now, whether I would recommend such intermediaries is a separate question. NAT traversal? Well, I have proposed a way to do that which avoids intermediaries whenever possible (and thats been a design goal for other media types). For reasons of scale and cost, I would argue you generally don't want these things in your network. After all, have we not heard complaints that the cost of SMS on signaling networks is large? Why would an IM provider WANT to buy more equipment and access bandwidth if it doesn't have to? I just must be missing something. -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 From jdrosen@dynamicsoft.com Wed Aug 22 09:54:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10052 for ; Wed, 22 Aug 2001 09:54:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MDrArN014618; Wed, 22 Aug 2001 09:53:10 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 09:53:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'Paul Kyzivat'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Wed, 22 Aug 2001 09:53:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 1601 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: > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, August 22, 2001 9:32 AM > To: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Sessions of MESSAGEs > > > There is a related issue that I have not seen discussed much: how a > Session of MESSAGEs is established and managed in the context of call > control. > > draft-ietf-simple-im-sdp-00 proposed some SDP extensions so that a > Session of MESSAGEs could be negotiated like any other medium. But I > have seen no further discussion of that in this context. Do the > proponents of Sessions of MESSAGEs agree that use of > draft-ietf-simple-im-sdp-00 or something similar should be required to > establish a session? Yes. By definition, the idea behind the "session model" is that messaging is just another media stream established by SIP, using normal SIP call control, with some SDP extension that describes the media stream. > > Regardless of whether IM Sessions are carried via Sessions of Messages > or some other way, I think there is a essential requirement that those > sessions be established via a standard INVITE sequence exchanging a > session description in SDP. Yes. That is the session model by definition. -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 From bcampbell@dynamicsoft.com Wed Aug 22 10:48:02 2001 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 KAA10255 for ; Wed, 22 Aug 2001 10:48:02 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7MEkeS01611; Wed, 22 Aug 2001 09:46:40 -0500 Message-ID: <3B83C5CF.3080307@dynamicsoft.com> Date: Wed, 22 Aug 2001 09:46:39 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Kyzivat CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: <3B83B43D.8EB47265@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 999 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: Paul Kyzivat wrote: > There is a related issue that I have not seen discussed much: how a > Session of MESSAGEs is established and managed in the context of call > control. > > draft-ietf-simple-im-sdp-00 proposed some SDP extensions so that a > Session of MESSAGEs could be negotiated like any other medium. But I > have seen no further discussion of that in this context. Do the > proponents of Sessions of MESSAGEs agree that use of > draft-ietf-simple-im-sdp-00 or something similar should be required to > establish a session? The draft you mention was specific to sending IM messages using a SIP transport. Since the IESG has recommended against that approach, the draft is no longer particularly relevant. > > Regardless of whether IM Sessions are carried via Sessions of Messages > or some other way, I think there is a essential requirement that those > sessions be established via a standard INVITE sequence exchanging a > session description in SDP. That is our intention. From Vasilis.Polychronidis@Openwave.com Wed Aug 22 21:00:28 2001 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 VAA11948 for ; Wed, 22 Aug 2001 21:00:27 -0400 (EDT) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010823005942.ZOJY13809.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Wed, 22 Aug 2001 19:59:42 -0500 Received: from Openwave.com ([64.14.128.39]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010823005917.EVMX16324.oe-ismta2.bizmailsrvcs.net@Openwave.com>; Wed, 22 Aug 2001 19:59:17 -0500 Message-ID: <3B8455A6.17F02F0C@Openwave.com> Date: Wed, 22 Aug 2001 18:00:22 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Robert Osborne , Zane Thomas , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: Content-Type: multipart/alternative; boundary="------------2528FFABAEE1F2F30FE503E7" Content-Length: 29897 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: --------------2528FFABAEE1F2F30FE503E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan, Please see my response below: BR, -Vasilis Jonathan Rosenberg wrote: > > -----Original Message----- > >From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com] > >Sent: Wednesday, August 22, 2001 5:45 AM > >To: Jonathan Rosenberg > >Cc: Robert Osborne; Zane Thomas; simple@mailman.dynamicsoft.com > >Subject: Re: [Simple] Sessions of MESSAGEs > > > > > >Hi Jonathan, > >I finally browsed through your ID (draft-rosenberg-sip-entfw-02.txt) and I > >have the following comments: > > > >This ID is solving the NAT issues related to SIP. > >However IMO we should first specify how a SIP based IM service will work > with > >an IM/conferencing Server > >and then analyze the NAT associated issues. > >IMO it is not a good idea to mix these two topics since it will only create > > >additional confusion. > > Huh?? Conferencing has nothing to do with it. IM conferencing is easy in the > session model. Great it will be easy then to describe it in an Internet draft. Jonathan you wrote so many IDs that is hard for me to keep up :-) Thank you for being patient with my ignorance. > The whole point of using the session model is that we can > reuse media conferencing mechanisms defined for other media types, and apply > them to IM just as easily. draft-rosenberg-sip-conferencing-models goes > through several different conferencing mechanisms. I see no reason why any > of these aren't applicable to IM. They are :-) Actually I like the Dial-in Conference Server model (Section 4 of draft-rosenberg-sip-conferencing-models) and the Adhoc centralized Conference model (Section 4 of draft-rosenberg-sip-conferencing-models) > > > Establishing conferences is also orthogonal to the use of NAT. Exactly my point. We were talking about different things. > I don't see > what they have to do with each other. The server used for NAT traversal is > not a conferencing server; Correct. > it is much simpler than a conferencing server. > Also, unlike conferencing, where you direct your call at some kind of group > ID ultimately, there is no notion of a group here. Well my preference is to treat an IM session as a mufti party session where mufti party = 2, 3, ...,N IM users > > > > > >The following diagram describes the architecture and protocols that we want > to >use in order to > >define IM as a session protocol: > > Please view in a fixed-width font such as Courier. > > +---------+ > > |SIP Proxy| > > | | > > / +---------+ \\ > > // | \\ > > // | \\ > > // | \\ > > SIP for IM signaling | SIP for IM signaling > > // | \\ > > / |???? \\ > > // |How do we \\ > > // |correlate transport \\ > > // |Sessions in the \\ > > // |IM Server? \\ > > // | \\ > > / | \ > > +-----+ +---------+ +-----+ > > |IM UA| |IM Server| |IM UA| > > | 1 |<---IM-Transport----->| |<----IM-Trasport-------| 2 | > > +-----+ +---------+ +-----+ > >As it was pointed out by Robert Osborne in the above case we need to > specify > >the binding for the IM transport legs. > >One obvious solution is depicted in the following diagram: > > This picture above does not correlate with the models in EITHER > draft-rosenberg-sip-entfw or draft-rosenberg-sip-conferencing-models. For > nat traversal, the proxy plays no role. IM UA1 would communicate directly > with the IM server, and obtain a binding. This binding is passed in the SDP > in the INVITE from IM UA1 to IM UA2, which would then initiate a connection > to the address provided. Since the IM server gave out the binding in the > first place, correlation is easy. > > As far as conferencing is concerned, creating a two party conference call > through a conferencing server is possible, but doesn't work the way you > describe. IM UA1 would INVITE to the conferencing server with a uniquely > chosen conference ID (in the request URI). It would then REFER IM UA2 to > contact this conference server. Alternately, it can use 3pcc to INVITE to IM > UA2 and provide a conference port to it directly. > > The model you draw above is possible (as I describe below), but its not a > proxy there, rather a B2BUA. That communications protocol can be SIP, > MGCP/megaco or midcom, depending on how you implement the "conferecing" box. > I am not a fan of this model, as it has issues with scale and fault > tolerance. > > >In addition we will need to address the following case scenario: > > Please view in a fixed-width font such as Courier. > >+-----+ +----------+ +----------+ +-----+ > >|IM UA| |IM Server | |IM Server | |IM UA| > >| 1 |<-------->|Provider X|<--------->|Provider Y|<--------->| 2 | > >+-----+ +----------+ +----------+ +-----+ > >How do we set IM media sessions between two different IM providers? > >IMO it is critical for the protocol to allow for an IM Server (gateway or > >conferencing server) in case the IM provider > >chooses to deploy such architecture.. > > Generally, I find the argument "yes, but this is how existing systems work" > less than compelling. Most of these systems are built on large centralized > servers with no interdomain operation or security, and limited scalability > (or at least, not cost effective scalability). The SIP model is that media > streams go end to end whenever possible. This has very, very good scaling > properties, and it is something that is accepted as a good thing for voice > and video. There seems to be pushback for this for text, but beyond the > slightly relaxed real time requirements, if we view IM as a media stream > (and there is agreement on that, right?), Yes I think there is agreement on that. > why all of a sudden does every > design decision get thrown out? The big idea with SIP is that we can use the > signaling infrastructure to set up all kinds of media sessions, including > audio, video, games, and so on (I have seen SIP used to set up quake > deathmatches). Now, it seems people want to say, "no, just kidding about > that session independence. Text sessions are different, and we need to > re-engineer SIP for them". I don't think so. I am not advocating reinventing any wheels here. I am just trying to understand how IM will work in the Conference Server Model. BTW can you explain to me how IM as a session will work using the Conference Server model when you have two or more IM/Conference Servers? Please view in a fixed-width font such as Courier. +-----+ +----------+ +----------+ +-----+ |IM UA| |IM/Conf | |IM/Conf | |IM UA| | 1 |<-------->|Server |<--------->|Server |<--------->| 2 | | | |Provider X| |Provider Y| | | +-----+ +----------+ +----------+ +-----+ How do we set IM media sessions between two different IM providers? > > > Is it possible in SIP for a provide to route media traffic through an > intermediary that they control? Sure, of course it is. Its possible for a > B2BUA (NOT a proxy) to get media routed through an intermediary of its own > choice. That can be done with 3pcc, and it has also been proposed to have > the B2BUA control the intermediary with MGCP and midcom. Both are workable, > but what the relative costs are is a different story. One of the benefits of > SIP and the session model is that all of the thinking thats happened for > these things for other media types is available for IM. > > Now, whether I would recommend such intermediaries is a separate question. > NAT traversal? Well, I have proposed a way to do that Well frankly your proposal is technically correct but very complicated and requires a lot of new functionality. However if this is the only way to solve the VoIP NAT issues I will supported. At this point of time I do not have enough data points to make a decision. Maybe the experts in VoIP can shed some light here? Question for the VoIP experts: What is the preferred way of solving NAT issues with the minimum amount of modifications on SIP and media protocols? > which avoids > intermediaries whenever possible (and thats been a design goal for other > media types). For reasons of scale and cost, I would argue you generally > don't want these things in your network. Well we disagree at this point as I mentioned in a previous E-mail having a IM/conferecing Server makes it easy to achieve: 1. Universal access (mobile, PDA, PC, etc.) 2. Consistency and synchronization 3. Authorization/Authentication 4. "Mobility" of buddy lists 5. Security 6. NAT issues (IM/conferecing Server is not a NAT traversal server but it helps to alleviate some of the NAT issues) > After all, have we not heard > complaints that the cost of SMS on signaling networks is large? Why would an > IM provider WANT to buy more equipment and access bandwidth if it doesn't > have to? Please refer to the above list. In addition many operators have Legal intercept requirements which a peer to peer model is hard to satisfy. Again we may have different views here but the proposed protocol should allow for a IM/conferecing Server model. I think we should provide a flexible IM Session Protocol and let the market decide which specific implementation is optimal. > I just must be missing something. > > -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 --------------2528FFABAEE1F2F30FE503E7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan,
Please see my response below:

BR,

-Vasilis

Jonathan Rosenberg wrote:

 
-----Original Message-----
>From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@Openwave.com]
>Sent: Wednesday, August 22, 2001 5:45 AM
>To: Jonathan Rosenberg
>Cc: Robert Osborne; Zane Thomas; simple@mailman.dynamicsoft.com
>Subject: Re: [Simple] Sessions of MESSAGEs
>
>
>Hi Jonathan,
>I finally browsed through your ID (draft-rosenberg-sip-entfw-02.txt) and I
>have the following comments:
>
>This ID is solving the NAT issues related to SIP.
>However IMO we should first specify how a SIP based IM service will work
with
>an IM/conferencing Server
>and then analyze the NAT associated issues.
>IMO it is not a good idea to mix these two topics since it will only create

>additional confusion.

Huh?? Conferencing has nothing to do with it. IM conferencing is easy in the
session model.

Great it will be easy then to describe it in an Internet draft.
Jonathan you wrote so many IDs that is hard for me to keep up :-)
Thank you for being patient with my ignorance.
The whole point of using the session model is that we can
reuse media conferencing mechanisms defined for other media types, and apply
them to IM just as easily. draft-rosenberg-sip-conferencing-models goes
through several different conferencing mechanisms. I see no reason why any
of these aren't applicable to IM.
They are :-)
Actually I like the Dial-in Conference Server model (Section 4 of draft-rosenberg-sip-conferencing-models)
and the Adhoc centralized Conference model (Section 4 of draft-rosenberg-sip-conferencing-models)
 

Establishing conferences is also orthogonal to the use of NAT.

Exactly my point. We were talking about different things.
I don't see
what they have to do with each other. The server used for NAT traversal is
not a conferencing server;
Correct.
it is much simpler than a conferencing server.
Also, unlike conferencing, where you direct your call at some kind of group
ID ultimately, there is no notion of a group here.
Well my preference is to treat an IM session as a mufti party session
where mufti party = 2, 3, ...,N IM users
 

>
>The following diagram describes the architecture and protocols that we want
to >use in order to
>define IM as a session protocol:
>          Please view in a fixed-width font such as Courier.
>                              +---------+
>                              |SIP Proxy|
>                              |         |
>                            / +---------+ \\
>                          //       |        \\
>                        //         |          \\
>                      //           |            \\
>        SIP for IM signaling       |            SIP for IM signaling
>                  //               |                \\
>                 /                 |????              \\
>               //                  |How do we           \\
>             //                    |correlate transport   \\
>           //                      |Sessions in the         \\
>         //                        |IM Server?                \\
>       //                          |                            \\
>      /                            |                              \
> +-----+                      +---------+                       +-----+
> |IM UA|                      |IM Server|                       |IM UA|
> |  1  |<---IM-Transport----->|         |<----IM-Trasport-------|  2  |
> +-----+                      +---------+                       +-----+
>As it was pointed out by Robert Osborne in the above case we need to
specify
>the binding for the IM transport legs.
>One obvious solution is depicted in the following diagram:

This picture above does not correlate with the models in EITHER
draft-rosenberg-sip-entfw or draft-rosenberg-sip-conferencing-models. For
nat traversal, the proxy plays no role. IM UA1 would communicate directly
with the IM server, and obtain a binding. This binding is passed in the SDP
in the INVITE from IM UA1 to IM UA2, which would then initiate a connection
to the address provided. Since the IM server gave out the binding in the
first place, correlation is easy.

As far as conferencing is concerned, creating a two party conference call
through a conferencing server is possible, but doesn't work the way you
describe. IM UA1 would INVITE to the conferencing server with a uniquely
chosen conference ID (in the request URI). It would then REFER IM UA2 to
contact this conference server. Alternately, it can use 3pcc to INVITE to IM
UA2 and provide a conference port to it directly.

The model you draw above is possible (as I describe below), but its not a
proxy there, rather a B2BUA. That communications protocol can be SIP,
MGCP/megaco or midcom, depending on how you implement the "conferecing" box.
I am not a fan of this model, as it has issues with scale and fault
tolerance.

>In addition we will need to address the following case scenario:
>          Please view in a fixed-width font such as Courier.
>+-----+          +----------+           +----------+           +-----+
>|IM UA|          |IM Server |           |IM Server |           |IM UA|
>|  1  |<-------->|Provider X|<--------->|Provider Y|<--------->|  2  |
>+-----+          +----------+           +----------+           +-----+
>How do we set IM media sessions between two different IM providers?
>IMO it is critical for the protocol to allow for an IM Server (gateway or
>conferencing server) in case the IM provider
>chooses to deploy such architecture..

Generally, I find the argument "yes, but this is how existing systems work"
less than compelling. Most of these systems are built on large centralized
servers with no interdomain operation or security, and limited scalability
(or at least, not cost effective scalability). The SIP model is that media
streams go end to end whenever possible. This has very, very good scaling
properties, and it is something that is accepted as a good thing for voice
and video. There seems to be pushback for this for text, but beyond the
slightly relaxed real time requirements, if we view IM as a media stream
(and there is agreement on that, right?),

Yes I think there is agreement on that.
why all of a sudden does every
design decision get thrown out? The big idea with SIP is that we can use the
signaling infrastructure to set up all kinds of media sessions, including
audio, video, games, and so on (I have seen SIP used to set up quake
deathmatches). Now, it seems people want to say, "no, just kidding about
that session independence. Text sessions are different, and we need to
re-engineer SIP for them". I don't think so.
I am not advocating reinventing any wheels here.
I am just trying to understand how IM will work in the Conference Server Model.
BTW can you explain to me how IM as a session will work using
the Conference Server model when you have two or more IM/Conference Servers?
      
          Please view in a fixed-width font such as Courier.

+-----+          +----------+           +----------+           +-----+
|IM UA|          |IM/Conf   |           |IM/Conf   |           |IM UA|
|  1  |<-------->|Server    |<--------->|Server    |<--------->|  2  |
|     |          |Provider X|           |Provider Y|           |     |
+-----+          +----------+           +----------+           +-----+

How do we set IM media sessions between two different IM providers?

 

Is it possible in SIP for a provide to route media traffic through an
intermediary that they control? Sure, of course it is. Its possible for a
B2BUA (NOT a proxy) to get media routed through an intermediary of its own
choice. That can be done with 3pcc, and it has also been proposed to have
the B2BUA control the intermediary with MGCP and midcom. Both are workable,
but what the relative costs are is a different story. One of the benefits of
SIP and the session model is that all of the thinking thats happened for
these things for other media types is available for IM.

Now, whether I would recommend such intermediaries is a separate question.
NAT traversal? Well, I have proposed a way to do that

Well frankly your proposal is technically correct but very complicated and requires a lot of new functionality.
However if this is the only way to solve the VoIP NAT issues I will supported.
At this point of time I do not have enough data points to make a decision.
Maybe the experts in VoIP can shed some light here?
Question for the VoIP experts:
What is the preferred way of solving NAT issues with the minimum amount of modifications on SIP and media protocols?
which avoids
intermediaries whenever possible (and thats been a design goal for other
media types). For reasons of scale and cost, I would argue you generally
don't want these things in your network.
Well we disagree at this point as I mentioned in a previous E-mail having a IM/conferecing Server
makes it easy to achieve:

1. Universal access (mobile, PDA, PC, etc.)
2. Consistency and synchronization
3. Authorization/Authentication
4. "Mobility" of buddy lists
5. Security
6. NAT issues (IM/conferecing Server is not a NAT traversal server but it helps to alleviate some of the NAT issues)

After all, have we not heard
complaints that the cost of SMS on signaling networks is large? Why would an
IM provider WANT to buy more equipment and access bandwidth if it doesn't
have to?
Please refer to the above list. In addition many operators have Legal intercept
requirements which a peer to peer model is hard to satisfy.
Again we may have different views here but the proposed protocol
should allow for a  IM/conferecing Server model.
I think we should provide a flexible IM Session Protocol and let the market decide which specific implementation
is optimal.
I just must be missing something.

-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

--------------2528FFABAEE1F2F30FE503E7-- From cjjj012001@hotmail.comduz Wed Aug 22 23:31:21 2001 Received: from ips-city.com (dmn242.radiks.net [205.216.90.155]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id XAA12372 for ; Wed, 22 Aug 2001 23:31:17 -0400 (EDT) Message-Id: <200108230331.XAA12372@mailman.dynamicsoft.com> From: "Joel Jeffries" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 22 Aug 2001 22:29:40 -0500 Content-Transfer-Encoding: 8bit Content-Length: 15051 Subject: [Simple] (no subject) 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: YOU MUST READ THIS!!!!--Pleasd don't delete till you Read It!--adv If you do not wish to receive further emails of this type, please send a blank email with remove in the subject line to: jcppoorman2001@hotmail.com Hi, I hope this will be of interest to you..... Dear Friend and Future Millionaire, AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time THANKS TO THE COMPUTER AGE AND THE INTERNET! ===================================================== = BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money.\\~ The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can -follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: '' Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required.To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. ===================================================== == Here is another testimonial: ''' this program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, ===== PRINT THIS NOW FOR YOUR FUTUREREFERENCE ======== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$ $ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: =====Order all 5 reports shown on the list below ===== For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person  whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURNADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. === When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your disk in case something happens to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will lose out on the majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, andif you alter it, it will NOT work !!! People have tried to puttheir friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2. 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ===================================================== ======== **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you lose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally,where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1: BY SENDING BULK E-MAIL LEGALLY ===================================================== ======== Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that through mailing you receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands of e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That is:100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3.....$5,000 + 4..... $50,000 + 5..... $500,000 ........ .....Grand Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ===================================================== ======== REMEMBER, THIS IS ASSUMING ONLY 10 PEOPLE ORDER OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if  half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET ===================================================== ======== Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and add METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receive the report. ===========AVAILABLE REPORTS ==================== ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW : ===================================================== ===== REPORT # 1: 'The Insider's Guide to Advertising for Free on the Net Order Report #1 from: J. Jeffries 4515 Franklin ave. Des Moines, IA 50310 USA _____________________________________________________ ___ REPORT # 2: The Insider's Guide to Sending Bulk e-mail on the Net Order Report # 2 from: D. WARKE 15 Porritt Avenue Mt Victoria Wellington New Zealand _____________________________________________________ ____________ REPORT # 3: Secret to Multilevel marketing on the net Order Report # 3 from : D. FERNANDEZ 414 Phillip St Vallejo, CA 94590 USA _____________________________________________________ ____________ REPORT # 4: How to become a millionaire utilizing MLM & the Net Order Report # 4 from:   S. Williams 1025 River Road Modesto, CA  95351-4107 USA _____________________________________________________ ___________ REPORT #5: How to send out one Million e-mails for free Order Report # 5 From: S. Gabriel P.O.Box 818 Vallejo, CA  94590 USA _____________________________________________________ ___________ If you would like to contact me with any questions, you can at cjjj012001@hotmail.com $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. === Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCES AGAIN. There is NO LIMIT to the income you can generate from this business !!! ===================================================== ======== FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! ======================== MORE TESTIMONIALS =================== '' My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ===================================================== ======== '' Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''. Dan Sondstrom, Alberta, Canada ===================================================== ======== '' I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''. Susan De Suza, New York, N.Y. ===================================================== ======== '' It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20, 560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful,Thanx to internet''. Fred Dellaca, Westport, New Zealand ===================================================== ======== ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM ! ===================================================== ======== If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices,Federal Trade Commission,Bureau of Consumer Protection, Washington, D.C. From Basavaraj.Patil@nokia.com Thu Aug 23 01:00:42 2001 Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12668 for ; Thu, 23 Aug 2001 01:00:41 -0400 (EDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7N50fi05305 for ; Thu, 23 Aug 2001 00:00:41 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Aug 2001 00:00:36 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 00:00:36 -0500 content-class: urn:content-classes:message Subject: RE: [Simple] Why do we need Presence Caching? Date: Thu, 23 Aug 2001 00:00:35 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E847A@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [Simple] Why do we need Presence Caching? Thread-Index: AcEp9axQHFbhoJXlEdWpVgBQi2kYTQBmvI9g From: "Patil Basavaraj (NET/Dallas)" To: "'ext Jonathan Rosenberg'" , "'Arnaud Weil'" , "Tony Hansen" , X-OriginalArrivalTime: 23 Aug 2001 05:00:36.0217 (UTC) FILETIME=[8BB38E90:01C12B90] Content-Length: 1100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id BAA12668 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: > >e2e authentication and encryption between end users is a really, really hard >problem, for which a usefully deployable solution is quite elusive. Thats >true for SIP and for all other protocols in a similar boat, as far as I can >tell. > I quite agree with that e2e authentication between end users is a hard problem to solve. In fact the Mobile IPv6 specification is now delayed mainly because of the fact that it is very difficult (at least from a deployment perspective) to have two end points authenticate each other and setup a security association. So in the absence of a global PKI or some other similar mechanism, I am wondering if this requirement is a potential rat-hole for the WG at this time. >-Jonathan R. > -Basavaraj >--- >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 > From joshua@digitalknowledge.net Thu Aug 23 08:21:38 2001 Received: from granada.digitalknowledge.net (cdm-208-145-244-geor.cox-internet.com [208.180.145.244]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13845 for ; Thu, 23 Aug 2001 08:21:37 -0400 (EDT) Received: by granada.digitalknowledge.net with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Aug 2001 07:12:14 -0500 Message-ID: From: SpatialLocation@digitalknowledge.net To: simple@mailman.dynamicsoft.com Date: Thu, 23 Aug 2001 07:11:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5633 Subject: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol 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: Howdy watching and putting some pieces together and I have this to offer... There appear to be two significant issues: 1. the IESG wants to tank MESSAGE method for MESSAGE sessions or 'chat' like conversations between known SIP UAs based on SIP Extension Rules, i.e. looks like a transport protocol 2. using the MESSAGE method for simple 'paged' instant messages or one-off instant messages is OK. although one could argue it is still a mis-use of ideal SIP. This is because it is still carrying a payload and not necessarily initiating a 'session' Unless the session is a human-based session, i.e. "come here watson" or "can I ask you a quick question?" which would then create the need for a 'session of MESSAGES' or physical appearance, either of which SHOULD be handled by another protocol. However, having another protocol for 'sessions of MESSAGEs' leads to the issues Robert O. brought up, which were then refuted by Jonathon R. on the basis of internet-drafts and scalability issues. Moreover, the fact that the MESSAGE extension was being perceived as a 'transport' violates the use of SIP extension (ID sip-guidelines-02.txt section 3.1.) SIP is supposed to act more like Chuck Wollery from 'the love connection' - to use a colloquialism, i.e. bringing together Jonathon R. would like to have end-to-end session of MESSAGEs to travel between the clients directly as this supports the scalability and original voice use of the SIP server. On the other hand this doesn't support the fundamental design requirements of IM as stated in rfc2779 2.4.3/2.4.4. Which means, prior to supporting that end-to-end communication, the SIP server would have to determine if 'that was allowed' based on the security requirements Vasilis and Robert O have been talking about, which is also required per rfc2779. Those fundamental services can be easily implemented at the SIP server if SIP was the method used to send 'sessions of MESSAGES' - problem here, IESG doesn't like it. There is a good reason why it is liked it's 'convenient', but conveniences are not always a value. So what we have is the need to 'reuse or create security features' adjunct by the modular/portability needs and requirements of SIP/Signaling The intermediary/PROXY MUST be created and supported as a basic feature of the IM 'session of MESSAGEs' design. In Robert Os case he would want the development of that intermediary to play off of the domain and security information designed into the SIP server (thus making it portable across SIP and the IM proxy). This is easily designed if you have a unified configuration-directory where the SIP Server and IM Message proxy pull configuration information, otherwise, it looks like a complex proposition. Should the protocol used for 'sessions of MESSAGEs' define how the intermediary would be used? Yes, it has to, if it is to meet the design requirement of rfc2779 2.4.3/4 In addition, to support end-to-end signaling the SIP server needs to have logic on whether or not that end-to-end signaling is allowed or whether it's end-to-end-to-end-to-end :) - this meets the rfc2779 2.4.3/4 requirement, regardless of natiness. So in retrospect: MESSAGE SIP extension can't be used for sessions of IMs other wise it looks like a transport mechanism and should be implemented separately You need to design in the ability to use an intermediary per rfc 2779 2.4.3/4 (at a minimum) We will have to figure out a way to get the bonus of domain/security from SIP server into an IM intermediary. A simple solution exists in using SIP server to determine use of initiating sessions through an intermediary? That is session initiation. Jonathon R. has some good solutions for the intermediary in other IDs he has written, but the reality is the communication looks more like 'direct chatting' than text based audio/video conference, which is why the IESG probably frowned on using RTP - wasn't there so I can't say for sure. At a high level these look the same, but at a low level the solution breaks down, i.e. no video frames or audio sequencing in the protocol mechanism. Which is probably why ID cpim-msgfmt specifies the use of an existing text based format, RFC822. As an aside, I would also presume this is why sctp may not be a necessary choice for the instant message 'signaling', to use a term from voice drafts, given the sctp's primary use, albeit congestion management at the intermediary/PROXY. IMs are only text per node, am I naive to think it's a moot point or would there be congestion issues at the intermediary??? Lastly, Jonathon R appears convinced that the communication should be end-to-end. (http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html), but over TCP :)! That works great if you are trying to scale the servers and you want to put two callers together, but with IM, it's not voice and it's like email, but more importantly, as stated in rfc2779, the security/control needs to be built in. I am just pointing out the 'vision/scope' of rfc2779 that says 'when you are heads down discussing technical stuff, don't forget these requirements' Jonathon didn't write that RFC2779 so he probably isn't thinking with that light bulb on. I would not want to see the IMsession design based on 'phone-calls' as that's the 'way SIP has been predominatly used', but instead, to take a different and assuredly positive approach. I am not intending to offend anyone and I took some time to listen to the forum, prior to submitting my points. TIA Joshua -- Joshua L. Konkle Business Technology Architect Digital Knowledge http://www.digitalknowledge.net From oded@novawiz.com Thu Aug 23 09:37:42 2001 Received: from dino.novawiz.com ([212.150.9.210]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14073 for ; Thu, 23 Aug 2001 09:37:36 -0400 (EDT) Received: from mona.odigo.com (comp30 [10.0.0.30]) by dino.novawiz.com (8.11.1/8.11.1) with ESMTP id f7NDasw31165 for ; Thu, 23 Aug 2001 16:36:54 +0300 Received: by MONA with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 16:37:30 +0200 Message-ID: From: Oded Cnaan To: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Date: Thu, 23 Aug 2001 16:37:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 7094 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: I agree with Joshua K regarding the MESSAGE analysis. It's important to remember, that leaving IM to end-to-end communications results in a security hole that allows other users to reveal your IP address. Several IM services that used to reveal users' IPs (like ICQ) caused deadly attacks by hackers on user's clients. If you take a look at the leading IM services, none of them support end-to-end communications (for IM). There are two different concepts in IM, that sometimes are perceived as one. The first is Instant Messaging (IM) which means sending direct and quick message to someone. The latter is chatting, which means continuous messaging. Several services converge these concepts into one feature while other let the user choose between the two. I think that SIP needs to support both options. MESSAGE should be used to send a direct IM (through the server, that might redirect it to the client) and a session for initiating a chat. Oded Cna'an VP, New Technologies Odigo Inc. -----Original Message----- From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of SpatialLocation@digitalknowledge.net Sent: Thursday, August 23, 2001 2:12 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Howdy watching and putting some pieces together and I have this to offer... There appear to be two significant issues: 1. the IESG wants to tank MESSAGE method for MESSAGE sessions or 'chat' like conversations between known SIP UAs based on SIP Extension Rules, i.e. looks like a transport protocol 2. using the MESSAGE method for simple 'paged' instant messages or one-off instant messages is OK. although one could argue it is still a mis-use of ideal SIP. This is because it is still carrying a payload and not necessarily initiating a 'session' Unless the session is a human-based session, i.e. "come here watson" or "can I ask you a quick question?" which would then create the need for a 'session of MESSAGES' or physical appearance, either of which SHOULD be handled by another protocol. However, having another protocol for 'sessions of MESSAGEs' leads to the issues Robert O. brought up, which were then refuted by Jonathon R. on the basis of internet-drafts and scalability issues. Moreover, the fact that the MESSAGE extension was being perceived as a 'transport' violates the use of SIP extension (ID sip-guidelines-02.txt section 3.1.) SIP is supposed to act more like Chuck Wollery from 'the love connection' - to use a colloquialism, i.e. bringing together Jonathon R. would like to have end-to-end session of MESSAGEs to travel between the clients directly as this supports the scalability and original voice use of the SIP server. On the other hand this doesn't support the fundamental design requirements of IM as stated in rfc2779 2.4.3/2.4.4. Which means, prior to supporting that end-to-end communication, the SIP server would have to determine if 'that was allowed' based on the security requirements Vasilis and Robert O have been talking about, which is also required per rfc2779. Those fundamental services can be easily implemented at the SIP server if SIP was the method used to send 'sessions of MESSAGES' - problem here, IESG doesn't like it. There is a good reason why it is liked it's 'convenient', but conveniences are not always a value. So what we have is the need to 'reuse or create security features' adjunct by the modular/portability needs and requirements of SIP/Signaling The intermediary/PROXY MUST be created and supported as a basic feature of the IM 'session of MESSAGEs' design. In Robert Os case he would want the development of that intermediary to play off of the domain and security information designed into the SIP server (thus making it portable across SIP and the IM proxy). This is easily designed if you have a unified configuration-directory where the SIP Server and IM Message proxy pull configuration information, otherwise, it looks like a complex proposition. Should the protocol used for 'sessions of MESSAGEs' define how the intermediary would be used? Yes, it has to, if it is to meet the design requirement of rfc2779 2.4.3/4 In addition, to support end-to-end signaling the SIP server needs to have logic on whether or not that end-to-end signaling is allowed or whether it's end-to-end-to-end-to-end :) - this meets the rfc2779 2.4.3/4 requirement, regardless of natiness. So in retrospect: MESSAGE SIP extension can't be used for sessions of IMs other wise it looks like a transport mechanism and should be implemented separately You need to design in the ability to use an intermediary per rfc 2779 2.4.3/4 (at a minimum) We will have to figure out a way to get the bonus of domain/security from SIP server into an IM intermediary. A simple solution exists in using SIP server to determine use of initiating sessions through an intermediary? That is session initiation. Jonathon R. has some good solutions for the intermediary in other IDs he has written, but the reality is the communication looks more like 'direct chatting' than text based audio/video conference, which is why the IESG probably frowned on using RTP - wasn't there so I can't say for sure. At a high level these look the same, but at a low level the solution breaks down, i.e. no video frames or audio sequencing in the protocol mechanism. Which is probably why ID cpim-msgfmt specifies the use of an existing text based format, RFC822. As an aside, I would also presume this is why sctp may not be a necessary choice for the instant message 'signaling', to use a term from voice drafts, given the sctp's primary use, albeit congestion management at the intermediary/PROXY. IMs are only text per node, am I naive to think it's a moot point or would there be congestion issues at the intermediary??? Lastly, Jonathon R appears convinced that the communication should be end-to-end. (http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html), but over TCP :)! That works great if you are trying to scale the servers and you want to put two callers together, but with IM, it's not voice and it's like email, but more importantly, as stated in rfc2779, the security/control needs to be built in. I am just pointing out the 'vision/scope' of rfc2779 that says 'when you are heads down discussing technical stuff, don't forget these requirements' Jonathon didn't write that RFC2779 so he probably isn't thinking with that light bulb on. I would not want to see the IMsession design based on 'phone-calls' as that's the 'way SIP has been predominatly used', but instead, to take a different and assuredly positive approach. I am not intending to offend anyone and I took some time to listen to the forum, prior to submitting my points. TIA Joshua -- Joshua L. Konkle Business Technology Architect Digital Knowledge http://www.digitalknowledge.net _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From Basavaraj.Patil@nokia.com Thu Aug 23 10:34:58 2001 Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14323 for ; Thu, 23 Aug 2001 10:34:57 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7NEZ1i22761 for ; Thu, 23 Aug 2001 09:35:02 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 23 Aug 2001 09:34:56 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 23 Aug 2001 09:34:56 -0500 content-class: urn:content-classes:message Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Date: Thu, 23 Aug 2001 09:34:55 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E8484@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Thread-Index: AcEr3Dtlxg/Xb5fOEdWxLgAIx6TWeAABKCEg From: "Patil Basavaraj (NET/Dallas)" To: "'ext Oded Cnaan'" , X-OriginalArrivalTime: 23 Aug 2001 14:34:56.0031 (UTC) FILETIME=[C759E2F0:01C12BE0] Content-Length: 2138 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA14323 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: Comments inline: >I agree with Joshua K regarding the MESSAGE analysis. It's important to >remember, that leaving IM to end-to-end communications results in a security >hole that allows other users to reveal your IP address. > A possible way to avoid this is to use HIP (Host identity payload) instead of IP addresses to identify the clients. This would give e2e security between the end points as well as prevent attacks because of IP address exposure. >Several IM services that used to reveal users' IPs (like ICQ) caused deadly >attacks by hackers on user's clients. If you take a look at the leading IM >services, none of them support end-to-end communications (for IM). > According to RFC3041 : " Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node " So in the case of IPv6 clients could possibly use this mechanism to achieve some degree of privacy and a way to prevent attacks, especially if the client keeps changing its address on a frequent basis. >There are two different concepts in IM, that sometimes are perceived as one. >The first is Instant Messaging (IM) which means sending direct and quick >message to someone. The latter is chatting, which means continuous >messaging. Several services converge these concepts into one feature while >other let the user choose between the two. > >I think that SIP needs to support both options. MESSAGE should be used to >send a direct IM (through the server, that might redirect it to the >client) Are you suggesting that clients always use the intermediate server for sending IM? It may make sense in some scenarios, but not always. >and a session for initiating a chat. > >Oded Cna'an >VP, New Technologies >Odigo Inc. -Basavaraj From sean.olson@ericsson.com Thu Aug 23 12:43:03 2001 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 MAA14711 for ; Thu, 23 Aug 2001 12:43:03 -0400 (EDT) From: sean.olson@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 f7NGh2525872; Thu, 23 Aug 2001 11:43:02 -0500 (CDT) 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 f7NGh1Z13479; Thu, 23 Aug 2001 11:43:01 -0500 (CDT) Received: from e0000865ab2db (pc050058.exu.ericsson.se [138.85.50.58]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA24046; Thu, 23 Aug 2001 11:43:01 -0500 (CDT) Reply-To: To: , , Date: Thu, 23 Aug 2001 11:42:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 V5.50.4522.1200 Content-Length: 712 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA14711 Subject: [Simple] draft-koskelainen-sip-group-00 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: I was curious about the status of this draft and its possible inclusion into the MESSAGE work within SIMPLE. The draft points out a number of interesting problems and possible solutions for dealing with requests sent to potentially large groups (for example, instant messaging to a chat room). Adding a Message-Id: header seems like a very good idea. I would prefer In-Reply-To: instead of References:, but this addition seems sound as well. The addition of a message sequence header is my only hesitation. I think a Date: timestamp is sufficient for all real world problems, given that MESSAGE is meant to be rendered to a human user and not to a automaton. Any comments? Regards, Sean Olson Ericsson Inc. From mailman@permissiononly.com Thu Aug 23 15:16:30 2001 Received: from permissiononly.com (permissiononly.com [216.133.253.90]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15166 for ; Thu, 23 Aug 2001 15:16:30 -0400 (EDT) Received: (from mailman@localhost) by permissiononly.com (8.9.3/8.9.3) id LAA18011; Thu, 23 Aug 2001 11:36:53 -0700 Date: Thu, 23 Aug 2001 11:36:53 -0700 Message-Id: <200108231836.LAA18011@permissiononly.com> Content-type: text/html From: tpinkus@vitalstream.cc To: simple@mailman.dynamicsoft.com Content-Length: 6403 Subject: [Simple] Add Streaming Media to your Web Site 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: VitalStream
 
Now Showing
Free Streaming Kit
You Can Add Streaming Media to
Your Company's Web Site

Streaming Media is Easier Than You Think

I invite you to learn more about streaming media by reading our Free Streaming Kit on Live Streaming with Windows Media. It contains a step-by-step tutorial on how to stream media over the Internet with Windows Media technologies.

VitalStream specializes in customized streaming and hosting solutions for small to medium sized businesses.

VitalStream Delivers...

- Live and On-Demand Streaming
- Pay-Per-View Solutions
- 24 x 7 Live Technical Support
- 99.7% Guaranteed Uptime
- And More...

These companies use us
for their streaming needs.

Call today to see what
VitalStream can do for
your company's web site

 Windows Media Service Provider

Tom Pinkus
Account Representative
(800) 254-7554 x2038
tpinkus@vitalstream.cc

VitalStream
 


Click here if you received this message in error.

Microsoft, Windows Media, and the Windows Logo are trademarks or registered
trademarks of Microsoft Corporation in the United States and/or other countries.

From jdrosen@dynamicsoft.com Fri Aug 24 02:03:38 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16856 for ; Fri, 24 Aug 2001 02:03:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7O62ZrN029851; Fri, 24 Aug 2001 02:02:35 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 02:03:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'SpatialLocation@digitalknowledge.net'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Date: Fri, 24 Aug 2001 02:03:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 8990 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: > -----Original Message----- > From: SpatialLocation@digitalknowledge.net > [mailto:SpatialLocation@digitalknowledge.net] > Sent: Thursday, August 23, 2001 8:12 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol > > although one could argue it is still a mis-use of ideal SIP. This is > because it is still carrying a payload and not necessarily > initiating a > 'session' Unless the session is a human-based session, i.e. > "come here > watson" or "can I ask you a quick question?" which would then > create the > need for a 'session of MESSAGES' or physical appearance, > either of which > SHOULD be handled by another protocol. Perhaps you should take a look at SIP, which defines several methods that have exactly ZERO to do with establishing a session (OPTIONS, BYE, REGISTER in the base spec). OPTIONS, in particular, is the case that the value SIP provides is the ability to address a request towards a user with a location-independent name (sip:jdrosen@dynamicsoft.com) and make sure that this request is forward to the many places that the user may have a point of communications. What SIP is really good at is this kind of human user rendezvous. In the case of the paging model, there are two tasks at hand - (1) taking of a location indpendent name, i.e., sip:jdrosen@dynamicsoft.com, and getting a message to that user at the many places the user has a point of communications, (2) the message should contain some content that is rednered to the user. IMHO, the hard part of that problem is the routing of the request towards the user. The easy part is sticking some payload in that message. Since SIP already supports MIME payloads, SIP can provide the paging model of IM pretty much as a freebie over its existing proxy networks, which exist for the purpose of user rendezvous. If you add to that the abilities SIP provides for user identification and authentication, privacy services, call routing preference services, multipart capabilities, and so on, all of which can be applied to the IM paging model even, it seems that you get quite a lot of reuse. This is why there was a substantial community that found the provision of IM/presence with SIP to be a good thing, and so the group was chartered. So, let us put these irritating statements about "don't use SIP for IM at all", which appear to be in vogue on this list these days, to rest. The point is moot. > Jonathon R. would like to have end-to-end session of MESSAGEs > to travel > between the clients directly as this supports the scalability > and original > voice use of the SIP server. On the other hand this doesn't > support the > fundamental design requirements of IM as stated in rfc2779 > 2.4.3/2.4.4. > Which means, prior to supporting that end-to-end > communication, the SIP > server would have to determine if 'that was allowed' based on > the security > requirements Vasilis and Robert O have been talking about, > which is also > required per rfc2779. My preference is e2e. That doesn't mean its not possible to use intermediaries, no matter what the transport. I'll note that the same exact issues arise for voice and video. > > Those fundamental services can be easily implemented at the > SIP server if > SIP was the method used to send 'sessions of MESSAGES' - False. It is easy to do this independent of the transport. Processing-wise, it is more intensive to do this with SIP, since SIP message processing is far more intensive than the the TCP byte shuffling I have described in previous posts. > The intermediary/PROXY MUST be created and supported as a > basic feature of > the IM 'session of MESSAGEs' design. I agree it is a requirement that such a thing be possible. I think it is easy to show that it is doable for any transport protocol. > > In Robert Os case he would want the development of that > intermediary to play > off of the domain and security information designed into the > SIP server > (thus making it portable across SIP and the IM proxy). > > This is easily designed if you have a unified > configuration-directory where > the SIP Server and IM Message proxy pull configuration information, > otherwise, it looks like a complex proposition. I will comment separately on Robert's inter-enterprise-with-firewalls case. But, I'll note that you've got a general problem here for all session oriented protocols. If you put IM on the proxy path, well, that might be easy, but voice will never work that way. Neither will video. Neither will games. Neither will the new communications medium of next year. So, you can solve this with a one-off solution that works for ONE, and ONLY ONE form of communications (IM), or you can solve it in a more general way that enables this domain security to be applied to all media types. The SIP view is to solve these for all media types with a generic mechanism. I think that is the right approach. > In addition, to support end-to-end signaling the SIP server > needs to have > logic on whether or not that end-to-end signaling is allowed > or whether it's > end-to-end-to-end-to-end :) - this meets the rfc2779 2.4.3/4 > requirement, > regardless of natiness. SIP doesn't specify what policy you put into your proxies. If you want to introduce these intermediaries, you can. > Jonathon R. has some good solutions for the intermediary in > other IDs he has > written, but the reality is the communication looks more like 'direct > chatting' than text based audio/video conference, which is > why the IESG > probably frowned on using RTP No such thing happened. You might even want to take a look at RFC2793, "RTP Payload format for text conversation". RTP is not a fit for IM for other reasons. > As an aside, I would also presume this is why sctp may not be > a necessary > choice for the instant message 'signaling', to use a term > from voice drafts, > given the sctp's primary use, albeit congestion management at the > intermediary/PROXY. IMs are only text per node, am I naive > to think it's a > moot point or would there be congestion issues at the intermediary??? There will be lots of congestion with IM, which is why a congestion-control enabled transport is required by IESG. In fact, IM could potentially be the source of boundless congestion. Think about what it offers - end to end transport of arbitrary content between peer users. I can think of a million uses for that, many of which have little to do with instant messaging as you know it. The developers of aimster have already seen this value, and there will be others. This is why congestion control is so important, and this is why I don't want my proxies in the path of 120Meg IM transfers. Let routers do bit shuffling. Let proxies do rendezvous. > > Lastly, Jonathon R appears convinced that the communication should be > end-to-end. > (http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html), >but over TCP :)! That works great if you are trying to scale the servers >and you want to put two callers together, but with IM, it's not voice and >it's like email, but more importantly, as stated in rfc2779, the >security/control needs to be built in. Ultimately, the best security is afforded by a pure, session oriented end to end model. I find it frightening that people associate privacy with sending all of their messages to MSN/Yahoo/AOL/whomever for archival and who-knows-what-else. The security community has long recognized the power of e2e security vs. transitive chains of trust. I am just pointing out the >'vision/scope' of rfc2779 that says 'when you are heads down discussing >technical stuff, don't forget these requirements' Jonathon didn't write >that RFC2779 so he probably isn't thinking with that light bulb on. I take personal offense at this. >I would not want to see the IMsession design based on 'phone-calls' as >that's the 'way SIP has been predominatly used', but instead, to take a >different and assuredly positive approach. I could not disagree more. This group was formed because there is a large community that believes that the right technical approach is to view communications in the more general multi-modal (IM, voice, video, gaming, etc.) context, rather than point solutions for each mode. Absolutely NONE of the issues you raise applies to IM alone or voice alone, and I have pointed these cases out explicitly above. >I am not intending to offend anyone In that case, I would recommend that you refrain from personal insults, as you have done above, as those usual cause people as myself to take offense. -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 From Vasilis.Polychronidis@Openwave.com Fri Aug 24 07:39:37 2001 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 HAA17773 for ; Fri, 24 Aug 2001 07:39:36 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010824113748.OLOM3396.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Fri, 24 Aug 2001 06:37:48 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010824113934.WYOW26952.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Fri, 24 Aug 2001 06:39:34 -0500 Message-ID: <3B863CF5.A0EF2E63@Openwave.com> Date: Fri, 24 Aug 2001 04:39:33 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'SpatialLocation@digitalknowledge.net'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol References: Content-Type: multipart/alternative; boundary="------------F9EBDE8EDAECE78311C12493" Content-Length: 1433 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: --------------F9EBDE8EDAECE78311C12493 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > The intermediary/PROXY MUST be created and supported as a > > basic feature of > > the IM 'session of MESSAGEs' design. > > I agree it is a requirement that such a thing be possible. I think it is > easy to show that it is doable for any transport protocol. Jonathan are you planing to write an ID explaining how? I would like to see all of the issues raised by myself and Robert O, to be resolved with your proposal if possible. --------------F9EBDE8EDAECE78311C12493 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote:
 
> The intermediary/PROXY MUST be created and supported as a
> basic feature of
> the IM 'session of MESSAGEs' design.

I agree it is a requirement that such a thing be possible. I think it is
easy to show that it is doable for any transport protocol.

Jonathan are you planing to write an ID explaining how?
I would like to see all of the issues raised by myself and Robert O,
to be resolved with your proposal if possible.
  --------------F9EBDE8EDAECE78311C12493-- From Vasilis.Polychronidis@Openwave.com Fri Aug 24 07:40:20 2001 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 HAA17792 for ; Fri, 24 Aug 2001 07:40:20 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010824113832.OMGI3396.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Fri, 24 Aug 2001 06:38:32 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010824114018.WYPK26952.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Fri, 24 Aug 2001 06:40:18 -0500 Message-ID: <3B863D21.25454C4D@Openwave.com> Date: Fri, 24 Aug 2001 04:40:17 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'SpatialLocation@digitalknowledge.net'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol References: Content-Type: multipart/alternative; boundary="------------628175FE471AE62C2681929E" Content-Length: 1631 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: --------------628175FE471AE62C2681929E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > The intermediary/PROXY MUST be created and supported as a > > basic feature of > > the IM 'session of MESSAGEs' design. > > I agree it is a requirement that such a thing be possible. I think it is > easy to show that it is doable for any transport protocol. Jonathan are you planing to write an ID explaining how? I would like to see all of the issues raised by myself and Robert O, to be resolved with your proposal if possible. Kind Regards, -Vasilis Polychronidis --------------628175FE471AE62C2681929E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote:
 
> The intermediary/PROXY MUST be created and supported as a
> basic feature of
> the IM 'session of MESSAGEs' design.

I agree it is a requirement that such a thing be possible. I think it is
easy to show that it is doable for any transport protocol.

Jonathan are you planing to write an ID explaining how?
I would like to see all of the issues raised by myself and Robert O,
to be resolved with your proposal if possible.

Kind Regards,

-Vasilis Polychronidis
  --------------628175FE471AE62C2681929E-- From HUITEMA@windows.microsoft.com Fri Aug 24 12:41:23 2001 Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA18682 for ; Fri, 24 Aug 2001 12:41:22 -0400 (EDT) Received: from 157.54.9.101 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 24 Aug 2001 09:39:49 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 09:39:48 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 09:39:47 -0700 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(5.0.2195.2966); Fri, 24 Aug 2001 09:39:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Date: Fri, 24 Aug 2001 09:39:30 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Thread-Index: AcEsY5IS+RsJm/1wTE+ObtVCFszhBAAVEisw From: "Christian Huitema" To: "Jonathan Rosenberg" Cc: X-OriginalArrivalTime: 24 Aug 2001 16:39:31.0484 (UTC) FILETIME=[597B3DC0:01C12CBB] Content-Length: 1929 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA18682 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: Let's take another try at summarizing our dilemma: 1) Carrying Messages through the proxies works, goes through firewalls, but has the potential of overloading the signaling infrastructure if messaging is used for something else than 5 char per sec chat. Also, Message has a strictly one-to-one semantic, which obliges us to resort to funny tricks for multi-party chat sessions. 2) Treating IM as just one specific media in a multi-modal session is fully in line with the SIP architecture; it provides an easy path for multi-party and other fancy session management extensions. However, we have not agreed on the transport; also, we know that the transport will probably have to be over TCP, which means that we will not be able to re-use the NAT and firewall traversal solutions designed for RTP over UDP. The IESG hand us an edict to "not pick alternative 1." It seems to me that, at this stage, we have to collect transport proposals. The proposals should define the transport format and the SDP documentation of the media. They should meet a set of requirements, which I would basically summarize as "parity with RTP" when it comes to security, multiparty, and ease of proxying; the CPIM requirement of, essentially, carrying MIME types messages; and the additional requirement is to implement AIMD congestion control, e.g. by running over TCP. So far, I see two alternatives: 1) Jonathan's proposal of using MESSAGE in an "end-to-end" fashion. I see how we can do MIME and proxying, but I don't have a clear understanding of security and multiparty. Can we reuse carry keys through SDP in the same way as we carry keys for audio and video? 2) A yet to be defined protocol running over TCP -- but whoever thinks this is a good idea should write a draft that we can analyze. RTP-text is not an alternative; even if we somehow added AIMD congestion control, it does not meet the CPIM requirements. -- Christian Huitema From petkos@cs.columbia.edu Fri Aug 24 13:20:34 2001 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 NAA18825 for ; Fri, 24 Aug 2001 13:20:34 -0400 (EDT) Received: from dynamo.cs.columbia.edu (dynamo.cs.columbia.edu [128.59.16.4]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA14816; Fri, 24 Aug 2001 13:20:33 -0400 (EDT) Received: (from petkos@localhost) by dynamo.cs.columbia.edu (8.9.3+Sun/8.9.3) id NAA05685; Fri, 24 Aug 2001 13:20:32 -0400 (EDT) From: "Petri K. Koskelainen" Message-Id: <200108241720.NAA05685@dynamo.cs.columbia.edu> To: sean.olson@ericsson.com Date: Fri, 24 Aug 2001 13:20:32 -0400 (EDT) Cc: simple@mailman.dynamicsoft.com, petkos@cs.columbia.edu, schulzrinne@cs.columbia.edu In-Reply-To: from "sean.olson@ericsson.com" at Aug 23, 2001 11:42:58 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2014 Subject: [Simple] Re: draft-koskelainen-sip-group-00 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: Hi, Thanks for the comments. This was an invidual submission, a discussion document meant to raise the discussion around this topic. SIMPLE WG is probably good place to continue this work if there is enough interest. The draft-ietf-simple-im-01.txt document might be the easiest route to progress with some of the issues found useful in the discussion document? I'd like to continue at least with the following issues: - event package for group message delivery status notification - message and thread identification mechanisms e.g. Message-id and References header (or In-Reply-To as you said) - message sequencing (ordering information) since in some cases the 1-second granularity of Date header is not enough. We were assuming that in some cases the recipient of the MESSAGE is not human (but application which require the exact ordering information). Also, I'm not convinced that all group messaging issues are understood widely enough by implementors so some kind of informational RFC (or guideline chapter in simple-im draft) might be a good idea. Otherwise we'll see a lot of variations in implementation details and interoperability is more difficult (group messaging is provided in several different ways). br, -- Petri > > I was curious about the status of this draft and > its possible inclusion into the MESSAGE work > within SIMPLE. The draft points out a number > of interesting problems and possible solutions > for dealing with requests sent to potentially > large groups (for example, instant messaging > to a chat room). > > Adding a Message-Id: header seems like a very > good idea. I would prefer In-Reply-To: instead > of References:, but this addition seems sound > as well. The addition of a message sequence > header is my only hesitation. I think a Date: > timestamp is sufficient for all real world > problems, given that MESSAGE is meant to be > rendered to a human user and not to a automaton. > > Any comments? > Regards, > Sean Olson > Ericsson Inc. > > From pkyzivat@cisco.com Fri Aug 24 13:48:37 2001 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 NAA18934 for ; Fri, 24 Aug 2001 13:48:37 -0400 (EDT) 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 f7OHlk617131; Fri, 24 Aug 2001 13:47:46 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAJ09183 (AUTH pkyzivat); Fri, 24 Aug 2001 13:48:57 -0400 (EDT) Message-ID: <3B8691D8.E1F9B6AA@cisco.com> Date: Fri, 24 Aug 2001 13:41:44 -0400 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: "Petri K. Koskelainen" CC: sean.olson@ericsson.com, simple@mailman.dynamicsoft.com, schulzrinne@cs.columbia.edu Subject: Re: [Simple] Re: draft-koskelainen-sip-group-00 References: <200108241720.NAA05685@dynamo.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3342 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: Petri, I had one comment about this, wrt sequencing. You state (in 5.3): > Group messaging should enable ordering. This means that clients > should know in what order (or time) the messages were processed > and sent by the server. ... > Therefore server should add ordering information to the outgoing > message. Ordering added by the server is only useful if everybody receives all the messages from the server. But as far as I know nobody has proposed a model where a message sender receives its own messages back from the server. As a result, the sender has to order its own messages relative to those it receives, and there is no guarantee that it will do so the same way as the server does. There is a similar problem if you conference together two existing conferences each with its own server. The idea of a single server coordinating all traffic is fundamentally different from a protocol designed to work e2e with the possibility of some endpoints acting as mixers for other endpoints. Paul Kyzivat Cisco Systems "Petri K. Koskelainen" wrote: > > Hi, > > Thanks for the comments. > > This was an invidual submission, a discussion document > meant to raise the discussion around this topic. > > SIMPLE WG is probably good place to continue this > work if there is enough interest. The > draft-ietf-simple-im-01.txt document might be the > easiest route to progress with some of the issues found > useful in the discussion document? > > I'd like to continue at least with the following issues: > - event package for group message delivery status notification > - message and thread identification mechanisms > e.g. Message-id and References header (or In-Reply-To as you said) > - message sequencing (ordering information) since in some cases > the 1-second granularity of Date header is not enough. > We were assuming that in some cases the recipient of the MESSAGE > is not human (but application which require the exact ordering > information). > > Also, I'm not convinced that all group messaging issues are understood > widely enough by implementors so some kind of informational RFC (or > guideline chapter in simple-im draft) might be a good idea. > Otherwise we'll see a lot of variations in implementation details > and interoperability is more difficult (group messaging is provided > in several different ways). > > br, > -- > Petri > > > > > I was curious about the status of this draft and > > its possible inclusion into the MESSAGE work > > within SIMPLE. The draft points out a number > > of interesting problems and possible solutions > > for dealing with requests sent to potentially > > large groups (for example, instant messaging > > to a chat room). > > > > Adding a Message-Id: header seems like a very > > good idea. I would prefer In-Reply-To: instead > > of References:, but this addition seems sound > > as well. The addition of a message sequence > > header is my only hesitation. I think a Date: > > timestamp is sufficient for all real world > > problems, given that MESSAGE is meant to be > > rendered to a human user and not to a automaton. > > > > Any comments? > > Regards, > > Sean Olson > > Ericsson Inc. > > > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From jdrosen@dynamicsoft.com Sat Aug 25 00:52:24 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20659 for ; Sat, 25 Aug 2001 00:52:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7P4pUrN007346; Sat, 25 Aug 2001 00:51:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 25 Aug 2001 00:52:19 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christian Huitema'" , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Date: Sat, 25 Aug 2001 00:52:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 4361 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: > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Friday, August 24, 2001 12:40 PM > To: Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol > > > 2) Treating IM as just one specific media in a multi-modal session is > fully in line with the SIP architecture; it provides an easy path for > multi-party and other fancy session management extensions. However, we > have not agreed on the transport; also, we know that the > transport will > probably have to be over TCP, which means that we will not be able to > re-use the NAT and firewall traversal solutions designed for RTP over > UDP. Actually, I think we can get some reuse. The scenario is identical to the case where you are behind a symmetric NAT. I posted a note previously on the list describing a tcp variant of the reflector protocol. Basically, if you learn you are behind a nat (based on the documented udp mechanisms in draft-rosenberg-sip-entfw-02), and want to do an IM session, you initiate a TCP connection to a "tcp reflector" in the service provider network. Once you connect, the provider sends data over that connection (or to another connection thats been established for this purpose) with the binding of this new connection. The binding is an IP/port such that if a host does a TCP connect to it, the "reflector" will join the two connections, shuffling data between them. Then, you just include that binding, a public address, as the port to receive IM on. Since this is a connection oriented media transport, we use draft-ietf-mmusic-comedia. The direction attributes are sent as described in entfw, as if this were symmetric RTP. The result is that you still get a direct TCP connection if only one side is behind a nat, but use the intermediary if both are behind it. The logic that makes this happen is identical to the symmetric RTP case from entfw. So, there is good reuse of the nat stuff, I think. > > The IESG hand us an edict to "not pick alternative 1." No, thats not the edit actuallly. In the "page model", which is what I think you mean by alternative 1 (there is no INVITE), we will use mESSAGE through the proxy networks. The edict is that when we use INVITE to set it up (session model), the transport is not SIP, whether it be end to end or through proxies. > It seems to me > that, at this stage, we have to collect transport proposals. The > proposals should define the transport format and the SDP documentation > of the media. They should meet a set of requirements, which I would > basically summarize as "parity with RTP" when it comes to security, > multiparty, and ease of proxying; the CPIM requirement of, > essentially, > carrying MIME types messages; and the additional requirement is to > implement AIMD congestion control, e.g. by running over TCP. Right. I sent out a list of requirements in a previous note. Let me add another for people to noodle over: eventual support for multicast IM. Ouchies! That would be desirable in the long run, but I don't know that a single transport can satisfy the congestion control and multicast requirements, at least not today. If I had to choose, I'd drop multicast. So far, I > see two alternatives: > > 1) Jonathan's proposal of using MESSAGE in an "end-to-end" fashion. I > see how we can do MIME and proxying, but I don't have a clear > understanding of security and multiparty. Can we reuse carry keys > through SDP in the same way as we carry keys for audio and video? Well, this proposal has been dismissed as a result of the edict from IESG. e2e or through proxies, it aint sip. > > 2) A yet to be defined protocol running over TCP -- but whoever thinks > this is a good idea should write a draft that we can analyze. We assigned someone at last IETF to look it over and come up with some ideas. I am leaning towards something that resembles MIME over TCP (or possibly CPIM over TCP). -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 From joshua@digitalknowledge.net Sun Aug 26 01:44:29 2001 Received: from granada.digitalknowledge.net (cdm-208-145-244-geor.cox-internet.com [208.180.145.244]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24711 for ; Sun, 26 Aug 2001 01:44:28 -0400 (EDT) From: joshua@digitalknowledge.net Received: by granada.digitalknowledge.net with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Aug 2001 00:47:48 -0500 Message-ID: To: simple@mailman.dynamicsoft.com Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Date: Sun, 26 Aug 2001 00:47:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 11764 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: > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, August 24, 2001 1:03 AM > To: Spatial Location; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol > > > > > > > > -----Original Message----- > > From: SpatialLocation@digitalknowledge.net > > [mailto:SpatialLocation@digitalknowledge.net] > > Sent: Thursday, August 23, 2001 8:12 AM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol > > > > although one could argue it is still a mis-use of ideal > SIP. This is > > because it is still carrying a payload and not necessarily > > initiating a > > 'session' Unless the session is a human-based session, i.e. > > "come here > > watson" or "can I ask you a quick question?" which would then > > create the > > need for a 'session of MESSAGES' or physical appearance, > > either of which > > SHOULD be handled by another protocol. > > Perhaps you should take a look at SIP, which defines several > So, let us put these irritating statements about "don't use > SIP for IM at > all", which appear to be in vogue on this list these days, to > rest. The > point is moot. I agree with you 100%. The difference between paging and sessions is the use of INVITE. So, SIP is great for paging, but once the INVITE flys, then it's session time. > > > Jonathon R. would like to have end-to-end session of MESSAGEs > > to travel > > between the clients directly as this supports the scalability > > and original > > voice use of the SIP server. On the other hand this doesn't > > support the > > fundamental design requirements of IM as stated in rfc2779 > > 2.4.3/2.4.4. > > Which means, prior to supporting that end-to-end > > communication, the SIP > > server would have to determine if 'that was allowed' based on > > the security > > requirements Vasilis and Robert O have been talking about, > > which is also > > required per rfc2779. > > My preference is e2e. That doesn't mean its not possible to use > intermediaries, no matter what the transport. I'll note that > the same exact > issues arise for voice and video. I also don't mean to imply you don't see those options. I also see your claim with the issues in voice/video. The choice made for the protocol needs to make it possible for the e2e security mechanism to be reused/forwarded by PROXY/intermediaries. I liken the intermediary to a PBX at companies today - there is a value to screen certain calls, where others you just let through. The reality is, there needs to be a way to provide an intermediary solution between the endpoints as necessary with interoperability. > > > > > > Those fundamental services can be easily implemented at the > > SIP server if > > SIP was the method used to send 'sessions of MESSAGES' - > > False. It is easy to do this independent of the transport. > Processing-wise, > it is more intensive to do this with SIP, since SIP message > processing is > far more intensive than the the TCP byte shuffling I have described in > previous posts. I agree with you and so did the IESG, which is why they/we are pushing 'sessions of MESSAGEs' to another protocol and transport, i.e. cpim/tcp or cpim/sctp. Easy above is relative, to continue to process the IMsessions as MESSAGEs appears, on the surfuce, simpler. As you note and I agree with, it is doesn't scale well in very large peer2peer environemnts, i.e mobile phones. > > > The intermediary/PROXY MUST be created and supported as a > > basic feature of > > the IM 'session of MESSAGEs' design. > > I agree it is a requirement that such a thing be possible. I > think it is > easy to show that it is doable for any transport protocol. > I understand that and would ask the same question of vasilis - would you write that? > > > > In Robert Os case he would want the development of that > > intermediary to play > > off of the domain and security information designed into the > > SIP server > > (thus making it portable across SIP and the IM proxy). > > > > This is easily designed if you have a unified > > configuration-directory where > > the SIP Server and IM Message proxy pull configuration information, > > otherwise, it looks like a complex proposition. > >I will comment separately on Robert's inter-enterprise-with-firewalls case. >But, I'll note that you've got a general problem here for all session >oriented protocols. If you put IM on the proxy path, well, that might be >easy, but voice will never work that way. Neither will video. Neither will >games. Neither will the new communications medium of next year. So, you can >solve this with a one-off solution that works for ONE, and ONLY ONE form of >communications (IM), or you can solve it in a more general way that enables >this domain security to be applied to all media types. The SIP view is to >solve these for all media types with a generic mechanism. I think that is >the right approach. I don't advocate all IMsessions over the proxy, but only when necessary for security. A method needs to be considered on how do this so existing companies/carriers/etc can remain interoperable. The question is how do you build in the 'necessity for security' into the IMSession protocol or SIP for Instant Messaging. If the SIP server provides the IMclient with an IMProxy that seems most probable. This, then, uses sip to solve the problem. I believe these mechanisms are already in place for voice? > > > > Jonathon R. has some good solutions for the intermediary in > > other IDs he has > > written, but the reality is the communication looks more > like 'direct > > chatting' than text based audio/video conference, which is > > why the IESG > > probably frowned on using RTP > > No such thing happened. You might even want to take a look at > RFC2793, "RTP > Payload format for text conversation". RTP is not a fit for > IM for other > reasons. Thanks for pointing this out - I'll follow your lead on this method. > > > > IMs are only text per node, am I naive > > to think it's a > > moot point or would there be congestion issues at the > intermediary??? >I don't want my proxies in the path of 120Meg IM > transfers. Let routers > do bit shuffling. Let proxies do rendezvous. I agree with you as this is a good argument to avoid putting a 'proxy' in between users. Although, in a corporation one would specify policy on the intermediary/PROXY to avoid that large TX, thus it is irrespective of the base protocol. however, that's implementation and restrictions not needed to be defined by the protocol itself. In a carrier network or ISP a proxy may not be possible (reasonable). The SIP server wouldn't hand the user off to an intermediary IMProxy, but provide e2e solutions. > > > > > Lastly, Jonathon R appears convinced that the communication > should be > > end-to-end. > > > (http://mailman.dynamicsoft.com/pipermail/simple/2001-August/0 > 00606.html), > >but over TCP :)! That works great if you are trying to > scale the servers > >and you want to put two callers together, but with IM, it's > not voice and > >it's like email, but more importantly, as stated in rfc2779, the > >security/control needs to be built in. > > Ultimately, the best security is afforded by a pure, session > oriented end to > end model. I find it frightening that people associate > privacy with sending > all of their messages to MSN/Yahoo/AOL/whomever for archival and > who-knows-what-else. The security community has long > recognized the power of > e2e security vs. transitive chains of trust. My thought doesn't consider specific companies, but it does consider a need to use an intermediary at a network boundary when necessary. e2e is one solution, but an intermediary is still necessary and the SIP server provies the capability to hand the user off to an IMProxy or an actual IM user agent. The intermediary starts to look like PSTN2PBX in a company, but some organizations have found a PBX valuable: scoping calls, screening, no-direct dial to inside phones etc. > > > > I am just pointing out the > >'vision/scope' of rfc2779 that says 'when you are heads down > discussing > >technical stuff, don't forget these requirements' Jonathon > didn't write > >that RFC2779 so he probably isn't thinking with that light bulb on. > > I take personal offense at this. I agree and I should have just made the point. It was intended to be 'lite' as it is obvious you enjoy or have some fun with the IDs. And as it's been said 'if you don't want to WORK do something you like' I extend an apology to you as sincere as I can given the newness of our association. > > > >I would not want to see the IMsession design based on > 'phone-calls' as > >that's the 'way SIP has been predominatly used', but > instead, to take a > >different and assuredly positive approach. > > I could not disagree more. This group was formed because > there is a large > community that believes that the right technical approach is to view > communications in the more general multi-modal (IM, voice, > video, gaming, > etc.) context, rather than point solutions for each mode. > Absolutely NONE of > the issues you raise applies to IM alone or voice alone, and > I have pointed > these cases out explicitly above. 'This group was formed' - simple or sip? I presume you mean SIP. If you mean SIP then it's primary goal is to provide rendevous mechanisms between zero-time communictions UAs. If you mean SIMPLe, then I may have to re-read the the WG description, but it looks like the role is define SIP and IMP relationships when necessary, where as, in this case there is an argument for the use and creation of an IMsession mechanism. Let's look at the requirements for the IMsessions: Jonathon R. 1. reliable, sequenced delivery of messages 2. support for messages of arbitrary size, from 1 byte to megabytes (think aimster) 3. congestion control 4. framing 5. content typing (text/html, text/plain, etc.) 6. support for e2e privacy, authentication, integrity 7. natability (i.e., can be made to work through nats without major headaches) 8. rapid delivery (one the order of hundreds of milliseconds to a second) 9. relatively lightweight (will need to be implemented in phones and other smaller devices) Paul K 10. provision for IM conferences. Joshua K etc (not claiming ownership just adding a point) 11. In my opinion the protocol needs to 'work' with/between PROXY/intermediaries in a standarized format. This facilitates internet/extranet quality and level of use. This kinda looks like IM conferences, but the basis is security not group sessions. My point is simply this, the 'method' (not server) used to hand multiple IMs off to a conference server could be used to support intermediary network perimeter security. If one claims that IM conferences should occur e2e then I can tell you that's not stable in most environments and becomes unstable if the primary UA doing the mixing drops out. I believe the use of CPIM would still be necessary, albeit the superfluous use of to/from in a strict e2e scenario, but in an e2p2e, e2p2p2e or Hop-by-hop scenarios I believe it it is still useful. > > >I am not intending to offend anyone > > In that case, I would recommend that you refrain from > personal insults, as > you have done above, as those usual cause people as myself to > take offense. Noted Lastly, I agree with Jonathon R on getting some requirments down so you get into the tasking of an actual protocol. So with that said, I think the point 11 above looks suspiciously like 10 - the need for 'conference' type IM services. Joshua From joshua@digitalknowledge.net Sun Aug 26 01:52:52 2001 Received: from granada.digitalknowledge.net (cdm-208-145-244-geor.cox-internet.com [208.180.145.244]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24786 for ; Sun, 26 Aug 2001 01:52:51 -0400 (EDT) From: joshua@digitalknowledge.net Received: by granada.digitalknowledge.net with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Aug 2001 00:56:22 -0500 Message-ID: To: simple@mailman.dynamicsoft.com Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Date: Sun, 26 Aug 2001 00:56:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 5528 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: > -----Original Message----- > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Thursday, August 23, 2001 9:35 AM > To: 'ext Oded Cnaan'; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol > > > > Comments inline: > > >I agree with Joshua K regarding the MESSAGE analysis. It's > important to > >remember, that leaving IM to end-to-end communications results in a > security > >hole that allows other users to reveal your IP address. > > > > A possible way to avoid this is to use HIP (Host identity payload) > instead of IP addresses to identify the clients. This would give e2e > security between the end points as well as prevent attacks because of > IP address exposure. > This makes sense and could be considered by the architects of the IM Session based protocol, which needs to be defined. However, it should be noted that the primary starting point should be with requirements (per JR earlier) and not existing solutions. Please understand this is not an attempt to degrade your suggestion as it holds merit given the current needs. I am not to familiar with HIP, maybe you could expound on how that works or just suggest a read to me. (just trying to get your perspective) > >Several IM services that used to reveal users' IPs (like ICQ) caused > deadly > >attacks by hackers on user's clients. If you take a look at > the leading > IM > >services, none of them support end-to-end communications (for IM). > > > > According to RFC3041 : > " > Use of the extension causes nodes to generate global-scope > addresses from interface identifiers that change over time, even in > cases where the interface contains an embedded IEEE identifier. > Changing the interface identifier (and the global-scope addresses > generated from it) over time makes it more difficult for > eavesdroppers and other information collectors to identify when > different addresses used in different transactions actually > correspond to the same node > " > > So in the case of IPv6 clients could possibly use this mechanism to > achieve some degree of privacy and a way to prevent attacks, > especially if the client keeps changing its address on a > frequent basis. > This is 'relatively' secure given the dynamic nature of IP use, none-the-less, there will be enterprises that will want to restrict direct communications with internal IM clients. In short, it's a good point on how end-to-end communications can be somewhat safeguarded! > >There are two different concepts in IM, that sometimes are > perceived as > one. > >The first is Instant Messaging (IM) which means sending direct and > quick > >message to someone. The latter is chatting, which means continuous > >messaging. Several services converge these concepts into one feature > while > >other let the user choose between the two. > > > >I think that SIP needs to support both options. MESSAGE > should be used > to > >send a direct IM (through the server, that might redirect it to the > >client) > > Are you suggesting that clients always use the intermediate server for > sending IM? It may make sense in some scenarios, but not always. > Professionally I would not advocate *always* using the intermediary, however, the logic should be built into the SIP establishment for IM to use an intermediary in the event a secure network perimeter is being traveresed and e2e is not allowed. This of course is defined by the enterprise hosting the purported "secure network". In the case of a service provider, like AT&T wireless they could implement IM in an direct end-to-end (e2e) fashion as suggested by Jonathon R. However, the e2e solution may not work 100% for the enterprises or between AOL networks and DigitalKnowledge.NET, for example. In the case of an enterprise which is accepting communications from a client on the AT&T wireless network, it's necessary to define rules by which the SIP server would hand off the session to the enterprise client directly or to an intermediary to support network/domain security - no nating at issue here, strictly perimiter protection. In these cases the IMsession protocl would need to handle proxying the messages in an e2p2e scenario or in somecases an e2p2p2e scenario. So it's probably best to focus on the requirments as suggested by JR in earlier messages. As noted in my last response to JR, I believe we should consider situations where E2E is not allowed and messages do need to be proxied. So that makes it 11 requirements, albeit that fresh one jonathon brougt up 'multicast IM?' Joshua Requirments as of 8/26/01 Let's look at the requirements for the IMsessions: Jonathon R. 1. reliable, sequenced delivery of messages 2. support for messages of arbitrary size, from 1 byte to megabytes (think aimster) 3. congestion control 4. framing 5. content typing (text/html, text/plain, etc.) 6. support for e2e privacy, authentication, integrity 7. natability (i.e., can be made to work through nats without major headaches) 8. rapid delivery (one the order of hundreds of milliseconds to a second) 9. relatively lightweight (will need to be implemented in phones and other smaller devices) Paul K 10. provision for IM conferences. Joshua K etc (not claiming ownership just adding a point) 11. In my opinion the protocol needs to 'work' with/between PROXY/intermediaries in a standarized format. This facilitates internet/extranet quality and level of use. Jonathon R. 12. Multicast IM From oded@novawiz.com Mon Aug 27 04:31:27 2001 Received: from dino.novawiz.com ([212.150.9.210]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00270 for ; Mon, 27 Aug 2001 04:31:21 -0400 (EDT) Received: from mona.odigo.com (comp30 [10.0.0.30]) by dino.novawiz.com (8.11.1/8.11.1) with ESMTP id f7R8UJw22680; Mon, 27 Aug 2001 11:30:20 +0300 Received: by MONA with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 11:31:04 +0200 Message-ID: From: Oded Cnaan To: "'simple@mailman.dynamicsoft.com'" Cc: "'Gabriel Matsliach (E-mail)'" , "'Avner Ronen (E-mail)'" Subject: [Simple] 'Sessions of MESSAGEs' Date: Mon, 27 Aug 2001 11:31:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2005 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: Let's say that user A wishes to send a message to user B, assuming the session model for messaging. In this case, there are two options: 1. Start a session, send the message and close the session (INVITE..MESSAGE..BYE) 2. Start a session, send the message and leave the session open for consecutive messages. The session will be closed at a later time (INVITE..MESSAGE..MESSAGE..MESSAGE..BYE) The first scenario puts a lot of burden on the server (proxy) and network as it requires several transactions for only sending a single message. The second scenario, that seems more logical, carries a different kind of difficulty. In 'All IP' networks, the IP of the handset may be changed by the network at any time (the user moves to a different base station or even moves to a different network). When the address of the recipient changes after a session has already started, consecutive messages will fail. Unlike VoIP sessions, messages are not streamed so user A has no way to know that B's address has changed (assuming B is not in A's friend list). Moving to the more general discussion: In the discussions so far, it seems that there is a tendency to treat IM as any other messaging media (VoIP, calls etc.). I understand the 'esthetics' of this solution but I believe that it neglects the special behavior (and use) of IM in oppose to other medias. IM is used in its core for quick, short text messaging while VoIP, a phone call or even a Quack game are used to create a stream intended to be used for a long discussion / game / whatever. It seems to me that SIMPLE should support 2 types of messaging: 1. Direct MESSAGE (as in the current draft) without initiating a session 2. A session based messaging using the second model mentioned above. (INVITE..MESSAGE..MESSAGE..MESSAGE..BYE) This will be very useful for initiating chat sessions, in opposed to single messaging. I would be interested in hearing other people's opinions on that. Oded Cna'an VP, New Technologies Odigo Inc. From bcampbell@dynamicsoft.com Mon Aug 27 09:58:00 2001 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 JAA01120 for ; Mon, 27 Aug 2001 09:57:59 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7RDuK001128; Mon, 27 Aug 2001 08:56:21 -0500 Message-ID: <3B8A5184.1040007@dynamicsoft.com> Date: Mon, 27 Aug 2001 08:56:20 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: Oded Cnaan CC: "'simple@mailman.dynamicsoft.com'" , "'Gabriel Matsliach (E-mail)'" , "'Avner Ronen (E-mail)'" Subject: Re: [Simple] 'Sessions of MESSAGEs' References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 2973 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: Oded Cnaan wrote: > Let's say that user A wishes to send a message to user B, assuming the > session model for messaging. In this case, there are two options: > > 1. Start a session, send the message and close the session > (INVITE..MESSAGE..BYE) > > 2. Start a session, send the message and leave the session open for > consecutive messages. The session will be closed at a later time > (INVITE..MESSAGE..MESSAGE..MESSAGE..BYE) > > The first scenario puts a lot of burden on the server (proxy) and network as > it requires several transactions for only sending a single message. Yes, it does. That is exactly why we are maintaining the use of the MESSAGE method for one-shot messages like you describe. Any draft about message sessions should (and the one I am working one will) deprecate using sessions for single messages to a single endpoint. > > The second scenario, that seems more logical, carries a different kind of > difficulty. In 'All IP' networks, the IP of the handset may be changed by > the network at any time (the user moves to a different base station or even > moves to a different network). When the address of the recipient changes > after a session has already started, consecutive messages will fail. > > Unlike VoIP sessions, messages are not streamed so user A has no way to know > that B's address has changed (assuming B is not in A's friend list). I don't understand what streaming has to do with noticing your target endpoint address has changed, without extra signalling. I assume that a message session would allow noticing an network error just as easily as an RTP session. > > Moving to the more general discussion: > > In the discussions so far, it seems that there is a tendency to treat IM as > any other messaging media (VoIP, calls etc.). I understand the 'esthetics' > of this solution but I believe that it neglects the special behavior (and > use) of IM in oppose to other medias. That is why we are keeping MESSAGE for single, page-model messages. > > IM is used in its core for quick, short text messaging while VoIP, a phone > call or even a Quack game are used to create a stream intended to be used > for a long discussion / game / whatever. > > It seems to me that SIMPLE should support 2 types of messaging: > > 1. Direct MESSAGE (as in the current draft) without initiating a session > > 2. A session based messaging using the second model mentioned above. > (INVITE..MESSAGE..MESSAGE..MESSAGE..BYE) This will be very useful for > initiating chat sessions, in opposed to single messaging. That was the consensus of the wg meeting in London, and the direction we are working on so far. > > > I would be interested in hearing other people's opinions on that. > > Oded Cna'an > VP, New Technologies > Odigo Inc. > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From Vasilis.Polychronidis@Openwave.com Wed Aug 22 05:45:28 2001 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 FAA09246 for ; Wed, 22 Aug 2001 05:45:28 -0400 (EDT) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010822094341.WMEL14168.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Wed, 22 Aug 2001 04:43:41 -0500 Received: from Openwave.com ([4.41.17.79]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.02.00 201-253-122-103-101-20001108) with ESMTP id <20010822094521.TFIZ26952.oe-ismta1.bizmailsrvcs.net@Openwave.com>; Wed, 22 Aug 2001 04:45:21 -0500 Message-ID: <3B837F31.2CB9AFFA@Openwave.com> Date: Wed, 22 Aug 2001 02:45:21 -0700 From: Vasilis Polychronidis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Robert Osborne , Zane Thomas , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: Content-Type: multipart/alternative; boundary="------------F2AAA53094CED50DF0A825EA" Content-Length: 61784 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: --------------F2AAA53094CED50DF0A825EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan, I finally browsed through your ID (draft-rosenberg-sip-entfw-02.txt) and I have the following comments: This ID is solving the NAT issues related to SIP. However IMO we should first specify how a SIP based IM service will work with an IM/conferencing Server and then analyze the NAT associated issues. IMO it is not a good idea to mix these two topics since it will only create additional confusion. The following diagram describes the architecture and protocols that we want to use in order to define IM as a session protocol: Please view in a fixed-width font such as Courier. +---------+ |SIP Proxy| | | / +---------+ \\ // | \\ // | \\ // | \\ SIP for IM signaling | SIP for IM signaling // | \\ / |???? \\ // |How do we \\ // |correlate transport \\ // |Sessions in the \\ // |IM Server? \\ // | \\ / | \ +-----+ +---------+ +-----+ |IM UA| |IM Server| |IM UA| | 1 |<---IM-Transport----->| |<----IM-Trasport-------| 2 | +-----+ +---------+ +-----+ As it was pointed out by Robert Osborne in the above case we need to specify the binding for the IM transport legs. One obvious solution is depicted in the following diagram: Please view in a fixed-width font such as Courier. +---------+ <---IM-Signaling----->|SIP proxy|<---IM-Signaling-----> +-----+ +---------+ +-----+ |IM UA| |IM Server| |IM UA| | 1 |<---IM-Transport----->| |<----IM-Trasport-------| 2 | +-----+ +---------+ +-----+ Where the IM/conferencing Server includes SIP proxy functionality. The binding in this case is obvious and is similar to the one described in draft-ietf-sip-call-flows-05.txt section 3.1.5 The following diagram depicts the message flow for the above case: Please view in a fixed-width font such as Courier. IM UA 1 IM Server Proxy 1 IM UA 2 | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | (100) F3 |--------------->| INVITE F4 | |<---------------| (100) F5 |--------------->| | |<---------------| 180 F6 | | | 180 F7 |<---------------| | 180 F8 |<---------------| | |<---------------| | 200 F9 | | | 200 F10 |<---------------| | 200 F11 |<---------------| | |<---------------| | | | ACK F12 | | | |--------------->| ACK F13 | | | |--------------->| ACK F14 | | | |--------------->| | IM Media | Both Way IM Media | |<==============>|<===============================>| | BYE F15 | | | |--------------->| BYE F16 | | | |--------------->| BYE F17 | | | |--------------->| | | | 200 F18 | | | 200 F19 |<---------------| | 200 F20 |<---------------| | |<---------------| | | | | | | In addition we will need to address the following case scenario: Please view in a fixed-width font such as Courier. +-----+ +----------+ +----------+ +-----+ |IM UA| |IM Server | |IM Server | |IM UA| | 1 |<-------->|Provider X|<--------->|Provider Y|<--------->| 2 | +-----+ +----------+ +----------+ +-----+ How do we set IM media sessions between two different IM providers? IMO it is critical for the protocol to allow for an IM Server (gateway or conferencing server) in case the IM provider chooses to deploy such architecture.. After all most of the commercial systems today include such an IM Server Jonathan my main question is: Does the draft-rosenberg-sip-entfw-02.txt handles all of the above mentioned cases? If the answer is yes please describe in detail your proposed solution for the above mentioned cases. Kind Regards, -Vasilis Polychronidis Jonathan Rosenberg wrote: > Vasilis, > > I made a concrete proposal on a mechanism for TCP transport of IM, using a > TCP version of the reflector protocol documented in > draft-rosenberg-sip-entfw-02.txt. I discussed it in the email yesterday: > > http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html > > you seem to be proposing an alternate mechanism (not entirely sure, though). > Is there any reason you do not support the above approach? As I mentioned in > the email, by using the discovery/negotiation mechanisms in entfw, we get > the benefit of using direct tcp whenever possible (at least one of the users > has a direct connection to the Internet (i.e., not natted)), but we work > through nats even in the hard case where both users are natted. > > -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: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com] > Sent: Tuesday, August 21, 2001 5:38 AM > To: Robert Osborne > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Sessions of MESSAGEs > > Hi Robert, > The following is just a rough proposal but I hope will > answer your questions. > Obviously we need a couple of IDs in order to completely specify the > functionality of the IM session proposal. > Please see my comments below: > Kind Regards, > -Vasilis Polychronidis > Robert Osborne wrote: > Well I do :-) > What is simple or is not as objective as we would like to think. > After all most of the commercial systems today include (as you clearly > explained above) > an IM Server (trusted server) and this is how the overcome the NAT issues. > > [Robert Osborne] Ok, so lets agree to disagree on the simplicity, but agree > that a server is required at the domain's edge. > Well first let me provide some background information that will make this > discussion more precise: > 1. For simplicity lets assume the IM Service providers under discussion > deployed only IM systems that initiate IM sessions via > "normal" SIP operations (Similar way as it is done for VoIP). For other > cases please refer to IMPP and CPIM gatewaying. > 2. Let us assume that we have two such IM service providers: > IM provider X > IM provider Y > 3. For simplicity lets assume that each provider has each one domain that > servers all of its users > IM provider X --> simple.OperatorX.net > IM provider Y --> simple.OperatorY.net > 4. Each user can be addressed by a SIP URL. It is assumed that the operators > have deployed a SIP > proxy infrastructure for establishing VoIP sessions. > Now under these assumptions each operator will have its own IM Server in > order to solve the following issues: > 1. NAT issues > 2. Universal access (mobile, PDA, PC, etc.) > 3. Consistency and synchronization > 4. Authorization/Authentication > 5. "Mobility" of buddy lists > 6. Security > Operators are very reluctant to deploy a peer to peer model for various > reasons that I will not analyze here. > Treating IM as a session does not preclude the use of the peer to peer > model. > So under the above logic and assuming that the operators do not wish to > deploy a peer to peer IM system > I would agree that each operator will have its own IM Server. > Now let me analyze the case where IM User A that is being served by > OperatorX wants to set up an IM > session with IM User B and start the chat. > The following diagram is a rough example that depicts the message flow for > establishment of the IM session. > The SDP documents carried by the appropriate SIP messages can indicate to > B > (or A) client to connect to the IM Server X (or IM Server Y) > A Client can reside behind Openwave's firewall. > B client can reside behind Microsoft's firewall. > There is the issue of the OperatorX to allow incoming TCP connections > from subscribers other than its own (for example like MSN subs). > For additional security OperatorX can deploy a gateway IM Server X' in order > to allow > interoperability with other Operators. > > Please view in a fixed-width font such as Courier. > +-----+ +-------+ +-------+ +-------+ +-----+ > |A | |IM | |SIP | |SIP | |B | > | | |Srv X | |proxy X| |proxy Y| | | > +-----+ +-------+ +-------+ +-------+ +-----+ > | TCP connection | | | | > 1 |<-------------->| | | | > | INVITE | | | > |--------------------------->| INVITE | | > | 100 |--------------->| INVITE | > |<---------------------------| |-------------->| > | |<-----100-------| | > | | | | > | | | | > | | 180 |<-----180------| > | 180 |<---------------| | > |<---------------------------| | | > | | | 200 | > | | 200 |<--------------| > | 200 |<---------------| | > |<---------------------------| | | > | | | | > |----------ACK-------------->| | | > | |------ACK------>| ACK | > | | |-------------->| > | TCP to home IM | Initiate TCP connection with IM Srv X | > |<-------------->|<----------+----------------+---------------| > | | | | | > | TCP to home IM | TCP connection is established | > |<-------------->|<----------+----------------+-------------->| > | | | | | > | | | | | > | | | | | > | BYE | | | > |--------------------------->| BYE | | > | |--------------->| BYE | > | | |-------------->| > | | | | > | | |<----200-------| > | 200 |<------200------| | > |<---------------------------| | | > | | | | > > This is is the most complicated case so for any other case you should be > able to analyze it using the above mentioned analysis. > Now let me answer your questions: > 1) How would client A within domain X ensure that the local server (IM > Server X) is aware that a session with client B in domain Y > has been created? > After the SIP exchange the client A will convey the session information > (Call-ID:, IP address, Port # in SDP, etc.) to its local IM Server > via its TCP connection. > I know this answer is vague but the details should be specified in the > upcoming ID for the IM session. > 2) How would the server know that a particular TCP connection from domain Y > actually maps into a session with client A within the domain? > Well since the IM Server X is aware of the session information (see above > answer) it can map the TCP connections. > 3) How would the server authenticate that the TCP connection is actually > from client B within domain Y? > When the client B connects to the IM Server X uses the information > received via the INVITE message in order to authenticate. > 4) How does the server become aware that client A no longer wishes to > receive traffic for this session (i.e. user has closed IM window)? > The client A sends a BYE to the client B and tears down the TCP > connection. > For another implementation (taken from draft-ietf-sip-call-flows-05.txt) > please see the diagram below: > I wish I knew about it before I wrote the above "rough" scenario :-) > 3.1.5 Successful SIP to SIP through SIP Firewall Proxy > Please view in a fixed-width font such as Courier. > User A IM Server Proxy 1 User B > | | | | > | INVITE F1 | | | > |--------------->| INVITE F2 | | > | (100) F3 |--------------->| INVITE F4 | > |<---------------| (100) F5 |--------------->| > | |<---------------| 180 F6 | > | | 180 F7 |<---------------| > | 180 F8 |<---------------| | > |<---------------| | 200 F9 | > | | 200 F10 |<---------------| > | 200 F11 |<---------------| | > |<---------------| | | > | ACK F12 | | | > |--------------->| ACK F13 | | > | |--------------->| ACK F14 | > | | |--------------->| > | IM Media | Both Way IM Media | > |<==============>|<===============================>| > | BYE F15 | | | > |--------------->| BYE F16 | | > | |--------------->| BYE F17 | > | | |--------------->| > | | | 200 F18 | > | | 200 F19 |<---------------| > | 200 F20 |<---------------| | > |<---------------| | | > | | | | > Where in the above picture I changed Firewall Proxy to IM Server :-) > and RTP Media to IM Media :-) > I think this case scenario provides for more specific answers to your > questions. > I agree with you that we need an Internet draft that will specify all the > details of > how to initialize IM sessions with SIP and carry IM messages over TCP, SCTP > or HTTP. > The above examples indicate that such IM system is relatively easy to > design. > I would be more than happy to help with the production of such ID. > My question is, how would you expect this server to work, particularly in > the following area:1) How would user X within domain X ensure that the > local server is aware that a session with user A in domain A has been > created.2) How would the server know that a particular TCP connection > from domain A actually maps into a session with user X within the domain3) > How would the server authenticate that the TCP connection is actually from > user A within domain A4) How does the server become aware that user X no > longer wishes to receive traffic for this session (ie user has closed IM > window > >IM as a session with a TCP or HTTP transport is the right way moving > >forward. > > > >> > >> > >> Rob O > >> --------------F2AAA53094CED50DF0A825EA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathan,
I finally browsed through your ID (draft-rosenberg-sip-entfw-02.txt) and I have the following comments:
This ID is solving the NAT issues related to SIP.
However IMO we should first specify how a SIP based IM service will work with an IM/conferencing Server
and then analyze the NAT associated issues.
IMO it is not a good idea to mix these two topics since it will only create additional confusion.

The following diagram describes the architecture and protocols that we want to use in order to
define IM as a session protocol:
          Please view in a fixed-width font such as Courier.

                              +---------+
                              |SIP Proxy|
                              |         |
                            / +---------+ \\
                          //       |        \\
                        //         |          \\
                      //           |            \\
        SIP for IM signaling       |            SIP for IM signaling
                  //               |                \\
                 /                 |????              \\
               //                  |How do we           \\
             //                    |correlate transport   \\
           //                      |Sessions in the         \\
         //                        |IM Server?                \\
       //                          |                            \\
      /                            |                              \
 +-----+                      +---------+                       +-----+
 |IM UA|                      |IM Server|                       |IM UA|
 |  1  |<---IM-Transport----->|         |<----IM-Trasport-------|  2  |
 +-----+                      +---------+                       +-----+

As it was pointed out by Robert Osborne in the above case we need to specify
the binding for the IM transport legs.

One obvious solution is depicted in the following diagram:
           Please view in a fixed-width font such as Courier.

                               +---------+
         <---IM-Signaling----->|SIP proxy|<---IM-Signaling----->
  +-----+                      +---------+                       +-----+
  |IM UA|                      |IM Server|                       |IM UA|
  |  1  |<---IM-Transport----->|         |<----IM-Trasport-------|  2  |
  +-----+                      +---------+                       +-----+
Where the IM/conferencing Server includes SIP proxy functionality. The binding in this case is
obvious and is similar to the one described in draft-ietf-sip-call-flows-05.txt section 3.1.5
The following diagram depicts the message flow for the above case:
Please view in a fixed-width font such as Courier.

   IM UA 1          IM Server         Proxy 1          IM UA 2
     |                |                |                |
     |   INVITE F1    |                |                |
     |--------------->|   INVITE F2    |                |
     |    (100) F3    |--------------->|   INVITE F4    |
     |<---------------|    (100) F5    |--------------->|
     |                |<---------------|      180 F6    |
     |                |     180 F7     |<---------------|
     |     180 F8     |<---------------|                |
     |<---------------|                |      200 F9    |
     |                |    200 F10     |<---------------|
     |     200 F11    |<---------------|                |
     |<---------------|                |                |
     |     ACK F12    |                |                |
     |--------------->|     ACK F13    |                |
     |                |--------------->|     ACK F14    |
     |                |                |--------------->|
     |     IM Media   |         Both Way IM Media       |
     |<==============>|<===============================>|
     |     BYE F15    |                |                |
     |--------------->|     BYE F16    |                |
     |                |--------------->|     BYE F17    |
     |                |                |--------------->|
     |                |                |     200 F18    |
     |                |     200 F19    |<---------------|
     |     200 F20    |<---------------|                |
     |<---------------|                |                |
     |                |                |                |
 

In addition we will need to address the following case scenario:
          Please view in a fixed-width font such as Courier.

+-----+          +----------+           +----------+           +-----+
|IM UA|          |IM Server |           |IM Server |           |IM UA|
|  1  |<-------->|Provider X|<--------->|Provider Y|<--------->|  2  |
+-----+          +----------+           +----------+           +-----+
How do we set IM media sessions between two different IM providers?

IMO it is critical for the protocol to allow for an IM Server (gateway or conferencing server) in case the IM provider
chooses to deploy such architecture..
After all most of the commercial systems today include such an IM Server

Jonathan my main question is:
Does the draft-rosenberg-sip-entfw-02.txt handles all of the above mentioned cases?
If the answer is yes please describe in detail your proposed solution for the above mentioned cases.

Kind Regards,

-Vasilis Polychronidis

Jonathan Rosenberg wrote:

Vasilis,

I made a concrete proposal on a mechanism for TCP transport of IM, using a
TCP version of the reflector protocol documented in
draft-rosenberg-sip-entfw-02.txt. I discussed it in the email yesterday:

http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html

you seem to be proposing an alternate mechanism (not entirely sure, though).
Is there any reason you do not support the above approach? As I mentioned in
the email, by using the discovery/negotiation mechanisms in entfw, we get
the benefit of using direct tcp whenever possible (at least one of the users
has a direct connection to the Internet (i.e., not natted)), but we work
through nats even in the hard case where both users are natted.

-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: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com]
Sent: Tuesday, August 21, 2001 5:38 AM
To: Robert Osborne
Cc: Zane Thomas; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Sessions of MESSAGEs

Hi Robert,
The following is just a rough proposal but I hope will
answer your questions.
Obviously we need a couple of IDs in order to completely specify the
functionality of the IM session proposal.
Please see my comments below:
Kind Regards,
-Vasilis Polychronidis
Robert Osborne wrote:
Well I do :-)
What is simple or is not as objective as we would like to think.
After all most of the commercial systems today include (as you clearly
explained above)
an IM Server (trusted server) and this is how the overcome the NAT issues.

[Robert Osborne]  Ok, so lets agree to disagree on the simplicity, but agree
that a server is required at the domain's edge.
Well first let me provide some background information that will make this
discussion more precise:
1. For simplicity lets assume the IM Service providers under discussion
deployed only IM systems that initiate IM sessions via
    "normal" SIP operations (Similar way as it is done for VoIP). For other
cases please refer to IMPP and CPIM gatewaying.
2. Let us assume that we have two such IM service providers:
    IM provider X
    IM provider Y
3. For simplicity lets assume that each provider has each one domain that
servers all of its users
    IM provider X --> simple.OperatorX.net
    IM provider Y --> simple.OperatorY.net
4. Each user can be addressed by a SIP URL. It is assumed that the operators
have deployed a SIP
    proxy infrastructure for establishing VoIP sessions.
Now under these assumptions each operator will have its own IM Server in
order to solve the following issues:
1. NAT issues
2. Universal access (mobile, PDA, PC, etc.)
3. Consistency and synchronization
4. Authorization/Authentication
5. "Mobility" of buddy lists
6. Security
Operators are very reluctant to deploy a peer to peer model for various
reasons that I will not analyze here.
Treating IM as a session does not preclude the use of the peer to peer
model.
So under the above logic and assuming that the operators do not wish to
deploy a peer to peer IM system
I would agree that each operator will have its own IM Server.
Now let me analyze the case where IM User A<x> that is being served by
OperatorX wants to set up an IM
session with IM User B<y> and start the chat.
The following diagram is a rough example that depicts the message flow for
establishment of the IM session.
The SDP documents carried by the appropriate SIP messages can indicate to
B<y>
(or A<x>) client to connect to the IM Server X (or IM Server Y)
A<x> Client can reside behind Openwave's firewall.
B<y> client can reside behind Microsoft's firewall.
There is the issue of the OperatorX to allow incoming TCP connections
from subscribers other than its own (for example like MSN subs).
For additional security OperatorX can deploy a gateway IM Server X' in order
to allow
interoperability with other Operators.

Please view in a fixed-width font such as Courier.
 +-----+        +-------+    +-------+        +-------+        +-----+
 |A<x> |        |IM     |    |SIP    |        |SIP    |        |B<y> |
 |     |        |Srv X  |    |proxy X|        |proxy Y|        |     |
 +-----+        +-------+    +-------+        +-------+        +-----+
    | TCP connection |           |                |               |
  1 |<-------------->|           |                |               |
    |       INVITE               |                |               |
    |--------------------------->|     INVITE     |               |
    |        100                 |--------------->|   INVITE      |
    |<---------------------------|                |-------------->|
    |                            |<-----100-------|               |
    |                            |                |               |
    |                            |                |               |
    |                            |      180       |<-----180------|
    |          180               |<---------------|               |
    |<---------------------------|                |               |
    |                            |                |      200      |
    |                            |      200       |<--------------|
    |          200               |<---------------|               |
    |<---------------------------|                |               |
    |                            |                |               |
    |----------ACK-------------->|                |               |
    |                            |------ACK------>|      ACK      |
    |                            |                |-------------->|
    | TCP to home IM |  Initiate TCP connection with IM Srv X     |
    |<-------------->|<----------+----------------+---------------|
    |                |           |                |               |
    | TCP to home IM |    TCP connection is established           |
    |<-------------->|<----------+----------------+-------------->|
    |                |           |                |               |
    |                |           |                |               |
    |                |           |                |               |
    |        BYE                 |                |               |
    |--------------------------->|       BYE      |               |
    |                            |--------------->|     BYE       |
    |                            |                |-------------->|
    |                            |                |               |
    |                            |                |<----200-------|
    |         200                |<------200------|               |
    |<---------------------------|                |               |
    |                            |                |               |

This is is the most complicated case so for any other case you should be
able to analyze it using the above mentioned analysis.
Now let me answer your questions:
1) How would client A<x> within domain X ensure that the local server (IM
Server X) is aware that a session with client B<y> in domain Y
    has been created?
After the SIP exchange the client A<x> will convey the session information
(Call-ID:, IP address, Port # in SDP, etc.) to its local IM Server
via its TCP connection.
I know this answer is vague but the details should be specified in the
upcoming ID for the IM session.
2) How would the server know that a particular TCP connection from domain Y
actually maps into a session with client A<x> within the domain?
Well since the IM Server X is aware of the session information (see above
answer) it can map the TCP connections.
3) How would the server authenticate that the TCP connection is actually
from client B<y> within domain Y?
When the client B<y> connects to the IM Server X uses the information
received via the INVITE message in order to authenticate.
4) How does the server become aware that client A<x> no longer wishes to
receive traffic for this session (i.e. user has closed IM window)?
The client A<x> sends a BYE to the client B<y> and tears down the TCP
connection.
For another implementation (taken from draft-ietf-sip-call-flows-05.txt)
please see the diagram below:
I wish I knew about it before I wrote the above "rough" scenario :-)
3.1.5 Successful SIP to SIP through SIP Firewall Proxy
Please view in a fixed-width font such as Courier.
   User A          IM Server         Proxy 1          User B
     |                |                |                |
     |   INVITE F1    |                |                |
     |--------------->|   INVITE F2    |                |
     |    (100) F3    |--------------->|   INVITE F4    |
     |<---------------|    (100) F5    |--------------->|
     |                |<---------------|      180 F6    |
     |                |     180 F7     |<---------------|
     |     180 F8     |<---------------|                |
     |<---------------|                |      200 F9    |
     |                |    200 F10     |<---------------|
     |     200 F11    |<---------------|                |
     |<---------------|                |                |
     |     ACK F12    |                |                |
     |--------------->|     ACK F13    |                |
     |                |--------------->|     ACK F14    |
     |                |                |--------------->|
     |     IM Media   |         Both Way IM Media       |
     |<==============>|<===============================>|
     |     BYE F15    |                |                |
     |--------------->|     BYE F16    |                |
     |                |--------------->|     BYE F17    |
     |                |                |--------------->|
     |                |                |     200 F18    |
     |                |     200 F19    |<---------------|
     |     200 F20    |<---------------|                |
     |<---------------|                |                |
     |                |                |                |
Where in the above picture I changed Firewall Proxy to IM Server :-)
and RTP Media to IM Media :-)
I think this case scenario provides for more specific answers to your
questions.
I agree with you that we need an Internet draft that will specify all the
details of
how to initialize IM sessions with SIP and carry IM messages over TCP, SCTP
or HTTP.
The above examples indicate that such IM system is relatively easy to
design.
I would be more than happy to help with the production of such ID.
My question is, how would you expect this server to work, particularly in
the following area:1)    How would user X within domain X ensure that the
local server is aware that a session with user A in domain A has been
created.2)    How would the server know that a particular TCP connection
from domain A actually maps into a session with user X within the domain3)
How would the server authenticate that the TCP connection is actually from
user A within domain A4)    How does the server become aware that user X no
longer wishes to receive traffic for this session (ie user has closed IM
window
>IM as a session with a TCP or HTTP transport is the right way moving
>forward.
>
>>
>>
>> Rob O
>>

--------------F2AAA53094CED50DF0A825EA-- From jdrosen@dynamicsoft.com Mon Aug 27 11:17:00 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01438 for ; Mon, 27 Aug 2001 11:17:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7RFG2rN012247; Mon, 27 Aug 2001 11:16:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 11:16:52 -0400 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Oded Cnaan Cc: "'simple@mailman.dynamicsoft.com'" , "'Gabriel Matsliach (E-mail)'" , "'Avner Ronen (E-mail)'" Subject: RE: [Simple] 'Sessions of MESSAGEs' Date: Mon, 27 Aug 2001 11:16:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 1990 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: > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, August 27, 2001 9:56 AM > To: Oded Cnaan > Cc: 'simple@mailman.dynamicsoft.com'; 'Gabriel Matsliach (E-mail)'; > 'Avner Ronen (E-mail)' > Subject: Re: [Simple] 'Sessions of MESSAGEs' > > > Oded Cnaan wrote: > > The second scenario, that seems more logical, carries a > different kind of > > difficulty. In 'All IP' networks, the IP of the handset may > be changed by > > the network at any time (the user moves to a different base > station or even > > moves to a different network). When the address of the > recipient changes > > after a session has already started, consecutive messages will fail. > > > > Unlike VoIP sessions, messages are not streamed so user A > has no way to know > > that B's address has changed (assuming B is not in A's friend list). > > > I don't understand what streaming has to do with noticing your target > endpoint address has changed, without extra signalling. I > assume that a > message session would allow noticing an network error just as > easily as > an RTP session. Oded, I think you are talking about terminal mobility, right? In that case, the 2.5G and 3G solutions generally use lower layer mobility, which makes all of this transparent. There are solutions for sip layer mobility (see http://search.ietf.org/internet-drafts/draft-itsumo-sipping-mobility-multime dia-00.txt), and to my knowledge these do NOT depend on the timeliness of the media transport. The local end that has moved sends a re-INVITE to its peer to update the media address (and signaling address to). --- 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 From Avshalom@ubique.com Mon Aug 27 13:20:40 2001 Received: from ubqgate02.lotus.com ([194.196.39.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01791 for ; Mon, 27 Aug 2001 13:20:38 -0400 (EDT) From: Avshalom@ubique.com Subject: Re: [Simple] Sessions of MESSAGEs To: simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Mon, 27 Aug 2001 20:19:03 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 27/08/2001 20:19:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 4865 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: How do we know the consensus of the group? avshalom Sametime/Lotus/IBM Vasilis Polychronidis nwave.com> cc: Jonathan Rosenberg , "Peterson, Jon" , Avshalom@ubique.com, 21/08/2001 00:12 simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs Hi Rob, Reading the mailing list is apparent to me that the consensus in the group is not to use the MESSAGE method and consequently SIP as the transport protocol for IM sessions. I hope the above answer your first question. As far as your second question (about presence events) it seems to me that presence events are more closely related to signaling (SIP) however I agree that they may create congestion issues. I think the group should seriously consider the proposal put forward by Michael Hammer. Personally I think assigning different priorities to presence messages is an excellent idea. BR, -Vasilis Polychronidis Robert Osborne wrote: > Hi, > > I still do not understand why we need to force sessions of > MESSAGEs to have to go via a special media channel. Using the current > draft if you wish to avoid congestion or server load, it is possible > for the MESSAGEs to go peer to peer. If there is a firewall in > between the peers, then the traffic can be forced to go through > the signalling path. > > By forcing MESSAGEs to always go via a seperate connection we are > introducing severe constraints that will block deployment of IM > solutions. Why would a company deploy a server to allow for > federated presence, have to deploy another server to get the IM > through the firewall? In reality they shouldnt need to, they should > be able to use the same server. > > In reality the amount of traffic caused by an IM session is > insignificant when compared with that of presence, so why is there > such a major concern? Why not force a NOTIFY to have it's own > connection? > > Rob O > > >-----Original Message----- > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >Sent: Monday, August 20, 2001 10:49 AM > >To: Robert Osborne; Peterson, Jon; Avshalom@ubique.com; > >simple@mailman.dynamicsoft.com > >Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > > > > > > > > >> -----Original Message----- > >> From: Robert Osborne [mailto:roberto@windows.microsoft.com] > >> Sent: Monday, August 20, 2001 1:17 PM > >> To: Peterson, Jon; Avshalom@ubique.com; > >simple@mailman.dynamicsoft.com > >> Subject: RE: [Simple] Sessions of MESSAGEs > >> > >> > >> Actually I was referring to the session of MESSAGEs and not the > >> paging of MESSAGEs. > >> > >> The scenario that always strikes me as being a priority is > >> that a employee > >> of Company A, wishes to communicate with an employee of > >> Company X, who supplies > >> parts to Company A. Irrespective of wether this IM session is > >> paging or not, > >> both employees will want to ensure that it is secure, encrypted and > >> authenticated session that easily traverses firewalls. > > > >I agree with those requirements (and in fact included them in > >my list of > >requirement), but I do not see why the solution has to be > >"send IM over the > >proxy networks". The security story is probably better with the session > >model, using a separate transport, since you can negotiate > >session keys e2e > >for the stream. I agree that the fw/nat traversal is important; I think > >there are sensible ways to deal with it which do not require > >using the SIP > >proxies for message transport. > > > >-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 roberbr@microsoft.com Mon Aug 27 13:32:54 2001 Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01841 for ; Mon, 27 Aug 2001 13:32:53 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Aug 2001 10:31:58 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 10:31:57 -0700 Received: from roberbr420xp ([172.31.77.52]) by red-msg-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 10:31:54 -0700 Message-ID: <003e01c12f1e$2a41e350$344d1fac@redmond.corp.microsoft.com> From: "Robert Brown" To: , References: Subject: Re: [Simple] Sessions of MESSAGEs Date: Mon, 27 Aug 2001 10:31:54 -0700 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 X-OriginalArrivalTime: 27 Aug 2001 17:31:54.0816 (UTC) FILETIME=[2A4AE400:01C12F1E] Content-Length: 6093 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: RE-activating this thread as I believe it is too important to be ignored. Because it needs a firewall traversal box (like entfw-02 or myriad other designs), which most enterprises will not deploy, the current messaging proposal is not suitable for the enterprise and will be undeployed in enterprise networks. I did not say enterprise networks will not deploy SIP-based instant messaging. I would prefer that they deploy an IETF protocol than a proprietary one. ----- Original Message ----- From: To: Sent: Wednesday, August 22, 2001 3:27 AM Subject: RE: [Simple] Sessions of MESSAGEs > > I agree with Robert. > > If we want SIMPLE to be widely deployed and not remain in the PR pages we > must learn from the experience of existing communities. If SIMPLE will not > be optimized, I assume that pure SIMPLE will be implemented only between > communities while the client will remain proprietary in order to be able to > create communities that really work. > > SIP was built for negotiating media (usually heavy) sessions. Trying to > leverage SIP into the awareness/IM area will require some adjustment in SIP > in order to be deployed in very large communities. One very important > requirement in large deployments is limiting the number of TCP connections > that server farm has to handle. Additionally when the protocol is tunneled > over HTTP it is not always possible to create many connections from the > client to the server, as the server and proxies limit the number of > simultaneous connections from a client. > > Consider the case where a user is on several chats. Not enabling MESSAGE on > the control protocol will require creating a different TCP connection for > each chat I am in. I am assuming that the chat is handled by a chat server. > It might be acceptable for small communities but not for big ones. > > avshalom > Sametime/Lotus/IBM > > > > > "Robert Brown" > To: "Jonathan Rosenberg" , "Vasilis > Sent by: Polychronidis" , "Robert Osborne" > simple-admin@mailman.dynam > icsoft.com cc: "Zane Thomas" , > Subject: RE: [Simple] Sessions of MESSAGEs > > 22/08/2001 03:27 > > > > > > OK. I understand your proposal. Yes, I think we were talking past each > other. > > However, I am concerned that such an approach will not be widely > deployed, as it also requires deployment of a firewall/NAT traversal > server (such as draft-rosenberg-sip-entfw-02) adjacent to every > firewall/NAT that exists between two end points. In other words, if the > assumption is that there is a server in the public network, this will > only work for Internet-based services (like MSN and AOL) or for > organizations with liberal-minded firewall administrators (rare by > definition). > > An in-band solution will be far more deployable, as it requires all the > common problems (like routing, authentication, firewall configuration, > etc) to be solved only once. > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, August 21, 2001 12:23 PM > > To: Robert Brown; Jonathan Rosenberg; Vasilis Polychronidis; Robert > > Osborne > > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > > > > > > > > -----Original Message----- > > > From: Robert Brown [mailto:roberbr@microsoft.com] > > > Sent: Tuesday, August 21, 2001 3:13 PM > > > To: Jonathan Rosenberg; Vasilis Polychronidis; Robert Osborne > > > Cc: Zane Thomas; simple@mailman.dynamicsoft.com > > > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > > > > > Huh? > > > > > > I don't see how this is anything like how the web works. Very few > web > > > users have certs for TLS, except for a very few specialized > > > cases where > > > they are used for user auth. > > > > I think we are talking past each other. > > > > In my proposal, there *is* a server in the public network. This server > is > > needed for nat traversal if both are behind a nat. In that case, each > > client > > would have a tls connection to that server, and it is only the server > > which > > needs to have a cert. This is standard web stuff, and thats what I was > > talking about. > > > > In the case of direct communication between clients, yes, this will be > an > > issue for TLS as it would require client certs, which is not that > common. > > This is a problem shared by all e2e encryption/authentication > mechanisms. > > There is work on defining SDP extensions for negotiation of session > keys > > (primarily for SRTP), and some of the key management mechanisms don't > > require certs, but rather, just shared secrets. It would be nice to be > > able > > to use that key management stuff for transport beyond SRTP, such as > > whatever > > we define for IM. > > > > However, if you want secure IM and trust that server in the cloud, you > can > > simply elect not to use direct communications even if possible. The > > signaling mechanisms in entfw and the drafts it depends on (i.e., > comedia) > > support that. > > > > So, you get best of both worlds, from what I can tell.... > > > > -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 Basavaraj.Patil@nokia.com Mon Aug 27 13:45:24 2001 Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01905 for ; Mon, 27 Aug 2001 13:45:23 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7RHjLi17684 for ; Mon, 27 Aug 2001 12:45:21 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Aug 2001 12:45:14 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 12:45:14 -0500 content-class: urn:content-classes:message Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 27 Aug 2001 12:45:14 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E850D@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [Simple] Sessions of MESSAGEs Thread-Index: AcEvHnOLfQLOR5sNEdWpVgBQi2kYTQAAW5oQ From: "Patil Basavaraj (NET/Dallas)" To: "'ext Robert Brown'" , , X-OriginalArrivalTime: 27 Aug 2001 17:45:14.0474 (UTC) FILETIME=[06ED04A0:01C12F20] Content-Length: 685 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA01905 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: > >RE-activating this thread as I believe it is too important to be ignored. >Because it needs a firewall traversal box (like entfw-02 or myriad other >designs), which most enterprises will not deploy, the current messaging >proposal is not suitable for the enterprise and will be undeployed in >enterprise networks. > I agree with Robert's sentiments here. All the "myriad" designs have no value if we do not see a glimmer of a chance at being deployed. >I did not say enterprise networks will not deploy SIP-based instant >messaging. I would prefer that they deploy an IETF protocol than a >proprietary one. Going with an IETF defined solution helps in an interoperable IM ;) From jon.peterson@NeuStar.com Mon Aug 27 19:10:00 2001 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 TAA02773 for ; Mon, 27 Aug 2001 19:09:59 -0400 (EDT) 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 f7RN9xK31756 for ; Mon, 27 Aug 2001 18:09:59 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 18:08:38 -0500 Message-ID: <70565611B164D511957A001083FCDD56478A8A@va02.va.neustar.com> From: "Peterson, Jon" To: "'simple@mailman.dynamicsoft.com'" Date: Mon, 27 Aug 2001 18:09:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 950 Subject: [Simple] Charter revision redux 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: After receiving some feedback, we've changed a few things around in the proposed charter revision below. Significantly, the CPIM mapping deliverable was omitted from the previous version - in London, Patrik requested that the CPIM mapping be extracted out from our presence and instant message drafts into a separate document that exclusively detailed mapping to CPIM - that is now reflected as a November deliverable. We've also pushed back the presence dates to September. Goals and Milestones: Sep 01 Submission of extension for presence to IESG Sep 01 Transfer of MESSAGE definition draft to SIP WG Sep 01 Submission of instant messaging session drafts to IESG Oct 01 Submission of extensions for watcher information to IESG Nov 01 Submission of CPIM mapping draft to IESG Nov 01 Submission of extension for presence publication to IESG Any further comments on these deliverables? Jon Peterson NeuStar, Inc SIMPLE co-chair From bcampbell@dynamicsoft.com Wed Aug 29 14:51:31 2001 Received: from localhost.localdomain ([63.110.3.192]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03373 for ; Wed, 29 Aug 2001 14:51:30 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f7SEvJ701370 for ; Tue, 28 Aug 2001 09:58:39 -0500 Message-ID: <3B8BB14F.7030307@dynamicsoft.com> Date: Tue, 28 Aug 2001 09:57:19 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010622 X-Accept-Language: en-us MIME-Version: 1.0 To: "'simple@mailman.dynamicsoft.com'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 506 Subject: [Simple] IM Session requirement? 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: Here's one that I haven't seen go by. Perhaps it is just so obvious that no one felt the need to discuss it, but here it is just in case. Someone please tell me if we have discussed it and i missed it: Rfc2779 has a requirement for positive confirmation that a message has been delivered. And of course, the CPIM semantics for stand-alone message delivery uses a request-response model. So it seems we have a requirement for delivery confirmations an a per message basis inside a message session. From jdrosen@dynamicsoft.com Thu Aug 30 01:09:13 2001 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 BAA05057 for ; Thu, 30 Aug 2001 01:09:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7U58Mob003221 for ; Thu, 30 Aug 2001 01:08:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 01:09:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Thu, 30 Aug 2001 01:09:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1116 Subject: [Simple] We're back online! 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: Folks, Many of you have probably noticed that the simple list was unavailable for the last day or two. My sincere apologies for this. Turns out, the machine sits on a public network with T1 access from some ISP called OnSite. Well, they went bankrupt and cut service without notifying us. So, we had to move the machine to another net, and change the IP addresses. The DNS changes took some time to get configured, and then we needed to wait for the TTLs to expire. We're now back online. Two major outages in a few weeks is definitely embarassing, but these were for totally unrelated reasons, and now that both are resolved, operation should be good. Please repost any mails that bounced back during the outage. Once again, my apologies. 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 From oran@cisco.com Thu Aug 30 10:35:25 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06724 for ; Thu, 30 Aug 2001 10:35:24 -0400 (EDT) Received: from oranlt ([161.44.238.60]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7TGJ7H15183; Wed, 29 Aug 2001 09:19:07 -0700 (PDT) From: "David R. Oran" To: "'Patil Basavaraj \(NET/Dallas\)'" , "'ext Robert Brown'" , , Subject: RE: [Simple] Sessions of MESSAGEs Date: Wed, 29 Aug 2001 12:25:29 -0400 Organization: Cisco Systems Message-ID: <0c1101c130a7$38b6f2b0$3cee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-reply-to: <697DAA22C5004B4596E033803A7CEF441E850D@daebe007.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2542.0000 Content-Length: 2633 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: > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Patil Basavaraj (NET/Dallas) > Sent: Monday, August 27, 2001 1:45 PM > To: 'ext Robert Brown'; Avshalom@ubique.com; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > >RE-activating this thread as I believe it is too important to be > ignored. > >Because it needs a firewall traversal box (like entfw-02 or myriad > other > >designs), which most enterprises will not deploy, the > current messaging > >proposal is not suitable for the enterprise and will be > undeployed in > >enterprise networks. > > I find the logic behind this conclusion utterly incomprehensible. First of all, for "enterprise IM" the firewall/NAT issue doesn't even arise because the communication stays within the enterprise. If there are multiple sites interconnected, they tend to use VPN technology for precisely the reasons of not wanting to deal with the NAT/FW bull.... for their own internal communication. Therefore, it seems completely wrongheaded to burden the IM protocols with IM-specific mechanisms for firewall/NAT traversal when this is know to hurt robustness, limit scalability, and introduce gratuitous complexity. Second, IM is one of a class of "peer-to-peer" applications which all need essentially the same external rendezvous point to deal with the symmetric double-NAT problem. Solving this on a per protocol basis leads to the same horrendous rat hole we're already seeing with every protocol needing its own ALG on the firewall/NAT. Everybody think THEIR protocol is the most important, has the most urgent requirements, is clearly "special", and has the tremendous revenue/commercial impact that it clearly needs custom mechanisms. > > I agree with Robert's sentiments here. All the "myriad" designs > have no value if we do not see a glimmer of a chance at being > deployed. > Lack of deployment of a standard IM protocol has much more to do with clashing proprietary solutions than with inadequacy of the IETF proposals. > >I did not say enterprise networks will not deploy SIP-based instant > >messaging. I would prefer that they deploy an IETF protocol than a > >proprietary one. > Sure, but what does this have to do with the purely technical discussion of how to achieve FW/NAT traversal? > Going with an IETF defined solution helps in an interoperable > IM ;) _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinf> o/simple > From oran@cisco.com Thu Aug 30 10:45:34 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06782 for ; Thu, 30 Aug 2001 10:45:34 -0400 (EDT) Received: from oranlt ([161.44.238.60]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7TJhAH15424; Wed, 29 Aug 2001 12:43:10 -0700 (PDT) From: "David R. Oran" To: "'Robert Brown'" , "'Patil Basavaraj \(NET/Dallas\)'" , , Subject: RE: [Simple] Sessions of MESSAGEs Date: Wed, 29 Aug 2001 15:49:28 -0400 Organization: Cisco Systems Message-ID: <0c5201c130c3$b8203900$3cee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-reply-to: <8DC4B82A94A29D4AB708F05E0EB557AB0320D1FC@red-msg-05.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2542.0000 Content-Length: 1154 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: We simply have a different definition of "enterprise IM". Of course the general case has to accommodate cross-boundary operation. > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Wednesday, August 29, 2001 2:59 PM > To: David R. Oran; Patil Basavaraj (NET/Dallas); > Avshalom@ubique.com; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > > I find the logic behind this conclusion utterly incomprehensible. > First > > of all, for "enterprise IM" the firewall/NAT issue doesn't > even arise > > because the communication stays within the enterprise. If there are > > multiple sites interconnected, they tend to use VPN technology for > > precisely the reasons of not wanting to deal with the > NAT/FW bull.... > > for their own internal communication. > > I find the fictional world described in this paragraph to be > utterly incomprehensible. > > Have you ever used email? Have you heard of B2B e-commerce? > You and I work in enterprises, and I don't believe a VPN > exists between you and I, but many firewalls do, and you can > still read this mail... > > From gryphon@startcorp.com Thu Aug 30 10:50:28 2001 Received: from i01sv4161.i01rd0002.ids1.intelonline.com (i01sv4161-p.ids1.intelonline.com [147.208.166.27]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06817 for ; Thu, 30 Aug 2001 10:50:27 -0400 (EDT) Received: from i01sv4081 (unverified [10.81.26.30]) by i01sv4161.i01rd0002.ids1.intelonline.com (Rockliffe SMTPRA 4.5.4) with SMTP id for ; Wed, 29 Aug 2001 14:39:26 +0000 Message-ID: From: Stephen Gryphon To: "simple@mailman.dynamicsoft.com" X-Originating-IP: [61.9.177.55] Date: Thu, 30 Aug 2001 0:39:04 +1000 X-MSMail-Priority: Normal X-mailer: AspMail 4.0 4.02 (SMT4DD4B4F) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Length: 319 Subject: [Simple] (no subject) 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: -- Stephen Gryphon | Senior Technology Officer Start Corporation Pty Ltd | ACN 083 289 061 Tel +61, 2, 99544411 | Mob +61, 4, 14542562 Fax +61, 2, 99544422 | http://startcorp.com __________________________________________________________________ Get your free Australian email account at http://www.start.com.au From c-Dai.Ngo@WCOM.Com Thu Aug 30 11:00:52 2001 Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06887 for ; Thu, 30 Aug 2001 11:00:47 -0400 (EDT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GIV00DHMZ16T2@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Thu, 30 Aug 2001 15:00:43 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GIV00B01YZ6EB@pmismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 30 Aug 2001 15:00:38 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GIV00A6ZYYQPG@pmismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 30 Aug 2001 14:59:15 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 14:59:14 +0000 Content-return: allowed Date: Thu, 30 Aug 2001 14:58:47 +0000 From: "Ngo, Dai (c)" To: "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E6C4DE0@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_K0GERQGx8tG5mz6oAJ2OUw)" Content-Length: 2396 Subject: [Simple] Question on the List of Supported Presence Data Format and MIME T ypes 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: 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_K0GERQGx8tG5mz6oAJ2OUw) Content-type: text/plain; charset=iso-8859-1 Hi All, In section "5.4 NOTIFY Bodies" of the "draft-ietf-simple-presence-01.txt" it states, "The body of the notification contains a presence document. This document describes the user presence of the presentity that was subscribed to. All subscribers MUST support the presence data format described in [fill in with IMPP document TBD], and MUST list its MIME type, [fill in with MIME type] in an Accept header present in the SUBSCRIBE request." Does anyone have any information about the list of the presence data formats and the MIME types that will be supported by SIMPLE? Thanks. -- Dai Ngo --Boundary_(ID_K0GERQGx8tG5mz6oAJ2OUw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Question on the List of Supported Presence Data Format and MIME = Types

Hi All,

In section "5.4 NOTIFY Bodies" of the = "draft-ietf-simple-presence-01.txt" it states,

   "The body of the notification = contains a presence document. This
   document describes the user presence of = the presentity that was
   subscribed to. All subscribers MUST = support the presence data format
   described in [fill in with IMPP = document TBD], and MUST list its MIME
   type, [fill in with MIME type] in an = Accept header present in the
   SUBSCRIBE request."

Does anyone have any information about the list of = the presence data formats and the MIME types that will be supported by = SIMPLE?


Thanks.

-- Dai Ngo

--Boundary_(ID_K0GERQGx8tG5mz6oAJ2OUw)-- From c-Dai.Ngo@WCOM.Com Thu Aug 30 11:02:47 2001 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 LAA06913 for ; Thu, 30 Aug 2001 11:02:46 -0400 (EDT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0GIV00H5TZ35OH@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Thu, 30 Aug 2001 15:01:53 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GIV00B01YZ6EA@pmismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 30 Aug 2001 15:01:51 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GIV00A83YZ1RR@pmismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Thu, 30 Aug 2001 14:59:27 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 14:59:24 +0000 Content-return: allowed Date: Thu, 30 Aug 2001 14:59:20 +0000 From: "Ngo, Dai (c)" To: "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E6C4DE1@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_PlvmvglZyymgjkmZqJ3dbQ)" Content-Length: 2931 Subject: [Simple] INVITE or BYE Clarification 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: 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_PlvmvglZyymgjkmZqJ3dbQ) Content-type: text/plain; charset=iso-8859-1 Hi All, In section 3, "Overview of Operation" of the draft-ietf-simple-presence-01.txt it states, "The SUBSCRIBE message effectively establishes a session with the presence agent. As a result, the SUBSCRIBE can be record-routed, and rules for tag handling and Contact processing mirror those for INVITE. " However, in section 5, "Node Behavior" of draft-ietf-sip-events-00.txt it states, "Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow the same protocol rules governing the usage of tags, Route, Record-Route, Via handling, retransmission, reliability, CSeq handling, Contact handling, provisional responses, and message formatting as those defined in RFC 2543 [1] for BYE." Please note the difference of INVITE in the first draft versus BYE in the second draft. Which one is correct? Please clarify. Thanks. -- Dai Ngo --Boundary_(ID_PlvmvglZyymgjkmZqJ3dbQ) Content-type: text/html; charset=iso-8859-1 INVITE or BYE Clarification

Hi All,

In section 3, "Overview of Operation" of the draft-ietf-simple-presence-01.txt it states,
"The SUBSCRIBE message effectively establishes a session with the
   presence agent. As a result, the SUBSCRIBE can be record-routed, and
   rules for tag handling and Contact processing mirror those for
   INVITE. "

However, in section 5, "Node Behavior" of draft-ietf-sip-events-00.txt it states,
"Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow the
     same protocol rules governing the usage of tags, Route,
     Record-Route, Via handling, retransmission, reliability, CSeq
     handling, Contact handling, provisional responses, and message
     formatting as those defined in RFC 2543 [1] for BYE."

Please note the difference of INVITE in the first draft versus BYE in the second draft.

Which one is correct? Please clarify.
Thanks.

-- Dai Ngo

--Boundary_(ID_PlvmvglZyymgjkmZqJ3dbQ)-- From roberbr@microsoft.com Thu Aug 30 11:05:45 2001 Received: from inet-vrs-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA06948 for ; Thu, 30 Aug 2001 11:05:45 -0400 (EDT) Received: from 157.54.1.52 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Aug 2001 11:59:01 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 11:59:00 -0700 content-class: urn:content-classes:message Subject: RE: [Simple] Sessions of MESSAGEs MIME-Version: 1.0 Date: Wed, 29 Aug 2001 11:59:00 -0700 Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0066_01C13081.FD69AC40" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320D1FC@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs Thread-Index: AcEwpurVBQn6O64UQ12ljtbedO629gAFTeOA From: "Robert Brown" To: "David R. Oran" , "Patil Basavaraj (NET/Dallas)" , , X-OriginalArrivalTime: 29 Aug 2001 18:59:00.0884 (UTC) FILETIME=[AA191540:01C130BC] Content-Length: 16972 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: This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C13081.FD69AC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > I find the logic behind this conclusion utterly incomprehensible. First > of all, for "enterprise IM" the firewall/NAT issue doesn't even arise > because the communication stays within the enterprise. If there are > multiple sites interconnected, they tend to use VPN technology for > precisely the reasons of not wanting to deal with the NAT/FW bull.... > for their own internal communication. I find the fictional world described in this paragraph to be utterly incomprehensible. Have you ever used email? Have you heard of B2B e-commerce? You and I work in enterprises, and I don't believe a VPN exists between you and I, but many firewalls do, and you can still read this mail... ------=_NextPart_000_0066_01C13081.FD69AC40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIqDDCCB2ww ggZUoAMCAQICCYpKzgAEAAAa6DANBgkqhkiG9w0BAQUFADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJ VEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1v bmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQg UGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcwOTE3MjUzMVoXDTAyMDEwOTE3MzUzMVowUTES MBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lw aWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtjTd65Df 8iVrq5iSbSg30njDljwoXqEMCBpqB4JdWZ5k+9IF3ordwToVAGxs5mXM9jFcWY8cfbnP6oGtPXcQ f+YzDMwQqQARaxDQ9QFLax8Rw16r5pg3tCK0ZQpOw/M7iegz6I1frUG9VXQGrrnZNYnHmBFNS7Ru lYSKKGoGedMCAwEAAaOCBH4wggR6MB0GA1UdDgQWBBTsnqGiMVuxHoTJ7iR5ApXP/KrDITAfBgNV HSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNVHREEGTAXgRVyb2JlcmJyQG1pY3Jvc29m dC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIw UGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJFRElUR0NBQjA1LENOPUNEUCxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAs REM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0 Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSggfGGge5sZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUyMEUtTWFpbCUyMENBJTIwMSxDTj1SRURJ VEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDmgN6A1hjNo dHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvbXNwZWNhMS5jcmwwggGDBggr BgEFBQcBAQSCAXUwggFxMIHQBggrBgEFBQcwAoaBw2xkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVy c29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNv bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB mwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUucmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5j b20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25kLmNvcnAubWljcm9zb2Z0LmNvbV9NaWNy b3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUyMDEoNCkuY3J0MAwGA1UdEwEB/wQCMAAw CwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAnBgkrBgEEAYI3FAIE Gh4YAEUAeABjAGgAYQBuAGcAZQBVAHMAZQByMA0GCSqGSIb3DQEBBQUAA4IBAQCB0k+uJDbp1E68 bsO+sLj9ByQF3esISCGiP9n7eO6WA/V5sLna4+7wGhOSK+ELvI+muBia4Ib1WrwsXcjE1edy3FGE UTmmOYQhMOeyLwapIHIOEGkDHgWEhEIsrtbUIApMqsl/RmYJoCVI8LFP8cTECqqlkfLOxVW195tT T3fikwuF8xr7Z+NgxzjmbYBWJkabiaoS+H7Kwaodb6HCPJ3TcHVZbbzZPK2nF22Yuj6eOueGwK5U lC/gK5l2kvbMRT9uwS24xt9JoyTJNqSZArCXKB/M3gS4x0oiYtBAI+yzAYRftqXBQGXVtULOaMmx 0lPUeToT57JkGC/vfxj6/WXBMIIHvDCCBqSgAwIBAgIKEDC/8QAEAAAcNzANBgkqhkiG9w0BAQUF ADCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMB4XDTAxMDcxMjE4 MjE0MFoXDTAyMDExMjE4MzE0MFowUTESMBAGA1UEChMJbWljcm9zb2Z0MRUwEwYDVQQLEwxub3J0 aGFtZXJpY2ExEzARBgNVBAMTCnJlY2lwaWVudHMxDzANBgNVBAMTBjI2MjMzNDCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEAy3lm9JALv4LDed1mg36iAOZHpioL2XED76qNShMdiMcC8i3W+Q03 3J+hxN6yfyoENRVl1tLIWQWVgrQZBtVDnD9LdZMSbER/fKez4FhYcjXdS9YSuAjL7iWAy6H4RGFe /xkNzk+o01J6SxXXbSBIsvF65SHKW8TKNlFmYRjYQD0CAwEAAaOCBM0wggTJMB0GA1UdDgQWBBRK yxFbaT9TWPH1DkqLLMGS8C7kCzAfBgNVHSMEGDAWgBQnpxTgUi4DFY3GrJJDZPCdNvyDjjAgBgNV HREEGTAXgRVyb2JlcmJyQG1pY3Jvc29mdC5jb20wggIqBgNVHR8EggIhMIICHTCB5aCB4qCB34aB 3GxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPVJF RElUR0NBQjA1LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jZXJ0aWZpY2F0ZVJl dm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfeggfSg gfGGge5sZGFwOi8vY29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMFBlcnNvbm5lbCUy MEUtTWFpbCUyMENBJTIwMSxDTj1SRURJVEdDQUIwNSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDmgN6A1hjNodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNwZWNhMS5jcmwwggHABggrBgEFBQcBAQSCAbIwggGuMIHQBggrBgEFBQcwAoaBw2xk YXA6Ly8vQ049TWljcm9zb2Z0JTIwUGVyc29ubmVsJTIwRS1NYWlsJTIwQ0ElMjAxLENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PWNvcnAsREM9bWljcm9zb2Z0LERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBmwYIKwYBBQUHMAKGgY5odHRwOi8vcmVkaXRnY2FiMDUu cmVkbW9uZC5jb3JwLm1pY3Jvc29mdC5jb20vQ2VydEVucm9sbC9SRURJVEdDQUIwNS5yZWRtb25k LmNvcnAubWljcm9zb2Z0LmNvbV9NaWNyb3NvZnQlMjBQZXJzb25uZWwlMjBFLU1haWwlMjBDQSUy MDEoNCkuY3J0MDsGCCsGAQUFBzAChi9odHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9tc3BlY2ExLmNydDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwOQYJKwYBBAGCNxQCBCweKgBFAHgAYwBoAGEAbgBnAGUAVQBzAGUAcgBT AGkAZwBuAGEAdAB1AHIAZTANBgkqhkiG9w0BAQUFAAOCAQEAMv7T9pvrp6UXB7O9RFnTSsBuvTBo V97TVmsMf5v4Jex00ggBPBAEDxY+uwryYrQaXCNQk2aIyty7G3/i9M7bK9oynIVzDhjQb48y68t7 MwD2wGC5BhUBuAFs4rIqHIDFoTRPceCLXYDmsx/9P3rzMACc4NO2jshuiwITMHDjrvO1UFvo+Y7y wVrId5WSMbIhvm5xTXvQGbrvDujSKpAkIMLESfXN+2VhWbbH07p1ysQKEv/aUFKHf5zsdDwqCw5+ hOrbCVplYWbbwVLkXicSFWybh11sDt87tM+RM/1ctf8dP6dLibR6PkAEK54+nUVx2MZRxoMgy/Py XsEjvi7M7jCCCFAwggc4oAMCAQICECqYqHcDdOezQZXr4E2bF/YwDQYJKoZIhvcNAQEFBQAwgZ4x ITAfBgkqhkiG9w0BCQEWEnBraXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AldBMRAwDgYDVQQHEwdSZWRtb25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEr MCkGA1UEAxMiTWljcm9zb2Z0IENvcnBvcmF0ZSBSb290IEF1dGhvcml0eTAeFw0wMDAyMjUwMTM0 MzlaFw0wODAyMjUwMTQxNTJaMIGeMSEwHwYJKoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20x CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWlj cm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNVBAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBB dXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC271QaJR4cS4M/pGAtU7D1 BUUuMAdaiSwV6lV1OnZ9mLjutGhOXmbiIcestCD1d9hpTOOl6e2TuRo65o4UWEUTAASMUtmLPj9V PVsIP4kx32lW6BhLI6DiAFvL/BrkjOSAibamfUXp/AbCwbX7RQLSf4jZwiQtAYlrPwBr24pMI/WM nJxXlMx/KUsYt627dWkJFkXKVOopS0MdIuYXfz0K6WuSmrLsAbbbuC/kIPBF/SAYJsIs/BGyRmuw yUiWoHDJgi83ZTXSQ1rzSgYhZO9xPL9ZjdI4jeQXIDoCTlIzZyUVbulHzBn58jWbnrSIi2OP7wI/ rxxuBwqjimQlPGZjAgMBAAGjggSGMIIEgjALBgNVHQ8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQUOYnU1B9o8UWwxpwWxCw6fJ0T50AwggIjBgNVHR8EggIaMIICFjCB5qCB46CB4IaB 3WxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIwUm9vdCUyMEF1dGhvcml0eSxDTj1S RURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMs Q049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIH4oIH1 oIHyhoHvbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUl MjBSb290JTIwQXV0aG9yaXR5LENOPVJFRElUR0NBQTAxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9z b2Z0LERDPUNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JM RGlzdHJpYnV0aW9uUG9pbnQwMKAuoCyGKmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9tc2NvcnAv bXNjcmExLmNybDAQBgkrBgEEAYI3FQEEAwIBADCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsG AQUFBzAChoHEbGRhcDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9y aXR5LENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m aWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8v Y29ycC5taWNyb3NvZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRo b3JpdHksQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNv bmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8v d3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IB AQBKfYPOd/2gS3ac9J2sylBGHBlas8dYp6nk+zq3Ml1Pm4L7UkUHTeJW82aPadYbjeWsiHwJgb3A W+YB2iLlKEvvLExH0MOaitwxX5rKDW4G607Yx8KhjE0fK0q3mRd8Xf5zymaxSpKBFSTvh1YI3+WT AiVMSasIr7DuGU0MR4j0DqBE1lHKi60FqCW4kY18oU+jGRQ557DWNi6273zBjY+HH7pB54n8CCFq RNSiStQdu8jlzUCO3eDrEVz9fxRq8T5qrQFod8viyFWLZUZYzWQHibYvKf+aGMGFlRYW2ZP304zI gWcvThTryPsupiHOXGzJZVcybRojwaWdkEkgk7K0MIIIZjCCB06gAwIBAgIKYSDXogAAAAAACjAN BgkqhkiG9w0BAQUFADCBnjEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYD VQQGEwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29m dDEMMAoGA1UECxMDSVRHMSswKQYDVQQDEyJNaWNyb3NvZnQgQ29ycG9yYXRlIFJvb3QgQXV0aG9y aXR5MB4XDTAxMDYxODE5NDg0MFoXDTA1MDYxODE5NTg0MFowgZExITAfBgkqhkiG9w0BCQEWEnBr aXRAbWljcm9zb2Z0LmNvbTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdSZWRt b25kMRIwEAYDVQQKEwlNaWNyb3NvZnQxDDAKBgNVBAsTA0lURzEeMBwGA1UEAxMVTWljcm9zb2Z0 IEV4dHJhbmV0IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw3ayeYZALL1YGLjj t7gEAWw1o2LudM5WWMFCaQtx3gdr4HrZG5064i+ls4UKHjoq8RIz4lnNt/y2qpqpbdT2y8HXICqq SALswJM93//mjtitRwKKKxSd11W1dtKzfbX699za1gP8PUz603wUx+Ojdtwb9HrZcprXAVVt7l+s B+slMjw2el0zqjhUguXbaTbdadMso291Vv3AS3pe+zahIj4RUe8FSu0Rvu5dT91JzDEdPhzC192O PbsQYerq3JDGTBo2dhzkCxolFLjicRmEh48t1PJTR7Tg/QSR/uegAirS/TAg0PJk6Fu7hWepBHzL 80wErx0lqpICzfkUMX2FjwIDAQABo4IErzCCBKswEAYJKwYBBAGCNxUBBAMCAQIwHQYDVR0OBBYE FJl9crx76x52nNzEuwP1X0U2aZX0MAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8EBTADAQH/MB8GA1Ud IwQYMBaAFDmJ1NQfaPFFsMacFsQsOnydE+dAMIICKwYDVR0fBIICIjCCAh4wgeaggeOggeCGgd1s ZGFwOi8vL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049UkVE SVRHQ0FBMDEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENO PUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RjbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCB+KCB9aCB 8oaB72xkYXA6Ly9jb3JwLm1pY3Jvc29mdC5jb20vQ049TWljcm9zb2Z0JTIwQ29ycG9yYXRlJTIw Um9vdCUyMEF1dGhvcml0eSxDTj1SRURJVEdDQUEwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29m dCxEQz1Db20/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERp c3RyaWJ1dGlvblBvaW50MDigNqA0hjJodHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29y cC9jcmwvbXNjcmExLmNybDCCAggGCCsGAQUFBwEBBIIB+jCCAfYwgdEGCCsGAQUFBzAChoHEbGRh cDovLy9DTj1NaWNyb3NvZnQlMjBDb3Jwb3JhdGUlMjBSb290JTIwQXV0aG9yaXR5LENOPUFJQSxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERD PUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB4wYIKwYBBQUHMAKGgdZsZGFwOi8vY29ycC5taWNyb3Nv ZnQuY29tL0NOPU1pY3Jvc29mdCUyMENvcnBvcmF0ZSUyMFJvb3QlMjBBdXRob3JpdHksQ049QUlB LENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24s REM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RjbGFz cz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5odHRwOi8vd3d3Lm1pY3Jvc29m dC5jb20vcGtpL21zY29ycC9tc2NyYTEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBi7uqxBueATj3M DPlmswvqlWKeuEtaKkI8RKBbFHMAeUIJ+AGoszsUIFsJ3k98kIB29ozHXl7sZoy0zbMMKhOdcyDS 32PvaRwZsFDMF3Kn/uSZjfCrRzB2O/x14j9Oo+fU17IfEBWi7r0Z4wzg/ms0AiVIhbC0a3TBF+uS +e+87SOjXi4FYs9xQPsK5xO0AXVNyyRRzF28eKrdhjCcluby2Vt/OSVutyJE2Nj5ZsrxJjKmLwFy uYojzq6CPdc/BpqOcuyYx6PxKNAR66IM74kIUGkIGdbtyHUxgKfu8c5cQ7UkjtKx1LOLaBQNd0z0 uqvBNce9nkNYFgGECVITNDmvMIIKGjCCCQKgAwIBAgIKYTjfmwACAAAAGjANBgkqhkiG9w0BAQUF ADCBkTEhMB8GCSqGSIb3DQEJARYScGtpdEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UECxMD SVRHMR4wHAYDVQQDExVNaWNyb3NvZnQgRXh0cmFuZXQgQ0EwHhcNMDEwNzI3MTc0MDQ1WhcNMDMw NzI3MTc1MDQ1WjCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQG EwJVUzELMAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEM MAoGA1UECxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxqxYOZd4wOX59OpErK12dai5zHESruOslnVp AWtviLjQJbVRHK5JyZtR4bASg+KWKkcoMXbsqANh1f3laCzfyOcVSb5ks4bMC9CTJZx2L4x4YcWO sJUbJ+xo7QmkxxRde2OBz8xRFSIbqBofj1KwG1LAshnY1qzmW89XHsGfVTkJYlAyH3SUOvV5QMM1 utbONj9A4ibYYeHG+M2qu62dkScRyUZ/yMRPBbivaxINPMnPv0Ni85cgFGfUMvA4yuDuvFaCp0Vp C5Y5WbwK66yZJP3gdPOsmSdHHALlFX02o9MESdpBIrSkz74jpSX0QfmbFx3tHEg1wOurhYd0Ivec vQIDAQABo4IGZjCCBmIwEAYJKwYBBAGCNxUBBAMCAQYwHQYDVR0OBBYEFCenFOBSLgMVjcaskkNk 8J02/IOOMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBxjAPBgNVHRMBAf8E BTADAQH/MIHUBgNVHSMEgcwwgcmAFJl9crx76x52nNzEuwP1X0U2aZX0oYGkpIGhMIGeMSEwHwYJ KoZIhvcNAQkBFhJwa2l0QG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQ MA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKzApBgNV BAMTIk1pY3Jvc29mdCBDb3Jwb3JhdGUgUm9vdCBBdXRob3JpdHmCCmEg16IAAAAAAAowggJ9BgNV HR8EggJ0MIICcDCCAmygggJooIICZIaBzmxkYXA6Ly8vQ049TWljcm9zb2Z0JTIwRXh0cmFuZXQl MjBDQSxDTj1SRURJVEdDQUEwMyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1Db3JwLERDPU1pY3Jvc29mdCxEQz1Db20/Y2Vy dGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50hoHgbGRhcDovL2NvcnAubWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLENOPVJFRElUR0NBQTAzLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1T ZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAsREM9TWljcm9zb2Z0LERDPUNvbT9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Y2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnSGMmh0dHA6Ly9jcmwubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL2NybC9tc2VjYTEuY3Jshjto dHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLmNy bIY9ZmlsZTovL1xccmVkaXRnY2FhMDNcQ2VydEVucm9sbFxNaWNyb3NvZnQlMjBFeHRyYW5ldCUy MENBLmNybDCCApwGCCsGAQUFBwEBBIICjjCCAoowgdQGCCsGAQUFBzAChoHHbGRhcDovL2NvcnAu bWljcm9zb2Z0LmNvbS9DTj1NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBLENOPUFJQSxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPUNvcnAs REM9TWljcm9zb2Z0LERDPUNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vL0NOPU1pY3Jvc29mdCUyMEV4 dHJhbmV0JTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9Q29ycCxEQz1NaWNyb3NvZnQsREM9Q29tP2NBQ2VydGlmaWNh dGU/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDoGCCsGAQUFBzAChi5o dHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9tc2VjYTEuY3J0MFYGCCsGAQUFBzAC hkpodHRwOi8vcmVkaXRnY2FhMDMvQ2VydEVucm9sbC9yZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBF eHRyYW5ldCUyMENBKDIpLmNydDBYBggrBgEFBQcwAoZMZmlsZTovL1xccmVkaXRnY2FhMDNcQ2Vy dEVucm9sbFxyZWRpdGdjYWEwM19NaWNyb3NvZnQlMjBFeHRyYW5ldCUyMENBKDIpLmNydDANBgkq hkiG9w0BAQUFAAOCAQEAPxiA/UabVI27oO7Ub0XffwiBJUPrYCH444I7YLvqfL/cQTMZNUd8g8zc DMntbJRN5fkVFZXma5T8UVXGEFVtrysc5PB63HPbyzBWnGT3U+dHWhkFbUxcuFtCe+s/1Gw2p8rN dUVfhX2IZ4qcS1e7Iydt7OvkIyWlRC/8unOPSVlJGdw1N7wIObuZahO1UIvlNUJjpGoXZ5Q1vW6v D6/QpVx2u/RjlrzfdBapGRC4e8erzwiwrHeQtVUW25QkYyzZvOEc5DHS27YA4OyBkY8cdohq14co O/RNlMpg5orc5DJMLGNNiixwxLnJejf9ldfpGdfXQncaPXgiFtoXvUapuDGCA5cwggOTAgEBMIGq MIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jvc29mdC5jb20xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UEChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJ VEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25uZWwgRS1NYWlsIENBIDECChAwv/EABAAAHDcw CQYFKw4DAhoFAKCCAkIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDEwODI5MTg1OTAwWjAjBgkqhkiG9w0BCQQxFgQUQgA3oMR7WFdPLd2xVnV1z5fpq+wwZwYJKoZI hvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgboGCSsGAQQBgjcQBDGB rDCBqTCBmzEhMB8GCSqGSIb3DQEJARYSUEtJVEBtaWNyb3NvZnQuY29tMQswCQYDVQQGEwJVUzEL MAkGA1UECBMCV0ExEDAOBgNVBAcTB1JlZG1vbmQxEjAQBgNVBAoTCU1pY3Jvc29mdDEMMAoGA1UE CxMDSVRHMSgwJgYDVQQDEx9NaWNyb3NvZnQgUGVyc29ubmVsIEUtTWFpbCBDQSAxAgmKSs4ABAAA GugwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGbMSEwHwYJKoZIhvcNAQkBFhJQS0lUQG1pY3Jvc29m dC5jb20xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJXQTEQMA4GA1UEBxMHUmVkbW9uZDESMBAGA1UE ChMJTWljcm9zb2Z0MQwwCgYDVQQLEwNJVEcxKDAmBgNVBAMTH01pY3Jvc29mdCBQZXJzb25uZWwg RS1NYWlsIENBIDECCYpKzgAEAAAa6DANBgkqhkiG9w0BAQEFAASBgBwKCCCroSE4XGTDICB8mxxu ErRl8kBo58JPI/B6Ng5tDXSzOBg+SlHYuu+KYt4gPfASbCw1ZeXvEAKOgkKj0D+hctzc/WyQ7P9z 61cw/U9cc6nViK80HvZZjSMWvAW9o7aI1lUAnjWxmVaTtJwMxtYf6yFZVifE7FvlmmU91Tt0AAAA AAAA ------=_NextPart_000_0066_01C13081.FD69AC40-- From jdrosen@dynamicsoft.com Thu Aug 30 11:08:25 2001 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 LAA06994 for ; Thu, 30 Aug 2001 11:08:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7UF7Wob006040; Thu, 30 Aug 2001 11:07:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 11:08:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Question on the List of Supported Presence Data Form at and MIME T ypes Date: Thu, 30 Aug 2001 11:08:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1674 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: -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Thursday, August 30, 2001 10:59 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] Question on the List of Supported Presence Data Format and MIME T ypes >Hi All, >In section "5.4 NOTIFY Bodies" of the "draft-ietf-simple-presence-01.txt" it states, > "The body of the notification contains a presence document. This > document describes the user presence of the presentity that was > subscribed to. All subscribers MUST support the presence data format > described in [fill in with IMPP document TBD], and MUST list its MIME > type, [fill in with MIME type] in an Accept header present in the > SUBSCRIBE request." >Does anyone have any information about the list of the presence data formats and the MIME >types that will be supported by SIMPLE? Funny you should ask. I am in the process right now of updating this spec, and will submit it hopefully today. One of the things in the update is the filling in of the TBD sections. At IETF 51, impp decided that: http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-00.txt would be the basis of work moving forward on the presence data format. So, I have referenced this document and its associated MIME type, application/cpim-pidf+xml. -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 From jdrosen@dynamicsoft.com Thu Aug 30 11:13:01 2001 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 LAA07039 for ; Thu, 30 Aug 2001 11:13:01 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7UFBhob006136; Thu, 30 Aug 2001 11:11:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 11:12:35 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , "'simple@mailman.dynamicsoft.com'" Cc: "Adam Roach (E-mail)" , "'sip@ietf.org'" Subject: RE: [Simple] INVITE or BYE Clarification Date: Thu, 30 Aug 2001 11:12:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1610 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: -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Thursday, August 30, 2001 10:59 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] INVITE or BYE Clarification >Hi All, >In section 3, "Overview of Operation" of the draft-ietf-simple-presence-01.txt it states, >"The SUBSCRIBE message effectively establishes a session with the > presence agent. As a result, the SUBSCRIBE can be record-routed, and > rules for tag handling and Contact processing mirror those for > INVITE. " >However, in section 5, "Node Behavior" of draft-ietf-sip-events-00.txt it states, >"Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow the > same protocol rules governing the usage of tags, Route, > Record-Route, Via handling, retransmission, reliability, CSeq > handling, Contact handling, provisional responses, and message > formatting as those defined in RFC 2543 [1] for BYE." >Please note the difference of INVITE in the first draft versus BYE in the second draft. >Which one is correct? Please clarify. I believe the behavior should mirror INVITE. I believe I pointed this out to Adam but don't recall whether he concurred. This obviously needs to be resolved asap. Adam? -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 From Ron.Akers@motorola.com Thu Aug 30 11:16:07 2001 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07073 for ; Thu, 30 Aug 2001 11:16:06 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA13439 for ; Thu, 30 Aug 2001 08:16:03 -0700 (MST)] Received: [from il02exi02.comm.mot.com (il02exi02.comm.mot.com [145.1.204.41]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA17598 for ; Thu, 30 Aug 2001 08:16:02 -0700 (MST)] Received: by il02exi02.comm.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 30 Aug 2001 10:16:02 -0500 Message-ID: From: Akers Ron-WRA001 To: "'David R. Oran'" , "'Patil Basavaraj \\(NET/Dallas\\)'" , "'ext Robert Brown'" , Avshalom@ubique.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Thu, 30 Aug 2001 10:15:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Content-Length: 1660 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: Hi David: > I find the logic behind this conclusion utterly > incomprehensible. First of all, for "enterprise IM" the > firewall/NAT issue doesn't even arise because the > communication stays within the enterprise. If there are > multiple sites interconnected, they tend to use VPN > technology for precisely the reasons of not wanting to > deal with the NAT/FW bull.... for their own internal communication. > > Therefore, it seems completely wrongheaded to burden the > IM protocols with IM-specific mechanisms for firewall/NAT > traversal when this is know to hurt robustness, limit > scalability, and introduce gratuitous complexity. > I disagree with your conclusion about "Enterprise IM." But I guess it depends on your definition of what the pronoun "Enterprise" really means. I know in my company that IM is used more and more by our Product Groups to talk to their customers. This typically takes place with our guys behind our firewall, and them most likely behind an additional firewall. The dual firewall problem has caused no end of searching for commercial IM solutions (AOL, Yahoo, etc.) that work correctly and reliably in such a situation. Secondly, many of us do work from home. More and more these days companies are requiring this home work be on home networks secured behind a NAT/Firewall. Now, admittedly we can temporarily setup a VPN to the corporate Intranet to use IM, but it would be great if I could use IM from my laptop at home through BOTH firewalls to talk to colleagues. So, NATs may be ugly...but I feel it's important to deal with them. Regards, Ron From dean.willis@softarmor.com Thu Aug 30 11:19:31 2001 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 LAA07107 for ; Thu, 30 Aug 2001 11:19:30 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7SIYSD03973; Tue, 28 Aug 2001 13:34:28 -0500 Message-ID: <008e01c12ff0$02b90160$ad036e3f@flak> From: "Dean Willis" To: "Jonathan Rosenberg" , References: Subject: Re: [Simple] Sessions of MESSAGEs Date: Tue, 28 Aug 2001 13:34:01 -0500 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Length: 1741 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: Excuse me, but it the messages in a session are transported end-to-end, you've blown the whole privacy thing. They MUST be proxy-moderated to provide privacy -- and if the messages have to traverse message proxies, why not use the same proxies that are used for signaling, inasmuch as the signaling proxies already support privacy? Messages must also be proxy-routed to provide network-authenticated remote-party-ID. In this case, "the media is the mesage" is perfectly true. -- Dean Jonathan wrote: > These are all arguments for the session model. You still get all of that - > privacy protection, network authenticated R-PID, privacy, etc., > independently of how the media is transported. The only real argument for > SIP transport of the IMs themselves is that you can get nat traversal using > proxies. This does not seem to be a strong enough reason, given the other > technical problems, and the fact that this traversal is possible with other > means, such as the TCP version of the entfw traversal draft. > > > On the other hand, do we really need a "message session", or > > are serialized > > "pager messages" with retransmission and in-order assembly by the > > application good enough? > > There are numerous advantages to the session model, which include ease of > multiparty conferencing, reduction of the load on the proxy network, ease of > transfer, hold, and other sip-supported services, and so on. Conferencing is the same order of problem either way. Reduction of load on the proxy network does not apply if, according to my above argument, the messages are proxy-routed anyhow. "Hold" is a silly concept -- just stop typing. Transfer can be accomplished by sending a URL in part of the message stream. -- Dean From dean.willis@softarmor.com Thu Aug 30 11:19:32 2001 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 LAA07111 for ; Thu, 30 Aug 2001 11:19:31 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7SIgxD03989; Tue, 28 Aug 2001 13:42:59 -0500 Message-ID: <00a301c12ff1$3293b7d0$ad036e3f@flak> From: "Dean Willis" To: "Ben Campbell" Cc: References: <2E33960095B58E40A4D3345AB9F65EC1460F57@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <01ab01c129f8$c9a0ee80$55fa403f@blazer> <3B827845.5030604@dynamicsoft.com> Subject: Re: [Simple] Sessions of MESSAGEs Date: Tue, 28 Aug 2001 13:42:31 -0500 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Length: 2147 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: In #1, only the session setup is over the proxy network, The actual transport of messages in unspecified, but assumed to not be sip-over-the-signaling-proxies. It might be TCP, or it might be end-to-end SIP that does not traverse the signaling proxies. in #3, the messages are carried by SIP over the same proxies that handle other SIP messages, such as those used for setup. This gets us complete reuse of privacy, firewall traversal, and all the other neat stuff in SIP proxy networks. -- Dean ----- Original Message ----- From: "Ben Campbell" To: "Dean Willis" Cc: Sent: Tuesday, August 21, 2001 10:03 AM Subject: Re: [Simple] Sessions of MESSAGEs > Dean Willis wrote: > > > Ok, there's THREE topics: > > > > 1) MESSAGE sessions established directly between two nodes using SIP which > > is routed by proxies. > > 2) MESSAGE transmissions outside of a session routed by proxies ("Pager > > mode") > > 3) MESSAGE sessions between two nodes, where those messages are routed by > > proxies using the routing semantics of any other SIP message. Oddly enough, > > this begins to look a lot like BXXP. > > > > > Maybe it is to early in the morning for me, but I do not grasp the > distinction between 1 and 3. Both appear to reduce to "message sessions > over SIP routed by proxies". Perhaps the "routed by proxies" clause in 1 > was unintended? > > [snip] > > > > On the other hand, do we really need a "message session", or are serialized > > "pager messages" with retransmission and in-order assembly by the > > application good enough? > > > > In all honesty, I hope we do not see a lot of 2 party messsage > conversations invoking message sessions. The page model with a little > intelligence on the client software's part is usually sufficient. You > usually only invoke a session when you need something more than a two > party conversation. You use it for N party conversation, or when you > want to add and additional media type such as voice or video. For those > cases, treating messaging like any other media stream has advantages. > > > > > From dean.willis@softarmor.com Thu Aug 30 11:19:33 2001 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 LAA07115 for ; Thu, 30 Aug 2001 11:19:32 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7SInSD04007; Tue, 28 Aug 2001 13:49:28 -0500 Message-ID: <00c901c12ff2$1a5ae480$ad036e3f@flak> From: "Dean Willis" To: , References: Subject: Re: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol Date: Tue, 28 Aug 2001 13:48:59 -0500 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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Length: 6820 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: I read this differently. The IESG objected to using SIP as an end-to-end transport because all of the routing stuff is useless overhead in these cases. The IESG did not address those cases where the messages are traversing the proxy network. I have proposed that there are real reasons to have messages traverse the proxy network -- the vast majority of reasons for having a proxy network at all apply to messaging. This include firewall traversal, retransmission delegation, network validation of identity, privacy mechanisms, gateways between administrative domains, and so on. -_ Dean ----- Original Message ----- From: To: Sent: Thursday, August 23, 2001 7:11 AM Subject: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol > Howdy > > watching and putting some pieces together and I have this to offer... > > There appear to be two significant issues: > > 1. the IESG wants to tank MESSAGE method for MESSAGE sessions or 'chat' like > conversations between known SIP UAs based on SIP Extension Rules, i.e. looks > like a transport protocol > > 2. using the MESSAGE method for simple 'paged' instant messages or one-off > instant messages is OK. > > although one could argue it is still a mis-use of ideal SIP. This is > because it is still carrying a payload and not necessarily initiating a > 'session' Unless the session is a human-based session, i.e. "come here > watson" or "can I ask you a quick question?" which would then create the > need for a 'session of MESSAGES' or physical appearance, either of which > SHOULD be handled by another protocol. > > However, having another protocol for 'sessions of MESSAGEs' leads to the > issues Robert O. brought up, which were then refuted by Jonathon R. on the > basis of internet-drafts and scalability issues. Moreover, the fact that > the MESSAGE extension was being perceived as a 'transport' violates the use > of SIP extension (ID sip-guidelines-02.txt section 3.1.) > > SIP is supposed to act more like Chuck Wollery from 'the love connection' - > to use a colloquialism, i.e. bringing together > > Jonathon R. would like to have end-to-end session of MESSAGEs to travel > between the clients directly as this supports the scalability and original > voice use of the SIP server. On the other hand this doesn't support the > fundamental design requirements of IM as stated in rfc2779 2.4.3/2.4.4. > Which means, prior to supporting that end-to-end communication, the SIP > server would have to determine if 'that was allowed' based on the security > requirements Vasilis and Robert O have been talking about, which is also > required per rfc2779. > > Those fundamental services can be easily implemented at the SIP server if > SIP was the method used to send 'sessions of MESSAGES' - problem here, IESG > doesn't like it. There is a good reason why it is liked it's 'convenient', > but conveniences are not always a value. > > So what we have is the need to 'reuse or create security features' adjunct > by the modular/portability needs and requirements of SIP/Signaling > > The intermediary/PROXY MUST be created and supported as a basic feature of > the IM 'session of MESSAGEs' design. > > In Robert Os case he would want the development of that intermediary to play > off of the domain and security information designed into the SIP server > (thus making it portable across SIP and the IM proxy). > > This is easily designed if you have a unified configuration-directory where > the SIP Server and IM Message proxy pull configuration information, > otherwise, it looks like a complex proposition. > > Should the protocol used for 'sessions of MESSAGEs' define how the > intermediary would be used? Yes, it has to, if it is to meet the design > requirement of rfc2779 2.4.3/4 > > In addition, to support end-to-end signaling the SIP server needs to have > logic on whether or not that end-to-end signaling is allowed or whether it's > end-to-end-to-end-to-end :) - this meets the rfc2779 2.4.3/4 requirement, > regardless of natiness. > > So in retrospect: > > MESSAGE SIP extension can't be used for sessions of IMs other wise it looks > like a transport mechanism and should be implemented separately > > You need to design in the ability to use an intermediary per rfc 2779 > 2.4.3/4 (at a minimum) > > We will have to figure out a way to get the bonus of domain/security from > SIP server into an IM intermediary. A simple solution exists in using SIP > server to determine use of initiating sessions through an intermediary? > That is session initiation. > > Jonathon R. has some good solutions for the intermediary in other IDs he has > written, but the reality is the communication looks more like 'direct > chatting' than text based audio/video conference, which is why the IESG > probably frowned on using RTP - wasn't there so I can't say for sure. At a > high level these look the same, but at a low level the solution breaks down, > i.e. no video frames or audio sequencing in the protocol mechanism. Which > is probably why ID cpim-msgfmt specifies the use of an existing text based > format, RFC822. > > As an aside, I would also presume this is why sctp may not be a necessary > choice for the instant message 'signaling', to use a term from voice drafts, > given the sctp's primary use, albeit congestion management at the > intermediary/PROXY. IMs are only text per node, am I naive to think it's a > moot point or would there be congestion issues at the intermediary??? > > Lastly, Jonathon R appears convinced that the communication should be > end-to-end. > (http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html), > but over TCP :)! That works great if you are trying to scale the servers > and you want to put two callers together, but with IM, it's not voice and > it's like email, but more importantly, as stated in rfc2779, the > security/control needs to be built in. I am just pointing out the > 'vision/scope' of rfc2779 that says 'when you are heads down discussing > technical stuff, don't forget these requirements' Jonathon didn't write > that RFC2779 so he probably isn't thinking with that light bulb on. > > I would not want to see the IMsession design based on 'phone-calls' as > that's the 'way SIP has been predominatly used', but instead, to take a > different and assuredly positive approach. > > I am not intending to offend anyone and I took some time to listen to the > forum, prior to submitting my points. TIA > > Joshua > > -- > Joshua L. Konkle > Business Technology Architect > Digital Knowledge > http://www.digitalknowledge.net > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > From jbuch@windows.microsoft.com Thu Aug 30 11:20:41 2001 Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA07175 for ; Thu, 30 Aug 2001 11:20:41 -0400 (EDT) Received: from 157.54.1.52 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 30 Aug 2001 08:19:46 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 30 Aug 2001 08:19:45 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 30 Aug 2001 08:19:45 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 30 Aug 2001 08:19:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Sessions of MESSAGEs Date: Thu, 30 Aug 2001 08:19:20 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102A1CF3D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs Thread-Index: AcEwpurVBQn6O64UQ12ljtbedO629gAFTeOAACp0EjA= From: "Jeremy Buch" To: "Robert Brown" , "David R. Oran" Cc: "Patil Basavaraj (NET/Dallas)" , , X-OriginalArrivalTime: 30 Aug 2001 15:19:22.0168 (UTC) FILETIME=[25625B80:01C13167] Content-Length: 1656 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA07175 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: It should also be noted that many of our customers, advocates and internal IT staff advocate that enabling VPNs for the purpose of tying communications between companies is not even recommended (if there are any alternatives). IT staff even advocates to many of our customers that utilizing application-level gateways that enable open (or closed) communications via the Internet are preferred to sharply-defined VPNs that need additional management (as needs change). We must (and will) build something that is manageable AND deployable for existing corporate network systems. We need to define and attempt to move forward on an overall architectural goal, but we can not leave existing customers and networks out in the cold. -----Original Message----- From: Robert Brown Sent: Wednesday, August 29, 2001 11:59 AM To: David R. Oran; Patil Basavaraj (NET/Dallas); Avshalom@ubique.com; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs > I find the logic behind this conclusion utterly incomprehensible. First > of all, for "enterprise IM" the firewall/NAT issue doesn't even arise > because the communication stays within the enterprise. If there are > multiple sites interconnected, they tend to use VPN technology for > precisely the reasons of not wanting to deal with the NAT/FW bull.... > for their own internal communication. I find the fictional world described in this paragraph to be utterly incomprehensible. Have you ever used email? Have you heard of B2B e-commerce? You and I work in enterprises, and I don't believe a VPN exists between you and I, but many firewalls do, and you can still read this mail... From c-Dai.Ngo@WCOM.Com Thu Aug 30 11:27:44 2001 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 LAA07245 for ; Thu, 30 Aug 2001 11:27:44 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GIU00DGDG0RXD@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Wed, 29 Aug 2001 19:12:28 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GIU00901G0RFQ@dgismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 29 Aug 2001 19:12:27 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GIU00760G0A93@dgismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 29 Aug 2001 19:12:10 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 19:12:10 +0000 Content-return: allowed Date: Wed, 29 Aug 2001 19:12:07 +0000 From: "Ngo, Dai (c)" To: "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E6C4DDF@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_h1fVhKgsmzgf9MpK/g9BCw)" Content-Length: 2348 Subject: [Simple] Question on the List of Supported Presence Data Format and MIME T ypes 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: 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_h1fVhKgsmzgf9MpK/g9BCw) Content-type: text/plain; charset=ISO-8859-1 In section "5.4 NOTIFY Bodies" of the "draft-ietf-simple-presence-01.txt" it states, "The body of the notification contains a presence document. This document describes the user presence of the presentity that was subscribed to. All subscribers MUST support the presence data format described in [fill in with IMPP document TBD], and MUST list its MIME type, [fill in with MIME type] in an Accept header present in the SUBSCRIBE request." Does anyone have any information about the list of the presence data formats and the MIME types that will be supported by SIMPLE? Thanks. -- Dai Ngo --Boundary_(ID_h1fVhKgsmzgf9MpK/g9BCw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Question on the List of Supported Presence Data Format and MIME = Types

In section "5.4 NOTIFY Bodies" of the = "draft-ietf-simple-presence-01.txt" it states,

   "The body of the notification = contains a presence document. This
   document describes the user presence of = the presentity that was
   subscribed to. All subscribers MUST = support the presence data format
   described in [fill in with IMPP = document TBD], and MUST list its MIME
   type, [fill in with MIME type] in an = Accept header present in the
   SUBSCRIBE request."

Does anyone have any information about the list of = the presence data formats and the MIME types that will be supported by = SIMPLE?


Thanks.

-- Dai Ngo

--Boundary_(ID_h1fVhKgsmzgf9MpK/g9BCw)-- From jdrosen@dynamicsoft.com Thu Aug 30 12:01:19 2001 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 MAA07395 for ; Thu, 30 Aug 2001 12:01:19 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7UG0Tob007006; Thu, 30 Aug 2001 12:00:29 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 12:01:19 -0400 Message-ID: From: Jonathan Rosenberg To: "'David R. Oran'" , "'Robert Brown'" , "'Patil Basavaraj (NET/Dallas)'" , Avshalom@ubique.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Thu, 30 Aug 2001 12:01:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 6832 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: I accept as a requirement that the solution needs to support communications between enterprises in the case where: 1. there is no public provider on the public Internet, 2. one/both or neither of the enterprises has deployed a nat and/or firewall, but is willing to affect static configuration changes to that firewall/nat to enable real time communications, 3. it is feasible and acceptable to deploy elements within the enterprise that are application specific, to facilitate this application I think that, so long as a solution meets these requirements, Robert and the others will be satisfied, right? My big beef is that I do not want the solution to this to be IM specific, as the same issue arises with voice, video, etc. Therefore, I would prefer a more generic solution. The generic solution is what we lovingly call a "B2BUAWM", which is a B2BUA with Media (B2BUA is a SIP term, Back-to-back user agent). This is a proxy-like kind of element which is call-stateful and capable of complete manipulation of sip messages, initiation of sip messages, and so on. In this case, it also handles the media. So, let us assume that IM is carried over some TCP oriented transport. The configuration of interest is: Please view in a fixed-width font such as Courier. NAT/FW | \ | \ | \ .....................\/ \/...................... . ++ ++ . . || || . . || || . . +-------+ || || +-------+ . . | | || || | | . . | S1 | || || | S2 | . . | | || || | | . . +-------+ ++ ++ +-------+ . . . . . . . . . . . . . . . . . . //---\\ . . //---\\ . . || UA A || . . || UA B || . . \\---// . . \\---// . . . . . . Enterprise X . . Enterprise Y . ....................... ....................... A wishes to talk to B. Both are in two enterprises, X and Y, which both deploy a nat/fw. S1 and S2 are B2BUAWM. A sends an INVITE to establish an IM session. It includes, within the SDP, the IP/port for incoming TCP connections for its IM stream, say 10.0.1.1:9988. This INVITE goes to S1. S1 rewrites the SDP, to rather include an IP/port of its own, which is a publically routable one (as such, there must be cooperation of the fw/nat admin to allow a single IP address of S1 to be visible to the outside). So, the INVITE from S1 to S2 contains 64.22.1.2:8876 in the SDP. S1 remembers the mapping {10.0.1.1:9988 <-> 64.22.1.2:8876}. This goes to S2. S2 does a similar thing, placing a private internal address into the SDP in the INVITE, 192.168.10.1:1234. This goes to UA B. In the 2xx in the reverse direction, a similar set of rewrites can occur. For simplicities sake to facilitate discussion, lets assume that we are using comedia, and arbitrarily have elected for A to act as the passive side. B will attempt to open a TCP connection to the address it receive in the INVITE (192.168.10.1:1234). This succeeeds. S2 is the server side of this connection. It accepts it, and proceeds to open a connection to the address bound to that (64.22.1.2:8876). This is S1. This connection succeeds. S1 now opens a connection to the address mapped to that, 10.0.1.1:9988, which goes to UA A. This succeeds. Now, either side can send data. S2 and S1 do nothing more than bit shuffling across these TCP connections. There is no message processing or anything, just pure bit shuffling, which is very efficient. Now, the key thing is that whether the rewrite of the SDP is done in either direction is a local matter. So, if enterprise X has no nat or firewall, S1 is just a proxy. In that case, the TCP connection extends from S2 to UA A. If neither sides have nats/firewalls, the TCP connection is direct from UA A to UA B, as it should ideally be. Even if both sides deploy nat/fw, they can elect to rewrite in one direction only (the incoming side) so that the TCP connection only involves one of S1 or S2 (whether its S1 or S2 depends on which TCP connection is ultimately chosen; draft-ietf-mmusic-comedia discusses how this is done). Now, this little trick of rewiring SDP will also work for RTP, with the same kind of bit shuffling going on. For security purposes, one can also specify the use of TLS instead of TCP on some of the hops. Now, things are a bit more complex if one wishes to separate the SIP component from the IM forwarding component. In that case, there needs to be some kind of control relationship between the two. Certainly SIP can fill that role, using third party call control (I will send a separate note with the call flows). This would require a TCP enabled "IM conference server". Another option is MGCP/megaco, but I am not sure if MGCP/megaco support TCP or just UDP/RTP. Perhaps someone who knows can tell me. Midcom would be another possibility, and would result in the fastest performance and lowest cose. In that case, the "IM conference server thing" is actually another nat. All of these things will work for IM and RTP, and the benefit of the session model is that you reuse the solutions we are developing for RTP to support IM as well. Now, there is one additional requirement that merits discussion. Oded, I believe, asked that there be a single TCP connection between each enterprise, and a single one between any UA and its proxy. In the proposal above, there will be multiple connections. Thats because I am using the TCP ports as a demux, so that forwarding decision for data is based on port number alone. If you want shared TCP connections, thats a harder problem, and will require demux at the higher layers. It is not clear whether the additional message processing needed for each IM is more or less expensive than multiple TCP connections. 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 From jdrosen@dynamicsoft.com Thu Aug 30 18:33:49 2001 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 SAA08576 for ; Thu, 30 Aug 2001 18:33:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7UMWxob009746; Thu, 30 Aug 2001 18:32:59 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 18:33:50 -0400 Message-ID: From: Jonathan Rosenberg To: "'Avshalom@ubique.com'" , simple@mailman.dynamicsoft.com, Jonathan Rosenberg Subject: RE: [Simple] INVITE or BYE Clarification Date: Thu, 30 Aug 2001 18:33:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Content-Length: 1438 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: > -----Original Message----- > From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] > Sent: Thursday, August 30, 2001 2:43 PM > To: simple@mailman.dynamicsoft.com; Jonathan Rosenberg > Subject: RE: [Simple] INVITE or BYE Clarification > > > > > I believe the behavior should mirror INVITE. > > Would not it be logical that if SUBSCRIBE establishes a > session then NOTIFY > should be regarded as media and have the same limits tried to > be imposed on > MESSAGE? That concept has come up. But, I think that presence data is much more arguably "signaling" than IM is. Its generally small in size (although potentially frequent in its generation), but machine interpretable and therefore reasonably operated on by signaling entities as well. Note that, in genearl, the model with SIP is that proxies assist in setting up the call, and then step out of the way for subsequent communication, both signaling and media, to go direct if possible. Thus, I would expect that proxies wouldn't record-route subscribe unless they really needed to (i.e., nat, firewall). -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 From c-Dai.Ngo@WCOM.Com Thu Aug 30 21:46:45 2001 Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09175 for ; Thu, 30 Aug 2001 21:46:44 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0GIU002AN577BR@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Wed, 29 Aug 2001 15:18:43 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GIU00B01575T7@dgismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 29 Aug 2001 15:18:43 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GIU008NU560AQ@dgismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Wed, 29 Aug 2001 15:18:00 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 15:17:59 +0000 Content-return: allowed Date: Wed, 29 Aug 2001 15:17:57 +0000 From: "Ngo, Dai (c)" To: "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E6C4DDE@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_+zCU6DQQygoA+V/VA5HQmQ)" Content-Length: 2917 Subject: [Simple] Clarification 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: 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_+zCU6DQQygoA+V/VA5HQmQ) Content-type: text/plain; charset=ISO-8859-1 Hi All, In section 3, "Overview of Operation" of the draft-ietf-simple-presence-01.txt it states, "The SUBSCRIBE message effectively establishes a session with the presence agent. As a result, the SUBSCRIBE can be record-routed, and rules for tag handling and Contact processing mirror those for INVITE. " However, in section 5, "Node Behavior" of draft-ietf-sip-events-00.txt it states, "Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow the same protocol rules governing the usage of tags, Route, Record-Route, Via handling, retransmission, reliability, CSeq handling, Contact handling, provisional responses, and message formatting as those defined in RFC 2543 [1] for BYE." Please note the difference of INVITE in the first draft versus BYE in the second draft. Which one is correct? Please clarify. Thanks. -- Dai Ngo --Boundary_(ID_+zCU6DQQygoA+V/VA5HQmQ) Content-type: text/html; charset=ISO-8859-1 Clarification

Hi All,

In section 3, "Overview of Operation" of the draft-ietf-simple-presence-01.txt it states,
"The SUBSCRIBE message effectively establishes a session with the
   presence agent. As a result, the SUBSCRIBE can be record-routed, and
   rules for tag handling and Contact processing mirror those for
   INVITE. "

However, in section 5, "Node Behavior" of draft-ietf-sip-events-00.txt it states,
"Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow the
     same protocol rules governing the usage of tags, Route,
     Record-Route, Via handling, retransmission, reliability, CSeq
     handling, Contact handling, provisional responses, and message
     formatting as those defined in RFC 2543 [1] for BYE."

Please note the difference of INVITE in the first draft versus BYE in the second draft.

Which one is correct? Please clarify.
Thanks.

-- Dai Ngo

--Boundary_(ID_+zCU6DQQygoA+V/VA5HQmQ)-- From ahouri@netvision.net.il Fri Aug 31 05:55:00 2001 Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10645 for ; Fri, 31 Aug 2001 05:54:58 -0400 (EDT) Received: from avshalom (slip139-92-185-44.tel.il.ibm.net [139.92.185.44]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with SMTP id MAA22303 for ; Fri, 31 Aug 2001 12:57:38 +0300 (IDT) Message-ID: <000801c1320b$4c913ba0$2dbeef20@avshalom> From: "Avshalom Houri" To: Date: Fri, 31 Aug 2001 12:54:18 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C1321C.0C1D3B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 695 Subject: [Simple] test - please ignore Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1321C.0C1D3B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0005_01C1321C.0C1D3B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0005_01C1321C.0C1D3B80-- From avshalom@ubique.com Fri Aug 31 06:11:50 2001 Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10715 for ; Fri, 31 Aug 2001 06:11:48 -0400 (EDT) Received: from avshalom (slip139-92-185-44.tel.il.ibm.net [139.92.185.44]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with SMTP id NAA28917 for ; Fri, 31 Aug 2001 13:14:29 +0300 (IDT) Message-ID: <002901c1320d$a6ed7cb0$2dbeef20@avshalom> From: "Avshalom Houri" To: Date: Fri, 31 Aug 2001 13:11:11 +0200 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 1241 Subject: [Simple] Is SIP too restrictive for SIMPLE? 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: [Sending from a different email due to mailing list DNS problems] Looking back, there were a lot of discussions in the IMPP group if SIP is adequate to be a protocol for IM and presence. There were a lot of discussions on the volume of the SIP protocol etc. If we look at SIMPLE as an extension of SIP without regarding the special needs of IMPP then there seems to be some problems: * SIP is a transport protocol while SIMPLE is an application protocol - Where the transport area considerations end and the application considerations start? For example, the mandate of the IESG not to send MESSAGE in a session seems to come from transport considerations and not from applications considerations. * SIP is geared for creating sessions, it might suffice for current definition of IMPP but when trying to extend it, new methods will be needed, the SIP protocol might be need to be "contaminated" with methods that are far from the intention for what SIP was created. Will it be possible? Will every method need the approval of the SIP group? Maybe the relationship between SIMPLE and SIP should be defined as less restrictive? I am not sure if there are precedencies to such cases that we can learn from. avshalom Sametime/Lotus/IBM From avshalom@ubique.com Fri Aug 31 06:38:30 2001 Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10824 for ; Fri, 31 Aug 2001 06:38:28 -0400 (EDT) Received: from avshalom (slip139-92-185-44.tel.il.ibm.net [139.92.185.44]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with SMTP id NAA11458 for ; Fri, 31 Aug 2001 13:41:11 +0300 (IDT) Message-ID: <000501c13211$613dafb0$2dbeef20@avshalom> From: "Avshalom Houri" To: Date: Fri, 31 Aug 2001 13:37:53 +0200 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 269 Subject: [Simple] Partial Notifies? 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: [Sending from a different email due to mailing list DNS problems] Will it be possible to get partial updates to presence info? It is of course an optimization but it seems to be an important one as presence info can become very big. avshalom Sametime/Lotus/IBM From jdrosen@dynamicsoft.com Fri Aug 31 12:21:21 2001 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 MAA11974 for ; Fri, 31 Aug 2001 12:21:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7VGKUob013954; Fri, 31 Aug 2001 12:20:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 12:21:21 -0400 Message-ID: From: Jonathan Rosenberg To: "'Avshalom Houri'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Is SIP too restrictive for SIMPLE? Date: Fri, 31 Aug 2001 12:21:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 3780 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: > -----Original Message----- > From: Avshalom Houri [mailto:avshalom@ubique.com] > Sent: Friday, August 31, 2001 7:11 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Is SIP too restrictive for SIMPLE? > > > [Sending from a different email due to mailing list DNS problems] > > Looking back, there were a lot of discussions in the IMPP > group if SIP is > adequate to be a protocol for IM and presence. There were a lot of > discussions on the volume of the SIP protocol etc. > > If we look at SIMPLE as an extension of SIP without regarding > the special > needs of IMPP then there seems to be some problems: > > * SIP is a transport protocol while SIMPLE is an application > protocol - No, of course that is not true. SIP is standardized within the transport area, and SIMPLE within the applications area. The presence of SIP in transport is more historical than anything else. RTP was the first "voip" working group, and since it really is a transport, it was in the transport area. As other groups got added, mmusic, iptel, pint, spirits, sip, sipping, megaco - they all went into transport since that was where the voip work was. Would you say megaco was a transport protocol? Hardly. Neither is SIP. > Where the transport area considerations end and the application > considerations start? For example, the mandate of the IESG not to send > MESSAGE in a session seems to come from transport > considerations and not > from applications considerations. There has always been coordination between the applications area and transport. I recall that early on, the impp group was going to get feedback from the transport area on transport issues related to IM and presence. Such feedback was to help make sure that the application protocols properly took congestion control and transport into account. We have just gotten some feedback, as was the goal in the first place. > > * SIP is geared for creating sessions, it might suffice for current > definition of IMPP but when trying to extend it, new methods > will be needed, > the SIP protocol might be need to be "contaminated" with > methods that are > far from the intention for what SIP was created. Will it be > possible? Will > every method need the approval of the SIP group? This is really nothing more than FUD. SIP has a whole lot of extensibility built in. New methods, new payloads, new headers, the Require/Supported framework, new response codes, etc. These seem more than adequate for new stuff and have been more than adequate to handle the currently proposed extensions. If you have a specific concern about these not being sufficient for future needs, please post a specific concern. Arguably, the SIP group has been too willing to accept proposed extensions, rather than too restrictive. The approval of the SIMPLE working group clearly shows that there is IETF commitment to making sure this thing works. By closely aligning IM and presence treatment with voice, video, and other things, you have good assurances that future IM needs (which are likely to mirror voice needs) are met. Examples would include conferencing, privacy, thid party control, etc., all of which you will get for IM for free via inheritance from SIP. Can you please point out specific concerns you have? > > Maybe the relationship between SIMPLE and SIP should be > defined as less > restrictive? What does that mean, exactly? -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 From jdrosen@dynamicsoft.com Fri Aug 31 14:38:37 2001 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 OAA12389 for ; Fri, 31 Aug 2001 14:38:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7VIbkob015048 for ; Fri, 31 Aug 2001 14:37:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 14:38:37 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" Date: Fri, 31 Aug 2001 14:38:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 729 Subject: [Simple] Updated presence spec 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: Folks, I've just submitted an update to the presence spec. Until the update appears in the archives, you can grab a copy from: http://www.jdrosen.net/papers/draft-ietf-simple-presence-02.txt Changes are documented in the changes section. Mostly, it incorporates things agreed to from IETF 51 and now makes use of the new presence data format from IMPP. 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 From adv1@market.gogocity.com Sat Sep 1 01:57:32 2001 Received: from market0 ([208.158.105.111]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14467 for ; Sat, 1 Sep 2001 01:57:21 -0400 (EDT) From: adv1@market.gogocity.com Received: from mail pickup service by market0 with Microsoft SMTPSVC; Fri, 31 Aug 2001 22:53:49 -0700 To: Date: Fri, 31 Aug 2001 22:53:49 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2136BC_01C1326F.CC928E80" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 01 Sep 2001 05:53:49.0940 (UTC) FILETIME=[7906C340:01C132AA] Content-Length: 28679 Subject: [Simple] Retire Beanie Babies Save Up to 50% 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: This is a multi-part message in MIME format. ------=_NextPart_000_2136BC_01C1326F.CC928E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Big Saving from GoGoCity. If you'd rather not receive any future promotional E-mails from GoGoCity.com,=20 please click --> Un-Subscribe My E-mai l =20 International Order Welcome FREE SHIPPING NOT APPLY=20 ty=AE Beanie Babies (Retired)=20 Britannia Original Buddy Britannia Original Buddy click for large image Retail Price: $199.00 Out Price: $99.99(save 50%) More Details... =20 ty=AE Beanie Babies Special Sale Retails for $29.95~299.99 ( Save Up to 50% ) Now Only.....$99.99=20 This is an opportunity you don't want to miss and a great one to add to your collection.=20 Limited Quantities, Hurry UP......!!!!! =20 1. BRITANNIA ORIGINAL BUDDY 2. VALENTINO TY BEANIE BUDDY =20 Britannia Original Buddy large image =20 Retail Price: $199.00 Out Price: $99.99 (save 50%) More Details... =20 Buy it NOW !! =20 VALENTINO TY BEANIE BUDDY large image =20 Retail Price: $29.95 Out Price: $14.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 3. BRITANNIA THE BRITISH BEAR 4. NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE =20 BRITANNIA THE BRITISH BEAR large image =20 Retail Price: $125.99 Out Price: $79.95 (save 37%) More Details... =20 Buy it NOW !! =20 NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE large image =20 Retail Price: $111.95 Out Price: $55.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 5. CHINOOK THE CANADA BEAR 6. RADAR TY BEANIE BEANIE =20 CHINOOK THE CANADA BEAR large image =20 Retail Price: $69.65 Out Price: $49.95 (save 28%) More Details... =20 Buy it NOW !! =20 RADAR TY BEANIE BEANIE large image =20 Retail Price: $179.95 Out Price: $89.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 7. CORAL TY BEANIE BABY 8. STING THE STINGRAY TY BEANIE BABY =20 CORAL TY BEANIE BABY large image =20 Retail Price: $179.95 Out Price: $99.95 (save 44%) More Details... =20 Buy it NOW !! =20 STING THE STINGRAY TY BEANIE BABY large image =20 Retail Price: $179.95 Out Price: $129.95 (save 28%) More Details... =20 Buy it NOW !! =20 =09 9. GARCIA THE BEAR TY BEANIE BEANIE 10. TABASCO THE BULL TY BEANIE BEANIE =20 GARCIA THE BEAR TY BEANIE BEANIE large image =20 Retail Price: $299.99 Out Price: $199.95 (save 33%) More Details... =20 Buy it NOW !! =20 TABASCO THE BULL TY BEANIE BEANIE large image =20 Retail Price: $179.95 Out Price: $89.95 (save 50%) More Details... =20 Buy it NOW !! =20 =09 More Hot Item.....Click Here =20 ------=_NextPart_000_2136BC_01C1326F.CC928E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=20


Big Saving = from GoGoCity.=20 If you'd rather not receive any future promotional E-mails from = GoGoCity.com,=20
please click --> Un-Subscribe=20 My E-mail
International=20 Order Welcome=20 FREE SHIPPING NOT APPLY

=20
=20
ty®=20 Beanie Babies (Retired) =
=20
=20

Britannia=20 Original Buddy
3D"Britannia
click = for large image
Retail Price:=20 $199.00
Out Price: $99.99(save = 50%)
More=20 Details...

=20

ty®=20 Beanie Babies Special = Sale
Retails for $29.95~299.99=20 (=20 Save Up to 50% )

=20 Now Only.....$99.99=20

This=20 is an opportunity you don't want to miss
and a great one to add to your collection.
= =
Limited=20 Quantities= ,=20 Hurry = UP......!!!!!<= /font><= /b>
=20 =20 =20 =20 =20 =20 =20 =20 =20 =20
1.=20 BRITANNIA = ORIGINAL=20 BUDDY 2.=20 VALENTINO TY BEANIE BUDDY
=20 Retail=20 Price: $199.00
Out Price: $99.99 (save = 50%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $29.95
Out Price: $14.95 (save = 50%)
More=20 Details...
Buy it = NOW !!
3.=20 BRITANNIA THE BRITISH BEAR 4.=20 NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE
=20 Retail=20 Price: $125.99
Out Price: $79.95 (save = 37%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $111.95
Out Price: $55.95 (save = 50%)
More=20 Details...
Buy it = NOW !!
5.=20 CHINOOK THE CANADA BEAR 6.=20 RADAR TY BEANIE BEANIE
=20 Retail=20 Price: $69.65
Out Price: $49.95 (save = 28%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $179.95
Out Price: $89.95 (save = 50%)
More=20 Details...
Buy it = NOW !!
7.=20 CORAL TY BEANIE BABY 8.=20 STING THE STINGRAY TY BEANIE BABY
=20 Retail=20 Price: $179.95
Out Price: $99.95 (save = 44%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $179.95
Out Price: $129.95 (save = 28%)
More=20 Details...
Buy it = NOW !!
9.=20 GARCIA THE BEAR TY BEANIE BEANIE 10.=20 TABASCO THE BULL TY BEANIE BEANIE
=20 Retail=20 Price: $299.99
Out Price: $199.95 (save = 33%)
More=20 Details...
Buy it = NOW !!
 =20 Retail=20 Price: $179.95
Out Price: $89.95 (save = 50%)
More=20 Details...
Buy it = NOW !!

More=20 Hot Item.....Click Here
------=_NextPart_000_2136BC_01C1326F.CC928E80-- From hgs@cs.columbia.edu Sat Sep 1 17:31:03 2001 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27504 for ; Sat, 1 Sep 2001 17:31:03 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id RAA18169; Sat, 1 Sep 2001 17:30:58 -0400 (EDT) Message-ID: <3B915392.728255ED@cs.columbia.edu> Date: Sat, 01 Sep 2001 17:30:58 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Robert Brown'" , Vasilis Polychronidis , Robert Osborne , Zane Thomas , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1011 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: SASL seems like the right mechanism for TCP-based connections. Jonathan Rosenberg wrote: > > In the case of direct communication between clients, yes, this will be an > issue for TLS as it would require client certs, which is not that common. > This is a problem shared by all e2e encryption/authentication mechanisms. > There is work on defining SDP extensions for negotiation of session keys > (primarily for SRTP), and some of the key management mechanisms don't > require certs, but rather, just shared secrets. It would be nice to be able > to use that key management stuff for transport beyond SRTP, such as whatever > we define for IM. > > However, if you want secure IM and trust that server in the cloud, you can > simply elect not to use direct communications even if possible. The > signaling mechanisms in entfw and the drafts it depends on (i.e., comedia) > support that. > > So, you get best of both worlds, from what I can tell.... -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From angelina313@prontomail.com Sat Sep 1 21:08:02 2001 Received: from online.fjzz.cn.net ([202.101.106.17]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id VAA28181 for ; Sat, 1 Sep 2001 21:08:00 -0400 (EDT) Received: from plain by online.fjzz.cn.net (SMI-8.6/SMI-SVR4) id FAA12641; Sun, 2 Sep 2001 05:40:38 +0900 Message-Id: <200109012040.FAA12641@online.fjzz.cn.net> From: radiationglowe449hgn@usa.net To: simple@mailman.dynamicsoft.com Date: Sat, 1 Sep 2001 21:09:55 Mime-Version: 1.0 Content-Type: text/plain; charset="DEFAULT_CHARSET" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Length: 1315 Subject: [Simple] "How To Make A Killing On The Net with no Money" Free Details. 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: --->How To Make It *BIG* on the Net...QUICKLY...with NO Money! This is NEW and INCREDIBLY EXCITING!! Join Free, WORLD-WIDE! (Zero investment!) No hassles, no selling, no pressure. Like NOTHING you have ever seen on the net today! No limits... You can join for FREE and MAKE MONEY!! We will Help YOU! Once your earnings START, they NEVER STOP! Check out this EXCITING OPPORTUNITY. Start immediately. ===> I'll email you free details. <=== Just send a blank e-mail to: quickway3@excite.com -->and type "JoinFree" in subject line. (DO NOT HIT REPLY or It will be automatically purged or bounced.) Hope you don't miss this one. ============================================= (DO NOT HIT REPLY or It will be automatically purged or bounced.) -- ---------------------------------------------- *********(REMOVAL INSTRUCTIONS BELOW)********** ---------------------------------------------- --------------------------------------------------------------------------------------------- If you wish to be removed from future mailings, please send an email to: rose@prontomail.com with the subject "Remove" and you will automatically be blocked from any future mailings. -------------------------------------------------------------------------------------------- From Avshalom@ubique.com Sun Sep 2 03:55:33 2001 Received: from ubqgate02.lotus.com ([194.196.39.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29503 for ; Sun, 2 Sep 2001 03:55:31 -0400 (EDT) From: Avshalom@ubique.com Subject: RE: [Simple] INVITE or BYE Clarification To: simple@mailman.dynamicsoft.com, Jonathan Rosenberg X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 30 Aug 2001 21:43:12 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 02/09/2001 10:54:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 3477 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: > I believe the behavior should mirror INVITE. Would not it be logical that if SUBSCRIBE establishes a session then NOTIFY should be regarded as media and have the same limits tried to be imposed on MESSAGE? I just want to try to point to what extermes things can go. avshalom Sametime/Lotus/IBM Jonathan Rosenberg To: "'Ngo, Dai (c)'" , Sent by: "'simple@mailman.dynamicsoft.com'" simple-admin@mailman.dynam cc: "Adam Roach (E-mail)" , "'sip@ietf.org'" icsoft.com Subject: RE: [Simple] INVITE or BYE Clarification 30/08/2001 18:12 -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Thursday, August 30, 2001 10:59 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] INVITE or BYE Clarification >Hi All, >In section 3, "Overview of Operation" of the draft-ietf-simple-presence-01.txt it states, >"The SUBSCRIBE message effectively establishes a session with the > presence agent. As a result, the SUBSCRIBE can be record-routed, and > rules for tag handling and Contact processing mirror those for > INVITE. " >However, in section 5, "Node Behavior" of draft-ietf-sip-events-00.txt it states, >"Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow the > same protocol rules governing the usage of tags, Route, > Record-Route, Via handling, retransmission, reliability, CSeq > handling, Contact handling, provisional responses, and message > formatting as those defined in RFC 2543 [1] for BYE." >Please note the difference of INVITE in the first draft versus BYE in the second draft. >Which one is correct? Please clarify. I believe the behavior should mirror INVITE. I believe I pointed this out to Adam but don't recall whether he concurred. This obviously needs to be resolved asap. Adam? -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 Amihay_Fuxbruner@icomverse.com Tue Sep 4 09:16:25 2001 Received: from ismailout.icomverse.com (comversegw.icomverse.com [192.118.48.253]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05365 for ; Tue, 4 Sep 2001 09:16:23 -0400 (EDT) Received: from ismail-bridge.icomverse.com (ismail-bridge.icomverse.com [190.190.110.12]) by ismailout.icomverse.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id f84DFQ502395; Tue, 4 Sep 2001 16:15:37 +0300 Received: by ismail-bridge.icomverse.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 16:14:24 +0300 Message-ID: From: "Fuxbruner, Amihay" To: "'Jonathan Rosenberg'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Sessions of MESSAGEs Date: Tue, 4 Sep 2001 16:12:58 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 7312 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: Can this support e2e encryption ? -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, August 30, 2001 7:01 PM To: 'David R. Oran'; 'Robert Brown'; 'Patil Basavaraj (NET/Dallas)'; Avshalom@ubique.com; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs I accept as a requirement that the solution needs to support communications between enterprises in the case where: 1. there is no public provider on the public Internet, 2. one/both or neither of the enterprises has deployed a nat and/or firewall, but is willing to affect static configuration changes to that firewall/nat to enable real time communications, 3. it is feasible and acceptable to deploy elements within the enterprise that are application specific, to facilitate this application I think that, so long as a solution meets these requirements, Robert and the others will be satisfied, right? My big beef is that I do not want the solution to this to be IM specific, as the same issue arises with voice, video, etc. Therefore, I would prefer a more generic solution. The generic solution is what we lovingly call a "B2BUAWM", which is a B2BUA with Media (B2BUA is a SIP term, Back-to-back user agent). This is a proxy-like kind of element which is call-stateful and capable of complete manipulation of sip messages, initiation of sip messages, and so on. In this case, it also handles the media. So, let us assume that IM is carried over some TCP oriented transport. The configuration of interest is: Please view in a fixed-width font such as Courier. NAT/FW | \ | \ | \ .....................\/ \/...................... . ++ ++ . . || || . . || || . . +-------+ || || +-------+ . . | | || || | | . . | S1 | || || | S2 | . . | | || || | | . . +-------+ ++ ++ +-------+ . . . . . . . . . . . . . . . . . . //---\\ . . //---\\ . . || UA A || . . || UA B || . . \\---// . . \\---// . . . . . . Enterprise X . . Enterprise Y . ....................... ....................... A wishes to talk to B. Both are in two enterprises, X and Y, which both deploy a nat/fw. S1 and S2 are B2BUAWM. A sends an INVITE to establish an IM session. It includes, within the SDP, the IP/port for incoming TCP connections for its IM stream, say 10.0.1.1:9988. This INVITE goes to S1. S1 rewrites the SDP, to rather include an IP/port of its own, which is a publically routable one (as such, there must be cooperation of the fw/nat admin to allow a single IP address of S1 to be visible to the outside). So, the INVITE from S1 to S2 contains 64.22.1.2:8876 in the SDP. S1 remembers the mapping {10.0.1.1:9988 <-> 64.22.1.2:8876}. This goes to S2. S2 does a similar thing, placing a private internal address into the SDP in the INVITE, 192.168.10.1:1234. This goes to UA B. In the 2xx in the reverse direction, a similar set of rewrites can occur. For simplicities sake to facilitate discussion, lets assume that we are using comedia, and arbitrarily have elected for A to act as the passive side. B will attempt to open a TCP connection to the address it receive in the INVITE (192.168.10.1:1234). This succeeeds. S2 is the server side of this connection. It accepts it, and proceeds to open a connection to the address bound to that (64.22.1.2:8876). This is S1. This connection succeeds. S1 now opens a connection to the address mapped to that, 10.0.1.1:9988, which goes to UA A. This succeeds. Now, either side can send data. S2 and S1 do nothing more than bit shuffling across these TCP connections. There is no message processing or anything, just pure bit shuffling, which is very efficient. Now, the key thing is that whether the rewrite of the SDP is done in either direction is a local matter. So, if enterprise X has no nat or firewall, S1 is just a proxy. In that case, the TCP connection extends from S2 to UA A. If neither sides have nats/firewalls, the TCP connection is direct from UA A to UA B, as it should ideally be. Even if both sides deploy nat/fw, they can elect to rewrite in one direction only (the incoming side) so that the TCP connection only involves one of S1 or S2 (whether its S1 or S2 depends on which TCP connection is ultimately chosen; draft-ietf-mmusic-comedia discusses how this is done). Now, this little trick of rewiring SDP will also work for RTP, with the same kind of bit shuffling going on. For security purposes, one can also specify the use of TLS instead of TCP on some of the hops. Now, things are a bit more complex if one wishes to separate the SIP component from the IM forwarding component. In that case, there needs to be some kind of control relationship between the two. Certainly SIP can fill that role, using third party call control (I will send a separate note with the call flows). This would require a TCP enabled "IM conference server". Another option is MGCP/megaco, but I am not sure if MGCP/megaco support TCP or just UDP/RTP. Perhaps someone who knows can tell me. Midcom would be another possibility, and would result in the fastest performance and lowest cose. In that case, the "IM conference server thing" is actually another nat. All of these things will work for IM and RTP, and the benefit of the session model is that you reuse the solutions we are developing for RTP to support IM as well. Now, there is one additional requirement that merits discussion. Oded, I believe, asked that there be a single TCP connection between each enterprise, and a single one between any UA and its proxy. In the proposal above, there will be multiple connections. Thats because I am using the TCP ports as a demux, so that forwarding decision for data is based on port number alone. If you want shared TCP connections, thats a harder problem, and will require demux at the higher layers. It is not clear whether the additional message processing needed for each IM is more or less expensive than multiple TCP connections. 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 pkyzivat@cisco.com Tue Sep 4 11:09:20 2001 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 LAA05760 for ; Tue, 4 Sep 2001 11:09:20 -0400 (EDT) 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 f84F8qe04772; Tue, 4 Sep 2001 11:08:52 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAI01194 (AUTH pkyzivat); Tue, 4 Sep 2001 11:10:16 -0400 (EDT) Message-ID: <3B94EE78.D7CE6731@cisco.com> Date: Tue, 04 Sep 2001 11:08:40 -0400 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] Updated presence spec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4266 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: Jonathan Rosenberg wrote: > > Folks, > > I've just submitted an update to the presence spec. Until the update appears > in the archives, you can grab a copy from: > > http://www.jdrosen.net/papers/draft-ietf-simple-presence-02.txt Here are some comments to this document. I suspect some of them apply equally well to earlier verions, and I apologize for not providing them sooner. ---------- 1) Frequency of presence changes: Section 5.11 suggests a maximum rate of one notification every 5 seconds. This kind of limit could damage the effectiveness of some call queuing mechanisms. For instance, to support call queuing it could be useful for a PA to generate presence notifications in response to on-hook/off-hook and off-hook/on-hook transitions in a UA. If an off-hook/on-hook transition generates a presence notification, this might well result in the arrival of an immediate INVITE, and that in turn lead to an immediate on-hook/off-hook transition. This kind of scenario could lead to frequencies on the order of a second or less. Even so, an *average* maximum rate of once per 5 seconds may be ok in such a scenario. Section 5.4 also gives examples of when presence changes, and suggests that the frequency of occurrence ranges from minutes to hours. This fails to mention the possibility that on-hook/off-hook and off-hook/on-hook transitions of a phone might alter presence. This doesn't alter the conclusion of section 5.4 regarding subscription duration, but mentioning it might alter the implication that a minute is a practical lower bound on frequency of presence changes. ---------- 2) Sourcing presence documents: Section 2 says: Presence User Agent (PUA): A Presence User Agent manipulates presence information for a presentity. In SIP terms, this means that a PUA generates REGISTER requests, conveying some kind of information about the presentity. whereas section 5.8 says: The means by which the PA learns the state of the presentity are also outside the scope of this recommendation. Registrations provide one way, and the means by which a PA uses registrations to construct a presence document are an implementation choice. Seems like the statement in section 2 is a bit strong. Perhaps the sentence beginning with "In SIP terms..." should just be deleted. Section 5.8 is also too strong. Seems like it can at most state: "Registrations MAY provide a way, though the means (if any) by which a PA uses registrations to construct a presence document are an implementation choice." Those changes would help achieve the apparent objective of eliminating any stardard way of making presence state known. But I don't understand why this is a good thing. Wouldn't it be better to have one way of doing this that is always available, even while permitting other ways? ---------- 3) Routing of Subscribe refreshes Section 5.10 says: Furthermore, when refreshing the subscription, the refresh SHOULD make use of the tags from the 202 and make use of any Contact or Record-Route headers in order to deliver the SUBSCRIBE back to the same PA that sent the 202. while 5.12 says: For the second phase, the PA destroys the subscriptions and then sends a NOTIFY to each subscriber, with an Subscription-Expires header with value 0 [3]. This informs the subscribers that their subscription was destroyed, and should be re-established with a new SUBSCRIBE (with a new Call-ID). The subscribers then create brand new subscriptions, with a new Call-ID, no route set and no To tag, and this is sent to recreate the subscription. These seem to conflict - unless the response to receipt of a Subscription-Expires header with value 0 is treated as a special case different from normal subscription expiration. That kind of special casing seems like a bad idea. ---------- 4) The followng in section 3 is grammatically incorrect: When an entity, the subscriber, wishes to learn about presence information from some user, it creates a SUBSCRIBE request. This request identifies the desired presentity in the request URI, using either a SIP URL. ^^^^^^ Something is missing - either a SIP URL or what??? ---------- Paul Kyzivat Cisco Systems From c-Dai.Ngo@WCOM.Com Tue Sep 4 16:26:17 2001 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 QAA06789 for ; Tue, 4 Sep 2001 16:26:17 -0400 (EDT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0GJ500ECTNFM2J@firewall.mcit.com> for simple@mailman.dynamicsoft.com; Tue, 4 Sep 2001 20:26:10 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GJ500I01NEHKD@dgismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Tue, 04 Sep 2001 20:26:09 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GJ500HB1NEA4R@dgismtp04.wcomnet.com> for simple@mailman.dynamicsoft.com; Tue, 04 Sep 2001 20:25:22 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Tue, 04 Sep 2001 20:25:21 +0000 Content-return: allowed Date: Tue, 04 Sep 2001 20:25:14 +0000 From: "Ngo, Dai (c)" To: simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E6C4DE8@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_FDwuQ/1c91EjxmY/oj89Rw)" Content-Length: 1780 Subject: [Simple] Notifier Migration Clarification 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: 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_FDwuQ/1c91EjxmY/oj89Rw) Content-type: text/plain; charset=ISO-8859-1 All, In section 5.12 "State Agents and Notifier Migration" of draft-ietf-simple-presence-02.txt it says, "The presence server MAY migrate the subscription if, for a given address of record, there is one, and only one registered contact that indicates explicit support for the SUBSCRIBE method." What's the behavior of the presence server if there are multiple registered contacts which explicitly support for the SUBSCRIBE method? Thanks. -- Dai --Boundary_(ID_FDwuQ/1c91EjxmY/oj89Rw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Notifier Migration Clarification

All,

In section 5.12 "State Agents and Notifier = Migration" of draft-ietf-simple-presence-02.txt it says, "The = presence server MAY migrate the subscription if, for a given address of = record, there is one, and only one registered contact that indicates = explicit support for the SUBSCRIBE method."

What's the behavior of the presence server if there = are multiple registered contacts which explicitly support for the = SUBSCRIBE method?

Thanks.

-- Dai

--Boundary_(ID_FDwuQ/1c91EjxmY/oj89Rw)-- From jdrosen@dynamicsoft.com Tue Sep 4 18:39:11 2001 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 SAA07204 for ; Tue, 4 Sep 2001 18:39:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f84McHCj006364; Tue, 4 Sep 2001 18:38:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Sep 2001 18:39:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Notifier Migration Clarification Date: Tue, 4 Sep 2001 18:39:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1053 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: -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Tuesday, September 04, 2001 4:25 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] Notifier Migration Clarification >All, >In section 5.12 "State Agents and Notifier Migration" of draft-ietf-simple-presence-02.txt >it says, "The presence server MAY migrate the subscription if, for a given address of >record, there is one, and only one registered contact that indicates explicit support for >the SUBSCRIBE method." > >What's the behavior of the presence server if there are multiple registered contacts which >explicitly support for the SUBSCRIBE method? It can't migrate the PA function. -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 From roberbr@microsoft.com Tue Sep 4 21:52:44 2001 Received: from inet-vrs-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id VAA07826 for ; Tue, 4 Sep 2001 21:52:44 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Sep 2001 18:51:39 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 18:51:41 -0700 Received: from roberbr420xp ([172.31.77.52]) by red-msg-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 18:51:41 -0700 Message-ID: <006c01c135ad$4f2d0790$344d1fac@redmond.corp.microsoft.com> From: "Robert Brown" To: "Jonathan Rosenberg" , "'David R. Oran'" , "'Patil Basavaraj \(NET/Dallas\)'" , , References: Subject: Re: [Simple] Sessions of MESSAGEs Date: Tue, 4 Sep 2001 18:51:41 -0700 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 X-OriginalArrivalTime: 05 Sep 2001 01:51:41.0285 (UTC) FILETIME=[4EECF150:01C135AD] Content-Length: 10635 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: Thanks for this detailed description. You're going to hate me, I'm sure :-), but I still think this is the wrong solution for IM. You're assuming "one/both or neither of the enterprises has deployed a nat and/or firewall, but is willing to affect static configuration changes to that firewall/nat to enable real time communications" and "it is feasible and acceptable to deploy elements within the enterprise that are application specific, to facilitate this application". But I don't think these are completely valid assumptions. I think it is flawed to assume all "real time communication" modes are equally complicated and should be solved in the same way. It is far easier to get cross-firewall IM (there are already many existing widespread implementations of this) than it is to get cross-firewall audio/video streams. IM is not "real time" in the same sense as audio and video: it tolerates considerable delays; it does not tolerate loss of information; it has extremely low bandwidth requirements. I just don't see the evidence that IM has much in common with RTP, and hence that an RTP solution is automatically the best solution for IM. The second flaw is to assume that IT departments will be willing to open port ranges. At most, an IT department will open a well-defined port for a specific purpose. E.g. 443 for HTTPS, 5061 for SIP/TLS. Hence mapping sessions to ports will not be deployable. You will need to map sessions to sockets. As you point out below, this is more difficult because it requires encoding at a higher layer. Thirdly, I don't think we should base something as fundamental as instant messaging on assumptions about what an acceptable generalized firewall traversal architecture may be. I don't want SIMPLE to make a design call based on whether something like your entfw-02 draft, or a MEGACO draft, or whatever, will be the firewall traversal solution. Fourthly, multiplexing multiple conversations on a single TCP session is a very valid requirement. Imagine you're a large IM service provider (such as MSN, AOL, Yahoo, and the various larger ISPs). You can expect quite a mesh between users of these services (assuming they want to open themselves to interop via SIMPLE). Hence probably millions of parallel TCP connections between a few data centers. I doubt that anybody who runs a data center wants to take this hit. And forget about making the TCP connections using TLS - how many cycles do you want to burn on session establishment? I can send a SIP MESSAGE request pretty easily. I've read nothing in any of these threads that convinces me that extending this innate SIP capability is a bad idea. If people are worried about swamping their proxies with IM, it's too late - you'll find SIP proxies will be far busier with SUBSCRIBE and NOTIFY than they ever will be with MESSAGE. Don't believe me? I have 62 buddies in my buddy list. That's 62 NOTIFYs each time my status changes. When I log on, I'm sending 62 SUBSCRIBEs, and receiving 62 NOTIFYs, and triggering 62 watcherinfo NOTIFYs to my buddies. Why not INVITE my buddies to a presence session, and define a separate protocol for transferring this presence information? ----- Original Message ----- From: "Jonathan Rosenberg" To: "'David R. Oran'" ; "'Robert Brown'" ; "'Patil Basavaraj (NET/Dallas)'" ; ; Sent: Thursday, August 30, 2001 9:01 AM Subject: RE: [Simple] Sessions of MESSAGEs > I accept as a requirement that the solution needs to support communications > between enterprises in the case where: > > 1. there is no public provider on the public Internet, > 2. one/both or neither of the enterprises has deployed a nat and/or > firewall, but is willing to affect static configuration changes to that > firewall/nat to enable real time communications, > 3. it is feasible and acceptable to deploy elements within the enterprise > that are application specific, to facilitate this application > > I think that, so long as a solution meets these requirements, Robert and the > others will be satisfied, right? My big beef is that I do not want the > solution to this to be IM specific, as the same issue arises with voice, > video, etc. Therefore, I would prefer a more generic solution. > > The generic solution is what we lovingly call a "B2BUAWM", which is a B2BUA > with Media (B2BUA is a SIP term, Back-to-back user agent). This is a > proxy-like kind of element which is call-stateful and capable of complete > manipulation of sip messages, initiation of sip messages, and so on. In this > case, it also handles the media. > > So, let us assume that IM is carried over some TCP oriented transport. The > configuration of interest is: > > Please view in a fixed-width font such as Courier. > > > > > NAT/FW > | \ > | \ > | \ > .....................\/ \/...................... > . ++ ++ . > . || || . > . || || . > . +-------+ || || +-------+ . > . | | || || | | . > . | S1 | || || | S2 | . > . | | || || | | . > . +-------+ ++ ++ +-------+ . > . . . . > . . . . > . . . . > . . . . > . //---\\ . . //---\\ . > . || UA A || . . || UA B || . > . \\---// . . \\---// . > . . . . > . Enterprise X . . Enterprise Y . > ....................... ....................... > > A wishes to talk to B. Both are in two enterprises, X and Y, which both > deploy a nat/fw. S1 and S2 are B2BUAWM. A sends an INVITE to establish an IM > session. It includes, within the SDP, the IP/port for incoming TCP > connections for its IM stream, say 10.0.1.1:9988. This INVITE goes to S1. S1 > rewrites the SDP, to rather include an IP/port of its own, which is a > publically routable one (as such, there must be cooperation of the fw/nat > admin to allow a single IP address of S1 to be visible to the outside). So, > the INVITE from S1 to S2 contains 64.22.1.2:8876 in the SDP. S1 remembers > the mapping {10.0.1.1:9988 <-> 64.22.1.2:8876}. This goes to S2. S2 does a > similar thing, placing a private internal address into the SDP in the > INVITE, 192.168.10.1:1234. This goes to UA B. In the 2xx in the reverse > direction, a similar set of rewrites can occur. > > For simplicities sake to facilitate discussion, lets assume that we are > using comedia, and arbitrarily have elected for A to act as the passive > side. B will attempt to open a TCP connection to the address it receive in > the INVITE (192.168.10.1:1234). This succeeeds. S2 is the server side of > this connection. It accepts it, and proceeds to open a connection to the > address bound to that (64.22.1.2:8876). This is S1. This connection > succeeds. S1 now opens a connection to the address mapped to that, > 10.0.1.1:9988, which goes to UA A. This succeeds. Now, either side can send > data. S2 and S1 do nothing more than bit shuffling across these TCP > connections. There is no message processing or anything, just pure bit > shuffling, which is very efficient. > > Now, the key thing is that whether the rewrite of the SDP is done in either > direction is a local matter. So, if enterprise X has no nat or firewall, S1 > is just a proxy. In that case, the TCP connection extends from S2 to UA A. > If neither sides have nats/firewalls, the TCP connection is direct from UA > A to UA B, as it should ideally be. Even if both sides deploy nat/fw, they > can elect to rewrite in one direction only (the incoming side) so that the > TCP connection only involves one of S1 or S2 (whether its S1 or S2 depends > on which TCP connection is ultimately chosen; draft-ietf-mmusic-comedia > discusses how this is done). > > Now, this little trick of rewiring SDP will also work for RTP, with the same > kind of bit shuffling going on. > > For security purposes, one can also specify the use of TLS instead of TCP on > some of the hops. > > Now, things are a bit more complex if one wishes to separate the SIP > component from the IM forwarding component. In that case, there needs to be > some kind of control relationship between the two. Certainly SIP can fill > that role, using third party call control (I will send a separate note with > the call flows). This would require a TCP enabled "IM conference server". > Another option is MGCP/megaco, but I am not sure if MGCP/megaco support TCP > or just UDP/RTP. Perhaps someone who knows can tell me. Midcom would be > another possibility, and would result in the fastest performance and lowest > cose. In that case, the "IM conference server thing" is actually another > nat. > > All of these things will work for IM and RTP, and the benefit of the session > model is that you reuse the solutions we are developing for RTP to support > IM as well. > > Now, there is one additional requirement that merits discussion. Oded, I > believe, asked that there be a single TCP connection between each > enterprise, and a single one between any UA and its proxy. In the proposal > above, there will be multiple connections. Thats because I am using the TCP > ports as a demux, so that forwarding decision for data is based on port > number alone. If you want shared TCP connections, thats a harder problem, > and will require demux at the higher layers. It is not clear whether the > additional message processing needed for each IM is more or less expensive > than multiple TCP connections. > > 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 > > From jdrosen@dynamicsoft.com Wed Sep 5 02:53:15 2001 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 CAA08739 for ; Wed, 5 Sep 2001 02:53:15 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f856qKCj007938; Wed, 5 Sep 2001 02:52:20 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 02:53:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'Avshalom Houri'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Partial Notifies? Date: Wed, 5 Sep 2001 02:53:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1805 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: > -----Original Message----- > From: Avshalom Houri [mailto:avshalom@ubique.com] > Sent: Friday, August 31, 2001 7:38 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Partial Notifies? > > > [Sending from a different email due to mailing list DNS problems] > > Will it be possible to get partial updates to presence info? > It is of course > an optimization I was actually debating this issue when doing the update of the presence spec. Its not specified right now, all through the events framework allows each package to define how its done. One model to do this is something I have proposed for other packages: 1. the notify triggered by a subscribe contains the full state 2. subsequent notifies contain only the piece thats changed (i.e., the contact address that is different) 3. the subscriber keeps track of the cseq to see if it may have missed a notify. If there are no gaps in Cseq, nothing was missed. If there is a gap, something may have been missed, or else there was an intermediate challenge or something like that. So, the subscriber re-subscribes to get a triggered notify with full state. A better way to handle the ordering is for the presence document itself to contain version numbers, but that would require changes in the pidf spec. Since the initial SUBSCRIBE has to trigger full state anyway, idempotency of SUBSCRIBE would argue for having full state triggered notify for refreshes too. -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 From dror@vocaltec.com Wed Sep 5 03:42:01 2001 Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08920 for ; Wed, 5 Sep 2001 03:41:59 -0400 (EDT) From: dror@vocaltec.com Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id JAA13296; Wed, 5 Sep 2001 09:19:41 +0200 (IST) To: Jonathan Rosenberg Cc: "'Avshalom Houri'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Partial Notifies? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: Date: Wed, 5 Sep 2001 10:33:45 +0200 X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 09/05/2001 10:33:47 AM, Serialize complete at 09/05/2001 10:33:47 AM Content-Type: multipart/alternative; boundary="=_alternative 002F817142256ABE_=" Content-Length: 8235 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: This is a multipart message in MIME format. --=_alternative 002F817142256ABE_= Content-Type: text/plain; charset="us-ascii" Actually, there's also an approach to allow the SUBSCRIBE-triggered notification to be partial: The subscribe may include a "digest" (or checksum) of the data currently known to the client. The server may respond with "not modified", if the same digest matches the information on the server. Only if there is some difference between the client's view of the data and the server's view of the data, a full trigger is returned. Also, the digest should be returned with every "partial" update, and thus the client does not have to rely on CSeg numbers for data integrity (That is, even if the CSeq numbers are not sequential, the client may recognize that there's no need for full update, as in the case that it missed a sequence of changes to the same entity, and received only the last change of it). ---------------------------------------------------------------- Dror Tirosh VocalTec Communications, Ltd -------------------------------------------------------------- Jonathan Rosenberg Sent by: simple-admin@mailman.dynamicsoft.com 05/09/2001 08:53 To: "'Avshalom Houri'" , simple@mailman.dynamicsoft.com cc: Subject: RE: [Simple] Partial Notifies? > -----Original Message----- > From: Avshalom Houri [mailto:avshalom@ubique.com] > Sent: Friday, August 31, 2001 7:38 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Partial Notifies? > > > [Sending from a different email due to mailing list DNS problems] > > Will it be possible to get partial updates to presence info? > It is of course > an optimization I was actually debating this issue when doing the update of the presence spec. Its not specified right now, all through the events framework allows each package to define how its done. One model to do this is something I have proposed for other packages: 1. the notify triggered by a subscribe contains the full state 2. subsequent notifies contain only the piece thats changed (i.e., the contact address that is different) 3. the subscriber keeps track of the cseq to see if it may have missed a notify. If there are no gaps in Cseq, nothing was missed. If there is a gap, something may have been missed, or else there was an intermediate challenge or something like that. So, the subscriber re-subscribes to get a triggered notify with full state. A better way to handle the ordering is for the presence document itself to contain version numbers, but that would require changes in the pidf spec. Since the initial SUBSCRIBE has to trigger full state anyway, idempotency of SUBSCRIBE would argue for having full state triggered notify for refreshes too. -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 --=_alternative 002F817142256ABE_= Content-Type: text/html; charset="us-ascii"
Actually, there's also an approach to allow the SUBSCRIBE-triggered notification to be partial:
The subscribe may include a "digest" (or checksum) of the data currently known to the client. The server may respond with "not modified", if the same digest matches the information on the server.
Only if there is some difference between the client's view of the data and the server's view of the data, a full trigger is returned.
Also, the digest should be returned with every "partial" update, and thus the client does not have to rely on CSeg numbers for data integrity (That is, even if the CSeq numbers are not sequential, the client may recognize that there's no need for full update, as in the case that it missed a sequence of changes to the same entity, and received only the last change of it).

----------------------------------------------------------------
Dror Tirosh <dror@vocaltec.com>
VocalTec Communications, Ltd
--------------------------------------------------------------




Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Sent by: simple-admin@mailman.dynamicsoft.com

05/09/2001 08:53

       
        To:        "'Avshalom Houri'" <avshalom@ubique.com>, simple@mailman.dynamicsoft.com
        cc:        
        Subject:        RE: [Simple] Partial Notifies?



> -----Original Message-----
> From: Avshalom Houri [mailto:avshalom@ubique.com]
> Sent: Friday, August 31, 2001 7:38 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Partial Notifies?
>
>
> [Sending from a different email due to mailing list DNS problems]
>
> Will it be possible to get partial updates to presence info?
> It is of course
> an optimization
I was actually debating this issue when doing the update of the presence
spec. Its not specified right now, all through the events framework allows
each package to define how its done.
One model to do this is something I have proposed for other packages:
1. the notify triggered by a subscribe contains the full state
2. subsequent notifies contain only the piece thats changed (i.e., the
contact address that is different)
3. the subscriber keeps track of the cseq to see if it may have missed a
notify. If there are no gaps in Cseq, nothing was missed. If there is a gap,
something may have been missed, or else there was an intermediate challenge
or something like that. So, the subscriber re-subscribes to get a triggered
notify with full state.
A better way to handle the ordering is for the presence document itself to
contain version numbers, but that would require changes in the pidf spec.
Since the initial SUBSCRIBE has to trigger full state anyway, idempotency of
SUBSCRIBE would argue for having full state triggered notify for refreshes
too.
-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

--=_alternative 002F817142256ABE_=-- From avshalom@ubique.com Wed Sep 5 06:34:27 2001 Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09455 for ; Wed, 5 Sep 2001 06:34:25 -0400 (EDT) Received: from avshalom (slip139-92-185-59.tel.il.ibm.net [139.92.185.59]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with SMTP id NAA02218 for ; Wed, 5 Sep 2001 13:37:06 +0300 (IDT) Message-ID: <001101c135fe$9f0ed800$3fbeef20@avshalom> From: "Avshalom Houri" To: Subject: RE: [Simple] Partial Notifies? Date: Wed, 5 Sep 2001 13:33:36 +0200 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 3438 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: > I was actually debating this issue when doing the update of the presence > spec. Its not specified right now, all through the events framework allows > each package to define how its done. I think that it should be included since NOTIFY can become big especially given detail/schema/human readable comment. > > One model to do this is something I have proposed for other packages: > > 1. the notify triggered by a subscribe contains the full state > 2. subsequent notifies contain only the piece thats changed (i.e., the > contact address that is different) > 3. the subscriber keeps track of the cseq to see if it may have missed a > notify. If there are no gaps in Cseq, nothing was missed. If there is a gap, > something may have been missed, or else there was an intermediate challenge > or something like that. So, the subscriber re-subscribes to get a triggered > notify with full state. I assume that the granularity will be a single tuple of the presence, and that there will be an operator preceding the tuple for add/delete/update. > > A better way to handle the ordering is for the presence document itself to > contain version numbers, but that would require changes in the pidf spec. > > Since the initial SUBSCRIBE has to trigger full state anyway, idempotency of > SUBSCRIBE would argue for having full state triggered notify for refreshes > too. It seems that Dror's suggestion (dror@vocaltec.com) can be helpful here. avshalom Sametime/Lotus/IBM Jonathan Rosenberg 05/09/2001 09:53 To: "'Avshalom Houri'" , simple@mailman.dynamicsoft.com cc: Subject: RE: [Simple] Partial Notifies? > -----Original Message----- > From: Avshalom Houri [mailto:avshalom@ubique.com] > Sent: Friday, August 31, 2001 7:38 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Partial Notifies? > > > [Sending from a different email due to mailing list DNS problems] > > Will it be possible to get partial updates to presence info? > It is of course > an optimization I was actually debating this issue when doing the update of the presence spec. Its not specified right now, all through the events framework allows each package to define how its done. One model to do this is something I have proposed for other packages: 1. the notify triggered by a subscribe contains the full state 2. subsequent notifies contain only the piece thats changed (i.e., the contact address that is different) 3. the subscriber keeps track of the cseq to see if it may have missed a notify. If there are no gaps in Cseq, nothing was missed. If there is a gap, something may have been missed, or else there was an intermediate challenge or something like that. So, the subscriber re-subscribes to get a triggered notify with full state. A better way to handle the ordering is for the presence document itself to contain version numbers, but that would require changes in the pidf spec. Since the initial SUBSCRIBE has to trigger full state anyway, idempotency of SUBSCRIBE would argue for having full state triggered notify for refreshes too. -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 From nsyracus@cnri.reston.va.us Wed Sep 5 06:49:32 2001 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 GAA09555 for ; Wed, 5 Sep 2001 06:49:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23089; Wed, 5 Sep 2001 06:47:17 -0400 (EDT) Message-Id: <200109051047.GAA23089@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 Date: Wed, 05 Sep 2001 06:47:17 -0400 Content-Length: 3007 Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-02.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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : SIP Extensions for Presence Author(s) : J. Rosenberg et al. Filename : draft-ietf-simple-presence-02.txt Pages : 36 Date : 04-Sep-01 This document proposes an extension to SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to 'on-line' and 'off-line' indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-presence-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presence-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010904141543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010904141543.I-D@ietf.org> --OtherAccess-- --NextPart-- From avshalom@ubique.com Wed Sep 5 07:04:18 2001 Received: from mailgw2.netvision.net.il (mailgw2.netvision.net.il [194.90.1.9]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09630 for ; Wed, 5 Sep 2001 07:04:17 -0400 (EDT) Received: from avshalom (slip139-92-185-59.tel.il.ibm.net [139.92.185.59]) by mailgw2.netvision.net.il (8.9.3/8.9.3) with SMTP id OAA14340 for ; Wed, 5 Sep 2001 14:06:57 +0300 (IDT) Message-ID: <002101c13602$ca622a30$3fbeef20@avshalom> From: "Avshalom Houri" To: Subject: Re: [Simple] Sessions of MESSAGEs Date: Wed, 5 Sep 2001 14:03:29 +0200 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 11150 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: I agree with Robert. Given the experience we had in implementing and deploying Sametime the concerns about firewalls are more then valid. I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE, given the detail/schema option and the human readable comment. We differ between NOTIFY and MESSAGE in that we allow a session of NOTIFYs (created by SUBSCRIBE) to be transferred over the same the control transport and not a session of MESSAGEs (created by INVITE). I think that we should define that the MESSAGE can be sent on the control transport as NOTIFY even when there is a session. We should also limit the size of the MESSAGE that can be sent and enable partial NOTIFYs as discussed in a separate tread. avshalom Sametime/Lotus/IBM "Robert Brown" Sent by: simple-admin@mailman.dynamicsoft.com 05/09/2001 04:51 To: "Jonathan Rosenberg" , "'David R. Oran'" , "'Patil Basavaraj \(NET/Dallas\)'" , , cc: Subject: Re: [Simple] Sessions of MESSAGEs Thanks for this detailed description. You're going to hate me, I'm sure :-), but I still think this is the wrong solution for IM. You're assuming "one/both or neither of the enterprises has deployed a nat and/or firewall, but is willing to affect static configuration changes to that firewall/nat to enable real time communications" and "it is feasible and acceptable to deploy elements within the enterprise that are application specific, to facilitate this application". But I don't think these are completely valid assumptions. I think it is flawed to assume all "real time communication" modes are equally complicated and should be solved in the same way. It is far easier to get cross-firewall IM (there are already many existing widespread implementations of this) than it is to get cross-firewall audio/video streams. IM is not "real time" in the same sense as audio and video: it tolerates considerable delays; it does not tolerate loss of information; it has extremely low bandwidth requirements. I just don't see the evidence that IM has much in common with RTP, and hence that an RTP solution is automatically the best solution for IM. The second flaw is to assume that IT departments will be willing to open port ranges. At most, an IT department will open a well-defined port for a specific purpose. E.g. 443 for HTTPS, 5061 for SIP/TLS. Hence mapping sessions to ports will not be deployable. You will need to map sessions to sockets. As you point out below, this is more difficult because it requires encoding at a higher layer. Thirdly, I don't think we should base something as fundamental as instant messaging on assumptions about what an acceptable generalized firewall traversal architecture may be. I don't want SIMPLE to make a design call based on whether something like your entfw-02 draft, or a MEGACO draft, or whatever, will be the firewall traversal solution. Fourthly, multiplexing multiple conversations on a single TCP session is a very valid requirement. Imagine you're a large IM service provider (such as MSN, AOL, Yahoo, and the various larger ISPs). You can expect quite a mesh between users of these services (assuming they want to open themselves to interop via SIMPLE). Hence probably millions of parallel TCP connections between a few data centers. I doubt that anybody who runs a data center wants to take this hit. And forget about making the TCP connections using TLS - how many cycles do you want to burn on session establishment? I can send a SIP MESSAGE request pretty easily. I've read nothing in any of these threads that convinces me that extending this innate SIP capability is a bad idea. If people are worried about swamping their proxies with IM, it's too late - you'll find SIP proxies will be far busier with SUBSCRIBE and NOTIFY than they ever will be with MESSAGE. Don't believe me? I have 62 buddies in my buddy list. That's 62 NOTIFYs each time my status changes. When I log on, I'm sending 62 SUBSCRIBEs, and receiving 62 NOTIFYs, and triggering 62 watcherinfo NOTIFYs to my buddies. Why not INVITE my buddies to a presence session, and define a separate protocol for transferring this presence information? ----- Original Message ----- From: "Jonathan Rosenberg" To: "'David R. Oran'" ; "'Robert Brown'" ; "'Patil Basavaraj (NET/Dallas)'" ; ; Sent: Thursday, August 30, 2001 9:01 AM Subject: RE: [Simple] Sessions of MESSAGEs > I accept as a requirement that the solution needs to support communications > between enterprises in the case where: > > 1. there is no public provider on the public Internet, > 2. one/both or neither of the enterprises has deployed a nat and/or > firewall, but is willing to affect static configuration changes to that > firewall/nat to enable real time communications, > 3. it is feasible and acceptable to deploy elements within the enterprise > that are application specific, to facilitate this application > > I think that, so long as a solution meets these requirements, Robert and the > others will be satisfied, right? My big beef is that I do not want the > solution to this to be IM specific, as the same issue arises with voice, > video, etc. Therefore, I would prefer a more generic solution. > > The generic solution is what we lovingly call a "B2BUAWM", which is a B2BUA > with Media (B2BUA is a SIP term, Back-to-back user agent). This is a > proxy-like kind of element which is call-stateful and capable of complete > manipulation of sip messages, initiation of sip messages, and so on. In this > case, it also handles the media. > > So, let us assume that IM is carried over some TCP oriented transport. The > configuration of interest is: > > Please view in a fixed-width font such as Courier. > > > > > NAT/FW > | \ > | \ > | \ > .....................\/ \/...................... > . ++ ++ . > . || || . > . || || . > . +-------+ || || +-------+ . > . | | || || | | . > . | S1 | || || | S2 | . > . | | || || | | . > . +-------+ ++ ++ +-------+ . > . . . . > . . . . > . . . . > . . . . > . //---\\ . . //---\\ . > . || UA A || . . || UA B || . > . \\---// . . \\---// . > . . . . > . Enterprise X . . Enterprise Y . > ....................... ....................... > > A wishes to talk to B. Both are in two enterprises, X and Y, which both > deploy a nat/fw. S1 and S2 are B2BUAWM. A sends an INVITE to establish an IM > session. It includes, within the SDP, the IP/port for incoming TCP > connections for its IM stream, say 10.0.1.1:9988. This INVITE goes to S1. S1 > rewrites the SDP, to rather include an IP/port of its own, which is a > publically routable one (as such, there must be cooperation of the fw/nat > admin to allow a single IP address of S1 to be visible to the outside). So, > the INVITE from S1 to S2 contains 64.22.1.2:8876 in the SDP. S1 remembers > the mapping {10.0.1.1:9988 <-> 64.22.1.2:8876}. This goes to S2. S2 does a > similar thing, placing a private internal address into the SDP in the > INVITE, 192.168.10.1:1234. This goes to UA B. In the 2xx in the reverse > direction, a similar set of rewrites can occur. > > For simplicities sake to facilitate discussion, lets assume that we are > using comedia, and arbitrarily have elected for A to act as the passive > side. B will attempt to open a TCP connection to the address it receive in > the INVITE (192.168.10.1:1234). This succeeeds. S2 is the server side of > this connection. It accepts it, and proceeds to open a connection to the > address bound to that (64.22.1.2:8876). This is S1. This connection > succeeds. S1 now opens a connection to the address mapped to that, > 10.0.1.1:9988, which goes to UA A. This succeeds. Now, either side can send > data. S2 and S1 do nothing more than bit shuffling across these TCP > connections. There is no message processing or anything, just pure bit > shuffling, which is very efficient. > > Now, the key thing is that whether the rewrite of the SDP is done in either > direction is a local matter. So, if enterprise X has no nat or firewall, S1 > is just a proxy. In that case, the TCP connection extends from S2 to UA A. > If neither sides have nats/firewalls, the TCP connection is direct from UA > A to UA B, as it should ideally be. Even if both sides deploy nat/fw, they > can elect to rewrite in one direction only (the incoming side) so that the > TCP connection only involves one of S1 or S2 (whether its S1 or S2 depends > on which TCP connection is ultimately chosen; draft-ietf-mmusic-comedia > discusses how this is done). > > Now, this little trick of rewiring SDP will also work for RTP, with the same > kind of bit shuffling going on. > > For security purposes, one can also specify the use of TLS instead of TCP on > some of the hops. > > Now, things are a bit more complex if one wishes to separate the SIP > component from the IM forwarding component. In that case, there needs to be > some kind of control relationship between the two. Certainly SIP can fill > that role, using third party call control (I will send a separate note with > the call flows). This would require a TCP enabled "IM conference server". > Another option is MGCP/megaco, but I am not sure if MGCP/megaco support TCP > or just UDP/RTP. Perhaps someone who knows can tell me. Midcom would be > another possibility, and would result in the fastest performance and lowest > cose. In that case, the "IM conference server thing" is actually another > nat. > > All of these things will work for IM and RTP, and the benefit of the session > model is that you reuse the solutions we are developing for RTP to support > IM as well. > > Now, there is one additional requirement that merits discussion. Oded, I > believe, asked that there be a single TCP connection between each > enterprise, and a single one between any UA and its proxy. In the proposal > above, there will be multiple connections. Thats because I am using the TCP > ports as a demux, so that forwarding decision for data is based on port > number alone. If you want shared TCP connections, thats a harder problem, > and will require demux at the higher layers. It is not clear whether the > additional message processing needed for each IM is more or less expensive > than multiple TCP connections. > > 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 sean.olson@ericsson.com Wed Sep 5 11:33:09 2001 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 LAA10519 for ; Wed, 5 Sep 2001 11:33:09 -0400 (EDT) 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 f85FX6525579 for ; Wed, 5 Sep 2001 10:33:07 -0500 (CDT) 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 f85FX6K04910 for ; Wed, 5 Sep 2001 10:33:06 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Sep 05 10:33:04 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Sep 2001 10:33:04 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Avshalom Houri'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Wed, 5 Sep 2001 10:33:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13620.0D743EE0" Content-Length: 5630 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: 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_01C13620.0D743EE0 Content-Type: text/plain; charset="iso-8859-1" >I agree with Robert. Given the experience we had in implementing and >deploying Sametime the concerns about firewalls are more then valid. > >I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE, >given the detail/schema option and the human readable comment. >We differ >between NOTIFY and MESSAGE in that we allow a session of >NOTIFYs (created by >SUBSCRIBE) to be transferred over the same the control >transport and not a >session of MESSAGEs (created by INVITE). Well, the NOTIFY is different than the INVITE case. For the INVITE case, the MESSAGE is the media. This is different from the NOTIFY case where the NOTIFY is signalling. > >I think that we should define that the MESSAGE can be sent on >the control >transport as NOTIFY even when there is a session. We should >also limit the >size of the MESSAGE that can be sent and enable partial >NOTIFYs as discussed >in a separate tread. Several comments on this: 1) The size of the MESSAGE should be as flexible as it is for any SIP Request. No special cases please. 2) The MESSAGE *can* be sent on the control transport. If you send a MESSAGE that has the same call leg information as a previously established call leg, then by default the MESSAGE will be routed on the same control transport (according to the Contact:/Record-Route: headers). Nothing special needed here. This is an alternative to the MESSAGE as media idea. Nest the messages within an INVITE or SUBSCRIBE session. 3) On the subject of partial NOTIFYs, what about a Last-Modified: header coupled with a "digest" sub-package? You could do a one-shot subscribe to the "digest" sub-package and receive a complete state update. Then subscribe to the base package and receive deltas. >avshalom >Sametime/Lotus/IBM Sean Olson Ericsson Inc. ------_=_NextPart_001_01C13620.0D743EE0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Sessions of MESSAGEs

>I agree with Robert. Given the experience we had in implementing and
>deploying Sametime the concerns about firewalls are more then valid.
>
>I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE,
>given the detail/schema option and the human readable comment.
>We differ
>between NOTIFY and MESSAGE in that we allow a session of
>NOTIFYs (created by
>SUBSCRIBE) to be transferred over the same the control
>transport and not a
>session of MESSAGEs (created by INVITE).

Well, the NOTIFY is different than the INVITE
case. For the INVITE case, the MESSAGE is the media.
This is different from the NOTIFY case where the NOTIFY
is signalling.

>
>I think that we should define that the MESSAGE can be sent on
>the control
>transport as NOTIFY even when there is a session. We should
>also limit the
>size of the MESSAGE that can be sent and enable partial
>NOTIFYs as discussed
>in a separate tread.

Several comments on this:

1) The size of the MESSAGE should be as flexible as
   it is for any SIP Request. No special cases please.

2) The MESSAGE *can* be sent on the control transport.
   If you send a MESSAGE that has the same call leg
   information as a previously established call leg,
   then by default the MESSAGE will be routed on the same
   control transport (according to the Contact:/Record-Route:
   headers). Nothing special needed here. This is an
   alternative to the MESSAGE as media idea. Nest the
   messages within an INVITE or SUBSCRIBE session.

3) On the subject of partial NOTIFYs, what about a
   Last-Modified: header coupled with a "digest"
   sub-package? You could do a one-shot subscribe to
   the "digest" sub-package and receive a complete
   state update. Then subscribe to the base package
   and receive deltas.

>avshalom
>Sametime/Lotus/IBM

Sean Olson
Ericsson Inc.

------_=_NextPart_001_01C13620.0D743EE0-- From roberbr@microsoft.com Wed Sep 5 16:42:23 2001 Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA11519 for ; Wed, 5 Sep 2001 16:42:22 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 05 Sep 2001 13:41:22 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Sep 2001 13:41:21 -0700 Received: from roberbr420xp ([172.31.77.52]) by red-msg-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Sep 2001 13:41:20 -0700 Message-ID: <001301c1364b$1ea3e870$344d1fac@redmond.corp.microsoft.com> From: "Robert Brown" To: "Avshalom Houri" , References: <001101c135fe$9f0ed800$3fbeef20@avshalom> Subject: Re: [Simple] Partial Notifies? Date: Wed, 5 Sep 2001 13:41:20 -0700 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 X-OriginalArrivalTime: 05 Sep 2001 20:41:20.0806 (UTC) FILETIME=[1EAB1460:01C1364B] Content-Length: 4164 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: Watcher info can become pretty big too. It would be nice to receive partials that only contained new pending watchers. ----- Original Message ----- From: "Avshalom Houri" To: Sent: Wednesday, September 05, 2001 4:33 AM Subject: RE: [Simple] Partial Notifies? > > I was actually debating this issue when doing the update of the presence > > > spec. Its not specified right now, all through the events framework allows > > > each package to define how its done. > > I think that it should be included since NOTIFY can become big especially > given > > detail/schema/human readable comment. > > > > > > One model to do this is something I have proposed for other packages: > > > > > > 1. the notify triggered by a subscribe contains the full state > > > 2. subsequent notifies contain only the piece thats changed (i.e., the > > > contact address that is different) > > > 3. the subscriber keeps track of the cseq to see if it may have missed a > > > notify. If there are no gaps in Cseq, nothing was missed. If there is a > gap, > > > something may have been missed, or else there was an intermediate > challenge > > > or something like that. So, the subscriber re-subscribes to get a > triggered > > > notify with full state. > > I assume that the granularity will be a single tuple of the presence, and > that > > there will be an operator preceding the tuple for add/delete/update. > > > > > > A better way to handle the ordering is for the presence document itself to > > > contain version numbers, but that would require changes in the pidf spec. > > > > > > Since the initial SUBSCRIBE has to trigger full state anyway, idempotency > of > > > SUBSCRIBE would argue for having full state triggered notify for refreshes > > > too. > > It seems that Dror's suggestion (dror@vocaltec.com) can be helpful here. > > avshalom > > Sametime/Lotus/IBM > > > > > > > > > > Jonathan Rosenberg > > 05/09/2001 09:53 > > To: "'Avshalom Houri'" , > simple@mailman.dynamicsoft.com > > cc: > > Subject: RE: [Simple] Partial Notifies? > > > > > > > > > > > -----Original Message----- > > > From: Avshalom Houri [mailto:avshalom@ubique.com] > > > Sent: Friday, August 31, 2001 7:38 AM > > > To: simple@mailman.dynamicsoft.com > > > Subject: [Simple] Partial Notifies? > > > > > > > > > [Sending from a different email due to mailing list DNS problems] > > > > > > Will it be possible to get partial updates to presence info? > > > It is of course > > > an optimization > > I was actually debating this issue when doing the update of the presence > > spec. Its not specified right now, all through the events framework allows > > each package to define how its done. > > One model to do this is something I have proposed for other packages: > > 1. the notify triggered by a subscribe contains the full state > > 2. subsequent notifies contain only the piece thats changed (i.e., the > > contact address that is different) > > 3. the subscriber keeps track of the cseq to see if it may have missed a > > notify. If there are no gaps in Cseq, nothing was missed. If there is a gap, > > something may have been missed, or else there was an intermediate challenge > > or something like that. So, the subscriber re-subscribes to get a triggered > > notify with full state. > > A better way to handle the ordering is for the presence document itself to > > contain version numbers, but that would require changes in the pidf spec. > > Since the initial SUBSCRIBE has to trigger full state anyway, idempotency of > > SUBSCRIBE would argue for having full state triggered notify for refreshes > > too. > > -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 avshalom@ubique.com Thu Sep 6 09:18:03 2001 Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14717 for ; Thu, 6 Sep 2001 09:18:01 -0400 (EDT) Received: from avshalom (slip139-92-208-219.tel.il.prserv.net [139.92.208.219]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with SMTP id QAA07614 for ; Thu, 6 Sep 2001 16:17:45 +0300 (IDT) Message-ID: <000b01c136de$9c4b8880$18cfef20@avshalom> From: "Avshalom Houri" To: Subject: RE: [Simple] Sessions of MESSAGEs Date: Thu, 6 Sep 2001 16:16:54 +0200 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 2936 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: I think that you touch the point of difference in this long thread, what is SIMPLE? Is it only an extension of SIP for IMPP which should support IMPP with the minimal contradictions to SIP nature or should it be a protocol that can support IMPP but in a way that is convenient to deploy and requires less servers and other elements for scalability. I also do not understand why a media of non-session MESSAGE is allowed on the control connection while the media of MESSAGEs in a session are prohibited. If MESSAGE is a media then go all the way. If not or a one-time MESSAGE was allowed since there was no other choice I do not see the harm in session of MESSAGEs. avshalom Sametime/Lotus/IBM "Sean Olson (EUS)" To: "'Avshalom Houri'" , cc: Subject: RE: [Simple] Sessions of MESSAGEs 05/09/2001 18:33 >I agree with Robert. Given the experience we had in implementing and >deploying Sametime the concerns about firewalls are more then valid. > >I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE, >given the detail/schema option and the human readable comment. >We differ >between NOTIFY and MESSAGE in that we allow a session of >NOTIFYs (created by >SUBSCRIBE) to be transferred over the same the control >transport and not a >session of MESSAGEs (created by INVITE). Well, the NOTIFY is different than the INVITE case. For the INVITE case, the MESSAGE is the media. This is different from the NOTIFY case where the NOTIFY is signalling. > >I think that we should define that the MESSAGE can be sent on >the control >transport as NOTIFY even when there is a session. We should >also limit the >size of the MESSAGE that can be sent and enable partial >NOTIFYs as discussed >in a separate tread. Several comments on this: 1) The size of the MESSAGE should be as flexible as it is for any SIP Request. No special cases please. 2) The MESSAGE *can* be sent on the control transport. If you send a MESSAGE that has the same call leg information as a previously established call leg, then by default the MESSAGE will be routed on the same control transport (according to the Contact:/Record-Route: headers). Nothing special needed here. This is an alternative to the MESSAGE as media idea. Nest the messages within an INVITE or SUBSCRIBE session. 3) On the subject of partial NOTIFYs, what about a Last-Modified: header coupled with a "digest" sub-package? You could do a one-shot subscribe to the "digest" sub-package and receive a complete state update. Then subscribe to the base package and receive deltas. >avshalom >Sametime/Lotus/IBM Sean Olson Ericsson Inc. From joshua@digitalknowledge.net Thu Sep 6 10:38:29 2001 Received: from granada.digitalknowledge.net ([204.1.2.114]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15012 for ; Thu, 6 Sep 2001 10:38:28 -0400 (EDT) Received: by granada.digitalknowledge.net with Internet Mail Service (5.5.2650.21) id ; Thu, 6 Sep 2001 09:42:27 -0500 Message-ID: From: wireless@digitalknowledge.net To: avshalom@ubique.com, simple@mailman.dynamicsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Thu, 6 Sep 2001 09:42:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2644 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: inline > -----Original Message----- > From: Avshalom Houri [mailto:avshalom@ubique.com] > Sent: Thursday, September 06, 2001 9:17 AM > To: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > I think that you touch the point of difference in this long > thread, what is > SIMPLE? Is it only an extension of SIP for IMPP which should > support IMPP > with the minimal contradictions to SIP nature or should it be > a protocol > that can support IMPP but in a way that is convenient to deploy and > requires less servers and other elements for scalability. yes it really hasn't changed much. It's still the same discussion: why not use SIP for message sessions that need to traverse the signal path. > > I also do not understand why a media of non-session MESSAGE > is allowed on > the control connection while the media of MESSAGEs in a session are > prohibited. If MESSAGE is a media then go all the way. If not > or a one-time > MESSAGE was allowed since there was no other choice I do not > see the harm > in session of MESSAGEs. I believe it's acceptable to allow one-off messages between the UA1 and UA2. Back on 8/24 JR postulated several technical reasons why it's okay. I completely agree that SIP is great for IM (based on my exp.), but when the messages start to use the signal path for back and forth sessions of messages, it seems futile to use SIP? The solution then is to go end2end, but this has draw backs in certain secure environments where perimeters have been configured. Perimeter establishment is most of the world, outside of carriers, like mobile phones, as they would like messages to go ME2ME. (ME is Mobile Equipment, fyi) However, if you are targeting Enterprise you want to go E2E in the enteprise, but outside the enterprise you may want to traversE the SIP PROXY SIGNALING or UA1 <-> proxyA <-> proxyB <-> UA2. This is where the problem sets in and begins the foundation for using SIP SIGNALING path for SESSIONS of messages. I believe you could argue that the sessions of messages should use the signal path when necessary, but e2e in other cases. So rather than defining a sepearate 'refractor/reflector' server you could target the sip signaling path, which ONE could arguably rationalize as 'signaling' and 'rendevous' setup. Although it is an IM specific solution. ON that same front, IM is a specific communications method outside of voice, email, data conferencing, video conferencing etc, where etc might be a telepathy rendevous mechanism (TRM). ;) (that's a joke, if those aren't allowed I'll refrain from using them in future list-posts) Joshua From pkyzivat@cisco.com Thu Sep 6 10:51:59 2001 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 KAA15072 for ; Thu, 6 Sep 2001 10:51:58 -0400 (EDT) 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 f86EpUe11430 for ; Thu, 6 Sep 2001 10:51:30 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAA09547 (AUTH pkyzivat); Thu, 6 Sep 2001 10:53:01 -0400 (EDT) Message-ID: <3B978D61.D7EFF640@cisco.com> Date: Thu, 06 Sep 2001 10:51:13 -0400 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: simple@mailman.dynamicsoft.com Subject: Re: [Simple] Sessions of MESSAGEs References: <000b01c136de$9c4b8880$18cfef20@avshalom> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1263 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: I am reserving judgement on the basic point of this thread - whether it is a good or bad thing to permit an IM session to be transported as a series of SIP MESSAGEs. But I would like to propose some basic groundrules that any proposed mechanism for IM sessions must follow: - An IM session must be initiated with a SIP INVITE transaction, using an SDP media description to request the IM session. - Like any other media session within a SIP call, it must be possible to add, drop, or redirect an IM session to a new destination through use of reINVITE, by exchanging revised SDP. I am trying to avoid a solution where IM is treated differently than other media, preventing reasonable management of multimedia calls. When I receive an INVITE, I should have the opportunity to accept or refuse any or all of the offered media by way of the SDP I return. If a proposal doesn't meet these groundrules, then I don't believe it belongs as a part of SIP. If it does, then of course it still must meet all the other concerns that have been raised in this thread. These groundrules are not a showstopper for using sessions of MESSAGEs - Jonathon at one point floated a proposal for m=message that would probably be adequate. Paul Kyzivat Cisco Systems From rsparks@dynamicsoft.com Thu Sep 6 14:09:41 2001 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 OAA15714 for ; Thu, 6 Sep 2001 14:09:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f86I8iCj020651; Thu, 6 Sep 2001 14:08:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Sep 2001 14:09:36 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E596@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" Cc: "'jon.peterson@nuestar.com'" , "'djrosen@dynamicsoft.com'" , =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= Date: Thu, 6 Sep 2001 14:09:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 320 Subject: [Simple] WG LAST CALL : draft-ietf-simple-presence-02 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: This is a SIMPLE Working Group Last Call for comments on draft-ietf-simple-presence-02.txt. This last call closes Friday September 21, 2001. Please post any final comments you have on this draft to this list by that date. The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-02.txt From roberbr@microsoft.com Thu Sep 6 14:11:23 2001 Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA15737 for ; Thu, 6 Sep 2001 14:11:22 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Sep 2001 11:10:16 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 6 Sep 2001 11:10:16 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Sessions of MESSAGEs Date: Thu, 6 Sep 2001 11:10:15 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320D26C@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs Thread-Index: AcE21wOq2amRVFUsT4qTY5mJkmzR1gAKBIZA From: "Robert Brown" To: "Avshalom Houri" , X-OriginalArrivalTime: 06 Sep 2001 18:10:16.0247 (UTC) FILETIME=[2E2EE470:01C136FF] Content-Length: 3575 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA15737 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: I agree - there is certainly an inconsistency in the treatment of MESSAGE. > -----Original Message----- > From: Avshalom Houri [mailto:avshalom@ubique.com] > Sent: Thursday, September 06, 2001 7:17 AM > To: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > I think that you touch the point of difference in this long thread, what > is > SIMPLE? Is it only an extension of SIP for IMPP which should support IMPP > with the minimal contradictions to SIP nature or should it be a protocol > that can support IMPP but in a way that is convenient to deploy and > requires less servers and other elements for scalability. > > I also do not understand why a media of non-session MESSAGE is allowed on > the control connection while the media of MESSAGEs in a session are > prohibited. If MESSAGE is a media then go all the way. If not or a one- > time > MESSAGE was allowed since there was no other choice I do not see the harm > in session of MESSAGEs. > > avshalom > Sametime/Lotus/IBM > > > > > "Sean Olson > (EUS)" To: "'Avshalom Houri'" > , > csson.com> cc: > Subject: RE: [Simple] > Sessions of MESSAGEs > 05/09/2001 > 18:33 > > > > > > >I agree with Robert. Given the experience we had in implementing and > >deploying Sametime the concerns about firewalls are more then valid. > > > >I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE, > >given the detail/schema option and the human readable comment. > >We differ > >between NOTIFY and MESSAGE in that we allow a session of > >NOTIFYs (created by > >SUBSCRIBE) to be transferred over the same the control > >transport and not a > >session of MESSAGEs (created by INVITE). > > > Well, the NOTIFY is different than the INVITE > case. For the INVITE case, the MESSAGE is the media. > This is different from the NOTIFY case where the NOTIFY > is signalling. > > > > > >I think that we should define that the MESSAGE can be sent on > >the control > >transport as NOTIFY even when there is a session. We should > >also limit the > >size of the MESSAGE that can be sent and enable partial > >NOTIFYs as discussed > >in a separate tread. > > > Several comments on this: > > > 1) The size of the MESSAGE should be as flexible as > it is for any SIP Request. No special cases please. > > > 2) The MESSAGE *can* be sent on the control transport. > If you send a MESSAGE that has the same call leg > information as a previously established call leg, > then by default the MESSAGE will be routed on the same > control transport (according to the Contact:/Record-Route: > headers). Nothing special needed here. This is an > alternative to the MESSAGE as media idea. Nest the > messages within an INVITE or SUBSCRIBE session. > > > 3) On the subject of partial NOTIFYs, what about a > Last-Modified: header coupled with a "digest" > sub-package? You could do a one-shot subscribe to > the "digest" sub-package and receive a complete > state update. Then subscribe to the base package > and receive deltas. > > > >avshalom > >Sametime/Lotus/IBM > > > Sean Olson > Ericsson Inc. > > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From roberbr@microsoft.com Thu Sep 6 14:15:41 2001 Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA15783 for ; Thu, 6 Sep 2001 14:15:41 -0400 (EDT) Received: from 157.54.9.100 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Sep 2001 11:14:31 -0700 Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 6 Sep 2001 11:14:24 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Sessions of MESSAGEs Date: Thu, 6 Sep 2001 11:14:22 -0700 Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320D26D@red-msg-05.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Sessions of MESSAGEs Thread-Index: AcE24f5KGDXbsQ3ERCC/YrZ1R5xk6AAHU0Og From: "Robert Brown" To: , , X-OriginalArrivalTime: 06 Sep 2001 18:14:24.0159 (UTC) FILETIME=[C1F342F0:01C136FF] Content-Length: 505 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA15783 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: > I completely agree that SIP is great for IM (based on my exp.), but when the > messages start to use the signal path for back and forth sessions of > messages, it seems futile to use SIP? > Joshua, I'm clear on how you drew the conclusion of futility here? > I believe you could argue that the sessions of messages should use the > signal path when necessary, but e2e in other cases. > Signaling can be e2e. There is no reason to use the same path as the INVITE unless a route has been recorded. From dean.willis@softarmor.com Fri Sep 7 01:54:43 2001 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 BAA17839 for ; Fri, 7 Sep 2001 01:54:42 -0400 (EDT) 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 f875tlD28562 for ; Fri, 7 Sep 2001 00:55:48 -0500 Message-ID: <009801c13761$37274380$55fa403f@blazer> From: "Dean Willis" To: References: <9BF66EBF6BEFD942915B4D4D45C051F338E596@DYN-TX-EXCH-001.dynamicsoft.com> Subject: Re: [Simple] WG LAST CALL : draft-ietf-simple-presence-02 Date: Fri, 7 Sep 2001 00:52:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Content-Length: 1412 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: I'm theoretically confused here. The draft descibes itself as as an :extension" to SIP using the events package defined therein. But it doesn't really extend SIP -- no new headers, no new messages, unless I REALLY missed something. It is rather a "usage" of SIP, the "definition" of a new "events package", (perhaps extending SIP-Events, not SIP), and a "framwwork" and "usage" document for implementing Presence and IM applications using SIP and SIP-Events. Besides, if it were a SIP extension, it would have to be in the SIP working group, right? Does that make any sense? -- Dean ----- Original Message ----- From: "Robert Sparks" To: Cc: ; ; "'Patrik Fältström'" Sent: Thursday, September 06, 2001 1:09 PM Subject: [Simple] WG LAST CALL : draft-ietf-simple-presence-02 > This is a SIMPLE Working Group Last Call for comments > on draft-ietf-simple-presence-02.txt. This last call > closes Friday September 21, 2001. Please post any > final comments you have on this draft to this list by > that date. > > The draft is available at > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-02.txt > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > From dean.willis@softarmor.com Fri Sep 7 02:00:35 2001 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 CAA17878 for ; Fri, 7 Sep 2001 02:00:35 -0400 (EDT) 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 f875xOD28577; Fri, 7 Sep 2001 00:59:25 -0500 Message-ID: <009e01c13761$b900fe50$55fa403f@blazer> From: "Dean Willis" To: "Robert Brown" , , , References: <8DC4B82A94A29D4AB708F05E0EB557AB0320D26D@red-msg-05.redmond.corp.microsoft.com> Subject: Re: [Simple] Sessions of MESSAGEs Date: Fri, 7 Sep 2001 00:55:38 -0500 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 Content-Length: 1203 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: Absolutely correct. There may, of course, be a reason to Record-Route, and "hiding" or "firewall proxies" generally do so. But in the absence of a Route header, signaling transactions after the initial INVITE sequence are end-to-end anyhow. -- Dean ----- Original Message ----- From: "Robert Brown" To: ; ; Sent: Thursday, September 06, 2001 1:14 PM Subject: RE: [Simple] Sessions of MESSAGEs > > > I completely agree that SIP is great for IM (based on my exp.), but > when the > > messages start to use the signal path for back and forth sessions of > > messages, it seems futile to use SIP? > > > > Joshua, I'm clear on how you drew the conclusion of futility here? > > > I believe you could argue that the sessions of messages should use the > > signal path when necessary, but e2e in other cases. > > > > Signaling can be e2e. There is no reason to use the same path as the > INVITE unless a route has been recorded. > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > > From jdrosen@dynamicsoft.com Fri Sep 7 11:23:20 2001 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 LAA19585 for ; Fri, 7 Sep 2001 11:23:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f87FMJCj027974; Fri, 7 Sep 2001 11:22:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 11:23:12 -0400 Message-ID: From: Jonathan Rosenberg To: "'Dean Willis'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] WG LAST CALL : draft-ietf-simple-presence-02 Date: Fri, 7 Sep 2001 11:21:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1003 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: > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, September 07, 2001 1:52 AM > To: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] WG LAST CALL : draft-ietf-simple-presence-02 > > > > I'm theoretically confused here. > > The draft descibes itself as as an :extension" to SIP using the events > package defined therein. > > But it doesn't really extend SIP -- no new headers, no new > messages, unless > I REALLY missed something. No, this is a good point. Its called "legacy verbiage" as this draft predates the common SUBSCRIBE/NOTIFY events framework. I'll remove 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 From sdonovan@dynamicsoft.com Fri Sep 7 11:41:48 2001 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 LAA19709 for ; Fri, 7 Sep 2001 11:41:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f87FerCj028225; Fri, 7 Sep 2001 11:40:54 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 11:41:47 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3371EF6@DYN-TX-EXCH-001.dynamicsoft.com> From: Steve Donovan To: "Sipping (E-mail)" , "Simple (E-mail)" Date: Fri, 7 Sep 2001 11:41:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C137B3.9933B160" Content-Length: 4838 Subject: [Simple] FW: I-D ACTION:draft-donovan-publish-requirements-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: 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_01C137B3.9933B160 Content-Type: text/plain; charset="iso-8859-1" This is a heads up on a recently published draft. This draft is an attempt to capture the requirements for a proposed extension the SIP protocol. This extension would formalize a publish or data upload method for SIP related data. This extension would be used for uploading CPL scripts, for publishing presence documents or for clients to send other SIP service related data to a SIP server. While this work directly impacts the SIMPLE working group (which is why I included the SIMPLE mailing list on this message), I believe that this is a general purpose discussion. As such, I would suggest that the discussion occur on the SIPPING mailing list. If you respond to this email, please removing the SIMPLE working group email address before doing so. Regards, Steve --- Steven R. Donovan Architect dynamicsoft mailto:sdonovan@dynamicsoft.com 5100 Tennyson Parkway sip:sdonovan@sip.dynamicsoft.com Plano, Texas 75025 tel:+1-972-473-5469 http://www.dynamicsoft.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, September 07, 2001 5:49 AM Subject: I-D ACTION:draft-donovan-publish-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Publication of SIP related service data Author(s) : S. Donovan Filename : draft-donovan-publish-requirements-00.txt Pages : 8 Date : 06-Sep-01 This document defines the requirements for a proposed extension to the Session Initiation Protocol [1]. This extension would provide a general-purpose mechanism for uploading service related data. For instance, there is currently the need to upload or publish CPL to SIP Proxies and presence documents to SIP Presence Servers. This document does NOT outline an extension to SIP to handle these requirements. The author is attempting to follow the guidelines that requirements should be defined and agreed to before work on the an extension begins. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-donovan-publish-requirements-00.tx t 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-donovan-publish-requirements-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-donovan-publish-requirements-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_01C137B3.9933B160 Content-Type: message/rfc822 To: Subject: Date: Fri, 7 Sep 2001 11:41:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C137B3.9933B160" ------_=_NextPart_002_01C137B3.9933B160 Content-Type: text/plain ------_=_NextPart_002_01C137B3.9933B160 Content-Type: application/octet-stream; name="ATT14603.txt" Content-Disposition: attachment; filename="ATT14603.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010906141706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-donovan-publish-requirements-00.txt ------_=_NextPart_002_01C137B3.9933B160 Content-Type: message/external-body; site="internet-drafts"; dir="draft-donovan-publish-requirements-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C137B3.9933B160-- ------_=_NextPart_000_01C137B3.9933B160-- From joshua@digitalknowledge.net Fri Sep 7 12:57:58 2001 Received: from granada.digitalknowledge.net (cdm-208-120-249-geor.cox-internet.com [208.180.120.249]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20003 for ; Fri, 7 Sep 2001 12:57:57 -0400 (EDT) Received: by granada.digitalknowledge.net with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Sep 2001 12:02:10 -0500 Message-ID: From: SpatialLocation@digitalknowledge.net To: simple@mailman.dynamicsoft.com Cc: roberbr@microsoft.com, avshalom@ubique.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Fri, 7 Sep 2001 12:02:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 2121 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: > -----Original Message----- > From: Robert Brown [mailto:roberbr@microsoft.com] > Sent: Thursday, September 06, 2001 1:14 PM > To: wireless; avshalom@ubique.com; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Sessions of MESSAGEs > > > > > I completely agree that SIP is great for IM (based on my exp.), but > when the > > messages start to use the signal path for back and forth sessions of > > messages, it seems futile to use SIP? > > > > Joshua, I'm clear on how you drew the conclusion of futility here? I didn't. :) I ended my sentance with a question mark. My point is, there are critical similarities that make SIP for IM sessions of MESSAGEs between perimiter networks viable and usuable. > > > I believe you could argue that the sessions of messages > should use the > > signal path when necessary, but e2e in other cases. > > > > Signaling can be e2e. There is no reason to use the same path as the > INVITE unless a route has been recorded. Okay - this I understand. The SIP PROXY works great, but what do you do when the UA1 lives behind a NAT/router and UA2 lives behind a NAT/router with both communicating with different SIP proxies (nwtraders and contoso, fictional) and the proxies exist outside the NAT/router. How does the SIP singaling path fix that problem? I really liked dean's point a few days ago about when to look at using e2e vs. proxying. > all apply to messaging. This include firewall traversal, > retransmission > delegation, network validation of identity, privacy > mechanisms, gateways > between administrative domains, and so on. So does one say, well if your behind a NAT it "just doesn't work for your client to offer services like RTCP". Esentially, does one really want to spend time defining a standard for backwards compatiblity with IPV4/NAT regarding a forward thinking solution like converged IP services vs just saying the newer technology will require e2e/IPv6 for ubiquitous support? I.E., Linksys is adding support for MSN/XP file transfer (along with basic firewall) this month and they will follow up with better SIP support. Joshua From hgs@cs.columbia.edu Fri Sep 7 15:54:12 2001 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20558 for ; Fri, 7 Sep 2001 15:54:11 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA17705 for ; Fri, 7 Sep 2001 15:54:07 -0400 (EDT) Message-ID: <3B9925DF.E612F684@cs.columbia.edu> Date: Fri, 07 Sep 2001 15:54:07 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 959 Subject: [Simple] MESSAGE session 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: While the use of MESSAGE-based sessions over UDP is 'out', I wonder whether this also implies that MESSAGE over TCP is unacceptable. It seems to satisfy the minimum requirements for any mechanism: + congestion and flow control + no size limitation for bodies + each message must allow a different content type + support of multipart MIME bodies for easy gatewaying to email, among other reasons + allow use of TLS (or similar) for security * if possible, avoid yet more parsers * extensible, i.e., allow additional labeling through headers (useful for various gateways) * possibly make use of existing compression mechanisms * allow multiplexing, i.e., re-use one "pipe" for multiple sessions (this simplifies various mixing functions, for example) (+ are, in my view, must-haves, while * are nice-to-have) I'm way backlogged on email, so my apologies if this has been discussed to death. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From zane@mabry.com Fri Sep 7 16:08:29 2001 Received: from mailnw.centurytel.net (mailnw.centurytel.net [209.206.160.237]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20636 for ; Fri, 7 Sep 2001 16:08:29 -0400 (EDT) Received: from toophat (dsl-209-206-250-63.rb.gh.centurytel.net [209.206.250.63]) by mailnw.centurytel.net (8.11.6/8.11.6) with ESMTP id f87K87719927 for ; Fri, 7 Sep 2001 13:08:07 -0700 (PDT) Message-ID: <01f101c137d9$66975830$47dcfea9@toophat> From: "Zane Thomas" To: References: <3B9925DF.E612F684@cs.columbia.edu> Subject: Re: [Simple] MESSAGE session Date: Fri, 7 Sep 2001 13:12:20 -0700 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Length: 529 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: > While the use of MESSAGE-based sessions over UDP is 'out', I wonder > whether this also implies that MESSAGE over TCP is unacceptable. It > seems to satisfy the minimum requirements for any mechanism: Fyi, I'm finding beep (www.beepcore.org) to be an interesting transport protocol. My hypothetical (at this time) scenario has me locating users with sip and establishing a beep session. Beep supports multiple logical channels over a single tcp connection, ssl, and can easily be proxied in a many-to-many fashion. Zane From petkos@cs.columbia.edu Fri Sep 7 17:26:00 2001 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 RAA20930 for ; Fri, 7 Sep 2001 17:25:59 -0400 (EDT) Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA27724 for ; Fri, 7 Sep 2001 17:25:47 -0400 (EDT) Received: (from petkos@localhost) by disco.cs.columbia.edu (8.9.3/8.9.3) id RAA22066; Fri, 7 Sep 2001 17:25:46 -0400 (EDT) From: "Petri K. Koskelainen" Message-Id: <200109072125.RAA22066@disco.cs.columbia.edu> To: simple@mailman.dynamicsoft.com Date: Fri, 7 Sep 2001 17:25:46 -0400 (EDT) Cc: hgs@cs.columbia.edu X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1635 Subject: [Simple] Re: MESSAGE 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: This is a good idea. Only problem which is not solved by TCP is the message overhead (unnecessary SIP headers inside a session). However, there must be some kind of payload headers anyway (at least the Content-Type, Content-Lenght) so the difference between SIP and whatever new format is not that big. Moreover, in low-speed links such as wireless there will be compression anyway so message overhead is not an issue. Therefore it would make a lot of sense to finalize the MESSAGE sessions draft asap with "TCP-only" label. Other media formats may be defined in addition to MESSAGE sessions, but it would be great to have this finalized asap. Petri ----------- While the use of MESSAGE-based sessions over UDP is 'out', I wonder whether this also implies that MESSAGE over TCP is unacceptable. It seems to satisfy the minimum requirements for any mechanism: + congestion and flow control + no size limitation for bodies + each message must allow a different content type + support of multipart MIME bodies for easy gatewaying to email, among other reasons + allow use of TLS (or similar) for security * if possible, avoid yet more parsers * extensible, i.e., allow additional labeling through headers (useful for various gateways) * possibly make use of existing compression mechanisms * allow multiplexing, i.e., re-use one "pipe" for multiple sessions (this simplifies various mixing functions, for example) (+ are, in my view, must-haves, while * are nice-to-have) I'm way backlogged on email, so my apologies if this has been discussed to death. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From HUITEMA@windows.microsoft.com Fri Sep 7 18:55:08 2001 Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA21236 for ; Fri, 7 Sep 2001 18:55:05 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 15:54:26 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 15:54:26 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 15:54:25 -0700 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(5.0.2195.2966); Fri, 7 Sep 2001 15:53:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Simple] Re: MESSAGE sessions Date: Fri, 7 Sep 2001 15:53:54 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Re: MESSAGE sessions Thread-Index: AcE35RGQSHTYg/0XS8GxKkg+L8eH/AACs0kg From: "Christian Huitema" To: "Petri K. Koskelainen" , Cc: X-OriginalArrivalTime: 07 Sep 2001 22:53:54.0465 (UTC) FILETIME=[F83EA110:01C137EF] Content-Length: 2306 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA21236 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: In fact, you need the equivalent of the SIP header anyhow; they are needed if you want to write a proxy, and they are handy if you are doing a multi-party chat. > -----Original Message----- > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu] > Sent: Friday, September 07, 2001 2:26 PM > To: simple@mailman.dynamicsoft.com > Cc: hgs@cs.columbia.edu > Subject: [Simple] Re: MESSAGE sessions > > > This is a good idea. > Only problem which is not solved by TCP > is the message overhead (unnecessary SIP > headers inside a session). > > However, there must be some kind of payload > headers anyway (at least the Content-Type, Content-Lenght) > so the difference between SIP and whatever > new format is not that big. > Moreover, in low-speed links such as wireless > there will be compression anyway so message > overhead is not an issue. > > Therefore it would make a lot of sense to > finalize the MESSAGE sessions draft asap > with "TCP-only" label. > Other media formats may be defined > in addition to MESSAGE sessions, > but it would be great to have this finalized > asap. > > Petri > > > > ----------- > > While the use of MESSAGE-based sessions over UDP is 'out', I wonder > whether this also implies that MESSAGE over TCP is unacceptable. It > seems to satisfy the minimum requirements for any mechanism: > > + congestion and flow control > + no size limitation for bodies > + each message must allow a different content type > + support of multipart MIME bodies > for easy gatewaying to email, among other reasons > + allow use of TLS (or similar) for security > * if possible, avoid yet more parsers > * extensible, i.e., allow additional labeling through > headers (useful for various gateways) > * possibly make use of existing compression mechanisms > * allow multiplexing, i.e., re-use one "pipe" for multiple > sessions (this simplifies various mixing functions, for example) > > (+ are, in my view, must-haves, while * are nice-to-have) > > I'm way backlogged on email, so my apologies if this has been > discussed > to death. > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From Avshalom@ubique.com Sun Sep 9 05:33:36 2001 Received: from ubqgate02.lotus.com ([194.196.39.99]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27771; Sun, 9 Sep 2001 05:33:34 -0400 (EDT) From: Avshalom@ubique.com Subject: Re: [Simple] Sessions of MESSAGEs To: "Robert Brown" Cc: "'Patil Basavaraj \(NET/Dallas\)'" , "Jonathan Rosenberg" , "'David R. Oran'" , simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 5 Sep 2001 11:33:31 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 09/09/2001 12:32:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 12973 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: I agree with Robert. Given the experience we had in implementing and deploying Sametime the concerns about firewalls are more then valid. I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE, given the detail/schema option and the human readable comment. We differ between NOTIFY and MESSAGE in that we allow a session of NOTIFYs (created by SUBSCRIBE) to be transferred over the same the control transport and not a session of MESSAGEs (created by INVITE). I think that we should define that the MESSAGE can be sent on the control transport as NOTIFY even when there is a session. We should also limit the size of the MESSAGE that can be sent and enable partial NOTIFYs as discussed in a separate tread. avshalom Sametime/Lotus/IBM "Robert Brown" To: "Jonathan Rosenberg" , "'David R. Oran'" Sent by: , "'Patil Basavaraj \(NET/Dallas\)'" simple-admin@mailman.dynam , , icsoft.com cc: Subject: Re: [Simple] Sessions of MESSAGEs 05/09/2001 04:51 Thanks for this detailed description. You're going to hate me, I'm sure :-), but I still think this is the wrong solution for IM. You're assuming "one/both or neither of the enterprises has deployed a nat and/or firewall, but is willing to affect static configuration changes to that firewall/nat to enable real time communications" and "it is feasible and acceptable to deploy elements within the enterprise that are application specific, to facilitate this application". But I don't think these are completely valid assumptions. I think it is flawed to assume all "real time communication" modes are equally complicated and should be solved in the same way. It is far easier to get cross-firewall IM (there are already many existing widespread implementations of this) than it is to get cross-firewall audio/video streams. IM is not "real time" in the same sense as audio and video: it tolerates considerable delays; it does not tolerate loss of information; it has extremely low bandwidth requirements. I just don't see the evidence that IM has much in common with RTP, and hence that an RTP solution is automatically the best solution for IM. The second flaw is to assume that IT departments will be willing to open port ranges. At most, an IT department will open a well-defined port for a specific purpose. E.g. 443 for HTTPS, 5061 for SIP/TLS. Hence mapping sessions to ports will not be deployable. You will need to map sessions to sockets. As you point out below, this is more difficult because it requires encoding at a higher layer. Thirdly, I don't think we should base something as fundamental as instant messaging on assumptions about what an acceptable generalized firewall traversal architecture may be. I don't want SIMPLE to make a design call based on whether something like your entfw-02 draft, or a MEGACO draft, or whatever, will be the firewall traversal solution. Fourthly, multiplexing multiple conversations on a single TCP session is a very valid requirement. Imagine you're a large IM service provider (such as MSN, AOL, Yahoo, and the various larger ISPs). You can expect quite a mesh between users of these services (assuming they want to open themselves to interop via SIMPLE). Hence probably millions of parallel TCP connections between a few data centers. I doubt that anybody who runs a data center wants to take this hit. And forget about making the TCP connections using TLS - how many cycles do you want to burn on session establishment? I can send a SIP MESSAGE request pretty easily. I've read nothing in any of these threads that convinces me that extending this innate SIP capability is a bad idea. If people are worried about swamping their proxies with IM, it's too late - you'll find SIP proxies will be far busier with SUBSCRIBE and NOTIFY than they ever will be with MESSAGE. Don't believe me? I have 62 buddies in my buddy list. That's 62 NOTIFYs each time my status changes. When I log on, I'm sending 62 SUBSCRIBEs, and receiving 62 NOTIFYs, and triggering 62 watcherinfo NOTIFYs to my buddies. Why not INVITE my buddies to a presence session, and define a separate protocol for transferring this presence information? ----- Original Message ----- From: "Jonathan Rosenberg" To: "'David R. Oran'" ; "'Robert Brown'" ; "'Patil Basavaraj (NET/Dallas)'" ; ; Sent: Thursday, August 30, 2001 9:01 AM Subject: RE: [Simple] Sessions of MESSAGEs > I accept as a requirement that the solution needs to support communications > between enterprises in the case where: > > 1. there is no public provider on the public Internet, > 2. one/both or neither of the enterprises has deployed a nat and/or > firewall, but is willing to affect static configuration changes to that > firewall/nat to enable real time communications, > 3. it is feasible and acceptable to deploy elements within the enterprise > that are application specific, to facilitate this application > > I think that, so long as a solution meets these requirements, Robert and the > others will be satisfied, right? My big beef is that I do not want the > solution to this to be IM specific, as the same issue arises with voice, > video, etc. Therefore, I would prefer a more generic solution. > > The generic solution is what we lovingly call a "B2BUAWM", which is a B2BUA > with Media (B2BUA is a SIP term, Back-to-back user agent). This is a > proxy-like kind of element which is call-stateful and capable of complete > manipulation of sip messages, initiation of sip messages, and so on. In this > case, it also handles the media. > > So, let us assume that IM is carried over some TCP oriented transport. The > configuration of interest is: > > Please view in a fixed-width font such as Courier. > > > > > NAT/FW > | \ > | \ > | \ > .....................\/ \/...................... > . ++ ++ . > . || || . > . || || . > . +-------+ || || +-------+ . > . | | || || | | . > . | S1 | || || | S2 | . > . | | || || | | . > . +-------+ ++ ++ +-------+ . > . . . . > . . . . > . . . . > . . . . > . //---\\ . . //---\\ . > . || UA A || . . || UA B || . > . \\---// . . \\---// . > . . . . > . Enterprise X . . Enterprise Y . > ....................... ....................... > > A wishes to talk to B. Both are in two enterprises, X and Y, which both > deploy a nat/fw. S1 and S2 are B2BUAWM. A sends an INVITE to establish an IM > session. It includes, within the SDP, the IP/port for incoming TCP > connections for its IM stream, say 10.0.1.1:9988. This INVITE goes to S1. S1 > rewrites the SDP, to rather include an IP/port of its own, which is a > publically routable one (as such, there must be cooperation of the fw/nat > admin to allow a single IP address of S1 to be visible to the outside). So, > the INVITE from S1 to S2 contains 64.22.1.2:8876 in the SDP. S1 remembers > the mapping {10.0.1.1:9988 <-> 64.22.1.2:8876}. This goes to S2. S2 does a > similar thing, placing a private internal address into the SDP in the > INVITE, 192.168.10.1:1234. This goes to UA B. In the 2xx in the reverse > direction, a similar set of rewrites can occur. > > For simplicities sake to facilitate discussion, lets assume that we are > using comedia, and arbitrarily have elected for A to act as the passive > side. B will attempt to open a TCP connection to the address it receive in > the INVITE (192.168.10.1:1234). This succeeeds. S2 is the server side of > this connection. It accepts it, and proceeds to open a connection to the > address bound to that (64.22.1.2:8876). This is S1. This connection > succeeds. S1 now opens a connection to the address mapped to that, > 10.0.1.1:9988, which goes to UA A. This succeeds. Now, either side can send > data. S2 and S1 do nothing more than bit shuffling across these TCP > connections. There is no message processing or anything, just pure bit > shuffling, which is very efficient. > > Now, the key thing is that whether the rewrite of the SDP is done in either > direction is a local matter. So, if enterprise X has no nat or firewall, S1 > is just a proxy. In that case, the TCP connection extends from S2 to UA A. > If neither sides have nats/firewalls, the TCP connection is direct from UA > A to UA B, as it should ideally be. Even if both sides deploy nat/fw, they > can elect to rewrite in one direction only (the incoming side) so that the > TCP connection only involves one of S1 or S2 (whether its S1 or S2 depends > on which TCP connection is ultimately chosen; draft-ietf-mmusic-comedia > discusses how this is done). > > Now, this little trick of rewiring SDP will also work for RTP, with the same > kind of bit shuffling going on. > > For security purposes, one can also specify the use of TLS instead of TCP on > some of the hops. > > Now, things are a bit more complex if one wishes to separate the SIP > component from the IM forwarding component. In that case, there needs to be > some kind of control relationship between the two. Certainly SIP can fill > that role, using third party call control (I will send a separate note with > the call flows). This would require a TCP enabled "IM conference server". > Another option is MGCP/megaco, but I am not sure if MGCP/megaco support TCP > or just UDP/RTP. Perhaps someone who knows can tell me. Midcom would be > another possibility, and would result in the fastest performance and lowest > cose. In that case, the "IM conference server thing" is actually another > nat. > > All of these things will work for IM and RTP, and the benefit of the session > model is that you reuse the solutions we are developing for RTP to support > IM as well. > > Now, there is one additional requirement that merits discussion. Oded, I > believe, asked that there be a single TCP connection between each > enterprise, and a single one between any UA and its proxy. In the proposal > above, there will be multiple connections. Thats because I am using the TCP > ports as a demux, so that forwarding decision for data is based on port > number alone. If you want shared TCP connections, thats a harder problem, > and will require demux at the higher layers. It is not clear whether the > additional message processing needed for each IM is more or less expensive > than multiple TCP connections. > > 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 Avshalom@ubique.com Sun Sep 9 05:33:39 2001 Received: from ubqgate02.lotus.com ([194.196.39.99]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27775 for ; Sun, 9 Sep 2001 05:33:37 -0400 (EDT) From: Avshalom@ubique.com Subject: RE: [Simple] Partial Notifies? To: simple@mailman.dynamicsoft.com, Jonathan Rosenberg Cc: dror@vocaltec.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Wed, 5 Sep 2001 13:14:55 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 09/09/2001 12:32:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 4462 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: > I was actually debating this issue when doing the update of the presence > spec. Its not specified right now, all through the events framework allows > each package to define how its done. I think that it should be included since NOTIFY can become big especially given detail/schema/human readable comment. > > One model to do this is something I have proposed for other packages: > > 1. the notify triggered by a subscribe contains the full state > 2. subsequent notifies contain only the piece thats changed (i.e., the > contact address that is different) > 3. the subscriber keeps track of the cseq to see if it may have missed a > notify. If there are no gaps in Cseq, nothing was missed. If there is a gap, > something may have been missed, or else there was an intermediate challenge > or something like that. So, the subscriber re-subscribes to get a triggered > notify with full state. I assume that the granularity will be a single tuple of the presence, and that there will be an operator preceding the tuple for add/delete/update. > > A better way to handle the ordering is for the presence document itself to > contain version numbers, but that would require changes in the pidf spec. > > Since the initial SUBSCRIBE has to trigger full state anyway, idempotency of > SUBSCRIBE would argue for having full state triggered notify for refreshes > too. It seems that Dror's suggestion (dror@vocaltec.com) can be helpful here. avshalom Sametime/Lotus/IBM Jonathan Rosenberg To: "'Avshalom Houri'" , cc: Subject: RE: [Simple] Partial Notifies? 05/09/2001 09:53 > -----Original Message----- > From: Avshalom Houri [mailto:avshalom@ubique.com] > Sent: Friday, August 31, 2001 7:38 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Partial Notifies? > > > [Sending from a different email due to mailing list DNS problems] > > Will it be possible to get partial updates to presence info? > It is of course > an optimization I was actually debating this issue when doing the update of the presence spec. Its not specified right now, all through the events framework allows each package to define how its done. One model to do this is something I have proposed for other packages: 1. the notify triggered by a subscribe contains the full state 2. subsequent notifies contain only the piece thats changed (i.e., the contact address that is different) 3. the subscriber keeps track of the cseq to see if it may have missed a notify. If there are no gaps in Cseq, nothing was missed. If there is a gap, something may have been missed, or else there was an intermediate challenge or something like that. So, the subscriber re-subscribes to get a triggered notify with full state. A better way to handle the ordering is for the presence document itself to contain version numbers, but that would require changes in the pidf spec. Since the initial SUBSCRIBE has to trigger full state anyway, idempotency of SUBSCRIBE would argue for having full state triggered notify for refreshes too. -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 From Avshalom@ubique.com Sun Sep 9 05:33:42 2001 Received: from ubqgate02.lotus.com ([194.196.39.99]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27781 for ; Sun, 9 Sep 2001 05:33:40 -0400 (EDT) From: Avshalom@ubique.com Subject: RE: [Simple] Sessions of MESSAGEs To: "Sean Olson (EUS)" , simple@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 6 Sep 2001 15:51:32 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 09/09/2001 12:32:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Length: 3724 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: I think that you touch the point of difference in this long thread, what is SIMPLE? Is it only an extension of SIP for IMPP which should support IMPP with the minimal contradictions to SIP nature or should it be a protocol that can support IMPP but in a way that is convenient to deploy and requires less servers and other elements for scalability. I also do not understand why a media of non-session MESSAGE is allowed on the control connection while the media of MESSAGEs in a session are prohibited. If MESSAGE is a media then go all the way. If not or a one-time MESSAGE was allowed since there was no other choice I do not see the harm in session of MESSAGEs. avshalom Sametime/Lotus/IBM "Sean Olson (EUS)" To: "'Avshalom Houri'" , cc: Subject: RE: [Simple] Sessions of MESSAGEs 05/09/2001 18:33 >I agree with Robert. Given the experience we had in implementing and >deploying Sametime the concerns about firewalls are more then valid. > >I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE, >given the detail/schema option and the human readable comment. >We differ >between NOTIFY and MESSAGE in that we allow a session of >NOTIFYs (created by >SUBSCRIBE) to be transferred over the same the control >transport and not a >session of MESSAGEs (created by INVITE). Well, the NOTIFY is different than the INVITE case. For the INVITE case, the MESSAGE is the media. This is different from the NOTIFY case where the NOTIFY is signalling. > >I think that we should define that the MESSAGE can be sent on >the control >transport as NOTIFY even when there is a session. We should >also limit the >size of the MESSAGE that can be sent and enable partial >NOTIFYs as discussed >in a separate tread. Several comments on this: 1) The size of the MESSAGE should be as flexible as it is for any SIP Request. No special cases please. 2) The MESSAGE *can* be sent on the control transport. If you send a MESSAGE that has the same call leg information as a previously established call leg, then by default the MESSAGE will be routed on the same control transport (according to the Contact:/Record-Route: headers). Nothing special needed here. This is an alternative to the MESSAGE as media idea. Nest the messages within an INVITE or SUBSCRIBE session. 3) On the subject of partial NOTIFYs, what about a Last-Modified: header coupled with a "digest" sub-package? You could do a one-shot subscribe to the "digest" sub-package and receive a complete state update. Then subscribe to the base package and receive deltas. >avshalom >Sametime/Lotus/IBM Sean Olson Ericsson Inc. From oran@cisco.com Mon Sep 10 08:51:14 2001 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01124 for ; Mon, 10 Sep 2001 08:51:13 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f8ACpSv24996; Mon, 10 Sep 2001 05:51:28 -0700 (PDT) Received: from oranlt ([161.44.238.36]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id AAX90957; Mon, 10 Sep 2001 05:51:04 -0700 (PDT) From: "David R. Oran" To: "'Henning G. Schulzrinne'" , Subject: RE: [Simple] MESSAGE session Date: Mon, 10 Sep 2001 08:57:10 -0400 Organization: Cisco Systems Message-ID: <019f01c139f8$1b3475a0$24ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2542.0000 In-Reply-To: <3B9925DF.E612F684@cs.columbia.edu> Content-Length: 1877 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: > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of > Henning G. Schulzrinne > Sent: Friday, September 07, 2001 3:54 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] MESSAGE session > > > While the use of MESSAGE-based sessions over UDP is 'out', I > wonder whether this also implies that MESSAGE over TCP is > unacceptable. It seems to satisfy the minimum requirements > for any mechanism: > > + congestion and flow control > + no size limitation for bodies > + each message must allow a different content type > + support of multipart MIME bodies > for easy gatewaying to email, among other reasons > + allow use of TLS (or similar) for security > * if possible, avoid yet more parsers > * extensible, i.e., allow additional labeling through > headers (useful for various gateways) > * possibly make use of existing compression mechanisms > * allow multiplexing, i.e., re-use one "pipe" for multiple > sessions (this simplifies various mixing functions, for example) > > (+ are, in my view, must-haves, while * are nice-to-have) > Yes, it does. At first blush CPIM-over-TCP would seem to have the same properties and avoids a bunch of gatewaying issues, assuming SIMPLE endpoints would need a CPIM parser anyway. I'm not sure I would consider your last bullet about multiplexing an advantage as I'm usually a skeptic about application-specific TCP multiplexing schemes. If you really need this SCTP would seem an attractive alternative. > I'm way backlogged on email, so my apologies if this has been > discussed to death. > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinf> o/simple > From hgs@cs.columbia.edu Mon Sep 10 08:57:02 2001 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 IAA01155 for ; Mon, 10 Sep 2001 08:57:02 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA20020; Mon, 10 Sep 2001 08:56:55 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id IAA24522; Mon, 10 Sep 2001 08:56:54 -0400 (EDT) Message-ID: <3B9CB828.C0830343@cs.columbia.edu> Date: Mon, 10 Sep 2001 08:55:04 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "David R. Oran" CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] MESSAGE session References: <019f01c139f8$1b3475a0$24ee2ca1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 920 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: > At first blush CPIM-over-TCP would seem to have the same properties and > avoids a bunch of gatewaying issues, assuming SIMPLE endpoints would > need a CPIM parser anyway. Is this a real format as opposed to a meta or abstract format? The value depends also on the likelihood that we will be seeing large amounts of gatewaying to BEEP or PRIM. I have my doubts. > > I'm not sure I would consider your last bullet about multiplexing an > advantage as I'm usually a skeptic about application-specific TCP > multiplexing schemes. If you really need this SCTP would seem an > attractive alternative. > I'm primarily concerned about TLS, as setting up those sessions is fairly expensive. I agree that multiplexing is a secondary issue (that's why it's a *, not a +). But we seem to need it, even if there are sometimes better mechanisms around. I'm not holding my breath until every OS and end system supports SCTP. From joshua@digitalknowledge.net Mon Sep 10 09:39:01 2001 Received: from granada.digitalknowledge.net ([204.1.2.114]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01327 for ; Mon, 10 Sep 2001 09:39:00 -0400 (EDT) Received: by granada.digitalknowledge.net with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Sep 2001 08:43:24 -0500 Message-ID: From: wireless@digitalknowledge.net To: simple@mailman.dynamicsoft.com Cc: Avshalom@ubique.com, roberbr@microsoft.com Subject: RE: [Simple] Sessions of MESSAGEs Date: Mon, 10 Sep 2001 08:43:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1334 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: inline > -----Original Message----- > From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] > Sent: Wednesday, September 05, 2001 3:34 AM > > > > I agree with Robert. Given the experience we had in implementing and > deploying Sametime the concerns about firewalls are more then valid. > > I would like to emphasize that NOTIFY can be arbitrary long > as MESSAGE, > given the detail/schema option and the human readable > comment. We differ > between NOTIFY and MESSAGE in that we allow a session of > NOTIFYs (created > by SUBSCRIBE) to be transferred over the same the control > transport and not > a session of MESSAGEs (created by INVITE). interesting argument and appears to be valid, it is like the kettle calling the pot black. > > I think that we should define that the MESSAGE can be sent on > the control > transport as NOTIFY even when there is a session. We should > also limit the > size of the MESSAGE that can be sent and enable partial NOTIFYs as > discussed in a separate tread. We shouldn't arbitrarily set a cap on the size of IM's. This should be implementable via a server policy by the IM vendor, but setting a cap on this is likened to limiting the max. size of an email or length of a phone call. It's not the role of the WG to do this. I like the rest of what you say, obviously ;) Joshua From bcampbell@dynamicsoft.com Mon Sep 10 11:52:38 2001 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 LAA01755 for ; Mon, 10 Sep 2001 11:52:37 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f8AFm9L08593 for ; Mon, 10 Sep 2001 10:48:09 -0500 Message-ID: <3B9CE0B8.90400@dynamicsoft.com> Date: Mon, 10 Sep 2001 10:48:08 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: "'simple@mailman.dynamicsoft.com'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1765 Subject: [Simple] Implicit MESSAGE sessions revisited 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: (My apologies in advance for re-opening an old can of worms...) It seems to the main advantages of explicit (that is, established by INVITE) IM sessions are that it can take advantage of existing SIP work for things like complex multipary conferencing scenarios (i.e. chat rooms). I hope that we do not see a lot of implementations using it for simple things like 2 party chats. Dean recently commented to me out-of-band, that most 2 party chat features can be handled without an explicit session. The most such feature obvious is strictly a user interface convenience, where the UI can present a series of messages as a thread, using the call-leg to identify the thread, CSeq to provide ordering, etc. But there are other features, such as short-circuiting the path of subsequent messages by skipping intervening proxies which do not record route, etc. that MESSAGE does not allow. We originally _did_ allow this, but the most recent version of the MESSAGE draft deprecates the use of _any_ implied session semantics with MESSAGE requests. We made this change because at that time we planned to use _explicit_ essions of MESSAGE requests to support any session semantics. In light of the current controversy over the explicit IM session concept, I am beginning to wonder if it was a good idea to entirely deprecate implicit IM sessions. If we are not going to support explicit sessions of IM sessions, does it make sense to revive implicit session semantics? Specifically, should we bring back an optional use of Contact headers in MESSAGE requests and associated responses, and should we allow record-route semantics? For those who wanted to keep explicit MESSAGE request sessions for firewall reasons, would this option help matters? From bcampbell@dynamicsoft.com Mon Sep 10 12:01:44 2001 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 MAA01816 for ; Mon, 10 Sep 2001 12:01:43 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f8AFvlL08600; Mon, 10 Sep 2001 10:57:47 -0500 Message-ID: <3B9CE2FB.2050008@dynamicsoft.com> Date: Mon, 10 Sep 2001 10:57:47 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: "David R. Oran" CC: "'Henning G. Schulzrinne'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] MESSAGE session References: <019f01c139f8$1b3475a0$24ee2ca1@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 2038 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: David R. Oran wrote: >>-----Original Message----- >>From: simple-admin@mailman.dynamicsoft.com >>[mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of >>Henning G. Schulzrinne >>Sent: Friday, September 07, 2001 3:54 PM >>To: simple@mailman.dynamicsoft.com >>Subject: [Simple] MESSAGE session >> >> >>While the use of MESSAGE-based sessions over UDP is 'out', I >>wonder whether this also implies that MESSAGE over TCP is >>unacceptable. It seems to satisfy the minimum requirements >>for any mechanism: >> >>+ congestion and flow control >>+ no size limitation for bodies >>+ each message must allow a different content type >>+ support of multipart MIME bodies >> for easy gatewaying to email, among other reasons >>+ allow use of TLS (or similar) for security >>* if possible, avoid yet more parsers >>* extensible, i.e., allow additional labeling through >> headers (useful for various gateways) >>* possibly make use of existing compression mechanisms >>* allow multiplexing, i.e., re-use one "pipe" for multiple >> sessions (this simplifies various mixing functions, for example) >> >>(+ are, in my view, must-haves, while * are nice-to-have) >> >> > Yes, it does. > > At first blush CPIM-over-TCP would seem to have the same properties and > avoids a bunch of gatewaying issues, assuming SIMPLE endpoints would > need a CPIM parser anyway. > > I'm not sure I would consider your last bullet about multiplexing an > advantage as I'm usually a skeptic about application-specific TCP > multiplexing schemes. If you really need this SCTP would seem an > attractive alternative. > Why is this sort of multiplexing any different than that used for SIP devices, where they accept all sip traffic on 5060, and use the request-URI call-leg info to demux between various destinations, transactions, call-legs, etc? If we have a pair of hypothetical IM session relays (assume cpim over tcp for the sake of argument), would you expect them to have a separate TCP connection for each active session between them? From oran@cisco.com Mon Sep 10 12:21:05 2001 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01911 for ; Mon, 10 Sep 2001 12:21:04 -0400 (EDT) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f8AGL5i10925; Mon, 10 Sep 2001 09:21:06 -0700 (PDT) Received: from oranlt ([161.44.238.36]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id AAX93628; Mon, 10 Sep 2001 09:20:51 -0700 (PDT) From: "David R. Oran" To: "'Ben Campbell'" Cc: "'Henning G. Schulzrinne'" , Subject: RE: [Simple] MESSAGE session Date: Mon, 10 Sep 2001 12:26:56 -0400 Organization: Cisco Systems Message-ID: <01b701c13a15$697ae330$24ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2542.0000 In-Reply-To: <3B9CE2FB.2050008@dynamicsoft.com> Content-Length: 1409 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: Ben, > > Why is this sort of multiplexing any different than that used for SIP > devices, where they accept all sip traffic on 5060, and use the > request-URI call-leg info to demux between various destinations, > transactions, call-legs, etc? > > If we have a pair of hypothetical IM session relays (assume cpim over > tcp for the sake of argument), would you expect them to have > a separate > TCP connection for each active session between them? > Depends on whether you care about head-of-line blocking or care whether all your sessions are coupled in terms of TCP congestion adaptation behavior. Some environments don't care about either and hence would not have a problem with straightforward TCP connection multiplexing. One of the nice things about SIP as a session establishment protocol is that the transport mechanisms SIP uses are pretty much decoupled from the rendezvous and transaction semantics SIP itself provides. In the case of end-to-end "session based" IM it isn't clear this independence is either needed or desired. If I didn't want independent session flows, I wouldn't bother with session-mode IM in the first place and I'd just do "paging mode". It seems that your world model always has "IM session relays" and if you are going to have such middleboxes between the users then it isn't clear that you're doing "session based IM" in the first place. Dave. > > > > From bcampbell@dynamicsoft.com Mon Sep 10 12:50:48 2001 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 MAA02030 for ; Mon, 10 Sep 2001 12:50:47 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f8AGkmL08641; Mon, 10 Sep 2001 11:46:49 -0500 Message-ID: <3B9CEE78.2090005@dynamicsoft.com> Date: Mon, 10 Sep 2001 11:46:48 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: "David R. Oran" CC: "'Henning G. Schulzrinne'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] MESSAGE session References: <01b701c13a15$697ae330$24ee2ca1@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 2057 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: David R. Oran wrote: > Ben, > > >>Why is this sort of multiplexing any different than that used for SIP >>devices, where they accept all sip traffic on 5060, and use the >>request-URI call-leg info to demux between various destinations, >>transactions, call-legs, etc? >> >>If we have a pair of hypothetical IM session relays (assume cpim over >>tcp for the sake of argument), would you expect them to have >>a separate >>TCP connection for each active session between them? >> >> > Depends on whether you care about head-of-line blocking or care whether > all your sessions are coupled in terms of TCP congestion adaptation > behavior. Some environments don't care about either and hence would not > have a problem with straightforward TCP connection multiplexing. > > One of the nice things about SIP as a session establishment protocol is > that the transport mechanisms SIP uses are pretty much decoupled from > the rendezvous and transaction semantics SIP itself provides. In the > case of end-to-end "session based" IM it isn't clear this independence > is either needed or desired. If I didn't want independent session flows, > I wouldn't bother with session-mode IM in the first place and I'd just > do "paging mode". > > It seems that your world model always has "IM session relays" and if you > are going to have such middleboxes between the users then it isn't clear > that you're doing "session based IM" in the first place. > > I'm sorry I gave that impression, as it is not my world view at all. I merely chose the example of relays as a situation where you would be likely to have many sessions crossing the same pair of devices. If we could get away with saying all explicit IM sessions are point-to-point, I would be very happy. However, a number of participants have indicated a need to be able to insert proxies. If we could get away with saying that if you need intermediaries, just use the page model, life would be much simpler. I am unable to fathom the wg consensus on that question from the list discussion. From pkyzivat@cisco.com Mon Sep 10 13:30:41 2001 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 NAA02171 for ; Mon, 10 Sep 2001 13:30:41 -0400 (EDT) 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 f8AHU6e10164; Mon, 10 Sep 2001 13:30:08 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAA26487 (AUTH pkyzivat); Mon, 10 Sep 2001 13:31:33 -0400 (EDT) Message-ID: <3B9CF880.8245290C@cisco.com> Date: Mon, 10 Sep 2001 13:29:36 -0400 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: Ben Campbell CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Implicit MESSAGE sessions revisited References: <3B9CE0B8.90400@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 4380 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: Comments below. Paul Kyzivat Ben Campbell wrote: > > (My apologies in advance for re-opening an old can of worms...) > > It seems to the main advantages of explicit (that is, established by > INVITE) IM sessions are that it can take advantage of existing SIP work > for things like complex multipary conferencing scenarios (i.e. chat > rooms). I hope that we do not see a lot of implementations using it for > simple things like 2 party chats. I believe there are a number of other advantages. The most obvious is explicit call control - there is a clear beginning and end to a session. If I don't want to talk to you anymore, I can hang up. And if you call back, I can refuse to answer. The act of my hanging up is a clear signal that I am done with the session. Another advantage is that multiple media can be clearly tied together in one call. This is important if those media are needed together. For instance, if I want you to assist me in operating a troublesome application, I need an application sharing protocol plus some other protocol for communicating with you - which might be voice or might be IM. It doesn't do me any good to have one without the other. And then, in mid-call, I may decide that IM is too cumbersome, and that voice would be more helpful. With a call tying everything together, I can simply reinvite, adding voice, and be reasonably confident that the voice will be connected to the same endpoint where I am already interacting with you, rather than some other place like your voicemail server. This last example also is relevant when starting out with only IM. I may still want to switch to voice in mid-call. All of these are cases that make sense with 2-party calls. To avoid being spammed excessively, I think I must be reasonably restrictive about who I accept page mode IMs from. I may be less restrictive in who I automatically reject when receiving an INVITE - I can look at who is calling and decide then whether to answer or not. Most likely I will only accept page mode from an explicit list of friends, but may at least entertain calls from anyone not on an exclude list. My impression is that most existing IM products don't have true session mode. Instead they seem to presume that messages to me will only originate with people on my buddy list. I don't know whether this is enforced however. If it is not, then eventually it will be abused by spammers. But there is need for the IM from unknown parties, and I don't think it can be satisfied by having each potential caller first asking to be a buddy. My implication is that when I want to send an IM, or session of IMs, to someone, it may be best to use session mode unless I know I am dealing with someone who will permit page mode. Or maybe I should always be prepared to try both ways. > > Dean recently commented to me out-of-band, that most 2 party chat > features can be handled without an explicit session. The most such > feature obvious is strictly a user interface convenience, where the UI > can present a series of messages as a thread, using the call-leg to > identify the thread, CSeq to provide ordering, etc. > > But there are other features, such as short-circuiting the path of > subsequent messages by skipping intervening proxies which do not record > route, etc. that MESSAGE does not allow. We originally _did_ allow this, > but the most recent version of the MESSAGE draft deprecates the use of > _any_ implied session semantics with MESSAGE requests. We made this > change because at that time we planned to use _explicit_ essions of > MESSAGE requests to support any session semantics. > > In light of the current controversy over the explicit IM session > concept, I am beginning to wonder if it was a good idea to entirely > deprecate implicit IM sessions. If we are not going to support explicit > sessions of IM sessions, does it make sense to revive implicit session > semantics? > > Specifically, should we bring back an optional use of Contact headers in > MESSAGE requests and associated responses, and should we allow > record-route semantics? For those who wanted to keep explicit MESSAGE > request sessions for firewall reasons, would this option help matters? > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple From bcampbell@dynamicsoft.com Mon Sep 10 14:08:41 2001 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 OAA02317 for ; Mon, 10 Sep 2001 14:08:38 -0400 (EDT) Received: from dynamicsoft.com (Avalon2 [127.0.0.1]) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id f8AI4aL08689; Mon, 10 Sep 2001 13:04:36 -0500 Message-ID: <3B9D00B4.3060809@dynamicsoft.com> Date: Mon, 10 Sep 2001 13:04:36 -0500 From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Kyzivat CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Implicit MESSAGE sessions revisited References: <3B9CE0B8.90400@dynamicsoft.com> <3B9CF880.8245290C@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 3738 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: Paul Kyzivat wrote: > Comments below. > > Paul Kyzivat > > Ben Campbell wrote: > >>(My apologies in advance for re-opening an old can of worms...) >> >>It seems to the main advantages of explicit (that is, established by >>INVITE) IM sessions are that it can take advantage of existing SIP work >>for things like complex multipary conferencing scenarios (i.e. chat >>rooms). I hope that we do not see a lot of implementations using it for >>simple things like 2 party chats. >> > > I believe there are a number of other advantages. > > The most obvious is explicit call control - there is a clear beginning > and end to a session. If I don't want to talk to you anymore, I can hang > up. And if you call back, I can refuse to answer. The act of my hanging > up is a clear signal that I am done with the session. > > Another advantage is that multiple media can be clearly tied together in > one call. This is important if those media are needed together. For > instance, if I want you to assist me in operating a troublesome > application, I need an application sharing protocol plus some other > protocol for communicating with you - which might be voice or might be > IM. It doesn't do me any good to have one without the other. And then, > in mid-call, I may decide that IM is too cumbersome, and that voice > would be more helpful. With a call tying everything together, I can > simply reinvite, adding voice, and be reasonably confident that the > voice will be connected to the same endpoint where I am already > interacting with you, rather than some other place like your voicemail > server. > > This last example also is relevant when starting out with only IM. I may > still want to switch to voice in mid-call. > > All of these are cases that make sense with 2-party calls. I agree on the explicit call control--there is some advantage in knowing when the session ends that can be a minor pain in an implicit session. The adding of an additional media stream can normally be handled by a new invite, even if the original session was implicit. I can see an issue, though, if one participant is not reachable via a direct media session, but had been available for a SIP message. > > To avoid being spammed excessively, I think I must be reasonably > restrictive about who I accept page mode IMs from. I may be less > restrictive in who I automatically reject when receiving an INVITE - I > can look at who is calling and decide then whether to answer or not. > Most likely I will only accept page mode from an explicit list of > friends, but may at least entertain calls from anyone not on an exclude > list. > > My impression is that most existing IM products don't have true session > mode. Instead they seem to presume that messages to me will only > originate with people on my buddy list. I don't know whether this is > enforced however. If it is not, then eventually it will be abused by > spammers. But there is need for the IM from unknown parties, and I don't > think it can be satisfied by having each potential caller first asking > to be a buddy. AOL works much like you describe, I think. Others (yahoo for example) has a clear distinction between sending a message and inviting someone to a conference--even if it is just a text conference. > > My implication is that when I want to send an IM, or session of IMs, to > someone, it may be best to use session mode unless I know I am dealing > with someone who will permit page mode. Or maybe I should always be > prepared to try both ways. > I would expect a class of endpoints that could only accept page mode, and a class that can do both. I would be surprised to see endpoints that could _only_ do sessions, but not page mode. From pkyzivat@cisco.com Mon Sep 10 15:16:22 2001 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 PAA02574 for ; Mon, 10 Sep 2001 15:16:22 -0400 (EDT) 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 f8AJFoe23110; Mon, 10 Sep 2001 15:15:50 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAA27478 (AUTH pkyzivat); Mon, 10 Sep 2001 15:17:21 -0400 (EDT) Message-ID: <3B9D1151.C70BBA25@cisco.com> Date: Mon, 10 Sep 2001 15:15:29 -0400 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: Ben Campbell CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] Implicit MESSAGE sessions revisited References: <3B9CE0B8.90400@dynamicsoft.com> <3B9CF880.8245290C@cisco.com> <3B9D00B4.3060809@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 653 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: Ben Campbell wrote: > > Paul Kyzivat wrote: > > > My implication is that when I want to send an IM, or session of IMs, to > > someone, it may be best to use session mode unless I know I am dealing > > with someone who will permit page mode. Or maybe I should always be > > prepared to try both ways. > > > > I would expect a class of endpoints that could only accept page mode, > and a class that can do both. I would be surprised to see endpoints that > could _only_ do sessions, but not page mode. I didn't mean to suggest that an endpoint wouldn't be *able* to do page mode. Only that it might not be *willing* to do page mode with some callers. From bstucker@nortelnetworks.com Tue Sep 11 15:30:26 2001 Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07004 for ; Tue, 11 Sep 2001 15:30:25 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA07443 for ; Tue, 11 Sep 2001 14:30:10 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 11 Sep 2001 14:29:59 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Sep 2001 14:29:57 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430358D932@crchy271.us.nortel.com> From: "Brian Stucker" To: "'simple@mailman.dynamicsoft.com'" Date: Tue, 11 Sep 2001 14:29:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13AF8.1F819150" Content-Length: 4197 Subject: [Simple] Questions on the current presence draft. 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: 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_01C13AF8.1F819150 Content-Type: text/plain; charset="iso-8859-1" I was reading through the current draft, and noticed a few things that I was looking for clairification on. In the section on presence migration, the last sentence of the description for the second phase of presence migration states: "...This informs the subscribers that their subscription was destroyed, and should be re-established with a new SUBSCRIBE (with a new Call-ID)." I was wondering, if a watcher was offline when the NOTIFY containing the "Subscription-Expires" header to destroy the current subscription, what are the implications with the call id? I would imagine when the watcher comes back online, and tries to refresh the subscription, it would use the old call-id (since it doesn't know that it needs to reselect), which gets proxied to the new PA (after the migration occurred). This seems like a gap to me. Also, what happens if the watchers (previous to the migration) never receive the NOTIFY to update their subscriptions to cause a refresh. Unless they do a fetch, the new PA doesn't know that they exist, so their subscriptions will be effectively moot, but they won't be aware of this fact. They won't get any notifications, and won't know that their subscriptions are being ignored. In section 8, there are mixed uses of the presence URL and SIP URL's. Is this done intentionally? Finally, can someone point a link to the draft listed as [4] in the bibliography? It doesn't seem to be available at the IETF webpage. Thanks, Brian ------_=_NextPart_001_01C13AF8.1F819150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Questions on the current presence draft.

I was reading through the current draft, and noticed = a few things that I
was looking for clairification on.

In the section on presence migration, the last = sentence of the description
for the second phase of presence migration states: = "...This informs the subscribers that their
subscription was destroyed, and should be = re-established with a new SUBSCRIBE (with a new Call-ID)."

I was wondering, if a watcher was offline when the = NOTIFY containing the "Subscription-Expires" header
to destroy the current subscription, what are the = implications with the call id? I would imagine when the
watcher comes back online, and tries to refresh the = subscription, it would use the old call-id (since it doesn't
know that it needs to reselect), which gets proxied = to the new PA (after the migration occurred). This seems like a gap to = me.

Also, what happens if the watchers (previous to the = migration) never receive the NOTIFY to update their
subscriptions to cause a refresh. Unless they do a = fetch, the new PA doesn't know that they exist, so their
subscriptions will be effectively moot, but they = won't be aware of this fact. They won't get any notifications, = and
won't know that their subscriptions are being = ignored.

In section 8, there are mixed uses of the presence = URL and SIP URL's. Is this done intentionally?

Finally, can someone point a link to the draft listed = as [4] in the bibliography? It doesn't seem to be available
at the IETF webpage.

Thanks,

Brian

------_=_NextPart_001_01C13AF8.1F819150-- From sendstrategies@11399.com Thu Sep 13 02:52:04 2001 Received: from www.doobee.com (www.doobee.com [210.112.35.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA13380 for ; Thu, 13 Sep 2001 02:52:03 -0400 (EDT) From: sendstrategies@11399.com Received: from 210.112.35.1 (unverified [216.129.66.97]) by www.doobee.com (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 13 Sep 2001 15:48:19 +0900 Received: from sendstrategies@consultant.com by (8.8.5/8.6.5) with SMTP id GAA04094 for ; Wed, 12 Sep 2001 23:34:53 -0600 (EST) Date: Wed, 12 Sep 01 23:34:53 EST To: simple@mailman.dynamicsoft.com Message-ID: <> Reply-To: sendstrategies@consultant.com Content-Length: 3565 Subject: [Simple] Learn the FREE Strategies to Passive Income 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: 

Dear simple@mailman.dynamicsoft.com,

Learn the Strategies of Passive Income and more 
from this FREE WEBSITE. 

Time-tested principles in the age of the internet 
can mean a fortune for anyone. We'll show you how.
 
We're about to share with you the secrets of earning 
a six-figure income working from home. That's $100,000 
per year.... at least!  $8,333.33 per month. You don't 
think it's possible? Money magazine says there are 
over one million people who do it every year... not 
just six figures... six figures with a six-second 
commute!

But we're not going to just show you how to earn six 
figures from home. We're going to show you how to build 
a passive six-figure income from your little make-shift 
home office.  And passive income is freedom!  Everyone 
wants freedom... but it's often too elusive for most 
people... why?

Have you ever seen a transient on the street and 
thought, "If that were me, I'd be back on my feet 
within 6 months. I wish I could just show him what 
he has to do."? Do you know why you could be back 
on your feet?  Because you:

- Know what to do, and 
- Have the emotional fortitude to see it through.


Well, we have news for you. There are people who look 
at you like you look at the transient. They wish they 
could tell you what it takes to get to the next level 
of freedom in your life and give you the coaching and 
motivational mentoring you need to see it through.

Wealth and freedom can, and should, be yours. You have 
the right to acquire it. The family that is jetsetting 
around the world, teaching their children about art in 
Paris and about science on the Amazon, eating out 
whenever they want to, cruising on yachts, hot-air 
ballooning over wine country, relaxing on tropical 
beaches, has no more right to all of that than you. We 
believe you can have, should have, and will have all 
your dreams. All of them.   

That's why we're offering this FREE website. We want 
to give back. We've been very fortunate to have been 
mentored out of deep financial debt and emotional 
turmoil, and now it's our turn to help you out. We're 
going to share with you the principles and strategies 
for building a massive passive income. These are not 
just our strategies. These are proven principles that 
have long been the secret of the rich. We've synthesized 
years of our own experience developing massive passive 
wealth and hundreds of interviews with people who are 
rich. Not just rich in money, but in time, too. People 
who have wealth AND freedom.

To obtain your more information on this FREE Website
click the hyper-link below... then just click send in 
your e-mail screen. We will then send you an e-mail with 
the URL of all the details: (AOL users must cut & paste
the email address below and send an email manually with the 
subject line "Send Free Strategies")

 mailto:sendstrategies@consultant.com?subject=sendfreestrategies


Best of luck in your internet ventures,

Q.R. Marketing


P.S. In my experience it does not get any better or 
easier than this for discovering the "Inside Secrets 
to Web Marketing!" 

PPS. We want to help you in any way we can.... just email 
us and tell us what kind of assistance you need:   
mailto:sendstrategies@consultant.com

___________________________________________________________
If you wish to be removed from future mailings, please 
reply with the subject "Remove" and you will automatically 
be blocked from any future mailings.








From Basavaraj.Patil@nokia.com  Fri Sep 14 14:08:04 2001
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 OAA19664
	for ; Fri, 14 Sep 2001 14:08:02 -0400 (EDT)
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 f8EI8F722870
	for ; Fri, 14 Sep 2001 21:08:15 +0300 (EET DST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8EI7pC14131
	for ; Fri, 14 Sep 2001 13:07:55 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 14 Sep 2001 13:07:44 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 14 Sep 2001 13:07:43 -0500
content-class: urn:content-classes:message
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Fri, 14 Sep 2001 13:07:43 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF441E8684@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Implicit MESSAGE sessions revisited
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcE6JP4JBj5KhqYXEdWrxAAIx6S5QwDIp80A
From: "Patil Basavaraj (NET/Dallas)" 
To: "'ext Ben Campbell'" 
Cc: 
X-OriginalArrivalTime: 14 Sep 2001 18:07:43.0776 (UTC) FILETIME=[269BAA00:01C13D48]
Content-Length: 194
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA19664
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: 

One of the protocols that has been suggested for use instead of
MESSAGE is BEEP. Are there any serious concerns *at this time*
why BEEP would not be good eniugh for IM Sessions? 

-Basavaraj



From rsparks@dynamicsoft.com  Fri Sep 14 14:09:30 2001
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 OAA19673
	for ; Fri, 14 Sep 2001 14:09:30 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8EI8SCj008898;
	Fri, 14 Sep 2001 14:08:28 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 14 Sep 2001 14:09:24 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E5CD@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: "'simple@mailman.dynamicsoft.com'" 
Cc: "'jon.peterson@nuestar.com'" 
Date: Fri, 14 Sep 2001 14:09:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 964
Subject: [Simple] REMINDER: WG LAST CALL : draft-ietf-simple-presence-02
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: 

One week remains in this WGLC. If you have comments
that you anticipate will require discussion, please
get them in to the list ASAP.

RjS

> -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: Thursday, September 06, 2001 1:10 PM
> To: 'simple@mailman.dynamicsoft.com'
> Cc: 'jon.peterson@nuestar.com'; 'djrosen@dynamicsoft.com'; 'Patrik
> Faltstrom'
> Subject: [Simple] WG LAST CALL : draft-ietf-simple-presence-02
> 
> 
> This is a SIMPLE Working Group Last Call for comments
> on draft-ietf-simple-presence-02.txt. This last call
> closes Friday September 21, 2001. Please post any
> final comments you have on this draft to this list by
> that date.
> 
> The draft is available at
> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-02.txt
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From hgs@cs.columbia.edu  Fri Sep 14 14:14:04 2001
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 OAA19698
	for ; Fri, 14 Sep 2001 14:13:59 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA26178;
	Fri, 14 Sep 2001 14:13:44 -0400 (EDT)
Message-ID: <3BA248ED.F2A1B529@cs.columbia.edu>
Date: Fri, 14 Sep 2001 14:14:05 -0400
From: Henning Schulzrinne 
Reply-To: hgs@cs.columbia.edu
Organization: Lucent Technologies
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Patil Basavaraj (NET/Dallas)" 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Implicit MESSAGE sessions revisited
References: <697DAA22C5004B4596E033803A7CEF441E8684@daebe007.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 429
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: 

While BEEP is a useful protocol, I fail to see what advantages it offers
compared to "smaller" solutions that don't require as much additional
infrastructure and end system complexity.

"Patil Basavaraj (NET/Dallas)" wrote:
> 
> One of the protocols that has been suggested for use instead of
> MESSAGE is BEEP. Are there any serious concerns *at this time*
> why BEEP would not be good eniugh for IM Sessions?
> 
> -Basavaraj
>

From Basavaraj.Patil@nokia.com  Fri Sep 14 14:37:16 2001
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19818
	for ; Fri, 14 Sep 2001 14:37:15 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.americas.nokia.com [172.18.194.216])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8EIfUG07070
	for ; Fri, 14 Sep 2001 21:41:30 +0300 (EET DST)
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 f8EIb8311645
	for ; Fri, 14 Sep 2001 13:37:08 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 14 Sep 2001 13:37:07 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 14 Sep 2001 13:37:07 -0500
content-class: urn:content-classes:message
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Fri, 14 Sep 2001 13:37:06 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF44096817@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Implicit MESSAGE sessions revisited
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcE9SQEfuTCKWKk4EdWJUwAIx6TWpQAASvug
From: "Patil Basavaraj (NET/Dallas)" 
To: 
Cc: 
X-OriginalArrivalTime: 14 Sep 2001 18:37:07.0198 (UTC) FILETIME=[41B081E0:01C13D4C]
Content-Length: 1145
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA19818
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: 

> 
> While BEEP is a useful protocol, I fail to see what 
> advantages it offers
> compared to "smaller" solutions that don't require as much additional
> infrastructure and end system complexity.
>

Do we really need yet another (AL) protocol is what I had in mind.
Whether
BEEP has advantages should be evaluated against whether BEEP can
satisfy the requirements for IM sessions. 

-Reuse Vs Reinventing something else. The problem with the reinvention
is that by the time the "smaller" solution has addressed all the
requirements
and concerns, it ends up looking something that already exists and the
argument of simplicity is gone.

-Reuse of BEEP also means getting the IM for sessions spec/solution done

faster. If the IM for Sessions spec focused on getting the signaling
part done
and not have to worry about how to transport the data, that would
simplify the
spec and 

 
> "Patil Basavaraj (NET/Dallas)" wrote:
> > 
> > One of the protocols that has been suggested for use instead of
> > MESSAGE is BEEP. Are there any serious concerns *at this time*
> > why BEEP would not be good eniugh for IM Sessions?
> > 
> > -Basavaraj
> >
> 

From Basavaraj.Patil@nokia.com  Fri Sep 14 15:59:47 2001
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20101
	for ; Fri, 14 Sep 2001 15:59:46 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.americas.nokia.com [172.18.194.217])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8EK3wG22138
	for ; Fri, 14 Sep 2001 23:03:59 +0300 (EET DST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8EJxhC24428
	for ; Fri, 14 Sep 2001 14:59:43 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Fri, 14 Sep 2001 14:59:35 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 14 Sep 2001 14:59:35 -0500
content-class: urn:content-classes:message
Date: Fri, 14 Sep 2001 14:59:34 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF44096818@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Topic: Comment: draft-ietf-simple-presence-02
Thread-Index: AcE9V8Y6n68RX6kYEdWw0gAAhj/HZA==
From: "Patil Basavaraj (NET/Dallas)" 
To: 
X-OriginalArrivalTime: 14 Sep 2001 19:59:35.0311 (UTC) FILETIME=[C6FEA1F0:01C13D57]
Content-Length: 349
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA20101
Subject: [Simple] Comment: draft-ietf-simple-presence-02
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: 

Non-critical issue:

Section 5.3 (Paragraph 3) defines a default filter. However
I do not see the need for bullet 3 wherein additional markup
is sent (if < 50 bytes). It is better to have a consistent mechanism
of sending any markup (irrespective of size) only if explicitly
requested
by the subscriber or just send all the markup as the default. 

From c-Dai.Ngo@WCOM.Com  Fri Sep 14 16:55:48 2001
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 QAA20303
	for ; Fri, 14 Sep 2001 16:55:47 -0400 (EDT)
Received: from dgismtp03.wcomnet.com ([166.38.58.143])
 by firewall.wcom.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GJO004156SDT7@firewall.wcom.com> for
 simple@mailman.dynamicsoft.com; Fri, 14 Sep 2001 20:41:01 +0000 (GMT)
Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0GJO001016RR5A@dgismtp03.wcomnet.com>;
 Fri, 14 Sep 2001 20:41:01 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0GJO00KIA6RMQ3@dgismtp03.wcomnet.com>; Fri,
 14 Sep 2001 20:40:35 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 14 Sep 2001 20:40:34 +0000
Content-return: allowed
Date: Fri, 14 Sep 2001 20:40:26 +0000
From: "Ngo, Dai (c)" 
Subject: RE: [Simple] Notifier Migration Clarification
To: "'Jonathan Rosenberg'" ,
        simple@mailman.dynamicsoft.com
Message-id: <492EB4A3F68CD411ABE800508B69362E6C4DF7@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_M61j1YgLrgwNjHzu0QP9+A)"
Content-Length: 5341
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: 

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_M61j1YgLrgwNjHzu0QP9+A)
Content-type: text/plain; charset=iso-8859-1

Does this seem inflexible to you? We allow (serial/parallel) forking for
SUBSCRIBE, why not for this?

-- Dai

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, September 04, 2001 5:39 PM
To: Ngo, Dai (c); simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Notifier Migration Clarification




  
-----Original Message-----
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com]
Sent: Tuesday, September 04, 2001 4:25 PM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] Notifier Migration Clarification


>All, 
>In section 5.12 "State Agents and Notifier Migration" of
draft-ietf-simple-presence-02.txt 
>it says, "The presence server MAY migrate the subscription if, for a given
address of 
>record, there is one, and only one registered contact that indicates
explicit support for 
>the SUBSCRIBE method."
>
>What's the behavior of the presence server if there are multiple registered
contacts which 
>explicitly support for the SUBSCRIBE method?

It can't migrate the PA function.

-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

--Boundary_(ID_M61j1YgLrgwNjHzu0QP9+A)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: quoted-printable






RE: [Simple] Notifier Migration Clarification




Does this seem inflexible to you? We allow =
(serial/parallel) forking for SUBSCRIBE, why not for this?




-- Dai




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Tuesday, September 04, 2001 5:39 PM

To: Ngo, Dai (c); =
simple@mailman.dynamicsoft.com

Subject: RE: [Simple] Notifier Migration =
Clarification










  

-----Original Message-----

From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com]=


Sent: Tuesday, September 04, 2001 4:25 PM

To: simple@mailman.dynamicsoft.com

Subject: [Simple] Notifier Migration =
Clarification






>All, 

>In section 5.12 "State Agents and Notifier =
Migration" of

draft-ietf-simple-presence-02.txt 

>it says, "The presence server MAY migrate =
the subscription if, for a given

address of 

>record, there is one, and only one registered =
contact that indicates

explicit support for 

>the SUBSCRIBE method."

>

>What's the behavior of the presence server if =
there are multiple registered

contacts which 

>explicitly support for the SUBSCRIBE =
method?




It can't migrate the PA function.




-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






--Boundary_(ID_M61j1YgLrgwNjHzu0QP9+A)--

From dean.willis@softarmor.com  Sat Sep 15 00:34:20 2001
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 AAA21683
	for ; Sat, 15 Sep 2001 00:34:19 -0400 (EDT)
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 f8F4ZMD17753;
	Fri, 14 Sep 2001 23:35:23 -0500
Message-ID: <001501c13d9f$3999f510$55fa403f@blazer>
From: "Dean Willis" 
To: "Patil Basavaraj \(NET/Dallas\)" ,
        "'ext Ben Campbell'" 
Cc: 
References: <697DAA22C5004B4596E033803A7CEF441E8684@daebe007.NOE.Nokia.com>
Subject: Re: [Simple] Implicit MESSAGE sessions revisited
Date: Fri, 14 Sep 2001 23:31:01 -0500
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
Content-Length: 1052
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: 

Just as MESSAGE for sessions has all the wasted overhead of headers and
routing mechanisms designed to find users and traverse firewalls (assuming
you think this is a waste), so does BEEP.

I personally have yet to see the need for message sessions as a specialized
transport.

I think "pager" messages carrying a session-ID and sequence number can
provide the same user experience.

--
dean


----- Original Message -----
From: "Patil Basavaraj (NET/Dallas)" 
To: "'ext Ben Campbell'" 
Cc: 
Sent: Friday, September 14, 2001 1:07 PM
Subject: RE: [Simple] Implicit MESSAGE sessions revisited


>
> One of the protocols that has been suggested for use instead of
> MESSAGE is BEEP. Are there any serious concerns *at this time*
> why BEEP would not be good eniugh for IM Sessions?
>
> -Basavaraj
>
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>


From hgs@cs.columbia.edu  Sat Sep 15 10:34:30 2001
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23456
	for ; Sat, 15 Sep 2001 10:34:30 -0400 (EDT)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id KAA05381;
	Sat, 15 Sep 2001 10:34:20 -0400 (EDT)
Message-ID: <3BA366EC.E9B6CA02@cs.columbia.edu>
Date: Sat, 15 Sep 2001 10:34:20 -0400
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Implicit MESSAGE sessions revisited
References: <697DAA22C5004B4596E033803A7CEF441E8684@daebe007.NOE.Nokia.com> <001501c13d9f$3999f510$55fa403f@blazer>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 805
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: 

Dean Willis wrote:
> 
> Just as MESSAGE for sessions has all the wasted overhead of headers and
> routing mechanisms designed to find users and traverse firewalls (assuming
> you think this is a waste), so does BEEP.
> 
> I personally have yet to see the need for message sessions as a specialized
> transport.
> 
> I think "pager" messages carrying a session-ID and sequence number can
> provide the same user experience.

Just for clarification:

Are you assuming that TCP (or, presumably, SCTP) is used? Are you
assuming that the TCP connection is kept open implicitly?

(To avoid artificial disagreement: I would agree that a regular SIP
session over TCP would address most of the requirements, but just saying
"paging" isn't quite enough.)


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From zane@mabry.com  Sat Sep 15 13:21:40 2001
Received: from mailnw.centurytel.net (mailnw.centurytel.net [209.206.160.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23995
	for ; Sat, 15 Sep 2001 13:21:40 -0400 (EDT)
Received: from toophat (dsl-209-206-250-63.rb.gh.centurytel.net [209.206.250.63])
	by mailnw.centurytel.net (8.11.6/8.11.6) with ESMTP id f8FHLHj26122
	for ; Sat, 15 Sep 2001 10:21:18 -0700 (PDT)
Message-ID: <03d001c13e0a$eb977010$47dcfea9@toophat>
From: "Zane Thomas" 
To: 
References: <697DAA22C5004B4596E033803A7CEF441E8684@daebe007.NOE.Nokia.com> <3BA248ED.F2A1B529@cs.columbia.edu>
Subject: Re: [Simple] Implicit MESSAGE sessions revisited
Date: Sat, 15 Sep 2001 10:21:55 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Content-Length: 643
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA23995
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: 

Henning,

> While BEEP is a useful protocol, I fail to see what advantages it offers
> compared to "smaller" solutions that don't require as much additional
> infrastructure and end system complexity.

If, after establishing a session with SIP, your only requirement is to pass simple messages back and forth then BEEP is certainly overkill.  However, if you want to use the same (tcp for instance) connection to simultaneously pass other information - such as "out of band" file transfers, realtime presence information, or other application level sorts of information then you have the sort of problems BEEP was designed to address.

Zane



From mwatson@nortelnetworks.com  Mon Sep 17 10:41:05 2001
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01378
	for ; Mon, 17 Sep 2001 10:41:05 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f8HEeng02984
	for ; Mon, 17 Sep 2001 15:40:49 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Mon, 17 Sep 2001 15:40:21 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id ;
          Mon, 17 Sep 2001 15:40:19 +0100
Message-ID: 
From: "Mark Watson" 
To: "'Dean Willis'" ,
        "Patil Basavaraj (NET/Dallas)" ,
        "'ext Ben Campbell'" 
Cc: simple 
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Mon, 17 Sep 2001 15:39:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C13F86.9C77F7C0"
Content-Length: 6969
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: 

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_01C13F86.9C77F7C0
Content-Type: text/plain;
	charset="iso-8859-1"

Dean,

Do you mean that you don't see the advantage of using INVITE to set up an IM
'session' (indicating this in the SDP), or just that once such a session is
set up, there is no need for the 'media' to use any different protocol than
that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set up using INVITE
just like any other SIP session, make sense. I don't care much yet what the
transport protocol then is for the IMs in the session.

Sorry if this is covering old ground.

...Mark




> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 15 September 2001 05:31
> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'
> Cc: simple
> Subject: Re: [Simple] Implicit MESSAGE sessions revisited
> 
> 
> 
> Just as MESSAGE for sessions has all the wasted overhead of 
> headers and
> routing mechanisms designed to find users and traverse 
> firewalls (assuming
> you think this is a waste), so does BEEP.
> 
> I personally have yet to see the need for message sessions as 
> a specialized
> transport.
> 
> I think "pager" messages carrying a session-ID and sequence number can
> provide the same user experience.
> 
> --
> dean
> 
> 
> ----- Original Message -----
> From: "Patil Basavaraj (NET/Dallas)" 
> To: "'ext Ben Campbell'" 
> Cc: 
> Sent: Friday, September 14, 2001 1:07 PM
> Subject: RE: [Simple] Implicit MESSAGE sessions revisited
> 
> 
> >
> > One of the protocols that has been suggested for use instead of
> > MESSAGE is BEEP. Are there any serious concerns *at this time*
> > why BEEP would not be good eniugh for IM Sessions?
> >
> > -Basavaraj
> >
> >
> > _______________________________________________
> > 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_01C13F86.9C77F7C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Implicit MESSAGE sessions revisited




Dean,




Do you mean that you don't see the advantage of using =
INVITE to set up an IM 'session' (indicating this in the SDP), or just =
that once such a session is set up, there is no need for the 'media' to =
use any different protocol than that used for 'paging' ?



I think there are a lot of reasons why IM 'sessions' =
set up using INVITE just like any other SIP session, make sense. I =
don't care much yet what the transport protocol then is for the IMs in =
the session.



Sorry if this is covering old ground.




...Mark










> -----Original Message-----

> From: Dean Willis [mailto:dean.willis@softarmor.c=
om]

> Sent: 15 September 2001 05:31

> To: Patil Basavaraj (NET/Dallas); 'ext Ben =
Campbell'

> Cc: simple

> Subject: Re: [Simple] Implicit MESSAGE sessions =
revisited

> 

> 

> 

> Just as MESSAGE for sessions has all the wasted =
overhead of 

> headers and

> routing mechanisms designed to find users and =
traverse 

> firewalls (assuming

> you think this is a waste), so does =
BEEP.

> 

> I personally have yet to see the need for =
message sessions as 

> a specialized

> transport.

> 

> I think "pager" messages carrying a =
session-ID and sequence number can

> provide the same user experience.

> 

> --

> dean

> 

> 

> ----- Original Message -----

> From: "Patil Basavaraj (NET/Dallas)" =
<Basavaraj.Patil@nokia.com>

> To: "'ext Ben Campbell'" =
<bcampbell@dynamicsoft.com>

> Cc: =
<simple@mailman.dynamicsoft.com>

> Sent: Friday, September 14, 2001 1:07 PM

> Subject: RE: [Simple] Implicit MESSAGE sessions =
revisited

> 

> 

> >

> > One of the protocols that has been =
suggested for use instead of

> > MESSAGE is BEEP. Are there any serious =
concerns *at this time*

> > why BEEP would not be good eniugh for IM =
Sessions?

> >

> > -Basavaraj

> >

> >

> > =
_______________________________________________

> > 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_01C13F86.9C77F7C0--

From dean.willis@softarmor.com  Mon Sep 17 12:31:01 2001
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 MAA01731
	for ; Mon, 17 Sep 2001 12:31:01 -0400 (EDT)
Received: from flak (localhost.localdomain [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f8HGWAD27407;
	Mon, 17 Sep 2001 11:32:10 -0500
Message-ID: <00e101c13f96$1c47db00$3b2e713f@flak>
From: "Dean Willis" 
To: "Henning G. Schulzrinne" 
Cc: 
References: <697DAA22C5004B4596E033803A7CEF441E8684@daebe007.NOE.Nokia.com> <001501c13d9f$3999f510$55fa403f@blazer> <3BA366EC.E9B6CA02@cs.columbia.edu>
Subject: Re: [Simple] Implicit MESSAGE sessions revisited
Date: Mon, 17 Sep 2001 11:30:47 -0500
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
Content-Length: 1653
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: 

No, we're clearly thinking something different here. I'm proposing providing
the concept of a "session" as a sequence of messages, with that sequence
association being indicated at the application rather than transport layer.

For example, the message body itself might contain a session identifier and
a sequence number.

This would allow the receiving client to render messages into appropriate
windows in an appropriate order, as appropriate to the implementation,
without the transport layer being aware of that behavior.

--
Dean

----- Original Message -----
From: "Henning G. Schulzrinne" 
To: "Dean Willis" 
Cc: 
Sent: Saturday, September 15, 2001 9:34 AM
Subject: Re: [Simple] Implicit MESSAGE sessions revisited


> Dean Willis wrote:
> >
> > Just as MESSAGE for sessions has all the wasted overhead of headers and
> > routing mechanisms designed to find users and traverse firewalls
(assuming
> > you think this is a waste), so does BEEP.
> >
> > I personally have yet to see the need for message sessions as a
specialized
> > transport.
> >
> > I think "pager" messages carrying a session-ID and sequence number can
> > provide the same user experience.
>
> Just for clarification:
>
> Are you assuming that TCP (or, presumably, SCTP) is used? Are you
> assuming that the TCP connection is kept open implicitly?
>
> (To avoid artificial disagreement: I would agree that a regular SIP
> session over TCP would address most of the requirements, but just saying
> "paging" isn't quite enough.)
>
>
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
>


From dean.willis@softarmor.com  Mon Sep 17 12:37:31 2001
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 MAA01770
	for ; Mon, 17 Sep 2001 12:37:30 -0400 (EDT)
Received: from flak (localhost.localdomain [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f8HGXbD27412;
	Mon, 17 Sep 2001 11:33:37 -0500
Message-ID: <00f101c13f96$504e7d50$3b2e713f@flak>
From: "Dean Willis" 
To: "Mark Watson" ,
        "Patil Basavaraj \(NET/Dallas\)" ,
        "'ext Ben Campbell'" 
Cc: "simple" 
References: 
Subject: Re: [Simple] Implicit MESSAGE sessions revisited
Date: Mon, 17 Sep 2001 11:32:14 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00EE_01C13F6C.6651A890"
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
Content-Length: 9293
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_00EE_01C13F6C.6651A890
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [Simple] Implicit MESSAGE sessions revisitedBoth, actually. I =
believe the issues are independent.

--
Dean

  ----- Original Message -----=20
  From: Mark Watson=20
  To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben Campbell'=20
  Cc: simple=20
  Sent: Monday, September 17, 2001 9:39 AM
  Subject: RE: [Simple] Implicit MESSAGE sessions revisited


  Dean,=20

  Do you mean that you don't see the advantage of using INVITE to set up =
an IM 'session' (indicating this in the SDP), or just that once such a =
session is set up, there is no need for the 'media' to use any different =
protocol than that used for 'paging' ?

  I think there are a lot of reasons why IM 'sessions' set up using =
INVITE just like any other SIP session, make sense. I don't care much =
yet what the transport protocol then is for the IMs in the session.

  Sorry if this is covering old ground.=20

  ...Mark=20





  > -----Original Message-----=20
  > From: Dean Willis [mailto:dean.willis@softarmor.com]=20
  > Sent: 15 September 2001 05:31=20
  > To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'=20
  > Cc: simple=20
  > Subject: Re: [Simple] Implicit MESSAGE sessions revisited=20
  >=20
  >=20
  >=20
  > Just as MESSAGE for sessions has all the wasted overhead of=20
  > headers and=20
  > routing mechanisms designed to find users and traverse=20
  > firewalls (assuming=20
  > you think this is a waste), so does BEEP.=20
  >=20
  > I personally have yet to see the need for message sessions as=20
  > a specialized=20
  > transport.=20
  >=20
  > I think "pager" messages carrying a session-ID and sequence number =
can=20
  > provide the same user experience.=20
  >=20
  > --=20
  > dean=20
  >=20
  >=20
  > ----- Original Message -----=20
  > From: "Patil Basavaraj (NET/Dallas)" =20
  > To: "'ext Ben Campbell'" =20
  > Cc: =20
  > Sent: Friday, September 14, 2001 1:07 PM=20
  > Subject: RE: [Simple] Implicit MESSAGE sessions revisited=20
  >=20
  >=20
  > >=20
  > > One of the protocols that has been suggested for use instead of=20
  > > MESSAGE is BEEP. Are there any serious concerns *at this time*=20
  > > why BEEP would not be good eniugh for IM Sessions?=20
  > >=20
  > > -Basavaraj=20
  > >=20
  > >=20
  > > _______________________________________________=20
  > > simple mailing list=20
  > > simple@mailman.dynamicsoft.com=20
  > > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
  > >=20
  > >=20
  >=20
  > _______________________________________________=20
  > simple mailing list=20
  > simple@mailman.dynamicsoft.com=20
  > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
  >=20


------=_NextPart_000_00EE_01C13F6C.6651A890
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: [Simple] Implicit MESSAGE sessions =
revisited






Both, actually. I believe the issues =
are=20
independent.


 


--
Dean


 



  
----- Original Message ----- 

  From:=20
  Mark Watson 
  
To: 'Dean Willis' ; Patil=20
  Basavaraj (NET/Dallas) ; 'ext Ben Campbell' =


  
Cc: simple 

  
Sent: Monday, September 17, =
2001 9:39=20
  AM

  
Subject: RE: [Simple] Implicit =
MESSAGE=20
  sessions revisited

  


  
Dean, 

  
Do you mean that you don't see the advantage of =
using INVITE=20
  to set up an IM 'session' (indicating this in the SDP), or just that =
once such=20
  a session is set up, there is no need for the 'media' to use any =
different=20
  protocol than that used for 'paging' ?

  
I think there are a lot of reasons why IM 'sessions' =
set up=20
  using INVITE just like any other SIP session, make sense. I don't care =
much=20
  yet what the transport protocol then is for the IMs in the =
session.

  
Sorry if this is covering old ground. 

  
...Mark 




  
> -----Original Message----- 
>=20
  From: Dean Willis [mailto:dean.willis@softarmor.co=
m]=20
  
> Sent: 15 September 2001 05:31 
> To: Patil Basavaraj (NET/Dallas); 'ext Ben =
Campbell'=20
  
> Cc: simple 
> =
Subject: Re:=20
  [Simple] Implicit MESSAGE sessions revisited 
>=20
  
> 
> =

> Just as MESSAGE for sessions has all the wasted overhead =
of=20
  
> headers and 
> routing=20
  mechanisms designed to find users and traverse 
>=20
  firewalls (assuming 
> you think this is a =
waste),=20
  so does BEEP. 
> 
> I=20
  personally have yet to see the need for message sessions as =

> a specialized 
> =
transport.=20
  
> 
> I think "pager" =
messages=20
  carrying a session-ID and sequence number can 
>=20
  provide the same user experience. 
>=20
  
> -- 
> =
dean=20
  
> 
> =

> ----- Original Message ----- 
> From:=20
  "Patil Basavaraj (NET/Dallas)" =
<Basavaraj.Patil@nokia.com>=20
  
> To: "'ext Ben Campbell'"=20
  <bcampbell@dynamicsoft.com> 
> Cc:=20
  <simple@mailman.dynamicsoft.com> 
> =
Sent:=20
  Friday, September 14, 2001 1:07 PM 
> =
Subject: RE:=20
  [Simple] Implicit MESSAGE sessions revisited 
>=20
  
> 
> =
>=20
  
> > One of the protocols that has been =
suggested for=20
  use instead of 
> > MESSAGE is BEEP. =
Are there=20
  any serious concerns *at this time* 
> =
> why BEEP=20
  would not be good eniugh for IM Sessions? 
>=20
  > 
> > -Basavaraj 
>=20
  > 
> > 
> >=20
  _______________________________________________ 
>=20
  > simple mailing list 
> >=20
  simple@mailman.dynamicsoft.com 
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
  
> > 
> =
> 
> 
>=20
  _______________________________________________ 
>=20
  simple mailing list 
>=20
  simple@mailman.dynamicsoft.com 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
  
> 


------=_NextPart_000_00EE_01C13F6C.6651A890--


From mwatson@nortelnetworks.com  Mon Sep 17 13:03:14 2001
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01891
	for ; Mon, 17 Sep 2001 13:03:14 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f8HH36g05176
	for ; Mon, 17 Sep 2001 18:03:06 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Mon, 17 Sep 2001 18:02:49 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id ;
          Mon, 17 Sep 2001 18:02:47 +0100
Message-ID: 
From: "Mark Watson" 
To: "'Dean Willis'" ,
        "Patil Basavaraj (NET/Dallas)" ,
        "'ext Ben Campbell'" 
Cc: simple 
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Mon, 17 Sep 2001 18:02:37 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C13F9A.8DCF96B0"
Content-Length: 14376
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: 

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_01C13F9A.8DCF96B0
Content-Type: text/plain;
	charset="iso-8859-1"

Dean,
 
I agree that they're independent. On the first one, I had thought that the
idea of IM 'sessions' fulfilled two key requirements:
 
1) I want to find my desired called party, and then exchange multiple
messages with this person
 
Some of these things which can happen (in the network/UEs) as a SIP message
finds the desired end-user may take time/cost money/require user
interaction, and I don't want to repeat them once I have found the person I
want to chat to. Also, there is no guarantee that repeating the process at a
later time will get me to the same end-user. So, I want to be able to do a
'session setup' and then send messages directly to the person I've found.
 
Of course, I could just treat the first message as an implicit session
setup, but this seems to be out of fashion.
 
2) I want IM to be just another media that I can negotiate, add & remove
from a session etc.
 
Again, I could do something clever with Call IDs to connect a MESSAGE
message with a pre-existing session etc. etc., but why should I make an
exception for this one kind of media. If I do that, then no capabilities
that I have now or invent in the future which are supposed to be 'media type
independent', will work for IM, and I will have to be hacking the IM system
constantly to keep up.
 
Did you disagree with these requirements, or just with the implementation ?
 
Regards...Mark

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 17 September 2001 17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); 'ext Ben
Campbell'
Cc: simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited


Both, actually. I believe the issues are independent.
 
--
Dean
 

----- Original Message ----- 
From: Mark Watson   
To: 'Dean Willis'   ; Patil Basavaraj
(NET/Dallas)   ; 'ext
 Ben Campbell' 
Cc: simple   
Sent: Monday, September 17, 2001 9:39 AM
Subject: RE: [Simple] Implicit MESSAGE sessions revisited


Dean, 

Do you mean that you don't see the advantage of using INVITE to set up an IM
'session' (indicating this in the SDP), or just that once such a session is
set up, there is no need for the 'media' to use any different protocol than
that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set up using INVITE
just like any other SIP session, make sense. I don't care much yet what the
transport protocol then is for the IMs in the session.

Sorry if this is covering old ground. 

...Mark 




> -----Original Message----- 
> From: Dean Willis [ mailto:dean.willis@softarmor.com
 ] 
> Sent: 15 September 2001 05:31 
> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell' 
> Cc: simple 
> Subject: Re: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> 
> Just as MESSAGE for sessions has all the wasted overhead of 
> headers and 
> routing mechanisms designed to find users and traverse 
> firewalls (assuming 
> you think this is a waste), so does BEEP. 
> 
> I personally have yet to see the need for message sessions as 
> a specialized 
> transport. 
> 
> I think "pager" messages carrying a session-ID and sequence number can 
> provide the same user experience. 
> 
> -- 
> dean 
> 
> 
> ----- Original Message ----- 
> From: "Patil Basavaraj (NET/Dallas)"  
> To: "'ext Ben Campbell'"  
> Cc:  
> Sent: Friday, September 14, 2001 1:07 PM 
> Subject: RE: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> > 
> > One of the protocols that has been suggested for use instead of 
> > MESSAGE is BEEP. Are there any serious concerns *at this time* 
> > why BEEP would not be good eniugh for IM Sessions? 
> > 
> > -Basavaraj 
> > 
> > 
> > _______________________________________________ 
> > 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_01C13F9A.8DCF96B0
Content-Type: text/html;
	charset="iso-8859-1"




RE: [Simple] Implicit MESSAGE sessions revisited






Dean,


 


I 
agree that they're independent. On the first one, I had thought that the 
idea of IM 'sessions' fulfilled two key requirements:


 


1) I 
want to find my desired called party, and then exchange multiple messages with 
this person


 


Some 
of these things which can happen (in the network/UEs) as a SIP message finds the 
desired end-user may take time/cost money/require user interaction, and I don't 
want to repeat them once I have found the person I want to chat to. Also, there 
is no guarantee that repeating the process at a later time will get me to the 
same end-user. So, I want to be able to do a 'session setup' and then send 
messages directly to the person I've found.


 


Of 
course, I could just treat the first message as an implicit session setup, but 
this seems to be out of fashion.


 


2) I 
want IM to be just another media that I can negotiate, add & remove from a 
session etc.


 


Again, I could do something clever with Call IDs to 
connect a MESSAGE message with a pre-existing session etc. etc., but why should 
I make an exception for this one kind of media. If I do that, then no 
capabilities that I have now or invent in the future which are supposed to be 
'media type independent', will work for IM, and I will have to be hacking the IM 
system constantly to keep up.


 


Did 
you disagree with these requirements, or just with the implementation 
?


 


Regards...Mark



  
-----Original Message-----
From: Dean Willis 
  [mailto:dean.willis@softarmor.com]
Sent: 17 September 2001 
  17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj 
  (NET/Dallas); 'ext Ben Campbell'
Cc: simple
Subject: Re: 
  [Simple] Implicit MESSAGE sessions revisited


  
Both, actually. I believe the issues are 
  independent.

  
 

  
--
Dean

  
 

  

    
----- Original Message ----- 

    
    
    
Cc: simple 

    
Sent: Monday, September 17, 2001 9:39 
    AM

    
Subject: RE: [Simple] Implicit MESSAGE 
    sessions revisited

    


    
Dean, 

    
Do you mean that you don't see the advantage of using INVITE 
    to set up an IM 'session' (indicating this in the SDP), or just that once 
    such a session is set up, there is no need for the 'media' to use any 
    different protocol than that used for 'paging' ?

    
I think there are a lot of reasons why IM 'sessions' set up 
    using INVITE just like any other SIP session, make sense. I don't care much 
    yet what the transport protocol then is for the IMs in the 
    session.

    
Sorry if this is covering old ground. 

    
...Mark 




    
> -----Original Message----- 
> 
    From: Dean Willis [mailto:dean.willis@softarmor.com] 
    
> Sent: 15 September 2001 05:31 
> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell' 
    
> Cc: simple 
> Subject: Re: 
    [Simple] Implicit MESSAGE sessions revisited 
> 
    
> 
> 
> Just as MESSAGE for sessions has all the wasted overhead of 
    
> headers and 
> 
    routing mechanisms designed to find users and traverse 
> firewalls (assuming 
> you think this 
    is a waste), so does BEEP. 
> 
> I personally have yet to see the need for message sessions as 
    
> a specialized 
> 
    transport. 
> 
> I think 
    "pager" messages carrying a session-ID and sequence number can 
    
> provide the same user experience. 
> 
> -- 
> 
    dean 
> 
> 
    
> ----- Original Message ----- 
> From: "Patil Basavaraj (NET/Dallas)" 
    <Basavaraj.Patil@nokia.com> 
> To: "'ext Ben 
    Campbell'" <bcampbell@dynamicsoft.com> 
> 
    Cc: <simple@mailman.dynamicsoft.com> 
> 
    Sent: Friday, September 14, 2001 1:07 PM 
> 
    Subject: RE: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> 
    > 
> > One of the protocols that has been 
    suggested for use instead of 
> > MESSAGE is 
    BEEP. Are there any serious concerns *at this time* 
> > why BEEP would not be good eniugh for IM Sessions? 
    
> > 
> > 
    -Basavaraj 
> > 
> 
    > 
> > 
    _______________________________________________ 
> 
    > 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_01C13F9A.8DCF96B0--

From rrroy@att.com  Mon Sep 17 13:31:35 2001
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 NAA02004
	for ; Mon, 17 Sep 2001 13:31:25 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f8HHV8309980;
	Mon, 17 Sep 2001 13:31:08 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id NAA14930; Mon, 17 Sep 2001 13:31:18 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 17 Sep 2001 13:31:07 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Dean Willis 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Mon, 17 Sep 2001 13:31:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 928
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: 

[DW] I'm proposing providing
the concept of a "session" as a sequence of messages, with that sequence
association being indicated at the application rather than transport layer.

For example, the message body itself might contain a session identifier and
a sequence number.

This would allow the receiving client to render messages into appropriate
windows in an appropriate order, as appropriate to the implementation,
without the transport layer being aware of that behavior.

[RRR] I guess that it is quite possible. One of the possible suggestions to
achieve the objectives:

1. Establish the MESSAGE session as another media. This session ID will
serve as the global identifier.

2. Let this media to have multiple sequence of messages as a part of the
MESSAGE session (as if, videos within a video). 
These sequences of messages will serve as the sub-IDs of the global
identifier of item 1.

Radhika R. Roy
rrroy@att.com


From pkyzivat@cisco.com  Mon Sep 17 13:35:11 2001
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 NAA02057
	for ; Mon, 17 Sep 2001 13:35:11 -0400 (EDT)
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 f8HHYVv09257
	for ; Mon, 17 Sep 2001 13:34:35 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAA68822 (AUTH pkyzivat);
	Mon, 17 Sep 2001 13:36:05 -0400 (EDT)
Message-ID: <3BA63403.10C81113@cisco.com>
Date: Mon, 17 Sep 2001 13:33:56 -0400
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: simple 
Subject: [Fwd: Re: [Simple] Implicit MESSAGE sessions revisited]
Content-Type: multipart/alternative;
 boundary="------------F9A0A5DDF5D90A19D33244AB"
Content-Length: 9550
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: 

--------------F9A0A5DDF5D90A19D33244AB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dean,

So, you don't you don't see the advantage of using INVITE to set up an
IM 'session' (indicating this in the SDP)? Why not? Without this, you
lose the ability to:
- associate the IM session with other related media sessions that should
be used together;
- transfer the IM session to another endpoint while retaining its
identity as a session;
- transfer a grouping of media sessions as a unit if IM is involved.

I agree that the ability to do this is independent of how the session
content is transported. It is certainly *possible* to introduce a
session via SDP, but have that session multiplexed on a common transport
by the application level. I believe there are a number of problems with
that, but it is certainly an appropriate subject for discussion.

But first it is important to agree that it must be possible to negotiate
these sessions by the exchange of SDP. I know there are people other
than myself who believe this is essential. I don't have a good sense of
how many disagree. This is an essential point to resolve.

    Paul Kyzivat
    Cisco Systems

Dean Willis wrote:
>
> No, we're clearly thinking something different here. I'm proposing
providing
> the concept of a "session" as a sequence of messages, with that
sequence
> association being indicated at the application rather than transport
layer.
>
> For example, the message body itself might contain a session
identifier and
> a sequence number.
>
> This would allow the receiving client to render messages into
appropriate
> windows in an appropriate order, as appropriate to the implementation,

> without the transport layer being aware of that behavior.
>
> --
> Dean
>
> ----- Original Message -----
> From: "Henning G. Schulzrinne" 
> To: "Dean Willis" 
> Cc: 
> Sent: Saturday, September 15, 2001 9:34 AM
> Subject: Re: [Simple] Implicit MESSAGE sessions revisited
>
[snip]
> > Just for clarification:
> >
> > Are you assuming that TCP (or, presumably, SCTP) is used? Are you
> > assuming that the TCP connection is kept open implicitly?
> >
> > (To avoid artificial disagreement: I would agree that a regular SIP
> > session over TCP would address most of the requirements, but just
saying
> > "paging" isn't quite enough.)
[snip]


-------- Original Message --------
   Subject: Re: [Simple] Implicit MESSAGE sessions revisited
      Date: Mon, 17 Sep 2001 11:32:14 -0500
      From: "Dean Willis" 
        To: "Mark Watson" ,"Patil Basavaraj
            \(NET/Dallas\)" ,"'ext Ben Campbell'"
            
        CC: "simple" 
References: 

Both, actually. I believe the issues are independent. --
Dean

     ----- Original Message -----
     From: Mark Watson
     To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben
     Campbell'
     Cc: simple
     Sent: Monday, September 17, 2001 9:39 AM
     Subject: RE: [Simple] Implicit MESSAGE sessions revisited
      Dean,

     Do you mean that you don't see the advantage of using INVITE
     to set up an IM 'session' (indicating this in the SDP), or
     just that once such a session is set up, there is no need for
     the 'media' to use any different protocol than that used for
     'paging' ?

     I think there are a lot of reasons why IM 'sessions' set up
     using INVITE just like any other SIP session, make sense. I
     don't care much yet what the transport protocol then is for
     the IMs in the session.

     Sorry if this is covering old ground.

     ...Mark

--------------F9A0A5DDF5D90A19D33244AB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




Dean,

So, you don't you don't see the advantage of using INVITE to set up
an IM 'session' (indicating this in the SDP)? Why not? Without this, you
lose the ability to:

- associate the IM session with other related media sessions that should
be used together;

- transfer the IM session to another endpoint while retaining its identity
as a session;

- transfer a grouping of media sessions as a unit if IM is involved.

I agree that the ability to do this is independent of how the session
content is transported. It is certainly *possible* to introduce a session
via SDP, but have that session multiplexed on a common transport by the
application level. I believe there are a number of problems with that,
but it is certainly an appropriate subject for discussion.

But first it is important to agree that it must be possible to negotiate
these sessions by the exchange of SDP. I know there are people other than
myself who believe this is essential. I don't have a good sense of how
many disagree. This is an essential point to resolve.

    Paul Kyzivat

    Cisco Systems

Dean Willis wrote:

>

> No, we're clearly thinking something different here. I'm proposing
providing

> the concept of a "session" as a sequence of messages, with that sequence

> association being indicated at the application rather than transport
layer.

>

> For example, the message body itself might contain a session identifier
and

> a sequence number.

>

> This would allow the receiving client to render messages into appropriate

> windows in an appropriate order, as appropriate to the implementation,

> without the transport layer being aware of that behavior.

>

> --

> Dean

>

> ----- Original Message -----

> From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>

> To: "Dean Willis" <dean.willis@softarmor.com>

> Cc: <simple@mailman.dynamicsoft.com>

> Sent: Saturday, September 15, 2001 9:34 AM

> Subject: Re: [Simple] Implicit MESSAGE sessions revisited

>

[snip]

> > Just for clarification:

> >

> > Are you assuming that TCP (or, presumably, SCTP) is used? Are you

> > assuming that the TCP connection is kept open implicitly?

> >

> > (To avoid artificial disagreement: I would agree that a regular
SIP

> > session over TCP would address most of the requirements, but just
saying

> > "paging" isn't quite enough.)

[snip]

 

-------- Original Message --------




Subject: 

Re: [Simple] Implicit MESSAGE sessions revisited





Date: 

Mon, 17 Sep 2001 11:32:14 -0500





From: 

"Dean Willis" <dean.willis@softarmor.com>





To: 

"Mark Watson" <mwatson@nortelnetworks.com>,"Patil Basavaraj \(NET/Dallas\)"
<Basavaraj.Patil@nokia.com>,"'ext Ben Campbell'" <bcampbell@dynamicsoft.com>





CC: 

"simple" <simple@mailman.dynamicsoft.com>





References: 

<A3C2399B2FACD411A54200508BE39C7402E845A1@zwcwd00r.europe.nortel.com>







Both, actually. I believe
the issues are independent. --

Dean 



----- Original Message -----







Cc: simple



Sent: Monday, September 17, 2001 9:39
AM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

 Dean,

Do you mean that you don't see the advantage of using
INVITE to set up an IM 'session' (indicating this in the SDP), or just
that once such a session is set up, there is no need for the 'media' to
use any different protocol than that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set
up using INVITE just like any other SIP session, make sense. I don't care
much yet what the transport protocol then is for the IMs in the session.

Sorry if this is covering old ground.

...Mark





--------------F9A0A5DDF5D90A19D33244AB--


From rrroy@att.com  Mon Sep 17 14:09:12 2001
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 OAA02179
	for ; Mon, 17 Sep 2001 14:09:11 -0400 (EDT)
Received: from mo3980r1.ems.att.com ([135.38.12.14])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f8HI8hi03715;
	Mon, 17 Sep 2001 14:08:43 -0400 (EDT)
Received: from njb140bh3.ems.att.com by mo3980r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id OAA11694; Mon, 17 Sep 2001 14:04:04 -0400 (EDT)
Received: by njb140bh3.ems.att.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 17 Sep 2001 14:08:43 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Paul Kyzivat ,
        Dean Willis
	 
Cc: simple 
Subject: RE: [Fwd: Re: [Simple] Implicit MESSAGE sessions revisited]
Date: Mon, 17 Sep 2001 14:08:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C13FA3.C3E1F870"
Content-Length: 4480
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: 

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_01C13FA3.C3E1F870
Content-Type: text/plain;
	charset="iso-8859-1"

[PK]  So, you don't you don't see the advantage of using INVITE to set up an
IM 'session' (indicating this in the SDP)? Why not? Without this, you lose
the ability to: 
- associate the IM session with other related media sessions that should be
used together; 
- transfer the IM session to another endpoint while retaining its identity
as a session; 
- transfer a grouping of media sessions as a unit if IM is involved. 


I agree that the ability to do this is independent of how the session
content is transported. It is certainly *possible* to introduce a session
via SDP, but have that session multiplexed on a common transport by the
application level. I believe there are a number of problems with that, but
it is certainly an appropriate subject for discussion. 


But first it is important to agree that it must be possible to negotiate
these sessions by the exchange of SDP. I know there are people other than
myself who believe this is essential. I don't have a good sense of how many
disagree. This is an essential point to resolve. 


[Roy, Radhika R, ALARC]  I agree with Paul that SDP is a tool in SIP that
helps to meet a variety of requirements including the above. In addition, a
stream of messages as a part of the MESSAGE session, as Dean mentioned in
his earlier message, can also  be satisfied using SDP. So, the suggestion
is: Let us write all requirements of a message session that needs to be
performed and, examine each requirement why it cannot be performed using
SDP. At that point, we can examine the detail proposal(s), if any, of the
MESSAGE session alternative to the SDP solution. 


Radhika R. Roy 


rrroy@att.com  


------_=_NextPart_001_01C13FA3.C3E1F870
Content-Type: text/html;
	charset="iso-8859-1"










  
[PK] 
   So, you don't you don't see the advantage of using INVITE 
  to set up an IM 'session' (indicating this in the SDP)? Why not? Without this, 
  you lose the ability to: 
- associate the IM session with other related 
  media sessions that should be used together; 
- transfer the IM session to 
  another endpoint while retaining its identity as a session; 
- transfer a 
  grouping of media sessions as a unit if IM is involved. 
  
I agree that the ability to do this is independent of how the session 
  content is transported. It is certainly *possible* to introduce a session via 
  SDP, but have that session multiplexed on a common transport by the 
  application level. I believe there are a number of problems with that, but it 
  is certainly an appropriate subject for discussion. 
  
But first it is important to agree that it must be possible to negotiate 
  these sessions by the exchange of SDP. I know there are people other than 
  myself who believe this is essential. I don't have a good sense of how many 
  disagree. This is an essential point to resolve. 
  
[Roy, 
  Radhika R, ALARC]  I agree with Paul that SDP is a tool in SIP that 
  helps to meet a variety of requirements including the above. In addition, 
  a stream of messages as a part of the MESSAGE session, as Dean mentioned in 
  his earlier message, can also  be satisfied using SDP. So, the suggestion 
  is: Let us write all requirements of a message session that needs to be 
  performed and, examine each requirement why it cannot be performed using SDP. 
  At that point, we can examine the detail proposal(s), if any, of the MESSAGE 
  session alternative to the SDP solution.
  
Radhika R. Roy
  
rrroy@att.com


------_=_NextPart_001_01C13FA3.C3E1F870--

From rsparks@dynamicsoft.com  Mon Sep 17 14:32:48 2001
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 OAA02292
	for ; Mon, 17 Sep 2001 14:32:48 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8HIVj8P020751
	for ; Mon, 17 Sep 2001 14:31:45 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 17 Sep 2001 14:32:43 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E5DB@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: simple 
Subject: RE: [Fwd: Re: [Simple] Implicit MESSAGE sessions revisited]
Date: Mon, 17 Sep 2001 14:32:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C13FA7.22A7B8B0"
Content-Length: 1129
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: 

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_01C13FA7.22A7B8B0
Content-Type: text/plain;
	charset="iso-8859-1"

If you've not yet reviewed draft-ietf-simple-presence-02, please do so
before returning to this thread.
 
RjS

------_=_NextPart_001_01C13FA7.22A7B8B0
Content-Type: text/html;
	charset="iso-8859-1"









If 
you've not yet reviewed draft-ietf-simple-presence-02, please do 
so


before 
returning to this thread.


 


RjS


------_=_NextPart_001_01C13FA7.22A7B8B0--

From HUITEMA@windows.microsoft.com  Mon Sep 17 14:53:39 2001
Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA02384
	for ; Mon, 17 Sep 2001 14:53:38 -0400 (EDT)
Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 11:52:53 -0700
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);
	 Mon, 17 Sep 2001 11:52:51 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 17 Sep 2001 11:52:50 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 17 Sep 2001 11:52:04 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Mon, 17 Sep 2001 11:51:59 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Implicit MESSAGE sessions revisited
Thread-Index: AcE9SQEfuTCKWKk4EdWJUwAIx6TWpQAASvugAJfL5UA=
From: "Christian Huitema" 
To: "Patil Basavaraj (NET/Dallas)" ,
        
Cc: 
X-OriginalArrivalTime: 17 Sep 2001 18:52:04.0542 (UTC) FILETIME=[D7C995E0:01C13FA9]
Content-Length: 1812
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA02384
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: 

Since the use of BEEP is minuscule so far, the reuse argument is pretty
weak. I would much rather reuse Message, and if not that, then SOAP.

-- Christian Huitema

> -----Original Message-----
> From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
> Sent: Friday, September 14, 2001 11:37 AM
> To: hgs@cs.columbia.edu
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Implicit MESSAGE sessions revisited
> 
> 
> >
> > While BEEP is a useful protocol, I fail to see what
> > advantages it offers
> > compared to "smaller" solutions that don't require as much
> additional
> > infrastructure and end system complexity.
> >
> 
> Do we really need yet another (AL) protocol is what I had in mind.
> Whether
> BEEP has advantages should be evaluated against whether BEEP can
> satisfy the requirements for IM sessions.
> 
> -Reuse Vs Reinventing something else. The problem with the reinvention
> is that by the time the "smaller" solution has addressed all the
> requirements
> and concerns, it ends up looking something that already exists and the
> argument of simplicity is gone.
> 
> -Reuse of BEEP also means getting the IM for sessions spec/solution
> done
> 
> faster. If the IM for Sessions spec focused on getting the signaling
> part done
> and not have to worry about how to transport the data, that would
> simplify the
> spec and
> 
> 
> > "Patil Basavaraj (NET/Dallas)" wrote:
> > >
> > > One of the protocols that has been suggested for use instead of
> > > MESSAGE is BEEP. Are there any serious concerns *at this time*
> > > why BEEP would not be good eniugh for IM Sessions?
> > >
> > > -Basavaraj
> > >
> >
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From jdrosen@dynamicsoft.com  Tue Sep 18 06:57:24 2001
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 GAA05252
	for ; Tue, 18 Sep 2001 06:57:24 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8IAuK8P024805;
	Tue, 18 Sep 2001 06:56:20 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Sep 2001 06:57:17 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Patil Basavaraj (NET/Dallas)'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
Date: Tue, 18 Sep 2001 06:57:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1733
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: 

my apologies for an extensive absence from the list... I've been on
vacation. Comments below.

 

> -----Original Message-----
> From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
> Sent: Friday, September 14, 2001 4:00 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Comment: draft-ietf-simple-presence-02
> 
> 
> 
> Non-critical issue:
> 
> Section 5.3 (Paragraph 3) defines a default filter. However
> I do not see the need for bullet 3 wherein additional markup
> is sent (if < 50 bytes). It is better to have a consistent mechanism
> of sending any markup (irrespective of size) only if explicitly
> requested
> by the subscriber or just send all the markup as the default. 

The problem is that in rfc2778, "additional markup" can be almost anything.
Always sending it might imply, down the road, sending huge jpeg files with
pictures of the user. I'm not sure you want that to be the default.

Never sending it also has problems. Looking at draft-ietf-impp-cpim-pidf,
this would mean that the "note" element would never be sent unless
explicitly requested, since it is neither status or contact information. I
suspect the note will be used often, and I want to make sure its included in
the normal case. 

So, I put this middle-ground sentence in to make sure that the small stuff
goes, and the bigger stuff needs to be requested.

-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

From jdrosen@dynamicsoft.com  Tue Sep 18 07:28:33 2001
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 HAA05385
	for ; Tue, 18 Sep 2001 07:28:33 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8IBRQ8P024926;
	Tue, 18 Sep 2001 07:27:26 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Sep 2001 07:28:24 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brian Stucker'" ,
        "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Questions on the current presence draft.
Date: Tue, 18 Sep 2001 07:28:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5380
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: 


  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Tuesday, September 11, 2001 3:30 PM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] Questions on the current presence draft.


>I was reading through the current draft, and noticed a few things that I 
>was looking for clairification on. 
>In the section on presence migration, the last sentence of the description 
>for the second phase of presence migration states: "...This informs the
subscribers that 
>their 
>subscription was destroyed, and should be re-established with a new
SUBSCRIBE (with a new 
>Call-ID)." 
>I was wondering, if a watcher was offline when the NOTIFY containing the
"Subscription-
>Expires" header 
>to destroy the current subscription, what are the implications with the
call id? I would 
>imagine when the 
>watcher comes back online, and tries to refresh the subscription, it would
use the old 
>call-id (since it doesn't 
>know that it needs to reselect), which gets proxied to the new PA (after
the migration 
>occurred). This seems like a gap to me.

There are two cases here. In case 1, when the subscriber goes "offline", all
subscriptions state is lost. This would happen when a PC application is
terminated, for example. In that case, when the watcher comes back, it will
have no record of previous subscription state. So, it creates a new
subscription with a brand new call ID. No problems.

In case 2, the subscriber goes "offline" in the sense that its network
connectivity is lost, so it won't get the NOTIFY, but it still retains
subscription state. THis would be the case, for example, with a mobile phone
that goes out of range. When the mobile comes back in range, it will
re-subscribe with the old call-id/route-set, in order to obtain the latest
data it may have missed while out of range. Since this subscribe has a route
set, the request will arrive at the presence server (the one that formerly
owned the subscriptions, but has since migrated them) with the URL of the
presence server in the request URI (like sip:presence-server-1.foo.com).
Since the URL points to itself, the presence server knows that it should
process it. Since no subscriptions exist, this request would be rejected
with a 481. Should it be proxied anyway to the PUA now handling the
subscription, it would probably also be rejected with a 481 because the tags
don't match those of any existing subscriptions at the PUA.

The 481 would trigger the subscriber to retry the subscription with a fresh
call-id and no route set.

The specifications are not clear at the moment about the handling of the
case when you get a subscribe with a tag in the To field that doesn't match
an existing subscription. That needs to be clarified in the events framework
spec. I'll send a note to Adam about it.

>
>Also, what happens if the watchers (previous to the migration) never
receive the NOTIFY to 
>update their 
>subscriptions to cause a refresh. Unless they do a fetch, the new PA
doesn't know that 
>they exist, so their 
>subscriptions will be effectively moot, but they won't be aware of this
fact. They won't 
>get any notifications, and 
>won't know that their subscriptions are being ignored. 

I think this is the same problem I discussed above. The question you need to
ask is why the watcher would not have gotten the NOTIFY. Assuming the
watcher application is running the whole time, the only reason this would
occur is a network failure of some sort, or a failure of the presence server
itself. Network failures that occur because the mobile has gone out of range
are generally detectable, and so the mobile can do something about it.
Network failures in the middle of the network which occur for long enough to
prevent a notification from being delivered (in excess of 16s) are hard to
deal with in any protocol. A "nice" presence agent could retain the
subscription state unless it gets a positive response to the NOTIFY, but
that can be used as a DoS attack. So, I don't know how solve this particular
failure case. There will be a gap in the delivery of notifications for the
duration of a refresh period. Given the scope of the failure that must occur
for that to happen, I think thats acceptable. 

Failures of the presence server itself can be handled using traditional
mechanisms, such as replication of subscription state to a hot standby.


>
>In section 8, there are mixed uses of the presence URL and SIP URL's. Is
this done 
>intentionally? 

No. My error. I've changed them all to sip URLs. Thanks.

>
>Finally, can someone point a link to the draft listed as [4] in the
bibliography? It 
>doesn't seem to be available 
>at the IETF webpage. 

It just recently expired. The impp chairs have been pinging the editor to
resubmit an update. 

Until then, you can get a copy from google's cached version of the draft:
http://www.google.com/search?q=cache:jdFIIPRBPY0:www.ietf.org/internet-draft
s/draft-ietf-impp-cpim-01.txt+draft-ietf-impp-cpim&hl=en

Thanks for your comments,
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

From jdrosen@dynamicsoft.com  Tue Sep 18 07:58:49 2001
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 HAA05513
	for ; Tue, 18 Sep 2001 07:58:49 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8IBvf8P025088;
	Tue, 18 Sep 2001 07:57:41 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Sep 2001 07:58:39 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Robert Brown'" ,
        Avshalom Houri
	 , simple@mailman.dynamicsoft.com
Cc: "Adam Roach (E-mail)" 
Subject: RE: [Simple] Partial Notifies?
Date: Tue, 18 Sep 2001 07:58:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4654
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: 

This thread fell on the floor, but its a real important one and I want to
get it going again. Its probably the biggest open issue for the presence
spec, which is currently in wglc, so addressing it is really a higher
priority than the IM session discussion.

I think that partial updates is probably a really good thing. I'd like to
make sure it is adequately supported in the right way.

Now, the question is, where does such support belong? Is it a per-package
thing? Or is it something in the sip-events framework? I would argue that
each package be able to define whether it does or doesn't use partial
notifies, but that the mechanism for doing them be shared across all
packages. For example, if we add a header like Last-Data-Received: with a
hash of the body, as Dror had proposed, I think this header belongs in the
sip-events specification.

I believe the requirements for the partial notifications are the following:

1. the subscribe request have a way for the subscriber to indicate what
version they have, so that the notify only contain a delta from that version
(indeed, perhaps the notify isn't even sent if the version the subscriber
has is up to date)

2. the notify have a way to indicate what version of the document the
subscriber will have once the patch is applied

3. the notify have a way to indicate what version the of the document the
subscriber has to apply the patch against (i.e, the old version)

4. the "patch" be in a format that is independent of the format of the
presence document. 


Number 4 is important, I think, to avoid needing to specify updates and
partial notifies within every event document format. We just do it once, and
then each event package doesn't need to ever worry about it again. 

Anders Kristensen had pointed out to me that webdav has looked at a very
similar problem, and that there are specs for deltas within http. I haven't
looked at those in detail, but they might provide a solution for us that
would allow us to reuse existing work elsewhere in IETF.

So, the quesitons to be discussed, in order, are:

1. is there consensus that we should have a solution for partial notifies in
simple?

2. is there consensus that this should be done in a general fashion as part
of the sip events specification?

3. how should it be done?

Comments?

-Jonathan R.

 

> -----Original Message-----
> From: Robert Brown [mailto:roberbr@microsoft.com]
> Sent: Wednesday, September 05, 2001 4:41 PM
> To: Avshalom Houri; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Partial Notifies?
> 
> 
> Watcher info can become pretty big too.  It would be nice to receive
> partials that only contained new pending watchers.
> 
> ----- Original Message -----
> From: "Avshalom Houri" 
> To: 
> Sent: Wednesday, September 05, 2001 4:33 AM
> Subject: RE: [Simple] Partial Notifies?
> 
> 
> > > I was actually debating this issue when doing the update 
> of the presence
> >
> > > spec. Its not specified right now, all through the events 
> framework
> allows
> >
> > > each package to define how its done.
> >
> > I think that it should be included since NOTIFY can become 
> big especially
> > given
> >
> > detail/schema/human readable comment.
> >
> > >
> >
> > > One model to do this is something I have proposed for 
> other packages:
> >
> > >
> >
> > > 1. the notify triggered by a subscribe contains the full state
> >
> > > 2. subsequent notifies contain only the piece thats 
> changed (i.e., the
> >
> > > contact address that is different)
> >
> > > 3. the subscriber keeps track of the cseq to see if it 
> may have missed a
> >
> > > notify. If there are no gaps in Cseq, nothing was missed. 
> If there is a
> > gap,
> >
> > > something may have been missed, or else there was an intermediate
> > challenge
> >
> > > or something like that. So, the subscriber re-subscribes to get a
> > triggered
> >
> > > notify with full state.
> >
> > I assume that the granularity will be a single tuple of the 
> presence, and
> > that
> >
> > there will be an operator preceding the tuple for add/delete/update.
> >
> > >
> >
> > > A better way to handle the ordering is for the presence 
> document itself
> to
> >
> > > contain version numbers, but that would require changes 
> in the pidf
> spec.
> >
> > >
> >
> > > Since the initial SUBSCRIBE has to trigger full state anyway,
> idempotency
> > of
> >
> > > SUBSCRIBE would argue for having full state triggered notify for
> refreshes
> >
> > > too.
> >
> > It seems that Dror's suggestion (dror@vocaltec.com) can be 
> helpful here.
> >
> > avshalom
> >
> > Sametime/Lotus/IBM
> >
> >
> >

From jdrosen@dynamicsoft.com  Tue Sep 18 08:10:01 2001
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 IAA05605
	for ; Tue, 18 Sep 2001 08:10:01 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8IC8w8P025204;
	Tue, 18 Sep 2001 08:08:58 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Sep 2001 08:09:55 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Ngo, Dai (c)'" ,
        Jonathan Rosenberg
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Notifier Migration Clarification
Date: Tue, 18 Sep 2001 08:09:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3779
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: 


  
-----Original Message-----
>From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com]
>Sent: Friday, September 14, 2001 4:40 PM
>To: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com
>Subject: RE: [Simple] Notifier Migration Clarification
>
>
>Does this seem inflexible to you? We allow (serial/parallel) forking for
SUBSCRIBE, why 
>not for this? 
>-- Dai 

We do allow SUBSCRIBE to fork, but the spec only allows one of them to
proceed (the one whose 200 OK went to the subscriber). So, I don't mind
changing the text to allow it to fork the SUBSCRIBE in the migration case,
but you should recognize that the effect will be the same - only one of the
forked SUBSCRIBEs will actually be used.

The issue is one of aggregation. Consider a presentity whose presence is
based on the aggregation of presence state from a phone and a PC
application. The question is: how performs the aggregation of that state? I
have argued that the aggregation of presence state is highly policy
dependent, and can only be done properly by an entity in the domain of the
presentity. Thereofre, it makes sense for a server to handle the
subscription, and for it to generate an aggregate presence document that
combines the state of the phone and the PC. If the phone and PC were to each
act as presence agents, both would send notifications of their individual
states to the subscribers. Then, the role of aggregation would lie with the
subscriber. I don't think it belongs there for user presence.

So, forking of subscribe to independent devices, each of which knows its own
presence, is not a good thing. Forking a subscribe to a set of elements,
each of which knows the full presence state of the presentity, is just fine
and perfectly reasonable.

So, my proposal would be this:

1. I add text which says that a PUA only indicate support for SUBSCRIBE in
its registration if it is certain that it has full knowledge of the presence
state of the presentity (although I have no idea how it would know this in
general)

2. migrations are allowed when multiple contacts have registered indicating
support for subscribe.

OK?

-Jonathan R.



-----Original Message----- 
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent: Tuesday, September 04, 2001 5:39 PM 
To: Ngo, Dai (c); simple@mailman.dynamicsoft.com 
Subject: RE: [Simple] Notifier Migration Clarification 




  
-----Original Message----- 
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] 
Sent: Tuesday, September 04, 2001 4:25 PM 
To: simple@mailman.dynamicsoft.com 
Subject: [Simple] Notifier Migration Clarification 


>All, 
>In section 5.12 "State Agents and Notifier Migration" of 
draft-ietf-simple-presence-02.txt 
>it says, "The presence server MAY migrate the subscription if, for a given 
address of 
>record, there is one, and only one registered contact that indicates 
explicit support for 
>the SUBSCRIBE method." 
> 
>What's the behavior of the presence server if there are multiple registered

contacts which 
>explicitly support for the SUBSCRIBE method? 
It can't migrate the PA function. 
-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

From dean.willis@softarmor.com  Tue Sep 18 10:46:08 2001
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 KAA06147
	for ; Tue, 18 Sep 2001 10:46:07 -0400 (EDT)
Received: from flak (localhost.localdomain [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f8IElID29543
	for ; Tue, 18 Sep 2001 09:47:19 -0500
Message-ID: <007001c14050$a9bd6e90$3b2e713f@flak>
From: "Dean Willis" 
To: "simple" 
References: 
Subject: Re: [Simple] Implicit MESSAGE sessions revisited
Date: Tue, 18 Sep 2001 09:46:11 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_006D_01C14026.BFE07DE0"
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
Content-Length: 19477
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_006D_01C14026.BFE07DE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [Simple] Implicit MESSAGE sessions revisited
I agree with #1,sortof. The best (only?) justfication for INVITE-bounded =
message sessions is the use of Record-Route to allow proxies that don't =
need to be in the route to opt out. This allows the SIP-network to be =
"self optimizing" for message routing. However, such SIP paths may be =
necessarily NOT end-to-end. For example, putting a SIP UA behind a =
firewall proxy will require that messages transit the firewall proxy. =
This is easily accomplished with record-route. Remember, all the =
"signaling privacy" requirements like  calling-party-ID and =
address-hiding apply to SIP messages. We already have mechanisms to meet =
those requirements for SIP traffic -- reusing them for messages is =
obviously functional.

I disagree with requirement #2 -- SIP messages are inherently NOT media. =
They are, in effect "user to user signaling". This is consistent with my =
earlier position on the use of phone input (DTMF) as "user to system =
signaling", not media.

--
Dean
  ----- Original Message -----=20
  From: Mark Watson=20
  To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben Campbell'=20
  Cc: simple=20
  Sent: Monday, September 17, 2001 12:02 PM
  Subject: RE: [Simple] Implicit MESSAGE sessions revisited


  Dean,

  I agree that they're independent. On the first one, I had thought that =
the idea of IM 'sessions' fulfilled two key requirements:

  1) I want to find my desired called party, and then exchange multiple =
messages with this person

  Some of these things which can happen (in the network/UEs) as a SIP =
message finds the desired end-user may take time/cost money/require user =
interaction, and I don't want to repeat them once I have found the =
person I want to chat to. Also, there is no guarantee that repeating the =
process at a later time will get me to the same end-user. So, I want to =
be able to do a 'session setup' and then send messages directly to the =
person I've found.

  Of course, I could just treat the first message as an implicit session =
setup, but this seems to be out of fashion.

  2) I want IM to be just another media that I can negotiate, add & =
remove from a session etc.

  Again, I could do something clever with Call IDs to connect a MESSAGE =
message with a pre-existing session etc. etc., but why should I make an =
exception for this one kind of media. If I do that, then no capabilities =
that I have now or invent in the future which are supposed to be 'media =
type independent', will work for IM, and I will have to be hacking the =
IM system constantly to keep up.

  Did you disagree with these requirements, or just with the =
implementation ?

  Regards...Mark
    -----Original Message-----
    From: Dean Willis [mailto:dean.willis@softarmor.com]
    Sent: 17 September 2001 17:32
    To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); =
'ext Ben Campbell'
    Cc: simple
    Subject: Re: [Simple] Implicit MESSAGE sessions revisited


    Both, actually. I believe the issues are independent.

    --
    Dean

      ----- Original Message -----=20
      From: Mark Watson=20
      To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben =
Campbell'=20
      Cc: simple=20
      Sent: Monday, September 17, 2001 9:39 AM
      Subject: RE: [Simple] Implicit MESSAGE sessions revisited


      Dean,=20

      Do you mean that you don't see the advantage of using INVITE to =
set up an IM 'session' (indicating this in the SDP), or just that once =
such a session is set up, there is no need for the 'media' to use any =
different protocol than that used for 'paging' ?

      I think there are a lot of reasons why IM 'sessions' set up using =
INVITE just like any other SIP session, make sense. I don't care much =
yet what the transport protocol then is for the IMs in the session.

      Sorry if this is covering old ground.=20

      ...Mark=20





      > -----Original Message-----=20
      > From: Dean Willis [mailto:dean.willis@softarmor.com]=20
      > Sent: 15 September 2001 05:31=20
      > To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'=20
      > Cc: simple=20
      > Subject: Re: [Simple] Implicit MESSAGE sessions revisited=20
      >=20
      >=20
      >=20
      > Just as MESSAGE for sessions has all the wasted overhead of=20
      > headers and=20
      > routing mechanisms designed to find users and traverse=20
      > firewalls (assuming=20
      > you think this is a waste), so does BEEP.=20
      >=20
      > I personally have yet to see the need for message sessions as=20
      > a specialized=20
      > transport.=20
      >=20
      > I think "pager" messages carrying a session-ID and sequence =
number can=20
      > provide the same user experience.=20
      >=20
      > --=20
      > dean=20
      >=20
      >=20
      > ----- Original Message -----=20
      > From: "Patil Basavaraj (NET/Dallas)"  =

      > To: "'ext Ben Campbell'" =20
      > Cc: =20
      > Sent: Friday, September 14, 2001 1:07 PM=20
      > Subject: RE: [Simple] Implicit MESSAGE sessions revisited=20
      >=20
      >=20
      > >=20
      > > One of the protocols that has been suggested for use instead =
of=20
      > > MESSAGE is BEEP. Are there any serious concerns *at this time* =

      > > why BEEP would not be good eniugh for IM Sessions?=20
      > >=20
      > > -Basavaraj=20
      > >=20
      > >=20
      > > _______________________________________________=20
      > > simple mailing list=20
      > > simple@mailman.dynamicsoft.com=20
      > > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
      > >=20
      > >=20
      >=20
      > _______________________________________________=20
      > simple mailing list=20
      > simple@mailman.dynamicsoft.com=20
      > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
      >=20


------=_NextPart_000_006D_01C14026.BFE07DE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: [Simple] Implicit MESSAGE sessions =
revisited






 


I agree with #1,sortof. The best =
(only?)=20
justfication for INVITE-bounded message sessions is the use of =
Record-Route to=20
allow proxies that don't need to be in the route to opt out. This allows =
the=20
SIP-network to be "self optimizing" for message routing. However, such =
SIP paths=20
may be necessarily NOT end-to-end. For example, putting a SIP UA behind =
a=20
firewall proxy will require that messages transit the firewall proxy. =
This is=20
easily accomplished with record-route. Remember, all the "signaling =
privacy"=20
requirements like  calling-party-ID and address-hiding apply to SIP =

messages. We already have mechanisms to meet those requirements for SIP =
traffic=20
-- reusing them for messages is obviously functional.


 


I disagree with requirement #2 -- SIP =
messages are=20
inherently NOT media. They are, in effect "user to user signaling". This =
is=20
consistent with my earlier position on the use of phone input (DTMF) as =
"user to=20
system signaling", not media.


 


--
Dean



  
----- Original Message ----- 

  From:=20
  Mark Watson 
  
To: 'Dean Willis' ; Patil=20
  Basavaraj (NET/Dallas) ; 'ext Ben Campbell' =


  
Cc: simple 

  
Sent: Monday, September 17, =
2001 12:02=20
  PM

  
Subject: RE: [Simple] Implicit =
MESSAGE=20
  sessions revisited

  


  
Dean,

  
 

  
I=20
  agree that they're independent. On the first one, I had thought =
that the=20
  idea of IM 'sessions' fulfilled two key =
requirements:

  
 

  
1)=20
  I want to find my desired called party, and then exchange multiple =
messages=20
  with this person

  
 

  
Some of these things which can happen (in =
the=20
  network/UEs) as a SIP message finds the desired end-user may take =
time/cost=20
  money/require user interaction, and I don't want to repeat them once I =
have=20
  found the person I want to chat to. Also, there is no guarantee that =
repeating=20
  the process at a later time will get me to the same end-user. So, I =
want to be=20
  able to do a 'session setup' and then send messages directly to the =
person=20
  I've found.

  
 

  
Of=20
  course, I could just treat the first message as an implicit session =
setup, but=20
  this seems to be out of fashion.

  
 

  
2)=20
  I want IM to be just another media that I can negotiate, add & =
remove from=20
  a session etc.

  
 

  
Again, I could do something clever with =
Call IDs to=20
  connect a MESSAGE message with a pre-existing session etc. etc., but =
why=20
  should I make an exception for this one kind of media. If I do that, =
then no=20
  capabilities that I have now or invent in the future which are =
supposed to be=20
  'media type independent', will work for IM, and I will have to be =
hacking the=20
  IM system constantly to keep up.

  
 

  
Did you disagree with these requirements, =
or just=20
  with the implementation ?

  
 

  
Regards...Mark

  

    
-----Original Message-----
From: Dean Willis=20
    [mailto:dean.willis@softarmor.com]
Sent: 17 September 2001 =

    17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj=20
    (NET/Dallas); 'ext Ben Campbell'
Cc: =
simple
Subject: Re:=20
    [Simple] Implicit MESSAGE sessions revisited


    
Both, actually. I believe the =
issues are=20
    independent.

    
 

    
--
Dean

    
 

    

      
----- Original Message ----- =


      From:=20
      Mark Watson 
      
To: 'Dean Willis' ; Patil Basavaraj =
(NET/Dallas) ;=20
      'ext Ben Campbell' =


      
Cc: simple 

      
Sent: Monday, September 17, =
2001 9:39=20
      AM

      
Subject: RE: [Simple] =
Implicit=20
      MESSAGE sessions revisited

      


      
Dean, 

      
Do you mean that you don't see the advantage of =
using=20
      INVITE to set up an IM 'session' (indicating this in the SDP), or =
just=20
      that once such a session is set up, there is no need for the =
'media' to=20
      use any different protocol than that used for 'paging' =
?

      
I think there are a lot of reasons why IM =
'sessions' set=20
      up using INVITE just like any other SIP session, make sense. I =
don't care=20
      much yet what the transport protocol then is for the IMs in the=20
      session.

      
Sorry if this is covering old ground. =


      
...Mark 




      
> -----Original Message----- 
> From: Dean Willis [mailto:dean.willis@softarmor.co=
m]=20
      
> Sent: 15 September 2001 05:31 =

> To: Patil Basavaraj (NET/Dallas); 'ext Ben =
Campbell'=20
      
> Cc: simple 
> =
Subject: Re:=20
      [Simple] Implicit MESSAGE sessions revisited 
>=20
      
> 
> =

> Just as MESSAGE for sessions has all the wasted =
overhead of=20
      
> headers and 
>=20
      routing mechanisms designed to find users and traverse =

> firewalls (assuming 
> =
you think=20
      this is a waste), so does BEEP. 
>=20
      
> I personally have yet to see the =
need for=20
      message sessions as 
> a =
specialized=20
      
> transport. 
>=20
      
> I think "pager" messages carrying a =

      session-ID and sequence number can 
> =
provide=20
      the same user experience. 
> =

> -- 
> dean =

> 
> 
>=20
      ----- Original Message ----- 
> From: =
"Patil=20
      Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com> =

> To: "'ext Ben Campbell'"=20
      <bcampbell@dynamicsoft.com> 
> =
Cc:=20
      <simple@mailman.dynamicsoft.com> 
> Sent:=20
      Friday, September 14, 2001 1:07 PM 
> =
Subject:=20
      RE: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
>=20
      > 
> > One of the protocols that =
has been=20
      suggested for use instead of 
> > =
MESSAGE is=20
      BEEP. Are there any serious concerns *at this time* =

> > why BEEP would not be good eniugh for IM =
Sessions?=20
      
> > 
> >=20
      -Basavaraj 
> > 
>=20
      > 
> >=20
      _______________________________________________ 
> > simple mailing list 
> >=20
      simple@mailman.dynamicsoft.com 
> > =
http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
      
> > 
> =
>=20
      
> 
>=20
      _______________________________________________ 
> simple mailing list 
>=20
      simple@mailman.dynamicsoft.com 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
      
>=20



------=_NextPart_000_006D_01C14026.BFE07DE0--


From dean.willis@softarmor.com  Tue Sep 18 10:50:15 2001
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 KAA06175
	for ; Tue, 18 Sep 2001 10:50:14 -0400 (EDT)
Received: from flak (localhost.localdomain [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f8IEpMD29554;
	Tue, 18 Sep 2001 09:51:22 -0500
Message-ID: <007e01c14051$3af2e4d0$3b2e713f@flak>
From: "Dean Willis" 
To: "Paul Kyzivat" ,
        "simple" 
References: <3BA63403.10C81113@cisco.com>
Subject: Re: Re: [Simple] Implicit MESSAGE sessions revisited]
Date: Tue, 18 Sep 2001 09:50:15 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_007B_01C14027.5137ACF0"
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
Content-Length: 12956
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_007B_01C14027.5137ACF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


One can manipulate the participants in a messaging relationship =
independently of INVITE/BYE semantics. One can also refer to a call from =
within a message, without the message being part of that call.

The ONLY justfication for INVITE/BYE bounding a MESSAGE sequence that =
I've recognized (or at least am willing to admit) to-date is path =
optimization with record-route/route.

--
Dean
  ----- Original Message -----=20
  From: Paul Kyzivat=20
  To: simple=20
  Sent: Monday, September 17, 2001 12:33 PM
  Subject: [Fwd: Re: [Simple] Implicit MESSAGE sessions revisited]


  Dean,=20
  So, you don't you don't see the advantage of using INVITE to set up an =
IM 'session' (indicating this in the SDP)? Why not? Without this, you =
lose the ability to:=20
  - associate the IM session with other related media sessions that =
should be used together;=20
  - transfer the IM session to another endpoint while retaining its =
identity as a session;=20
  - transfer a grouping of media sessions as a unit if IM is involved.=20

  I agree that the ability to do this is independent of how the session =
content is transported. It is certainly *possible* to introduce a =
session via SDP, but have that session multiplexed on a common transport =
by the application level. I believe there are a number of problems with =
that, but it is certainly an appropriate subject for discussion.=20

  But first it is important to agree that it must be possible to =
negotiate these sessions by the exchange of SDP. I know there are people =
other than myself who believe this is essential. I don't have a good =
sense of how many disagree. This is an essential point to resolve.=20

      Paul Kyzivat=20
      Cisco Systems=20

  Dean Willis wrote:=20
  >=20
  > No, we're clearly thinking something different here. I'm proposing =
providing=20
  > the concept of a "session" as a sequence of messages, with that =
sequence=20
  > association being indicated at the application rather than transport =
layer.=20
  >=20
  > For example, the message body itself might contain a session =
identifier and=20
  > a sequence number.=20
  >=20
  > This would allow the receiving client to render messages into =
appropriate=20
  > windows in an appropriate order, as appropriate to the =
implementation,=20
  > without the transport layer being aware of that behavior.=20
  >=20
  > --=20
  > Dean=20
  >=20
  > ----- Original Message -----=20
  > From: "Henning G. Schulzrinne" =20
  > To: "Dean Willis" =20
  > Cc: =20
  > Sent: Saturday, September 15, 2001 9:34 AM=20
  > Subject: Re: [Simple] Implicit MESSAGE sessions revisited=20
  >=20
  [snip]=20
  > > Just for clarification:=20
  > >=20
  > > Are you assuming that TCP (or, presumably, SCTP) is used? Are you=20
  > > assuming that the TCP connection is kept open implicitly?=20
  > >=20
  > > (To avoid artificial disagreement: I would agree that a regular =
SIP=20
  > > session over TCP would address most of the requirements, but just =
saying=20
  > > "paging" isn't quite enough.)=20
  [snip]=20
   =20

  -------- Original Message -------- Subject:  Re: [Simple] Implicit =
MESSAGE sessions revisited=20
        Date:  Mon, 17 Sep 2001 11:32:14 -0500=20
        From:  "Dean Willis" =20
        To:  "Mark Watson" ,"Patil Basavaraj =
\(NET/Dallas\)" ,"'ext Ben Campbell'" =
=20
        CC:  "simple" =20
        References:  =
=20


  Both, actually. I believe the issues are independent. --=20
  Dean =20

    ----- Original Message -----
    From: Mark Watson
    To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben =
Campbell'
    Cc: simple
    Sent: Monday, September 17, 2001 9:39 AM
    Subject: RE: [Simple] Implicit MESSAGE sessions revisited
     Dean,=20
    Do you mean that you don't see the advantage of using INVITE to set =
up an IM 'session' (indicating this in the SDP), or just that once such =
a session is set up, there is no need for the 'media' to use any =
different protocol than that used for 'paging' ?=20

    I think there are a lot of reasons why IM 'sessions' set up using =
INVITE just like any other SIP session, make sense. I don't care much =
yet what the transport protocol then is for the IMs in the session.=20

    Sorry if this is covering old ground.=20

    ...Mark


------=_NextPart_000_007B_01C14027.5137ACF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







 


One can manipulate the participants in =
a messaging=20
relationship independently of INVITE/BYE semantics. One can also refer =
to a call=20
from within a message, without the message being part of that =
call.


 


The ONLY justfication for INVITE/BYE =
bounding a=20
MESSAGE sequence that I've recognized (or at least am willing to admit) =
to-date=20
is path optimization with record-route/route.


 


--
Dean



  
----- Original Message ----- 

  From:=20
  Paul =
Kyzivat=20
  
  
To: simple 

  
Sent: Monday, September 17, =
2001 12:33=20
  PM

  
Subject: [Fwd: Re: [Simple] =
Implicit=20
  MESSAGE sessions revisited]

  

Dean,=20
  
So, you don't you don't see the advantage of using INVITE to set up =
an IM=20
  'session' (indicating this in the SDP)? Why not? Without this, you =
lose the=20
  ability to: 
- associate the IM session with other related media =
sessions=20
  that should be used together; 
- transfer the IM session to another =

  endpoint while retaining its identity as a session; 
- transfer a =
grouping=20
  of media sessions as a unit if IM is involved.=20
  
I agree that the ability to do this is independent of how the =
session=20
  content is transported. It is certainly *possible* to introduce a =
session via=20
  SDP, but have that session multiplexed on a common transport by the=20
  application level. I believe there are a number of problems with that, =
but it=20
  is certainly an appropriate subject for discussion.=20
  
But first it is important to agree that it must be possible to =
negotiate=20
  these sessions by the exchange of SDP. I know there are people other =
than=20
  myself who believe this is essential. I don't have a good sense of how =
many=20
  disagree. This is an essential point to resolve.=20
  
    Paul Kyzivat 
    Cisco =
Systems=20
  
Dean Willis wrote: 
> 
> No, we're clearly thinking =
something=20
  different here. I'm proposing providing 
> the concept of a =
"session" as=20
  a sequence of messages, with that sequence 
> association being=20
  indicated at the application rather than transport layer. 
> =

>=20
  For example, the message body itself might contain a session =
identifier and=20
  
> a sequence number. 
> 
> This would allow the =
receiving=20
  client to render messages into appropriate 
> windows in an =
appropriate=20
  order, as appropriate to the implementation, 
> without the =
transport=20
  layer being aware of that behavior. 
> 
> -- 
> Dean =

  
> 
> ----- Original Message ----- 
> From: "Henning =
G.=20
  Schulzrinne" <hgs@cs.columbia.edu> 
> To: "Dean Willis"=20
  <dean.willis@softarmor.com> 
> Cc:=20
  <simple@mailman.dynamicsoft.com> 
> Sent: Saturday, =
September 15,=20
  2001 9:34 AM 
> Subject: Re: [Simple] Implicit MESSAGE sessions=20
  revisited 
> 
[snip] 
> > Just for clarification: =

>=20
  > 
> > Are you assuming that TCP (or, presumably, SCTP) is =
used?=20
  Are you 
> > assuming that the TCP connection is kept open=20
  implicitly? 
> > 
> > (To avoid artificial =
disagreement: I=20
  would agree that a regular SIP 
> > session over TCP would =
address=20
  most of the requirements, but just saying 
> > "paging" isn't =
quite=20
  enough.) 
[snip] 
 =20
  
-------- Original Message --------=20
  
      =


    
    

      Subject: 
      Re: [Simple] Implicit MESSAGE sessions revisited

    

      Date: 
      Mon, 17 Sep 2001 11:32:14 -0500

    

      From: 
      "Dean Willis" <dean.willis@softarmor.com>

    

      To: 
      "Mark Watson" <mwatson@nortelnetworks.com>,"Patil =
Basavaraj=20
        \(NET/Dallas\)" <Basavaraj.Patil@nokia.com>,"'ext Ben =
Campbell'"=20
        <bcampbell@dynamicsoft.com>

    

      CC: 
      "simple" <simple@mailman.dynamicsoft.com>

    

      References: <A3C2399B2FACD411A54200508BE39C7402E845A1@zwcwd00r.europe.nortel.c=
om>

  

  
  Both, actually. I believe the =
issues are=20
  independent. -- 
Dean =20
  

    
----- Original Message -----

    From:=20
    Mark Watson
    
To: 'Dean Willis' ; Patil Basavaraj =
(NET/Dallas) ;=20
    'ext Ben =
Campbell'

    
Cc: simple

    
Sent: Monday, September 17, =
2001 9:39=20
    AM

    
Subject: RE: [Simple] =
Implicit MESSAGE=20
    sessions revisited
 Dean,=20
    
Do you mean that you don't see the advantage of =
using=20
    INVITE to set up an IM 'session' (indicating this in the SDP), or =
just that=20
    once such a session is set up, there is no need for the 'media' to =
use any=20
    different protocol than that used for 'paging' ?=20
    
I think there are a lot of reasons why IM =
'sessions' set up=20
    using INVITE just like any other SIP session, make sense. I don't =
care much=20
    yet what the transport protocol then is for the IMs in the =
session.=20
    
Sorry if this is covering old ground.=20
    
...Mark


------=_NextPart_000_007B_01C14027.5137ACF0--


From pkyzivat@cisco.com  Tue Sep 18 11:21:11 2001
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 LAA06347
	for ; Tue, 18 Sep 2001 11:21:10 -0400 (EDT)
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 f8IFKUv06697
	for ; Tue, 18 Sep 2001 11:20:30 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAA75579 (AUTH pkyzivat);
	Tue, 18 Sep 2001 11:22:07 -0400 (EDT)
Message-ID: <3BA7661A.F82C9F90@cisco.com>
Date: Tue, 18 Sep 2001 11:19:54 -0400
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: simple 
Subject: [Fwd: Re: Re: [Simple] Implicit MESSAGE sessions revisited]]
Content-Type: multipart/alternative;
 boundary="------------FB52066EC32FCCD8D72633BF"
Content-Length: 15678
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: 

--------------FB52066EC32FCCD8D72633BF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dean,

Can you please elaborate? (Your brief assertion isn't very convincing.)
 > One can manipulate the participants in a messaging relationship
independently of INVITE/BYE semantics.

Sure you can. But you need to use media specific means to do so. If
multiple media are being used together, then you need to manipulate them
separately, and using different techniques. If the point is to transfer
a multimedia call, then that is a very unfriendly way to do it.

> One can also refer to a call from within a message, without the
message being part of that call.

How? Unless you propose to stardardize a way, it becomes impossible to
have common tools understand the association between the two.

I get the impression that you really believe that IM is so different
that there is no reason to imagine it being used in conjunction with
other media. If so, then there is also no reason for SIMPLE - you might
as well go with BEEP.

    Paul

-------- Original Message --------
   Subject: Re: Re: [Simple] Implicit MESSAGE sessions revisited]
      Date: Tue, 18 Sep 2001 09:50:15 -0500
      From: "Dean Willis" 
        To: "Paul Kyzivat" ,"simple"
            
References: <3BA63403.10C81113@cisco.com>

  One can manipulate the participants in a messaging relationship
independently of INVITE/BYE semantics. One can also refer to a call from
within a message, without the message being part of that call. The ONLY
justfication for INVITE/BYE bounding a MESSAGE sequence that I've
recognized (or at least am willing to admit) to-date is path
optimization with record-route/route. --
Dean

     ----- Original Message -----
     From: Paul Kyzivat
     To: simple
     Sent: Monday, September 17, 2001 12:33 PM
     Subject: [Fwd: Re: [Simple] Implicit MESSAGE sessions
     revisited]
      Dean,

     So, you don't you don't see the advantage of using INVITE to
     set up an IM 'session' (indicating this in the SDP)? Why not?
     Without this, you lose the ability to:
     - associate the IM session with other related media sessions
     that should be used together;
     - transfer the IM session to another endpoint while retaining
     its identity as a session;
     - transfer a grouping of media sessions as a unit if IM is
     involved.

     I agree that the ability to do this is independent of how the
     session content is transported. It is certainly *possible* to
     introduce a session via SDP, but have that session multiplexed
     on a common transport by the application level. I believe
     there are a number of problems with that, but it is certainly
     an appropriate subject for discussion.

     But first it is important to agree that it must be possible to
     negotiate these sessions by the exchange of SDP. I know there
     are people other than myself who believe this is essential. I
     don't have a good sense of how many disagree. This is an
     essential point to resolve.

         Paul Kyzivat
         Cisco Systems

     Dean Willis wrote:
     >
     > No, we're clearly thinking something different here. I'm
     proposing providing
     > the concept of a "session" as a sequence of messages, with
     that sequence
     > association being indicated at the application rather than
     transport layer.
     >
     > For example, the message body itself might contain a session
     identifier and
     > a sequence number.
     >
     > This would allow the receiving client to render messages
     into appropriate
     > windows in an appropriate order, as appropriate to the
     implementation,
     > without the transport layer being aware of that behavior.
     >
     > --
     > Dean
     >
     > ----- Original Message -----
     > From: "Henning G. Schulzrinne" 
     > To: "Dean Willis" 
     > Cc: 
     > Sent: Saturday, September 15, 2001 9:34 AM
     > Subject: Re: [Simple] Implicit MESSAGE sessions revisited
     >
     [snip]
     > > Just for clarification:
     > >
     > > Are you assuming that TCP (or, presumably, SCTP) is used?
     Are you
     > > assuming that the TCP connection is kept open implicitly?
     > >
     > > (To avoid artificial disagreement: I would agree that a
     regular SIP
     > > session over TCP would address most of the requirements,
     but just saying
     > > "paging" isn't quite enough.)
     [snip]


     -------- Original Message --------

        Subject: Re: [Simple] Implicit MESSAGE sessions revisited
           Date: Mon, 17 Sep 2001 11:32:14 -0500
           From: "Dean Willis" 
             To: "Mark Watson" ,"Patil Basavaraj
                 \(NET/Dallas\)" ,"'ext Ben Campbell'"
                 
             CC: "simple" 
     References: 

     Both, actually. I believe the issues are independent. --
     Dean

          ----- Original Message -----
          From: Mark Watson
          To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ;
          'ext Ben Campbell'
          Cc: simple
          Sent: Monday, September 17, 2001 9:39 AM
          Subject: RE: [Simple] Implicit MESSAGE sessions
          revisited
           Dean,

          Do you mean that you don't see the advantage of
          using INVITE to set up an IM 'session' (indicating
          this in the SDP), or just that once such a session
          is set up, there is no need for the 'media' to use
          any different protocol than that used for 'paging' ?

          I think there are a lot of reasons why IM 'sessions'
          set up using INVITE just like any other SIP session,
          make sense. I don't care much yet what the transport
          protocol then is for the IMs in the session.

          Sorry if this is covering old ground.

          ...Mark

--------------FB52066EC32FCCD8D72633BF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




Dean,

Can you please elaborate?
(Your brief assertion isn't very convincing.)

 > One can manipulate the participants
in a messaging relationship independently of INVITE/BYE semantics.

Sure you can. But you need to use media
specific means to do so. If multiple media are being used together, then
you need to manipulate them separately, and using different techniques.
If the point is to transfer a multimedia call, then that is a very unfriendly
way to do it.

> One can also refer to a call from
within a message, without the message being part of that call.

How? Unless you propose to stardardize
a way, it becomes impossible to have common tools understand the association
between the two.

I get the impression that you really
believe that IM is so different that there is no reason to imagine it being
used in conjunction with other media. If so, then there is also no reason
for SIMPLE - you might as well go with BEEP.

    Paul


-------- Original Message --------




Subject: 

Re: Re: [Simple] Implicit MESSAGE sessions revisited]





Date: 

Tue, 18 Sep 2001 09:50:15 -0500





From: 

"Dean Willis" <dean.willis@softarmor.com>





To: 

"Paul Kyzivat" <pkyzivat@cisco.com>,"simple" <simple@mailman.dynamicsoft.com>





References: 

<3BA63403.10C81113@cisco.com>






  One can manipulate the
participants in a messaging relationship independently of INVITE/BYE semantics.
One can also refer to a call from within a message, without the message
being part of that call. The
ONLY justfication for INVITE/BYE bounding a MESSAGE sequence that I've
recognized (or at least am willing to admit) to-date is path optimization
with record-route/route. --

Dean



----- Original Message -----





To: simple



Sent: Monday, September 17, 2001 12:33
PM



Subject: [Fwd: Re: [Simple] Implicit
MESSAGE sessions revisited]

 Dean,

So, you don't you don't see the advantage of using INVITE to set up
an IM 'session' (indicating this in the SDP)? Why not? Without this, you
lose the ability to:

- associate the IM session with other related media sessions that should
be used together;

- transfer the IM session to another endpoint while retaining its identity
as a session;

- transfer a grouping of media sessions as a unit if IM is involved.

I agree that the ability to do this is independent of how the session
content is transported. It is certainly *possible* to introduce a session
via SDP, but have that session multiplexed on a common transport by the
application level. I believe there are a number of problems with that,
but it is certainly an appropriate subject for discussion.

But first it is important to agree that it must be possible to negotiate
these sessions by the exchange of SDP. I know there are people other than
myself who believe this is essential. I don't have a good sense of how
many disagree. This is an essential point to resolve.

    Paul Kyzivat

    Cisco Systems

Dean Willis wrote:

>

> No, we're clearly thinking something different here. I'm proposing
providing

> the concept of a "session" as a sequence of messages, with that sequence

> association being indicated at the application rather than transport
layer.

>

> For example, the message body itself might contain a session identifier
and

> a sequence number.

>

> This would allow the receiving client to render messages into appropriate

> windows in an appropriate order, as appropriate to the implementation,

> without the transport layer being aware of that behavior.

>

> --

> Dean

>

> ----- Original Message -----

> From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>

> To: "Dean Willis" <dean.willis@softarmor.com>

> Cc: <simple@mailman.dynamicsoft.com>

> Sent: Saturday, September 15, 2001 9:34 AM

> Subject: Re: [Simple] Implicit MESSAGE sessions revisited

>

[snip]

> > Just for clarification:

> >

> > Are you assuming that TCP (or, presumably, SCTP) is used? Are you

> > assuming that the TCP connection is kept open implicitly?

> >

> > (To avoid artificial disagreement: I would agree that a regular
SIP

> > session over TCP would address most of the requirements, but just
saying

> > "paging" isn't quite enough.)

[snip]

 

-------- Original Message --------







Subject: 

Re: [Simple] Implicit MESSAGE sessions revisited





Date: 

Mon, 17 Sep 2001 11:32:14 -0500





From: 

"Dean Willis" <dean.willis@softarmor.com>





To: 

"Mark Watson" <mwatson@nortelnetworks.com>,"Patil Basavaraj \(NET/Dallas\)"
<Basavaraj.Patil@nokia.com>,"'ext Ben Campbell'" <bcampbell@dynamicsoft.com>





CC: 

"simple" <simple@mailman.dynamicsoft.com>





References: 

<A3C2399B2FACD411A54200508BE39C7402E845A1@zwcwd00r.europe.nortel.com>







Both, actually. I believe
the issues are independent. --

Dean



----- Original Message -----







Cc: simple



Sent: Monday, September 17, 2001 9:39
AM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

 Dean,

Do you mean that you don't see the advantage of using
INVITE to set up an IM 'session' (indicating this in the SDP), or just
that once such a session is set up, there is no need for the 'media' to
use any different protocol than that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set
up using INVITE just like any other SIP session, make sense. I don't care
much yet what the transport protocol then is for the IMs in the session.

Sorry if this is covering old ground.

...Mark







--------------FB52066EC32FCCD8D72633BF--


From pkyzivat@cisco.com  Tue Sep 18 11:34:14 2001
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 LAA06434
	for ; Tue, 18 Sep 2001 11:34:14 -0400 (EDT)
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 f8IFXbv07506
	for ; Tue, 18 Sep 2001 11:33:37 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAA75693 (AUTH pkyzivat);
	Tue, 18 Sep 2001 11:35:12 -0400 (EDT)
Message-ID: <3BA7692B.DAA8DE75@cisco.com>
Date: Tue, 18 Sep 2001 11:32:59 -0400
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: simple 
Subject: [Fwd: Re: [Simple] Implicit MESSAGE sessions revisited]
Content-Type: multipart/alternative;
 boundary="------------7252057415F6637287B0A17A"
Content-Length: 21506
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: 

--------------7252057415F6637287B0A17A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> I disagree with requirement #2 -- SIP messages are inherently NOT
media.
> They are, in effect "user to user signaling".

I presume you mean "SIP MESSAGEs" rather than "SIP messages"???
That is an  argument for why MESSAGE shouldn't have been added to SIP,
or an argument for why MESSAGE shouldn't be used for session-oriented
IM. But it isn't a very strong argument against having a
session-oriented IM that is negotiated with INVITE and SDP.

If I call you on the phone and talk, we are exchanging media, but if I
happen to be deaf and want to use text to do the same thing it is
signalling rather than media???

I can accept that a paging message, where very likely there will be no
associated reply, might not be media. But when it is intended as an
interactive conversation then I believe it is appropriately considered
media.

    Paul

-------- Original Message --------
   Subject: Re: [Simple] Implicit MESSAGE sessions revisited
      Date: Tue, 18 Sep 2001 09:46:11 -0500
      From: "Dean Willis" 
        To: "simple" 
References: 

 I agree with #1,sortof. The best (only?) justfication for
INVITE-bounded message sessions is the use of Record-Route to allow
proxies that don't need to be in the route to opt out. This allows the
SIP-network to be "self optimizing" for message routing. However, such
SIP paths may be necessarily NOT end-to-end. For example, putting a SIP
UA behind a firewall proxy will require that messages transit the
firewall proxy. This is easily accomplished with record-route. Remember,
all the "signaling privacy" requirements like  calling-party-ID and
address-hiding apply to SIP messages. We already have mechanisms to meet
those requirements for SIP traffic -- reusing them for messages is
obviously functional. I disagree with requirement #2 -- SIP messages are
inherently NOT media. They are, in effect "user to user signaling". This
is consistent with my earlier position on the use of phone input (DTMF)
as "user to system signaling", not media. --
Dean

     ----- Original Message -----
     From: Mark Watson
     To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben
     Campbell'
     Cc: simple
     Sent: Monday, September 17, 2001 12:02 PM
     Subject: RE: [Simple] Implicit MESSAGE sessions revisited
      Dean,I agree that they're independent. On the first one, I
     had thought that the idea of IM 'sessions' fulfilled two key
     requirements:1) I want to find my desired called party, and
     then exchange multiple messages with this personSome of these
     things which can happen (in the network/UEs) as a SIP message
     finds the desired end-user may take time/cost money/require
     user interaction, and I don't want to repeat them once I have
     found the person I want to chat to. Also, there is no
     guarantee that repeating the process at a later time will get
     me to the same end-user. So, I want to be able to do a
     'session setup' and then send messages directly to the person
     I've found.Of course, I could just treat the first message as
     an implicit session setup, but this seems to be out of
     fashion.2) I want IM to be just another media that I can
     negotiate, add & remove from a session etc.Again, I could do
     something clever with Call IDs to connect a MESSAGE message
     with a pre-existing session etc. etc., but why should I make
     an exception for this one kind of media. If I do that, then no
     capabilities that I have now or invent in the future which are
     supposed to be 'media type independent', will work for IM, and
     I will have to be hacking the IM system constantly to keep
     up.Did you disagree with these requirements, or just with the
     implementation ?Regards...Mark

          -----Original Message-----
          From: Dean Willis [mailto:dean.willis@softarmor.com]

          Sent: 17 September 2001 17:32
          To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj
          (NET/Dallas); 'ext Ben Campbell'
          Cc: simple
          Subject: Re: [Simple] Implicit MESSAGE sessions
          revisited

          Both, actually. I believe the issues are
          independent. --
          Dean

               ----- Original Message -----
               From: Mark Watson
               To: 'Dean Willis' ; Patil Basavaraj
               (NET/Dallas) ; 'ext Ben Campbell'
               Cc: simple
               Sent: Monday, September 17, 2001 9:39 AM
               Subject: RE: [Simple] Implicit MESSAGE
               sessions revisited
                Dean,

               Do you mean that you don't see the
               advantage of using INVITE to set up an IM
               'session' (indicating this in the SDP), or
               just that once such a session is set up,
               there is no need for the 'media' to use
               any different protocol than that used for
               'paging' ?

               I think there are a lot of reasons why IM
               'sessions' set up using INVITE just like
               any other SIP session, make sense. I don't
               care much yet what the transport protocol
               then is for the IMs in the session.

               Sorry if this is covering old ground.

               ...Mark



               > -----Original Message-----
               > From: Dean Willis
               [mailto:dean.willis@softarmor.com]
               > Sent: 15 September 2001 05:31
               > To: Patil Basavaraj (NET/Dallas); 'ext
               Ben Campbell'
               > Cc: simple
               > Subject: Re: [Simple] Implicit MESSAGE
               sessions revisited
               >
               >
               >
               > Just as MESSAGE for sessions has all the
               wasted overhead of
               > headers and
               > routing mechanisms designed to find
               users and traverse
               > firewalls (assuming
               > you think this is a waste), so does
               BEEP.
               >
               > I personally have yet to see the need
               for message sessions as
               > a specialized
               > transport.
               >
               > I think "pager" messages carrying a
               session-ID and sequence number can
               > provide the same user experience.
               >
               > --
               > dean
               >
               >
               > ----- Original Message -----
               > From: "Patil Basavaraj (NET/Dallas)"
               
               > To: "'ext Ben Campbell'"
               
               > Cc: 
               > Sent: Friday, September 14, 2001 1:07 PM

               > Subject: RE: [Simple] Implicit MESSAGE
               sessions revisited
               >
               >
               > >
               > > One of the protocols that has been
               suggested for use instead of
               > > MESSAGE is BEEP. Are there any serious
               concerns *at this time*
               > > why BEEP would not be good eniugh for
               IM Sessions?
               > >
               > > -Basavaraj
               > >
               > >
               > >
               _______________________________________________

               > > 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

               >

--------------7252057415F6637287B0A17A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




> I disagree with requirement #2 -- SIP
messages are inherently NOT media.

> They are, in effect "user to user
signaling".

I presume you mean "SIP MESSAGEs" rather
than "SIP messages"???

That is an  argument for why
MESSAGE shouldn't have been added to SIP, or an argument for why MESSAGE
shouldn't be used for session-oriented IM. But it isn't a very strong argument
against having a session-oriented IM that is negotiated with INVITE and
SDP.

If I call you on the phone and talk,
we are exchanging media, but if I happen to be deaf and want to use text
to do the same thing it is signalling rather than media???

I can accept that a paging message,
where very likely there will be no associated reply, might not be media.
But when it is intended as an interactive conversation then I believe it
is appropriately considered media.

    Paul

-------- Original Message --------




Subject: 

Re: [Simple] Implicit MESSAGE sessions revisited





Date: 

Tue, 18 Sep 2001 09:46:11 -0500





From: 

"Dean Willis" <dean.willis@softarmor.com>





To: 

"simple" <simple@mailman.dynamicsoft.com>





References: 

<A3C2399B2FACD411A54200508BE39C7402E845AB@zwcwd00r.europe.nortel.com>







 I agree with
#1,sortof. The best (only?) justfication for INVITE-bounded message sessions
is the use of Record-Route to allow proxies that don't need to be in the
route to opt out. This allows the SIP-network to be "self optimizing" for
message routing. However, such SIP paths may be necessarily NOT end-to-end.
For example, putting a SIP UA behind a firewall proxy will require that
messages transit the firewall proxy. This is easily accomplished with record-route.
Remember, all the "signaling privacy" requirements like  calling-party-ID
and address-hiding apply to SIP messages. We already have mechanisms to
meet those requirements for SIP traffic -- reusing them for messages is
obviously functional. I
disagree with requirement #2 -- SIP messages are inherently NOT media.
They are, in effect "user to user signaling". This is consistent with my
earlier position on the use of phone input (DTMF) as "user to system signaling",
not media. --

Dean



----- Original Message -----







Cc: simple



Sent: Monday, September 17, 2001 12:02
PM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

 Dean,I
agree that they're independent. On the first one, I had thought that the
idea of IM 'sessions' fulfilled two key requirements:1)
I want to find my desired called party, and then exchange multiple messages
with this personSome
of these things which can happen (in the network/UEs) as a SIP message
finds the desired end-user may take time/cost money/require user interaction,
and I don't want to repeat them once I have found the person I want to
chat to. Also, there is no guarantee that repeating the process at a later
time will get me to the same end-user. So, I want to be able to do a 'session
setup' and then send messages directly to the person I've found.Of
course, I could just treat the first message as an implicit session setup,
but this seems to be out of fashion.2)
I want IM to be just another media that I can negotiate, add & remove
from a session etc.Again,
I could do something clever with Call IDs to connect a MESSAGE message
with a pre-existing session etc. etc., but why should I make an exception
for this one kind of media. If I do that, then no capabilities that I have
now or invent in the future which are supposed to be 'media type independent',
will work for IM, and I will have to be hacking the IM system constantly
to keep up.Did
you disagree with these requirements, or just with the implementation ?Regards...Mark



-----Original
Message-----

From: Dean Willis [mailto:dean.willis@softarmor.com]

Sent: 17 September 2001 17:32

To: Watson, Mark [MAIFP:EP11:EXCH];
Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'

Cc: simple

Subject: Re: [Simple] Implicit
MESSAGE sessions revisited

 

Both, actually. I believe the issues are
independent. --

Dean 



----- Original Message -----







Cc: simple



Sent: Monday, September 17, 2001 9:39
AM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

 Dean,

Do you mean that you don't see the advantage of using
INVITE to set up an IM 'session' (indicating this in the SDP), or just
that once such a session is set up, there is no need for the 'media' to
use any different protocol than that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set
up using INVITE just like any other SIP session, make sense. I don't care
much yet what the transport protocol then is for the IMs in the session.

Sorry if this is covering old ground.

...Mark

 

 

> -----Original Message-----

> From: Dean Willis [mailto:dean.willis@softarmor.com]

> Sent: 15 September 2001 05:31

> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'

> Cc: simple

> Subject: Re: [Simple] Implicit MESSAGE sessions revisited

>

>

>

> Just as MESSAGE for sessions has all the wasted overhead
of

> headers and

> routing mechanisms designed to find users and traverse

> firewalls (assuming

> you think this is a waste), so does BEEP.

>

> I personally have yet to see the need for message sessions
as

> a specialized

> transport.

>

> I think "pager" messages carrying a session-ID and
sequence number can

> provide the same user experience.

>

> --

> dean

>

>

> ----- Original Message -----

> From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>

> To: "'ext Ben Campbell'" <bcampbell@dynamicsoft.com>

> Cc: <simple@mailman.dynamicsoft.com>

> Sent: Friday, September 14, 2001 1:07 PM

> Subject: RE: [Simple] Implicit MESSAGE sessions revisited

>

>

> >

> > One of the protocols that has been suggested for
use instead of

> > MESSAGE is BEEP. Are there any serious concerns *at
this time*

> > why BEEP would not be good eniugh for IM Sessions?

> >

> > -Basavaraj

> >

> >

> > _______________________________________________

> > 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

>









--------------7252057415F6637287B0A17A--


From sean.olson@ericsson.com  Tue Sep 18 12:06:54 2001
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 MAA06606
	for ; Tue, 18 Sep 2001 12:06:53 -0400 (EDT)
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 f8IG6m719232
	for ; Tue, 18 Sep 2001 11:06:48 -0500 (CDT)
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 f8IG6mH04708
	for ; Tue, 18 Sep 2001 11:06:48 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Sep 18 11:06:37 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Sep 2001 11:06:36 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Jonathan Rosenberg'" ,
        "'Robert Brown'"
	 ,
        Avshalom Houri , simple@mailman.dynamicsoft.com
Cc: "Adam Roach (E-mail)" 
Subject: RE: [Simple] Partial Notifies?
Date: Tue, 18 Sep 2001 11:06:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1405B.E49ED2A0"
Content-Length: 10425
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: 

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_01C1405B.E49ED2A0
Content-Type: text/plain;
	charset="iso-8859-1"


>I believe the requirements for the partial notifications are 
>the following:
>
>1. the subscribe request have a way for the subscriber to indicate what
>version they have, so that the notify only contain a delta 
>from that version
>(indeed, perhaps the notify isn't even sent if the version the 
>subscriber
>has is up to date)

It would also be nice to support packages that do not
keep multiple versions around on the server. The delta
would always be against the most recent version and
if you are out of sync you would retrieve the complete
state in a fetch first, then apply the latest delta.

>
>2. the notify have a way to indicate what version of the document the
>subscriber will have once the patch is applied
>
>3. the notify have a way to indicate what version the of the 
>document the
>subscriber has to apply the patch against (i.e, the old version)
>
>4. the "patch" be in a format that is independent of the format of the
>presence document.

Would a Content-Encoding or Content-Transfer-Encoding
be appropriate here? What is the goal of partial notifies?
Is it simply to reduce message size? If so, gzip or deflate
compression of the body may be sufficient. 
 
>Anders Kristensen had pointed out to me that webdav has looked 
>at a very
>similar problem, and that there are specs for deltas within 
>http. I haven't
>looked at those in detail, but they might provide a solution 
>for us that
>would allow us to reuse existing work elsewhere in IETF.

see 
http://search.ietf.org/internet-drafts/draft-ietf-deltav-versioning-18.txt

WebDAV deals with a more sophisticated concept of version
control that is appropriate for document or source code
control. For example, it allows forking and merging of
versions. Do we need this level of complexity for 
partial notifies? I think (hope) not.

One very interesting concept we can borrow from WebDAV
is the notion of versioning information embedded in a 
URL. This could obviously be included in the Request-URI
of a SUBSCRIBE to indicate the current version that the
client has. It could also be included in the Request-URI
of the NOTIFY.

>
>So, the quesitons to be discussed, in order, are:
>
>1. is there consensus that we should have a solution for 
>partial notifies in
>simple?

Yes, but ... I think it is also useful to allow
a client to use the current "every NOTIFY contains
complete state" model. What I would propose is a
".delta" sub-package that an event package could
support if a client wishes to receive partial notifies.
Doing a one-time fetch of the base package gives complete
state. From that point on, the client can SUBSCRIBE to the
.delta sub-package if it wishes to receive partial notifies.

This leaves the possibility for both modes of operation.

>
>2. is there consensus that this should be done in a general 
>fashion as part
>of the sip events specification?

Yes, but should it go into the base SUB/NOT draft or should
there be another draft describing versioning as an optional
extension to SUB/NOT? I would prefer to close the base SUB/NOT
draft as quickly as possible. Partial notifies may be a useful
extension, but they don't seem valuable enough to warrant 
slowing down the standardization of SUB/NOT (upon which a 
bunch of other work is dependent)

>3. how should it be done?

I'm assuming that version information will be opaque
strings/tokens.

A "Label:" header as proposed in the WebDAV work might
be useful for satisfying requirements 1 and 2 above.


>Comments?
>-Jonathan R.

Regards,
Sean Olson
Ericsson Inc.

------_=_NextPart_001_01C1405B.E49ED2A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Partial Notifies?






>I believe the requirements for the partial =
notifications are 

>the following:

>

>1. the subscribe request have a way for the =
subscriber to indicate what

>version they have, so that the notify only =
contain a delta 

>from that version

>(indeed, perhaps the notify isn't even sent if =
the version the 

>subscriber

>has is up to date)




It would also be nice to support packages that do =
not

keep multiple versions around on the server. The =
delta

would always be against the most recent version =
and

if you are out of sync you would retrieve the =
complete

state in a fetch first, then apply the latest =
delta.




>

>2. the notify have a way to indicate what =
version of the document the

>subscriber will have once the patch is =
applied

>

>3. the notify have a way to indicate what =
version the of the 

>document the

>subscriber has to apply the patch against (i.e, =
the old version)

>

>4. the "patch" be in a format that is =
independent of the format of the

>presence document.




Would a Content-Encoding or =
Content-Transfer-Encoding

be appropriate here? What is the goal of partial =
notifies?

Is it simply to reduce message size? If so, gzip or =
deflate

compression of the body may be sufficient. 

 

>Anders Kristensen had pointed out to me that =
webdav has looked 

>at a very

>similar problem, and that there are specs for =
deltas within 

>http. I haven't

>looked at those in detail, but they might =
provide a solution 

>for us that

>would allow us to reuse existing work elsewhere =
in IETF.




see 

http://search.ietf.org/internet-drafts/draft-ietf-delt=
av-versioning-18.txt




WebDAV deals with a more sophisticated concept of =
version

control that is appropriate for document or source =
code

control. For example, it allows forking and merging =
of

versions. Do we need this level of complexity for =


partial notifies? I think (hope) not.




One very interesting concept we can borrow from =
WebDAV

is the notion of versioning information embedded in =
a 

URL. This could obviously be included in the =
Request-URI

of a SUBSCRIBE to indicate the current version that =
the

client has. It could also be included in the =
Request-URI

of the NOTIFY.




>

>So, the quesitons to be discussed, in order, =
are:

>

>1. is there consensus that we should have a =
solution for 

>partial notifies in

>simple?




Yes, but ... I think it is also useful to =
allow

a client to use the current "every NOTIFY =
contains

complete state" model. What I would propose is =
a

".delta" sub-package that an event package =
could

support if a client wishes to receive partial =
notifies.

Doing a one-time fetch of the base package gives =
complete

state. From that point on, the client can SUBSCRIBE =
to the

.delta sub-package if it wishes to receive partial =
notifies.




This leaves the possibility for both modes of =
operation.




>

>2. is there consensus that this should be done =
in a general 

>fashion as part

>of the sip events specification?




Yes, but should it go into the base SUB/NOT draft or =
should

there be another draft describing versioning as an =
optional

extension to SUB/NOT? I would prefer to close the =
base SUB/NOT

draft as quickly as possible. Partial notifies may =
be a useful

extension, but they don't seem valuable enough to =
warrant 

slowing down the standardization of SUB/NOT (upon =
which a 

bunch of other work is dependent)




>3. how should it be done?




I'm assuming that version information will be =
opaque

strings/tokens.




A "Label:" header as proposed in the WebDAV =
work might

be useful for satisfying requirements 1 and 2 =
above.






>Comments?

>-Jonathan R.




Regards,

Sean Olson

Ericsson Inc.





------_=_NextPart_001_01C1405B.E49ED2A0--

From sean.olson@ericsson.com  Tue Sep 18 13:05:11 2001
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 NAA06825
	for ; Tue, 18 Sep 2001 13:05:11 -0400 (EDT)
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 f8IH55725930
	for ; Tue, 18 Sep 2001 12:05:05 -0500 (CDT)
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 f8IH55H00496
	for ; Tue, 18 Sep 2001 12:05:05 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Sep 18 12:04:54 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Sep 2001 12:04:54 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Jonathan Rosenberg'" ,
        "'Robert Brown'"
	 ,
        Avshalom Houri , simple@mailman.dynamicsoft.com
Cc: "Adam Roach (E-mail)" 
Subject: RE: [Simple] Partial Notifies?
Date: Tue, 18 Sep 2001 12:04:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14064.08F53740"
Content-Length: 3261
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: 

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_01C14064.08F53740
Content-Type: text/plain;
	charset="iso-8859-1"


>4. the "patch" be in a format that is independent of the format of the
>presence document. 
>
>Number 4 is important, I think, to avoid needing to specify updates and
>partial notifies within every event document format. We just 
>do it once, and
>then each event package doesn't need to ever worry about it again. 

There are a couple of obvious choices here:

1) Use a context or unified diff
   http://www.gnu.org/software/diffutils/diffutils.html

   This is appropriate for text (XML) but not binary
   payloads.

2) Use a binary diff format like gdiff
   http://www.w3.org/TR/NOTE-gdiff-19970825.html


In either case, for smaller payloads, the diff
format may actually be larger than the original
version. If message size is an issue, then we
should allow either format to be sent depending
on the size of the patch.

Sean Olson
Ericsson Inc.



------_=_NextPart_001_01C14064.08F53740
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Partial Notifies?






>4. the "patch" be in a format that is =
independent of the format of the

>presence document. 

>

>Number 4 is important, I think, to avoid needing =
to specify updates and

>partial notifies within every event document =
format. We just 

>do it once, and

>then each event package doesn't need to ever =
worry about it again. 




There are a couple of obvious choices here:




1) Use a context or unified diff

   http://www.gnu.org/software/diffutils/diffutils.html




   This is appropriate for text (XML) but =
not binary

   payloads.




2) Use a binary diff format like gdiff

   http://www.w3.org/TR/NOTE-gdiff-19970825.html






In either case, for smaller payloads, the diff

format may actually be larger than the =
original

version. If message size is an issue, then we

should allow either format to be sent =
depending

on the size of the patch.




Sean Olson

Ericsson Inc.







------_=_NextPart_001_01C14064.08F53740--

From mwatson@nortelnetworks.com  Tue Sep 18 13:59:53 2001
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07027
	for ; Tue, 18 Sep 2001 13:59:52 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f8IHxag07810
	for ; Tue, 18 Sep 2001 18:59:37 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Tue, 18 Sep 2001 18:59:11 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id ;
          Tue, 18 Sep 2001 18:59:09 +0100
Message-ID: 
From: "Mark Watson" 
To: "'Dean Willis'" ,
        simple 
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Tue, 18 Sep 2001 18:59:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1406B.9FE2BE00"
Content-Length: 23869
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: 

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_01C1406B.9FE2BE00
Content-Type: text/plain;
	charset="iso-8859-1"

(1), it's not just a question of optimising the message routing, it's also
that in routing the initial INVITE I may use up certain resources or require
user intervention, and I don't want to repeat all that for every message in
the 'chat session'.

For example, Ann has all incoming sessions presented to their SIP client but
can hit a key to forward them to her assistant Bob. If it's an IM chat
session, and Bob gets into a long conversation, Ann does not want to see
every message, and have to hit a key to forward it.
 
Anns client could forward 'subsequent' messages automatically, but then
Ann's client is implicitly taking on a notion of a 'session' and we are into
the implicit session setup debate again - how does it detect when this
session has ended and a new one started ? What happens if Ann turns her
client off before Bob has finished chatting ? Ann could instruct her proxy
to forwared SIP requests to Bob, but perhaps she doesn't want to. Perhaps
she wants new calls to go to her mobile, but the rest of Bob's chat session
to continue unaffected.
 
So it's not just a message routing optimisation, there are other resources
being optimised too (Ann's time).
 
(2) SIP messages are not media, sure, but Instant Messages are. Instant
Messages are not 'user to user signalling' either, because they are not
signalling - they are a communication between the human end-users, not
between the equipment facilitating that communication (which is how I would
characterise 'signalling' here). So perhaps SIP messages should not be used
to carry Instant Messages - but this is a different point entirely.
 
...Mark
 
 

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 18 September 2001 15:46
To: simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited


 
I agree with #1,sortof. The best (only?) justfication for INVITE-bounded
message sessions is the use of Record-Route to allow proxies that don't need
to be in the route to opt out. This allows the SIP-network to be "self
optimizing" for message routing. However, such SIP paths may be necessarily
NOT end-to-end. For example, putting a SIP UA behind a firewall proxy will
require that messages transit the firewall proxy. This is easily
accomplished with record-route. Remember, all the "signaling privacy"
requirements like  calling-party-ID and address-hiding apply to SIP
messages. We already have mechanisms to meet those requirements for SIP
traffic -- reusing them for messages is obviously functional.
 
I disagree with requirement #2 -- SIP messages are inherently NOT media.
They are, in effect "user to user signaling". This is consistent with my
earlier position on the use of phone input (DTMF) as "user to system
signaling", not media.
 
--
Dean

----- Original Message ----- 
From: Mark Watson   
To: 'Dean Willis'   ; Patil Basavaraj
(NET/Dallas)   ; 'ext
 Ben Campbell' 
Cc: simple   
Sent: Monday, September 17, 2001 12:02 PM
Subject: RE: [Simple] Implicit MESSAGE sessions revisited

Dean,
 
I agree that they're independent. On the first one, I had thought that the
idea of IM 'sessions' fulfilled two key requirements:
 
1) I want to find my desired called party, and then exchange multiple
messages with this person
 
Some of these things which can happen (in the network/UEs) as a SIP message
finds the desired end-user may take time/cost money/require user
interaction, and I don't want to repeat them once I have found the person I
want to chat to. Also, there is no guarantee that repeating the process at a
later time will get me to the same end-user. So, I want to be able to do a
'session setup' and then send messages directly to the person I've found.
 
Of course, I could just treat the first message as an implicit session
setup, but this seems to be out of fashion.
 
2) I want IM to be just another media that I can negotiate, add & remove
from a session etc.
 
Again, I could do something clever with Call IDs to connect a MESSAGE
message with a pre-existing session etc. etc., but why should I make an
exception for this one kind of media. If I do that, then no capabilities
that I have now or invent in the future which are supposed to be 'media type
independent', will work for IM, and I will have to be hacking the IM system
constantly to keep up.
 
Did you disagree with these requirements, or just with the implementation ?
 
Regards...Mark

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 17 September 2001 17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); 'ext Ben
Campbell'
Cc: simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited


Both, actually. I believe the issues are independent.
 
--
Dean
 

----- Original Message ----- 
From: Mark Watson   
To: 'Dean Willis'   ; Patil Basavaraj
(NET/Dallas)   ; 'ext Ben Campbell'
  
Cc: simple   
Sent: Monday, September 17, 2001 9:39 AM
Subject: RE: [Simple] Implicit MESSAGE sessions revisited


Dean, 

Do you mean that you don't see the advantage of using INVITE to set up an IM
'session' (indicating this in the SDP), or just that once such a session is
set up, there is no need for the 'media' to use any different protocol than
that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set up using INVITE
just like any other SIP session, make sense. I don't care much yet what the
transport protocol then is for the IMs in the session.

Sorry if this is covering old ground. 

...Mark 




> -----Original Message----- 
> From: Dean Willis [ mailto:dean.willis@softarmor.com
 ] 
> Sent: 15 September 2001 05:31 
> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell' 
> Cc: simple 
> Subject: Re: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> 
> Just as MESSAGE for sessions has all the wasted overhead of 
> headers and 
> routing mechanisms designed to find users and traverse 
> firewalls (assuming 
> you think this is a waste), so does BEEP. 
> 
> I personally have yet to see the need for message sessions as 
> a specialized 
> transport. 
> 
> I think "pager" messages carrying a session-ID and sequence number can 
> provide the same user experience. 
> 
> -- 
> dean 
> 
> 
> ----- Original Message ----- 
> From: "Patil Basavaraj (NET/Dallas)"  
> To: "'ext Ben Campbell'"  
> Cc:  
> Sent: Friday, September 14, 2001 1:07 PM 
> Subject: RE: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> > 
> > One of the protocols that has been suggested for use instead of 
> > MESSAGE is BEEP. Are there any serious concerns *at this time* 
> > why BEEP would not be good eniugh for IM Sessions? 
> > 
> > -Basavaraj 
> > 
> > 
> > _______________________________________________ 
> > 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_01C1406B.9FE2BE00
Content-Type: text/html;
	charset="iso-8859-1"




RE: [Simple] Implicit MESSAGE sessions revisited






(1), 
it's not just a question of optimising the message routing, it's also that in 
routing the initial INVITE I may use up certain resources or require user 
intervention, and I don't want to repeat all that for every message in the 'chat 
session'.



For example, Ann has all incoming sessions 
presented to their SIP client but can hit a key to forward them to her assistant 
Bob. If it's an IM chat session, and Bob gets into a long conversation, Ann does 
not want to see every message, and have to hit a key to forward 
it.


 


Anns 
client could forward 'subsequent' messages automatically, but then Ann's client 
is implicitly taking on a notion of a 'session' and we are into the implicit 
session setup debate again - how does it detect when this session has ended and 
a new one started ? What happens if Ann turns her client off before Bob has 
finished chatting ? Ann could instruct her proxy to forwared SIP requests to 
Bob, but perhaps she doesn't want to. Perhaps she wants new calls to go to her 
mobile, but the rest of Bob's chat session to continue 
unaffected.


 


So 
it's not just a message routing optimisation, there are other resources being 
optimised too (Ann's time).


 


(2) 
SIP messages are not media, sure, but Instant Messages are. Instant Messages are 
not 'user to user signalling' either, because they are not signalling - they are 
a communication between the human end-users, not between the equipment 
facilitating that communication (which is how I would characterise 'signalling' 
here). So perhaps SIP messages should not be used to carry Instant Messages - 
but this is a different point entirely.


 


...Mark


 


 



  
-----Original Message-----
From: Dean Willis 
  [mailto:dean.willis@softarmor.com]
Sent: 18 September 2001 
  15:46
To: simple
Subject: Re: [Simple] Implicit MESSAGE 
  sessions revisited


  
 

  
I agree with #1,sortof. The best (only?) 
  justfication for INVITE-bounded message sessions is the use of Record-Route to 
  allow proxies that don't need to be in the route to opt out. This allows the 
  SIP-network to be "self optimizing" for message routing. However, such SIP 
  paths may be necessarily NOT end-to-end. For example, putting a SIP UA behind 
  a firewall proxy will require that messages transit the firewall proxy. This 
  is easily accomplished with record-route. Remember, all the "signaling 
  privacy" requirements like  calling-party-ID and address-hiding apply to 
  SIP messages. We already have mechanisms to meet those requirements for SIP 
  traffic -- reusing them for messages is obviously functional.

  
 

  
I disagree with requirement #2 -- SIP messages 
  are inherently NOT media. They are, in effect "user to user signaling". This 
  is consistent with my earlier position on the use of phone input (DTMF) as 
  "user to system signaling", not media.

  
 

  
--
Dean

  

    
----- Original Message ----- 

    
    
    
Cc: simple 

    
Sent: Monday, September 17, 2001 12:02 
    PM

    
Subject: RE: [Simple] Implicit MESSAGE 
    sessions revisited

    


    
Dean,

    
 

    
I agree that they're independent. On the first one, 
    I had thought that the idea of IM 'sessions' fulfilled two key 
    requirements:

    
 

    
1) I want to find my desired called party, and then 
    exchange multiple messages with this person

    
 

    
Some of these things which can happen (in the 
    network/UEs) as a SIP message finds the desired end-user may take time/cost 
    money/require user interaction, and I don't want to repeat them once I have 
    found the person I want to chat to. Also, there is no guarantee that 
    repeating the process at a later time will get me to the same end-user. So, 
    I want to be able to do a 'session setup' and then send messages directly to 
    the person I've found.

    
 

    
Of course, I could just treat the first message as 
    an implicit session setup, but this seems to be out of 
    fashion.

    
 

    
2) I want IM to be just another media that I can 
    negotiate, add & remove from a session etc.

    
 

    
Again, I could do something clever with Call IDs to 
    connect a MESSAGE message with a pre-existing session etc. etc., but why 
    should I make an exception for this one kind of media. If I do that, then no 
    capabilities that I have now or invent in the future which are supposed to 
    be 'media type independent', will work for IM, and I will have to be hacking 
    the IM system constantly to keep up.

    
 

    
Did you disagree with these requirements, or just 
    with the implementation ?

    
 

    
Regards...Mark

    

      
-----Original Message-----
From: Dean Willis 
      [mailto:dean.willis@softarmor.com]
Sent: 17 September 2001 
      17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj 
      (NET/Dallas); 'ext Ben Campbell'
Cc: simple
Subject: 
      Re: [Simple] Implicit MESSAGE sessions revisited


      
Both, actually. I believe the issues are 
      independent.

      
 

      
--
Dean

      
 

      

        
----- Original Message ----- 

        
        
        
Cc: simple 

        
Sent: Monday, September 17, 2001 
        9:39 AM

        
Subject: RE: [Simple] Implicit 
        MESSAGE sessions revisited

        


        
Dean, 

        
Do you mean that you don't see the advantage of using 
        INVITE to set up an IM 'session' (indicating this in the SDP), or just 
        that once such a session is set up, there is no need for the 'media' to 
        use any different protocol than that used for 'paging' ?

        
I think there are a lot of reasons why IM 'sessions' set 
        up using INVITE just like any other SIP session, make sense. I don't 
        care much yet what the transport protocol then is for the IMs in the 
        session.

        
Sorry if this is covering old ground. 

        
...Mark 




        
> -----Original Message----- 
> From: Dean Willis [mailto:dean.willis@softarmor.com] 
        
> Sent: 15 September 2001 05:31 
> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell' 
        
> Cc: simple 
> Subject: 
        Re: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> 
        
> Just as MESSAGE for sessions has all the 
        wasted overhead of 
> headers and 
        
> routing mechanisms designed to find users and 
        traverse 
> firewalls (assuming 
        
> you think this is a waste), so does BEEP. 
        
> 
> I personally have yet 
        to see the need for message sessions as 
> a 
        specialized 
> transport. 
> 
> I think "pager" messages 
        carrying a session-ID and sequence number can 
> provide the same user experience. 
> 
> -- 
> 
        dean 
> 
> 
        
> ----- Original Message ----- 
        
> From: "Patil Basavaraj (NET/Dallas)" 
        <Basavaraj.Patil@nokia.com> 
> To: "'ext 
        Ben Campbell'" <bcampbell@dynamicsoft.com> 
> Cc: <simple@mailman.dynamicsoft.com> 
> Sent: Friday, September 14, 2001 1:07 PM 
> Subject: RE: [Simple] Implicit MESSAGE sessions 
        revisited 
> 
> 
        
> > 
> > One 
        of the protocols that has been suggested for use instead of 
        
> > MESSAGE is BEEP. Are there any serious 
        concerns *at this time* 
> > why BEEP would 
        not be good eniugh for IM Sessions? 
> 
        > 
> > -Basavaraj 
> > 
> > 
> > _______________________________________________ 
        
> > 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_01C1406B.9FE2BE00--

From roberbr@microsoft.com  Tue Sep 18 21:25:47 2001
Received: from inet-imc-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08378
	for ; Tue, 18 Sep 2001 21:25:44 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 18 Sep 2001 18:25:37 -0700
Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Sep 2001 18:25:36 -0700
Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 18 Sep 2001 18:25:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Tue, 18 Sep 2001 18:25:22 -0700
Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320D35E@red-msg-05.redmond.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Implicit MESSAGE sessions revisited
Thread-Index: AcFAbnviNpiX7T49TrWPeejWARMPvwAO1XcA
From: "Robert Brown" 
To: "Mark Watson" ,
        "Dean Willis" ,
        "simple" 
X-OriginalArrivalTime: 19 Sep 2001 01:25:23.0602 (UTC) FILETIME=[F4561F20:01C140A9]
Content-Length: 34623
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: 

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C140A9.F3E6A8F6"

------_=_NextPart_001_01C140A9.F3E6A8F6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I'm not convinced that the "Ann" example is legitimate.  This just
sounds like a poor UI design.

=20

-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]=20
Sent: Tuesday, September 18, 2001 10:59 AM
To: 'Dean Willis'; simple
Subject: RE: [Simple] Implicit MESSAGE sessions revisited

=20

(1), it's not just a question of optimising the message routing, it's
also that in routing the initial INVITE I may use up certain resources
or require user intervention, and I don't want to repeat all that for
every message in the 'chat session'.


For example, Ann has all incoming sessions presented to their SIP client
but can hit a key to forward them to her assistant Bob. If it's an IM
chat session, and Bob gets into a long conversation, Ann does not want
to see every message, and have to hit a key to forward it.

=20

Anns client could forward 'subsequent' messages automatically, but then
Ann's client is implicitly taking on a notion of a 'session' and we are
into the implicit session setup debate again - how does it detect when
this session has ended and a new one started ? What happens if Ann turns
her client off before Bob has finished chatting ? Ann could instruct her
proxy to forwared SIP requests to Bob, but perhaps she doesn't want to.
Perhaps she wants new calls to go to her mobile, but the rest of Bob's
chat session to continue unaffected.

=20

So it's not just a message routing optimisation, there are other
resources being optimised too (Ann's time).

=20

(2) SIP messages are not media, sure, but Instant Messages are. Instant
Messages are not 'user to user signalling' either, because they are not
signalling - they are a communication between the human end-users, not
between the equipment facilitating that communication (which is how I
would characterise 'signalling' here). So perhaps SIP messages should
not be used to carry Instant Messages - but this is a different point
entirely.

=20

...Mark

=20

=20

	-----Original Message-----
	From: Dean Willis [mailto:dean.willis@softarmor.com]
	Sent: 18 September 2001 15:46
	To: simple
	Subject: Re: [Simple] Implicit MESSAGE sessions revisited

	=20

	I agree with #1,sortof. The best (only?) justfication for
INVITE-bounded message sessions is the use of Record-Route to allow
proxies that don't need to be in the route to opt out. This allows the
SIP-network to be "self optimizing" for message routing. However, such
SIP paths may be necessarily NOT end-to-end. For example, putting a SIP
UA behind a firewall proxy will require that messages transit the
firewall proxy. This is easily accomplished with record-route. Remember,
all the "signaling privacy" requirements like  calling-party-ID and
address-hiding apply to SIP messages. We already have mechanisms to meet
those requirements for SIP traffic -- reusing them for messages is
obviously functional.

	=20

	I disagree with requirement #2 -- SIP messages are inherently
NOT media. They are, in effect "user to user signaling". This is
consistent with my earlier position on the use of phone input (DTMF) as
"user to system signaling", not media.

	=20

	--
	Dean

		----- Original Message -----=20

		From: Mark Watson  =20

		To: 'Dean Willis'   ;
Patil Basavaraj (NET/Dallas)   ; 'ext
Ben Campbell'  =20

		Cc: simple  =20

		Sent: Monday, September 17, 2001 12:02 PM

		Subject: RE: [Simple] Implicit MESSAGE sessions
revisited

		=20

		Dean,

		=20

		I agree that they're independent. On the first one, I
had thought that the idea of IM 'sessions' fulfilled two key
requirements:

		=20

		1) I want to find my desired called party, and then
exchange multiple messages with this person

		=20

		Some of these things which can happen (in the
network/UEs) as a SIP message finds the desired end-user may take
time/cost money/require user interaction, and I don't want to repeat
them once I have found the person I want to chat to. Also, there is no
guarantee that repeating the process at a later time will get me to the
same end-user. So, I want to be able to do a 'session setup' and then
send messages directly to the person I've found.

		=20

		Of course, I could just treat the first message as an
implicit session setup, but this seems to be out of fashion.

		=20

		2) I want IM to be just another media that I can
negotiate, add & remove from a session etc.

		=20

		Again, I could do something clever with Call IDs to
connect a MESSAGE message with a pre-existing session etc. etc., but why
should I make an exception for this one kind of media. If I do that,
then no capabilities that I have now or invent in the future which are
supposed to be 'media type independent', will work for IM, and I will
have to be hacking the IM system constantly to keep up.

		=20

		Did you disagree with these requirements, or just with
the implementation ?

		=20

		Regards...Mark

			-----Original Message-----
			From: Dean Willis
[mailto:dean.willis@softarmor.com]
			Sent: 17 September 2001 17:32
			To: Watson, Mark [MAIFP:EP11:EXCH]; Patil
Basavaraj (NET/Dallas); 'ext Ben Campbell'
			Cc: simple
			Subject: Re: [Simple] Implicit MESSAGE sessions
revisited

			Both, actually. I believe the issues are
independent.

			=20

			--
			Dean

			=20

				----- Original Message -----=20

				From: Mark Watson
 =20

				To: 'Dean Willis'
  ; Patil Basavaraj (NET/Dallas)
  ; 'ext Ben Campbell'
 =20

				Cc: simple
 =20

				Sent: Monday, September 17, 2001 9:39 AM

				Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

				=20

				Dean,=20

				Do you mean that you don't see the
advantage of using INVITE to set up an IM 'session' (indicating this in
the SDP), or just that once such a session is set up, there is no need
for the 'media' to use any different protocol than that used for
'paging' ?

				I think there are a lot of reasons why
IM 'sessions' set up using INVITE just like any other SIP session, make
sense. I don't care much yet what the transport protocol then is for the
IMs in the session.

				Sorry if this is covering old ground.=20

				...Mark=20

			=09
			=09
			=09

				> -----Original Message-----=20
				> From: Dean Willis
[mailto:dean.willis@softarmor.com]=20
				> Sent: 15 September 2001 05:31=20
				> To: Patil Basavaraj (NET/Dallas); 'ext
Ben Campbell'=20
				> Cc: simple=20
				> Subject: Re: [Simple] Implicit MESSAGE
sessions revisited=20
				>=20
				>=20
				>=20
				> Just as MESSAGE for sessions has all
the wasted overhead of=20
				> headers and=20
				> routing mechanisms designed to find
users and traverse=20
				> firewalls (assuming=20
				> you think this is a waste), so does
BEEP.=20
				>=20
				> I personally have yet to see the need
for message sessions as=20
				> a specialized=20
				> transport.=20
				>=20
				> I think "pager" messages carrying a
session-ID and sequence number can=20
				> provide the same user experience.=20
				>=20
				> --=20
				> dean=20
				>=20
				>=20
				> ----- Original Message -----=20
				> From: "Patil Basavaraj (NET/Dallas)"
=20
				> To: "'ext Ben Campbell'"
=20
				> Cc: =20
				> Sent: Friday, September 14, 2001 1:07
PM=20
				> Subject: RE: [Simple] Implicit MESSAGE
sessions revisited=20
				>=20
				>=20
				> >=20
				> > One of the protocols that has been
suggested for use instead of=20
				> > MESSAGE is BEEP. Are there any
serious concerns *at this time*=20
				> > why BEEP would not be good eniugh
for IM Sessions?=20
				> >=20
				> > -Basavaraj=20
				> >=20
				> >=20
				> >
_______________________________________________=20
				> > simple mailing list=20
				> > simple@mailman.dynamicsoft.com=20
				> >
http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
				> >=20
				> >=20
				>=20
				>
_______________________________________________=20
				> simple mailing list=20
				> simple@mailman.dynamicsoft.com=20
				>
http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
				>=20


------_=_NextPart_001_01C140A9.F3E6A8F6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









RE: [Simple] Implicit MESSAGE sessions revisited











I’m not convinced that the =
“Ann”
example is legitimate.  This just sounds like a poor UI =
design.



 






-----Original Message-----

From: Mark Watson
[mailto:mwatson@nortelnetworks.com] 

Sent: Tuesday, September =
18, 2001
10:59 AM

To: 'Dean Willis'; =
simple

Subject: RE: [Simple] =
Implicit
MESSAGE sessions revisited



 






(1), it's not just a question of
optimising the message routing, it's also that in routing the initial =
INVITE I
may use up certain resources or require user intervention, and I don't =
want to
repeat all that for every message in the 'chat =
session'.











For example, Ann has all incoming sessions presented to their SIP =
client
but can hit a key to forward them to her assistant Bob. If it's an IM =
chat
session, and Bob gets into a long conversation, Ann does not want to see =
every
message, and have to hit a key to forward it.









 









Anns client could forward =
'subsequent'
messages automatically, but then Ann's client is implicitly taking on a =
notion
of a 'session' and we are into the implicit session setup debate again - =
how
does it detect when this session has ended and a new one started ? What =
happens
if Ann turns her client off before Bob has finished chatting ? Ann could
instruct her proxy to forwared SIP requests to Bob, but perhaps she =
doesn't
want to. Perhaps she wants new calls to go to her mobile, but the rest =
of Bob's
chat session to continue unaffected.









 









So it's not just a message routing
optimisation, there are other resources being optimised too (Ann's =
time).









 









(2) SIP messages are not media, =
sure, but
Instant Messages are. Instant Messages are not 'user to user signalling'
either, because they are not signalling - they are a communication =
between the
human end-users, not between the equipment facilitating that =
communication
(which is how I would characterise 'signalling' here). So perhaps SIP =
messages
should not be used to carry Instant Messages - but this is a different =
point
entirely.









 









...Mark









 









 









-----Original =
Message-----

From: Dean Willis
[mailto:dean.willis@softarmor.com]

Sent: 18 September 2001 =
15:46

To: simple

Subject: Re: [Simple] =
Implicit
MESSAGE sessions revisited






 









I agree with #1,sortof. The best (only?) =
justfication
for INVITE-bounded message sessions is the use of Record-Route to allow =
proxies
that don't need to be in the route to opt out. This allows the =
SIP-network to
be "self optimizing" for message routing. However, such SIP =
paths may
be necessarily NOT end-to-end. For example, putting a SIP UA behind a =
firewall
proxy will require that messages transit the firewall proxy. This is =
easily
accomplished with record-route. Remember, all the "signaling =
privacy"
requirements like  calling-party-ID and address-hiding apply to SIP
messages. We already have mechanisms to meet those requirements for SIP =
traffic
-- reusing them for messages is obviously functional.









 









I disagree with requirement #2 -- SIP messages are
inherently NOT media. They are, in effect "user to user =
signaling".
This is consistent with my earlier position on the use of phone input =
(DTMF) as
"user to system signaling", not media.









 









--

Dean












----- Original Message ----- 









From: Mark
Watson 











Cc: simple 









Sent: Monday, =
September
17, 2001 12:02 PM









Subject: RE: =
[Simple]
Implicit MESSAGE sessions revisited









 









Dean,









 









I agree that they're independent. =
On the
first one, I had thought that the idea of IM 'sessions' fulfilled =
two key
requirements:









 









1) I want to find my desired =
called
party, and then exchange multiple messages with this =
person









 









Some of these things which can =
happen
(in the network/UEs) as a SIP message finds the desired end-user may =
take
time/cost money/require user interaction, and I don't want to repeat =
them once
I have found the person I want to chat to. Also, there is no guarantee =
that
repeating the process at a later time will get me to the same end-user. =
So, I
want to be able to do a 'session setup' and then send messages directly =
to the
person I've found.









 









Of course, I could just treat the =
first
message as an implicit session setup, but this seems to be out of =
fashion.









 









2) I want IM to be just another =
media
that I can negotiate, add & remove from a session =
etc.









 









Again, I could do something =
clever with
Call IDs to connect a MESSAGE message with a pre-existing session etc. =
etc.,
but why should I make an exception for this one kind of media. If I do =
that,
then no capabilities that I have now or invent in the future which are =
supposed
to be 'media type independent', will work for IM, and I will have to be =
hacking
the IM system constantly to keep up.









 









Did you disagree with these
requirements, or just with the implementation ?









 









Regards...Mark









-----Original =
Message-----

From: Dean Willis
[mailto:dean.willis@softarmor.com]

Sent: 17 September 2001 =
17:32

To: Watson, Mark
[MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'

Cc: simple

Subject: Re: [Simple] =
Implicit
MESSAGE sessions revisited






Both, actually. I believe the issues are =
independent.









 









--

Dean









 












----- Original Message ----- 









From: Mark
Watson 











Cc: simple 









Sent: Monday, =
September
17, 2001 9:39 AM









Subject: RE: =
[Simple]
Implicit MESSAGE sessions revisited









 






Dean,




Do you
mean that you don't see the advantage of using INVITE to set up an IM =
'session'
(indicating this in the SDP), or just that once such a session is set =
up, there
is no need for the 'media' to use any different protocol than that used =
for
'paging' ?



I think
there are a lot of reasons why IM 'sessions' set up using INVITE just =
like any
other SIP session, make sense. I don't care much yet what the transport
protocol then is for the IMs in the session.



Sorry if
this is covering old ground. 



...Mark












>
-----Original Message----- 

> From: Dean Willis =
[mailto:dean.willis@softarmor.co=
m]


> Sent: 15 September =
2001 05:31


> To: Patil Basavaraj
(NET/Dallas); 'ext Ben Campbell' 

> Cc: =
simple 

> Subject: Re: =
[Simple] Implicit
MESSAGE sessions revisited 

> 

> 

> 

> Just as MESSAGE for =
sessions
has all the wasted overhead of 

> headers =
and 

> routing mechanisms =
designed to
find users and traverse 

> firewalls =
(assuming


> you think this is a =
waste), so
does BEEP. 

> 

> I personally have =
yet to see
the need for message sessions as 

> a =
specialized 

> =
transport. 

> 

> I think =
"pager"
messages carrying a session-ID and sequence number can =


> provide the same =
user
experience. 

> 

> -- =


> dean =


> 

> 

> ----- Original =
Message -----


> From: "Patil =
Basavaraj
(NET/Dallas)" <Basavaraj.Patil@nokia.com> 

> To: "'ext Ben
Campbell'" <bcampbell@dynamicsoft.com> 

> Cc:
<simple@mailman.dynamicsoft.com> 

> Sent: Friday, =
September 14,
2001 1:07 PM 

> Subject: RE: =
[Simple] Implicit
MESSAGE sessions revisited 

> 

> 

> > =


> > One of the =
protocols that
has been suggested for use instead of 

> > MESSAGE is =
BEEP. Are
there any serious concerns *at this time* 

> > why BEEP would =
not be
good eniugh for IM Sessions? 

> > =


> > =
-Basavaraj 

> > =


> > =


> >
_______________________________________________ 

> > simple mailing =
list


> >
simple@mailman.dynamicsoft.com 

> > http://mailman.dynamicsoft.com/mailman/listinfo/simple<=
/a>


> > =


> > =


> 

>
_______________________________________________ 

> simple mailing =
list


> =
simple@mailman.dynamicsoft.com


> http://mailman.dynamicsoft.com/mailman/listinfo/simple<=
/a>


> 























=00
------_=_NextPart_001_01C140A9.F3E6A8F6--

--------------InterScan_NT_MIME_Boundary--


From akristensen@dynamicsoft.com  Tue Sep 18 22:01:16 2001
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 WAA08549
	for ; Tue, 18 Sep 2001 22:01:16 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.156])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8J2078P002769;
	Tue, 18 Sep 2001 22:00:07 -0400 (EDT)
Message-ID: <3BA7FC62.A7F499C1@dynamicsoft.com>
Date: Tue, 18 Sep 2001 22:01:06 -0400
From: Anders Kristensen 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Sean Olson (EUS)" 
CC: "'Jonathan Rosenberg'" ,
        "'Robert Brown'" ,
        Avshalom Houri , simple@mailman.dynamicsoft.com,
        "Adam Roach (E-mail)" 
Subject: Re: [Simple] Partial Notifies?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 6338
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: 


"Sean Olson (EUS)" wrote:
> 
> >I believe the requirements for the partial notifications are
> >the following:
> >
> >1. the subscribe request have a way for the subscriber to indicate
> what
> >version they have, so that the notify only contain a delta
> >from that version
> >(indeed, perhaps the notify isn't even sent if the version the
> >subscriber
> >has is up to date)
> 
> It would also be nice to support packages that do not
> keep multiple versions around on the server. The delta
> would always be against the most recent version and
> if you are out of sync you would retrieve the complete
> state in a fetch first, then apply the latest delta.
> 
> >
> >2. the notify have a way to indicate what version of the document the
> 
> >subscriber will have once the patch is applied
> >
> >3. the notify have a way to indicate what version the of the
> >document the
> >subscriber has to apply the patch against (i.e, the old version)
> >
> >4. the "patch" be in a format that is independent of the format of
> the
> >presence document.
> 
> Would a Content-Encoding or Content-Transfer-Encoding
> be appropriate here? What is the goal of partial notifies?
> Is it simply to reduce message size?

Yes, that would be the only goal. Simplicity on the client side would
likely be a requirement also.

 If so, gzip or deflate
> compression of the body may be sufficient.

Yes, might be. As a side note, gzip might still be applied to a diff
itself to further lessen size.

> 
> >Anders Kristensen had pointed out to me that webdav has looked
> >at a very
> >similar problem, and that there are specs for deltas within
> >http. I haven't
> >looked at those in detail, but they might provide a solution
> >for us that
> >would allow us to reuse existing work elsewhere in IETF.
> 
> see
> http://search.ietf.org/internet-drafts/draft-ietf-deltav-versioning-18.txt
> 
> WebDAV deals with a more sophisticated concept of version
> control that is appropriate for document or source code
> control. For example, it allows forking and merging of
> versions. Do we need this level of complexity for
> partial notifies? I think (hope) not.

That sure sounds like way too much. The draft I had in mind was
http://www.ietf.org/internet-drafts/draft-mogul-http-delta-08.txt

This details how various diff algorithms (textual or binary - the
mechanism works with either) can be used to reduce the message size when
the client has an old version of some resource. It seems like it should
be fairly straightforward to apply the same ideas to SIP.

> 
> One very interesting concept we can borrow from WebDAV
> is the notion of versioning information embedded in a
> URL. This could obviously be included in the Request-URI
> of a SUBSCRIBE to indicate the current version that the
> client has. It could also be included in the Request-URI
> of the NOTIFY.
> 
> >
> >So, the quesitons to be discussed, in order, are:
> >
> >1. is there consensus that we should have a solution for
> >partial notifies in
> >simple?
> 
> Yes, but ... I think it is also useful to allow
> a client to use the current "every NOTIFY contains
> complete state" model. What I would propose is a
> ".delta" sub-package that an event package could
> support if a client wishes to receive partial notifies.
> Doing a one-time fetch of the base package gives complete
> state. From that point on, the client can SUBSCRIBE to the
> .delta sub-package if it wishes to receive partial notifies.
> 
> This leaves the possibility for both modes of operation.
> 
> >
> >2. is there consensus that this should be done in a general
> >fashion as part
> >of the sip events specification?

If we go with a generic diff model it may be that it is more widely
applicable than sip events. Or at least independent.

> 
> Yes, but should it go into the base SUB/NOT draft or should
> there be another draft describing versioning as an optional
> extension to SUB/NOT? I would prefer to close the base SUB/NOT
> draft as quickly as possible. Partial notifies may be a useful
> extension, but they don't seem valuable enough to warrant
> slowing down the standardization of SUB/NOT (upon which a
> bunch of other work is dependent)
> 
> >3. how should it be done?
> 
> I'm assuming that version information will be opaque
> strings/tokens.
> 
> A "Label:" header as proposed in the WebDAV work might
> be useful for satisfying requirements 1 and 2 above.
> 
> >Comments?
> >-Jonathan R.
> 
> Regards,
> Sean Olson
> Ericsson Inc.


So here's a sketch of how this might work in SIP.

Clients would indicate support for one or more delta encoding mechanisms
in SUBSCRIBEs by listing extension token 'delta' in a Supported header
and the actual "instance manipulations" supported in an A-IM header
(A-IM stands for Accept-Instance-Manipulations and is defined in the
http draft as is the IM header used in NOTIFYes):

        SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
        Supported: delta
        A-IM: diffe, vcdiff
        Event: presence
        ...

the server would make a note of supported alg's in the subscription
"record".

The server then has to know what version of a particular subscription
doc a watcher has received, and when it sends a NOTIFY for a watcher it
may send only a delta if that guy has indicated support for it, e.g.:

        NOTIFY sip:user@watcherhost.example.com SIP/2.0
        Require: delta
        IM: diffe
        Delta-Base: "abc"
        Etag: "ghi"
        Event: presence
        Content-Type: application/cpim-pidf+xml

        ...

Unlike the http case there's no request in which a version number/tag
can be carried so presumably the server has to just know what version of
the presence doc (or whatever) the client knows about, or else assume
that it knows about the previous version.  If for some reason the client
doesn't, it would return some error response which would tell the server
to send the whole resource/document. The error response would also list
the A-IM and Supported header as appropriate.

The Delta-Base header gives the version of the resource that the delta
should be applied to (and which the client is assumed to possess). The
ETag gives an identifier for the new resource.

A presence server that doesn't know about the delta extension just
ignores the A-IM header and sends the full update every time.

Anders

From mwatson@nortelnetworks.com  Wed Sep 19 05:01:49 2001
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09825
	for ; Wed, 19 Sep 2001 05:01:48 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f8J91gg03527
	for ; Wed, 19 Sep 2001 10:01:42 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 19 Sep 2001 10:01:26 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 19 Sep 2001 10:01:25 +0100
Message-ID: 
From: "Mark Watson" 
To: "'Robert Brown'" ,
        Dean Willis ,
        simple 
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Wed, 19 Sep 2001 10:01:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C140E9.A8DA9720"
Content-Length: 39167
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: 

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_01C140E9.A8DA9720
Content-Type: text/plain;
	charset="iso-8859-1"

Can you explain - I would have thought that allowing a user to screen
incoming sessions and decide on their disposition without answering the
session would be a common requirement. I don't understand how you could
avoid the problem below just by changing the UI.
 
...Mark

-----Original Message-----
From: Robert Brown [mailto:roberbr@microsoft.com]
Sent: 19 September 2001 02:25
To: Watson, Mark [MAIFP:EP11:EXCH]; Dean Willis; simple
Subject: RE: [Simple] Implicit MESSAGE sessions revisited



I'm not convinced that the "Ann" example is legitimate.  This just sounds
like a poor UI design.

 

-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com] 
Sent: Tuesday, September 18, 2001 10:59 AM
To: 'Dean Willis'; simple
Subject: RE: [Simple] Implicit MESSAGE sessions revisited

 

(1), it's not just a question of optimising the message routing, it's also
that in routing the initial INVITE I may use up certain resources or require
user intervention, and I don't want to repeat all that for every message in
the 'chat session'.


For example, Ann has all incoming sessions presented to their SIP client but
can hit a key to forward them to her assistant Bob. If it's an IM chat
session, and Bob gets into a long conversation, Ann does not want to see
every message, and have to hit a key to forward it.

 

Anns client could forward 'subsequent' messages automatically, but then
Ann's client is implicitly taking on a notion of a 'session' and we are into
the implicit session setup debate again - how does it detect when this
session has ended and a new one started ? What happens if Ann turns her
client off before Bob has finished chatting ? Ann could instruct her proxy
to forwared SIP requests to Bob, but perhaps she doesn't want to. Perhaps
she wants new calls to go to her mobile, but the rest of Bob's chat session
to continue unaffected.

 

So it's not just a message routing optimisation, there are other resources
being optimised too (Ann's time).

 

(2) SIP messages are not media, sure, but Instant Messages are. Instant
Messages are not 'user to user signalling' either, because they are not
signalling - they are a communication between the human end-users, not
between the equipment facilitating that communication (which is how I would
characterise 'signalling' here). So perhaps SIP messages should not be used
to carry Instant Messages - but this is a different point entirely.

 

...Mark

 

 

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 18 September 2001 15:46
To: simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited

 

I agree with #1,sortof. The best (only?) justfication for INVITE-bounded
message sessions is the use of Record-Route to allow proxies that don't need
to be in the route to opt out. This allows the SIP-network to be "self
optimizing" for message routing. However, such SIP paths may be necessarily
NOT end-to-end. For example, putting a SIP UA behind a firewall proxy will
require that messages transit the firewall proxy. This is easily
accomplished with record-route. Remember, all the "signaling privacy"
requirements like  calling-party-ID and address-hiding apply to SIP
messages. We already have mechanisms to meet those requirements for SIP
traffic -- reusing them for messages is obviously functional.

 

I disagree with requirement #2 -- SIP messages are inherently NOT media.
They are, in effect "user to user signaling". This is consistent with my
earlier position on the use of phone input (DTMF) as "user to system
signaling", not media.

 

--
Dean

----- Original Message ----- 

From: Mark Watson   

To: 'Dean Willis'   ; Patil Basavaraj
(NET/Dallas)   ; 'ext Ben Campbell'
  

Cc: simple   

Sent: Monday, September 17, 2001 12:02 PM

Subject: RE: [Simple] Implicit MESSAGE sessions revisited

 

Dean,

 

I agree that they're independent. On the first one, I had thought that the
idea of IM 'sessions' fulfilled two key requirements:

 

1) I want to find my desired called party, and then exchange multiple
messages with this person

 

Some of these things which can happen (in the network/UEs) as a SIP message
finds the desired end-user may take time/cost money/require user
interaction, and I don't want to repeat them once I have found the person I
want to chat to. Also, there is no guarantee that repeating the process at a
later time will get me to the same end-user. So, I want to be able to do a
'session setup' and then send messages directly to the person I've found.

 

Of course, I could just treat the first message as an implicit session
setup, but this seems to be out of fashion.

 

2) I want IM to be just another media that I can negotiate, add & remove
from a session etc.

 

Again, I could do something clever with Call IDs to connect a MESSAGE
message with a pre-existing session etc. etc., but why should I make an
exception for this one kind of media. If I do that, then no capabilities
that I have now or invent in the future which are supposed to be 'media type
independent', will work for IM, and I will have to be hacking the IM system
constantly to keep up.

 

Did you disagree with these requirements, or just with the implementation ?

 

Regards...Mark

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 17 September 2001 17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); 'ext Ben
Campbell'
Cc: simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited

Both, actually. I believe the issues are independent.

 

--
Dean

 

----- Original Message ----- 

From: Mark Watson   

To: 'Dean Willis'   ; Patil Basavaraj
(NET/Dallas)   ; 'ext Ben Campbell'
  

Cc: simple   

Sent: Monday, September 17, 2001 9:39 AM

Subject: RE: [Simple] Implicit MESSAGE sessions revisited

 

Dean, 

Do you mean that you don't see the advantage of using INVITE to set up an IM
'session' (indicating this in the SDP), or just that once such a session is
set up, there is no need for the 'media' to use any different protocol than
that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set up using INVITE
just like any other SIP session, make sense. I don't care much yet what the
transport protocol then is for the IMs in the session.

Sorry if this is covering old ground. 

...Mark 





> -----Original Message----- 
> From: Dean Willis [ mailto:dean.willis@softarmor.com
 ] 
> Sent: 15 September 2001 05:31 
> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell' 
> Cc: simple 
> Subject: Re: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> 
> Just as MESSAGE for sessions has all the wasted overhead of 
> headers and 
> routing mechanisms designed to find users and traverse 
> firewalls (assuming 
> you think this is a waste), so does BEEP. 
> 
> I personally have yet to see the need for message sessions as 
> a specialized 
> transport. 
> 
> I think "pager" messages carrying a session-ID and sequence number can 
> provide the same user experience. 
> 
> -- 
> dean 
> 
> 
> ----- Original Message ----- 
> From: "Patil Basavaraj (NET/Dallas)"  
> To: "'ext Ben Campbell'"  
> Cc:  
> Sent: Friday, September 14, 2001 1:07 PM 
> Subject: RE: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> > 
> > One of the protocols that has been suggested for use instead of 
> > MESSAGE is BEEP. Are there any serious concerns *at this time* 
> > why BEEP would not be good eniugh for IM Sessions? 
> > 
> > -Basavaraj 
> > 
> > 
> > _______________________________________________ 
> > 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_01C140E9.A8DA9720
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: [Simple] Implicit MESSAGE sessions revisited






Can=20
you explain - I would have thought that allowing a user to screen =
incoming=20
sessions and decide on their disposition without answering the session =
would be=20
a common requirement. I don't understand how you could avoid the =
problem below=20
just by changing the UI.


 


...Mark



  
-----Original Message-----
From: Robert Brown=20
  [mailto:roberbr@microsoft.com]
Sent: 19 September 2001=20
  02:25
To: Watson, Mark [MAIFP:EP11:EXCH]; Dean Willis;=20
  simple
Subject: RE: [Simple] Implicit MESSAGE sessions=20
  revisited


  

  
I’m =
not convinced=20
  that the “Ann” example is legitimate.  This just =
sounds like a poor UI=20
  design.

  
 

  
  
-----Original=20
  Message-----
From: =
Mark=20
  Watson [mailto:mwatson@nortelnetworks.com] 
Sent: Tuesday, September 18, =
2001 10:59=20
  AM
To: 'Dean =
Willis';=20
  simple
Subject: =
RE: [Simple]=20
  Implicit MESSAGE sessions revisited

  
 

  

  
(1), it's =
not just a=20
  question of optimising the message routing, it's also that in routing =
the=20
  initial INVITE I may use up certain resources or require user =
intervention,=20
  and I don't want to repeat all that for every message in the 'chat=20
  session'.

  

  

For=20
  example, Ann has all incoming sessions presented to their SIP =
client but=20
  can hit a key to forward them to her assistant Bob. If it's an IM =
chat=20
  session, and Bob gets into a long conversation, Ann does not want to =
see every=20
  message, and have to hit a key to forward it.

  

  
 

  

  
Anns =
client could=20
  forward 'subsequent' messages automatically, but then Ann's client is =

  implicitly taking on a notion of a 'session' and we are into the =
implicit=20
  session setup debate again - how does it detect when this session has =
ended=20
  and a new one started ? What happens if Ann turns her client off =
before Bob=20
  has finished chatting ? Ann could instruct her proxy to forwared SIP =
requests=20
  to Bob, but perhaps she doesn't want to. Perhaps she wants new calls =
to go to=20
  her mobile, but the rest of Bob's chat session to continue=20
  unaffected.

  

  
 

  

  
So it's =
not just a=20
  message routing optimisation, there are other resources being =
optimised too=20
  (Ann's time).

  

  
 

  

  
(2) SIP =
messages are=20
  not media, sure, but Instant Messages are. Instant Messages are not =
'user to=20
  user signalling' either, because they are not signalling - they are a =

  communication between the human end-users, not between the equipment=20
  facilitating that communication (which is how I would characterise=20
  'signalling' here). So perhaps SIP messages should not be used to =
carry=20
  Instant Messages - but this is a different point=20
  entirely.

  

  
 

  

  
...Mark

  

  
 

  

  
 

  

    
-----Original=20
    Message-----
From: Dean=20
    Willis [mailto:dean.willis@softarmor.com]
Sent: 18 September 2001=20
    15:46
To:=20
    simple
Subject: =
Re:=20
    [Simple] Implicit MESSAGE sessions revisited

    

    
 

    

    
I agree with =
#1,sortof. The=20
    best (only?) justfication for INVITE-bounded message sessions is =
the use of=20
    Record-Route to allow proxies that don't need to be in the route to =
opt out.=20
    This allows the SIP-network to be "self optimizing" for message =
routing.=20
    However, such SIP paths may be necessarily NOT end-to-end. For =
example,=20
    putting a SIP UA behind a firewall proxy will require that messages =
transit=20
    the firewall proxy. This is easily accomplished with record-route. =
Remember,=20
    all the "signaling privacy" requirements like  =
calling-party-ID and=20
    address-hiding apply to SIP messages. We already have mechanisms to =
meet=20
    those requirements for SIP traffic -- reusing them for messages is =
obviously=20
    functional.

    

    
 

    

    
I disagree with =
requirement #2=20
    -- SIP messages are inherently NOT media. They are, in effect "user =
to user=20
    signaling". This is consistent with my earlier position on the use =
of phone=20
    input (DTMF) as "user to system signaling", not=20
    media.

    

    
 

    

    
--
Dean

    
      

      
----- Original =
Message -----=20
      

      
      

      
To: 'Dean Willis' ; Patil Basavaraj =
(NET/Dallas) ; 'ext Ben Campbell'=20
      

      

      
Cc: simple =


      

      
Sent:=20
      Monday, September 17, 2001 12:02 PM

      

      
Subject: RE:=20
      [Simple] Implicit MESSAGE sessions =
revisited

      

      
 

      

      
Dean,

      

      
 

      

      
I =
agree that=20
      they're independent. On the first one, I had thought =
that the idea of=20
      IM 'sessions' fulfilled two key =
requirements:

      

      
 

      

      
1) I =
want to=20
      find my desired called party, and then exchange multiple messages =
with=20
      this person

      

      
 

      

      
Some =
of these=20
      things which can happen (in the network/UEs) as a SIP message =
finds the=20
      desired end-user may take time/cost money/require user =
interaction, and I=20
      don't want to repeat them once I have found the person I want to =
chat to.=20
      Also, there is no guarantee that repeating the process at a later =
time=20
      will get me to the same end-user. So, I want to be able to do a =
'session=20
      setup' and then send messages directly to the person I've=20
      found.

      

      
 

      

      
Of =
course, I=20
      could just treat the first message as an implicit session setup, =
but this=20
      seems to be out of fashion.

      

      
 

      

      
2) I =
want IM to=20
      be just another media that I can negotiate, add & remove from =
a=20
      session etc.

      

      
 

      

      
Again, I could=20
      do something clever with Call IDs to connect a MESSAGE message =
with a=20
      pre-existing session etc. etc., but why should I make an =
exception for=20
      this one kind of media. If I do that, then no capabilities that I =
have now=20
      or invent in the future which are supposed to be 'media type =
independent',=20
      will work for IM, and I will have to be hacking the IM system =
constantly=20
      to keep up.

      

      
 

      

      
Did =
you=20
      disagree with these requirements, or just with the implementation =

      ?

      

      
 

      

      
Regards...Mark

      
        
-----Original=20
        Message-----
From: Dean=20
        Willis [mailto:dean.willis@softarmor.com]
Sent: 17 September 2001=20
        17:32
To: =
Watson, Mark=20
        [MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); 'ext Ben=20
        Campbell'
Cc:=20
        simple
Subject: Re:=20
        [Simple] Implicit MESSAGE sessions revisited

        

        
Both, actually. I =
believe=20
        the issues are independent.

        

        
 

        

        
--
Dean

        

        
 

        
          

          
----- Original =
Message=20
          ----- 

          

          
From:=20
          Mark Watson=20
          

          

          
To:=20
          'Dean Willis' ; Patil Basavaraj =
(NET/Dallas) ; 'ext Ben Campbell'=20
          

          

          
Cc:=20
          simple=20
          

          

          
Sent:=20
          Monday, September 17, 2001 9:39 AM

          

          
Subject:=20
          RE: [Simple] Implicit MESSAGE sessions=20
          revisited

          

          
 

          
Dean, 

          
Do you mean that you don't see the =
advantage=20
          of using INVITE to set up an IM 'session' (indicating this in =
the=20
          SDP), or just that once such a session is set up, there is no =
need for=20
          the 'media' to use any different protocol than that used for =
'paging'=20
          ?

          
I=20
          think there are a lot of reasons why IM 'sessions' set up =
using INVITE=20
          just like any other SIP session, make sense. I don't care =
much yet=20
          what the transport protocol then is for the IMs in the=20
          session.

          
Sorry if this is covering old=20
          ground. 

          
...Mark 

          



          
> -----Original =
Message-----=20
          
> From: =
Dean Willis=20
          [mailto:dean.willis@softarmor.c=
om]=20
          
> Sent: =
15 September=20
          2001 05:31 
> To: Patil Basavaraj =
(NET/Dallas); 'ext=20
          Ben Campbell' 
> Cc: simple =

> Subject: Re: =
[Simple]=20
          Implicit MESSAGE sessions revisited 
> =

> =

> =

> Just as MESSAGE =
for sessions=20
          has all the wasted overhead of 
> headers and =

> routing =
mechanisms designed=20
          to find users and traverse 
> firewalls =
(assuming=20
          
> you =
think this is=20
          a waste), so does BEEP. 
> 
> I personally have yet to see =
the need for=20
          message sessions as 
> a specialized =

> =
transport.=20
          
>=20
          
> I=20
          think "pager" messages carrying a session-ID and sequence =
number=20
          can 
>=20
          provide the same user experience. 
> 
> -- 
> dean 
> 
> 
> ----- Original Message=20
          ----- 
> From: "Patil Basavaraj =
(NET/Dallas)"=20
          <Basavaraj.Patil@nokia.com> 
> To: "'ext Ben Campbell'"=20
          <bcampbell@dynamicsoft.com> 
> Cc:=20
          <simple@mailman.dynamicsoft.com> =

> Sent: Friday, =
September 14,=20
          2001 1:07 PM 
> Subject: RE: [Simple] Implicit =
MESSAGE=20
          sessions revisited 
> 
> 
> > 
> > One of the protocols that =
has been=20
          suggested for use instead of 
> > MESSAGE is BEEP. Are =
there any=20
          serious concerns *at this time* 
> > why BEEP would not be =
good eniugh=20
          for IM Sessions? 
> > 
> > -Basavaraj =

> =
> 
> =
> 
> >=20
          _______________________________________________ =

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

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



------_=_NextPart_001_01C140E9.A8DA9720--

From madhavb@trinc.com  Wed Sep 19 06:29:49 2001
Received: from brahma.roc.com ([202.125.87.14])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10156
	for ; Wed, 19 Sep 2001 06:29:45 -0400 (EDT)
Received: from localhost (madhavb@localhost)
	by brahma.roc.com (8.9.3/8.8.7) with ESMTP id QAA24015
	for ; Wed, 19 Sep 2001 16:00:53 +0530
X-Authentication-Warning: brahma.roc.com: madhavb owned process doing -bs
Date: Wed, 19 Sep 2001 16:00:53 +0530 (IST)
From: Madhav B 
X-Sender: madhavb@brahma.roc.com
To: simple@mailman.dynamicsoft.com
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 745
Subject: [Simple] Regarding Conference Call Setup
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: 






Hello,

        I have some doubts regarding the conferece call setup 

        1. wheather the non-initiator can invite the third or a subsequent
person, which means if A initiates a conference call to B and C,
is it possible for B or C to inivite D?

        2. is SIP signalling unicast or multicast? i,e I want to know
wheather INVITE or subsequent methods are sent sent point to point.
supposing A, B, C and D are in conference, if D wants quit does
it send send BYE just to the initiator or to all of the remaining
participants?

In the Example given in SIP RFC 2543(16.2 section), how does a proxy
adds maddr in Via(maddr=239.128.16.254;ttl=16), header, 
will it add based on the response from location server?	

Thanks,
Madhav





From bstucker@nortelnetworks.com  Wed Sep 19 10:09:13 2001
Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10867
	for ; Wed, 19 Sep 2001 10:09:13 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA10685
	for ; Wed, 19 Sep 2001 09:08:55 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 19 Sep 2001 09:08:58 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 19 Sep 2001 09:08:50 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E099E58@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Jonathan Rosenberg ,
        "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Questions on the current presence draft.
Date: Wed, 19 Sep 2001 09:08:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14114.9BC4C580"
Content-Length: 17769
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: 

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_01C14114.9BC4C580
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks for the clairification.

I'd like to make the problem of the watcher not getting a notification that
their
subscription has expired (due to a migration) because of a temporary failure
at the watcher,
or in the network, go away without a huge hassle if that is possible.

The scenario I'm thinking of would cause problems if the watcher simply
decided to go offline
when the migration occurred. No network failure needed, they just had their
machine turned off
during that time. The problem that I see is that you're right, and you'd
wind up likely creating
a flood of network traffic at some point to recover from this. 

Maybe a note in there somewhere that when a watcher has been SIP unreachable
(powered down, client
software not running, etc.), they need to fetch their subscriptions again
(at a reasonable rate)
in case a migration has occurred?

Thanks,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, September 18, 2001 6:28 AM
To: Stucker, Brian [NGB:B651:EXCH]; 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Questions on the current presence draft.




  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Tuesday, September 11, 2001 3:30 PM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] Questions on the current presence draft.


>I was reading through the current draft, and noticed a few things that I 
>was looking for clairification on. 
>In the section on presence migration, the last sentence of the description 
>for the second phase of presence migration states: "...This informs the
subscribers that 
>their 
>subscription was destroyed, and should be re-established with a new
SUBSCRIBE (with a new 
>Call-ID)." 
>I was wondering, if a watcher was offline when the NOTIFY containing the
"Subscription-
>Expires" header 
>to destroy the current subscription, what are the implications with the
call id? I would 
>imagine when the 
>watcher comes back online, and tries to refresh the subscription, it would
use the old 
>call-id (since it doesn't 
>know that it needs to reselect), which gets proxied to the new PA (after
the migration 
>occurred). This seems like a gap to me.

There are two cases here. In case 1, when the subscriber goes "offline", all
subscriptions state is lost. This would happen when a PC application is
terminated, for example. In that case, when the watcher comes back, it will
have no record of previous subscription state. So, it creates a new
subscription with a brand new call ID. No problems.

In case 2, the subscriber goes "offline" in the sense that its network
connectivity is lost, so it won't get the NOTIFY, but it still retains
subscription state. THis would be the case, for example, with a mobile phone
that goes out of range. When the mobile comes back in range, it will
re-subscribe with the old call-id/route-set, in order to obtain the latest
data it may have missed while out of range. Since this subscribe has a route
set, the request will arrive at the presence server (the one that formerly
owned the subscriptions, but has since migrated them) with the URL of the
presence server in the request URI (like sip:presence-server-1.foo.com).
Since the URL points to itself, the presence server knows that it should
process it. Since no subscriptions exist, this request would be rejected
with a 481. Should it be proxied anyway to the PUA now handling the
subscription, it would probably also be rejected with a 481 because the tags
don't match those of any existing subscriptions at the PUA.

The 481 would trigger the subscriber to retry the subscription with a fresh
call-id and no route set.

The specifications are not clear at the moment about the handling of the
case when you get a subscribe with a tag in the To field that doesn't match
an existing subscription. That needs to be clarified in the events framework
spec. I'll send a note to Adam about it.

>
>Also, what happens if the watchers (previous to the migration) never
receive the NOTIFY to 
>update their 
>subscriptions to cause a refresh. Unless they do a fetch, the new PA
doesn't know that 
>they exist, so their 
>subscriptions will be effectively moot, but they won't be aware of this
fact. They won't 
>get any notifications, and 
>won't know that their subscriptions are being ignored. 

I think this is the same problem I discussed above. The question you need to
ask is why the watcher would not have gotten the NOTIFY. Assuming the
watcher application is running the whole time, the only reason this would
occur is a network failure of some sort, or a failure of the presence server
itself. Network failures that occur because the mobile has gone out of range
are generally detectable, and so the mobile can do something about it.
Network failures in the middle of the network which occur for long enough to
prevent a notification from being delivered (in excess of 16s) are hard to
deal with in any protocol. A "nice" presence agent could retain the
subscription state unless it gets a positive response to the NOTIFY, but
that can be used as a DoS attack. So, I don't know how solve this particular
failure case. There will be a gap in the delivery of notifications for the
duration of a refresh period. Given the scope of the failure that must occur
for that to happen, I think thats acceptable. 

Failures of the presence server itself can be handled using traditional
mechanisms, such as replication of subscription state to a hot standby.


>
>In section 8, there are mixed uses of the presence URL and SIP URL's. Is
this done 
>intentionally? 

No. My error. I've changed them all to sip URLs. Thanks.

>
>Finally, can someone point a link to the draft listed as [4] in the
bibliography? It 
>doesn't seem to be available 
>at the IETF webpage. 

It just recently expired. The impp chairs have been pinging the editor to
resubmit an update. 

Until then, you can get a copy from google's cached version of the draft:
http://www.google.com/search?q=cache:jdFIIPRBPY0:www.ietf.org/internet-draft
s/draft-ietf-impp-cpim-01.txt+draft-ietf-impp-cpim&hl=en

Thanks for your comments,
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_01C14114.9BC4C580
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Questions on the current presence draft.




Thanks for the clairification.




I'd like to make the problem of the watcher not getting a notification that their

subscription has expired (due to a migration) because of a temporary failure at the watcher,

or in the network, go away without a huge hassle if that is possible.




The scenario I'm thinking of would cause problems if the watcher simply decided to go offline

when the migration occurred. No network failure needed, they just had their machine turned off

during that time. The problem that I see is that you're right, and you'd wind up likely creating

a flood of network traffic at some point to recover from this. 




Maybe a note in there somewhere that when a watcher has been SIP unreachable (powered down, client

software not running, etc.), they need to fetch their subscriptions again (at a reasonable rate)

in case a migration has occurred?




Thanks,




Brian




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Tuesday, September 18, 2001 6:28 AM

To: Stucker, Brian [NGB:B651:EXCH]; 'simple@mailman.dynamicsoft.com'

Subject: RE: [Simple] Questions on the current presence draft.










  

-----Original Message-----

From: Brian Stucker [mailto:bstucker@nortelnetworks.com]

Sent: Tuesday, September 11, 2001 3:30 PM

To: 'simple@mailman.dynamicsoft.com'

Subject: [Simple] Questions on the current presence draft.






>I was reading through the current draft, and noticed a few things that I 

>was looking for clairification on. 

>In the section on presence migration, the last sentence of the description 

>for the second phase of presence migration states: "...This informs the

subscribers that 

>their 

>subscription was destroyed, and should be re-established with a new

SUBSCRIBE (with a new 

>Call-ID)." 

>I was wondering, if a watcher was offline when the NOTIFY containing the

"Subscription-

>Expires" header 

>to destroy the current subscription, what are the implications with the

call id? I would 

>imagine when the 

>watcher comes back online, and tries to refresh the subscription, it would

use the old 

>call-id (since it doesn't 

>know that it needs to reselect), which gets proxied to the new PA (after

the migration 

>occurred). This seems like a gap to me.




There are two cases here. In case 1, when the subscriber goes "offline", all

subscriptions state is lost. This would happen when a PC application is

terminated, for example. In that case, when the watcher comes back, it will

have no record of previous subscription state. So, it creates a new

subscription with a brand new call ID. No problems.




In case 2, the subscriber goes "offline" in the sense that its network

connectivity is lost, so it won't get the NOTIFY, but it still retains

subscription state. THis would be the case, for example, with a mobile phone

that goes out of range. When the mobile comes back in range, it will

re-subscribe with the old call-id/route-set, in order to obtain the latest

data it may have missed while out of range. Since this subscribe has a route

set, the request will arrive at the presence server (the one that formerly

owned the subscriptions, but has since migrated them) with the URL of the

presence server in the request URI (like sip:presence-server-1.foo.com).

Since the URL points to itself, the presence server knows that it should

process it. Since no subscriptions exist, this request would be rejected

with a 481. Should it be proxied anyway to the PUA now handling the

subscription, it would probably also be rejected with a 481 because the tags

don't match those of any existing subscriptions at the PUA.




The 481 would trigger the subscriber to retry the subscription with a fresh

call-id and no route set.




The specifications are not clear at the moment about the handling of the

case when you get a subscribe with a tag in the To field that doesn't match

an existing subscription. That needs to be clarified in the events framework

spec. I'll send a note to Adam about it.




>

>Also, what happens if the watchers (previous to the migration) never

receive the NOTIFY to 

>update their 

>subscriptions to cause a refresh. Unless they do a fetch, the new PA

doesn't know that 

>they exist, so their 

>subscriptions will be effectively moot, but they won't be aware of this

fact. They won't 

>get any notifications, and 

>won't know that their subscriptions are being ignored. 




I think this is the same problem I discussed above. The question you need to

ask is why the watcher would not have gotten the NOTIFY. Assuming the

watcher application is running the whole time, the only reason this would

occur is a network failure of some sort, or a failure of the presence server

itself. Network failures that occur because the mobile has gone out of range

are generally detectable, and so the mobile can do something about it.

Network failures in the middle of the network which occur for long enough to

prevent a notification from being delivered (in excess of 16s) are hard to

deal with in any protocol. A "nice" presence agent could retain the

subscription state unless it gets a positive response to the NOTIFY, but

that can be used as a DoS attack. So, I don't know how solve this particular

failure case. There will be a gap in the delivery of notifications for the

duration of a refresh period. Given the scope of the failure that must occur

for that to happen, I think thats acceptable. 




Failures of the presence server itself can be handled using traditional

mechanisms, such as replication of subscription state to a hot standby.






>

>In section 8, there are mixed uses of the presence URL and SIP URL's. Is

this done 

>intentionally? 




No. My error. I've changed them all to sip URLs. Thanks.




>

>Finally, can someone point a link to the draft listed as [4] in the

bibliography? It 

>doesn't seem to be available 

>at the IETF webpage. 




It just recently expired. The impp chairs have been pinging the editor to

resubmit an update. 




Until then, you can get a copy from google's cached version of the draft:

http://www.google.com/search?q=cache:jdFIIPRBPY0:www.ietf.org/internet-draft

s/draft-ietf-impp-cpim-01.txt+draft-ietf-impp-cpim&hl=en




Thanks for your comments,

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_01C14114.9BC4C580--

From dean.willis@softarmor.com  Wed Sep 19 15:30:29 2001
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 PAA11849
	for ; Wed, 19 Sep 2001 15:30:27 -0400 (EDT)
Received: from flak (localhost.localdomain [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f8JJUqD32699;
	Wed, 19 Sep 2001 14:30:53 -0500
Message-ID: <00bc01c14141$6af86d30$3b2e713f@flak>
From: "Dean Willis" 
To: "Mark Watson" ,
        "simple" 
References: 
Subject: Re: [Simple] Implicit MESSAGE sessions revisited
Date: Wed, 19 Sep 2001 14:29:34 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00B9_01C14117.80F0C300"
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
Content-Length: 28620
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_00B9_01C14117.80F0C300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [Simple] Implicit MESSAGE sessions revisited
Assume page-mode messages have a "sessionID" in their payload.

Joe sends a message to Ann.
Ann forwards to Bob.
Bob replies to Joe. This reply carries the sessionID from Joe's original =
message.
Joe's app realizes his session is now with Bob and sends further =
messages in the session to Bob.
Joe and Bob exchange many messages in this session.
Ann has a life.

-_
Dean

  ----- Original Message -----=20
  From: Mark Watson=20
  To: 'Dean Willis' ; simple=20
  Sent: Tuesday, September 18, 2001 12:59 PM
  Subject: RE: [Simple] Implicit MESSAGE sessions revisited


  (1), it's not just a question of optimising the message routing, it's =
also that in routing the initial INVITE I may use up certain resources =
or require user intervention, and I don't want to repeat all that for =
every message in the 'chat session'.

  For example, Ann has all incoming sessions presented to their SIP =
client but can hit a key to forward them to her assistant Bob. If it's =
an IM chat session, and Bob gets into a long conversation, Ann does not =
want to see every message, and have to hit a key to forward it.

  Anns client could forward 'subsequent' messages automatically, but =
then Ann's client is implicitly taking on a notion of a 'session' and we =
are into the implicit session setup debate again - how does it detect =
when this session has ended and a new one started ? What happens if Ann =
turns her client off before Bob has finished chatting ? Ann could =
instruct her proxy to forwared SIP requests to Bob, but perhaps she =
doesn't want to. Perhaps she wants new calls to go to her mobile, but =
the rest of Bob's chat session to continue unaffected.

  So it's not just a message routing optimisation, there are other =
resources being optimised too (Ann's time).

  (2) SIP messages are not media, sure, but Instant Messages are. =
Instant Messages are not 'user to user signalling' either, because they =
are not signalling - they are a communication between the human =
end-users, not between the equipment facilitating that communication =
(which is how I would characterise 'signalling' here). So perhaps SIP =
messages should not be used to carry Instant Messages - but this is a =
different point entirely.

  ...Mark


    -----Original Message-----
    From: Dean Willis [mailto:dean.willis@softarmor.com]
    Sent: 18 September 2001 15:46
    To: simple
    Subject: Re: [Simple] Implicit MESSAGE sessions revisited



    I agree with #1,sortof. The best (only?) justfication for =
INVITE-bounded message sessions is the use of Record-Route to allow =
proxies that don't need to be in the route to opt out. This allows the =
SIP-network to be "self optimizing" for message routing. However, such =
SIP paths may be necessarily NOT end-to-end. For example, putting a SIP =
UA behind a firewall proxy will require that messages transit the =
firewall proxy. This is easily accomplished with record-route. Remember, =
all the "signaling privacy" requirements like  calling-party-ID and =
address-hiding apply to SIP messages. We already have mechanisms to meet =
those requirements for SIP traffic -- reusing them for messages is =
obviously functional.

    I disagree with requirement #2 -- SIP messages are inherently NOT =
media. They are, in effect "user to user signaling". This is consistent =
with my earlier position on the use of phone input (DTMF) as "user to =
system signaling", not media.

    --
    Dean
      ----- Original Message -----=20
      From: Mark Watson=20
      To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben =
Campbell'=20
      Cc: simple=20
      Sent: Monday, September 17, 2001 12:02 PM
      Subject: RE: [Simple] Implicit MESSAGE sessions revisited


      Dean,

      I agree that they're independent. On the first one, I had thought =
that the idea of IM 'sessions' fulfilled two key requirements:

      1) I want to find my desired called party, and then exchange =
multiple messages with this person

      Some of these things which can happen (in the network/UEs) as a =
SIP message finds the desired end-user may take time/cost money/require =
user interaction, and I don't want to repeat them once I have found the =
person I want to chat to. Also, there is no guarantee that repeating the =
process at a later time will get me to the same end-user. So, I want to =
be able to do a 'session setup' and then send messages directly to the =
person I've found.

      Of course, I could just treat the first message as an implicit =
session setup, but this seems to be out of fashion.

      2) I want IM to be just another media that I can negotiate, add & =
remove from a session etc.

      Again, I could do something clever with Call IDs to connect a =
MESSAGE message with a pre-existing session etc. etc., but why should I =
make an exception for this one kind of media. If I do that, then no =
capabilities that I have now or invent in the future which are supposed =
to be 'media type independent', will work for IM, and I will have to be =
hacking the IM system constantly to keep up.

      Did you disagree with these requirements, or just with the =
implementation ?

      Regards...Mark
        -----Original Message-----
        From: Dean Willis [mailto:dean.willis@softarmor.com]
        Sent: 17 September 2001 17:32
        To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj =
(NET/Dallas); 'ext Ben Campbell'
        Cc: simple
        Subject: Re: [Simple] Implicit MESSAGE sessions revisited


        Both, actually. I believe the issues are independent.

        --
        Dean

          ----- Original Message -----=20
          From: Mark Watson=20
          To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben =
Campbell'=20
          Cc: simple=20
          Sent: Monday, September 17, 2001 9:39 AM
          Subject: RE: [Simple] Implicit MESSAGE sessions revisited


          Dean,=20

          Do you mean that you don't see the advantage of using INVITE =
to set up an IM 'session' (indicating this in the SDP), or just that =
once such a session is set up, there is no need for the 'media' to use =
any different protocol than that used for 'paging' ?

          I think there are a lot of reasons why IM 'sessions' set up =
using INVITE just like any other SIP session, make sense. I don't care =
much yet what the transport protocol then is for the IMs in the session.

          Sorry if this is covering old ground.=20

          ...Mark=20





          > -----Original Message-----=20
          > From: Dean Willis [mailto:dean.willis@softarmor.com]=20
          > Sent: 15 September 2001 05:31=20
          > To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'=20
          > Cc: simple=20
          > Subject: Re: [Simple] Implicit MESSAGE sessions revisited=20
          >=20
          >=20
          >=20
          > Just as MESSAGE for sessions has all the wasted overhead of=20
          > headers and=20
          > routing mechanisms designed to find users and traverse=20
          > firewalls (assuming=20
          > you think this is a waste), so does BEEP.=20
          >=20
          > I personally have yet to see the need for message sessions =
as=20
          > a specialized=20
          > transport.=20
          >=20
          > I think "pager" messages carrying a session-ID and sequence =
number can=20
          > provide the same user experience.=20
          >=20
          > --=20
          > dean=20
          >=20
          >=20
          > ----- Original Message -----=20
          > From: "Patil Basavaraj (NET/Dallas)" =
=20
          > To: "'ext Ben Campbell'" =20
          > Cc: =20
          > Sent: Friday, September 14, 2001 1:07 PM=20
          > Subject: RE: [Simple] Implicit MESSAGE sessions revisited=20
          >=20
          >=20
          > >=20
          > > One of the protocols that has been suggested for use =
instead of=20
          > > MESSAGE is BEEP. Are there any serious concerns *at this =
time*=20
          > > why BEEP would not be good eniugh for IM Sessions?=20
          > >=20
          > > -Basavaraj=20
          > >=20
          > >=20
          > > _______________________________________________=20
          > > simple mailing list=20
          > > simple@mailman.dynamicsoft.com=20
          > > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
          > >=20
          > >=20
          >=20
          > _______________________________________________=20
          > simple mailing list=20
          > simple@mailman.dynamicsoft.com=20
          > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
          >=20


------=_NextPart_000_00B9_01C14117.80F0C300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


RE: [Simple] Implicit MESSAGE sessions =
revisited






 


Assume page-mode messages have a =
"sessionID" in=20
their payload.


 


Joe sends a message to =
Ann.


Ann forwards to Bob.


Bob replies to Joe. This reply carries =
the=20
sessionID from Joe's original message.


Joe's app realizes his session is now =
with Bob and=20
sends further messages in the session to Bob.


Joe and Bob exchange many messages in =
this=20
session.


Ann has a life.


 


-_
Dean


 



  
----- Original Message ----- 

  From:=20
  Mark Watson 
  
To: 'Dean Willis' ; simple 

  
Sent: Tuesday, September 18, =
2001 12:59=20
  PM

  
Subject: RE: [Simple] Implicit =
MESSAGE=20
  sessions revisited

  


  
(1),=20
  it's not just a question of optimising the message routing, it's also =
that in=20
  routing the initial INVITE I may use up certain resources or require =
user=20
  intervention, and I don't want to repeat all that for every message in =
the=20
  'chat session'.

  

For example, Ann has all incoming =
sessions=20
  presented to their SIP client but can hit a key to forward them to her =

  assistant Bob. If it's an IM chat session, and Bob gets into a long=20
  conversation, Ann does not want to see every message, and have to hit =
a key to=20
  forward it.

  
 

  
Anns=20
  client could forward 'subsequent' messages automatically, but then =
Ann's=20
  client is implicitly taking on a notion of a 'session' and we are into =
the=20
  implicit session setup debate again - how does it detect when this =
session has=20
  ended and a new one started ? What happens if Ann turns her client off =
before=20
  Bob has finished chatting ? Ann could instruct her proxy to forwared =
SIP=20
  requests to Bob, but perhaps she doesn't want to. Perhaps she wants =
new calls=20
  to go to her mobile, but the rest of Bob's chat session to continue=20
  unaffected.

  
 

  
So=20
  it's not just a message routing optimisation, there are other =
resources being=20
  optimised too (Ann's time).

  
 

  
(2)=20
  SIP messages are not media, sure, but Instant Messages are. Instant =
Messages=20
  are not 'user to user signalling' either, because they are not =
signalling -=20
  they are a communication between the human end-users, not between the=20
  equipment facilitating that communication (which is how I would =
characterise=20
  'signalling' here). So perhaps SIP messages should not be used to =
carry=20
  Instant Messages - but this is a different point =
entirely.

  
 

  
...Mark

  
 

  
 

  

    
-----Original Message-----
From: Dean Willis=20
    [mailto:dean.willis@softarmor.com]
Sent: 18 September 2001 =

    15:46
To: simple
Subject: Re: [Simple] Implicit =
MESSAGE=20
    sessions revisited


    
 

    
I agree with #1,sortof. The =
best (only?)=20
    justfication for INVITE-bounded message sessions is the use of =
Record-Route=20
    to allow proxies that don't need to be in the route to opt out. This =
allows=20
    the SIP-network to be "self optimizing" for message routing. =
However, such=20
    SIP paths may be necessarily NOT end-to-end. For example, putting a =
SIP UA=20
    behind a firewall proxy will require that messages transit the =
firewall=20
    proxy. This is easily accomplished with record-route. Remember, all =
the=20
    "signaling privacy" requirements like  calling-party-ID and=20
    address-hiding apply to SIP messages. We already have mechanisms to =
meet=20
    those requirements for SIP traffic -- reusing them for messages is =
obviously=20
    functional.

    
 

    
I disagree with requirement #2 -- =
SIP messages=20
    are inherently NOT media. They are, in effect "user to user =
signaling". This=20
    is consistent with my earlier position on the use of phone input =
(DTMF) as=20
    "user to system signaling", not media.

    
 

    
--
Dean

    

      
----- Original Message ----- =


      From:=20
      Mark Watson 
      
To: 'Dean Willis' ; Patil Basavaraj =
(NET/Dallas) ;=20
      'ext Ben Campbell' =


      
Cc: simple 

      
Sent: Monday, September 17, =
2001=20
      12:02 PM

      
Subject: RE: [Simple] =
Implicit=20
      MESSAGE sessions revisited

      


      
Dean,

      
 

      
I agree that they're independent. On =
the first=20
      one, I had thought that the idea of IM 'sessions' fulfilled =
two key=20
      requirements:

      
 

      
1) I want to find my desired called =
party, and=20
      then exchange multiple messages with this =
person

      
 

      
Some of these things which can happen =
(in the=20
      network/UEs) as a SIP message finds the desired end-user may take=20
      time/cost money/require user interaction, and I don't want to =
repeat them=20
      once I have found the person I want to chat to. Also, there is no=20
      guarantee that repeating the process at a later time will get me =
to the=20
      same end-user. So, I want to be able to do a 'session setup' and =
then send=20
      messages directly to the person I've found.

      
 

      
Of course, I could just treat the first =
message=20
      as an implicit session setup, but this seems to be out of=20
      fashion.

      
 

      
2) I want IM to be just another media =
that I can=20
      negotiate, add & remove from a session =
etc.

      
 

      
Again, I could do something clever with =
Call IDs=20
      to connect a MESSAGE message with a pre-existing session etc. =
etc., but=20
      why should I make an exception for this one kind of media. If I do =
that,=20
      then no capabilities that I have now or invent in the future which =
are=20
      supposed to be 'media type independent', will work for IM, and I =
will have=20
      to be hacking the IM system constantly to keep =
up.

      
 

      
Did you disagree with these =
requirements, or just=20
      with the implementation ?

      
 

      
Regards...Mark

      

        
-----Original Message-----
From: Dean Willis=20
        [mailto:dean.willis@softarmor.com]
Sent: 17 September =
2001=20
        17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil =
Basavaraj=20
        (NET/Dallas); 'ext Ben Campbell'
Cc: =
simple
Subject:=20
        Re: [Simple] Implicit MESSAGE sessions =
revisited


        
Both, actually. I believe the =
issues are=20
        independent.

        
 

        
--
Dean

        
 

        

          
----- Original Message ----- =


          From:=20
          Mark Watson =

          
To: 'Dean Willis' ; =
Patil Basavaraj=20
          (NET/Dallas) ; 'ext Ben =
Campbell' 

          
Cc: simple =


          
Sent: Monday, September =
17, 2001=20
          9:39 AM

          
Subject: RE: [Simple] =
Implicit=20
          MESSAGE sessions revisited

          


          
Dean, 

          
Do you mean that you don't see the advantage =
of using=20
          INVITE to set up an IM 'session' (indicating this in the SDP), =
or just=20
          that once such a session is set up, there is no need for the =
'media'=20
          to use any different protocol than that used for 'paging' =
?

          
I think there are a lot of reasons why IM =
'sessions'=20
          set up using INVITE just like any other SIP session, make =
sense. I=20
          don't care much yet what the transport protocol then is for =
the IMs in=20
          the session.

          
Sorry if this is covering old ground. =


          
...Mark 




          
> -----Original Message----- =

> From: Dean Willis [mailto:dean.willis@softarmor.co=
m]=20
          
> Sent: 15 September 2001 05:31 =

> To: Patil Basavaraj (NET/Dallas); 'ext Ben=20
          Campbell' 
> Cc: simple =

> Subject: Re: [Simple] Implicit MESSAGE sessions=20
          revisited 
> 
>=20
          
> 
> =
Just as=20
          MESSAGE for sessions has all the wasted overhead of =

> headers and 
> =
routing=20
          mechanisms designed to find users and traverse =

> firewalls (assuming 
> you think=20
          this is a waste), so does BEEP. 
> =

          
> I personally have yet to see =
the need for=20
          message sessions as 
> a =
specialized=20
          
> transport. 
>=20
          
> I think "pager" messages =
carrying a=20
          session-ID and sequence number can 
>=20
          provide the same user experience. 
>=20
          
> -- 
>=20
          dean 
> 
>=20
          
> ----- Original Message =
-----=20
          
> From: "Patil Basavaraj (NET/Dallas)"=20
          <Basavaraj.Patil@nokia.com> 
> To:=20
          "'ext Ben Campbell'" <bcampbell@dynamicsoft.com>=20
          
> Cc:=20
          <simple@mailman.dynamicsoft.com> 
>=20
          Sent: Friday, September 14, 2001 1:07 PM 
>=20
          Subject: RE: [Simple] Implicit MESSAGE sessions =
revisited=20
          
> 
> =

> > 
> > One of =
the=20
          protocols that has been suggested for use instead of =

> > MESSAGE is BEEP. Are there any serious =
concerns *at=20
          this time* 
> > why BEEP would =
not be=20
          good eniugh for IM Sessions? 
> =
>=20
          
> > -Basavaraj 
>=20
          > 
> > 
>=20
          > _______________________________________________ =

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

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



------=_NextPart_000_00B9_01C14117.80F0C300--


From pkyzivat@cisco.com  Wed Sep 19 18:09:14 2001
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 SAA12382
	for ; Wed, 19 Sep 2001 18:09:13 -0400 (EDT)
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 f8JM8Vs19206
	for ; Wed, 19 Sep 2001 18:08:34 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAA86807 (AUTH pkyzivat);
	Wed, 19 Sep 2001 18:10:07 -0400 (EDT)
Message-ID: <3BA9173D.D6C1E73A@cisco.com>
Date: Wed, 19 Sep 2001 18:07:58 -0400
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: simple 
Subject: [Fwd: Re: [Simple] Implicit MESSAGE sessions revisited]
Content-Type: multipart/alternative;
 boundary="------------148DB4EC12016C6F297EA897"
Content-Length: 33611
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: 

--------------148DB4EC12016C6F297EA897
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dean,

> Joe sends a message to Ann.> Ann forwards to Bob.> Bob replies to Joe.
This reply carries the sessionID from Joe's original message.> Joe's app
realizes his session is now with Bob and sends further messages in the
session to Bob.> Joe and Bob exchange many messages in this session.>
Ann has a life.

Bunch of problems with this scenario:

1) how does Bob reply to Joe? Does Bob's IM client offer a reply
function that extracts Joe's address? Or does Bob manually initiate a
new IM session with Bob?

If the former, then clearly the IM protocol must have a more or less
complete call control mechanism of its own, duplicating what is in SIP.

If the latter, then how does the sessionID get into the reply?
Presumably Bob would have to type it in. Not likely in the real world.

2) How is this case distinguished from one where Ann wants to conference
Bob in? Ann may be acting as a local mixer, passing Joe's messages on to
Bob after reading them. In your scenario, this would look exactly the
same to Bob, but the action he should take is different - he should
reply to Ann, so that she can see the reply and relay it back to Joe.

Your proposed solution can't deal with the multiple possibilities. There
are many useful topologies that can be established using SIP. Do you
propose to have SIMPLE reinvent all of them independently?

    Paul

-------- Original Message --------
   Subject: Re: [Simple] Implicit MESSAGE sessions revisited
      Date: Wed, 19 Sep 2001 14:29:34 -0500
      From: "Dean Willis" 
        To: "Mark Watson" ,"simple"
            
References: 

 Assume page-mode messages have a "sessionID" in their payload. Joe
sends a message to Ann.Ann forwards to Bob.Bob replies to Joe. This
reply carries the sessionID from Joe's original message.Joe's app
realizes his session is now with Bob and sends further messages in the
session to Bob.Joe and Bob exchange many messages in this session.Ann
has a life. -_
Dean

     ----- Original Message -----
     From: Mark Watson
     To: 'Dean Willis' ; simple
     Sent: Tuesday, September 18, 2001 12:59 PM
     Subject: RE: [Simple] Implicit MESSAGE sessions revisited
      (1), it's not just a question of optimising the message
     routing, it's also that in routing the initial INVITE I may
     use up certain resources or require user intervention, and I
     don't want to repeat all that for every message in the 'chat
     session'.
     For example, Ann has all incoming sessions presented to their
     SIP client but can hit a key to forward them to her assistant
     Bob. If it's an IM chat session, and Bob gets into a long
     conversation, Ann does not want to see every message, and have
     to hit a key to forward it.Anns client could forward
     'subsequent' messages automatically, but then Ann's client is
     implicitly taking on a notion of a 'session' and we are into
     the implicit session setup debate again - how does it detect
     when this session has ended and a new one started ? What
     happens if Ann turns her client off before Bob has finished
     chatting ? Ann could instruct her proxy to forwared SIP
     requests to Bob, but perhaps she doesn't want to. Perhaps she
     wants new calls to go to her mobile, but the rest of Bob's
     chat session to continue unaffected.So it's not just a message
     routing optimisation, there are other resources being
     optimised too (Ann's time).(2) SIP messages are not media,
     sure, but Instant Messages are. Instant Messages are not 'user
     to user signalling' either, because they are not signalling -
     they are a communication between the human end-users, not
     between the equipment facilitating that communication (which
     is how I would characterise 'signalling' here). So perhaps SIP
     messages should not be used to carry Instant Messages - but
     this is a different point entirely....Mark

          -----Original Message-----
          From: Dean Willis [mailto:dean.willis@softarmor.com]

          Sent: 18 September 2001 15:46
          To: simple
          Subject: Re: [Simple] Implicit MESSAGE sessions
          revisited

           I agree with #1,sortof. The best (only?)
          justfication for INVITE-bounded message sessions is
          the use of Record-Route to allow proxies that don't
          need to be in the route to opt out. This allows the
          SIP-network to be "self optimizing" for message
          routing. However, such SIP paths may be necessarily
          NOT end-to-end. For example, putting a SIP UA behind
          a firewall proxy will require that messages transit
          the firewall proxy. This is easily accomplished with
          record-route. Remember, all the "signaling privacy"
          requirements like  calling-party-ID and
          address-hiding apply to SIP messages. We already
          have mechanisms to meet those requirements for SIP
          traffic -- reusing them for messages is obviously
          functional. I disagree with requirement #2 -- SIP
          messages are inherently NOT media. They are, in
          effect "user to user signaling". This is consistent
          with my earlier position on the use of phone input
          (DTMF) as "user to system signaling", not media. --
          Dean

               ----- Original Message -----
               From: Mark Watson
               To: 'Dean Willis' ; Patil Basavaraj
               (NET/Dallas) ; 'ext Ben Campbell'
               Cc: simple
               Sent: Monday, September 17, 2001 12:02 PM
               Subject: RE: [Simple] Implicit MESSAGE
               sessions revisited
                Dean,I agree that they're independent. On
               the first one, I had thought that the idea
               of IM 'sessions' fulfilled two key
               requirements:1) I want to find my desired
               called party, and then exchange multiple
               messages with this personSome of these
               things which can happen (in the
               network/UEs) as a SIP message finds the
               desired end-user may take time/cost
               money/require user interaction, and I
               don't want to repeat them once I have
               found the person I want to chat to. Also,
               there is no guarantee that repeating the
               process at a later time will get me to the
               same end-user. So, I want to be able to do
               a 'session setup' and then send messages
               directly to the person I've found.Of
               course, I could just treat the first
               message as an implicit session setup, but
               this seems to be out of fashion.2) I want
               IM to be just another media that I can
               negotiate, add & remove from a session
               etc.Again, I could do something clever
               with Call IDs to connect a MESSAGE message
               with a pre-existing session etc. etc., but
               why should I make an exception for this
               one kind of media. If I do that, then no
               capabilities that I have now or invent in
               the future which are supposed to be 'media
               type independent', will work for IM, and I
               will have to be hacking the IM system
               constantly to keep up.Did you disagree
               with these requirements, or just with the
               implementation ?Regards...Mark

                    -----Original Message-----
                    From: Dean Willis
                    [mailto:dean.willis@softarmor.com]

                    Sent: 17 September 2001 17:32
                    To: Watson, Mark
                    [MAIFP:EP11:EXCH]; Patil
                    Basavaraj (NET/Dallas); 'ext Ben
                    Campbell'
                    Cc: simple
                    Subject: Re: [Simple] Implicit
                    MESSAGE sessions revisited

                    Both, actually. I believe the
                    issues are independent. --
                    Dean

                         ----- Original Message
                         -----
                         From: Mark Watson
                         To: 'Dean Willis' ;
                         Patil Basavaraj
                         (NET/Dallas) ; 'ext
                         Ben Campbell'
                         Cc: simple
                         Sent: Monday,
                         September 17, 2001
                         9:39 AM
                         Subject: RE: [Simple]
                         Implicit MESSAGE
                         sessions revisited
                          Dean,

                         Do you mean that you
                         don't see the
                         advantage of using
                         INVITE to set up an IM
                         'session' (indicating
                         this in the SDP), or
                         just that once such a
                         session is set up,
                         there is no need for
                         the 'media' to use any
                         different protocol
                         than that used for
                         'paging' ?

                         I think there are a
                         lot of reasons why IM
                         'sessions' set up
                         using INVITE just like
                         any other SIP session,
                         make sense. I don't
                         care much yet what the
                         transport protocol
                         then is for the IMs in
                         the session.

                         Sorry if this is
                         covering old ground.

                         ...Mark



                         > -----Original
                         Message-----
                         > From: Dean Willis
                         [mailto:dean.willis@softarmor.com]

                         > Sent: 15 September
                         2001 05:31
                         > To: Patil Basavaraj
                         (NET/Dallas); 'ext Ben
                         Campbell'
                         > Cc: simple
                         > Subject: Re:
                         [Simple] Implicit
                         MESSAGE sessions
                         revisited
                         >
                         >
                         >
                         > Just as MESSAGE for
                         sessions has all the
                         wasted overhead of
                         > headers and
                         > routing mechanisms
                         designed to find users
                         and traverse
                         > firewalls (assuming
                         > you think this is a
                         waste), so does BEEP.
                         >
                         > I personally have
                         yet to see the need
                         for message sessions
                         as
                         > a specialized
                         > transport.
                         >
                         > I think "pager"
                         messages carrying a
                         session-ID and
                         sequence number can
                         > provide the same
                         user experience.
                         >
                         > --
                         > dean
                         >
                         >
                         > ----- Original
                         Message -----
                         > From: "Patil
                         Basavaraj
                         (NET/Dallas)"
                         

                         > To: "'ext Ben
                         Campbell'"
                         

                         > Cc:
                         

                         > Sent: Friday,
                         September 14, 2001
                         1:07 PM
                         > Subject: RE:
                         [Simple] Implicit
                         MESSAGE sessions
                         revisited
                         >
                         >
                         > >
                         > > One of the
                         protocols that has
                         been suggested for use
                         instead of
                         > > MESSAGE is BEEP.
                         Are there any serious
                         concerns *at this
                         time*
                         > > why BEEP would not
                         be good eniugh for IM
                         Sessions?
                         > >
                         > > -Basavaraj
                         > >
                         > >
                         > >
                         _______________________________________________

                         > > 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

                         >

--------------148DB4EC12016C6F297EA897
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




Dean,

> Joe sends a message to Ann.>
Ann forwards to Bob.> Bob
replies to Joe. This reply carries the sessionID from Joe's original message.>
Joe's app realizes his session is now with Bob and sends further messages
in the session to Bob.>
Joe and Bob exchange many messages in this session.>
Ann has a life.

Bunch of problems with this scenario:

1) how does Bob reply to Joe? Does
Bob's IM client offer a reply function that extracts Joe's address? Or
does Bob manually initiate a new IM session with Bob?

If the former, then clearly the IM
protocol must have a more or less complete call control mechanism of its
own, duplicating what is in SIP.

If the latter, then how does the sessionID
get into the reply? Presumably Bob would have to type it in. Not likely
in the real world.

2) How is this case distinguished from
one where Ann wants to conference Bob in? Ann may be acting as a local
mixer, passing Joe's messages on to Bob after reading them. In your scenario,
this would look exactly the same to Bob, but the action he should take
is different - he should reply to Ann, so that she can see the reply and
relay it back to Joe.

Your proposed solution can't deal with
the multiple possibilities. There are many useful topologies that can be
established using SIP. Do you propose to have SIMPLE reinvent all of them
independently?

    Paul

-------- Original Message --------




Subject: 

Re: [Simple] Implicit MESSAGE sessions revisited





Date: 

Wed, 19 Sep 2001 14:29:34 -0500





From: 

"Dean Willis" <dean.willis@softarmor.com>





To: 

"Mark Watson" <mwatson@nortelnetworks.com>,"simple" <simple@mailman.dynamicsoft.com>





References: 

<A3C2399B2FACD411A54200508BE39C7402E845BB@zwcwd00r.europe.nortel.com>







 Assume page-mode
messages have a "sessionID" in their payload. Joe
sends a message to Ann.Ann
forwards to Bob.Bob replies
to Joe. This reply carries the sessionID from Joe's original message.Joe's
app realizes his session is now with Bob and sends further messages in
the session to Bob.Joe and
Bob exchange many messages in this session.Ann
has a life. -_

Dean 



----- Original Message -----







Sent: Tuesday, September 18, 2001
12:59 PM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

 (1),
it's not just a question of optimising the message routing, it's also that
in routing the initial INVITE I may use up certain resources or require
user intervention, and I don't want to repeat all that for every message
in the 'chat session'.

For example,
Ann has all incoming sessions presented to their SIP client but can hit
a key to forward them to her assistant Bob. If it's an IM chat session,
and Bob gets into a long conversation, Ann does not want to see every message,
and have to hit a key to forward it.Anns
client could forward 'subsequent' messages automatically, but then Ann's
client is implicitly taking on a notion of a 'session' and we are into
the implicit session setup debate again - how does it detect when this
session has ended and a new one started ? What happens if Ann turns her
client off before Bob has finished chatting ? Ann could instruct her proxy
to forwared SIP requests to Bob, but perhaps she doesn't want to. Perhaps
she wants new calls to go to her mobile, but the rest of Bob's chat session
to continue unaffected.So
it's not just a message routing optimisation, there are other resources
being optimised too (Ann's time).(2)
SIP messages are not media, sure, but Instant Messages are. Instant Messages
are not 'user to user signalling' either, because they are not signalling
- they are a communication between the human end-users, not between the
equipment facilitating that communication (which is how I would characterise
'signalling' here). So perhaps SIP messages should not be used to carry
Instant Messages - but this is a different point entirely....Mark



-----Original
Message-----

From: Dean Willis [mailto:dean.willis@softarmor.com]

Sent: 18 September 2001 15:46

To: simple

Subject: Re: [Simple] Implicit
MESSAGE sessions revisited

 

 I agree with #1,sortof. The best
(only?) justfication for INVITE-bounded message sessions is the use of
Record-Route to allow proxies that don't need to be in the route to opt
out. This allows the SIP-network to be "self optimizing" for message routing.
However, such SIP paths may be necessarily NOT end-to-end. For example,
putting a SIP UA behind a firewall proxy will require that messages transit
the firewall proxy. This is easily accomplished with record-route. Remember,
all the "signaling privacy" requirements like  calling-party-ID and
address-hiding apply to SIP messages. We already have mechanisms to meet
those requirements for SIP traffic -- reusing them for messages is obviously
functional. I disagree
with requirement #2 -- SIP messages are inherently NOT media. They are,
in effect "user to user signaling". This is consistent with my earlier
position on the use of phone input (DTMF) as "user to system signaling",
not media. --

Dean



----- Original Message -----







Cc: simple



Sent: Monday, September 17, 2001 12:02
PM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

 Dean,I
agree that they're independent. On the first one, I had thought that the
idea of IM 'sessions' fulfilled two key requirements:1)
I want to find my desired called party, and then exchange multiple messages
with this personSome
of these things which can happen (in the network/UEs) as a SIP message
finds the desired end-user may take time/cost money/require user interaction,
and I don't want to repeat them once I have found the person I want to
chat to. Also, there is no guarantee that repeating the process at a later
time will get me to the same end-user. So, I want to be able to do a 'session
setup' and then send messages directly to the person I've found.Of
course, I could just treat the first message as an implicit session setup,
but this seems to be out of fashion.2)
I want IM to be just another media that I can negotiate, add & remove
from a session etc.Again,
I could do something clever with Call IDs to connect a MESSAGE message
with a pre-existing session etc. etc., but why should I make an exception
for this one kind of media. If I do that, then no capabilities that I have
now or invent in the future which are supposed to be 'media type independent',
will work for IM, and I will have to be hacking the IM system constantly
to keep up.Did
you disagree with these requirements, or just with the implementation ?Regards...Mark



-----Original
Message-----

From: Dean Willis [mailto:dean.willis@softarmor.com]

Sent: 17 September 2001 17:32

To: Watson, Mark [MAIFP:EP11:EXCH];
Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'

Cc: simple

Subject: Re: [Simple] Implicit
MESSAGE sessions revisited

 

Both, actually. I believe the issues are
independent. --

Dean 



----- Original Message -----







Cc: simple



Sent: Monday, September 17, 2001 9:39
AM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

 Dean,

Do you mean that you don't see the advantage of using
INVITE to set up an IM 'session' (indicating this in the SDP), or just
that once such a session is set up, there is no need for the 'media' to
use any different protocol than that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set
up using INVITE just like any other SIP session, make sense. I don't care
much yet what the transport protocol then is for the IMs in the session.

Sorry if this is covering old ground.

...Mark

 

 

> -----Original Message-----

> From: Dean Willis [mailto:dean.willis@softarmor.com]

> Sent: 15 September 2001 05:31

> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'

> Cc: simple

> Subject: Re: [Simple] Implicit MESSAGE sessions revisited

>

>

>

> Just as MESSAGE for sessions has all the wasted overhead
of

> headers and

> routing mechanisms designed to find users and traverse

> firewalls (assuming

> you think this is a waste), so does BEEP.

>

> I personally have yet to see the need for message sessions
as

> a specialized

> transport.

>

> I think "pager" messages carrying a session-ID and
sequence number can

> provide the same user experience.

>

> --

> dean

>

>

> ----- Original Message -----

> From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>

> To: "'ext Ben Campbell'" <bcampbell@dynamicsoft.com>

> Cc: <simple@mailman.dynamicsoft.com>

> Sent: Friday, September 14, 2001 1:07 PM

> Subject: RE: [Simple] Implicit MESSAGE sessions revisited

>

>

> >

> > One of the protocols that has been suggested for
use instead of

> > MESSAGE is BEEP. Are there any serious concerns *at
this time*

> > why BEEP would not be good eniugh for IM Sessions?

> >

> > -Basavaraj

> >

> >

> > _______________________________________________

> > 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

>













--------------148DB4EC12016C6F297EA897--


From jdrosen@dynamicsoft.com  Wed Sep 19 18:14:20 2001
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 SAA12448
	for ; Wed, 19 Sep 2001 18:14:20 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8JMD88P010736;
	Wed, 19 Sep 2001 18:13:08 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 19 Sep 2001 18:14:08 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Dean Willis'" ,
        Mark Watson
	 ,
        simple 
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Wed, 19 Sep 2001 18:14:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4131
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: 

Sorry for my prolonged absence on this list... I was on vacation and am just
now getting back to list mails.

  
-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Wednesday, September 19, 2001 3:30 PM
To: Mark Watson; simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited

>
>
>Assume page-mode messages have a "sessionID" in their payload.
>
>Joe sends a message to Ann.
>Ann forwards to Bob.
>Bob replies to Joe. This reply carries the sessionID from Joe's original
message.
>Joe's app realizes his session is now with Bob and sends further messages
in the session 
>to Bob.
>Joe and Bob exchange many messages in this session.
>Ann has a life.

Sounds like you have assigned some additional semantics to messages with
different sources (i.e., ann vs. bob), but the same session id. In fact, it
sounds like you have just re-invented the old "replaces" approach that we
had, way back before we realized that implicit semantics like this get you
into trouble. How would conferencing work, then? Same session ID also? How
would Joe know whether Bob means to join the conference, or replace the
conversation with Ann? You'll need to define a special IM replaces
mechanism. Specifically, a header that says "hey, this session id replaces
that other one". You've just completely redone the replaces header.

THe one thing I feel REALLY strongly about here, is that if we want a notion
of a prolonged session of messages between endpoints, we use an INVITE/BYE
wrapper. The kind of little hacks that Dean has proposed above will all
eventually break and result in the need to reinvent all that we have done
for SIP today, but now, for IM. Please let us not do that. All of the
existing work - conferencing, remote party id, even manyfolks, can be made
to be useful for IM without any additional work with the INVITE/BYE session
wrapper. 

I do NOT want to invent a new mechanism for this using MESSAGE and implicit
sessions.

-Jonathan R.

----- Original Message ----- 
From: Mark Watson 
To: 'Dean Willis' ; simple 
Sent: Tuesday, September 18, 2001 12:59 PM
Subject: RE: [Simple] Implicit MESSAGE sessions revisited


(1), it's not just a question of optimising the message routing, it's also
that in routing the initial INVITE I may use up certain resources or require
user intervention, and I don't want to repeat all that for every message in
the 'chat session'.

For example, Ann has all incoming sessions presented to their SIP client but
can hit a key to forward them to her assistant Bob. If it's an IM chat
session, and Bob gets into a long conversation, Ann does not want to see
every message, and have to hit a key to forward it.

Anns client could forward 'subsequent' messages automatically, but then
Ann's client is implicitly taking on a notion of a 'session' and we are into
the implicit session setup debate again - how does it detect when this
session has ended and a new one started ? What happens if Ann turns her
client off before Bob has finished chatting ? Ann could instruct her proxy
to forwared SIP requests to Bob, but perhaps she doesn't want to. Perhaps
she wants new calls to go to her mobile, but the rest of Bob's chat session
to continue unaffected.

So it's not just a message routing optimisation, there are other resources
being optimised too (Ann's time).

(2) SIP messages are not media, sure, but Instant Messages are. Instant
Messages are not 'user to user signalling' either, because they are not
signalling - they are a communication between the human end-users, not
between the equipment facilitating that communication (which is how I would
characterise 'signalling' here). So perhaps SIP messages should not be used
to carry Instant Messages - but this is a different point entirely.

...Mark

---
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

From jdrosen@dynamicsoft.com  Thu Sep 20 02:05:01 2001
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 CAA13874
	for ; Thu, 20 Sep 2001 02:05:01 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8K63k8P012052;
	Thu, 20 Sep 2001 02:03:49 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 20 Sep 2001 02:04:44 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Robert Brown'" ,
        Jonathan Rosenberg
	 ,
        "'David R. Oran'" ,
        "'Patil Basavaraj (NET/Dallas)'" ,
        Avshalom@ubique.com, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Sessions of MESSAGEs
Date: Thu, 20 Sep 2001 02:04:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 6916
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: 

Comments inline.
 

> -----Original Message-----
> From: Robert Brown [mailto:roberbr@microsoft.com]
> Sent: Tuesday, September 04, 2001 9:52 PM
> To: Jonathan Rosenberg; 'David R. Oran'; 'Patil Basavaraj 
> (NET/Dallas)';
> Avshalom@ubique.com; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Sessions of MESSAGEs
> 
> 
> Thanks for this detailed description.  You're going to hate 
> me, I'm sure
> :-), but I still think this is the wrong solution for IM.
> 
> You're assuming "one/both or neither of the enterprises has 
> deployed a nat
> and/or firewall, but is willing to affect static 
> configuration changes to
> that firewall/nat to enable real time communications" and "it 
> is feasible
> and acceptable to deploy elements within the enterprise that 
> are application
> specific, to facilitate this application".  But I don't think 
> these are
> completely valid assumptions.
> 
> I think it is flawed to assume all "real time communication" modes are
> equally complicated and should be solved in the same way.  It 
> is far easier
> to get cross-firewall IM (there are already many existing widespread
> implementations of this) than it is to get cross-firewall audio/video
> streams.  IM is not "real time" in the same sense as audio 
> and video:  it
> tolerates considerable delays; it does not tolerate loss of 
> information; it
> has extremely low bandwidth requirements.  I just don't see 
> the evidence
> that IM has much in common with RTP, and hence that an RTP solution is
> automatically the best solution for IM.

No one is saying RTP is the right solution for IM. I think we had consensus
that it wasn't.  I also agree that IM is different in many ways from audio
and video, primarily in the latency requirements. I will note, however, that
that doesn't mean its not a "media stream" in the same sense that audio and
video are. The definition of a stream is that its a mode of communications
that exists between one or more participants. Even games are considered
"media streams" in the SIP model, and these have different characteristics
from audio and video as well.

I certainly understand the argument that using SIP MESSAGE along the
signaling path will make nat and firewall traversal easier. Recall that I
did propose this initially, in fact, primarily for that reason. I spend a
lot of my time worrying about nats and firewalls, I can assure you.

The solution I proposed, of what is effectively a "b2bua for messages" has
much the same characteristics of sending the IM over a proxy, especially
once support for multiplexed connections between elements is added. The
similarities are the ability to run on a single port for incoming
connections, the ability for a single server to play the role of entry/exit
from the network, and the ability to hide the addresses of the sender. The
difference lies in the layer at which this forwarding is done. The cost of
processing a SIP message in a proxy is much higher than something that
merely relays bytes between connections based on some identifier. I can
therefore deploy these things as separate boxes even, allowing the proxy
scaling to be decoupled from the scaling needed for message forwarding.

The usage of SIP proxies for message forwarding also has an implication for
traditional voip calls. Large messages will increase overall latencies
through proxies, causing potentially drastic increases in call setup times.
That kind of interaction is something you don't need to worry about in a
pure IM system, but is an issue in a system supporting IM, voice, video, and
so on.

> 
> The second flaw is to assume that IT departments will be 
> willing to open
> port ranges.  At most, an IT department will open a 
> well-defined port for a
> specific purpose.  E.g. 443 for HTTPS, 5061 for SIP/TLS.  
> Hence mapping
> sessions to ports will not be deployable.  You will need to 
> map sessions to
> sockets.  As you point out below, this is more difficult 
> because it requires
> encoding at a higher layer.

Agreed that they would only open a single port.

> 
> Thirdly, I don't think we should base something as 
> fundamental as instant
> messaging on assumptions about what an acceptable generalized firewall
> traversal architecture may be.  I don't want SIMPLE to make a 
> design call
> based on whether something like your entfw-02 draft, or a 
> MEGACO draft, or
> whatever, will be the firewall traversal solution.

My proposal makes no such dependency. For the inter-enterprise case, it can
be done with this b2bua thing that doesn't require any additional elements.
Its only when you split the message forwarding component off that you need
some kind of interface between the proxy and the message forwarding box.

> 
> Fourthly, multiplexing multiple conversations on a single TCP 
> session is a
> very valid requirement.  Imagine you're a large IM service 
> provider (such as
> MSN, AOL, Yahoo, and the various larger ISPs).  You can 
> expect quite a mesh
> between users of these services (assuming they want to open 
> themselves to
> interop via SIMPLE).  Hence probably millions of parallel TCP 
> connections
> between a few data centers.  I doubt that anybody who runs a 
> data center
> wants to take this hit.  And forget about making the TCP 
> connections using
> TLS - how many cycles do you want to burn on session establishment?

Agreed.

> 
> I can send a SIP MESSAGE request pretty easily.  I've read 
> nothing in any of
> these threads that convinces me that extending this innate 
> SIP capability is
> a bad idea.  If people are worried about swamping their 
> proxies with IM,
> it's too late - you'll find SIP proxies will be far busier 
> with SUBSCRIBE
> and NOTIFY than they ever will be with MESSAGE. 

The frequency of these is definitely greater, yes. However, proxies are less
likely to record-route on a subscribe than they are on an invite, so I
assume fewer proxies would be seeing the subscribe. Its also the size of the
IM that concerns me. I suspect subscribe and notify messages to almost
always be small, whereas an IM could conceivably contain a huge attachment. 

> Why not 
> INVITE my buddies
> to a presence session, and define a separate protocol for 
> transferring this
> presence information?

INVITE is more than just establishing an association between two points, its
about initiating a communications session. There are real differences
between the two, IMHO. Things like conferencing and transfer make sense for
any type of communications session, but have no meaning for 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

From mwatson@nortelnetworks.com  Thu Sep 20 05:35:10 2001
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14577
	for ; Thu, 20 Sep 2001 05:35:10 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f8K9Yng10306
	for ; Thu, 20 Sep 2001 10:34:53 +0100 (BST)
Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com;
          Thu, 20 Sep 2001 10:34:20 +0100
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 20 Sep 2001 10:34:04 +0100
Message-ID: 
From: "Mark Watson" 
To: "'Dean Willis'" ,
        simple 
Subject: RE: [Simple] Implicit MESSAGE sessions revisited
Date: Thu, 20 Sep 2001 09:54:28 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C141B1.DB37F960"
Content-Length: 29232
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: 

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_01C141B1.DB37F960
Content-Type: text/plain;
	charset="iso-8859-1"

But this is just using a page-mode message to set up an implicit session.
That's fine by me for requirement (1) - all I wanted was the 'session'
concept. But the 'implicit' session set up seems to have been rejected in
previous discussions (unless I've misunderstood).
 
It doesn't solve requirement (2) anyway.
 
...Mark

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 19 September 2001 20:30
To: Watson, Mark [MAIFP:EP11:EXCH]; simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited


 
Assume page-mode messages have a "sessionID" in their payload.
 
Joe sends a message to Ann.
Ann forwards to Bob.
Bob replies to Joe. This reply carries the sessionID from Joe's original
message.
Joe's app realizes his session is now with Bob and sends further messages in
the session to Bob.
Joe and Bob exchange many messages in this session.
Ann has a life.
 
-_
Dean
 

----- Original Message ----- 
From: Mark Watson   
To: 'Dean Willis'   ; simple
  
Sent: Tuesday, September 18, 2001 12:59 PM
Subject: RE: [Simple] Implicit MESSAGE sessions revisited


(1), it's not just a question of optimising the message routing, it's also
that in routing the initial INVITE I may use up certain resources or require
user intervention, and I don't want to repeat all that for every message in
the 'chat session'.

For example, Ann has all incoming sessions presented to their SIP client but
can hit a key to forward them to her assistant Bob. If it's an IM chat
session, and Bob gets into a long conversation, Ann does not want to see
every message, and have to hit a key to forward it.
 
Anns client could forward 'subsequent' messages automatically, but then
Ann's client is implicitly taking on a notion of a 'session' and we are into
the implicit session setup debate again - how does it detect when this
session has ended and a new one started ? What happens if Ann turns her
client off before Bob has finished chatting ? Ann could instruct her proxy
to forwared SIP requests to Bob, but perhaps she doesn't want to. Perhaps
she wants new calls to go to her mobile, but the rest of Bob's chat session
to continue unaffected.
 
So it's not just a message routing optimisation, there are other resources
being optimised too (Ann's time).
 
(2) SIP messages are not media, sure, but Instant Messages are. Instant
Messages are not 'user to user signalling' either, because they are not
signalling - they are a communication between the human end-users, not
between the equipment facilitating that communication (which is how I would
characterise 'signalling' here). So perhaps SIP messages should not be used
to carry Instant Messages - but this is a different point entirely.
 
...Mark
 
 

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 18 September 2001 15:46
To: simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited


 
I agree with #1,sortof. The best (only?) justfication for INVITE-bounded
message sessions is the use of Record-Route to allow proxies that don't need
to be in the route to opt out. This allows the SIP-network to be "self
optimizing" for message routing. However, such SIP paths may be necessarily
NOT end-to-end. For example, putting a SIP UA behind a firewall proxy will
require that messages transit the firewall proxy. This is easily
accomplished with record-route. Remember, all the "signaling privacy"
requirements like  calling-party-ID and address-hiding apply to SIP
messages. We already have mechanisms to meet those requirements for SIP
traffic -- reusing them for messages is obviously functional.
 
I disagree with requirement #2 -- SIP messages are inherently NOT media.
They are, in effect "user to user signaling". This is consistent with my
earlier position on the use of phone input (DTMF) as "user to system
signaling", not media.
 
--
Dean

----- Original Message ----- 
From: Mark Watson   
To: 'Dean Willis'   ; Patil Basavaraj
(NET/Dallas)   ; 'ext Ben Campbell'
  
Cc: simple   
Sent: Monday, September 17, 2001 12:02 PM
Subject: RE: [Simple] Implicit MESSAGE sessions revisited

Dean,
 
I agree that they're independent. On the first one, I had thought that the
idea of IM 'sessions' fulfilled two key requirements:
 
1) I want to find my desired called party, and then exchange multiple
messages with this person
 
Some of these things which can happen (in the network/UEs) as a SIP message
finds the desired end-user may take time/cost money/require user
interaction, and I don't want to repeat them once I have found the person I
want to chat to. Also, there is no guarantee that repeating the process at a
later time will get me to the same end-user. So, I want to be able to do a
'session setup' and then send messages directly to the person I've found.
 
Of course, I could just treat the first message as an implicit session
setup, but this seems to be out of fashion.
 
2) I want IM to be just another media that I can negotiate, add & remove
from a session etc.
 
Again, I could do something clever with Call IDs to connect a MESSAGE
message with a pre-existing session etc. etc., but why should I make an
exception for this one kind of media. If I do that, then no capabilities
that I have now or invent in the future which are supposed to be 'media type
independent', will work for IM, and I will have to be hacking the IM system
constantly to keep up.
 
Did you disagree with these requirements, or just with the implementation ?
 
Regards...Mark

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 17 September 2001 17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); 'ext Ben
Campbell'
Cc: simple
Subject: Re: [Simple] Implicit MESSAGE sessions revisited


Both, actually. I believe the issues are independent.
 
--
Dean
 

----- Original Message ----- 
From: Mark Watson   
To: 'Dean Willis'   ; Patil Basavaraj
(NET/Dallas)   ; 'ext Ben Campbell'
  
Cc: simple   
Sent: Monday, September 17, 2001 9:39 AM
Subject: RE: [Simple] Implicit MESSAGE sessions revisited


Dean, 

Do you mean that you don't see the advantage of using INVITE to set up an IM
'session' (indicating this in the SDP), or just that once such a session is
set up, there is no need for the 'media' to use any different protocol than
that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set up using INVITE
just like any other SIP session, make sense. I don't care much yet what the
transport protocol then is for the IMs in the session.

Sorry if this is covering old ground. 

...Mark 




> -----Original Message----- 
> From: Dean Willis [ mailto:dean.willis@softarmor.com
 ] 
> Sent: 15 September 2001 05:31 
> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell' 
> Cc: simple 
> Subject: Re: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> 
> Just as MESSAGE for sessions has all the wasted overhead of 
> headers and 
> routing mechanisms designed to find users and traverse 
> firewalls (assuming 
> you think this is a waste), so does BEEP. 
> 
> I personally have yet to see the need for message sessions as 
> a specialized 
> transport. 
> 
> I think "pager" messages carrying a session-ID and sequence number can 
> provide the same user experience. 
> 
> -- 
> dean 
> 
> 
> ----- Original Message ----- 
> From: "Patil Basavaraj (NET/Dallas)"  
> To: "'ext Ben Campbell'"  
> Cc:  
> Sent: Friday, September 14, 2001 1:07 PM 
> Subject: RE: [Simple] Implicit MESSAGE sessions revisited 
> 
> 
> > 
> > One of the protocols that has been suggested for use instead of 
> > MESSAGE is BEEP. Are there any serious concerns *at this time* 
> > why BEEP would not be good eniugh for IM Sessions? 
> > 
> > -Basavaraj 
> > 
> > 
> > _______________________________________________ 
> > 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_01C141B1.DB37F960
Content-Type: text/html;
	charset="iso-8859-1"




RE: [Simple] Implicit MESSAGE sessions revisited






But 
this is just using a page-mode message to set up an implicit session. That's 
fine by me for requirement (1) - all I wanted was the 'session' concept. But the 
'implicit' session set up seems to have been rejected in previous discussions 
(unless I've misunderstood).


 


It 
doesn't solve requirement (2) anyway.


 


...Mark



  
-----Original Message-----
From: Dean Willis 
  [mailto:dean.willis@softarmor.com]
Sent: 19 September 2001 
  20:30
To: Watson, Mark [MAIFP:EP11:EXCH]; simple
Subject: 
  Re: [Simple] Implicit MESSAGE sessions revisited


  
 

  
Assume page-mode messages have a "sessionID" in 
  their payload.

  
 

  
Joe sends a message to Ann.

  
Ann forwards to Bob.

  
Bob replies to Joe. This reply carries the 
  sessionID from Joe's original message.

  
Joe's app realizes his session is now with Bob 
  and sends further messages in the session to Bob.

  
Joe and Bob exchange many messages in this 
  session.

  
Ann has a life.

  
 

  
-_
Dean

  
 

  

    
----- Original Message ----- 

    
    
    
Sent: Tuesday, September 18, 2001 12:59 
    PM

    
Subject: RE: [Simple] Implicit MESSAGE 
    sessions revisited

    


    
(1), it's not just a question of optimising the 
    message routing, it's also that in routing the initial INVITE I may use up 
    certain resources or require user intervention, and I don't want to repeat 
    all that for every message in the 'chat session'.

    

For example, Ann has all incoming sessions 
    presented to their SIP client but can hit a key to forward them to her 
    assistant Bob. If it's an IM chat session, and Bob gets into a long 
    conversation, Ann does not want to see every message, and have to hit a key 
    to forward it.

    
 

    
Anns client could forward 'subsequent' messages 
    automatically, but then Ann's client is implicitly taking on a notion of a 
    'session' and we are into the implicit session setup debate again - how does 
    it detect when this session has ended and a new one started ? What happens 
    if Ann turns her client off before Bob has finished chatting ? Ann could 
    instruct her proxy to forwared SIP requests to Bob, but perhaps she doesn't 
    want to. Perhaps she wants new calls to go to her mobile, but the rest of 
    Bob's chat session to continue unaffected.

    
 

    
So 
    it's not just a message routing optimisation, there are other resources 
    being optimised too (Ann's time).

    
 

    
(2) SIP messages are not media, sure, but Instant 
    Messages are. Instant Messages are not 'user to user signalling' either, 
    because they are not signalling - they are a communication between the human 
    end-users, not between the equipment facilitating that communication (which 
    is how I would characterise 'signalling' here). So perhaps SIP messages 
    should not be used to carry Instant Messages - but this is a different point 
    entirely.

    
 

    
...Mark

    
 

    
 

    

      
-----Original Message-----
From: Dean Willis 
      [mailto:dean.willis@softarmor.com]
Sent: 18 September 2001 
      15:46
To: simple
Subject: Re: [Simple] Implicit 
      MESSAGE sessions revisited


      
 

      
I agree with #1,sortof. The best (only?) 
      justfication for INVITE-bounded message sessions is the use of 
      Record-Route to allow proxies that don't need to be in the route to opt 
      out. This allows the SIP-network to be "self optimizing" for message 
      routing. However, such SIP paths may be necessarily NOT end-to-end. For 
      example, putting a SIP UA behind a firewall proxy will require that 
      messages transit the firewall proxy. This is easily accomplished with 
      record-route. Remember, all the "signaling privacy" requirements 
      like  calling-party-ID and address-hiding apply to SIP messages. We 
      already have mechanisms to meet those requirements for SIP traffic -- 
      reusing them for messages is obviously functional.

      
 

      
I disagree with requirement #2 -- SIP 
      messages are inherently NOT media. They are, in effect "user to user 
      signaling". This is consistent with my earlier position on the use of 
      phone input (DTMF) as "user to system signaling", not media.

      
 

      
--
Dean

      

        
----- Original Message ----- 

        
        
        
Cc: simple 

        
Sent: Monday, September 17, 2001 
        12:02 PM

        
Subject: RE: [Simple] Implicit 
        MESSAGE sessions revisited

        


        
Dean,

        
 

        
I agree that they're independent. On the first 
        one, I had thought that the idea of IM 'sessions' fulfilled two key 
        requirements:

        
 

        
1) I want to find my desired called party, and 
        then exchange multiple messages with this person

        
 

        
Some of these things which can happen (in the 
        network/UEs) as a SIP message finds the desired end-user may take 
        time/cost money/require user interaction, and I don't want to repeat 
        them once I have found the person I want to chat to. Also, there is no 
        guarantee that repeating the process at a later time will get me to the 
        same end-user. So, I want to be able to do a 'session setup' and then 
        send messages directly to the person I've found.

        
 

        
Of course, I could just treat the first message 
        as an implicit session setup, but this seems to be out of 
        fashion.

        
 

        
2) I want IM to be just another media that I 
        can negotiate, add & remove from a session etc.

        
 

        
Again, I could do something clever with Call 
        IDs to connect a MESSAGE message with a pre-existing session etc. etc., 
        but why should I make an exception for this one kind of media. If I do 
        that, then no capabilities that I have now or invent in the future which 
        are supposed to be 'media type independent', will work for IM, and I 
        will have to be hacking the IM system constantly to keep 
        up.

        
 

        
Did you disagree with these requirements, or 
        just with the implementation ?

        
 

        
Regards...Mark

        

          
-----Original Message-----
From: Dean Willis 
          [mailto:dean.willis@softarmor.com]
Sent: 17 September 2001 
          17:32
To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj 
          (NET/Dallas); 'ext Ben Campbell'
Cc: 
          simple
Subject: Re: [Simple] Implicit MESSAGE sessions 
          revisited


          
Both, actually. I believe the issues are 
          independent.

          
 

          
--
Dean

          
 

          

            
----- Original Message ----- 

            
            
            
Cc: simple 

            
Sent: Monday, September 17, 
            2001 9:39 AM

            
Subject: RE: [Simple] Implicit 
            MESSAGE sessions revisited

            


            
Dean, 

            
Do you mean that you don't see the advantage of 
            using INVITE to set up an IM 'session' (indicating this in the SDP), 
            or just that once such a session is set up, there is no need for the 
            'media' to use any different protocol than that used for 'paging' 
            ?

            
I think there are a lot of reasons why IM 'sessions' 
            set up using INVITE just like any other SIP session, make sense. I 
            don't care much yet what the transport protocol then is for the IMs 
            in the session.

            
Sorry if this is covering old ground. 

            
...Mark 




            
> -----Original Message----- 
> From: Dean Willis [mailto:dean.willis@softarmor.com] 
            
> Sent: 15 September 2001 05:31 
> To: Patil Basavaraj (NET/Dallas); 'ext Ben 
            Campbell' 
> Cc: simple 
> Subject: Re: [Simple] Implicit MESSAGE sessions 
            revisited 
> 
> 
            
> 
> Just as 
            MESSAGE for sessions has all the wasted overhead of 
> headers and 
> routing 
            mechanisms designed to find users and traverse 
> firewalls (assuming 
> you 
            think this is a waste), so does BEEP. 
> 
            
> I personally have yet to see the need 
            for message sessions as 
> a 
            specialized 
> transport. 
> 
> I think "pager" messages 
            carrying a session-ID and sequence number can 
> provide the same user experience. 
> 
> -- 
> dean 
> 
> 
> ----- Original Message 
            ----- 
> From: "Patil Basavaraj 
            (NET/Dallas)" <Basavaraj.Patil@nokia.com> 
> To: "'ext Ben Campbell'" 
            <bcampbell@dynamicsoft.com> 
> Cc: 
            <simple@mailman.dynamicsoft.com> 
> 
            Sent: Friday, September 14, 2001 1:07 PM 
> Subject: RE: [Simple] Implicit MESSAGE sessions 
            revisited 
> 
> 
            
> > 
> > 
            One of the protocols that has been suggested for use instead 
            of 
> > MESSAGE is BEEP. Are there any 
            serious concerns *at this time* 
> > 
            why BEEP would not be good eniugh for IM Sessions? 
> > 
> > -Basavaraj 
            
> > 
> > 
            
> > 
            _______________________________________________ 
> > 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_01C141B1.DB37F960--

From Basavaraj.Patil@nokia.com  Thu Sep 20 15:34:49 2001
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 PAA16428
	for ; Thu, 20 Sep 2001 15:34:48 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.americas.nokia.com [172.18.194.216])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8KJZB726258
	for ; Thu, 20 Sep 2001 22:35:11 +0300 (EET DST)
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 f8KJYf326928
	for ; Thu, 20 Sep 2001 14:34:41 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 20 Sep 2001 14:34:39 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 20 Sep 2001 14:34:38 -0500
content-class: urn:content-classes:message
Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
Date: Thu, 20 Sep 2001 14:34:38 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF441E86F7@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Comment: draft-ietf-simple-presence-02
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFAMLD7CE8lkqwhEdWBSwBQi2X+DwB2oqFQ
From: "Patil Basavaraj (NET/Dallas)" 
To: "'ext Jonathan Rosenberg'" ,
        
X-OriginalArrivalTime: 20 Sep 2001 19:34:38.0302 (UTC) FILETIME=[492FAFE0:01C1420B]
Content-Length: 1535
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA16428
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: 

>> 
>> 
>> Non-critical issue:
>> 
>> Section 5.3 (Paragraph 3) defines a default filter. However
>> I do not see the need for bullet 3 wherein additional markup
>> is sent (if < 50 bytes). It is better to have a consistent mechanism
>> of sending any markup (irrespective of size) only if explicitly
>> requested
>> by the subscriber or just send all the markup as the default. 
>
>The problem is that in rfc2778, "additional markup" can be almost
anything.
>Always sending it might imply, down the road, sending huge jpeg files
with
>pictures of the user. I'm not sure you want that to be the default.
>

I agree. I was leaning towards not sending anything being the default.

>Never sending it also has problems. Looking at
draft-ietf-impp-cpim-pidf,
>this would mean that the "note" element would never be sent unless
>explicitly requested, since it is neither status or contact
information. I
>suspect the note will be used often, and I want to make sure its
included in
>the normal case. 
>
>So, I put this middle-ground sentence in to make sure that the small
stuff
>goes, and the bigger stuff needs to be requested.
>

It just does not seem to be a consistent way for doing things. So
while today it may be "note" that is useful to be carried in the
NOTIFY, there may be an other parameter that someone else might deem
important enough to be carried in the NOTIFY. Maybe there needs to be
a set of parameters that can be agreed upon as ones that pass through
the default filter irrespective of size.

-Basavaraj

>-Jonathan R.

From jdrosen@dynamicsoft.com  Fri Sep 21 00:32:54 2001
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 AAA18029
	for ; Fri, 21 Sep 2001 00:32:53 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8L4Vn8P019616;
	Fri, 21 Sep 2001 00:31:49 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 00:32:47 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Patil Basavaraj (NET/Dallas)'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
Date: Fri, 21 Sep 2001 00:32:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2658
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: 


 

> -----Original Message-----
> From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
> Sent: Thursday, September 20, 2001 3:35 PM
> To: 'ext Jonathan Rosenberg'; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
> 
> 
> >> 
> >> 
> >> Non-critical issue:
> >> 
> >> Section 5.3 (Paragraph 3) defines a default filter. However
> >> I do not see the need for bullet 3 wherein additional markup
> >> is sent (if < 50 bytes). It is better to have a consistent 
> mechanism
> >> of sending any markup (irrespective of size) only if explicitly
> >> requested
> >> by the subscriber or just send all the markup as the default. 
> >
> >The problem is that in rfc2778, "additional markup" can be almost
> anything.
> >Always sending it might imply, down the road, sending huge jpeg files
> with
> >pictures of the user. I'm not sure you want that to be the default.
> >
> 
> I agree. I was leaning towards not sending anything being the default.

I would also be fine for that, except for the technicality that in the
cpim-pidf format, the note element would then not be sent by default.

> 
> >Never sending it also has problems. Looking at
> draft-ietf-impp-cpim-pidf,
> >this would mean that the "note" element would never be sent unless
> >explicitly requested, since it is neither status or contact
> information. I
> >suspect the note will be used often, and I want to make sure its
> included in
> >the normal case. 
> >
> >So, I put this middle-ground sentence in to make sure that the small
> stuff
> >goes, and the bigger stuff needs to be requested.
> >
> 
> It just does not seem to be a consistent way for doing things. So
> while today it may be "note" that is useful to be carried in the
> NOTIFY, there may be an other parameter that someone else might deem
> important enough to be carried in the NOTIFY. Maybe there needs to be
> a set of parameters that can be agreed upon as ones that pass through
> the default filter irrespective of size.

The problem is that I don't want the spec to be specific to cpim-pidf as a
data format. If it did, I could simply say "send the note, but not
extensions", and we would be done. But, rfc2778 is more generic, and its all
clumped together.

I would welcome an alternate proposal.

-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

From rsparks@dynamicsoft.com  Fri Sep 21 10:21:48 2001
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 KAA19795
	for ; Fri, 21 Sep 2001 10:21:48 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8LEKg8P021696
	for ; Fri, 21 Sep 2001 10:20:42 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 10:21:41 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E605@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Fri, 21 Sep 2001 10:21:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 885
Subject: [Simple] Final day - WG LAST CALL : draft-ietf-simple-presence-02
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: 

Last call on this document closes at the end of today.

RjS

> -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: Thursday, September 06, 2001 1:10 PM
> To: 'simple@mailman.dynamicsoft.com'
> Cc: 'jon.peterson@nuestar.com'; 'djrosen@dynamicsoft.com'; 'Patrik
> Faltstrom'
> Subject: [Simple] WG LAST CALL : draft-ietf-simple-presence-02
> 
> 
> This is a SIMPLE Working Group Last Call for comments
> on draft-ietf-simple-presence-02.txt. This last call
> closes Friday September 21, 2001. Please post any
> final comments you have on this draft to this list by
> that date.
> 
> The draft is available at
> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-02.txt
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From Avshalom@ubique.com  Fri Sep 21 11:02:20 2001
Received: from ubqgate02.lotus.com ([194.196.39.50])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19954
	for ; Fri, 21 Sep 2001 11:02:19 -0400 (EDT)
From: Avshalom@ubique.com
Subject: RE: [Simple] Partial Notifies?
To: Jonathan Rosenberg 
Cc: "Adam Roach (E-mail)" ,
        "'Robert Brown'" ,
        simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Fri, 21 Sep 2001 18:00:15 +0300
X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at
 21/09/2001 18:01:05
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 5941
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: 

Is the partial silence can be considered as a consensus given that the wglc
is today?

avshalom
Sametime/Lotus/IBM



                                                                                                                     
                    Jonathan                                                                                         
                    Rosenberg              To:     "'Robert Brown'" , Avshalom Houri          
                    , simple@mailman.dynamicsoft.com                     
                    csoft.com>             cc:     "Adam Roach (E-mail)"                    
                                           Subject:     RE: [Simple] Partial Notifies?                               
                    18/09/2001                                                                                       
                    14:58                                                                                            
                                                                                                                     
                                                                                                                     




This thread fell on the floor, but its a real important one and I want to
get it going again. Its probably the biggest open issue for the presence
spec, which is currently in wglc, so addressing it is really a higher
priority than the IM session discussion.

I think that partial updates is probably a really good thing. I'd like to
make sure it is adequately supported in the right way.

Now, the question is, where does such support belong? Is it a per-package
thing? Or is it something in the sip-events framework? I would argue that
each package be able to define whether it does or doesn't use partial
notifies, but that the mechanism for doing them be shared across all
packages. For example, if we add a header like Last-Data-Received: with a
hash of the body, as Dror had proposed, I think this header belongs in the
sip-events specification.

I believe the requirements for the partial notifications are the following:

1. the subscribe request have a way for the subscriber to indicate what
version they have, so that the notify only contain a delta from that
version
(indeed, perhaps the notify isn't even sent if the version the subscriber
has is up to date)

2. the notify have a way to indicate what version of the document the
subscriber will have once the patch is applied

3. the notify have a way to indicate what version the of the document the
subscriber has to apply the patch against (i.e, the old version)

4. the "patch" be in a format that is independent of the format of the
presence document.


Number 4 is important, I think, to avoid needing to specify updates and
partial notifies within every event document format. We just do it once,
and
then each event package doesn't need to ever worry about it again.

Anders Kristensen had pointed out to me that webdav has looked at a very
similar problem, and that there are specs for deltas within http. I haven't
looked at those in detail, but they might provide a solution for us that
would allow us to reuse existing work elsewhere in IETF.

So, the quesitons to be discussed, in order, are:

1. is there consensus that we should have a solution for partial notifies
in
simple?

2. is there consensus that this should be done in a general fashion as part
of the sip events specification?

3. how should it be done?

Comments?

-Jonathan R.



> -----Original Message-----
> From: Robert Brown [mailto:roberbr@microsoft.com]
> Sent: Wednesday, September 05, 2001 4:41 PM
> To: Avshalom Houri; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Partial Notifies?
>
>
> Watcher info can become pretty big too.  It would be nice to receive
> partials that only contained new pending watchers.
>
> ----- Original Message -----
> From: "Avshalom Houri" 
> To: 
> Sent: Wednesday, September 05, 2001 4:33 AM
> Subject: RE: [Simple] Partial Notifies?
>
>
> > > I was actually debating this issue when doing the update
> of the presence
> >
> > > spec. Its not specified right now, all through the events
> framework
> allows
> >
> > > each package to define how its done.
> >
> > I think that it should be included since NOTIFY can become
> big especially
> > given
> >
> > detail/schema/human readable comment.
> >
> > >
> >
> > > One model to do this is something I have proposed for
> other packages:
> >
> > >
> >
> > > 1. the notify triggered by a subscribe contains the full state
> >
> > > 2. subsequent notifies contain only the piece thats
> changed (i.e., the
> >
> > > contact address that is different)
> >
> > > 3. the subscriber keeps track of the cseq to see if it
> may have missed a
> >
> > > notify. If there are no gaps in Cseq, nothing was missed.
> If there is a
> > gap,
> >
> > > something may have been missed, or else there was an intermediate
> > challenge
> >
> > > or something like that. So, the subscriber re-subscribes to get a
> > triggered
> >
> > > notify with full state.
> >
> > I assume that the granularity will be a single tuple of the
> presence, and
> > that
> >
> > there will be an operator preceding the tuple for add/delete/update.
> >
> > >
> >
> > > A better way to handle the ordering is for the presence
> document itself
> to
> >
> > > contain version numbers, but that would require changes
> in the pidf
> spec.
> >
> > >
> >
> > > Since the initial SUBSCRIBE has to trigger full state anyway,
> idempotency
> > of
> >
> > > SUBSCRIBE would argue for having full state triggered notify for
> refreshes
> >
> > > too.
> >
> > It seems that Dror's suggestion (dror@vocaltec.com) can be
> helpful here.
> >
> > avshalom
> >
> > Sametime/Lotus/IBM
> >
> >
> >





From sean.olson@ericsson.com  Fri Sep 21 11:06:01 2001
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 LAA19998
	for ; Fri, 21 Sep 2001 11:06:00 -0400 (EDT)
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 f8LF5oQ17403
	for ; Fri, 21 Sep 2001 10:05:50 -0500 (CDT)
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 f8LF5o624699
	for ; Fri, 21 Sep 2001 10:05:50 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Sep 21 10:05:39 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 10:05:39 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Avshalom@ubique.com'" ,
        Jonathan Rosenberg
	 
Cc: "Adam Roach (E-mail)" ,
        "'Robert Brown'"
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?
Date: Fri, 21 Sep 2001 10:05:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C142AE.DF65FBB0"
Content-Length: 26662
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: 

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_01C142AE.DF65FBB0
Content-Type: text/plain;
	charset="iso-8859-1"

I would like some clarification on how
this would be documented (separate I-D?) and
on whether or not this is mandatory to support
in the client / server. (I assume not)

Thanks,
Sean Olson
Ericsson Inc.

>-----Original Message-----
>From: Avshalom@ubique.com [mailto:Avshalom@ubique.com]
>Sent: Friday, September 21, 2001 10:00 AM
>To: Jonathan Rosenberg
>Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com
>Subject: RE: [Simple] Partial Notifies?
>
>
>
>Is the partial silence can be considered as a consensus given 
>that the wglc
>is today?
>
>avshalom
>Sametime/Lotus/IBM
>
>
>
>                                                               
>                                                      
>                    Jonathan                                   
>                                                      
>                    Rosenberg              To:     "'Robert 
>Brown'" , Avshalom Houri          
>                    , simple@mailman.dynamicsoft.com          
>           
>                    csoft.com>             cc:     "Adam Roach 
>(E-mail)"                    
>                                           Subject:     RE: 
>[Simple] Partial Notifies?                               
>                    18/09/2001                                 
>                                                      
>                    14:58                                      
>                                                      
>                                                               
>                                                      
>                                                               
>                                                      
>
>
>
>
>This thread fell on the floor, but its a real important one 
>and I want to
>get it going again. Its probably the biggest open issue for 
>the presence
>spec, which is currently in wglc, so addressing it is really a higher
>priority than the IM session discussion.
>
>I think that partial updates is probably a really good thing. 
>I'd like to
>make sure it is adequately supported in the right way.
>
>Now, the question is, where does such support belong? Is it a 
>per-package
>thing? Or is it something in the sip-events framework? I would 
>argue that
>each package be able to define whether it does or doesn't use partial
>notifies, but that the mechanism for doing them be shared across all
>packages. For example, if we add a header like 
>Last-Data-Received: with a
>hash of the body, as Dror had proposed, I think this header 
>belongs in the
>sip-events specification.
>
>I believe the requirements for the partial notifications are 
>the following:
>
>1. the subscribe request have a way for the subscriber to indicate what
>version they have, so that the notify only contain a delta from that
>version
>(indeed, perhaps the notify isn't even sent if the version the 
>subscriber
>has is up to date)
>
>2. the notify have a way to indicate what version of the document the
>subscriber will have once the patch is applied
>
>3. the notify have a way to indicate what version the of the 
>document the
>subscriber has to apply the patch against (i.e, the old version)
>
>4. the "patch" be in a format that is independent of the format of the
>presence document.
>
>
>Number 4 is important, I think, to avoid needing to specify updates and
>partial notifies within every event document format. We just 
>do it once,
>and
>then each event package doesn't need to ever worry about it again.
>
>Anders Kristensen had pointed out to me that webdav has looked 
>at a very
>similar problem, and that there are specs for deltas within 
>http. I haven't
>looked at those in detail, but they might provide a solution 
>for us that
>would allow us to reuse existing work elsewhere in IETF.
>
>So, the quesitons to be discussed, in order, are:
>
>1. is there consensus that we should have a solution for 
>partial notifies
>in
>simple?
>
>2. is there consensus that this should be done in a general 
>fashion as part
>of the sip events specification?
>
>3. how should it be done?
>
>Comments?
>
>-Jonathan R.
>
>
>
>> -----Original Message-----
>> From: Robert Brown [mailto:roberbr@microsoft.com]
>> Sent: Wednesday, September 05, 2001 4:41 PM
>> To: Avshalom Houri; simple@mailman.dynamicsoft.com
>> Subject: Re: [Simple] Partial Notifies?
>>
>>
>> Watcher info can become pretty big too.  It would be nice to receive
>> partials that only contained new pending watchers.
>>
>> ----- Original Message -----
>> From: "Avshalom Houri" 
>> To: 
>> Sent: Wednesday, September 05, 2001 4:33 AM
>> Subject: RE: [Simple] Partial Notifies?
>>
>>
>> > > I was actually debating this issue when doing the update
>> of the presence
>> >
>> > > spec. Its not specified right now, all through the events
>> framework
>> allows
>> >
>> > > each package to define how its done.
>> >
>> > I think that it should be included since NOTIFY can become
>> big especially
>> > given
>> >
>> > detail/schema/human readable comment.
>> >
>> > >
>> >
>> > > One model to do this is something I have proposed for
>> other packages:
>> >
>> > >
>> >
>> > > 1. the notify triggered by a subscribe contains the full state
>> >
>> > > 2. subsequent notifies contain only the piece thats
>> changed (i.e., the
>> >
>> > > contact address that is different)
>> >
>> > > 3. the subscriber keeps track of the cseq to see if it
>> may have missed a
>> >
>> > > notify. If there are no gaps in Cseq, nothing was missed.
>> If there is a
>> > gap,
>> >
>> > > something may have been missed, or else there was an intermediate
>> > challenge
>> >
>> > > or something like that. So, the subscriber re-subscribes to get a
>> > triggered
>> >
>> > > notify with full state.
>> >
>> > I assume that the granularity will be a single tuple of the
>> presence, and
>> > that
>> >
>> > there will be an operator preceding the tuple for 
>add/delete/update.
>> >
>> > >
>> >
>> > > A better way to handle the ordering is for the presence
>> document itself
>> to
>> >
>> > > contain version numbers, but that would require changes
>> in the pidf
>> spec.
>> >
>> > >
>> >
>> > > Since the initial SUBSCRIBE has to trigger full state anyway,
>> idempotency
>> > of
>> >
>> > > SUBSCRIBE would argue for having full state triggered notify for
>> refreshes
>> >
>> > > too.
>> >
>> > It seems that Dror's suggestion (dror@vocaltec.com) can be
>> helpful here.
>> >
>> > avshalom
>> >
>> > Sametime/Lotus/IBM
>> >
>> >
>> >
>
>
>
>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

------_=_NextPart_001_01C142AE.DF65FBB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Partial Notifies?




I would like some clarification on how

this would be documented (separate I-D?) and

on whether or not this is mandatory to =
support

in the client / server. (I assume not)




Thanks,

Sean Olson

Ericsson Inc.




>-----Original Message-----

>From: Avshalom@ubique.com [mailto:Avshalom@ubique.com]

>Sent: Friday, September 21, 2001 10:00 AM

>To: Jonathan Rosenberg

>Cc: Adam Roach (E-mail); 'Robert Brown'; =
simple@mailman.dynamicsoft.com

>Subject: RE: [Simple] Partial Notifies?

>

>

>

>Is the partial silence can be considered as a =
consensus given 

>that the wglc

>is today?

>

>avshalom

>Sametime/Lotus/IBM

>

>

>

>          =
;            =
;            =
;            =
;            =
;     

>          =
;            =
;            =
;            =
;        

>          =
;          =
Jonathan          &nbs=
p;           &nbs=
p;            =


>          =
;            =
;            =
;            =
;        

>          =
;          =
Rosenberg          &nb=
sp;   To:     "'Robert 

>Brown'" <roberbr@microsoft.com>, =
Avshalom Houri          =


>          =
;          =
<jdrosen@dynami        

><avshalom@ubique.com>, =
simple@mailman.dynamicsoft.com       =
   

>          =
; 

>          =
;          =
csoft.com>          =
;   cc:     "Adam Roach 

>(E-mail)" =
<adam.roach@ericsson.com>       =
;            =


>          =
;            =
;            =
;         =
Subject:     RE: 

>[Simple] Partial =
Notifies?          &nb=
sp;           &nb=
sp;        

>          =
;          =
18/09/2001          &n=
bsp;           &n=
bsp;          

>          =
;            =
;            =
;            =
;        

>          =
;          =
14:58           &=
nbsp;           &=
nbsp;           &=
nbsp;  

>          =
;            =
;            =
;            =
;        

>          =
;            =
;            =
;            =
;            =
;     

>          =
;            =
;            =
;            =
;        

>          =
;            =
;            =
;            =
;            =
;     

>          =
;            =
;            =
;            =
;        

>

>

>

>

>This thread fell on the floor, but its a real =
important one 

>and I want to

>get it going again. Its probably the biggest =
open issue for 

>the presence

>spec, which is currently in wglc, so addressing =
it is really a higher

>priority than the IM session discussion.

>

>I think that partial updates is probably a =
really good thing. 

>I'd like to

>make sure it is adequately supported in the =
right way.

>

>Now, the question is, where does such support =
belong? Is it a 

>per-package

>thing? Or is it something in the sip-events =
framework? I would 

>argue that

>each package be able to define whether it does =
or doesn't use partial

>notifies, but that the mechanism for doing them =
be shared across all

>packages. For example, if we add a header like =


>Last-Data-Received: with a

>hash of the body, as Dror had proposed, I think =
this header 

>belongs in the

>sip-events specification.

>

>I believe the requirements for the partial =
notifications are 

>the following:

>

>1. the subscribe request have a way for the =
subscriber to indicate what

>version they have, so that the notify only =
contain a delta from that

>version

>(indeed, perhaps the notify isn't even sent if =
the version the 

>subscriber

>has is up to date)

>

>2. the notify have a way to indicate what =
version of the document the

>subscriber will have once the patch is =
applied

>

>3. the notify have a way to indicate what =
version the of the 

>document the

>subscriber has to apply the patch against (i.e, =
the old version)

>

>4. the "patch" be in a format that is =
independent of the format of the

>presence document.

>

>

>Number 4 is important, I think, to avoid needing =
to specify updates and

>partial notifies within every event document =
format. We just 

>do it once,

>and

>then each event package doesn't need to ever =
worry about it again.

>

>Anders Kristensen had pointed out to me that =
webdav has looked 

>at a very

>similar problem, and that there are specs for =
deltas within 

>http. I haven't

>looked at those in detail, but they might =
provide a solution 

>for us that

>would allow us to reuse existing work elsewhere =
in IETF.

>

>So, the quesitons to be discussed, in order, =
are:

>

>1. is there consensus that we should have a =
solution for 

>partial notifies

>in

>simple?

>

>2. is there consensus that this should be done =
in a general 

>fashion as part

>of the sip events specification?

>

>3. how should it be done?

>

>Comments?

>

>-Jonathan R.

>

>

>

>> -----Original Message-----

>> From: Robert Brown [mailto:roberbr@microsoft.com]<=
/FONT>

>> Sent: Wednesday, September 05, 2001 4:41 =
PM

>> To: Avshalom Houri; =
simple@mailman.dynamicsoft.com

>> Subject: Re: [Simple] Partial =
Notifies?

>>

>>

>> Watcher info can become pretty big =
too.  It would be nice to receive

>> partials that only contained new pending =
watchers.

>>

>> ----- Original Message -----

>> From: "Avshalom Houri" =
<avshalom@ubique.com>

>> To: =
<simple@mailman.dynamicsoft.com>

>> Sent: Wednesday, September 05, 2001 4:33 =
AM

>> Subject: RE: [Simple] Partial =
Notifies?

>>

>>

>> > > I was actually debating this =
issue when doing the update

>> of the presence

>> >

>> > > spec. Its not specified right =
now, all through the events

>> framework

>> allows

>> >

>> > > each package to define how its =
done.

>> >

>> > I think that it should be included =
since NOTIFY can become

>> big especially

>> > given

>> >

>> > detail/schema/human readable =
comment.

>> >

>> > >

>> >

>> > > One model to do this is something =
I have proposed for

>> other packages:

>> >

>> > >

>> >

>> > > 1. the notify triggered by a =
subscribe contains the full state

>> >

>> > > 2. subsequent notifies contain =
only the piece thats

>> changed (i.e., the

>> >

>> > > contact address that is =
different)

>> >

>> > > 3. the subscriber keeps track of =
the cseq to see if it

>> may have missed a

>> >

>> > > notify. If there are no gaps in =
Cseq, nothing was missed.

>> If there is a

>> > gap,

>> >

>> > > something may have been missed, =
or else there was an intermediate

>> > challenge

>> >

>> > > or something like that. So, the =
subscriber re-subscribes to get a

>> > triggered

>> >

>> > > notify with full state.

>> >

>> > I assume that the granularity will be =
a single tuple of the

>> presence, and

>> > that

>> >

>> > there will be an operator preceding =
the tuple for 

>add/delete/update.

>> >

>> > >

>> >

>> > > A better way to handle the =
ordering is for the presence

>> document itself

>> to

>> >

>> > > contain version numbers, but that =
would require changes

>> in the pidf

>> spec.

>> >

>> > >

>> >

>> > > Since the initial SUBSCRIBE has =
to trigger full state anyway,

>> idempotency

>> > of

>> >

>> > > SUBSCRIBE would argue for having =
full state triggered notify for

>> refreshes

>> >

>> > > too.

>> >

>> > It seems that Dror's suggestion =
(dror@vocaltec.com) can be

>> helpful here.

>> >

>> > avshalom

>> >

>> > Sametime/Lotus/IBM

>> >

>> >

>> >

>

>

>

>

>_______________________________________________

>simple mailing list

>simple@mailman.dynamicsoft.com

>http://mailman.dynamicsoft.com/mailman/listinfo/simple=


>





------_=_NextPart_001_01C142AE.DF65FBB0--

From rsparks@dynamicsoft.com  Fri Sep 21 11:25:07 2001
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 LAA20131
	for ; Fri, 21 Sep 2001 11:25:07 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8LFK88P022570;
	Fri, 21 Sep 2001 11:20:08 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 11:21:08 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E607@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: Sean Olson ,
        "'Avshalom@ubique.com'"
	 ,
        Jonathan Rosenberg 
Cc: "Adam Roach (E-mail)" ,
        "'Robert Brown'"
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?
Date: Fri, 21 Sep 2001 11:21:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C142B1.08C69080"
Content-Length: 30867
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: 

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_01C142B1.08C69080
Content-Type: text/plain;
	charset="iso-8859-1"

To help me understand where the group thinking is on addressing partial
notifies,
comment on the following:
 
1) We have a full-state notification mechanism that works for the presence
and
    watcher-info events. For some environments, that will be sufficient. In
others
    it may be non-optimal.
 
2) We sense a need for partial-state notification of one or both of those
packages,
    and suspect that a general cross-package framework supporting the
partial-state
    concept would be better than having individual packages solve the
problem in
    different ways.
 
Proposal: We complete the full-state path we started on, so that we have a
concrete
solution in place. We work in SIP to develop the framework. We then return
and develop
packages in simple (partial-*) using that framework.
 
RjS

-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, September 21, 2001 10:06 AM
To: 'Avshalom@ubique.com'; Jonathan Rosenberg
Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?



I would like some clarification on how 
this would be documented (separate I-D?) and 
on whether or not this is mandatory to support 
in the client / server. (I assume not) 

Thanks, 
Sean Olson 
Ericsson Inc. 

>-----Original Message----- 
>From: Avshalom@ubique.com [ mailto:Avshalom@ubique.com
 ] 
>Sent: Friday, September 21, 2001 10:00 AM 
>To: Jonathan Rosenberg 
>Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com 
>Subject: RE: [Simple] Partial Notifies? 
> 
> 
> 
>Is the partial silence can be considered as a consensus given 
>that the wglc 
>is today? 
> 
>avshalom 
>Sametime/Lotus/IBM 
> 
> 
> 
>                                                               
>                                                      
>                    Jonathan                                   
>                                                      
>                    Rosenberg              To:     "'Robert 
>Brown'" , Avshalom Houri          
>                    , simple@mailman.dynamicsoft.com          
>           
>                    csoft.com>             cc:     "Adam Roach 
>(E-mail)"                    
>                                           Subject:     RE: 
>[Simple] Partial Notifies?                               
>                    18/09/2001                                 
>                                                      
>                    14:58                                      
>                                                      
>                                                               
>                                                      
>                                                               
>                                                      
> 
> 
> 
> 
>This thread fell on the floor, but its a real important one 
>and I want to 
>get it going again. Its probably the biggest open issue for 
>the presence 
>spec, which is currently in wglc, so addressing it is really a higher 
>priority than the IM session discussion. 
> 
>I think that partial updates is probably a really good thing. 
>I'd like to 
>make sure it is adequately supported in the right way. 
> 
>Now, the question is, where does such support belong? Is it a 
>per-package 
>thing? Or is it something in the sip-events framework? I would 
>argue that 
>each package be able to define whether it does or doesn't use partial 
>notifies, but that the mechanism for doing them be shared across all 
>packages. For example, if we add a header like 
>Last-Data-Received: with a 
>hash of the body, as Dror had proposed, I think this header 
>belongs in the 
>sip-events specification. 
> 
>I believe the requirements for the partial notifications are 
>the following: 
> 
>1. the subscribe request have a way for the subscriber to indicate what 
>version they have, so that the notify only contain a delta from that 
>version 
>(indeed, perhaps the notify isn't even sent if the version the 
>subscriber 
>has is up to date) 
> 
>2. the notify have a way to indicate what version of the document the 
>subscriber will have once the patch is applied 
> 
>3. the notify have a way to indicate what version the of the 
>document the 
>subscriber has to apply the patch against (i.e, the old version) 
> 
>4. the "patch" be in a format that is independent of the format of the 
>presence document. 
> 
> 
>Number 4 is important, I think, to avoid needing to specify updates and 
>partial notifies within every event document format. We just 
>do it once, 
>and 
>then each event package doesn't need to ever worry about it again. 
> 
>Anders Kristensen had pointed out to me that webdav has looked 
>at a very 
>similar problem, and that there are specs for deltas within 
>http. I haven't 
>looked at those in detail, but they might provide a solution 
>for us that 
>would allow us to reuse existing work elsewhere in IETF. 
> 
>So, the quesitons to be discussed, in order, are: 
> 
>1. is there consensus that we should have a solution for 
>partial notifies 
>in 
>simple? 
> 
>2. is there consensus that this should be done in a general 
>fashion as part 
>of the sip events specification? 
> 
>3. how should it be done? 
> 
>Comments? 
> 
>-Jonathan R. 
> 
> 
> 
>> -----Original Message----- 
>> From: Robert Brown [ mailto:roberbr@microsoft.com
 ] 
>> Sent: Wednesday, September 05, 2001 4:41 PM 
>> To: Avshalom Houri; simple@mailman.dynamicsoft.com 
>> Subject: Re: [Simple] Partial Notifies? 
>> 
>> 
>> Watcher info can become pretty big too.  It would be nice to receive 
>> partials that only contained new pending watchers. 
>> 
>> ----- Original Message ----- 
>> From: "Avshalom Houri"  
>> To:  
>> Sent: Wednesday, September 05, 2001 4:33 AM 
>> Subject: RE: [Simple] Partial Notifies? 
>> 
>> 
>> > > I was actually debating this issue when doing the update 
>> of the presence 
>> > 
>> > > spec. Its not specified right now, all through the events 
>> framework 
>> allows 
>> > 
>> > > each package to define how its done. 
>> > 
>> > I think that it should be included since NOTIFY can become 
>> big especially 
>> > given 
>> > 
>> > detail/schema/human readable comment. 
>> > 
>> > > 
>> > 
>> > > One model to do this is something I have proposed for 
>> other packages: 
>> > 
>> > > 
>> > 
>> > > 1. the notify triggered by a subscribe contains the full state 
>> > 
>> > > 2. subsequent notifies contain only the piece thats 
>> changed (i.e., the 
>> > 
>> > > contact address that is different) 
>> > 
>> > > 3. the subscriber keeps track of the cseq to see if it 
>> may have missed a 
>> > 
>> > > notify. If there are no gaps in Cseq, nothing was missed. 
>> If there is a 
>> > gap, 
>> > 
>> > > something may have been missed, or else there was an intermediate 
>> > challenge 
>> > 
>> > > or something like that. So, the subscriber re-subscribes to get a 
>> > triggered 
>> > 
>> > > notify with full state. 
>> > 
>> > I assume that the granularity will be a single tuple of the 
>> presence, and 
>> > that 
>> > 
>> > there will be an operator preceding the tuple for 
>add/delete/update. 
>> > 
>> > > 
>> > 
>> > > A better way to handle the ordering is for the presence 
>> document itself 
>> to 
>> > 
>> > > contain version numbers, but that would require changes 
>> in the pidf 
>> spec. 
>> > 
>> > > 
>> > 
>> > > Since the initial SUBSCRIBE has to trigger full state anyway, 
>> idempotency 
>> > of 
>> > 
>> > > SUBSCRIBE would argue for having full state triggered notify for 
>> refreshes 
>> > 
>> > > too. 
>> > 
>> > It seems that Dror's suggestion (dror@vocaltec.com) can be 
>> helpful here. 
>> > 
>> > avshalom 
>> > 
>> > Sametime/Lotus/IBM 
>> > 
>> > 
>> > 
> 
> 
> 
> 
>_______________________________________________ 
>simple mailing list 
>simple@mailman.dynamicsoft.com 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
  
> 


------_=_NextPart_001_01C142B1.08C69080
Content-Type: text/html;
	charset="iso-8859-1"




RE: [Simple] Partial Notifies?




To 
help me understand where the group thinking is on addressing partial 
notifies,


comment on the following:


 


1) We 
have a full-state notification mechanism that works for the presence 
and


    watcher-info events. For some environments, that will 
be sufficient. In others


    it may be non-optimal.


 


2) 
We sense a need for partial-state notification of one or both of those 
packages,


    and suspect that a general cross-package framework 
supporting the partial-state


    concept would be better than having individual 
packages solve the problem in


    different ways.


 


Proposal: We complete the full-state path we started on, so that we have 
a concrete


solution in place. We work in SIP to develop the framework. We then 
return and develop


packages in simple (partial-*) using that framework.


 


RjS



  
-----Original Message-----
From: Sean Olson (EUS) 
  [mailto:sean.olson@ericsson.com]
Sent: Friday, September 21, 2001 
  10:06 AM
To: 'Avshalom@ubique.com'; Jonathan Rosenberg
Cc: 
  Adam Roach (E-mail); 'Robert Brown'; 
  simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial 
  Notifies?


  
I would like some clarification on how 
this would be documented (separate I-D?) and 
on 
  whether or not this is mandatory to support 
in the 
  client / server. (I assume not) 

  
Thanks, 
Sean Olson 
Ericsson Inc. 

  
>-----Original Message----- 
>From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] 
  
>Sent: Friday, September 21, 2001 10:00 AM 
  
>To: Jonathan Rosenberg 
>Cc: 
  Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com 
  
>Subject: RE: [Simple] Partial Notifies? 
> 
> 
> 
  
>Is the partial silence can be considered as a consensus 
  given 
>that the wglc 
>is 
  today? 
> 
>avshalom 
>Sametime/Lotus/IBM 
  
> 
> 
> 
>                                                               
  
>                                                      
  
>                    
  Jonathan                                   
  
>                                                      
  
>                    
  Rosenberg              
  To:     "'Robert 
>Brown'" 
  <roberbr@microsoft.com>, Avshalom 
  Houri          
>                    
  <jdrosen@dynami        
><avshalom@ubique.com>, 
  simple@mailman.dynamicsoft.com          
  
>           
  
>                    
  csoft.com>             
  cc:     "Adam Roach 
>(E-mail)" 
  <adam.roach@ericsson.com>                   
  
>                                           
  Subject:     RE: 
>[Simple] 
  Partial 
  Notifies?                               
  
>                    
  18/09/2001                                 
  
>                                                      
  
>                    
  14:58                                      
  
>                                                      
  
>                                                               
  
>                                                      
  
>                                                               
  
>                                                      
  
> 
> 
> 
> 
>This 
  thread fell on the floor, but its a real important one 
>and I want to 
>get it going again. Its 
  probably the biggest open issue for 
>the 
  presence 
>spec, which is currently in wglc, so 
  addressing it is really a higher 
>priority than the 
  IM session discussion. 
> 
>I think that partial updates is probably a really good thing. 
  
>I'd like to 
>make sure 
  it is adequately supported in the right way. 
> 
>Now, the question is, where does such 
  support belong? Is it a 
>per-package 
  
>thing? Or is it something in the sip-events framework? I 
  would 
>argue that 
>each 
  package be able to define whether it does or doesn't use partial 
  
>notifies, but that the mechanism for doing them be shared 
  across all 
>packages. For example, if we add a 
  header like 
>Last-Data-Received: with a 
  
>hash of the body, as Dror had proposed, I think this 
  header 
>belongs in the 
>sip-events specification. 
> 
  
>I believe the requirements for the partial notifications 
  are 
>the following: 
> 
>1. the subscribe request have a way 
  for the subscriber to indicate what 
>version they 
  have, so that the notify only contain a delta from that 
>version 
>(indeed, perhaps the notify 
  isn't even sent if the version the 
>subscriber 
>has is up to date) 
  
> 
>2. the notify have a way to 
  indicate what version of the document the 
>subscriber will have once the patch is applied 
> 
>3. the notify have a way to indicate 
  what version the of the 
>document the 
  
>subscriber has to apply the patch against (i.e, the old 
  version) 
> 
>4. the 
  "patch" be in a format that is independent of the format of the 
  
>presence document. 
> 
  
> 
>Number 4 is important, I 
  think, to avoid needing to specify updates and 
>partial notifies within every event document format. We just 
  
>do it once, 
>and 
  
>then each event package doesn't need to ever worry about 
  it again. 
> 
>Anders 
  Kristensen had pointed out to me that webdav has looked 
>at a very 
>similar problem, and that 
  there are specs for deltas within 
>http. I 
  haven't 
>looked at those in detail, but they might 
  provide a solution 
>for us that 
>would allow us to reuse existing work elsewhere in IETF. 
  
> 
>So, the quesitons to be 
  discussed, in order, are: 
> 
>1. is there consensus that we should have a solution for 
  
>partial notifies 
>in 
>simple? 
> 
>2. is there consensus that this should 
  be done in a general 
>fashion as part 
  
>of the sip events specification? 
> 
>3. how should it be done? 
  
> 
>Comments? 
> 
>-Jonathan R. 
> 
> 
> 
  
>> -----Original Message----- 
>> From: Robert Brown [mailto:roberbr@microsoft.com] 
  
>> Sent: Wednesday, September 05, 2001 4:41 PM 
  
>> To: Avshalom Houri; 
  simple@mailman.dynamicsoft.com 
>> Subject: Re: 
  [Simple] Partial Notifies? 
>> 
>> 
>> Watcher info can become 
  pretty big too.  It would be nice to receive 
>> partials that only contained new pending watchers. 
  
>> 
>> ----- Original 
  Message ----- 
>> From: "Avshalom Houri" 
  <avshalom@ubique.com> 
>> To: 
  <simple@mailman.dynamicsoft.com> 
>> Sent: 
  Wednesday, September 05, 2001 4:33 AM 
>> 
  Subject: RE: [Simple] Partial Notifies? 
>> 
>> 
>> > > I was actually debating this issue when doing the 
  update 
>> of the presence 
>> > 
>> > > spec. Its not 
  specified right now, all through the events 
>> 
  framework 
>> allows 
>> > 
>> > > each package 
  to define how its done. 
>> > 
>> > I think that it should be included since NOTIFY can 
  become 
>> big especially 
>> > given 
>> > 
  
>> > detail/schema/human readable comment. 
  
>> > 
>> > 
  > 
>> > 
>> 
  > > One model to do this is something I have proposed for 
  
>> other packages: 
>> 
  > 
>> > > 
>> > 
>> > > 1. the notify 
  triggered by a subscribe contains the full state 
>> > 
>> > > 2. subsequent 
  notifies contain only the piece thats 
>> changed 
  (i.e., the 
>> > 
>> > > contact address that is different) 
>> > 
>> > > 3. the 
  subscriber keeps track of the cseq to see if it 
>> may have missed a 
>> > 
  
>> > > notify. If there are no gaps in Cseq, 
  nothing was missed. 
>> If there is a 
  
>> > gap, 
>> 
  > 
>> > > something may have been 
  missed, or else there was an intermediate 
>> 
  > challenge 
>> > 
>> > > or something like that. So, the subscriber 
  re-subscribes to get a 
>> > triggered 
  
>> > 
>> > > 
  notify with full state. 
>> > 
>> > I assume that the granularity will be a single tuple of 
  the 
>> presence, and 
>> > that 
>> > 
  
>> > there will be an operator preceding the tuple 
  for 
>add/delete/update. 
>> > 
>> > > 
  
>> > 
>> > > A 
  better way to handle the ordering is for the presence 
>> document itself 
>> to 
  
>> > 
>> > > 
  contain version numbers, but that would require changes 
>> in the pidf 
>> spec. 
  
>> > 
>> > 
  > 
>> > 
>> 
  > > Since the initial SUBSCRIBE has to trigger full state anyway, 
  
>> idempotency 
>> > 
  of 
>> > 
>> > 
  > SUBSCRIBE would argue for having full state triggered notify for 
  
>> refreshes 
>> 
  > 
>> > > too. 
>> > 
>> > It seems that 
  Dror's suggestion (dror@vocaltec.com) can be 
>> 
  helpful here. 
>> > 
>> > avshalom 
>> > 
  
>> > Sametime/Lotus/IBM 
>> > 
>> > 
>> > 
> 
> 
> 
> 
  
>_______________________________________________ 
  
>simple mailing list 
>simple@mailman.dynamicsoft.com 
>http://mailman.dynamicsoft.com/mailman/listinfo/simple 
  
> 


------_=_NextPart_001_01C142B1.08C69080--

From jdrosen@dynamicsoft.com  Fri Sep 21 11:27:03 2001
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 LAA20167
	for ; Fri, 21 Sep 2001 11:27:03 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8LFPd8P022662;
	Fri, 21 Sep 2001 11:25:39 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 11:26:39 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Sean Olson ,
        "'Avshalom@ubique.com'"
	 ,
        Jonathan Rosenberg 
Cc: "Adam Roach (E-mail)" ,
        "'Robert Brown'"
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?
Date: Fri, 21 Sep 2001 11:26:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 8231
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: 

I think we should proceed with the presence spec as is, and instead work on
the partial notifies as an extension. There is still a lot more work that
needs to happen for partial notifies, as there are lots of ways to do it,
and they require real investigation. I think we have some time until this
becomes a dire need as well. 

I will add some text to the presence spec, though, which mentions that
extensions or new sub-packages can support partial notifies, just as a
placeholder.


OK? Please speak up with a yea or nay so we can have a real decision and
move on.

-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: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, September 21, 2001 11:06 AM
To: 'Avshalom@ubique.com'; Jonathan Rosenberg
Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?


I would like some clarification on how 
this would be documented (separate I-D?) and 
on whether or not this is mandatory to support 
in the client / server. (I assume not) 
Thanks, 
Sean Olson 
Ericsson Inc. 
>-----Original Message----- 
>From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] 
>Sent: Friday, September 21, 2001 10:00 AM 
>To: Jonathan Rosenberg 
>Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com 
>Subject: RE: [Simple] Partial Notifies? 
> 
> 
> 
>Is the partial silence can be considered as a consensus given 
>that the wglc 
>is today? 
> 
>avshalom 
>Sametime/Lotus/IBM 
> 
> 
> 
>                                                               
>                                                      
>                    Jonathan                                   
>                                                      
>                    Rosenberg              To:     "'Robert 
>Brown'" , Avshalom Houri          
>                    , simple@mailman.dynamicsoft.com          
>           
>                    csoft.com>             cc:     "Adam Roach 
>(E-mail)"                    
>                                           Subject:     RE: 
>[Simple] Partial Notifies?                               
>                    18/09/2001                                 
>                                                      
>                    14:58                                      
>                                                      
>                                                               
>                                                      
>                                                               
>                                                      
> 
> 
> 
> 
>This thread fell on the floor, but its a real important one 
>and I want to 
>get it going again. Its probably the biggest open issue for 
>the presence 
>spec, which is currently in wglc, so addressing it is really a higher 
>priority than the IM session discussion. 
> 
>I think that partial updates is probably a really good thing. 
>I'd like to 
>make sure it is adequately supported in the right way. 
> 
>Now, the question is, where does such support belong? Is it a 
>per-package 
>thing? Or is it something in the sip-events framework? I would 
>argue that 
>each package be able to define whether it does or doesn't use partial 
>notifies, but that the mechanism for doing them be shared across all 
>packages. For example, if we add a header like 
>Last-Data-Received: with a 
>hash of the body, as Dror had proposed, I think this header 
>belongs in the 
>sip-events specification. 
> 
>I believe the requirements for the partial notifications are 
>the following: 
> 
>1. the subscribe request have a way for the subscriber to indicate what 
>version they have, so that the notify only contain a delta from that 
>version 
>(indeed, perhaps the notify isn't even sent if the version the 
>subscriber 
>has is up to date) 
> 
>2. the notify have a way to indicate what version of the document the 
>subscriber will have once the patch is applied 
> 
>3. the notify have a way to indicate what version the of the 
>document the 
>subscriber has to apply the patch against (i.e, the old version) 
> 
>4. the "patch" be in a format that is independent of the format of the 
>presence document. 
> 
> 
>Number 4 is important, I think, to avoid needing to specify updates and 
>partial notifies within every event document format. We just 
>do it once, 
>and 
>then each event package doesn't need to ever worry about it again. 
> 
>Anders Kristensen had pointed out to me that webdav has looked 
>at a very 
>similar problem, and that there are specs for deltas within 
>http. I haven't 
>looked at those in detail, but they might provide a solution 
>for us that 
>would allow us to reuse existing work elsewhere in IETF. 
> 
>So, the quesitons to be discussed, in order, are: 
> 
>1. is there consensus that we should have a solution for 
>partial notifies 
>in 
>simple? 
> 
>2. is there consensus that this should be done in a general 
>fashion as part 
>of the sip events specification? 
> 
>3. how should it be done? 
> 
>Comments? 
> 
>-Jonathan R. 
> 
> 
> 
>> -----Original Message----- 
>> From: Robert Brown [mailto:roberbr@microsoft.com] 
>> Sent: Wednesday, September 05, 2001 4:41 PM 
>> To: Avshalom Houri; simple@mailman.dynamicsoft.com 
>> Subject: Re: [Simple] Partial Notifies? 
>> 
>> 
>> Watcher info can become pretty big too.  It would be nice to receive 
>> partials that only contained new pending watchers. 
>> 
>> ----- Original Message ----- 
>> From: "Avshalom Houri"  
>> To:  
>> Sent: Wednesday, September 05, 2001 4:33 AM 
>> Subject: RE: [Simple] Partial Notifies? 
>> 
>> 
>> > > I was actually debating this issue when doing the update 
>> of the presence 
>> > 
>> > > spec. Its not specified right now, all through the events 
>> framework 
>> allows 
>> > 
>> > > each package to define how its done. 
>> > 
>> > I think that it should be included since NOTIFY can become 
>> big especially 
>> > given 
>> > 
>> > detail/schema/human readable comment. 
>> > 
>> > > 
>> > 
>> > > One model to do this is something I have proposed for 
>> other packages: 
>> > 
>> > > 
>> > 
>> > > 1. the notify triggered by a subscribe contains the full state 
>> > 
>> > > 2. subsequent notifies contain only the piece thats 
>> changed (i.e., the 
>> > 
>> > > contact address that is different) 
>> > 
>> > > 3. the subscriber keeps track of the cseq to see if it 
>> may have missed a 
>> > 
>> > > notify. If there are no gaps in Cseq, nothing was missed. 
>> If there is a 
>> > gap, 
>> > 
>> > > something may have been missed, or else there was an intermediate 
>> > challenge 
>> > 
>> > > or something like that. So, the subscriber re-subscribes to get a 
>> > triggered 
>> > 
>> > > notify with full state. 
>> > 
>> > I assume that the granularity will be a single tuple of the 
>> presence, and 
>> > that 
>> > 
>> > there will be an operator preceding the tuple for 
>add/delete/update. 
>> > 
>> > > 
>> > 
>> > > A better way to handle the ordering is for the presence 
>> document itself 
>> to 
>> > 
>> > > contain version numbers, but that would require changes 
>> in the pidf 
>> spec. 
>> > 
>> > > 
>> > 
>> > > Since the initial SUBSCRIBE has to trigger full state anyway, 
>> idempotency 
>> > of 
>> > 
>> > > SUBSCRIBE would argue for having full state triggered notify for 
>> refreshes 
>> > 
>> > > too. 
>> > 
>> > It seems that Dror's suggestion (dror@vocaltec.com) can be 
>> helpful here. 
>> > 
>> > avshalom 
>> > 
>> > Sametime/Lotus/IBM 
>> > 
>> > 
>> > 
> 
> 
> 
> 
>_______________________________________________ 
>simple mailing list 
>simple@mailman.dynamicsoft.com 
>http://mailman.dynamicsoft.com/mailman/listinfo/simple 
> 

From dean.willis@softarmor.com  Fri Sep 21 11:35:07 2001
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 LAA20243
	for ; Fri, 21 Sep 2001 11:34:59 -0400 (EDT)
Received: from flak (localhost.localdomain [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f8LFa2D03946;
	Fri, 21 Sep 2001 10:36:04 -0500
Message-ID: <003201c142b2$f8cf4670$ad036e3f@flak>
From: "Dean Willis" 
To: "Paul Kyzivat" ,
        "simple" 
References: <3BA9173D.D6C1E73A@cisco.com>
Subject: Re: Re: [Simple] Implicit MESSAGE sessions revisited]
Date: Fri, 21 Sep 2001 10:34:55 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002F_01C14289.0DE70040"
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
Content-Length: 36461
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C14289.0DE70040
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Response:

1) Bob's IM client responds to the address indicated in the "From:" =
field of the received message.
2) Ann creates a new "paging conference session", understood only on her =
system which is doing the mixing/replicating. The message to Bob has a =
"From:" of "ann" and ann's application handles the replicating to Joe.

--
Dean

  ----- Original Message -----=20
  From: Paul Kyzivat=20
  To: simple=20
  Sent: Wednesday, September 19, 2001 5:07 PM
  Subject: [Fwd: Re: [Simple] Implicit MESSAGE sessions revisited]


  Dean,=20
  > Joe sends a message to Ann.> Ann forwards to Bob.> Bob replies to =
Joe. This reply carries the sessionID from Joe's original message.> =
Joe's app realizes his session is now with Bob and sends further =
messages in the session to Bob.> Joe and Bob exchange many messages in =
this session.> Ann has a life.=20

  Bunch of problems with this scenario:=20

  1) how does Bob reply to Joe? Does Bob's IM client offer a reply =
function that extracts Joe's address? Or does Bob manually initiate a =
new IM session with Bob?=20

  If the former, then clearly the IM protocol must have a more or less =
complete call control mechanism of its own, duplicating what is in SIP.=20

  If the latter, then how does the sessionID get into the reply? =
Presumably Bob would have to type it in. Not likely in the real world.=20

  2) How is this case distinguished from one where Ann wants to =
conference Bob in? Ann may be acting as a local mixer, passing Joe's =
messages on to Bob after reading them. In your scenario, this would look =
exactly the same to Bob, but the action he should take is different - he =
should reply to Ann, so that she can see the reply and relay it back to =
Joe.=20

  Your proposed solution can't deal with the multiple possibilities. =
There are many useful topologies that can be established using SIP. Do =
you propose to have SIMPLE reinvent all of them independently?=20

      Paul=20

  -------- Original Message -------- Subject:  Re: [Simple] Implicit =
MESSAGE sessions revisited=20
        Date:  Wed, 19 Sep 2001 14:29:34 -0500=20
        From:  "Dean Willis" =20
        To:  "Mark Watson" ,"simple" =
=20
        References:  =
=20


   Assume page-mode messages have a "sessionID" in their payload. Joe =
sends a message to Ann.Ann forwards to Bob.Bob replies to Joe. This =
reply carries the sessionID from Joe's original message.Joe's app =
realizes his session is now with Bob and sends further messages in the =
session to Bob.Joe and Bob exchange many messages in this session.Ann =
has a life. -_=20
  Dean =20

    ----- Original Message -----
    From: Mark Watson
    To: 'Dean Willis' ; simple
    Sent: Tuesday, September 18, 2001 12:59 PM
    Subject: RE: [Simple] Implicit MESSAGE sessions revisited
     (1), it's not just a question of optimising the message routing, =
it's also that in routing the initial INVITE I may use up certain =
resources or require user intervention, and I don't want to repeat all =
that for every message in the 'chat session'.=20
    For example, Ann has all incoming sessions presented to their SIP =
client but can hit a key to forward them to her assistant Bob. If it's =
an IM chat session, and Bob gets into a long conversation, Ann does not =
want to see every message, and have to hit a key to forward it.Anns =
client could forward 'subsequent' messages automatically, but then Ann's =
client is implicitly taking on a notion of a 'session' and we are into =
the implicit session setup debate again - how does it detect when this =
session has ended and a new one started ? What happens if Ann turns her =
client off before Bob has finished chatting ? Ann could instruct her =
proxy to forwared SIP requests to Bob, but perhaps she doesn't want to. =
Perhaps she wants new calls to go to her mobile, but the rest of Bob's =
chat session to continue unaffected.So it's not just a message routing =
optimisation, there are other resources being optimised too (Ann's =
time).(2) SIP messages are not media, sure, but Instant Messages are. =
Instant Messages are not 'user to user signalling' either, because they =
are not signalling - they are a communication between the human =
end-users, not between the equipment facilitating that communication =
(which is how I would characterise 'signalling' here). So perhaps SIP =
messages should not be used to carry Instant Messages - but this is a =
different point entirely....Mark=20
      -----Original Message-----=20
      From: Dean Willis [mailto:dean.willis@softarmor.com]=20
      Sent: 18 September 2001 15:46=20
      To: simple=20
      Subject: Re: [Simple] Implicit MESSAGE sessions revisited=20
      =20
       I agree with #1,sortof. The best (only?) justfication for =
INVITE-bounded message sessions is the use of Record-Route to allow =
proxies that don't need to be in the route to opt out. This allows the =
SIP-network to be "self optimizing" for message routing. However, such =
SIP paths may be necessarily NOT end-to-end. For example, putting a SIP =
UA behind a firewall proxy will require that messages transit the =
firewall proxy. This is easily accomplished with record-route. Remember, =
all the "signaling privacy" requirements like  calling-party-ID and =
address-hiding apply to SIP messages. We already have mechanisms to meet =
those requirements for SIP traffic -- reusing them for messages is =
obviously functional. I disagree with requirement #2 -- SIP messages are =
inherently NOT media. They are, in effect "user to user signaling". This =
is consistent with my earlier position on the use of phone input (DTMF) =
as "user to system signaling", not media. --=20
      Dean=20
        ----- Original Message -----
        From: Mark Watson
        To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben =
Campbell'
        Cc: simple
        Sent: Monday, September 17, 2001 12:02 PM
        Subject: RE: [Simple] Implicit MESSAGE sessions revisited
         Dean,I agree that they're independent. On the first one, I had =
thought that the idea of IM 'sessions' fulfilled two key requirements:1) =
I want to find my desired called party, and then exchange multiple =
messages with this personSome of these things which can happen (in the =
network/UEs) as a SIP message finds the desired end-user may take =
time/cost money/require user interaction, and I don't want to repeat =
them once I have found the person I want to chat to. Also, there is no =
guarantee that repeating the process at a later time will get me to the =
same end-user. So, I want to be able to do a 'session setup' and then =
send messages directly to the person I've found.Of course, I could just =
treat the first message as an implicit session setup, but this seems to =
be out of fashion.2) I want IM to be just another media that I can =
negotiate, add & remove from a session etc.Again, I could do something =
clever with Call IDs to connect a MESSAGE message with a pre-existing =
session etc. etc., but why should I make an exception for this one kind =
of media. If I do that, then no capabilities that I have now or invent =
in the future which are supposed to be 'media type independent', will =
work for IM, and I will have to be hacking the IM system constantly to =
keep up.Did you disagree with these requirements, or just with the =
implementation ?Regards...Mark=20
          -----Original Message-----=20
          From: Dean Willis [mailto:dean.willis@softarmor.com]=20
          Sent: 17 September 2001 17:32=20
          To: Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj =
(NET/Dallas); 'ext Ben Campbell'=20
          Cc: simple=20
          Subject: Re: [Simple] Implicit MESSAGE sessions revisited=20
          =20
          Both, actually. I believe the issues are independent. --=20
          Dean =20
            ----- Original Message -----
            From: Mark Watson
            To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ; 'ext Ben =
Campbell'
            Cc: simple
            Sent: Monday, September 17, 2001 9:39 AM
            Subject: RE: [Simple] Implicit MESSAGE sessions revisited
             Dean,=20
            Do you mean that you don't see the advantage of using INVITE =
to set up an IM 'session' (indicating this in the SDP), or just that =
once such a session is set up, there is no need for the 'media' to use =
any different protocol than that used for 'paging' ?=20

            I think there are a lot of reasons why IM 'sessions' set up =
using INVITE just like any other SIP session, make sense. I don't care =
much yet what the transport protocol then is for the IMs in the session. =


            Sorry if this is covering old ground.=20

            ...Mark=20
             =20
             =20

            > -----Original Message-----=20
            > From: Dean Willis [mailto:dean.willis@softarmor.com]=20
            > Sent: 15 September 2001 05:31=20
            > To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'=20
            > Cc: simple=20
            > Subject: Re: [Simple] Implicit MESSAGE sessions revisited=20
            >=20
            >=20
            >=20
            > Just as MESSAGE for sessions has all the wasted overhead =
of=20
            > headers and=20
            > routing mechanisms designed to find users and traverse=20
            > firewalls (assuming=20
            > you think this is a waste), so does BEEP.=20
            >=20
            > I personally have yet to see the need for message sessions =
as=20
            > a specialized=20
            > transport.=20
            >=20
            > I think "pager" messages carrying a session-ID and =
sequence number can=20
            > provide the same user experience.=20
            >=20
            > --=20
            > dean=20
            >=20
            >=20
            > ----- Original Message -----=20
            > From: "Patil Basavaraj (NET/Dallas)" =
=20
            > To: "'ext Ben Campbell'" =20
            > Cc: =20
            > Sent: Friday, September 14, 2001 1:07 PM=20
            > Subject: RE: [Simple] Implicit MESSAGE sessions revisited=20
            >=20
            >=20
            > >=20
            > > One of the protocols that has been suggested for use =
instead of=20
            > > MESSAGE is BEEP. Are there any serious concerns *at this =
time*=20
            > > why BEEP would not be good eniugh for IM Sessions?=20
            > >=20
            > > -Basavaraj=20
            > >=20
            > >=20
            > > _______________________________________________=20
            > > simple mailing list=20
            > > simple@mailman.dynamicsoft.com=20
            > > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
            > >=20
            > >=20
            >=20
            > _______________________________________________=20
            > simple mailing list=20
            > simple@mailman.dynamicsoft.com=20
            > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
            >


------=_NextPart_000_002F_01C14289.0DE70040
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Response:


 


1) Bob's IM client responds to the =
address=20
indicated in the "From:" field of the received message.


2) Ann creates a new "paging conference =
session",=20
understood only on her system which is doing the mixing/replicating. The =
message=20
to Bob has a "From:" of "ann" and ann's application handles =
the replicating=20
to Joe.


 


--
Dean


 



  
----- Original Message ----- 

  From:=20
  Paul =
Kyzivat=20
  
  
To: simple 

  
Sent: Wednesday, September 19, =
2001 5:07=20
  PM

  
Subject: [Fwd: Re: [Simple] =
Implicit=20
  MESSAGE sessions revisited]

  

Dean,=20
  
> Joe sends a message to=20
  Ann.> Ann forwards =
to=20
  Bob.> Bob replies =
to Joe. This=20
  reply carries the sessionID from Joe's original =
message.> Joe's app realizes his session is =
now with Bob=20
  and sends further messages in the session to Bob.> Joe and Bob exchange many messages =
in this=20
  session.> Ann has =
a=20
  life.=20
  
Bunch of problems with this=20
  scenario:=20
  
1) how does Bob reply to Joe? =
Does Bob's IM=20
  client offer a reply function that extracts Joe's address? Or does Bob =

  manually initiate a new IM session with Bob?=20
  
If the former, then clearly the =
IM protocol=20
  must have a more or less complete call control mechanism of its own,=20
  duplicating what is in SIP.=20
  
If the latter, then how does the =
sessionID=20
  get into the reply? Presumably Bob would have to type it in. Not =
likely in the=20
  real world.=20
  
2) How is this case =
distinguished from one=20
  where Ann wants to conference Bob in? Ann may be acting as a local =
mixer,=20
  passing Joe's messages on to Bob after reading them. In your scenario, =
this=20
  would look exactly the same to Bob, but the action he should take is =
different=20
  - he should reply to Ann, so that she can see the reply and relay it =
back to=20
  Joe.=20
  
Your proposed solution can't =
deal with the=20
  multiple possibilities. There are many useful topologies that can be=20
  established using SIP. Do you propose to have SIMPLE reinvent all of =
them=20
  independently?=20
  
    =
Paul=20
  
-------- Original Message --------=20
  
      =


    
    

      Subject: 
      Re: [Simple] Implicit MESSAGE sessions revisited

    

      Date: 
      Wed, 19 Sep 2001 14:29:34 -0500

    

      From: 
      "Dean Willis" <dean.willis@softarmor.com>

    

      To: 
      "Mark Watson" <mwatson@nortelnetworks.com>,"simple"=20
        <simple@mailman.dynamicsoft.com>

    

      References: <A3C2399B2FACD411A54200508BE39C7402E845BB@zwcwd00r.europe.nortel.c=
om>

  

  
   Assume page-mode messages =
have a=20
  "sessionID" in their payload. Joe sends a message to Ann.Ann forwards to Bob.Bob=20
  replies to Joe. This reply carries the sessionID from Joe's original=20
  message.Joe's app =
realizes his=20
  session is now with Bob and sends further messages in the session to=20
  Bob.Joe and Bob =
exchange many=20
  messages in this session.Ann has=20
  a life. -_=20
  
Dean =20
  

    
----- Original Message -----

    From:=20
    Mark Watson
    
To: 'Dean Willis' ; simple

    
Sent: Tuesday, September 18, =
2001 12:59=20
    PM

    
Subject: RE: [Simple] =
Implicit MESSAGE=20
    sessions revisited
 (1), it's not =
just a question=20
    of optimising the message routing, it's also that in routing the =
initial=20
    INVITE I may use up certain resources or require user intervention, =
and I=20
    don't want to repeat all that for every message in the 'chat=20
    session'.=20
    
For =
example, Ann has=20
    all incoming sessions presented to their SIP client but can hit a =
key to=20
    forward them to her assistant Bob. If it's an IM chat session, and =
Bob gets=20
    into a long conversation, Ann does not want to see every message, =
and have=20
    to hit a key to forward it.Anns client could =
forward=20
    'subsequent' messages automatically, but then Ann's client is =
implicitly=20
    taking on a notion of a 'session' and we are into the implicit =
session setup=20
    debate again - how does it detect when this session has ended and a =
new one=20
    started ? What happens if Ann turns her client off before Bob has =
finished=20
    chatting ? Ann could instruct her proxy to forwared SIP requests to =
Bob, but=20
    perhaps she doesn't want to. Perhaps she wants new calls to go to =
her=20
    mobile, but the rest of Bob's chat session to continue=20
    unaffected.So it's not just =
a message=20
    routing optimisation, there are other resources being optimised too =
(Ann's=20
    time).(2) SIP messages =
are not media,=20
    sure, but Instant Messages are. Instant Messages are not 'user to =
user=20
    signalling' either, because they are not signalling - they are a=20
    communication between the human end-users, not between the equipment =

    facilitating that communication (which is how I would characterise=20
    'signalling' here). So perhaps SIP messages should not be used to =
carry=20
    Instant Messages - but this is a different point=20
    entirely....Mark=20
    

      
-----Original Message----- 
From: Dean Willis [mailto:dean.willis@softarmor.co=
m]=20
      
Sent: 18 September =
2001=20
      15:46 
To:=20
      simple 
Subject:=20
      Re: [Simple] Implicit MESSAGE sessions revisited=20
      
 
 I agree =
with=20
      #1,sortof. The best (only?) justfication for INVITE-bounded =
message=20
      sessions is the use of Record-Route to allow proxies that don't =
need to be=20
      in the route to opt out. This allows the SIP-network to be "self=20
      optimizing" for message routing. However, such SIP paths may be=20
      necessarily NOT end-to-end. For example, putting a SIP UA behind a =

      firewall proxy will require that messages transit the firewall =
proxy. This=20
      is easily accomplished with record-route. Remember, all the =
"signaling=20
      privacy" requirements like  calling-party-ID and =
address-hiding apply=20
      to SIP messages. We already have mechanisms to meet those =
requirements for=20
      SIP traffic -- reusing them for messages is obviously=20
      functional. I disagree=20
      with requirement #2 -- SIP messages are inherently NOT media. They =
are, in=20
      effect "user to user signaling". This is consistent with my =
earlier=20
      position on the use of phone input (DTMF) as "user to system =
signaling",=20
      not media. -- 
Dean=20
      

        
----- Original Message =
-----

        From:=20
        Mark Watson
        
        
Cc: simple

        
Sent: Monday, September =
17, 2001=20
        12:02 PM

        
Subject: RE: [Simple] =
Implicit=20
        MESSAGE sessions revisited
 Dean,I agree =
that they're=20
        independent. On the first one, I had thought that the idea of IM =

        'sessions' fulfilled two key=20
        requirements:1) I want =
to find my=20
        desired called party, and then exchange multiple messages with =
this=20
        personSome of =
these things=20
        which can happen (in the network/UEs) as a SIP message finds the =
desired=20
        end-user may take time/cost money/require user interaction, and =
I don't=20
        want to repeat them once I have found the person I want to chat =
to.=20
        Also, there is no guarantee that repeating the process at a =
later time=20
        will get me to the same end-user. So, I want to be able to do a =
'session=20
        setup' and then send messages directly to the person I've=20
        found.Of course, =
I could just=20
        treat the first message as an implicit session setup, but this =
seems to=20
        be out of fashion.2) I want =
IM to be just=20
        another media that I can negotiate, add & remove from a =
session=20
        etc.Again, I =
could do=20
        something clever with Call IDs to connect a MESSAGE message with =
a=20
        pre-existing session etc. etc., but why should I make an =
exception for=20
        this one kind of media. If I do that, then no capabilities that =
I have=20
        now or invent in the future which are supposed to be 'media type =

        independent', will work for IM, and I will have to be hacking =
the IM=20
        system constantly to keep up.Did you =
disagree with=20
        these requirements, or just with the implementation=20
        ?Regards...Mark=20
        

          
-----Original Message----- 
From: Dean Willis [mailto:dean.willis@softarmor.co=
m]=20
          
Sent: 17 =
September 2001=20
          17:32 
To:=20
          Watson, Mark [MAIFP:EP11:EXCH]; Patil Basavaraj (NET/Dallas); =
'ext Ben=20
          Campbell' 
Cc:=20
          simple 
Subject: Re: [Simple] Implicit MESSAGE =
sessions=20
          revisited 
 
Both, actually. I believe the issues are=20
          independent. -- 
Dean =20
          

            
----- Original Message =
-----

            From:=20
            Mark =
Watson
            
To: 'Dean Willis' =
; Patil Basavaraj=20
            (NET/Dallas) ; 'ext Ben =
Campbell'

            
Cc: simple

            
Sent: Monday, =
September 17,=20
            2001 9:39 AM

            
Subject: RE: [Simple] =
Implicit=20
            MESSAGE sessions revisited
 Dean,=20
            
Do you mean that you don't see the =
advantage of=20
            using INVITE to set up an IM 'session' (indicating this in =
the SDP),=20
            or just that once such a session is set up, there is no need =
for the=20
            'media' to use any different protocol than that used for =
'paging'=20
            ?=20
            
I think there are a lot of reasons why IM =

            'sessions' set up using INVITE just like any other SIP =
session, make=20
            sense. I don't care much yet what the transport protocol =
then is for=20
            the IMs in the session.=20
            
Sorry if this is covering old =
ground.=20
            
...Mark 
  
 =20
            
> -----Original Message----- =

> From: Dean Willis [mailto:dean.willis@softarmor.co=
m]=20
            
> Sent: 15 September 2001 =
05:31=20
            
> To: Patil Basavaraj (NET/Dallas); =
'ext Ben=20
            Campbell' 
> Cc: simple =

> Subject: Re: [Simple] Implicit MESSAGE =
sessions=20
            revisited 
> 
> 
> =

> Just as MESSAGE for sessions has all the =
wasted=20
            overhead of 
> headers =
and=20
            
> routing mechanisms designed to find =
users and=20
            traverse 
> firewalls =
(assuming=20
            
> you think this is a waste), so does =

            BEEP. 
> 
> I=20
            personally have yet to see the need for message sessions =
as=20
            
> a specialized 
>=20
            transport. 
> 
> I think "pager" messages carrying a =
session-ID and=20
            sequence number can 
> provide =
the same=20
            user experience. 
> =

> -- 
> =
dean 
> 
> =

> ----- Original Message ----- 
> From: "Patil Basavaraj (NET/Dallas)"=20
            <Basavaraj.Patil@nokia.com> 
> To:=20
            "'ext Ben Campbell'" =
<bcampbell@dynamicsoft.com>=20
            
> Cc:=20
            <simple@mailman.dynamicsoft.com> 
>=20
            Sent: Friday, September 14, 2001 1:07 PM 
> Subject: RE: [Simple] Implicit MESSAGE =
sessions=20
            revisited 
> 
> 
> > =

> > One of the protocols that has been =
suggested for=20
            use instead of 
> > MESSAGE =
is BEEP.=20
            Are there any serious concerns *at this time* =

> > why BEEP would not be good eniugh for IM =

            Sessions? 
> > =

> > -Basavaraj 
>=20
            > 
> > 
> >=20
            _______________________________________________ =

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

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


------=_NextPart_000_002F_01C14289.0DE70040--


From pkyzivat@cisco.com  Fri Sep 21 11:45:59 2001
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 LAA20337
	for ; Fri, 21 Sep 2001 11:45:58 -0400 (EDT)
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 f8LFjFs29941
	for ; Fri, 21 Sep 2001 11:45:19 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAA98465 (AUTH pkyzivat);
	Fri, 21 Sep 2001 11:46:52 -0400 (EDT)
Message-ID: <3BAB6065.CDEFDB65@cisco.com>
Date: Fri, 21 Sep 2001 11:44:38 -0400
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: simple 
Subject: [Fwd: Re: Re: [Simple] Implicit MESSAGE sessions revisited]]
Content-Type: multipart/alternative;
 boundary="------------A44D2DBE5D7D5D94C6758CEF"
Content-Length: 39391
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: 

--------------A44D2DBE5D7D5D94C6758CEF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dean - there probably is no point in continuing this debate because it
is going nowhere. I think you are trying to reinvent the wheel, but I
presume you feel otherwise.

    Paul

-------- Original Message --------
   Subject: Re: Re: [Simple] Implicit MESSAGE sessions revisited]
      Date: Fri, 21 Sep 2001 10:34:55 -0500
      From: "Dean Willis" 
        To: "Paul Kyzivat" ,"simple"
            
References: <3BA9173D.D6C1E73A@cisco.com>

 Response: 1) Bob's IM client responds to the address indicated in the
"From:" field of the received message.2) Ann creates a new "paging
conference session", understood only on her system which is doing the
mixing/replicating. The message to Bob has a "From:" of "ann" and ann's
application handles the replicating to Joe. --
Dean

     ----- Original Message -----
     From: Paul Kyzivat
     To: simple
     Sent: Wednesday, September 19, 2001 5:07 PM
     Subject: [Fwd: Re: [Simple] Implicit MESSAGE sessions
     revisited]
      Dean,

     > Joe sends a message to Ann.> Ann forwards to Bob.> Bob
     replies to Joe. This reply carries the sessionID from Joe's
     original message.> Joe's app realizes his session is now with
     Bob and sends further messages in the session to Bob.> Joe and
     Bob exchange many messages in this session.> Ann has a life.

     Bunch of problems with this scenario:

     1) how does Bob reply to Joe? Does Bob's IM client offer a
     reply function that extracts Joe's address? Or does Bob
     manually initiate a new IM session with Bob?

     If the former, then clearly the IM protocol must have a more
     or less complete call control mechanism of its own,
     duplicating what is in SIP.

     If the latter, then how does the sessionID get into the reply?
     Presumably Bob would have to type it in. Not likely in the
     real world.

     2) How is this case distinguished from one where Ann wants to
     conference Bob in? Ann may be acting as a local mixer, passing
     Joe's messages on to Bob after reading them. In your scenario,
     this would look exactly the same to Bob, but the action he
     should take is different - he should reply to Ann, so that she
     can see the reply and relay it back to Joe.

     Your proposed solution can't deal with the multiple
     possibilities. There are many useful topologies that can be
     established using SIP. Do you propose to have SIMPLE reinvent
     all of them independently?

         Paul

     -------- Original Message --------

        Subject: Re: [Simple] Implicit MESSAGE sessions revisited
           Date: Wed, 19 Sep 2001 14:29:34 -0500
           From: "Dean Willis" 
             To: "Mark Watson" ,"simple"
                 
     References: 

     Assume page-mode messages have a "sessionID" in their payload.
     Joe sends a message to Ann.Ann forwards to Bob.Bob replies to
     Joe. This reply carries the sessionID from Joe's original
     message.Joe's app realizes his session is now with Bob and
     sends further messages in the session to Bob.Joe and Bob
     exchange many messages in this session.Ann has a life. -_
     Dean

          ----- Original Message -----
          From: Mark Watson
          To: 'Dean Willis' ; simple
          Sent: Tuesday, September 18, 2001 12:59 PM
          Subject: RE: [Simple] Implicit MESSAGE sessions
          revisited
          (1), it's not just a question of optimising the
          message routing, it's also that in routing the
          initial INVITE I may use up certain resources or
          require user intervention, and I don't want to
          repeat all that for every message in the 'chat
          session'.
          For example, Ann has all incoming sessions presented
          to their SIP client but can hit a key to forward
          them to her assistant Bob. If it's an IM chat
          session, and Bob gets into a long conversation, Ann
          does not want to see every message, and have to hit
          a key to forward it.Anns client could forward
          'subsequent' messages automatically, but then Ann's
          client is implicitly taking on a notion of a
          'session' and we are into the implicit session setup
          debate again - how does it detect when this session
          has ended and a new one started ? What happens if
          Ann turns her client off before Bob has finished
          chatting ? Ann could instruct her proxy to forwared
          SIP requests to Bob, but perhaps she doesn't want
          to. Perhaps she wants new calls to go to her mobile,
          but the rest of Bob's chat session to continue
          unaffected.So it's not just a message routing
          optimisation, there are other resources being
          optimised too (Ann's time).(2) SIP messages are not
          media, sure, but Instant Messages are. Instant
          Messages are not 'user to user signalling' either,
          because they are not signalling - they are a
          communication between the human end-users, not
          between the equipment facilitating that
          communication (which is how I would characterise
          'signalling' here). So perhaps SIP messages should
          not be used to carry Instant Messages - but this is
          a different point entirely....Mark

               -----Original Message-----
               From: Dean Willis
               [mailto:dean.willis@softarmor.com]
               Sent: 18 September 2001 15:46
               To: simple
               Subject: Re: [Simple] Implicit MESSAGE
               sessions revisited
                I agree with #1,sortof. The best (only?)
               justfication for INVITE-bounded message
               sessions is the use of Record-Route to
               allow proxies that don't need to be in the
               route to opt out. This allows the
               SIP-network to be "self optimizing" for
               message routing. However, such SIP paths
               may be necessarily NOT end-to-end. For
               example, putting a SIP UA behind a
               firewall proxy will require that messages
               transit the firewall proxy. This is easily
               accomplished with record-route. Remember,
               all the "signaling privacy" requirements
               like  calling-party-ID and address-hiding
               apply to SIP messages. We already have
               mechanisms to meet those requirements for
               SIP traffic -- reusing them for messages
               is obviously functional. I disagree with
               requirement #2 -- SIP messages are
               inherently NOT media. They are, in effect
               "user to user signaling". This is
               consistent with my earlier position on the
               use of phone input (DTMF) as "user to
               system signaling", not media. --
               Dean

                    ----- Original Message -----
                    From: Mark Watson
                    To: 'Dean Willis' ; Patil
                    Basavaraj (NET/Dallas) ; 'ext
                    Ben Campbell'
                    Cc: simple
                    Sent: Monday, September 17, 2001
                    12:02 PM
                    Subject: RE: [Simple] Implicit
                    MESSAGE sessions revisited
                    Dean,I agree that they're
                    independent. On the first one, I
                    had thought that the idea of IM
                    'sessions' fulfilled two key
                    requirements:1) I want to find
                    my desired called party, and
                    then exchange multiple messages
                    with this personSome of these
                    things which can happen (in the
                    network/UEs) as a SIP message
                    finds the desired end-user may
                    take time/cost money/require
                    user interaction, and I don't
                    want to repeat them once I have
                    found the person I want to chat
                    to. Also, there is no guarantee
                    that repeating the process at a
                    later time will get me to the
                    same end-user. So, I want to be
                    able to do a 'session setup' and
                    then send messages directly to
                    the person I've found.Of course,
                    I could just treat the first
                    message as an implicit session
                    setup, but this seems to be out
                    of fashion.2) I want IM to be
                    just another media that I can
                    negotiate, add & remove from a
                    session etc.Again, I could do
                    something clever with Call IDs
                    to connect a MESSAGE message
                    with a pre-existing session etc.
                    etc., but why should I make an
                    exception for this one kind of
                    media. If I do that, then no
                    capabilities that I have now or
                    invent in the future which are
                    supposed to be 'media type
                    independent', will work for IM,
                    and I will have to be hacking
                    the IM system constantly to keep
                    up.Did you disagree with these
                    requirements, or just with the
                    implementation ?Regards...Mark

                         -----Original
                         Message-----
                         From: Dean Willis
                         [mailto:dean.willis@softarmor.com]

                         Sent: 17 September
                         2001 17:32
                         To: Watson, Mark
                         [MAIFP:EP11:EXCH];
                         Patil Basavaraj
                         (NET/Dallas); 'ext Ben
                         Campbell'
                         Cc: simple
                         Subject: Re: [Simple]
                         Implicit MESSAGE
                         sessions revisited
                         Both, actually. I
                         believe the issues are
                         independent. --
                         Dean

                              -----
                              Original
                              Message
                              -----
                              From: Mark
                              Watson
                              To: 'Dean
                              Willis' ;
                              Patil
                              Basavaraj
                              (NET/Dallas)
                              ; 'ext Ben
                              Campbell'
                              Cc: simple
                              Sent:
                              Monday,
                              September
                              17, 2001
                              9:39 AM
                              Subject: RE:
                              [Simple]
                              Implicit
                              MESSAGE
                              sessions
                              revisited
                               Dean,

                              Do you mean
                              that you
                              don't see
                              the
                              advantage of
                              using INVITE
                              to set up an
                              IM 'session'
                              (indicating
                              this in the
                              SDP), or
                              just that
                              once such a
                              session is
                              set up,
                              there is no
                              need for the
                              'media' to
                              use any
                              different
                              protocol
                              than that
                              used for
                              'paging' ?

                              I think
                              there are a
                              lot of
                              reasons why
                              IM
                              'sessions'
                              set up using
                              INVITE just
                              like any
                              other SIP
                              session,
                              make sense.
                              I don't care
                              much yet
                              what the
                              transport
                              protocol
                              then is for
                              the IMs in
                              the session.

                              Sorry if
                              this is
                              covering old
                              ground.

                              ...Mark



                              >
                              -----Original
                              Message-----

                              > From: Dean
                              Willis
                              [mailto:dean.willis@softarmor.com]

                              > Sent: 15
                              September
                              2001 05:31
                              > To: Patil
                              Basavaraj
                              (NET/Dallas);
                              'ext Ben
                              Campbell'
                              > Cc: simple

                              > Subject:
                              Re: [Simple]
                              Implicit
                              MESSAGE
                              sessions
                              revisited
                              >
                              >
                              >
                              > Just as
                              MESSAGE for
                              sessions has
                              all the
                              wasted
                              overhead of
                              > headers
                              and
                              > routing
                              mechanisms
                              designed to
                              find users
                              and traverse

                              > firewalls
                              (assuming
                              > you think
                              this is a
                              waste), so
                              does BEEP.
                              >
                              > I
                              personally
                              have yet to
                              see the need
                              for message
                              sessions as
                              > a
                              specialized
                              > transport.

                              >
                              > I think
                              "pager"
                              messages
                              carrying a
                              session-ID
                              and sequence
                              number can
                              > provide
                              the same
                              user
                              experience.
                              >
                              > --
                              > dean
                              >
                              >
                              > -----
                              Original
                              Message
                              -----
                              > From:
                              "Patil
                              Basavaraj
                              (NET/Dallas)"
                              

                              > To: "'ext
                              Ben
                              Campbell'"
                              

                              > Cc:
                              

                              > Sent:
                              Friday,
                              September
                              14, 2001
                              1:07 PM
                              > Subject:
                              RE: [Simple]
                              Implicit
                              MESSAGE
                              sessions
                              revisited
                              >
                              >
                              > >
                              > > One of
                              the
                              protocols
                              that has
                              been
                              suggested
                              for use
                              instead of
                              > > MESSAGE
                              is BEEP. Are
                              there any
                              serious
                              concerns *at
                              this time*
                              > > why BEEP
                              would not be
                              good eniugh
                              for IM
                              Sessions?
                              > >
                              > >
                              -Basavaraj
                              > >
                              > >
                              > >
                              _______________________________________________

                              > > 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

                              >

--------------A44D2DBE5D7D5D94C6758CEF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




Dean - there probably is no point in continuing this debate because it
is going nowhere. I think you are trying to reinvent the wheel, but I presume
you feel otherwise.

    Paul

-------- Original Message --------




Subject: 

Re: Re: [Simple] Implicit MESSAGE sessions revisited]





Date: 

Fri, 21 Sep 2001 10:34:55 -0500





From: 

"Dean Willis" <dean.willis@softarmor.com>





To: 

"Paul Kyzivat" <pkyzivat@cisco.com>,"simple" <simple@mailman.dynamicsoft.com>





References: 

<3BA9173D.D6C1E73A@cisco.com>






 Response: 1)
Bob's IM client responds to the address indicated in the "From:" field
of the received message.2)
Ann creates a new "paging conference session", understood only on her system
which is doing the mixing/replicating. The message to Bob has a "From:"
of "ann" and ann's application handles the replicating to Joe. --

Dean 



----- Original Message -----





To: simple



Sent: Wednesday, September 19, 2001
5:07 PM



Subject: [Fwd: Re: [Simple] Implicit
MESSAGE sessions revisited]

 Dean,

> Joe sends a message to Ann.> Ann
forwards to Bob.> Bob replies to Joe. This reply carries the sessionID
from Joe's original message.> Joe's app realizes his session is now with
Bob and sends further messages in the session to Bob.> Joe and Bob exchange
many messages in this session.> Ann has a life.

Bunch of problems with this scenario:

1) how does Bob reply to Joe? Does
Bob's IM client offer a reply function that extracts Joe's address? Or
does Bob manually initiate a new IM session with Bob?

If the former, then clearly the IM
protocol must have a more or less complete call control mechanism of its
own, duplicating what is in SIP.

If the latter, then how does the sessionID
get into the reply? Presumably Bob would have to type it in. Not likely
in the real world.

2) How is this case distinguished from
one where Ann wants to conference Bob in? Ann may be acting as a local
mixer, passing Joe's messages on to Bob after reading them. In your scenario,
this would look exactly the same to Bob, but the action he should take
is different - he should reply to Ann, so that she can see the reply and
relay it back to Joe.

Your proposed solution can't deal with
the multiple possibilities. There are many useful topologies that can be
established using SIP. Do you propose to have SIMPLE reinvent all of them
independently?

    Paul

-------- Original Message --------







Subject: 

Re: [Simple] Implicit MESSAGE sessions revisited





Date: 

Wed, 19 Sep 2001 14:29:34 -0500





From: 

"Dean Willis" <dean.willis@softarmor.com>





To: 

"Mark Watson" <mwatson@nortelnetworks.com>,"simple" <simple@mailman.dynamicsoft.com>





References: 

<A3C2399B2FACD411A54200508BE39C7402E845BB@zwcwd00r.europe.nortel.com>







 Assume page-mode messages
have a "sessionID" in their payload. Joe
sends a message to Ann.Ann forwards to Bob.Bob replies to Joe. This reply
carries the sessionID from Joe's original message.Joe's app realizes his
session is now with Bob and sends further messages in the session to Bob.Joe
and Bob exchange many messages in this session.Ann has a life.
-_

Dean



----- Original Message -----







Sent: Tuesday, September 18, 2001
12:59 PM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

(1),
it's not just a question of optimising the message routing, it's also that
in routing the initial INVITE I may use up certain resources or require
user intervention, and I don't want to repeat all that for every message
in the 'chat session'.

For example,
Ann has all incoming sessions presented to their SIP client but can hit
a key to forward them to her assistant Bob. If it's an IM chat session,
and Bob gets into a long conversation, Ann does not want to see every message,
and have to hit a key to forward it.Anns
client could forward 'subsequent' messages automatically, but then Ann's
client is implicitly taking on a notion of a 'session' and we are into
the implicit session setup debate again - how does it detect when this
session has ended and a new one started ? What happens if Ann turns her
client off before Bob has finished chatting ? Ann could instruct her proxy
to forwared SIP requests to Bob, but perhaps she doesn't want to. Perhaps
she wants new calls to go to her mobile, but the rest of Bob's chat session
to continue unaffected.So
it's not just a message routing optimisation, there are other resources
being optimised too (Ann's time).(2)
SIP messages are not media, sure, but Instant Messages are. Instant Messages
are not 'user to user signalling' either, because they are not signalling
- they are a communication between the human end-users, not between the
equipment facilitating that communication (which is how I would characterise
'signalling' here). So perhaps SIP messages should not be used to carry
Instant Messages - but this is a different point entirely....Mark



-----Original
Message-----

From: Dean Willis [mailto:dean.willis@softarmor.com]

Sent: 18 September 2001 15:46

To: simple

Subject: Re: [Simple] Implicit
MESSAGE sessions revisited

 I agree with #1,sortof. The best
(only?) justfication for INVITE-bounded message sessions is the use of
Record-Route to allow proxies that don't need to be in the route to opt
out. This allows the SIP-network to be "self optimizing" for message routing.
However, such SIP paths may be necessarily NOT end-to-end. For example,
putting a SIP UA behind a firewall proxy will require that messages transit
the firewall proxy. This is easily accomplished with record-route. Remember,
all the "signaling privacy" requirements like  calling-party-ID and
address-hiding apply to SIP messages. We already have mechanisms to meet
those requirements for SIP traffic -- reusing them for messages is obviously
functional. I disagree with
requirement #2 -- SIP messages are inherently NOT media. They are, in effect
"user to user signaling". This is consistent with my earlier position on
the use of phone input (DTMF) as "user to system signaling", not media.
--

Dean



----- Original Message -----







Cc: simple



Sent: Monday, September 17, 2001 12:02
PM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

Dean,I
agree that they're independent. On the first one, I had thought that the
idea of IM 'sessions' fulfilled two key requirements:1)
I want to find my desired called party, and then exchange multiple messages
with this personSome
of these things which can happen (in the network/UEs) as a SIP message
finds the desired end-user may take time/cost money/require user interaction,
and I don't want to repeat them once I have found the person I want to
chat to. Also, there is no guarantee that repeating the process at a later
time will get me to the same end-user. So, I want to be able to do a 'session
setup' and then send messages directly to the person I've found.Of
course, I could just treat the first message as an implicit session setup,
but this seems to be out of fashion.2)
I want IM to be just another media that I can negotiate, add & remove
from a session etc.Again,
I could do something clever with Call IDs to connect a MESSAGE message
with a pre-existing session etc. etc., but why should I make an exception
for this one kind of media. If I do that, then no capabilities that I have
now or invent in the future which are supposed to be 'media type independent',
will work for IM, and I will have to be hacking the IM system constantly
to keep up.Did
you disagree with these requirements, or just with the implementation ?Regards...Mark



-----Original
Message-----

From: Dean Willis [mailto:dean.willis@softarmor.com]

Sent: 17 September 2001 17:32

To: Watson, Mark [MAIFP:EP11:EXCH];
Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'

Cc: simple

Subject: Re: [Simple] Implicit
MESSAGE sessions revisited

Both, actually. I believe the issues are
independent. --

Dean



----- Original Message -----







Cc: simple



Sent: Monday, September 17, 2001 9:39
AM



Subject: RE: [Simple] Implicit MESSAGE
sessions revisited

 Dean,

Do you mean that you don't see the advantage of using
INVITE to set up an IM 'session' (indicating this in the SDP), or just
that once such a session is set up, there is no need for the 'media' to
use any different protocol than that used for 'paging' ?

I think there are a lot of reasons why IM 'sessions' set
up using INVITE just like any other SIP session, make sense. I don't care
much yet what the transport protocol then is for the IMs in the session.

Sorry if this is covering old ground.

...Mark

 

 

> -----Original Message-----

> From: Dean Willis [mailto:dean.willis@softarmor.com]

> Sent: 15 September 2001 05:31

> To: Patil Basavaraj (NET/Dallas); 'ext Ben Campbell'

> Cc: simple

> Subject: Re: [Simple] Implicit MESSAGE sessions revisited

>

>

>

> Just as MESSAGE for sessions has all the wasted overhead
of

> headers and

> routing mechanisms designed to find users and traverse

> firewalls (assuming

> you think this is a waste), so does BEEP.

>

> I personally have yet to see the need for message sessions
as

> a specialized

> transport.

>

> I think "pager" messages carrying a session-ID and
sequence number can

> provide the same user experience.

>

> --

> dean

>

>

> ----- Original Message -----

> From: "Patil Basavaraj (NET/Dallas)" <Basavaraj.Patil@nokia.com>

> To: "'ext Ben Campbell'" <bcampbell@dynamicsoft.com>

> Cc: <simple@mailman.dynamicsoft.com>

> Sent: Friday, September 14, 2001 1:07 PM

> Subject: RE: [Simple] Implicit MESSAGE sessions revisited

>

>

> >

> > One of the protocols that has been suggested for
use instead of

> > MESSAGE is BEEP. Are there any serious concerns *at
this time*

> > why BEEP would not be good eniugh for IM Sessions?

> >

> > -Basavaraj

> >

> >

> > _______________________________________________

> > 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

>















--------------A44D2DBE5D7D5D94C6758CEF--


From sean.olson@ericsson.com  Fri Sep 21 12:13:25 2001
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 MAA20485
	for ; Fri, 21 Sep 2001 12:13:23 -0400 (EDT)
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 f8LGDF709052
	for ; Fri, 21 Sep 2001 11:13:15 -0500 (CDT)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f8LGDEe09255
	for ; Fri, 21 Sep 2001 11:13:14 -0500 (CDT)
Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Sep 21 11:13:12 2001 -0500
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 11:13:12 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Jonathan Rosenberg'" ,
        "'Avshalom@ubique.com'" 
Cc: "Adam Roach (E-mail)" ,
        "'Robert Brown'"
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?
Date: Fri, 21 Sep 2001 11:13:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C142B8.4F27D230"
Content-Length: 5227
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: 

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_01C142B8.4F27D230
Content-Type: text/plain;
	charset="iso-8859-1"

Yea!
/sean

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>Sent: Friday, September 21, 2001 10:27 AM
>To: Sean Olson; 'Avshalom@ubique.com'; Jonathan Rosenberg
>Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com
>Subject: RE: [Simple] Partial Notifies?
>
>
>I think we should proceed with the presence spec as is, and 
>instead work on
>the partial notifies as an extension. There is still a lot 
>more work that
>needs to happen for partial notifies, as there are lots of 
>ways to do it,
>and they require real investigation. I think we have some time 
>until this
>becomes a dire need as well. 
>
>I will add some text to the presence spec, though, which mentions that
>extensions or new sub-packages can support partial notifies, just as a
>placeholder.
>
>
>OK? Please speak up with a yea or nay so we can have a real 
>decision and
>move on.
>
>-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_01C142B8.4F27D230
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Partial Notifies?




Yea!

/sean




>-----Original Message-----

>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

>Sent: Friday, September 21, 2001 10:27 AM

>To: Sean Olson; 'Avshalom@ubique.com'; Jonathan =
Rosenberg

>Cc: Adam Roach (E-mail); 'Robert Brown'; =
simple@mailman.dynamicsoft.com

>Subject: RE: [Simple] Partial Notifies?

>

>

>I think we should proceed with the presence spec =
as is, and 

>instead work on

>the partial notifies as an extension. There is =
still a lot 

>more work that

>needs to happen for partial notifies, as there =
are lots of 

>ways to do it,

>and they require real investigation. I think we =
have some time 

>until this

>becomes a dire need as well. 

>

>I will add some text to the presence spec, =
though, which mentions that

>extensions or new sub-packages can support =
partial notifies, just as a

>placeholder.

>

>

>OK? Please speak up with a yea or nay so we can =
have a real 

>decision and

>move on.

>

>-Jonathan R.

>

>---

>Jonathan D. Rosenberg, =
Ph.D.           &=
nbsp;    72 Eagle Rock Ave.

>Chief =
Scientist          &nb=
sp;           &nb=
sp;      First Floor

>dynamicsoft        =
            =
            =
 East Hanover, NJ 07936

>jdrosen@dynamicsoft.com      =
            =
   FAX:   (973) 952-5050

>http://www.jdrosen.net    &nbs=
p;           &nbs=
p;     PHONE: (973) 952-5000

>http://www.dynamicsoft.com

>  





------_=_NextPart_001_01C142B8.4F27D230--

From rsparks@dynamicsoft.com  Fri Sep 21 12:20:39 2001
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 MAA20543
	for ; Fri, 21 Sep 2001 12:20:39 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8LGJY8P023539;
	Fri, 21 Sep 2001 12:19:34 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 12:20:33 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E608@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: Jonathan Rosenberg ,
        "'Patil Basavaraj (NET/Dallas)'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
Date: Fri, 21 Sep 2001 12:20:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3798
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: 

Here's an alternate proposal.

The concept of filter is vague, and the default filter
written in this document is presuming that all future
presence documents will be tuple based (probably not
a wrong assumption, but an assumption non-the-less).
I suspect that the form of filters will depend on the
form of the presence documents.

I propose that the default filter is the identity function
(i.e. filter nothing), and control oversized additional
markup through other mechanisms until the filter concept
is made more concrete.

RjS

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, September 20, 2001 11:33 PM
> To: 'Patil Basavaraj (NET/Dallas)'; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Patil Basavaraj (NET/Dallas) 
> [mailto:Basavaraj.Patil@nokia.com]
> > Sent: Thursday, September 20, 2001 3:35 PM
> > To: 'ext Jonathan Rosenberg'; simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
> > 
> > 
> > >> 
> > >> 
> > >> Non-critical issue:
> > >> 
> > >> Section 5.3 (Paragraph 3) defines a default filter. However
> > >> I do not see the need for bullet 3 wherein additional markup
> > >> is sent (if < 50 bytes). It is better to have a consistent 
> > mechanism
> > >> of sending any markup (irrespective of size) only if explicitly
> > >> requested
> > >> by the subscriber or just send all the markup as the default. 
> > >
> > >The problem is that in rfc2778, "additional markup" can be almost
> > anything.
> > >Always sending it might imply, down the road, sending huge 
> jpeg files
> > with
> > >pictures of the user. I'm not sure you want that to be the default.
> > >
> > 
> > I agree. I was leaning towards not sending anything being 
> the default.
> 
> I would also be fine for that, except for the technicality that in the
> cpim-pidf format, the note element would then not be sent by default.
> 
> > 
> > >Never sending it also has problems. Looking at
> > draft-ietf-impp-cpim-pidf,
> > >this would mean that the "note" element would never be sent unless
> > >explicitly requested, since it is neither status or contact
> > information. I
> > >suspect the note will be used often, and I want to make sure its
> > included in
> > >the normal case. 
> > >
> > >So, I put this middle-ground sentence in to make sure that 
> the small
> > stuff
> > >goes, and the bigger stuff needs to be requested.
> > >
> > 
> > It just does not seem to be a consistent way for doing things. So
> > while today it may be "note" that is useful to be carried in the
> > NOTIFY, there may be an other parameter that someone else might deem
> > important enough to be carried in the NOTIFY. Maybe there 
> needs to be
> > a set of parameters that can be agreed upon as ones that 
> pass through
> > the default filter irrespective of size.
> 
> The problem is that I don't want the spec to be specific to 
> cpim-pidf as a
> data format. If it did, I could simply say "send the note, but not
> extensions", and we would be done. But, rfc2778 is more 
> generic, and its all
> clumped together.
> 
> I would welcome an alternate proposal.
> 
> -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 jdrosen@dynamicsoft.com  Fri Sep 21 13:05:33 2001
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 NAA20718
	for ; Fri, 21 Sep 2001 13:05:32 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8LH4R8P023923;
	Fri, 21 Sep 2001 13:04:27 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 13:05:27 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Robert Sparks ,
        "'Patil Basavaraj (NET/Dallas)'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
Date: Fri, 21 Sep 2001 13:05:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4732
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: 

Actually, I like that better since its less arbitrary.

Let us go with that.

-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 
> Sent: Friday, September 21, 2001 12:21 PM
> To: Jonathan Rosenberg; 'Patil Basavaraj (NET/Dallas)';
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
> 
> 
> Here's an alternate proposal.
> 
> The concept of filter is vague, and the default filter
> written in this document is presuming that all future
> presence documents will be tuple based (probably not
> a wrong assumption, but an assumption non-the-less).
> I suspect that the form of filters will depend on the
> form of the presence documents.
> 
> I propose that the default filter is the identity function
> (i.e. filter nothing), and control oversized additional
> markup through other mechanisms until the filter concept
> is made more concrete.
> 
> RjS
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Thursday, September 20, 2001 11:33 PM
> > To: 'Patil Basavaraj (NET/Dallas)'; simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
> > 
> > 
> > 
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Patil Basavaraj (NET/Dallas) 
> > [mailto:Basavaraj.Patil@nokia.com]
> > > Sent: Thursday, September 20, 2001 3:35 PM
> > > To: 'ext Jonathan Rosenberg'; simple@mailman.dynamicsoft.com
> > > Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
> > > 
> > > 
> > > >> 
> > > >> 
> > > >> Non-critical issue:
> > > >> 
> > > >> Section 5.3 (Paragraph 3) defines a default filter. However
> > > >> I do not see the need for bullet 3 wherein additional markup
> > > >> is sent (if < 50 bytes). It is better to have a consistent 
> > > mechanism
> > > >> of sending any markup (irrespective of size) only if explicitly
> > > >> requested
> > > >> by the subscriber or just send all the markup as the default. 
> > > >
> > > >The problem is that in rfc2778, "additional markup" can be almost
> > > anything.
> > > >Always sending it might imply, down the road, sending huge 
> > jpeg files
> > > with
> > > >pictures of the user. I'm not sure you want that to be 
> the default.
> > > >
> > > 
> > > I agree. I was leaning towards not sending anything being 
> > the default.
> > 
> > I would also be fine for that, except for the technicality 
> that in the
> > cpim-pidf format, the note element would then not be sent 
> by default.
> > 
> > > 
> > > >Never sending it also has problems. Looking at
> > > draft-ietf-impp-cpim-pidf,
> > > >this would mean that the "note" element would never be 
> sent unless
> > > >explicitly requested, since it is neither status or contact
> > > information. I
> > > >suspect the note will be used often, and I want to make sure its
> > > included in
> > > >the normal case. 
> > > >
> > > >So, I put this middle-ground sentence in to make sure that 
> > the small
> > > stuff
> > > >goes, and the bigger stuff needs to be requested.
> > > >
> > > 
> > > It just does not seem to be a consistent way for doing things. So
> > > while today it may be "note" that is useful to be carried in the
> > > NOTIFY, there may be an other parameter that someone else 
> might deem
> > > important enough to be carried in the NOTIFY. Maybe there 
> > needs to be
> > > a set of parameters that can be agreed upon as ones that 
> > pass through
> > > the default filter irrespective of size.
> > 
> > The problem is that I don't want the spec to be specific to 
> > cpim-pidf as a
> > data format. If it did, I could simply say "send the note, but not
> > extensions", and we would be done. But, rfc2778 is more 
> > generic, and its all
> > clumped together.
> > 
> > I would welcome an alternate proposal.
> > 
> > -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 c-Dai.Ngo@WCOM.Com  Fri Sep 21 13:59:22 2001
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20916
	for ; Fri, 21 Sep 2001 13:59:21 -0400 (EDT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.wcom.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GK000H4VXYIAB@firewall.wcom.com> for
 simple@mailman.dynamicsoft.com; Fri, 21 Sep 2001 17:59:06 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0GK000J01XWN6H@pmismtp02.wcomnet.com> for
 simple@mailman.dynamicsoft.com; Fri, 21 Sep 2001 17:59:06 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0GK000I4KXWJXH@pmismtp02.wcomnet.com> for
 simple@mailman.dynamicsoft.com; Fri, 21 Sep 2001 17:57:56 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 17:57:55 +0000
Content-return: allowed
Date: Fri, 21 Sep 2001 16:33:46 +0000
From: "Ngo, Dai (c)" 
Subject: RE: [Simple] Partial Notifies?
To: simple@mailman.dynamicsoft.com
Message-id: <492EB4A3F68CD411ABE800508B69362E6C4E0A@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_U2SbuN2PKQTRLgsC7N2vlA)"
Content-Length: 32394
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: 

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_U2SbuN2PKQTRLgsC7N2vlA)
Content-type: text/plain; charset=ISO-8859-1

Yes, I agree.

-- Dai

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, September 21, 2001 10:27 AM
To: Sean Olson; 'Avshalom@ubique.com'; Jonathan Rosenberg
Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?


I think we should proceed with the presence spec as is, and instead work on
the partial notifies as an extension. There is still a lot more work that
needs to happen for partial notifies, as there are lots of ways to do it,
and they require real investigation. I think we have some time until this
becomes a dire need as well. 

I will add some text to the presence spec, though, which mentions that
extensions or new sub-packages can support partial notifies, just as a
placeholder.


OK? Please speak up with a yea or nay so we can have a real decision and
move on.

-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: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, September 21, 2001 11:06 AM
To: 'Avshalom@ubique.com'; Jonathan Rosenberg
Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?


I would like some clarification on how 
this would be documented (separate I-D?) and 
on whether or not this is mandatory to support 
in the client / server. (I assume not) 
Thanks, 
Sean Olson 
Ericsson Inc. 
>-----Original Message----- 
>From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] 
>Sent: Friday, September 21, 2001 10:00 AM 
>To: Jonathan Rosenberg 
>Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com 
>Subject: RE: [Simple] Partial Notifies? 
> 
> 
> 
>Is the partial silence can be considered as a consensus given 
>that the wglc 
>is today? 
> 
>avshalom 
>Sametime/Lotus/IBM 
> 
> 
> 
>                                                               
>                                                      
>                    Jonathan                                   
>                                                      
>                    Rosenberg              To:     "'Robert 
>Brown'" , Avshalom Houri          
>                    , simple@mailman.dynamicsoft.com          
>           
>                    csoft.com>             cc:     "Adam Roach 
>(E-mail)"                    
>                                           Subject:     RE: 
>[Simple] Partial Notifies?                               
>                    18/09/2001                                 
>                                                      
>                    14:58                                      
>                                                      
>                                                               
>                                                      
>                                                               
>                                                      
> 
> 
> 
> 
>This thread fell on the floor, but its a real important one 
>and I want to 
>get it going again. Its probably the biggest open issue for 
>the presence 
>spec, which is currently in wglc, so addressing it is really a higher 
>priority than the IM session discussion. 
> 
>I think that partial updates is probably a really good thing. 
>I'd like to 
>make sure it is adequately supported in the right way. 
> 
>Now, the question is, where does such support belong? Is it a 
>per-package 
>thing? Or is it something in the sip-events framework? I would 
>argue that 
>each package be able to define whether it does or doesn't use partial 
>notifies, but that the mechanism for doing them be shared across all 
>packages. For example, if we add a header like 
>Last-Data-Received: with a 
>hash of the body, as Dror had proposed, I think this header 
>belongs in the 
>sip-events specification. 
> 
>I believe the requirements for the partial notifications are 
>the following: 
> 
>1. the subscribe request have a way for the subscriber to indicate what 
>version they have, so that the notify only contain a delta from that 
>version 
>(indeed, perhaps the notify isn't even sent if the version the 
>subscriber 
>has is up to date) 
> 
>2. the notify have a way to indicate what version of the document the 
>subscriber will have once the patch is applied 
> 
>3. the notify have a way to indicate what version the of the 
>document the 
>subscriber has to apply the patch against (i.e, the old version) 
> 
>4. the "patch" be in a format that is independent of the format of the 
>presence document. 
> 
> 
>Number 4 is important, I think, to avoid needing to specify updates and 
>partial notifies within every event document format. We just 
>do it once, 
>and 
>then each event package doesn't need to ever worry about it again. 
> 
>Anders Kristensen had pointed out to me that webdav has looked 
>at a very 
>similar problem, and that there are specs for deltas within 
>http. I haven't 
>looked at those in detail, but they might provide a solution 
>for us that 
>would allow us to reuse existing work elsewhere in IETF. 
> 
>So, the quesitons to be discussed, in order, are: 
> 
>1. is there consensus that we should have a solution for 
>partial notifies 
>in 
>simple? 
> 
>2. is there consensus that this should be done in a general 
>fashion as part 
>of the sip events specification? 
> 
>3. how should it be done? 
> 
>Comments? 
> 
>-Jonathan R. 
> 
> 
> 
>> -----Original Message----- 
>> From: Robert Brown [mailto:roberbr@microsoft.com] 
>> Sent: Wednesday, September 05, 2001 4:41 PM 
>> To: Avshalom Houri; simple@mailman.dynamicsoft.com 
>> Subject: Re: [Simple] Partial Notifies? 
>> 
>> 
>> Watcher info can become pretty big too.  It would be nice to receive 
>> partials that only contained new pending watchers. 
>> 
>> ----- Original Message ----- 
>> From: "Avshalom Houri"  
>> To:  
>> Sent: Wednesday, September 05, 2001 4:33 AM 
>> Subject: RE: [Simple] Partial Notifies? 
>> 
>> 
>> > > I was actually debating this issue when doing the update 
>> of the presence 
>> > 
>> > > spec. Its not specified right now, all through the events 
>> framework 
>> allows 
>> > 
>> > > each package to define how its done. 
>> > 
>> > I think that it should be included since NOTIFY can become 
>> big especially 
>> > given 
>> > 
>> > detail/schema/human readable comment. 
>> > 
>> > > 
>> > 
>> > > One model to do this is something I have proposed for 
>> other packages: 
>> > 
>> > > 
>> > 
>> > > 1. the notify triggered by a subscribe contains the full state 
>> > 
>> > > 2. subsequent notifies contain only the piece thats 
>> changed (i.e., the 
>> > 
>> > > contact address that is different) 
>> > 
>> > > 3. the subscriber keeps track of the cseq to see if it 
>> may have missed a 
>> > 
>> > > notify. If there are no gaps in Cseq, nothing was missed. 
>> If there is a 
>> > gap, 
>> > 
>> > > something may have been missed, or else there was an intermediate 
>> > challenge 
>> > 
>> > > or something like that. So, the subscriber re-subscribes to get a 
>> > triggered 
>> > 
>> > > notify with full state. 
>> > 
>> > I assume that the granularity will be a single tuple of the 
>> presence, and 
>> > that 
>> > 
>> > there will be an operator preceding the tuple for 
>add/delete/update. 
>> > 
>> > > 
>> > 
>> > > A better way to handle the ordering is for the presence 
>> document itself 
>> to 
>> > 
>> > > contain version numbers, but that would require changes 
>> in the pidf 
>> spec. 
>> > 
>> > > 
>> > 
>> > > Since the initial SUBSCRIBE has to trigger full state anyway, 
>> idempotency 
>> > of 
>> > 
>> > > SUBSCRIBE would argue for having full state triggered notify for 
>> refreshes 
>> > 
>> > > too. 
>> > 
>> > It seems that Dror's suggestion (dror@vocaltec.com) can be 
>> helpful here. 
>> > 
>> > avshalom 
>> > 
>> > Sametime/Lotus/IBM 
>> > 
>> > 
>> > 
> 
> 
> 
> 
>_______________________________________________ 
>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

--Boundary_(ID_U2SbuN2PKQTRLgsC7N2vlA)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable






RE: [Simple] Partial Notifies?




Yes, I agree.




-- Dai




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Friday, September 21, 2001 10:27 AM

To: Sean Olson; 'Avshalom@ubique.com'; Jonathan =
Rosenberg

Cc: Adam Roach (E-mail); 'Robert Brown'; =
simple@mailman.dynamicsoft.com

Subject: RE: [Simple] Partial Notifies?






I think we should proceed with the presence spec as =
is, and instead work on

the partial notifies as an extension. There is still =
a lot more work that

needs to happen for partial notifies, as there are =
lots of ways to do it,

and they require real investigation. I think we have =
some time until this

becomes a dire need as well. 




I will add some text to the presence spec, though, =
which mentions that

extensions or new sub-packages can support partial =
notifies, just as a

placeholder.






OK? Please speak up with a yea or nay so we can have =
a real decision and

move on.




-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: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]

Sent: Friday, September 21, 2001 11:06 AM

To: 'Avshalom@ubique.com'; Jonathan Rosenberg

Cc: Adam Roach (E-mail); 'Robert Brown'; =
simple@mailman.dynamicsoft.com

Subject: RE: [Simple] Partial Notifies?






I would like some clarification on how 

this would be documented (separate I-D?) and 

on whether or not this is mandatory to support =


in the client / server. (I assume not) 

Thanks, 

Sean Olson 

Ericsson Inc. 

>-----Original Message----- 

>From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] =


>Sent: Friday, September 21, 2001 10:00 AM =


>To: Jonathan Rosenberg 

>Cc: Adam Roach (E-mail); 'Robert Brown'; =
simple@mailman.dynamicsoft.com 

>Subject: RE: [Simple] Partial Notifies? 

> 

> 

> 

>Is the partial silence can be considered as a =
consensus given 

>that the wglc 

>is today? 

> 

>avshalom 

>Sametime/Lotus/IBM 

> 

> 

> 

>          =
;            =
;            =
;            =
;            =
;     

>          =
;            =
;            =
;            =
;        

>          =
;          =
Jonathan          &nbs=
p;           &nbs=
p;            =


>          =
;            =
;            =
;            =
;        

>          =
;          =
Rosenberg          &nb=
sp;   To:     "'Robert 

>Brown'" <roberbr@microsoft.com>, =
Avshalom Houri          =


>          =
;          =
<jdrosen@dynami        

><avshalom@ubique.com>, =
simple@mailman.dynamicsoft.com       =
   

>          =
; 

>          =
;          =
csoft.com>          =
;   cc:     "Adam Roach 

>(E-mail)" =
<adam.roach@ericsson.com>       =
;            =


>          =
;            =
;            =
;         =
Subject:     RE: 

>[Simple] Partial =
Notifies?          &nb=
sp;           &nb=
sp;        

>          =
;          =
18/09/2001          &n=
bsp;           &n=
bsp;          

>          =
;            =
;            =
;            =
;        

>          =
;          =
14:58           &=
nbsp;           &=
nbsp;           &=
nbsp;  

>          =
;            =
;            =
;            =
;        

>          =
;            =
;            =
;            =
;            =
;     

>          =
;            =
;            =
;            =
;        

>          =
;            =
;            =
;            =
;            =
;     

>          =
;            =
;            =
;            =
;        

> 

> 

> 

> 

>This thread fell on the floor, but its a real =
important one 

>and I want to 

>get it going again. Its probably the biggest =
open issue for 

>the presence 

>spec, which is currently in wglc, so addressing =
it is really a higher 

>priority than the IM session discussion. 

> 

>I think that partial updates is probably a =
really good thing. 

>I'd like to 

>make sure it is adequately supported in the =
right way. 

> 

>Now, the question is, where does such support =
belong? Is it a 

>per-package 

>thing? Or is it something in the sip-events =
framework? I would 

>argue that 

>each package be able to define whether it does =
or doesn't use partial 

>notifies, but that the mechanism for doing them =
be shared across all 

>packages. For example, if we add a header like =


>Last-Data-Received: with a 

>hash of the body, as Dror had proposed, I think =
this header 

>belongs in the 

>sip-events specification. 

> 

>I believe the requirements for the partial =
notifications are 

>the following: 

> 

>1. the subscribe request have a way for the =
subscriber to indicate what 

>version they have, so that the notify only =
contain a delta from that 

>version 

>(indeed, perhaps the notify isn't even sent if =
the version the 

>subscriber 

>has is up to date) 

> 

>2. the notify have a way to indicate what =
version of the document the 

>subscriber will have once the patch is applied =


> 

>3. the notify have a way to indicate what =
version the of the 

>document the 

>subscriber has to apply the patch against (i.e, =
the old version) 

> 

>4. the "patch" be in a format that is =
independent of the format of the 

>presence document. 

> 

> 

>Number 4 is important, I think, to avoid needing =
to specify updates and 

>partial notifies within every event document =
format. We just 

>do it once, 

>and 

>then each event package doesn't need to ever =
worry about it again. 

> 

>Anders Kristensen had pointed out to me that =
webdav has looked 

>at a very 

>similar problem, and that there are specs for =
deltas within 

>http. I haven't 

>looked at those in detail, but they might =
provide a solution 

>for us that 

>would allow us to reuse existing work elsewhere =
in IETF. 

> 

>So, the quesitons to be discussed, in order, =
are: 

> 

>1. is there consensus that we should have a =
solution for 

>partial notifies 

>in 

>simple? 

> 

>2. is there consensus that this should be done =
in a general 

>fashion as part 

>of the sip events specification? 

> 

>3. how should it be done? 

> 

>Comments? 

> 

>-Jonathan R. 

> 

> 

> 

>> -----Original Message----- 

>> From: Robert Brown [mailto:roberbr@microsoft.com] 

>> Sent: Wednesday, September 05, 2001 4:41 PM =


>> To: Avshalom Houri; =
simple@mailman.dynamicsoft.com 

>> Subject: Re: [Simple] Partial Notifies? =


>> 

>> 

>> Watcher info can become pretty big =
too.  It would be nice to receive 

>> partials that only contained new pending =
watchers. 

>> 

>> ----- Original Message ----- 

>> From: "Avshalom Houri" =
<avshalom@ubique.com> 

>> To: <simple@mailman.dynamicsoft.com> =


>> Sent: Wednesday, September 05, 2001 4:33 AM =


>> Subject: RE: [Simple] Partial Notifies? =


>> 

>> 

>> > > I was actually debating this =
issue when doing the update 

>> of the presence 

>> > 

>> > > spec. Its not specified right =
now, all through the events 

>> framework 

>> allows 

>> > 

>> > > each package to define how its =
done. 

>> > 

>> > I think that it should be included =
since NOTIFY can become 

>> big especially 

>> > given 

>> > 

>> > detail/schema/human readable comment. =


>> > 

>> > > 

>> > 

>> > > One model to do this is something =
I have proposed for 

>> other packages: 

>> > 

>> > > 

>> > 

>> > > 1. the notify triggered by a =
subscribe contains the full state 

>> > 

>> > > 2. subsequent notifies contain =
only the piece thats 

>> changed (i.e., the 

>> > 

>> > > contact address that is =
different) 

>> > 

>> > > 3. the subscriber keeps track of =
the cseq to see if it 

>> may have missed a 

>> > 

>> > > notify. If there are no gaps in =
Cseq, nothing was missed. 

>> If there is a 

>> > gap, 

>> > 

>> > > something may have been missed, =
or else there was an intermediate 

>> > challenge 

>> > 

>> > > or something like that. So, the =
subscriber re-subscribes to get a 

>> > triggered 

>> > 

>> > > notify with full state. 

>> > 

>> > I assume that the granularity will be =
a single tuple of the 

>> presence, and 

>> > that 

>> > 

>> > there will be an operator preceding =
the tuple for 

>add/delete/update. 

>> > 

>> > > 

>> > 

>> > > A better way to handle the =
ordering is for the presence 

>> document itself 

>> to 

>> > 

>> > > contain version numbers, but that =
would require changes 

>> in the pidf 

>> spec. 

>> > 

>> > > 

>> > 

>> > > Since the initial SUBSCRIBE has =
to trigger full state anyway, 

>> idempotency 

>> > of 

>> > 

>> > > SUBSCRIBE would argue for having =
full state triggered notify for 

>> refreshes 

>> > 

>> > > too. 

>> > 

>> > It seems that Dror's suggestion =
(dror@vocaltec.com) can be 

>> helpful here. 

>> > 

>> > avshalom 

>> > 

>> > Sametime/Lotus/IBM 

>> > 

>> > 

>> > 

> 

> 

> 

> 

>_______________________________________________ =


>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=







--Boundary_(ID_U2SbuN2PKQTRLgsC7N2vlA)--

From bcampbell@dynamicsoft.com  Fri Sep 21 16:50:56 2001
Received: from localhost.localdomain ([63.110.3.192])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21474
	for ; Fri, 21 Sep 2001 16:50:55 -0400 (EDT)
Received: from dynamicsoft.com (Avalon2 [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f8LKlaX08966;
	Fri, 21 Sep 2001 15:47:37 -0500
Message-ID: <3BABA768.7000102@dynamicsoft.com>
Date: Fri, 21 Sep 2001 15:47:36 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: "'simple@mailman.dynamicsoft.com'" ,
        jdrosen2 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1477
Subject: [Simple] presence-02 comments
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: 

A few comments, mostly nits. Apologies if these repeat comments from 
others(If so, I claim senility):

Section 2:

PUA definition (nit) definition states a PUA sends REGISTERS. Since this 
islikely to change with a new publication method we might should drop 
the phrase.

PA definition says "Typically colocated with proxy/registrar" This is a 
possible configuration, but not necessarily typical.

5.3: reads: "In general, subscriptions will normally
    not contain bodies. The request URI, which identifies the presentity,
    combined with the event package name, are sufficient for user
    presence."

suggested (remove redundant "In general" and fix singular/plural 
mismatch: "Subscriptions will normally not contain bodies. The request 
URI, which identifies the presentity,combined with the event package 
name, is sufficient for user presence."

5.4: Language appears to say that presence only gets changed by
one of the example events.

p7 paragraph2: I thought we were removing "polite blocking" as an 
explicitly required feature. In any case, I would not consider it part 
of the minimum allowed set of authorization decisions.

5.10: Forking (NIT): text mentions that each PA responds with 202 response.
Should be 2xx class response, since 200's are also allowed.

6.4: Call state subscription: While I assume this is non-normative,
I am afraid its presence will confuse people.

7.3: Refers to PGP authentication in SIP. Hasn't that been removed from
SIP?



From bcampbell@dynamicsoft.com  Fri Sep 21 16:55:42 2001
Received: from localhost.localdomain ([63.110.3.192])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21509
	for ; Fri, 21 Sep 2001 16:55:42 -0400 (EDT)
Received: from dynamicsoft.com (Avalon2 [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f8LKqRX08973;
	Fri, 21 Sep 2001 15:52:27 -0500
Message-ID: <3BABA88A.1070304@dynamicsoft.com>
Date: Fri, 21 Sep 2001 15:52:26 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com, jdrosen 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1529
Subject: [Simple] presence-02 comments
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: 

Oops, first attempt bounced.
--------------------------

A few comments, mostly nits. Apologies if these repeat comments from
others(If so, I claim senility):

Section 2:

PUA definition (nit) definition states a PUA sends REGISTERS. Since this
islikely to change with a new publication method we might should drop
the phrase.

PA definition says "Typically colocated with proxy/registrar" This is a
possible configuration, but not necessarily typical.

5.3: reads: "In general, subscriptions will normally
     not contain bodies. The request URI, which identifies the presentity,
     combined with the event package name, are sufficient for user
     presence."

suggested (remove redundant "In general" and fix singular/plural
mismatch: "Subscriptions will normally not contain bodies. The request
URI, which identifies the presentity,combined with the event package
name, is sufficient for user presence."

5.4: Language appears to say that presence only gets changed by
one of the example events.

p7 paragraph2: I thought we were removing "polite blocking" as an
explicitly required feature. In any case, I would not consider it part
of the minimum allowed set of authorization decisions.

5.10: Forking (NIT): text mentions that each PA responds with 202 response.
Should be 2xx class response, since 200's are also allowed.

6.4: Call state subscription: While I assume this is non-normative,
I am afraid its presence will confuse people.

7.3: Refers to PGP authentication in SIP. Hasn't that been removed from
SIP?




From Basavaraj.Patil@nokia.com  Fri Sep 21 18:27:11 2001
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 SAA21839
	for ; Fri, 21 Sep 2001 18:27:10 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.americas.nokia.com [172.18.194.217])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8LMPR905838
	for ; Sat, 22 Sep 2001 01:25:27 +0300 (EET DST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8LMRAC12470
	for ; Fri, 21 Sep 2001 17:27:10 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 21 Sep 2001 17:26:59 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 21 Sep 2001 17:26:59 -0500
content-class: urn:content-classes:message
Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
Date: Fri, 21 Sep 2001 17:27:03 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF441E8712@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Comment: draft-ietf-simple-presence-02
x-mimeole: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFCv56OADcOF66xEdWBSwBQi2X+DwALNKZg
From: "Patil Basavaraj (NET/Dallas)" 
To: "'ext Jonathan Rosenberg'" ,
        "Robert Sparks" ,
        
X-OriginalArrivalTime: 21 Sep 2001 22:26:59.0230 (UTC) FILETIME=[8745D3E0:01C142EC]
Content-Length: 4535
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA21839
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: 

> 
> Actually, I like that better since its less arbitrary.
> 
> Let us go with that.
> 
> -Jonathan R.
> 

Better than what is specified in the I-D today. I agree.

-Basavaraj

> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> 
> > 
> > Here's an alternate proposal.
> > 
> > The concept of filter is vague, and the default filter
> > written in this document is presuming that all future
> > presence documents will be tuple based (probably not
> > a wrong assumption, but an assumption non-the-less).
> > I suspect that the form of filters will depend on the
> > form of the presence documents.
> > 
> > I propose that the default filter is the identity function
> > (i.e. filter nothing), and control oversized additional
> > markup through other mechanisms until the filter concept
> > is made more concrete.
> > 
> > RjS
> > 
> > > -----Original Message-----
> > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > > Sent: Thursday, September 20, 2001 11:33 PM
> > > To: 'Patil Basavaraj (NET/Dallas)'; simple@mailman.dynamicsoft.com
> > > Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Patil Basavaraj (NET/Dallas) 
> > > [mailto:Basavaraj.Patil@nokia.com]
> > > > Sent: Thursday, September 20, 2001 3:35 PM
> > > > To: 'ext Jonathan Rosenberg'; simple@mailman.dynamicsoft.com
> > > > Subject: RE: [Simple] Comment: draft-ietf-simple-presence-02
> > > > 
> > > > 
> > > > >> 
> > > > >> 
> > > > >> Non-critical issue:
> > > > >> 
> > > > >> Section 5.3 (Paragraph 3) defines a default filter. However
> > > > >> I do not see the need for bullet 3 wherein additional markup
> > > > >> is sent (if < 50 bytes). It is better to have a consistent 
> > > > mechanism
> > > > >> of sending any markup (irrespective of size) only if 
> explicitly
> > > > >> requested
> > > > >> by the subscriber or just send all the markup as the 
> default. 
> > > > >
> > > > >The problem is that in rfc2778, "additional markup" 
> can be almost
> > > > anything.
> > > > >Always sending it might imply, down the road, sending huge 
> > > jpeg files
> > > > with
> > > > >pictures of the user. I'm not sure you want that to be 
> > the default.
> > > > >
> > > > 
> > > > I agree. I was leaning towards not sending anything being 
> > > the default.
> > > 
> > > I would also be fine for that, except for the technicality 
> > that in the
> > > cpim-pidf format, the note element would then not be sent 
> > by default.
> > > 
> > > > 
> > > > >Never sending it also has problems. Looking at
> > > > draft-ietf-impp-cpim-pidf,
> > > > >this would mean that the "note" element would never be 
> > sent unless
> > > > >explicitly requested, since it is neither status or contact
> > > > information. I
> > > > >suspect the note will be used often, and I want to 
> make sure its
> > > > included in
> > > > >the normal case. 
> > > > >
> > > > >So, I put this middle-ground sentence in to make sure that 
> > > the small
> > > > stuff
> > > > >goes, and the bigger stuff needs to be requested.
> > > > >
> > > > 
> > > > It just does not seem to be a consistent way for doing 
> things. So
> > > > while today it may be "note" that is useful to be carried in the
> > > > NOTIFY, there may be an other parameter that someone else 
> > might deem
> > > > important enough to be carried in the NOTIFY. Maybe there 
> > > needs to be
> > > > a set of parameters that can be agreed upon as ones that 
> > > pass through
> > > > the default filter irrespective of size.
> > > 
> > > The problem is that I don't want the spec to be specific to 
> > > cpim-pidf as a
> > > data format. If it did, I could simply say "send the note, but not
> > > extensions", and we would be done. But, rfc2778 is more 
> > > generic, and its all
> > > clumped together.
> > > 
> > > I would welcome an alternate proposal.
> > > 
> > > -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 Avshalom@ubique.com  Sat Sep 22 13:19:35 2001
Received: from ubqgate02.lotus.com ([194.196.39.50])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25249;
	Sat, 22 Sep 2001 13:19:32 -0400 (EDT)
From: Avshalom@ubique.com
Subject: RE: [Simple] Partial Notifies?
To: Jonathan Rosenberg 
Cc: "Adam Roach (E-mail)" ,
        Jonathan Rosenberg ,
        "'Robert Brown'" ,
        Sean Olson , simple@mailman.dynamicsoft.com,
        simple-admin@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Sat, 22 Sep 2001 20:17:27 +0300
X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at
 22/09/2001 20:18:19
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 8922
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: 

Yes.

avshalom
Sametime/Lotus/IBM



                                                                                                                                
                    Jonathan Rosenberg                                                                                          
                             To:     Sean Olson , "'Avshalom@ubique.com'"     
                    Sent by:                          , Jonathan Rosenberg        
                    simple-admin@mailman.dynam        cc:     "Adam Roach (E-mail)" , "'Robert Brown'" 
                    icsoft.com                        , simple@mailman.dynamicsoft.com                   
                                                      Subject:     RE: [Simple] Partial Notifies?                               
                                                                                                                                
                    21/09/2001 18:26                                                                                            
                                                                                                                                
                                                                                                                                



I think we should proceed with the presence spec as is, and instead work on
the partial notifies as an extension. There is still a lot more work that
needs to happen for partial notifies, as there are lots of ways to do it,
and they require real investigation. I think we have some time until this
becomes a dire need as well.

I will add some text to the presence spec, though, which mentions that
extensions or new sub-packages can support partial notifies, just as a
placeholder.


OK? Please speak up with a yea or nay so we can have a real decision and
move on.

-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: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, September 21, 2001 11:06 AM
To: 'Avshalom@ubique.com'; Jonathan Rosenberg
Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?


I would like some clarification on how
this would be documented (separate I-D?) and
on whether or not this is mandatory to support
in the client / server. (I assume not)
Thanks,
Sean Olson
Ericsson Inc.
>-----Original Message-----
>From: Avshalom@ubique.com [mailto:Avshalom@ubique.com]
>Sent: Friday, September 21, 2001 10:00 AM
>To: Jonathan Rosenberg
>Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com
>Subject: RE: [Simple] Partial Notifies?
>
>
>
>Is the partial silence can be considered as a consensus given
>that the wglc
>is today?
>
>avshalom
>Sametime/Lotus/IBM
>
>
>
>
>
>                    Jonathan
>
>                    Rosenberg              To:     "'Robert
>Brown'" , Avshalom Houri
>                    , simple@mailman.dynamicsoft.com
>
>                    csoft.com>             cc:     "Adam Roach
>(E-mail)" 
>                                           Subject:     RE:
>[Simple] Partial Notifies?
>                    18/09/2001
>
>                    14:58
>
>
>
>
>
>
>
>
>
>This thread fell on the floor, but its a real important one
>and I want to
>get it going again. Its probably the biggest open issue for
>the presence
>spec, which is currently in wglc, so addressing it is really a higher
>priority than the IM session discussion.
>
>I think that partial updates is probably a really good thing.
>I'd like to
>make sure it is adequately supported in the right way.
>
>Now, the question is, where does such support belong? Is it a
>per-package
>thing? Or is it something in the sip-events framework? I would
>argue that
>each package be able to define whether it does or doesn't use partial
>notifies, but that the mechanism for doing them be shared across all
>packages. For example, if we add a header like
>Last-Data-Received: with a
>hash of the body, as Dror had proposed, I think this header
>belongs in the
>sip-events specification.
>
>I believe the requirements for the partial notifications are
>the following:
>
>1. the subscribe request have a way for the subscriber to indicate what
>version they have, so that the notify only contain a delta from that
>version
>(indeed, perhaps the notify isn't even sent if the version the
>subscriber
>has is up to date)
>
>2. the notify have a way to indicate what version of the document the
>subscriber will have once the patch is applied
>
>3. the notify have a way to indicate what version the of the
>document the
>subscriber has to apply the patch against (i.e, the old version)
>
>4. the "patch" be in a format that is independent of the format of the
>presence document.
>
>
>Number 4 is important, I think, to avoid needing to specify updates and
>partial notifies within every event document format. We just
>do it once,
>and
>then each event package doesn't need to ever worry about it again.
>
>Anders Kristensen had pointed out to me that webdav has looked
>at a very
>similar problem, and that there are specs for deltas within
>http. I haven't
>looked at those in detail, but they might provide a solution
>for us that
>would allow us to reuse existing work elsewhere in IETF.
>
>So, the quesitons to be discussed, in order, are:
>
>1. is there consensus that we should have a solution for
>partial notifies
>in
>simple?
>
>2. is there consensus that this should be done in a general
>fashion as part
>of the sip events specification?
>
>3. how should it be done?
>
>Comments?
>
>-Jonathan R.
>
>
>
>> -----Original Message-----
>> From: Robert Brown [mailto:roberbr@microsoft.com]
>> Sent: Wednesday, September 05, 2001 4:41 PM
>> To: Avshalom Houri; simple@mailman.dynamicsoft.com
>> Subject: Re: [Simple] Partial Notifies?
>>
>>
>> Watcher info can become pretty big too.  It would be nice to receive
>> partials that only contained new pending watchers.
>>
>> ----- Original Message -----
>> From: "Avshalom Houri" 
>> To: 
>> Sent: Wednesday, September 05, 2001 4:33 AM
>> Subject: RE: [Simple] Partial Notifies?
>>
>>
>> > > I was actually debating this issue when doing the update
>> of the presence
>> >
>> > > spec. Its not specified right now, all through the events
>> framework
>> allows
>> >
>> > > each package to define how its done.
>> >
>> > I think that it should be included since NOTIFY can become
>> big especially
>> > given
>> >
>> > detail/schema/human readable comment.
>> >
>> > >
>> >
>> > > One model to do this is something I have proposed for
>> other packages:
>> >
>> > >
>> >
>> > > 1. the notify triggered by a subscribe contains the full state
>> >
>> > > 2. subsequent notifies contain only the piece thats
>> changed (i.e., the
>> >
>> > > contact address that is different)
>> >
>> > > 3. the subscriber keeps track of the cseq to see if it
>> may have missed a
>> >
>> > > notify. If there are no gaps in Cseq, nothing was missed.
>> If there is a
>> > gap,
>> >
>> > > something may have been missed, or else there was an intermediate
>> > challenge
>> >
>> > > or something like that. So, the subscriber re-subscribes to get a
>> > triggered
>> >
>> > > notify with full state.
>> >
>> > I assume that the granularity will be a single tuple of the
>> presence, and
>> > that
>> >
>> > there will be an operator preceding the tuple for
>add/delete/update.
>> >
>> > >
>> >
>> > > A better way to handle the ordering is for the presence
>> document itself
>> to
>> >
>> > > contain version numbers, but that would require changes
>> in the pidf
>> spec.
>> >
>> > >
>> >
>> > > Since the initial SUBSCRIBE has to trigger full state anyway,
>> idempotency
>> > of
>> >
>> > > SUBSCRIBE would argue for having full state triggered notify for
>> refreshes
>> >
>> > > too.
>> >
>> > It seems that Dror's suggestion (dror@vocaltec.com) can be
>> helpful here.
>> >
>> > avshalom
>> >
>> > Sametime/Lotus/IBM
>> >
>> >
>> >
>
>
>
>
>_______________________________________________
>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 roberbr@microsoft.com  Mon Sep 24 14:58:13 2001
Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA02104
	for ; Mon, 24 Sep 2001 14:58:09 -0400 (EDT)
Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Sep 2001 11:55:30 -0700
Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 24 Sep 2001 11:55:08 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] Partial Notifies?
Date: Mon, 24 Sep 2001 11:55:08 -0700
Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB0320D3B8@red-msg-05.redmond.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Partial Notifies?
Thread-Index: AcFCseAE73qkydySTT+heBrECpnJYACeIu1g
From: "Robert Brown" 
To: "Jonathan Rosenberg" ,
        "Sean Olson" , 
Cc: "Adam Roach (E-mail)" ,
        
X-OriginalArrivalTime: 24 Sep 2001 18:55:08.0671 (UTC) FILETIME=[6E6DB0F0:01C1452A]
Content-Length: 8532
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA02104
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: 

Yea

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent: Friday, September 21, 2001 8:27 AM
To: Sean Olson; 'Avshalom@ubique.com'; Jonathan Rosenberg
Cc: Adam Roach (E-mail); Robert Brown; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?

I think we should proceed with the presence spec as is, and instead work
on
the partial notifies as an extension. There is still a lot more work
that
needs to happen for partial notifies, as there are lots of ways to do
it,
and they require real investigation. I think we have some time until
this
becomes a dire need as well. 

I will add some text to the presence spec, though, which mentions that
extensions or new sub-packages can support partial notifies, just as a
placeholder.


OK? Please speak up with a yea or nay so we can have a real decision and
move on.

-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: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, September 21, 2001 11:06 AM
To: 'Avshalom@ubique.com'; Jonathan Rosenberg
Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?


I would like some clarification on how 
this would be documented (separate I-D?) and 
on whether or not this is mandatory to support 
in the client / server. (I assume not) 
Thanks, 
Sean Olson 
Ericsson Inc. 
>-----Original Message----- 
>From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] 
>Sent: Friday, September 21, 2001 10:00 AM 
>To: Jonathan Rosenberg 
>Cc: Adam Roach (E-mail); 'Robert Brown'; simple@mailman.dynamicsoft.com

>Subject: RE: [Simple] Partial Notifies? 
> 
> 
> 
>Is the partial silence can be considered as a consensus given 
>that the wglc 
>is today? 
> 
>avshalom 
>Sametime/Lotus/IBM 
> 
> 
> 
>                                                               
>                                                      
>                    Jonathan                                   
>                                                      
>                    Rosenberg              To:     "'Robert 
>Brown'" , Avshalom Houri          
>                    , simple@mailman.dynamicsoft.com          
>           
>                    csoft.com>             cc:     "Adam Roach 
>(E-mail)"                    
>                                           Subject:     RE: 
>[Simple] Partial Notifies?                               
>                    18/09/2001                                 
>                                                      
>                    14:58                                      
>                                                      
>                                                               
>                                                      
>                                                               
>                                                      
> 
> 
> 
> 
>This thread fell on the floor, but its a real important one 
>and I want to 
>get it going again. Its probably the biggest open issue for 
>the presence 
>spec, which is currently in wglc, so addressing it is really a higher 
>priority than the IM session discussion. 
> 
>I think that partial updates is probably a really good thing. 
>I'd like to 
>make sure it is adequately supported in the right way. 
> 
>Now, the question is, where does such support belong? Is it a 
>per-package 
>thing? Or is it something in the sip-events framework? I would 
>argue that 
>each package be able to define whether it does or doesn't use partial 
>notifies, but that the mechanism for doing them be shared across all 
>packages. For example, if we add a header like 
>Last-Data-Received: with a 
>hash of the body, as Dror had proposed, I think this header 
>belongs in the 
>sip-events specification. 
> 
>I believe the requirements for the partial notifications are 
>the following: 
> 
>1. the subscribe request have a way for the subscriber to indicate what

>version they have, so that the notify only contain a delta from that 
>version 
>(indeed, perhaps the notify isn't even sent if the version the 
>subscriber 
>has is up to date) 
> 
>2. the notify have a way to indicate what version of the document the 
>subscriber will have once the patch is applied 
> 
>3. the notify have a way to indicate what version the of the 
>document the 
>subscriber has to apply the patch against (i.e, the old version) 
> 
>4. the "patch" be in a format that is independent of the format of the 
>presence document. 
> 
> 
>Number 4 is important, I think, to avoid needing to specify updates and

>partial notifies within every event document format. We just 
>do it once, 
>and 
>then each event package doesn't need to ever worry about it again. 
> 
>Anders Kristensen had pointed out to me that webdav has looked 
>at a very 
>similar problem, and that there are specs for deltas within 
>http. I haven't 
>looked at those in detail, but they might provide a solution 
>for us that 
>would allow us to reuse existing work elsewhere in IETF. 
> 
>So, the quesitons to be discussed, in order, are: 
> 
>1. is there consensus that we should have a solution for 
>partial notifies 
>in 
>simple? 
> 
>2. is there consensus that this should be done in a general 
>fashion as part 
>of the sip events specification? 
> 
>3. how should it be done? 
> 
>Comments? 
> 
>-Jonathan R. 
> 
> 
> 
>> -----Original Message----- 
>> From: Robert Brown [mailto:roberbr@microsoft.com] 
>> Sent: Wednesday, September 05, 2001 4:41 PM 
>> To: Avshalom Houri; simple@mailman.dynamicsoft.com 
>> Subject: Re: [Simple] Partial Notifies? 
>> 
>> 
>> Watcher info can become pretty big too.  It would be nice to receive 
>> partials that only contained new pending watchers. 
>> 
>> ----- Original Message ----- 
>> From: "Avshalom Houri"  
>> To:  
>> Sent: Wednesday, September 05, 2001 4:33 AM 
>> Subject: RE: [Simple] Partial Notifies? 
>> 
>> 
>> > > I was actually debating this issue when doing the update 
>> of the presence 
>> > 
>> > > spec. Its not specified right now, all through the events 
>> framework 
>> allows 
>> > 
>> > > each package to define how its done. 
>> > 
>> > I think that it should be included since NOTIFY can become 
>> big especially 
>> > given 
>> > 
>> > detail/schema/human readable comment. 
>> > 
>> > > 
>> > 
>> > > One model to do this is something I have proposed for 
>> other packages: 
>> > 
>> > > 
>> > 
>> > > 1. the notify triggered by a subscribe contains the full state 
>> > 
>> > > 2. subsequent notifies contain only the piece thats 
>> changed (i.e., the 
>> > 
>> > > contact address that is different) 
>> > 
>> > > 3. the subscriber keeps track of the cseq to see if it 
>> may have missed a 
>> > 
>> > > notify. If there are no gaps in Cseq, nothing was missed. 
>> If there is a 
>> > gap, 
>> > 
>> > > something may have been missed, or else there was an intermediate

>> > challenge 
>> > 
>> > > or something like that. So, the subscriber re-subscribes to get a

>> > triggered 
>> > 
>> > > notify with full state. 
>> > 
>> > I assume that the granularity will be a single tuple of the 
>> presence, and 
>> > that 
>> > 
>> > there will be an operator preceding the tuple for 
>add/delete/update. 
>> > 
>> > > 
>> > 
>> > > A better way to handle the ordering is for the presence 
>> document itself 
>> to 
>> > 
>> > > contain version numbers, but that would require changes 
>> in the pidf 
>> spec. 
>> > 
>> > > 
>> > 
>> > > Since the initial SUBSCRIBE has to trigger full state anyway, 
>> idempotency 
>> > of 
>> > 
>> > > SUBSCRIBE would argue for having full state triggered notify for 
>> refreshes 
>> > 
>> > > too. 
>> > 
>> > It seems that Dror's suggestion (dror@vocaltec.com) can be 
>> helpful here. 
>> > 
>> > avshalom 
>> > 
>> > Sametime/Lotus/IBM 
>> > 
>> > 
>> > 
> 
> 
> 
> 
>_______________________________________________ 
>simple mailing list 
>simple@mailman.dynamicsoft.com 
>http://mailman.dynamicsoft.com/mailman/listinfo/simple 
> 

From jdrosen@dynamicsoft.com  Mon Sep 24 15:37:16 2001
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 PAA02265
	for ; Mon, 24 Sep 2001 15:37:16 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8OJa88P006891
	for ; Mon, 24 Sep 2001 15:36:08 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 24 Sep 2001 15:37:09 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Ben Campbell , simple@mailman.dynamicsoft.com
Date: Mon, 24 Sep 2001 15:37:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 4178
Subject: [Simple] RE: presence-02 comments
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: 

Responses inline.
 

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Friday, September 21, 2001 4:52 PM
> To: simple@mailman.dynamicsoft.com; jdrosen
> Subject: presence-02 comments
> 
> 
> Oops, first attempt bounced.
> --------------------------
> 
> A few comments, mostly nits. Apologies if these repeat comments from
> others(If so, I claim senility):
> 
> Section 2:
> 
> PUA definition (nit) definition states a PUA sends REGISTERS. 
> Since this
> islikely to change with a new publication method we might should drop
> the phrase.

Even with a different method for UPLOADING presence docs, it is still true
that a PUA can use REGISTER, and that this information can result in a
change in presence. But, I agree it doesn't read quite right. I changed it
to:

\item[Presence User Agent (PUA):] A Presence User Agent manipulates
presence information for a presentity. This manipulation can be the
side effect of some other action (such as sending a SIP REGISTER
request to add a new \header{Contact}) or can be done explicitly
through the publication of presence documents. We explicitly allow
multiple PUAs per presentity. This means that a user can have many



> 
> PA definition says "Typically colocated with proxy/registrar" 
> This is a
> possible configuration, but not necessarily typical.

Good point. Text now reads:

\item[Presence Agent (PA):] A presence agent is a SIP user agent which
is capable of receiving SUBSCRIBE requests, responding to them, and
generating notifications of changes in presence state. A presence
agent must have complete knowledge of the presence state of a
presentity. One way to do this is by co-locating the PA with
the proxy/registrar, or the presence user agent of
the presentity. However, this is not the only way, and this
specification makes no recommendations about where the PA function
should be located. A PA is always addressable with a SIP URL.



> 
> 5.3: reads: "In general, subscriptions will normally
>      not contain bodies. The request URI, which identifies 
> the presentity,
>      combined with the event package name, are sufficient for user
>      presence."
> 
> suggested (remove redundant "In general" and fix singular/plural
> mismatch: "Subscriptions will normally not contain bodies. The request
> URI, which identifies the presentity,combined with the event package
> name, is sufficient for user presence."

Changed.


> 
> 5.4: Language appears to say that presence only gets changed by
> one of the example events.

Well, it does say "events that include", meaning the set of events is
larger. But, I'll clarify. Now reads:

User presence changes as a result of many events. Some examples are:


> 
> p7 paragraph2: I thought we were removing "polite blocking" as an
> explicitly required feature. In any case, I would not consider it part
> of the minimum allowed set of authorization decisions.

Agreed its not minimum. I changed that bit to read:

Authorization decisions can be very complex. At a minimum, these are
be reject, accept, and pending. Pending occurs when

But I kept the text below which defines how to accomplish polite blocking,
since that particular policy is described in rfc 2779.


> 
> 5.10: Forking (NIT): text mentions that each PA responds with 
> 202 response.
> Should be 2xx class response, since 200's are also allowed.

Good catch. Fixed.

> 
> 6.4: Call state subscription: While I assume this is non-normative,
> I am afraid its presence will confuse people.

OK, I removed the section.

> 
> 7.3: Refers to PGP authentication in SIP. Hasn't that been 
> removed from
> SIP?
> 

Yes. It is in rfc2543, which is the normative reference for this, but in
reality no one has it and no one will. SO, I removed the pgp references.

Thanks for your comments.

-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

From jdrosen@dynamicsoft.com  Mon Sep 24 15:58:48 2001
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 PAA02352
	for ; Mon, 24 Sep 2001 15:58:48 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8OJve8P007152;
	Mon, 24 Sep 2001 15:57:40 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 24 Sep 2001 15:58:40 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Ngo, Dai (c)'" ,
        "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Notifier Migration Clarification
Date: Mon, 24 Sep 2001 15:58:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4674
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: 

Since no one objected, I have made this change.

-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 
> Sent: Tuesday, September 18, 2001 8:10 AM
> To: 'Ngo, Dai (c)'; Jonathan Rosenberg; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Notifier Migration Clarification
> 
> 
> 
> 
>   
> -----Original Message-----
> >From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com]
> >Sent: Friday, September 14, 2001 4:40 PM
> >To: 'Jonathan Rosenberg'; simple@mailman.dynamicsoft.com
> >Subject: RE: [Simple] Notifier Migration Clarification
> >
> >
> >Does this seem inflexible to you? We allow (serial/parallel) 
> forking for SUBSCRIBE, why 
> >not for this? 
> >-- Dai 
> 
> We do allow SUBSCRIBE to fork, but the spec only allows one 
> of them to proceed (the one whose 200 OK went to the 
> subscriber). So, I don't mind changing the text to allow it 
> to fork the SUBSCRIBE in the migration case, but you should 
> recognize that the effect will be the same - only one of the 
> forked SUBSCRIBEs will actually be used.
> 
> The issue is one of aggregation. Consider a presentity whose 
> presence is based on the aggregation of presence state from a 
> phone and a PC application. The question is: how performs the 
> aggregation of that state? I have argued that the aggregation 
> of presence state is highly policy dependent, and can only be 
> done properly by an entity in the domain of the presentity. 
> Thereofre, it makes sense for a server to handle the 
> subscription, and for it to generate an aggregate presence 
> document that combines the state of the phone and the PC. If 
> the phone and PC were to each act as presence agents, both 
> would send notifications of their individual states to the 
> subscribers. Then, the role of aggregation would lie with the 
> subscriber. I don't think it belongs there for user presence.
> 
> So, forking of subscribe to independent devices, each of 
> which knows its own presence, is not a good thing. Forking a 
> subscribe to a set of elements, each of which knows the full 
> presence state of the presentity, is just fine and perfectly 
> reasonable.
> 
> So, my proposal would be this:
> 
> 1. I add text which says that a PUA only indicate support for 
> SUBSCRIBE in its registration if it is certain that it has 
> full knowledge of the presence state of the presentity 
> (although I have no idea how it would know this in general)
> 
> 2. migrations are allowed when multiple contacts have 
> registered indicating support for subscribe.
> 
> OK?
> 
> -Jonathan R.
> 
> 
> 
> -----Original Message----- 
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
> Sent: Tuesday, September 04, 2001 5:39 PM 
> To: Ngo, Dai (c); simple@mailman.dynamicsoft.com 
> Subject: RE: [Simple] Notifier Migration Clarification 
> 
> 
> 
> 
>   
> -----Original Message----- 
> From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] 
> Sent: Tuesday, September 04, 2001 4:25 PM 
> To: simple@mailman.dynamicsoft.com 
> Subject: [Simple] Notifier Migration Clarification 
> 
> 
> >All, 
> >In section 5.12 "State Agents and Notifier Migration" of 
> draft-ietf-simple-presence-02.txt 
> >it says, "The presence server MAY migrate the subscription 
> if, for a given 
> address of 
> >record, there is one, and only one registered contact that indicates 
> explicit support for 
> >the SUBSCRIBE method." 
> > 
> >What's the behavior of the presence server if there are 
> multiple registered 
> contacts which 
> >explicitly support for the SUBSCRIBE method? 
> It can't migrate the PA function. 
> -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
> 

From jdrosen@dynamicsoft.com  Mon Sep 24 16:43:43 2001
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 QAA02528
	for ; Mon, 24 Sep 2001 16:43:43 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8OKga8P007627;
	Mon, 24 Sep 2001 16:42:36 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 24 Sep 2001 16:43:36 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Paul Kyzivat'" ,
        Jonathan Rosenberg
	 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Updated presence spec
Date: Mon, 24 Sep 2001 16:43:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 5662
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: 

Paul,

Thanks for your comments. Responses inline.
 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, September 04, 2001 11:09 AM
> To: Jonathan Rosenberg
> Cc: 'simple@mailman.dynamicsoft.com'
> Subject: Re: [Simple] Updated presence spec
> 
> ----------
> 
> 1) Frequency of presence changes:
> 
> Section 5.11 suggests a maximum rate of one notification every 5
> seconds. This kind of limit could damage the effectiveness of 
> some call
> queuing mechanisms. 
> 
> For instance, to support call queuing it could be useful for a PA to
> generate presence notifications in response to on-hook/off-hook and
> off-hook/on-hook transitions in a UA. If an off-hook/on-hook 
> transition
> generates a presence notification, this might well result in 
> the arrival
> of an immediate INVITE, and that in turn lead to an immediate
> on-hook/off-hook transition. This kind of scenario could lead to
> frequencies on the order of a second or less.  Even so, an *average*
> maximum rate of once per 5 seconds may be ok in such a scenario.

Its not a hard maximum, its just a recommended one. I'm trying to avoid the
"one update per millisecond" kind of volume. So, its just a question of
where to draw the line, and its quite hard to find that point. 

> 
> Section 5.4 also gives examples of when presence changes, and suggests
> that the frequency of occurrence ranges from minutes to hours. This
> fails to mention the possibility that on-hook/off-hook and
> off-hook/on-hook transitions of a phone might alter presence. This
> doesn't alter the conclusion of section 5.4 regarding subscription
> duration, but mentioning it might alter the implication that 
> a minute is
> a practical lower bound on frequency of presence changes.

I'll change it to seconds.

> 
> ----------
> 
> 2) Sourcing presence documents:
> 
> Section 2 says:
> 
>     Presence User Agent (PUA): A Presence User Agent manipulates
>     presence information for a presentity. In SIP terms, this
>     means that a PUA generates REGISTER requests, conveying
>     some kind of information about the presentity.
> 
> whereas section 5.8 says:
> 
>    The means by which the PA learns the state of the presentity are
>    also outside the scope of this recommendation. Registrations 
>    provide one way, and the means by which a PA uses registrations
>    to construct a presence document are an implementation choice.
> 
> Seems like the statement in section 2 is a bit strong. Perhaps the
> sentence beginning with "In SIP terms..." should just be deleted.
> Section 5.8 is also too strong. Seems like it can at most state:
> "Registrations MAY provide a way, though the means (if any) by which a
> PA uses registrations to construct a presence document are an
> implementation choice."

I've fixed section 2 already as a result of Ben's comments, as he had a
similar concern. I'll soften 5.8 as you describe.


> 
> Those changes would help achieve the apparent objective of eliminating
> any stardard way of making presence state known. But I don't 
> understand
> why this is a good thing. Wouldn't it be better to have one 
> way of doing
> this that is always available, even while permitting other ways?

Indeed, I'd like a solid way for a PA to upload presence data to a server.
Steve Donovan recently wrote a draft on requirements for such a protocol. We
should move it forward, but we need to clear some work out of the way first.

> 
> ----------
> 
> 3) Routing of Subscribe refreshes
> 
> Section 5.10 says:
> 
>    Furthermore, when refreshing the
>    subscription, the refresh SHOULD make use of the tags from the 202
>    and make use of any Contact or Record-Route headers in order to
>    deliver the SUBSCRIBE back to the same PA that sent the 202.
> 
> while 5.12 says:
> 
>    For the second phase, the PA destroys the subscriptions and then
>    sends a NOTIFY to each subscriber, with an Subscription-Expires
>    header with value 0 [3]. This informs the subscribers that their
>    subscription was destroyed, and should be re-established with a
>    new SUBSCRIBE (with a new Call-ID).
> 
>    The subscribers then create brand new subscriptions, with a new
>    Call-ID, no route set and no To tag, and this is sent to recreate
>    the subscription.
> 
> These seem to conflict - unless the response to receipt of a
> Subscription-Expires header with value 0 is treated as a special case
> different from normal subscription expiration. That kind of special
> casing seems like a bad idea.

It is a special case. Its a forceful termination of a subscription, along
with an explicit request to recreate it elsewhere. The difference is really
required for migration of subscriptions to work (and other things are
supported by it too).

> 
> ----------
> 
> 4) The followng in section 3 is grammatically incorrect:
> 
>    When an entity, the subscriber, wishes to learn about presence
>    information from some user, it creates a SUBSCRIBE request.
>    This request identifies the desired presentity in the request
>    URI, using either a SIP URL. 
>               ^^^^^^
> 
> Something is missing - either a SIP URL or what???

Or nothing. Old text from when we were using presence urls in the protocol.
Its just SIP URL.

Thanks for your comments,
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

From jdrosen@dynamicsoft.com  Mon Sep 24 16:50:15 2001
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 QAA02585
	for ; Mon, 24 Sep 2001 16:50:15 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8OKn08P007722;
	Mon, 24 Sep 2001 16:49:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 24 Sep 2001 16:50:00 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Robert Brown'" ,
        Jonathan Rosenberg
	 ,
        Sean Olson , Avshalom@ubique.com
Cc: "Adam Roach (E-mail)" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?
Date: Mon, 24 Sep 2001 16:49:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 3757
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: 

I think we have rough consensus. I added the the sentence to Section 5.8 at
the end of the following paragraph:

The times at which the {\NOTIFY} is sent for a particular subscriber,
and the contents of the body within that notification, are subject to
any rules specified by the authorization policy that governs the
subscription. This protocol in no way limits the scope of such
policies. As a baseline, a reasonable policy is to generate
notifications when the state of any of the communications addresses
changes. These notifications contain the complete and current presence
state of the presentity as known to the presence agent. Future
extensions {\MAY} be defined that allow a subscriber to request that
the notifications contain changes in presence information only, rather
than complete 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: Robert Brown [mailto:roberbr@microsoft.com]
> Sent: Monday, September 24, 2001 2:55 PM
> To: Jonathan Rosenberg; Sean Olson; Avshalom@ubique.com
> Cc: Adam Roach (E-mail); simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Partial Notifies?
> 
> 
> Yea
> 
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
> Sent: Friday, September 21, 2001 8:27 AM
> To: Sean Olson; 'Avshalom@ubique.com'; Jonathan Rosenberg
> Cc: Adam Roach (E-mail); Robert Brown; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Partial Notifies?
> 
> I think we should proceed with the presence spec as is, and 
> instead work
> on
> the partial notifies as an extension. There is still a lot more work
> that
> needs to happen for partial notifies, as there are lots of ways to do
> it,
> and they require real investigation. I think we have some time until
> this
> becomes a dire need as well. 
> 
> I will add some text to the presence spec, though, which mentions that
> extensions or new sub-packages can support partial notifies, just as a
> placeholder.
> 
> 
> OK? Please speak up with a yea or nay so we can have a real 
> decision and
> move on.
> 
> -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: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
> Sent: Friday, September 21, 2001 11:06 AM
> To: 'Avshalom@ubique.com'; Jonathan Rosenberg
> Cc: Adam Roach (E-mail); 'Robert Brown'; 
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Partial Notifies?
> 
> 
> I would like some clarification on how 
> this would be documented (separate I-D?) and 
> on whether or not this is mandatory to support 
> in the client / server. (I assume not) 
> Thanks, 
> Sean Olson 
> Ericsson Inc. 
> >-----Original Message----- 
> >From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] 
> >Sent: Friday, September 21, 2001 10:00 AM 
> >To: Jonathan Rosenberg 
> >Cc: Adam Roach (E-mail); 'Robert Brown'; 
> simple@mailman.dynamicsoft.com
> 
> >Subject: RE: [Simple] Partial Notifies? 
> > 
> > 
> > 
> >Is the partial silence can be considered as a consensus given 
> >that the wglc 
> >is today? 
> > 
> >avshalom 
> >Sametime/Lotus/IBM 
> > 
> > 

From pkyzivat@cisco.com  Mon Sep 24 17:00:14 2001
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 RAA02657
	for ; Mon, 24 Sep 2001 17:00:08 -0400 (EDT)
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 f8OKxN907851;
	Mon, 24 Sep 2001 16:59:23 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB14373 (AUTH pkyzivat);
	Mon, 24 Sep 2001 17:01:01 -0400 (EDT)
Message-ID: <3BAF9E85.A3E7E63@cisco.com>
Date: Mon, 24 Sep 2001 16:58:45 -0400
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] Updated presence spec
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1932
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: 

Further comment below.

	Paul

Jonathan Rosenberg wrote:
> 
> Paul,
> 
> Thanks for your comments. Responses inline.
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]

> > 3) Routing of Subscribe refreshes
> >
> > Section 5.10 says:
> >
> >    Furthermore, when refreshing the
> >    subscription, the refresh SHOULD make use of the tags from the 202
> >    and make use of any Contact or Record-Route headers in order to
> >    deliver the SUBSCRIBE back to the same PA that sent the 202.
> >
> > while 5.12 says:
> >
> >    For the second phase, the PA destroys the subscriptions and then
> >    sends a NOTIFY to each subscriber, with an Subscription-Expires
> >    header with value 0 [3]. This informs the subscribers that their
> >    subscription was destroyed, and should be re-established with a
> >    new SUBSCRIBE (with a new Call-ID).
> >
> >    The subscribers then create brand new subscriptions, with a new
> >    Call-ID, no route set and no To tag, and this is sent to recreate
> >    the subscription.
> >
> > These seem to conflict - unless the response to receipt of a
> > Subscription-Expires header with value 0 is treated as a special case
> > different from normal subscription expiration. That kind of special
> > casing seems like a bad idea.
> 
> It is a special case. Its a forceful termination of a subscription, along
> with an explicit request to recreate it elsewhere. The difference is really
> required for migration of subscriptions to work (and other things are
> supported by it too).

Then can this be made clearer? In which cases should tags, route headers
and contacts not be reused in a refresh? Is it in precisely the cases
where a Subscription-Expires is received with a value of zero? Or
perhaps it should be any time that a refresh is being sent after the
prior subscription has expired? The latter would make sense, and is less
of a special case.

From jdrosen@dynamicsoft.com  Mon Sep 24 17:01:49 2001
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 RAA02687
	for ; Mon, 24 Sep 2001 17:01:49 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8OL0g8P007929;
	Mon, 24 Sep 2001 17:00:42 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 24 Sep 2001 17:01:42 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brian Stucker'" ,
        Jonathan Rosenberg
	 ,
        "'simple@mailman.dynamicsoft.com'"
	 
Subject: RE: [Simple] Questions on the current presence draft.
Date: Mon, 24 Sep 2001 17:01:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 7980
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: 



-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Wednesday, September 19, 2001 10:09 AM
To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Questions on the current presence draft.


>Thanks for the clairification. 
>I'd like to make the problem of the watcher not getting a notification that
their 
>subscription has expired (due to a migration) because of a temporary
failure at the 
>watcher, 
>or in the network, go away without a huge hassle if that is possible. 

Thats generally a good design goal ;)

>The scenario I'm thinking of would cause problems if the watcher simply
decided to go 
>offline 
>when the migration occurred. No network failure needed, they just had their
machine turned
>off 
>during that time. The problem that I see is that you're right, and you'd
wind up likely 
>creating 
>a flood of network traffic at some point to recover from this. 

Why is it a flood? When the watcher comes back, they refresh their
subscriptions. This is just a set of refreshes from one watcher. 

>Maybe a note in there somewhere that when a watcher has been SIP
unreachable (powered down, 
>client 
>software not running, etc.), they need to fetch their subscriptions again
(at a reasonable 
>rate) 
>in case a migration has occurred? 

The problem is easy when the watcher knows they have been unreachable. I'm
not sure anything needs to be said here, as this is not really any different
from basic subscribe. The spec doesn't dictate a system, so I can't rightly
tell people when they have to send SUBSCRIBE; thats the job of the RFP, not
the RFC. 

When a host is SIP unreachable, but doesn't know it, this is quite a hard
problem that affects things far broader than presence, or sip-events even
(what if I miss the BYE, for example, of an ongoing call?). So, I'd rather
not try to address that in this document.


Thanks, 
Brian 


---
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: Tuesday, September 18, 2001 6:28 AM 
To: Stucker, Brian [NGB:B651:EXCH]; 'simple@mailman.dynamicsoft.com' 
Subject: RE: [Simple] Questions on the current presence draft. 




  
-----Original Message----- 
From: Brian Stucker [mailto:bstucker@nortelnetworks.com] 
Sent: Tuesday, September 11, 2001 3:30 PM 
To: 'simple@mailman.dynamicsoft.com' 
Subject: [Simple] Questions on the current presence draft. 


>I was reading through the current draft, and noticed a few things that I 
>was looking for clairification on. 
>In the section on presence migration, the last sentence of the description 
>for the second phase of presence migration states: "...This informs the 
subscribers that 
>their 
>subscription was destroyed, and should be re-established with a new 
SUBSCRIBE (with a new 
>Call-ID)." 
>I was wondering, if a watcher was offline when the NOTIFY containing the 
"Subscription- 
>Expires" header 
>to destroy the current subscription, what are the implications with the 
call id? I would 
>imagine when the 
>watcher comes back online, and tries to refresh the subscription, it would 
use the old 
>call-id (since it doesn't 
>know that it needs to reselect), which gets proxied to the new PA (after 
the migration 
>occurred). This seems like a gap to me. 
There are two cases here. In case 1, when the subscriber goes "offline", all

subscriptions state is lost. This would happen when a PC application is 
terminated, for example. In that case, when the watcher comes back, it will 
have no record of previous subscription state. So, it creates a new 
subscription with a brand new call ID. No problems. 
In case 2, the subscriber goes "offline" in the sense that its network 
connectivity is lost, so it won't get the NOTIFY, but it still retains 
subscription state. THis would be the case, for example, with a mobile phone

that goes out of range. When the mobile comes back in range, it will 
re-subscribe with the old call-id/route-set, in order to obtain the latest 
data it may have missed while out of range. Since this subscribe has a route

set, the request will arrive at the presence server (the one that formerly 
owned the subscriptions, but has since migrated them) with the URL of the 
presence server in the request URI (like sip:presence-server-1.foo.com). 
Since the URL points to itself, the presence server knows that it should 
process it. Since no subscriptions exist, this request would be rejected 
with a 481. Should it be proxied anyway to the PUA now handling the 
subscription, it would probably also be rejected with a 481 because the tags

don't match those of any existing subscriptions at the PUA. 
The 481 would trigger the subscriber to retry the subscription with a fresh 
call-id and no route set. 
The specifications are not clear at the moment about the handling of the 
case when you get a subscribe with a tag in the To field that doesn't match 
an existing subscription. That needs to be clarified in the events framework

spec. I'll send a note to Adam about it. 
> 
>Also, what happens if the watchers (previous to the migration) never 
receive the NOTIFY to 
>update their 
>subscriptions to cause a refresh. Unless they do a fetch, the new PA 
doesn't know that 
>they exist, so their 
>subscriptions will be effectively moot, but they won't be aware of this 
fact. They won't 
>get any notifications, and 
>won't know that their subscriptions are being ignored. 
I think this is the same problem I discussed above. The question you need to

ask is why the watcher would not have gotten the NOTIFY. Assuming the 
watcher application is running the whole time, the only reason this would 
occur is a network failure of some sort, or a failure of the presence server

itself. Network failures that occur because the mobile has gone out of range

are generally detectable, and so the mobile can do something about it. 
Network failures in the middle of the network which occur for long enough to

prevent a notification from being delivered (in excess of 16s) are hard to 
deal with in any protocol. A "nice" presence agent could retain the 
subscription state unless it gets a positive response to the NOTIFY, but 
that can be used as a DoS attack. So, I don't know how solve this particular

failure case. There will be a gap in the delivery of notifications for the 
duration of a refresh period. Given the scope of the failure that must occur

for that to happen, I think thats acceptable. 
Failures of the presence server itself can be handled using traditional 
mechanisms, such as replication of subscription state to a hot standby. 


> 
>In section 8, there are mixed uses of the presence URL and SIP URL's. Is 
this done 
>intentionally? 
No. My error. I've changed them all to sip URLs. Thanks. 
> 
>Finally, can someone point a link to the draft listed as [4] in the 
bibliography? It 
>doesn't seem to be available 
>at the IETF webpage. 
It just recently expired. The impp chairs have been pinging the editor to 
resubmit an update. 
Until then, you can get a copy from google's cached version of the draft: 
http://www.google.com/search?q=cache:jdFIIPRBPY0:www.ietf.org/internet-draft

s/draft-ietf-impp-cpim-01.txt+draft-ietf-impp-cpim&hl=en 
Thanks for your comments, 
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 

From jdrosen@dynamicsoft.com  Mon Sep 24 17:07:43 2001
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 RAA02740
	for ; Mon, 24 Sep 2001 17:07:43 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8OL6Z8P008048;
	Mon, 24 Sep 2001 17:06:35 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 24 Sep 2001 17:07:36 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Paul Kyzivat'" ,
        Jonathan Rosenberg
	 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Updated presence spec
Date: Mon, 24 Sep 2001 17:07:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 2051
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: 


 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, September 24, 2001 4:59 PM
> To: Jonathan Rosenberg
> Cc: 'simple@mailman.dynamicsoft.com'
> Subject: Re: [Simple] Updated presence spec
> 
> > > These seem to conflict - unless the response to receipt of a
> > > Subscription-Expires header with value 0 is treated as a 
> special case
> > > different from normal subscription expiration. That kind 
> of special
> > > casing seems like a bad idea.
> > 
> > It is a special case. Its a forceful termination of a 
> subscription, along
> > with an explicit request to recreate it elsewhere. The 
> difference is really
> > required for migration of subscriptions to work (and other 
> things are
> > supported by it too).
> 
> Then can this be made clearer? In which cases should tags, 
> route headers
> and contacts not be reused in a refresh? Is it in precisely the cases
> where a Subscription-Expires is received with a value of zero? 

Actually, there is supposed to be a parameter in the subscription-refresh
which says you better start from scratch. That would be the explicit hint.

> Or
> perhaps it should be any time that a refresh is being sent after the
> prior subscription has expired? The latter would make sense, 
> and is less
> of a special case.

You may have thought you sent it before the expiration when the server
thought it was afterwards. As such, you don't want this to be time based
IMHO. The explicit flag in the subscription-expires seems most appropriate,
since this is a special case.

That header and this flag should appear in a version of sip-events soon; we
have a dependency issue here unfortunately.

-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

From jdrosen@dynamicsoft.com  Mon Sep 24 17:33:14 2001
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 RAA02870
	for ; Mon, 24 Sep 2001 17:33:14 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8OLW78P008359
	for ; Mon, 24 Sep 2001 17:32:07 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 24 Sep 2001 17:33:07 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Mon, 24 Sep 2001 17:33:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 696
Subject: [Simple] Updated presence spec
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: 

Folks,

I've just submitted an update to the presence spec based on comments
received during the last call period. Until it appears in the archives, you
can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-03.txt

There are no open issues that I am aware of. Hopefully this one will go to
IESG.

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
 

From bstucker@nortelnetworks.com  Mon Sep 24 17:34:14 2001
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 RAA02879
	for ; Mon, 24 Sep 2001 17:34:10 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA20148
	for ; Mon, 24 Sep 2001 16:33:58 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 24 Sep 2001 16:33:44 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 24 Sep 2001 16:33:30 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E232750@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Jonathan Rosenberg ,
        Jonathan Rosenberg ,
        "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Questions on the current presence draft.
Date: Mon, 24 Sep 2001 16:33:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14540.8C48F6A0"
Content-Length: 26107
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: 

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_01C14540.8C48F6A0
Content-Type: text/plain;
	charset="iso-8859-1"

Thanks Johnathan (er.. Brian, as you signed below), hehe..

I'm just trying to protect from implementations that don't try to actively
keep their subscription state synced. Just seems like relying solely on the
PA to help watchers coordinate their state, without some degree of fetching
by the watcher could cause things to get out of sync in some easy error
scenarios. The flood bit was about the watcher trying to refresh their
subscriptions, and getting 481's back (possibly) a couple of times before
the subscription refreshes correctly. Since it'd be a self-induced flood,
well, I guess that's the problem that the watcher has to deal with, however,
I'm trying to think of ways of protecting the network in this case from
using this as an attack of some sort.

If the watcher gets a 481 back from the presence server because a presence
agent has migrated, how is it to tell that this was because it missed the
subscription expiration, rather than it simply making a bad request on the
presence server?

Thanks,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, September 24, 2001 4:02 PM
To: Stucker, Brian [NGB:B651:EXCH]; Jonathan Rosenberg;
'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Questions on the current presence draft.





-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Wednesday, September 19, 2001 10:09 AM
To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Questions on the current presence draft.


>Thanks for the clairification. 
>I'd like to make the problem of the watcher not getting a notification that
their 
>subscription has expired (due to a migration) because of a temporary
failure at the 
>watcher, 
>or in the network, go away without a huge hassle if that is possible. 

Thats generally a good design goal ;)

>The scenario I'm thinking of would cause problems if the watcher simply
decided to go 
>offline 
>when the migration occurred. No network failure needed, they just had their
machine turned
>off 
>during that time. The problem that I see is that you're right, and you'd
wind up likely 
>creating 
>a flood of network traffic at some point to recover from this. 

Why is it a flood? When the watcher comes back, they refresh their
subscriptions. This is just a set of refreshes from one watcher. 

>Maybe a note in there somewhere that when a watcher has been SIP
unreachable (powered down, 
>client 
>software not running, etc.), they need to fetch their subscriptions again
(at a reasonable 
>rate) 
>in case a migration has occurred? 

The problem is easy when the watcher knows they have been unreachable. I'm
not sure anything needs to be said here, as this is not really any different
from basic subscribe. The spec doesn't dictate a system, so I can't rightly
tell people when they have to send SUBSCRIBE; thats the job of the RFP, not
the RFC. 

When a host is SIP unreachable, but doesn't know it, this is quite a hard
problem that affects things far broader than presence, or sip-events even
(what if I miss the BYE, for example, of an ongoing call?). So, I'd rather
not try to address that in this document.


Thanks, 
Brian 


---
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: Tuesday, September 18, 2001 6:28 AM 
To: Stucker, Brian [NGB:B651:EXCH]; 'simple@mailman.dynamicsoft.com' 
Subject: RE: [Simple] Questions on the current presence draft. 




  
-----Original Message----- 
From: Brian Stucker [mailto:bstucker@nortelnetworks.com] 
Sent: Tuesday, September 11, 2001 3:30 PM 
To: 'simple@mailman.dynamicsoft.com' 
Subject: [Simple] Questions on the current presence draft. 


>I was reading through the current draft, and noticed a few things that I 
>was looking for clairification on. 
>In the section on presence migration, the last sentence of the description 
>for the second phase of presence migration states: "...This informs the 
subscribers that 
>their 
>subscription was destroyed, and should be re-established with a new 
SUBSCRIBE (with a new 
>Call-ID)." 
>I was wondering, if a watcher was offline when the NOTIFY containing the 
"Subscription- 
>Expires" header 
>to destroy the current subscription, what are the implications with the 
call id? I would 
>imagine when the 
>watcher comes back online, and tries to refresh the subscription, it would 
use the old 
>call-id (since it doesn't 
>know that it needs to reselect), which gets proxied to the new PA (after 
the migration 
>occurred). This seems like a gap to me. 
There are two cases here. In case 1, when the subscriber goes "offline", all

subscriptions state is lost. This would happen when a PC application is 
terminated, for example. In that case, when the watcher comes back, it will 
have no record of previous subscription state. So, it creates a new 
subscription with a brand new call ID. No problems. 
In case 2, the subscriber goes "offline" in the sense that its network 
connectivity is lost, so it won't get the NOTIFY, but it still retains 
subscription state. THis would be the case, for example, with a mobile phone

that goes out of range. When the mobile comes back in range, it will 
re-subscribe with the old call-id/route-set, in order to obtain the latest 
data it may have missed while out of range. Since this subscribe has a route

set, the request will arrive at the presence server (the one that formerly 
owned the subscriptions, but has since migrated them) with the URL of the 
presence server in the request URI (like sip:presence-server-1.foo.com). 
Since the URL points to itself, the presence server knows that it should 
process it. Since no subscriptions exist, this request would be rejected 
with a 481. Should it be proxied anyway to the PUA now handling the 
subscription, it would probably also be rejected with a 481 because the tags

don't match those of any existing subscriptions at the PUA. 
The 481 would trigger the subscriber to retry the subscription with a fresh 
call-id and no route set. 
The specifications are not clear at the moment about the handling of the 
case when you get a subscribe with a tag in the To field that doesn't match 
an existing subscription. That needs to be clarified in the events framework

spec. I'll send a note to Adam about it. 
> 
>Also, what happens if the watchers (previous to the migration) never 
receive the NOTIFY to 
>update their 
>subscriptions to cause a refresh. Unless they do a fetch, the new PA 
doesn't know that 
>they exist, so their 
>subscriptions will be effectively moot, but they won't be aware of this 
fact. They won't 
>get any notifications, and 
>won't know that their subscriptions are being ignored. 
I think this is the same problem I discussed above. The question you need to

ask is why the watcher would not have gotten the NOTIFY. Assuming the 
watcher application is running the whole time, the only reason this would 
occur is a network failure of some sort, or a failure of the presence server

itself. Network failures that occur because the mobile has gone out of range

are generally detectable, and so the mobile can do something about it. 
Network failures in the middle of the network which occur for long enough to

prevent a notification from being delivered (in excess of 16s) are hard to 
deal with in any protocol. A "nice" presence agent could retain the 
subscription state unless it gets a positive response to the NOTIFY, but 
that can be used as a DoS attack. So, I don't know how solve this particular

failure case. There will be a gap in the delivery of notifications for the 
duration of a refresh period. Given the scope of the failure that must occur

for that to happen, I think thats acceptable. 
Failures of the presence server itself can be handled using traditional 
mechanisms, such as replication of subscription state to a hot standby. 


> 
>In section 8, there are mixed uses of the presence URL and SIP URL's. Is 
this done 
>intentionally? 
No. My error. I've changed them all to sip URLs. Thanks. 
> 
>Finally, can someone point a link to the draft listed as [4] in the 
bibliography? It 
>doesn't seem to be available 
>at the IETF webpage. 
It just recently expired. The impp chairs have been pinging the editor to 
resubmit an update. 
Until then, you can get a copy from google's cached version of the draft: 
http://www.google.com/search?q=cache:jdFIIPRBPY0:www.ietf.org/internet-draft

s/draft-ietf-impp-cpim-01.txt+draft-ietf-impp-cpim&hl=en 
Thanks for your comments, 
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_01C14540.8C48F6A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Questions on the current presence draft.




Thanks Johnathan (er.. Brian, as you signed below), =
hehe..




I'm just trying to protect from implementations that =
don't try to actively keep their subscription state synced. Just seems =
like relying solely on the PA to help watchers coordinate their state, =
without some degree of fetching by the watcher could cause things to =
get out of sync in some easy error scenarios. The flood bit was about =
the watcher trying to refresh their subscriptions, and getting 481's =
back (possibly) a couple of times before the subscription refreshes =
correctly. Since it'd be a self-induced flood, well, I guess that's the =
problem that the watcher has to deal with, however, I'm trying to think =
of ways of protecting the network in this case from using this as an =
attack of some sort.



If the watcher gets a 481 back from the presence =
server because a presence agent has migrated, how is it to tell that =
this was because it missed the subscription expiration, rather than it =
simply making a bad request on the presence server?



Thanks,




Brian




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Monday, September 24, 2001 4:02 PM

To: Stucker, Brian [NGB:B651:EXCH]; Jonathan =
Rosenberg;

'simple@mailman.dynamicsoft.com'

Subject: RE: [Simple] Questions on the current =
presence draft.












-----Original Message-----

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

Sent: Wednesday, September 19, 2001 10:09 AM

To: Jonathan Rosenberg; =
'simple@mailman.dynamicsoft.com'

Subject: RE: [Simple] Questions on the current =
presence draft.






>Thanks for the clairification. 

>I'd like to make the problem of the watcher not =
getting a notification that

their 

>subscription has expired (due to a migration) =
because of a temporary

failure at the 

>watcher, 

>or in the network, go away without a huge hassle =
if that is possible. 




Thats generally a good design goal ;)




>The scenario I'm thinking of would cause problems =
if the watcher simply

decided to go 

>offline 

>when the migration occurred. No network failure =
needed, they just had their

machine turned

>off 

>during that time. The problem that I see is that =
you're right, and you'd

wind up likely 

>creating 

>a flood of network traffic at some point to =
recover from this. 




Why is it a flood? When the watcher comes back, they =
refresh their

subscriptions. This is just a set of refreshes from =
one watcher. 




>Maybe a note in there somewhere that when a =
watcher has been SIP

unreachable (powered down, 

>client 

>software not running, etc.), they need to fetch =
their subscriptions again

(at a reasonable 

>rate) 

>in case a migration has occurred? 




The problem is easy when the watcher knows they have =
been unreachable. I'm

not sure anything needs to be said here, as this is =
not really any different

from basic subscribe. The spec doesn't dictate a =
system, so I can't rightly

tell people when they have to send SUBSCRIBE; thats =
the job of the RFP, not

the RFC. 




When a host is SIP unreachable, but doesn't know it, =
this is quite a hard

problem that affects things far broader than =
presence, or sip-events even

(what if I miss the BYE, for example, of an ongoing =
call?). So, I'd rather

not try to address that in this document.






Thanks, 

Brian 






---

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: Tuesday, September 18, 2001 6:28 AM 

To: Stucker, Brian [NGB:B651:EXCH]; =
'simple@mailman.dynamicsoft.com' 

Subject: RE: [Simple] Questions on the current =
presence draft. 










  

-----Original Message----- 

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

Sent: Tuesday, September 11, 2001 3:30 PM 

To: 'simple@mailman.dynamicsoft.com' 

Subject: [Simple] Questions on the current presence =
draft. 






>I was reading through the current draft, and =
noticed a few things that I 

>was looking for clairification on. 

>In the section on presence migration, the last =
sentence of the description 

>for the second phase of presence migration =
states: "...This informs the 

subscribers that 

>their 

>subscription was destroyed, and should be =
re-established with a new 

SUBSCRIBE (with a new 

>Call-ID)." 

>I was wondering, if a watcher was offline when =
the NOTIFY containing the 

"Subscription- 

>Expires" header 

>to destroy the current subscription, what are =
the implications with the 

call id? I would 

>imagine when the 

>watcher comes back online, and tries to refresh =
the subscription, it would 

use the old 

>call-id (since it doesn't 

>know that it needs to reselect), which gets =
proxied to the new PA (after 

the migration 

>occurred). This seems like a gap to me. 

There are two cases here. In case 1, when the =
subscriber goes "offline", all




subscriptions state is lost. This would happen when a =
PC application is 

terminated, for example. In that case, when the =
watcher comes back, it will 

have no record of previous subscription state. So, =
it creates a new 

subscription with a brand new call ID. No problems. =


In case 2, the subscriber goes "offline" =
in the sense that its network 

connectivity is lost, so it won't get the NOTIFY, =
but it still retains 

subscription state. THis would be the case, for =
example, with a mobile phone




that goes out of range. When the mobile comes back in =
range, it will 

re-subscribe with the old call-id/route-set, in =
order to obtain the latest 

data it may have missed while out of range. Since =
this subscribe has a route




set, the request will arrive at the presence server =
(the one that formerly 

owned the subscriptions, but has since migrated =
them) with the URL of the 

presence server in the request URI (like =
sip:presence-server-1.foo.com). 

Since the URL points to itself, the presence server =
knows that it should 

process it. Since no subscriptions exist, this =
request would be rejected 

with a 481. Should it be proxied anyway to the PUA =
now handling the 

subscription, it would probably also be rejected =
with a 481 because the tags




don't match those of any existing subscriptions at =
the PUA. 

The 481 would trigger the subscriber to retry the =
subscription with a fresh 

call-id and no route set. 

The specifications are not clear at the moment about =
the handling of the 

case when you get a subscribe with a tag in the To =
field that doesn't match 

an existing subscription. That needs to be clarified =
in the events framework




spec. I'll send a note to Adam about it. 

> 

>Also, what happens if the watchers (previous to =
the migration) never 

receive the NOTIFY to 

>update their 

>subscriptions to cause a refresh. Unless they do =
a fetch, the new PA 

doesn't know that 

>they exist, so their 

>subscriptions will be effectively moot, but they =
won't be aware of this 

fact. They won't 

>get any notifications, and 

>won't know that their subscriptions are being =
ignored. 

I think this is the same problem I discussed above. =
The question you need to




ask is why the watcher would not have gotten the =
NOTIFY. Assuming the 

watcher application is running the whole time, the =
only reason this would 

occur is a network failure of some sort, or a =
failure of the presence server




itself. Network failures that occur because the =
mobile has gone out of range




are generally detectable, and so the mobile can do =
something about it. 

Network failures in the middle of the network which =
occur for long enough to




prevent a notification from being delivered (in =
excess of 16s) are hard to 

deal with in any protocol. A "nice" =
presence agent could retain the 

subscription state unless it gets a positive =
response to the NOTIFY, but 

that can be used as a DoS attack. So, I don't know =
how solve this particular




failure case. There will be a gap in the delivery of =
notifications for the 

duration of a refresh period. Given the scope of the =
failure that must occur




for that to happen, I think thats acceptable. 

Failures of the presence server itself can be =
handled using traditional 

mechanisms, such as replication of subscription =
state to a hot standby. 






> 

>In section 8, there are mixed uses of the =
presence URL and SIP URL's. Is 

this done 

>intentionally? 

No. My error. I've changed them all to sip URLs. =
Thanks. 

> 

>Finally, can someone point a link to the draft =
listed as [4] in the 

bibliography? It 

>doesn't seem to be available 

>at the IETF webpage. 

It just recently expired. The impp chairs have been =
pinging the editor to 

resubmit an update. 

Until then, you can get a copy from google's cached =
version of the draft: 

http://www.google.com/search?q=3Dcache:jdFIIPRBPY0:www=
.ietf.org/internet-draft




s/draft-ietf-impp-cpim-01.txt+draft-ietf-impp-cpim&hl=3Den =


Thanks for your comments, 

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_01C14540.8C48F6A0--

From sean.olson@ericsson.com  Mon Sep 24 18:33:32 2001
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 SAA03126
	for ; Mon, 24 Sep 2001 18:33:32 -0400 (EDT)
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 f8OMXJ721365
	for ; Mon, 24 Sep 2001 17:33:19 -0500 (CDT)
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 f8OMXJW26924
	for ; Mon, 24 Sep 2001 17:33:19 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Sep 24 17:33:13 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 21 Sep 2001 15:36:36 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Robert Sparks'" ,
        "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Final day - WG LAST CALL : draft-ietf-simple-presenc
	e-02
Date: Fri, 21 Sep 2001 15:36:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C142DD.17F03B70"
Content-Length: 6832
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: 

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_01C142DD.17F03B70
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,
Here are some minor comments. Hope they are
not too late.

1) Section 3, second paragraph, second sentence
   ",using either a SIP URL." should become
   ",using either a SIP URL or a presence URL [4]".

2) Section 5.6, second to last paragraph
   I think it would be useful to move the text
   about generation of subscription refreshes
   from Section 5.10 to here. The text I am
   referring to is:

   "Furthermore, when refreshing the subscription,
    the refresh SHOULD make use of the tags from 
    the 202 and make use of any Contact: or
    Record-Route: headers in order to deliver the
    SUBSCRIBE back to the same PA that sent the 202"

    This text makes sense not only for the forking case
    but also for the case where pres: URLs are used.
    That is, I believe that if the first SUBSCRIBE request
    contained a pres: URL in the Request-URI, subsequent
    refreshes of that SUBSCRIBE should take advantage of
    the SIP URL present in the Contact: of the 202 response
    to avoid that lookup again (particularly when the 
    client generating the SUBSCRIBE cannot directly handle
    the pres: URL lookup)

3) Section 5.7

    Regarding the use of the Remote-Party-ID header in a
    SUBSCRIBE, do you intend to allow pres: URLs as well
    or only SIP URLs? (very small point)

4) Section 5.12, description of three phases of migration

   It seems that there is a fourth (optional) phase
   missing before the current PA sends NOTIFYs with a
   Subscription-Expires: of 0 to force the current
   subscribers to migrate. This phase would push the
   current presence information from the current PA
   to the new target PA using the same potential 
   mechanisms described in Section 6.3 

   The reason for doing so is to allow the new PA client
   to act on behalf of other non-PA UserAgent:s for this
   presentity.

5) Section 8

   You might want to add a "Content-Length: 0" to 
   appropriate messages.

   You may also want to show an example Notifier
   migration triggered by a REGISTER request
   with ";methods="SUBSCRIBE,MESSAGE". This would
   show the use of the Subscription-Expires header.

Best Regards,
Sean Olson
Ericsson Inc.

------_=_NextPart_001_01C142DD.17F03B70
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Final day - WG LAST CALL : draft-ietf-simple-presence-02




Hello,

Here are some minor comments. Hope they are

not too late.




1) Section 3, second paragraph, second sentence

   ",using either a SIP URL." should become

   ",using either a SIP URL or a presence URL [4]".




2) Section 5.6, second to last paragraph

   I think it would be useful to move the text

   about generation of subscription refreshes

   from Section 5.10 to here. The text I am

   referring to is:




   "Furthermore, when refreshing the subscription,

    the refresh SHOULD make use of the tags from 

    the 202 and make use of any Contact: or

    Record-Route: headers in order to deliver the

    SUBSCRIBE back to the same PA that sent the 202"




    This text makes sense not only for the forking case

    but also for the case where pres: URLs are used.

    That is, I believe that if the first SUBSCRIBE request

    contained a pres: URL in the Request-URI, subsequent

    refreshes of that SUBSCRIBE should take advantage of

    the SIP URL present in the Contact: of the 202 response

    to avoid that lookup again (particularly when the 

    client generating the SUBSCRIBE cannot directly handle

    the pres: URL lookup)




3) Section 5.7




    Regarding the use of the Remote-Party-ID header in a

    SUBSCRIBE, do you intend to allow pres: URLs as well

    or only SIP URLs? (very small point)




4) Section 5.12, description of three phases of migration




   It seems that there is a fourth (optional) phase

   missing before the current PA sends NOTIFYs with a

   Subscription-Expires: of 0 to force the current

   subscribers to migrate. This phase would push the

   current presence information from the current PA

   to the new target PA using the same potential 

   mechanisms described in Section 6.3 




   The reason for doing so is to allow the new PA client

   to act on behalf of other non-PA UserAgent:s for this

   presentity.




5) Section 8




   You might want to add a "Content-Length: 0" to 

   appropriate messages.




   You may also want to show an example Notifier

   migration triggered by a REGISTER request

   with ";methods="SUBSCRIBE,MESSAGE". This would

   show the use of the Subscription-Expires header.




Best Regards,

Sean Olson

Ericsson Inc.





------_=_NextPart_001_01C142DD.17F03B70--

From sean.olson@ericsson.com  Mon Sep 24 19:53:38 2001
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 TAA03424
	for ; Mon, 24 Sep 2001 19:53:38 -0400 (EDT)
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 f8ONrQQ06851
	for ; Mon, 24 Sep 2001 18:53:26 -0500 (CDT)
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 f8ONrQW22782
	for ; Mon, 24 Sep 2001 18:53:26 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Sep 24 17:59:52 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Mon, 24 Sep 2001 14:54:19 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Anders Kristensen'" 
Cc: "'Jonathan Rosenberg'" ,
        "'Robert Brown'"
	 ,
        Avshalom Houri , simple@mailman.dynamicsoft.com,
        "Adam Roach (E-mail)"
	 
Subject: RE: [Simple] Partial Notifies?
Date: Mon, 24 Sep 2001 14:54:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14532.B278B120"
Content-Length: 11928
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: 

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_01C14532.B278B120
Content-Type: text/plain;
	charset="iso-8859-1"

I realize this has been pushed off to future work,
but I thought I would throw my two cents in now.
I think we could have a reasonable first draft
of a partial NOTIFY mechanism completed in a 
couple of weeks.

>That sure sounds like way too much. The draft I had in mind was
>http://www.ietf.org/internet-drafts/draft-mogul-http-delta-08.txt
>
>This details how various diff algorithms (textual or binary - the
>mechanism works with either) can be used to reduce the message 
>size when
>the client has an old version of some resource. It seems like it should
>be fairly straightforward to apply the same ideas to SIP.

I agree. This is much simpler. Can we make a baseline 
requirement for either vcdiff or gdiff? Both support 
binary data. gdiff seems simpler, but vcdiff supports
compression. If I had to choose, I would mandate support
for vcdiff.

>So here's a sketch of how this might work in SIP.
>
>Clients would indicate support for one or more delta encoding 
>mechanisms
>in SUBSCRIBEs by listing extension token 'delta' in a Supported header
>and the actual "instance manipulations" supported in an A-IM header
>(A-IM stands for Accept-Instance-Manipulations and is defined in the
>http draft as is the IM header used in NOTIFYes):
>
>        SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
>        Supported: delta
>        A-IM: diffe, vcdiff
>        Event: presence
>        ...

Can we use the A-IM: header as an implicit indicator
of support for delta encoding?

>the server would make a note of supported alg's in the subscription
>"record".
>
>The server then has to know what version of a particular subscription
>doc a watcher has received, and when it sends a NOTIFY for a watcher it
>may send only a delta if that guy has indicated support for it, e.g.:
>
>        NOTIFY sip:user@watcherhost.example.com SIP/2.0
>        Require: delta
>        IM: diffe
>        Delta-Base: "abc"
>        Etag: "ghi"
>        Event: presence
>        Content-Type: application/cpim-pidf+xml
>
>        ...
>
>Unlike the http case there's no request in which a version number/tag
>can be carried so presumably the server has to just know what 
>version of
>the presence doc (or whatever) the client knows about, or else assume
>that it knows about the previous version.  If for some reason 
>the client
>doesn't, it would return some error response which would tell 
>the server
>to send the whole resource/document. The error response would also list
>the A-IM and Supported header as appropriate.

I assume we can do something like:
SUBSCRIBE sip:presentity@pres.example.com?Etag="ghi" SIP/2.0
to at least indicate what version the client has at the
time of subscription. The first NOTIFY could then include
either the full state or the appropriate delta encoding to
bring the client in sync with the server. Or use a 
"If-None-Match:" header as in HTTP/1.1. 

I don't see a reason to return an error response to the server.
Do a one-time SUBSCRIBE with no "A-IM" header instead. It costs
two extra messages, but simplifies the life of the presence server.

>
>The Delta-Base header gives the version of the resource that the delta
>should be applied to (and which the client is assumed to possess). The
>ETag gives an identifier for the new resource.

Sounds good.

>
>A presence server that doesn't know about the delta extension just
>ignores the A-IM header and sends the full update every time.

Sounds reasonable. Some things that need to be fleshed out include:

1) How would the server indicate in the initial NOTIFY that the
   client state is already up-to-date? (HTTP 1.1 uses a 
   "304 Not Modified" response code. Do we want to do something
   similar?) This would be particularly useful for a fetch operation.

2) Do we want to allow compression manipulations in addition to the
   delta encoding? Or can we just apply Content-Encodings on top
   of the delta encoding? I assume the later is fine.


/sean

------_=_NextPart_001_01C14532.B278B120
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Partial Notifies?




I realize this has been pushed off to future =
work,

but I thought I would throw my two cents in =
now.

I think we could have a reasonable first =
draft

of a partial NOTIFY mechanism completed in a 

couple of weeks.




>That sure sounds like way too much. The draft I =
had in mind was

>http://www.ietf.org/internet-drafts/draft-mogul-http-d=
elta-08.txt

>

>This details how various diff algorithms =
(textual or binary - the

>mechanism works with either) can be used to =
reduce the message 

>size when

>the client has an old version of some resource. =
It seems like it should

>be fairly straightforward to apply the same =
ideas to SIP.




I agree. This is much simpler. Can we make a baseline =


requirement for either vcdiff or gdiff? Both support =


binary data. gdiff seems simpler, but vcdiff =
supports

compression. If I had to choose, I would mandate =
support

for vcdiff.




>So here's a sketch of how this might work in =
SIP.

>

>Clients would indicate support for one or more =
delta encoding 

>mechanisms

>in SUBSCRIBEs by listing extension token 'delta' =
in a Supported header

>and the actual "instance =
manipulations" supported in an A-IM header

>(A-IM stands for Accept-Instance-Manipulations =
and is defined in the

>http draft as is the IM header used in =
NOTIFYes):

>

>        =
SUBSCRIBE sip:presentity@pres.example.com SIP/2.0

>        =
Supported: delta

>        A-IM: =
diffe, vcdiff

>        =
Event: presence

>        =
...




Can we use the A-IM: header as an implicit =
indicator

of support for delta encoding?




>the server would make a note of supported alg's =
in the subscription

>"record".

>

>The server then has to know what version of a =
particular subscription

>doc a watcher has received, and when it sends a =
NOTIFY for a watcher it

>may send only a delta if that guy has indicated =
support for it, e.g.:

>

>        =
NOTIFY sip:user@watcherhost.example.com SIP/2.0

>        =
Require: delta

>        IM: =
diffe

>        =
Delta-Base: "abc"

>        Etag: =
"ghi"

>        =
Event: presence

>        =
Content-Type: application/cpim-pidf+xml

>

>        =
...

>

>Unlike the http case there's no request in which =
a version number/tag

>can be carried so presumably the server has to =
just know what 

>version of

>the presence doc (or whatever) the client knows =
about, or else assume

>that it knows about the previous version.  =
If for some reason 

>the client

>doesn't, it would return some error response =
which would tell 

>the server

>to send the whole resource/document. The error =
response would also list

>the A-IM and Supported header as =
appropriate.




I assume we can do something like:

SUBSCRIBE =
sip:presentity@pres.example.com?Etag=3D"ghi" SIP/2.0

to at least indicate what version the client has at =
the

time of subscription. The first NOTIFY could then =
include

either the full state or the appropriate delta =
encoding to

bring the client in sync with the server. Or use a =


"If-None-Match:" header as in HTTP/1.1. =





I don't see a reason to return an error response to =
the server.

Do a one-time SUBSCRIBE with no "A-IM" =
header instead. It costs

two extra messages, but simplifies the life of the =
presence server.




>

>The Delta-Base header gives the version of the =
resource that the delta

>should be applied to (and which the client is =
assumed to possess). The

>ETag gives an identifier for the new =
resource.




Sounds good.




>

>A presence server that doesn't know about the =
delta extension just

>ignores the A-IM header and sends the full =
update every time.




Sounds reasonable. Some things that need to be =
fleshed out include:




1) How would the server indicate in the initial =
NOTIFY that the

   client state is already up-to-date? =
(HTTP 1.1 uses a 

   "304 Not Modified" response =
code. Do we want to do something

   similar?) This would be particularly =
useful for a fetch operation.




2) Do we want to allow compression manipulations in =
addition to the

   delta encoding? Or can we just apply =
Content-Encodings on top

   of the delta encoding? I assume the =
later is fine.






/sean





------_=_NextPart_001_01C14532.B278B120--

From jundery@ubiquity.net  Tue Sep 25 06:32:21 2001
Received: from drago1.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 GAA05327
	for ; Tue, 25 Sep 2001 06:32:20 -0400 (EDT)
Received: from mailhost.ubiquity.net by drago1.ubiquity.net
          via smtpd (for [63.113.40.50]) with SMTP; 25 Sep 2001 10:32:13 UT
Received: from jundery ([193.195.52.67]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 25 Sep 2001 11:32:07 +0100
From: "James Undery" 
To: "Jonathan Rosenberg" 
Cc: "SIMPLE" 
Date: Tue, 25 Sep 2001 11:31:38 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-OriginalArrivalTime: 25 Sep 2001 10:32:07.0985 (UTC) FILETIME=[53C03A10:01C145AD]
Content-Length: 747
Subject: [Simple] draft-ietf-simple-presence-03.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: 

Hi,

This is really late I know, and I failed to read the 02 draft at all.

Section 3. Once authenticated I'd expect a 202, once authorised I'd
expect a 200. (I've also a nit about saying "subscription is carried
as any other INVITE" I think "non-INVITE" is better, but I don't
really care about that.)

Section 5.7 The use of the word accepted to have a different meaning
to "202 Accepted", is confusing, authorised is probably better. Also I
believe polite blocking is best done with 202 I think 200 should show
I am authorised (as per previous text in this section).

Section 5.8 Should say "a NOTIFY MUST be sent after a 2xx response to
the SUBSCRIBE has been sent." i.e. s/200/2xx/

Section 5.9 first paragraph only s/200/2xx/

James Undery


From mhammer@cisco.com  Tue Sep 25 10:10:30 2001
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 KAA05995
	for ; Tue, 25 Sep 2001 10:10:29 -0400 (EDT)
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 KAA24112; Tue, 25 Sep 2001 10:10:21 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-135.cisco.com [161.44.87.135])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ARF00855;
	Tue, 25 Sep 2001 10:10:24 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010925101006.00b10e00@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 25 Sep 2001 10:14:19 -0400
To: "James Undery" 
From: Michael Hammer 
Subject: Re: [Simple] draft-ietf-simple-presence-03.txt
Cc: "Jonathan Rosenberg" ,
        "SIMPLE" 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 1284
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: 

Inline.

At 11:31 AM 9/25/2001 +0100, James Undery wrote:
>Hi,
>
>This is really late I know, and I failed to read the 02 draft at all.
>
>Section 3. Once authenticated I'd expect a 202, once authorised I'd
>expect a 200. (I've also a nit about saying "subscription is carried
>as any other INVITE" I think "non-INVITE" is better, but I don't
>really care about that.)
>
>Section 5.7 The use of the word accepted to have a different meaning
>to "202 Accepted", is confusing, authorised is probably better. Also I
>believe polite blocking is best done with 202 I think 200 should show
>I am authorised (as per previous text in this section).

Correct my understanding, but I thought that the 202 was intended to 
acknowledge receipt of the message, but to indicates that authorization has 
not yet occurred, but will at some unspecified time.

It could mean that the originator was authenticated, but authorization 
still occurs later.

Mike

>Section 5.8 Should say "a NOTIFY MUST be sent after a 2xx response to
>the SUBSCRIBE has been sent." i.e. s/200/2xx/
>
>Section 5.9 first paragraph only s/200/2xx/
>
>James Undery
>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple


From jundery@ubiquity.net  Tue Sep 25 10:24:48 2001
Received: from drago1.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 KAA06067
	for ; Tue, 25 Sep 2001 10:24:48 -0400 (EDT)
Received: from mailhost.ubiquity.net by drago1.ubiquity.net
          via smtpd (for [63.113.40.50]) with SMTP; 25 Sep 2001 14:24:41 UT
Received: from jundery ([193.195.52.67]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 25 Sep 2001 15:24:40 +0100
From: "James Undery" 
To: "Michael Hammer" 
Cc: "SIMPLE" 
Subject: RE: [Simple] draft-ietf-simple-presence-03.txt
Date: Tue, 25 Sep 2001 15:24:11 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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)
In-Reply-To: <4.3.2.7.2.20010925101006.00b10e00@cia.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-OriginalArrivalTime: 25 Sep 2001 14:24:40.0619 (UTC) FILETIME=[D02B37B0:01C145CD]
Content-Length: 1159
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: 


> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of
> Michael Hammer

> At 11:31 AM 9/25/2001 +0100, James Undery wrote:

> >Section 5.7 The use of the word accepted to have a
> different meaning
> >to "202 Accepted", is confusing, authorised is probably
> better. Also I
> >believe polite blocking is best done with 202 I think 200
> should show
> >I am authorised (as per previous text in this section).
>
> Correct my understanding, but I thought that the 202 was
> intended to
> acknowledge receipt of the message, but to indicates that
> authorization has
> not yet occurred, but will at some unspecified time.

No you are correct, the problem is with CPIM compliance, where the 202
is a successful subscription and requires an immediate NOTIFY. This
means 202 is a possible means for polite blocking e.g. one scheme
could be the NOTIFY says offline (so the subscriber won't expect
authorisation some time soon) the subscription is then dropped
silently.

> It could mean that the originator was authenticated, but
> authorization
> still occurs later.

Indeed.

James


From petkos@cs.columbia.edu  Tue Sep 25 11:39:27 2001
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 LAA06316
	for ; Tue, 25 Sep 2001 11:39:26 -0400 (EDT)
Received: from dynamo.cs.columbia.edu (dynamo.cs.columbia.edu [128.59.16.4])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA14416
	for ; Tue, 25 Sep 2001 11:39:17 -0400 (EDT)
Received: (from petkos@localhost)
	by dynamo.cs.columbia.edu (8.9.3+Sun/8.9.3) id LAA00380
	for simple@mailman.dynamicsoft.com; Tue, 25 Sep 2001 11:39:16 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200109251539.LAA00380@dynamo.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Tue, 25 Sep 2001 11:39:16 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1556
Subject: [Simple] MESSAGE sessions - over TCP
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: 

There hasn't been any conclusion or rough consensus relating to 
the SIP MESSAGE session model.

It seems that there are two main proposals:

1: Implicit MESSAGE session (no INVITE, just MESSAGEs).

2: Use of INVITE to establish a SIP session and then using
some protocol X to carry the messages. The X protocol
may be SIP MESSAGE, BEEP-based, some new protocol etc.
IESG has ruled out SIP MESSAGE mainly because of three reasons:
- large message overhead in SIP headers 
- lack of congestion control (in UDP only)
- size limitation (in UDP only)
However, SIP MESSAGE over TCP should be ok. Message overhead is an 
issue only in wireless environment, but SIP compression (even UDPcomp) 
eliminates the overhead. 
TCP has also other advantages (like the use of TLS).
 
I really think that something should be decided asap. Option 2 with SIP 
MESSAGE over TCP seems to be ok. It does not have to be the one-and-only
format for next 100 years. If someone really wants it, he can specify 
BEEP-based or whatever additional formats inside a SIP 
session - just like it is possible to create new RTP formats. 
However, SIP session model and MESSAGE over TCP is sufficient for 
many applications and therefore it would be really useful 
to continue at least with that (and have something to use asap).

Since other formats inside a session may be defined later, the real
question is whether the INVITE established session is needed or not.
I think yes. This is similar to audio/video sessions, and it allows e.g.
the use of record-route, mobility etc.

--
Petri

From ROBERTO@windows.microsoft.com  Tue Sep 25 14:08:46 2001
Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA06806
	for ; Tue, 25 Sep 2001 14:08:45 -0400 (EDT)
Received: from 157.54.9.104 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Sep 2001 11:07:04 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 25 Sep 2001 11:07:41 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 25 Sep 2001 11:05:05 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 25 Sep 2001 11:02:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] MESSAGE sessions - over TCP
Date: Tue, 25 Sep 2001 11:02:56 -0700
Message-ID: <2E33960095B58E40A4D3345AB9F65EC103129DB7@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] MESSAGE sessions - over TCP
thread-index: AcFF2L0Cq2Gud3z2SzmmthInQQ/JJgAE0jFw
From: "Robert Osborne" 
To: "Petri K. Koskelainen" ,
        
X-OriginalArrivalTime: 25 Sep 2001 18:02:57.0204 (UTC) FILETIME=[4E577F40:01C145EC]
Content-Length: 2448
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA06806
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: 

Hi,

there is also a third option, which is a combination of the other
two.

3) Use of INVITE to establish an IM session, and then using MESSAGE
over the signalling channel to send the IMs.

This is my preferred option, as it gives all the control and flexibility
of the INVITE, plus the ability to traverse firewalls in a manner that
can be controlled by the administrator.

I agree with you that there should be resolution on this matter as soon
as is possible.

Rob O

>-----Original Message-----
>From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
>Sent: Tuesday, September 25, 2001 8:39 AM
>To: simple@mailman.dynamicsoft.com
>Subject: [Simple] MESSAGE sessions - over TCP
>
>
>
>There hasn't been any conclusion or rough consensus relating to 
>the SIP MESSAGE session model.
>
>It seems that there are two main proposals:
>
>1: Implicit MESSAGE session (no INVITE, just MESSAGEs).
>
>2: Use of INVITE to establish a SIP session and then using
>some protocol X to carry the messages. The X protocol
>may be SIP MESSAGE, BEEP-based, some new protocol etc.
>IESG has ruled out SIP MESSAGE mainly because of three reasons:
>- large message overhead in SIP headers 
>- lack of congestion control (in UDP only)
>- size limitation (in UDP only)
>However, SIP MESSAGE over TCP should be ok. Message overhead is an 
>issue only in wireless environment, but SIP compression (even UDPcomp) 
>eliminates the overhead. 
>TCP has also other advantages (like the use of TLS).
> 
>I really think that something should be decided asap. Option 2 
>with SIP 
>MESSAGE over TCP seems to be ok. It does not have to be the 
>one-and-only
>format for next 100 years. If someone really wants it, he can specify 
>BEEP-based or whatever additional formats inside a SIP 
>session - just like it is possible to create new RTP formats. 
>However, SIP session model and MESSAGE over TCP is sufficient for 
>many applications and therefore it would be really useful 
>to continue at least with that (and have something to use asap).
>
>Since other formats inside a session may be defined later, the real
>question is whether the INVITE established session is needed or not.
>I think yes. This is similar to audio/video sessions, and it 
>allows e.g.
>the use of record-route, mobility etc.
>
>--
>Petri
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

From hgs@cs.columbia.edu  Tue Sep 25 16:41:35 2001
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07310
	for ; Tue, 25 Sep 2001 16:41:29 -0400 (EDT)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id QAA18715;
	Tue, 25 Sep 2001 16:41:14 -0400 (EDT)
Message-ID: <3BB0EBEA.38487B8B@cs.columbia.edu>
Date: Tue, 25 Sep 2001 16:41:14 -0400
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Osborne 
CC: "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] MESSAGE sessions - over TCP
References: <2E33960095B58E40A4D3345AB9F65EC103129DB7@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2490
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: 

Robert Osborne wrote:
> 
> Hi,
> 
> there is also a third option, which is a combination of the other
> two.
> 
> 3) Use of INVITE to establish an IM session, and then using MESSAGE
> over the signalling channel to send the IMs.

This only works if the signaling channel is TCP, per the
congestion-control requirement. It doesn't seem clean to decide that "my
SDP contains a MESSAGE session, I better use TCP for signaling", but I
suppose that's mostly aesthetics.


> 
> This is my preferred option, as it gives all the control and flexibility
> of the INVITE, plus the ability to traverse firewalls in a manner that
> can be controlled by the administrator.

> >2: Use of INVITE to establish a SIP session and then using
> >some protocol X to carry the messages. The X protocol
> >may be SIP MESSAGE, BEEP-based, some new protocol etc.
> >IESG has ruled out SIP MESSAGE mainly because of three reasons:
> >- large message overhead in SIP headers
> >- lack of congestion control (in UDP only)
> >- size limitation (in UDP only)
> >However, SIP MESSAGE over TCP should be ok. Message overhead is an
> >issue only in wireless environment, but SIP compression (even UDPcomp)
> >eliminates the overhead.
> >TCP has also other advantages (like the use of TLS).
> >
> >I really think that something should be decided asap. Option 2
> >with SIP
> >MESSAGE over TCP seems to be ok. It does not have to be the
> >one-and-only
> >format for next 100 years. If someone really wants it, he can specify
> >BEEP-based or whatever additional formats inside a SIP
> >session - just like it is possible to create new RTP formats.
> >However, SIP session model and MESSAGE over TCP is sufficient for
> >many applications and therefore it would be really useful
> >to continue at least with that (and have something to use asap).
> >
> >Since other formats inside a session may be defined later, the real
> >question is whether the INVITE established session is needed or not.
> >I think yes. This is similar to audio/video sessions, and it
> >allows e.g.
> >the use of record-route, mobility etc.
> >
> >--
> >Petri
> >_______________________________________________
> >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

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From pkyzivat@cisco.com  Tue Sep 25 17:37:45 2001
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 RAA07508
	for ; Tue, 25 Sep 2001 17:37:44 -0400 (EDT)
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 f8PLaw908560;
	Tue, 25 Sep 2001 17:36:58 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB21873 (AUTH pkyzivat);
	Tue, 25 Sep 2001 17:38:32 -0400 (EDT)
Message-ID: <3BB0F8CC.9DAAFE5F@cisco.com>
Date: Tue, 25 Sep 2001 17:36:12 -0400
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] Updated presence spec
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1625
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: 

Jonathan,

In reviewing the new document, I noticed something troublesome about the
migration description:

It suggests that a PUA can indicate ability to act as a PA by sending a
REGISTER with a caller preferences "methods" parameter listing
SUBSCRIBE, and goes on to say that a PUA MUST NOT do this unless it
knows definitively that it has complete presence information for a user.
The problem with this is that the PUA may also be a UA for reasons other
than presence, and may need to support SUBSCRIBE for event packages
other than presence. Then it is stuck - it is forced to implement PUA
functionality as a precondition to advertising support for the other
event package.

	Paul Kyzivat

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> I've just submitted an update to the presence spec based on comments
> received during the last call period. Until it appears in the archives, you
> can pick up a copy at:
> 
> http://www.jdrosen.net/papers/draft-ietf-simple-presence-03.txt
> 
> There are no open issues that I am aware of. Hopefully this one will go to
> IESG.
> 
> 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 nsyracus@cnri.reston.va.us  Wed Sep 26 07:08:55 2001
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 HAA09928
	for ; Wed, 26 Sep 2001 07:08:49 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12779;
	Wed, 26 Sep 2001 07:08:27 -0400 (EDT)
Message-Id: <200109261108.HAA12779@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
Date: Wed, 26 Sep 2001 07:08:27 -0400
Content-Length: 3000
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-03.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: SIP Extensions for Presence
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-presence-03.txt
	Pages		: 37
	Date		: 25-Sep-01
	
This document proposes an extension to SIP for subscriptions and
notifications of user presence. User presence is defined as the
willingness and ability of a user to communicate with other users on
the network. Historically, presence has been limited to 'on-line' and
'off-line' indicators; the notion of presence here is broader.
Subscriptions and notifications of user presence are supported by
defining an event package within the general SIP event notification
framework. This protocol is also compliant with the Common Presence
and Instant Messaging (CPIM) framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-presence-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-presence-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010925111227.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010925111227.I-D@ietf.org>

--OtherAccess--

--NextPart--



From Dror@vocaltec.com  Wed Sep 26 07:28:32 2001
Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10026
	for ; Wed, 26 Sep 2001 07:28:30 -0400 (EDT)
From: Dror@vocaltec.com
Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135])
	by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id NAA28327;
	Wed, 26 Sep 2001 13:27:45 +0200 (IST)
To: "Petri K. Koskelainen" 
Cc: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] MESSAGE sessions - over TCP
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: 
Date: Wed, 26 Sep 2001 13:24:50 +0200
X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 09/26/2001 01:24:51 PM,
	Serialize complete at 09/26/2001 01:24:51 PM
Content-Type: multipart/alternative; boundary="=_alternative 00443EF042256AD3_="
Content-Length: 7124
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: 

This is a multipart message in MIME format.
--=_alternative 00443EF042256AD3_=
Content-Type: text/plain; charset="us-ascii"

I think there is yet another option, which I haven't seen discussed, and 
that is to use "direct message first, session later"..

When I'm sending a single message, opening a point-to-point session via 
INVITE has a lot of overhead, and also takes time and some system 
resources. The entire process of creating a session its by far larger than 
my "Hi, meet me for lunch" message. 
also, passing MESSAGE or INVITE from the SIP network perspective is almost 
the same (and mabe a bit in favour of MESSAGE...)
This is why I wouldn't send a email in the first place - since its a 
heavyweight solution.

If the other side will want to start a chat, only then should a full 
messaging session be opened.

Of course, there should be a limitation on the size of this initial 
message, which will require a use of p2p session for sending a message 
above a given size (e.g. equivalent to a single UDP packet) 





"Petri K. Koskelainen" 
Sent by: simple-admin@mailman.dynamicsoft.com
25/09/2001 17:39

 
        To:     simple@mailman.dynamicsoft.com
        cc: 
        Subject:        [Simple] MESSAGE sessions - over TCP



There hasn't been any conclusion or rough consensus relating to
the SIP MESSAGE session model.

It seems that there are two main proposals:

1: Implicit MESSAGE session (no INVITE, just MESSAGEs).

2: Use of INVITE to establish a SIP session and then using
some protocol X to carry the messages. The X protocol
may be SIP MESSAGE, BEEP-based, some new protocol etc.
IESG has ruled out SIP MESSAGE mainly because of three reasons:
- large message overhead in SIP headers
- lack of congestion control (in UDP only)
- size limitation (in UDP only)
However, SIP MESSAGE over TCP should be ok. Message overhead is an
issue only in wireless environment, but SIP compression (even UDPcomp)
eliminates the overhead.
TCP has also other advantages (like the use of TLS).

I really think that something should be decided asap. Option 2 with SIP
MESSAGE over TCP seems to be ok. It does not have to be the one-and-only
format for next 100 years. If someone really wants it, he can specify
BEEP-based or whatever additional formats inside a SIP
session - just like it is possible to create new RTP formats.
However, SIP session model and MESSAGE over TCP is sufficient for
many applications and therefore it would be really useful
to continue at least with that (and have something to use asap).

Since other formats inside a session may be defined later, the real
question is whether the INVITE established session is needed or not.
I think yes. This is similar to audio/video sessions, and it allows e.g.
the use of record-route, mobility etc.

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


--=_alternative 00443EF042256AD3_=
Content-Type: text/html; charset="us-ascii"



I think there is yet another option, which I haven't seen discussed, and that is to use "direct message first, session later"..



When I'm sending a single message, opening a point-to-point session via INVITE has a lot of overhead, and also takes time and some system resources. The entire process of creating a session its by far larger than my "Hi, meet me for lunch" message. 

also, passing MESSAGE or INVITE from the SIP network perspective is almost the same (and mabe a bit in favour of MESSAGE...)

This is why I wouldn't send a email in the first place - since its a heavyweight solution.



If the other side will want to start a chat, only then should a full messaging session be opened.



Of course, there should be a limitation on the size of this initial message, which will require a use of p2p session for sending a message above a given size (e.g. equivalent to a single UDP packet) 













"Petri K. Koskelainen" <petkos@cs.columbia.edu>

Sent by: simple-admin@mailman.dynamicsoft.com

25/09/2001 17:39



        

        To:        simple@mailman.dynamicsoft.com

        cc:        

        Subject:        [Simple] MESSAGE sessions - over TCP








There hasn't been any conclusion or rough consensus relating to

the SIP MESSAGE session model.



It seems that there are two main proposals:



1: Implicit MESSAGE session (no INVITE, just MESSAGEs).



2: Use of INVITE to establish a SIP session and then using

some protocol X to carry the messages. The X protocol

may be SIP MESSAGE, BEEP-based, some new protocol etc.

IESG has ruled out SIP MESSAGE mainly because of three reasons:

- large message overhead in SIP headers

- lack of congestion control (in UDP only)

- size limitation (in UDP only)

However, SIP MESSAGE over TCP should be ok. Message overhead is an

issue only in wireless environment, but SIP compression (even UDPcomp)

eliminates the overhead.

TCP has also other advantages (like the use of TLS).



I really think that something should be decided asap. Option 2 with SIP

MESSAGE over TCP seems to be ok. It does not have to be the one-and-only

format for next 100 years. If someone really wants it, he can specify

BEEP-based or whatever additional formats inside a SIP

session - just like it is possible to create new RTP formats.

However, SIP session model and MESSAGE over TCP is sufficient for

many applications and therefore it would be really useful

to continue at least with that (and have something to use asap).



Since other formats inside a session may be defined later, the real

question is whether the INVITE established session is needed or not.

I think yes. This is similar to audio/video sessions, and it allows e.g.

the use of record-route, mobility etc.



--

Petri

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple




--=_alternative 00443EF042256AD3_=--

From Avshalom@ubique.com  Wed Sep 26 09:37:27 2001
Received: from ubqgate02.lotus.com ([194.196.39.196])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10440;
	Wed, 26 Sep 2001 09:37:25 -0400 (EDT)
From: Avshalom@ubique.com
Subject: RE: [Simple] MESSAGE sessions - over TCP
To: "Robert Osborne" 
Cc: "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Wed, 26 Sep 2001 15:35:33 +0200
X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at
 26/09/2001 15:36:07
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 4248
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: 

Agree with both (MESSAGE over signalling channel and a asap resolution).

avshalom
Sametime/Lotus/IBM



                                                                                                                                
                    "Robert Osborne"                                                                                            
                    ,                  
                    .com>                                                                       
                    Sent by:                          cc:                                                                       
                    simple-admin@mailman.dynam        Subject:     RE: [Simple] MESSAGE sessions - over TCP                     
                    icsoft.com                                                                                                  
                                                                                                                                
                                                                                                                                
                    25/09/2001 20:02                                                                                            
                                                                                                                                
                                                                                                                                



Hi,

there is also a third option, which is a combination of the other
two.

3) Use of INVITE to establish an IM session, and then using MESSAGE
over the signalling channel to send the IMs.

This is my preferred option, as it gives all the control and flexibility
of the INVITE, plus the ability to traverse firewalls in a manner that
can be controlled by the administrator.

I agree with you that there should be resolution on this matter as soon
as is possible.

Rob O

>-----Original Message-----
>From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
>Sent: Tuesday, September 25, 2001 8:39 AM
>To: simple@mailman.dynamicsoft.com
>Subject: [Simple] MESSAGE sessions - over TCP
>
>
>
>There hasn't been any conclusion or rough consensus relating to
>the SIP MESSAGE session model.
>
>It seems that there are two main proposals:
>
>1: Implicit MESSAGE session (no INVITE, just MESSAGEs).
>
>2: Use of INVITE to establish a SIP session and then using
>some protocol X to carry the messages. The X protocol
>may be SIP MESSAGE, BEEP-based, some new protocol etc.
>IESG has ruled out SIP MESSAGE mainly because of three reasons:
>- large message overhead in SIP headers
>- lack of congestion control (in UDP only)
>- size limitation (in UDP only)
>However, SIP MESSAGE over TCP should be ok. Message overhead is an
>issue only in wireless environment, but SIP compression (even UDPcomp)
>eliminates the overhead.
>TCP has also other advantages (like the use of TLS).
>
>I really think that something should be decided asap. Option 2
>with SIP
>MESSAGE over TCP seems to be ok. It does not have to be the
>one-and-only
>format for next 100 years. If someone really wants it, he can specify
>BEEP-based or whatever additional formats inside a SIP
>session - just like it is possible to create new RTP formats.
>However, SIP session model and MESSAGE over TCP is sufficient for
>many applications and therefore it would be really useful
>to continue at least with that (and have something to use asap).
>
>Since other formats inside a session may be defined later, the real
>question is whether the INVITE established session is needed or not.
>I think yes. This is similar to audio/video sessions, and it
>allows e.g.
>the use of record-route, mobility etc.
>
>--
>Petri
>_______________________________________________
>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 Markus.Isomaki@nokia.com  Wed Sep 26 10:11:07 2001
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 KAA10581
	for ; Wed, 26 Sep 2001 10:11:05 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8QEBS720868
	for ; Wed, 26 Sep 2001 17:11:28 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Wed, 26 Sep 2001 17:10:53 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id ; Wed, 26 Sep 2001 17:10:53 +0300
Message-ID: <034272783A93C944A6CA1D87FBF6F49E107F56@esebe014.NOE.Nokia.com>
To: simple@mailman.dynamicsoft.com
Date: Wed, 26 Sep 2001 17:10:51 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1161
Subject: [Simple] Different verbosity levels of presence 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: 

Hi,

I have a couple of basic questions about the subscription of presence
information. 

What I think would be required is that a watcher is able to subscribe to
different "verbosity levels" of presence information of a given presentity.
If the presence document is large having a lot of attributes and changing
often, it might be an overkill in wireless and small handset environment.
That's why it would be nice to be able to subscribe either to the full or
partial presence state of a presentity.

Can this be done by doing different SIP event packages with different levels
of presence information associated with them or is there some
architecturally better way? The watcher would then decide which one of them
to subscribe.

Another question is about subscription to a list of presentities (buddy list
etc.). I guess there is no sound way of doing that in a single SIP subscribe
transaction, so again some kind of sub-package would be needed? But even in
that case how is the list of URIs delivered? Is this outside the scope of
SIP? Again the problem raises from the desire to protect the limited
bandwith available over the air.

Best Regards,
	Markus

From Markus.Isomaki@nokia.com  Wed Sep 26 10:36:30 2001
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 KAA10704
	for ; Wed, 26 Sep 2001 10:36:29 -0400 (EDT)
From: Markus.Isomaki@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 f8QEaq317993
	for ; Wed, 26 Sep 2001 17:36:52 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 26 Sep 2001 17:36:20 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id ; Wed, 26 Sep 2001 17:35:30 +0300
Message-ID: <034272783A93C944A6CA1D87FBF6F49E107F58@esebe014.NOE.Nokia.com>
To: simple@mailman.dynamicsoft.com, rohc@cdt.luth.se
Subject: RE: [Simple] MESSAGE sessions - over TCP
Date: Wed, 26 Sep 2001 17:35:22 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2600
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: 

Hi,

> However, SIP MESSAGE over TCP should be ok. Message overhead is an 
> issue only in wireless environment, but SIP compression (even 
> UDPcomp) 
> eliminates the overhead. 

If we have SIP MESSAGEs over TCP directly between UAs, is SIP compression
applicable? Usually the compression is meant to be used between a UA and the
(outbound) proxy, but is there anything hindering the End-to-End case? I
suppose the UAs would have to agree to use compression in SDP as part of the
transport description?

Is this part of the signaling compression requirements?

Rgs,
	Markus

> -----Original Message-----
> From: ext Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> Sent: 25 September, 2001 18:39
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] MESSAGE sessions - over TCP
> 
> 
> 
> There hasn't been any conclusion or rough consensus relating to 
> the SIP MESSAGE session model.
> 
> It seems that there are two main proposals:
> 
> 1: Implicit MESSAGE session (no INVITE, just MESSAGEs).
> 
> 2: Use of INVITE to establish a SIP session and then using
> some protocol X to carry the messages. The X protocol
> may be SIP MESSAGE, BEEP-based, some new protocol etc.
> IESG has ruled out SIP MESSAGE mainly because of three reasons:
> - large message overhead in SIP headers 
> - lack of congestion control (in UDP only)
> - size limitation (in UDP only)
> However, SIP MESSAGE over TCP should be ok. Message overhead is an 
> issue only in wireless environment, but SIP compression (even 
> UDPcomp) 
> eliminates the overhead. 
> TCP has also other advantages (like the use of TLS).
>  
> I really think that something should be decided asap. Option 
> 2 with SIP 
> MESSAGE over TCP seems to be ok. It does not have to be the 
> one-and-only
> format for next 100 years. If someone really wants it, he can specify 
> BEEP-based or whatever additional formats inside a SIP 
> session - just like it is possible to create new RTP formats. 
> However, SIP session model and MESSAGE over TCP is sufficient for 
> many applications and therefore it would be really useful 
> to continue at least with that (and have something to use asap).
> 
> Since other formats inside a session may be defined later, the real
> question is whether the INVITE established session is needed or not.
> I think yes. This is similar to audio/video sessions, and it 
> allows e.g.
> the use of record-route, mobility etc.
> 
> --
> Petri
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From lwc@roke.co.uk  Wed Sep 26 11:51:49 2001
Received: from cundall.co.uk ([193.118.202.13])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA10972
	for ; Wed, 26 Sep 2001 11:51:40 -0400 (EDT)
Received: from [193.118.192.55] ([193.118.192.55] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000056856; Wed, 26 Sep 2001 16:52:51 +0100
Mime-Version: 1.0
X-Sender: lwc@193.118.192.24
Message-Id: 
In-Reply-To: 
 <034272783A93C944A6CA1D87FBF6F49E107F58@esebe014.NOE.Nokia.com>
References: <034272783A93C944A6CA1D87FBF6F49E107F58@esebe014.NOE.Nokia.com>
Date: Wed, 26 Sep 2001 16:51:59 +0100
To: Markus.Isomaki@nokia.com, simple@mailman.dynamicsoft.com, rohc@cdt.luth.se
From: Lawrence Conroy 
Subject: [rohc] RE: [Simple] MESSAGE sessions - over TCP
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Content-Length: 1203
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: 

At 5:35 pm +0300 26/9/01, Markus.Isomaki@nokia.com wrote:
>Hi,
>
>>  However, SIP MESSAGE over TCP should be ok. Message overhead is an
>>  issue only in wireless environment, but SIP compression (even
>>  UDPcomp)
>>  eliminates the overhead.
>
>If we have SIP MESSAGEs over TCP directly between UAs, is SIP compression
>applicable? Usually the compression is meant to be used between a UA and the
>(outbound) proxy, but is there anything hindering the End-to-End case? I
>suppose the UAs would have to agree to use compression in SDP as part of the
>transport description?
>
>Is this part of the signaling compression requirements?
>
>Rgs,
>	Markus
>
Hi there,
   my understanding was that: Initially, the end systems agree "out of band"
(e.g the SUAS listens on a particular port for compressed messages).
This should work for TCP or UDP.

Don't believe that anyone has seriously suggested yet another addition to
SDP to indicate compressed SIP should be used (i.e. to negotiate).
The goal is to compress even the initial SIP message; this would not be
possible if negotiation were carried in SDP (carried inside a SIP message :).

BR,
   Lawrence
-- 
lwc@roke.co.uk: +44 1794 833666:::

From zhigang.c.liu@nokia.com  Wed Sep 26 13:10:05 2001
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 NAA11323
	for ; Wed, 26 Sep 2001 13:10:04 -0400 (EDT)
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 f8QHAR707754
	for ; Wed, 26 Sep 2001 20:10:27 +0300 (EET DST)
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 f8QHA6C18212
	for ; Wed, 26 Sep 2001 12:10:06 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 26 Sep 2001 12:08:49 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 26 Sep 2001 12:08:48 -0500
content-class: urn:content-classes:message
Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP
Date: Wed, 26 Sep 2001 12:08:48 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rohc] RE: [Simple] MESSAGE sessions - over TCP
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFGo//CsGUNb7KWEdWBTABQi2X+DwAAz5GA
From: "Liu Zhigang.C (NRC/Dallas)" 
To: "'ext Lawrence Conroy'" ,
        "Isomaki Markus (NRC/Helsinki)" ,
        , 
X-OriginalArrivalTime: 26 Sep 2001 17:08:48.0786 (UTC) FILETIME=[E88BFF20:01C146AD]
Content-Length: 3125
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA11323
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: 

Hi,

I agree with Lawrence on the need of "out of band" negotiation.
Another reason is that the SigComp should be generic (i.e. not
only for SIP, also see notes below). During the negotiation, the 
two end systems can do the following:

1) Agree on whether to use compression

2) Agree on parameters. E.g. over which TCP or UDP port number
the payload should be compressed. What application-level protocol
is carried over that port number (SIP or something else). This
allows both end systems to setup the right static dictionary.
And perhaps other parameters related to the compression algorithm.

3) Pre-populate of the dictionary. This can boost the compression
ratio for the first several messages.

(Some of the ideas are described in SCRIBE,
http://www.ietf.org/internet-drafts/draft-liu-rohc-scribe-01.txt)

Note that although the negotiation procedure is out of SIP (again,
to be generic), it may be triggered by SIP as a service request. 
Also, the negotiation only needs to be done once if both endpoints 
agree to keep the negotiated results. However, the two endpoints 
should periodically verify they are still in sync (e.g. between 
sessions when traffic is relatively idle).

Re Markus' question about the requirement, the location of the peer
compression entities is not addressed (to make SigComp generic).
However, the need of negotiation is mentioned/implied in current
requirement draft (e.g. 3a - compatibility, 6 - Scalability).

BR,
Zhigang

> -----Original Message-----
> From: ext Lawrence Conroy [mailto:lwc@roke.co.uk]
> Sent: September 26, 2001 10:52 AM
> To: Isomaki Markus (NRC/Helsinki); simple@mailman.dynamicsoft.com;
> rohc@cdt.luth.se
> Subject: [rohc] RE: [Simple] MESSAGE sessions - over TCP
> 
> 
> At 5:35 pm +0300 26/9/01, Markus.Isomaki@nokia.com wrote:
> >Hi,
> >
> >>  However, SIP MESSAGE over TCP should be ok. Message overhead is an
> >>  issue only in wireless environment, but SIP compression (even
> >>  UDPcomp)
> >>  eliminates the overhead.
> >
> >If we have SIP MESSAGEs over TCP directly between UAs, is 
> SIP compression
> >applicable? Usually the compression is meant to be used 
> between a UA and the
> >(outbound) proxy, but is there anything hindering the 
> End-to-End case? I
> >suppose the UAs would have to agree to use compression in 
> SDP as part of the
> >transport description?
> >
> >Is this part of the signaling compression requirements?
> >
> >Rgs,
> >	Markus
> >
> Hi there,
>    my understanding was that: Initially, the end systems 
> agree "out of band"
> (e.g the SUAS listens on a particular port for compressed messages).
> This should work for TCP or UDP.
> 
> Don't believe that anyone has seriously suggested yet another 
> addition to
> SDP to indicate compressed SIP should be used (i.e. to negotiate).
> The goal is to compress even the initial SIP message; this 
> would not be
> possible if negotiation were carried in SDP (carried inside a 
> SIP message :).
> 
> BR,
>    Lawrence
> -- 
> lwc@roke.co.uk: +44 1794 833666:::
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
> 

From petkos@cs.columbia.edu  Wed Sep 26 13:20:59 2001
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 NAA11379
	for ; Wed, 26 Sep 2001 13:20:56 -0400 (EDT)
Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA02377;
	Wed, 26 Sep 2001 13:20:43 -0400 (EDT)
Received: (from petkos@localhost)
	by disco.cs.columbia.edu (8.9.3/8.9.3) id NAA05697;
	Wed, 26 Sep 2001 13:20:41 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200109261720.NAA05697@disco.cs.columbia.edu>
Subject: Re: [Simple] MESSAGE sessions - over TCP
To: Dror@vocaltec.com
Date: Wed, 26 Sep 2001 13:20:41 -0400 (EDT)
Cc: simple@mailman.dynamicsoft.com
In-Reply-To:  from "Dror@vocaltec.com" at Sep 26, 2001 01:24:50 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 8315
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: 


If you have just one message to send, you don't have to 
establish a session. Just send a MESSAGE. 
No need for INVITE then.

In general, IM session is just another media stream just like 
audio or video stream.
Often it is established at the same time than the
audio and video streams (one m line for each media stream).
This is the ideal situation since it allows all the
control and flexibility of INVITE for IM session 
(e.g. mobility, record-route, multi-party IM..).

Still, one-shot MESSAGEs can be sent if someone does
not want to use the session model.

Is there a consensus that INVITE-established IM messaging 
session idea is ok ? (in addition to one shot MESSAGEs)


If we can agree on that, then we can continue with other problems, like:
- messaging protocol/format inside a session (e.g. SIP MESSAGE over TCP)
- direct end-to-end vs. via signaling proxies vs. via IM servers 
- compression (hopefully this does not have to be discussed here)
 
There should be a resolution on this asap.

--
Petri

> I think there is yet another option, which I haven't seen discussed, and 
> that is to use "direct message first, session later"..
> 
> When I'm sending a single message, opening a point-to-point session via 
> INVITE has a lot of overhead, and also takes time and some system 
> resources. The entire process of creating a session its by far larger than 
> my "Hi, meet me for lunch" message. 
> also, passing MESSAGE or INVITE from the SIP network perspective is almost 
> the same (and mabe a bit in favour of MESSAGE...)
> This is why I wouldn't send a email in the first place - since its a 
> heavyweight solution.
> 
> If the other side will want to start a chat, only then should a full 
> messaging session be opened.
> 
> Of course, there should be a limitation on the size of this initial 
> message, which will require a use of p2p session for sending a message 
> above a given size (e.g. equivalent to a single UDP packet) 
> 
> 
> 
> 
> 
> "Petri K. Koskelainen" 
> Sent by: simple-admin@mailman.dynamicsoft.com
> 25/09/2001 17:39
> 
>  
>         To:     simple@mailman.dynamicsoft.com
>         cc: 
>         Subject:        [Simple] MESSAGE sessions - over TCP
> 
> 
> 
> There hasn't been any conclusion or rough consensus relating to
> the SIP MESSAGE session model.
> 
> It seems that there are two main proposals:
> 
> 1: Implicit MESSAGE session (no INVITE, just MESSAGEs).
> 
> 2: Use of INVITE to establish a SIP session and then using
> some protocol X to carry the messages. The X protocol
> may be SIP MESSAGE, BEEP-based, some new protocol etc.
> IESG has ruled out SIP MESSAGE mainly because of three reasons:
> - large message overhead in SIP headers
> - lack of congestion control (in UDP only)
> - size limitation (in UDP only)
> However, SIP MESSAGE over TCP should be ok. Message overhead is an
> issue only in wireless environment, but SIP compression (even UDPcomp)
> eliminates the overhead.
> TCP has also other advantages (like the use of TLS).
> 
> I really think that something should be decided asap. Option 2 with SIP
> MESSAGE over TCP seems to be ok. It does not have to be the one-and-only
> format for next 100 years. If someone really wants it, he can specify
> BEEP-based or whatever additional formats inside a SIP
> session - just like it is possible to create new RTP formats.
> However, SIP session model and MESSAGE over TCP is sufficient for
> many applications and therefore it would be really useful
> to continue at least with that (and have something to use asap).
> 
> Since other formats inside a session may be defined later, the real
> question is whether the INVITE established session is needed or not.
> I think yes. This is similar to audio/video sessions, and it allows e.g.
> the use of record-route, mobility etc.
> 
> --
> Petri
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 
> --=_alternative 00443EF042256AD3_=
> Content-Type: text/html; charset="us-ascii"
> 
> 
> 
I think there is yet another option, which I haven't seen discussed, and that is to use "direct message first, session later"..
> 

> 
When I'm sending a single message, opening a point-to-point session via INVITE has a lot of overhead, and also takes time and some system resources. The entire process of creating a session its by far larger than my "Hi, meet me for lunch" message. 
> 
also, passing MESSAGE or INVITE from the SIP network perspective is almost the same (and mabe a bit in favour of MESSAGE...)
> 
This is why I wouldn't send a email in the first place - since its a heavyweight solution.
> 

> 
If the other side will want to start a chat, only then should a full messaging session be opened.

> 
> 
Of course, there should be a limitation on the size of this initial message, which will require a use of p2p session for sending a message above a given size (e.g. equivalent to a single UDP packet) 
> 

> 

> 

> 

> 
> 
> 

> "Petri K. Koskelainen" <petkos@cs.columbia.edu>
> 
Sent by: simple-admin@mailman.dynamicsoft.com
> 
25/09/2001 17:39
> 

> 
        
> 
        To:        simple@mailman.dynamicsoft.com
> 
        cc:        
> 
        Subject:        [Simple] MESSAGE sessions - over TCP

> 

> 

> 

> 
There hasn't been any conclusion or rough consensus relating to

> the SIP MESSAGE session model.

> 
> 
It seems that there are two main proposals:

> 
> 
1: Implicit MESSAGE session (no INVITE, just MESSAGEs).

> 
> 
2: Use of INVITE to establish a SIP session and then using

> some protocol X to carry the messages. The X protocol

> may be SIP MESSAGE, BEEP-based, some new protocol etc.

> IESG has ruled out SIP MESSAGE mainly because of three reasons:

> - large message overhead in SIP headers

> - lack of congestion control (in UDP only)

> - size limitation (in UDP only)

> However, SIP MESSAGE over TCP should be ok. Message overhead is an

> issue only in wireless environment, but SIP compression (even UDPcomp)

> eliminates the overhead.

> TCP has also other advantages (like the use of TLS).

> 
> 
I really think that something should be decided asap. Option 2 with SIP

> MESSAGE over TCP seems to be ok. It does not have to be the one-and-only

> format for next 100 years. If someone really wants it, he can specify

> BEEP-based or whatever additional formats inside a SIP

> session - just like it is possible to create new RTP formats.

> However, SIP session model and MESSAGE over TCP is sufficient for

> many applications and therefore it would be really useful

> to continue at least with that (and have something to use asap).

> 
> 
Since other formats inside a session may be defined later, the real

> question is whether the INVITE established session is needed or not.

> I think yes. This is similar to audio/video sessions, and it allows e.g.

> the use of record-route, mobility etc.

> 
> 
--

> Petri

> _______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

> 

> --=_alternative 00443EF042256AD3_=--
> 


From sriramp@nortelnetworks.com  Wed Sep 26 13:30:27 2001
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 NAA11438
	for ; Wed, 26 Sep 2001 13:30:26 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA07648
	for ; Wed, 26 Sep 2001 12:30:17 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 26 Sep 2001 12:23:31 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 26 Sep 2001 12:29:52 -0500
Message-ID: <9A9367D1556AD21182C40000F80930AB04411DE4@crchy28b.us.nortel.com>
From: "Sriram Parameswar" 
To: "'Lawrence Conroy'" , Markus.Isomaki@nokia.com,
        simple@mailman.dynamicsoft.com, rohc@cdt.luth.se
Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP
Date: Wed, 26 Sep 2001 12:29:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C146B0.D832A270"
X-Orig: 
Content-Length: 5941
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: 

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_01C146B0.D832A270
Content-Type: text/plain;
	charset="iso-8859-1"

Comment in-line; pardon the plug!

Sriram

-----Original Message-----
From: Lawrence Conroy [mailto:lwc@roke.co.uk]
Sent: Wednesday, September 26, 2001 10:52 AM
To: Markus.Isomaki@nokia.com; simple@mailman.dynamicsoft.com;
rohc@cdt.luth.se
Subject: [rohc] RE: [Simple] MESSAGE sessions - over TCP


At 5:35 pm +0300 26/9/01, Markus.Isomaki@nokia.com wrote:
>Hi,
>
>>  However, SIP MESSAGE over TCP should be ok. Message overhead is an
>>  issue only in wireless environment, but SIP compression (even
>>  UDPcomp)
>>  eliminates the overhead.
>
>If we have SIP MESSAGEs over TCP directly between UAs, is SIP compression
>applicable? Usually the compression is meant to be used between a UA and
the
>(outbound) proxy, but is there anything hindering the End-to-End case? I
>suppose the UAs would have to agree to use compression in SDP as part of
the
>transport description?
>
>Is this part of the signaling compression requirements?
>
>Rgs,
>	Markus
>
Hi there,
   my understanding was that: Initially, the end systems agree "out of band"
(e.g the SUAS listens on a particular port for compressed messages).
This should work for TCP or UDP.

Don't believe that anyone has seriously suggested yet another addition to
SDP to indicate compressed SIP should be used (i.e. to negotiate).
The goal is to compress even the initial SIP message; this would not be
possible if negotiation were carried in SDP (carried inside a SIP message
:).

<> 
Please see
http://search.ietf.org/internet-drafts/draft-spbs-sip-negotiate-00.txt
<>
BR,
   Lawrence
-- 
lwc@roke.co.uk: +44 1794 833666:::
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

------_=_NextPart_001_01C146B0.D832A270
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP




Comment in-line; pardon the plug!




Sriram




-----Original Message-----

From: Lawrence Conroy [mailto:lwc@roke.co.uk]

Sent: Wednesday, September 26, 2001 10:52 AM

To: Markus.Isomaki@nokia.com; =
simple@mailman.dynamicsoft.com;

rohc@cdt.luth.se

Subject: [rohc] RE: [Simple] MESSAGE sessions - over =
TCP






At 5:35 pm +0300 26/9/01, Markus.Isomaki@nokia.com =
wrote:

>Hi,

>

>>  However, SIP MESSAGE over TCP should =
be ok. Message overhead is an

>>  issue only in wireless environment, =
but SIP compression (even

>>  UDPcomp)

>>  eliminates the overhead.

>

>If we have SIP MESSAGEs over TCP directly =
between UAs, is SIP compression

>applicable? Usually the compression is meant to =
be used between a UA and the

>(outbound) proxy, but is there anything =
hindering the End-to-End case? I

>suppose the UAs would have to agree to use =
compression in SDP as part of the

>transport description?

>

>Is this part of the signaling compression =
requirements?

>

>Rgs,

>       =
Markus

>

Hi there,

   my understanding was that: Initially, =
the end systems agree "out of band"

(e.g the SUAS listens on a particular port for =
compressed messages).

This should work for TCP or UDP.




Don't believe that anyone has seriously suggested yet =
another addition to

SDP to indicate compressed SIP should be used (i.e. =
to negotiate).

The goal is to compress even the initial SIP =
message; this would not be

possible if negotiation were carried in SDP (carried =
inside a SIP message :).




<<Sriram>> 

Please see http://search.ietf.org/internet-drafts/draft-spbs-sip-=
negotiate-00.txt

<</Sriram>>

BR,

   Lawrence

-- 

lwc@roke.co.uk: +44 1794 833666::<my =
opinions>:

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple=






------_=_NextPart_001_01C146B0.D832A270--

From Vasilis.Polychronidis@Openwave.com  Wed Sep 26 15:49:50 2001
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 PAA11880
	for ; Wed, 26 Sep 2001 15:49:45 -0400 (EDT)
Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26])
          by oe-mp1.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20010926194725.IGXT13960.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>;
          Wed, 26 Sep 2001 14:47:25 -0500
Received: from Openwave.com ([4.41.19.164]) by oe-ismta1.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20010926194928.HOAE1932.oe-ismta1.bizmailsrvcs.net@Openwave.com>;
          Wed, 26 Sep 2001 14:49:28 -0500
Message-ID: <3BB23146.21D10A68@Openwave.com>
Date: Wed, 26 Sep 2001 12:49:26 -0700
From: Vasilis Polychronidis 
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Petri K. Koskelainen" 
CC: Dror@vocaltec.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] MESSAGE sessions - over TCP
References: <200109261720.NAA05697@disco.cs.columbia.edu>
Content-Type: multipart/alternative;
 boundary="------------494DDD16B06BAFD7C209F186"
Content-Length: 20784
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: 

--------------494DDD16B06BAFD7C209F186
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Petri,
See comments inline:

BR,

-Vasilis

"Petri K. Koskelainen" wrote:

> If you have just one message to send, you don't have to
> establish a session. Just send a MESSAGE.
> No need for INVITE then.
>
> In general, IM session is just another media stream just like
> audio or video stream.
> Often it is established at the same time than the
> audio and video streams (one m line for each media stream).
> This is the ideal situation since it allows all the
> control and flexibility of INVITE for IM session
> (e.g. mobility, record-route, multi-party IM..).
>
> Still, one-shot MESSAGEs can be sent if someone does
> not want to use the session model.
>
> Is there a consensus that INVITE-established IM messaging
> session idea is ok ?

I think so.

> (in addition to one shot MESSAGEs)
>
> If we can agree on that, then we can continue with other problems, like:
> - messaging protocol/format inside a session (e.g. SIP MESSAGE over TCP)

We can minimize the debate on this issue if we can agree on a generic SDP format (m-line, etc.)
that is flexible enough to support multiple options (SIP/TCP, CPIM/TCP, XML/HTTP, etc.) and future extensions.

>
> - direct end-to-end vs. via signaling proxies vs. via IM servers

Since IM is just another media stream it should should support the
same variety of architectures supported by the current media streams (direct end-to-end, Conferencing Servers, etc.)

>
> - compression (hopefully this does not have to be discussed here)

I agree.

>
>
> There should be a resolution on this asap.

I agree.

>
>
> --
> Petri
>
> > I think there is yet another option, which I haven't seen discussed, and
> > that is to use "direct message first, session later"..
> >
> > When I'm sending a single message, opening a point-to-point session via
> > INVITE has a lot of overhead, and also takes time and some system
> > resources. The entire process of creating a session its by far larger than
> > my "Hi, meet me for lunch" message.
> > also, passing MESSAGE or INVITE from the SIP network perspective is almost
> > the same (and mabe a bit in favour of MESSAGE...)
> > This is why I wouldn't send a email in the first place - since its a
> > heavyweight solution.
> >
> > If the other side will want to start a chat, only then should a full
> > messaging session be opened.
> >
> > Of course, there should be a limitation on the size of this initial
> > message, which will require a use of p2p session for sending a message
> > above a given size (e.g. equivalent to a single UDP packet)
> >
> >
> >
> >
> >
> > "Petri K. Koskelainen" 
> > Sent by: simple-admin@mailman.dynamicsoft.com
> > 25/09/2001 17:39
> >
> >
> >         To:     simple@mailman.dynamicsoft.com
> >         cc:
> >         Subject:        [Simple] MESSAGE sessions - over TCP
> >
> >
> >
> > There hasn't been any conclusion or rough consensus relating to
> > the SIP MESSAGE session model.
> >
> > It seems that there are two main proposals:
> >
> > 1: Implicit MESSAGE session (no INVITE, just MESSAGEs).
> >
> > 2: Use of INVITE to establish a SIP session and then using
> > some protocol X to carry the messages. The X protocol
> > may be SIP MESSAGE, BEEP-based, some new protocol etc.
> > IESG has ruled out SIP MESSAGE mainly because of three reasons:
> > - large message overhead in SIP headers
> > - lack of congestion control (in UDP only)
> > - size limitation (in UDP only)
> > However, SIP MESSAGE over TCP should be ok. Message overhead is an
> > issue only in wireless environment, but SIP compression (even UDPcomp)
> > eliminates the overhead.
> > TCP has also other advantages (like the use of TLS).
> >
> > I really think that something should be decided asap. Option 2 with SIP
> > MESSAGE over TCP seems to be ok. It does not have to be the one-and-only
> > format for next 100 years. If someone really wants it, he can specify
> > BEEP-based or whatever additional formats inside a SIP
> > session - just like it is possible to create new RTP formats.
> > However, SIP session model and MESSAGE over TCP is sufficient for
> > many applications and therefore it would be really useful
> > to continue at least with that (and have something to use asap).
> >
> > Since other formats inside a session may be defined later, the real
> > question is whether the INVITE established session is needed or not.
> > I think yes. This is similar to audio/video sessions, and it allows e.g.
> > the use of record-route, mobility etc.
> >
> > --
> > Petri
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >
> >
> > --=_alternative 00443EF042256AD3_=
> > Content-Type: text/html; charset="us-ascii"
> >
> >
> > 
I think there is yet another option, which I haven't seen discussed, and that is to use "direct message first, session later"..
> > 

> > 
When I'm sending a single message, opening a point-to-point session via INVITE has a lot of overhead, and also takes time and some system resources. The entire process of creating a session its by far larger than my "Hi, meet me for lunch" message. 
> > 
also, passing MESSAGE or INVITE from the SIP network perspective is almost the same (and mabe a bit in favour of MESSAGE...)
> > 
This is why I wouldn't send a email in the first place - since its a heavyweight solution.
> > 

> > 
If the other side will want to start a chat, only then should a full messaging session be opened.

> > 
> > 
Of course, there should be a limitation on the size of this initial message, which will require a use of p2p session for sending a message above a given size (e.g. equivalent to a single UDP packet) 
> > 

> > 

> > 

> > 

> > 
> > 
> > 

> > "Petri K. Koskelainen" <petkos@cs.columbia.edu>
> > 
Sent by: simple-admin@mailman.dynamicsoft.com
> > 
25/09/2001 17:39
> > 

> > 
        
> > 
        To:        simple@mailman.dynamicsoft.com
> > 
        cc:        
> > 
        Subject:        [Simple] MESSAGE sessions - over TCP

> > 

> > 

> > 

> > 
There hasn't been any conclusion or rough consensus relating to

> > the SIP MESSAGE session model.

> > 
> > 
It seems that there are two main proposals:

> > 
> > 
1: Implicit MESSAGE session (no INVITE, just MESSAGEs).

> > 
> > 
2: Use of INVITE to establish a SIP session and then using

> > some protocol X to carry the messages. The X protocol

> > may be SIP MESSAGE, BEEP-based, some new protocol etc.

> > IESG has ruled out SIP MESSAGE mainly because of three reasons:

> > - large message overhead in SIP headers

> > - lack of congestion control (in UDP only)

> > - size limitation (in UDP only)

> > However, SIP MESSAGE over TCP should be ok. Message overhead is an

> > issue only in wireless environment, but SIP compression (even UDPcomp)

> > eliminates the overhead.

> > TCP has also other advantages (like the use of TLS).

> > 
> > 
I really think that something should be decided asap. Option 2 with SIP

> > MESSAGE over TCP seems to be ok. It does not have to be the one-and-only

> > format for next 100 years. If someone really wants it, he can specify

> > BEEP-based or whatever additional formats inside a SIP

> > session - just like it is possible to create new RTP formats.

> > However, SIP session model and MESSAGE over TCP is sufficient for

> > many applications and therefore it would be really useful

> > to continue at least with that (and have something to use asap).

> > 
> > 
Since other formats inside a session may be defined later, the real

> > question is whether the INVITE established session is needed or not.

> > I think yes. This is similar to audio/video sessions, and it allows e.g.

> > the use of record-route, mobility etc.

> > 
> > 
--

> > Petri

> > _______________________________________________

> > simple mailing list

> > simple@mailman.dynamicsoft.com

> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 

> > 

> > --=_alternative 00443EF042256AD3_=--
> >
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

--------------494DDD16B06BAFD7C209F186
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi Petri,

See comments inline:

BR,

-Vasilis

"Petri K. Koskelainen" wrote:

If you have just one message to send, you don't have
to

establish a session. Just send a MESSAGE.

No need for INVITE then.

In general, IM session is just another media stream just like

audio or video stream.

Often it is established at the same time than the

audio and video streams (one m line for each media stream).

This is the ideal situation since it allows all the

control and flexibility of INVITE for IM session

(e.g. mobility, record-route, multi-party IM..).

Still, one-shot MESSAGEs can be sent if someone does

not want to use the session model.

Is there a consensus that INVITE-established IM messaging

session idea is ok ?

I think so.

(in addition to one shot MESSAGEs)

If we can agree on that, then we can continue with other problems, like:

- messaging protocol/format inside a session (e.g. SIP MESSAGE over
TCP)

We can minimize the debate on this issue if we can
agree on a generic SDP format (m-line, etc.)

that is flexible enough to support multiple options
(SIP/TCP, CPIM/TCP, XML/HTTP, etc.) and future extensions.

 

- direct end-to-end vs. via signaling proxies vs. via IM servers

Since IM is just another media stream it should should
support the

same variety of architectures supported by the
current media streams (direct end-to-end, Conferencing Servers, etc.)

 

- compression (hopefully this does not have to be discussed here)

I agree.

 

There should be a resolution on this asap.

I agree.

 

--

Petri

> I think there is yet another option, which I haven't seen discussed,
and

> that is to use "direct message first, session later"..

>

> When I'm sending a single message, opening a point-to-point session
via

> INVITE has a lot of overhead, and also takes time and some system

> resources. The entire process of creating a session its by far larger
than

> my "Hi, meet me for lunch" message.

> also, passing MESSAGE or INVITE from the SIP network perspective
is almost

> the same (and mabe a bit in favour of MESSAGE...)

> This is why I wouldn't send a email in the first place - since its
a

> heavyweight solution.

>

> If the other side will want to start a chat, only then should a full

> messaging session be opened.

>

> Of course, there should be a limitation on the size of this initial

> message, which will require a use of p2p session for sending a message

> above a given size (e.g. equivalent to a single UDP packet)

>

>

>

>

>

> "Petri K. Koskelainen" <petkos@cs.columbia.edu>

> Sent by: simple-admin@mailman.dynamicsoft.com

> 25/09/2001 17:39

>

>

>         To:    
simple@mailman.dynamicsoft.com

>         cc:

>         Subject:       
[Simple] MESSAGE sessions - over TCP

>

>

>

> There hasn't been any conclusion or rough consensus relating to

> the SIP MESSAGE session model.

>

> It seems that there are two main proposals:

>

> 1: Implicit MESSAGE session (no INVITE, just MESSAGEs).

>

> 2: Use of INVITE to establish a SIP session and then using

> some protocol X to carry the messages. The X protocol

> may be SIP MESSAGE, BEEP-based, some new protocol etc.

> IESG has ruled out SIP MESSAGE mainly because of three reasons:

> - large message overhead in SIP headers

> - lack of congestion control (in UDP only)

> - size limitation (in UDP only)

> However, SIP MESSAGE over TCP should be ok. Message overhead is an

> issue only in wireless environment, but SIP compression (even UDPcomp)

> eliminates the overhead.

> TCP has also other advantages (like the use of TLS).

>

> I really think that something should be decided asap. Option 2 with
SIP

> MESSAGE over TCP seems to be ok. It does not have to be the one-and-only

> format for next 100 years. If someone really wants it, he can specify

> BEEP-based or whatever additional formats inside a SIP

> session - just like it is possible to create new RTP formats.

> However, SIP session model and MESSAGE over TCP is sufficient for

> many applications and therefore it would be really useful

> to continue at least with that (and have something to use asap).

>

> Since other formats inside a session may be defined later, the real

> question is whether the INVITE established session is needed or not.

> I think yes. This is similar to audio/video sessions, and it allows
e.g.

> the use of record-route, mobility etc.

>

> --

> Petri

> _______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple

>

>

> --=_alternative 00443EF042256AD3_=

> Content-Type: text/html; charset="us-ascii"

>

>

> <br><font size=2 face="sans-serif">I think there is yet another
option, which I haven't seen discussed, and that is to use &quot;direct
message first, session later&quot;..</font>

> <br>

> <br><font size=2 face="sans-serif">When I'm sending a single
message, opening a point-to-point session via INVITE has a lot of overhead,
and also takes time and some system resources. The entire process of creating
a session its by far larger than my &quot;Hi, meet me for lunch&quot;
message. </font>

> <br><font size=2 face="sans-serif">also, passing MESSAGE or
INVITE from the SIP network perspective is almost the same (and mabe a
bit in favour of MESSAGE...)</font>

> <br><font size=2 face="sans-serif">This is why I wouldn't send
a email in the first place - since its a heavyweight solution.</font>

> <br>

> <br><font size=2 face="sans-serif">If the other side will want
to start a chat, only then should a full messaging session be opened.<br>

> </font>

> <br><font size=2 face="sans-serif">Of course, there should
be a limitation on the size of this initial message, which will require
a use of p2p session for sending a message above a given size (e.g. equivalent
to a single UDP packet) </font>

> <br>

> <br>

> <br>

> <br>

> <table width=100%>

> <tr valign=top>

> <td>

> <td><font size=1 face="sans-serif"><b>&quot;Petri K.
Koskelainen&quot; &lt;petkos@cs.columbia.edu&gt;</b></font>

> <br><font size=1 face="sans-serif">Sent by: simple-admin@mailman.dynamicsoft.com</font>

> <p><font size=1 face="sans-serif">25/09/2001 17:39</font>

> <br>

> <td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp;
&nbsp; </font>

> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp;
&nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;simple@mailman.dynamicsoft.com</font>

> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp;
&nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>

> <br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp;
&nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;[Simple]
MESSAGE sessions - over TCP</font></table>

> <br>

> <br>

> <br>

> <br><font size=2><tt>There hasn't been any conclusion or
rough consensus relating to<br>

> the SIP MESSAGE session model.<br>

> </tt></font>

> <br><font size=2><tt>It seems that there are two main proposals:<br>

> </tt></font>

> <br><font size=2><tt>1: Implicit MESSAGE session (no INVITE,
just MESSAGEs).<br>

> </tt></font>

> <br><font size=2><tt>2: Use of INVITE to establish a SIP
session and then using<br>

> some protocol X to carry the messages. The X protocol<br>

> may be SIP MESSAGE, BEEP-based, some new protocol etc.<br>

> IESG has ruled out SIP MESSAGE mainly because of three reasons:<br>

> - large message overhead in SIP headers<br>

> - lack of congestion control (in UDP only)<br>

> - size limitation (in UDP only)<br>

> However, SIP MESSAGE over TCP should be ok. Message overhead is an<br>

> issue only in wireless environment, but SIP compression (even UDPcomp)<br>

> eliminates the overhead.<br>

> TCP has also other advantages (like the use of TLS).<br>

> </tt></font>

> <br><font size=2><tt>I really think that something should
be decided asap. Option 2 with SIP<br>

> MESSAGE over TCP seems to be ok. It does not have to be the one-and-only<br>

> format for next 100 years. If someone really wants it, he can specify<br>

> BEEP-based or whatever additional formats inside a SIP<br>

> session - just like it is possible to create new RTP formats.<br>

> However, SIP session model and MESSAGE over TCP is sufficient for<br>

> many applications and therefore it would be really useful<br>

> to continue at least with that (and have something to use asap).<br>

> </tt></font>

> <br><font size=2><tt>Since other formats inside a session
may be defined later, the real<br>

> question is whether the INVITE established session is needed or not.<br>

> I think yes. This is similar to audio/video sessions, and it allows
e.g.<br>

> the use of record-route, mobility etc.<br>

> </tt></font>

> <br><font size=2><tt>--<br>

> Petri<br>

> _______________________________________________<br>

> simple mailing list<br>

> simple@mailman.dynamicsoft.com<br>

> http://mailman.dynamicsoft.com/mailman/listinfo/simple</tt></font>

> <br>

> <br>

> --=_alternative 00443EF042256AD3_=--

>

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple



--------------494DDD16B06BAFD7C209F186--




From jdrosen@dynamicsoft.com  Wed Sep 26 16:31:30 2001
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 QAA12084
	for ; Wed, 26 Sep 2001 16:31:30 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f8QKTF8P024765;
	Wed, 26 Sep 2001 16:29:15 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 26 Sep 2001 16:30:17 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Petri K. Koskelainen'" , Dror@vocaltec.com
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] MESSAGE sessions - over TCP
Date: Wed, 26 Sep 2001 16:30:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1821
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: 


 

> -----Original Message-----
> From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> Sent: Wednesday, September 26, 2001 1:21 PM
> To: Dror@vocaltec.com
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] MESSAGE sessions - over TCP
> 
> Is there a consensus that INVITE-established IM messaging 
> session idea is ok ? (in addition to one shot MESSAGEs)
> 
> 
> If we can agree on that, then we can continue with other 
> problems, like:
> - messaging protocol/format inside a session (e.g. SIP 
> MESSAGE over TCP)
> - direct end-to-end vs. via signaling proxies vs. via IM servers 
> - compression (hopefully this does not have to be discussed here)
>  
> There should be a resolution on this asap.

Yes, part of the reason we are circling around is that we have not been able
to break the problem into pieces. Clearly the first is the question Petri
has asked - can we agree that a session model for messaging (session model
being to wrap it in INVITE/BYE, and the messages are viewed as a media
stream.) THis says nothing about how they are transported, and wouldn't rule
out sending them over the signaling channel.

I strongly support this need for a session model. I think most have
expressed support for it, with a few notable exceptions (Dean, I think).

I think its time for the chairs to make a ruling on consensus on whether to
pursue a session model as defined above. 

We would still retain the paging model of course, 

-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


From pkyzivat@cisco.com  Wed Sep 26 17:53:12 2001
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 RAA12545
	for ; Wed, 26 Sep 2001 17:53:11 -0400 (EDT)
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 f8QLpLg11544;
	Wed, 26 Sep 2001 17:51:21 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAA08819 (AUTH pkyzivat);
	Wed, 26 Sep 2001 17:53:14 -0400 (EDT)
Message-ID: <3BB24DAC.B2AAF19@cisco.com>
Date: Wed, 26 Sep 2001 17:50:36 -0400
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, Dror@vocaltec.com,
        "'Petri K. Koskelainen'" 
Subject: Re: [Simple] MESSAGE sessions - over TCP
References: 
Content-Type: multipart/mixed;
 boundary="------------DDB7E5A205BB0B522E62BC08"
Content-Length: 5720
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: 

This is a multi-part message in MIME format.
--------------DDB7E5A205BB0B522E62BC08
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I agree with this - I believe it is essential!
I proposed more or less the same thing three weeks ago, but got no
responses. 

	Paul Kyzivat
	Cisco Systems

Jonathan Rosenberg wrote:
[snip]
> > Is there a consensus that INVITE-established IM messaging
> > session idea is ok ? (in addition to one shot MESSAGEs)
[snip] 
> Yes, part of the reason we are circling around is that we have not been able
> to break the problem into pieces. Clearly the first is the question Petri
> has asked - can we agree that a session model for messaging (session model
> being to wrap it in INVITE/BYE, and the messages are viewed as a media
> stream.) THis says nothing about how they are transported, and wouldn't rule
> out sending them over the signaling channel.
> 
> I strongly support this need for a session model. I think most have
> expressed support for it, with a few notable exceptions (Dean, I think).
> 
> I think its time for the chairs to make a ruling on consensus on whether to
> pursue a session model as defined above.
> 
> We would still retain the paging model of course,
> 
> -Jonathan R.
--------------DDB7E5A205BB0B522E62BC08
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: 
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAA09563;
	Thu, 6 Sep 2001 10:54:31 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f86Eriv28147;
	Thu, 6 Sep 2001 07:53:44 -0700 (PDT)
Received: from proxy1.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f86ErNE16686;
	Thu, 6 Sep 2001 07:53:23 -0700 (PDT)
Received: from mail1.dynamicsoft.com ([63.113.40.10])
	by proxy1.cisco.com (8.11.2/8.11.2) with ESMTP id f86Er8u02023;
	Thu, 6 Sep 2001 07:53:08 -0700 (PDT)
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f86EpDCr018292;
	Thu, 6 Sep 2001 10:51:20 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15087;
	Thu, 6 Sep 2001 10:52:03 -0400 (EDT)
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 KAA15072
	for ; Thu, 6 Sep 2001 10:51:58 -0400 (EDT)
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 f86EpUe11430
	for ; Thu, 6 Sep 2001 10:51:30 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAA09547 (AUTH pkyzivat);
	Thu, 6 Sep 2001 10:53:01 -0400 (EDT)
Message-ID: <3B978D61.D7EFF640@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: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Sessions of MESSAGEs
References: <000b01c136de$9c4b8880$18cfef20@avshalom>
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, 06 Sep 2001 10:51:13 -0400
X-Mozilla-Status2: 00000000

I am reserving judgement on the basic point of this thread - whether it
is a good or bad thing to permit an IM session to be transported as a
series of SIP MESSAGEs. 

But I would like to propose some basic groundrules that any proposed
mechanism for IM sessions must follow:

-  An IM session must be initiated with a SIP INVITE transaction,
   using an SDP media description to request the IM session.

-  Like any other media session within a SIP call, it must be
   possible to add, drop, or redirect an IM session to a new
   destination through use of reINVITE, by exchanging revised SDP.

I am trying to avoid a solution where IM is treated differently than
other media, preventing reasonable management of multimedia calls. When
I receive an INVITE, I should have the opportunity to accept or refuse
any or all of the offered media by way of the SDP I return.

If a proposal doesn't meet these groundrules, then I don't believe it
belongs as a part of SIP. If it does, then of course it still must meet
all the other concerns that have been raised in this thread. These
groundrules are not a showstopper for using sessions of MESSAGEs -
Jonathon at one point floated a proposal for m=message that would
probably be adequate.

	Paul Kyzivat
	Cisco Systems
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


--------------DDB7E5A205BB0B522E62BC08--


From Hans.Hannu@epl.ericsson.se  Thu Sep 27 11:12:55 2001
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15810
	for ; Thu, 27 Sep 2001 11:12:53 -0400 (EDT)
Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f8RFCZv28216;
	Thu, 27 Sep 2001 17:12:35 +0200 (MEST)
Received: by lms001.lu.erisoft.se id RAA06548; Thu, 27 Sep 2001 17:12:34 +0200 (MET DST)
Reply-To: 
From: "Hans Hannu" 
To: "'Liu Zhigang.C (NRC/Dallas)'" ,
        "'ext Lawrence Conroy'" ,
        "'Isomaki Markus (NRC/Helsinki)'" ,
        , 
Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP
Date: Thu, 27 Sep 2001 17:10:28 +0200
Message-ID: <003201c14766$8b4648c0$0eb08496@e0000865d41e2.epl.ericsson.se>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0033_01C14777.4ECF18C0"
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 V4.72.3612.1700
X-MS-TNEF-Correlator: 00000000255E33C6958DD511B6B70000865D41E284362400
In-Reply-To: 
Content-Length: 7075
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0033_01C14777.4ECF18C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I agree that the negotiation whether to apply compression between two
parties or not should be taken care of before (in the case of SIP) the first
SIP INVITE messages. Thus, this can not be done by SigComp itself.

However, there might be a need to negotiate other parameters, e.g. The usage
of a Codebook/Byte-buffer, buffer memory etc., But, we have to think of the
complexity issue with too many parameters to set/negotiate, and also if
SigComp itself should do this kind of negotiation or if some other protocol
should do this, e.g. according to
http://search.ietf.org/internet-drafts/draft-spbs-sip-negotiate-00.txt . My
belief is that SigComp should not have its own negotiation procedure.


> 3) Pre-populate of the dictionary. This can boost the compression
> ratio for the first several messages.

Yes, this is true. And I believe that Jonathan had a good proposal for this:
http://www.cdt.luth.se/rohc/msg02593.html
"User specific and static dictionaries can all be supported by a single
decoder capability - the ability to set a codebook entry without
constructing decoder output. With this, the encoder could transfer the user
specific and static codebooks at init time of the session (presumably before
a call is made)."

Also how to decide to use a Codebook or a Byte-buffer is suggested by Jan
Christoffersson in:
http://www.cdt.luth.se/rohc/msg02686.html .


> Note that although the negotiation procedure is out of SIP (again,
> to be generic), it may be triggered by SIP as a service request.

The scheme is still generic even though it uses e.g. SIP to negotiate its
usage. The same compression scheme can still be applied to e.g. RTSP. If we
define what has to be negotiated (if any) it should be up to the application
to make this happen.

> Also, the negotiation only needs to be done once if both endpoints
> agree to keep the negotiated results.

Agree.

> However, the two endpoints
> should periodically verify they are still in sync (e.g. between
> sessions when traffic is relatively idle).

What should be verified? The settings of the compression scheme or its
dictionaries/Code-books.

> Re Markus' question about the requirement, the location of the peer
> compression entities is not addressed (to make SigComp generic).
> However, the need of negotiation is mentioned/implied in current
> requirement draft (e.g. 3a - compatibility, 6 - Scalability).

Yes, negotiation is needed, but the question is how we do it.

BR
/Hans H

------=_NextPart_000_0033_01C14777.4ECF18C0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+Ih0PAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCQAbABEACgAAAAQAGwEB
A5AGAKgLAAArAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA
AAAAAwA2AAAAAAAeAHAAAQAAADAAAABbcm9oY10gUkU6IFtTaW1wbGVdIE1FU1NBR0Ugc2Vzc2lv
bnMgLSBvdmVyIFRDUAACAXEAAQAAABYAAAABwUdmiqghGg6WsxYR1ZBkAACGXUHiAAACAR0MAQAA
ACAAAABTTVRQOkhBTlMuSEFOTlVARVBMLkVSSUNTU09OLlNFAAsAAQ4AAAAAQAAGDgBU33lmR8EB
AgEKDgEAAAAYAAAAAAAAACVeM8aVjdURtrcAAIZdQeLCgAAAAwAUDgEAAAALAB8OAQAAAAMABhBZ
cnSqAwAHEMYHAAAeAAgQAQAAAGUAAABISSxJQUdSRUVUSEFUVEhFTkVHT1RJQVRJT05XSEVUSEVS
VE9BUFBMWUNPTVBSRVNTSU9OQkVUV0VFTlRXT1BBUlRJRVNPUk5PVFNIT1VMREJFVEFLRU5DQVJF
T0ZCRUZPUkUoAAAAAAIBCRABAAAAyAYAAMQGAACcCwAATFpGdfYi0sQDAAoAcmNwZzEyNeIyA0N0
ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRG
E7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAULMLCQFkMzYWUAunYwEwcCBIaSwKogqECoBJ5CBhCcIg
dBPgBUAeoMEegG5lZ290BzAfcDkCICB3HwAe8QXAdG8lHjBwC1B5IAWgbXDXGCAEEB+yYhQgdwnh
HpC+dyCACrEfcAeRBbFuH2DIIHNoCGBsZCGxHpA0YWsiEWMKwB6Ab2b3IbECECSRKAuAHuMkcBQQ
ISSyU0lQKR7jZmkHFAAFQCZhIElOVkloVEUgB4FzHkAHkC7AIFRodXMsHpEEAG8kYQOgIzIj4WQC
IB6AYjEg4FNpZwhQISAgaSJ0FBBsZi4dakhvvSHwdgSQKOIEkB6AbSqQ+mgps2EfIQmAIGIfNiSh
eyAjCrFhB4AOsBQAKOBl/C5nKIIegCjAKEEksi2wBwhQAQAG4G9rL0J58Q6wLWJ1ASAsgjI0J/FN
BGByIOAUIGMuKOBC7HV0KOAh8CAT4CxwIGK5KQFuaySyJaMhEWwOwL8rACDgBAEKUB/gKwBoIGG/
IIADgSDgL1ggYhQRLy5X7yjgAHAjwAdAcyCABpAqffcjZioAKPRrC4AjwCTBHzr/BbE6ETngB4Au
5gNgIHAXka87LS/1ANAFoWQLgGcgYsEtUHRwOi8vFBAKwC0T0C4IkAAwLgWwZy/HC4AvsR8wdC1k
L3ABgARzL0MjLXNwYnMLQ+AFIC0uVy0wMC63DNAFQCiATSDgIcBsCJD/JNApIR6jKoYjdSMyNHMr
Ad0i8HcpcR9JPnFjCYAIcI8wEB1qCuMKgD4gMyaQwlAYIC1wb3AjoC6z2zVkQKBjH6IKwHkogikl
/zGRJyE1hiFFSwYvcB+hJuB/BbEmuBQQLHEHQCf4HWpZtweQKOVGUnIKUCiAQTmR7x4gReM0kh6y
Sk1BHqEDoPsT4DmhIB9QBHA+YkvwKDC3AyBQdAQAOh1kQSV3WLBgLmNkdC4KQB6gLgUUEC8DYGhj
L21zRGcwDjA5My4tUG3zGAAdcyJVFBAFwEPwBZD/BpAN4DlzJyAfkVwATPciwv8pUgdAAyAj4TaQ
ILAXwS3x/ypRLbAAkEDANgAdZAWCBIHbJGEKsGIDEDYyLR7jYLb/OGQtoWAiMZIwAAIwM2E20v0I
YHQdZAWgAIBT8U0RQMHPYAZj0UwQWRAgVzbjP7P/HvIJ8GAlI5NT8ABxMuIe8v8owASQHWRbn1vx
YqYEIB7BfwuAKwAekAdxNUYUECFkKP0hMnUAwAJgRcIlEh1kYoGPXeIpIQDAAQApLiIdar5BOdIj
gAfgIHEFgWkBAP8gYmjRMSki8i2wMelGQjaQlmcoUV61SgORQ2gFEP8nICTAMmEEEB/BC4BX31jv
8Vn0Njg2WoNFgR1qSwb+Th9gHoUHQGOyLUAe70mX/0ZCY9EmJSVQHkALcR1VS2CfIHEj4ShQHzAF
EGMpKOD/a6EAwEXCU+EqkChQGCEqQ+8nYSXwXxIEkHYN4B6AGCD+cQpQJyB5PDBiBPAfAD3h/3PC
H3Bd8X+VMAAscCWCe3P/a6Fo0QQgMBMnUi4rSFIwo/8wRCgwPeEhCoRFKVKE5C2CDyCxCJAuAzAT
UlRTUP0ogEkk0DRBAQELgDaxHrL/E+A4QyPhLlcjwCVgMRE3gP8mkGuhI3heYDS0i4UkcB+j/yBx
AMAkMCj0E+AgsAnwKIDfk3F5vHBiZsQ8q24g0S3S/45GKgMCIIKBOhEG4DbxCfD+ZEvwQpEEIUsV
HkUggCQw/mWQ4R8JLfFtMntAKHFvq/8JwitrS2AsOiIzmC8jZmmA/wUQBHCRsV3wIOAscQaQYfGf
HwBfASSRhOQlcXN5ZzD/JVAwEyHGn1chVAQgH/EiId9DMVviKSEYIEwxaSxwINHvcVA2AG9wHWpX
HrIjeKET/YvhP4kEFCBk4iLhNWiJ7fc9YkhhXNovMVIyIGsCnL0qUh6ATQrAayjAJyD/gtMfsgGg
fZIe8oKyJwCEcf8CMGbEF7CRxTVVaYBo9ktg/yEKYzErACLCKSEjMlYgQyD/IVGPQpI2KoZ/litl
nY0t0+88fW8Cs/IqEWRCgDXhi+L9JXFjCHAYIAIwT5eweCnw+0MyouUzLbBhMCECH5FgxPUo4DZh
IVNusWC1ptxTI/+5DS3SCYAykh7UrzeS0nDBT40yOfF3YB1qQlIdZC8qSAYiSB1kfcawAwAQEAAA
AAADABEQAAAAAB4AQhABAAAAQAAAADxCODFDODk0MDRBOUJENjQ5ODNFMzY5QjdENDQ1Mzk0MTBE
NTZFNUBkYWViZTAwNS5OT0UuTm9raWEuY29tPgADAAlZAQAAAAsAAIAIIAYAAAAAAMAAAAAAAABG
AAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAiACCAGAAAAAADA
AAAAAAAARgAAAAABhQAAAAAAAAMAWoAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAADWGQAAHgBbgAgg
BgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC41AAsAXIAIIAYAAAAAAMAAAAAAAABGAAAA
AAaFAAAAAAAACwBdgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAF6ACCAGAAAAAADAAAAA
AAAARgAAAAARhQAAAAAAAAMAX4AIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgBggAggBgAA
AAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AYYAIIAYAAAAAAMAAAAAAAABGAAAAADeF
AAABAAAAAQAAAAAAAAAeAGKACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwBj
gAsgBgAAAAAAwAAAAAAAAEYAAAAAAIgAAAAAAAALAGSACyAGAAAAAADAAAAAAAAARgAAAAAFiAAA
AAAAAAIB+A8BAAAAEAAAACVeM8aVjdURtrcAAIZdQeICAfoPAQAAABAAAAAlXjPGlY3VEba3AACG
XUHiAgH7DwEAAABlAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/
uAEAqgA32W4AAABDOlxXSU5OVFxQcm9maWxlc1xlcGxoYWh1XFBlcnNvbmFsXE1haWx0b29sLnBz
dAAAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDAyNTVFMzNDNjk1OERENTEx
QjZCNzAwMDA4NjVENDFFMjg0MzYyNDAwAAAAADMr

------=_NextPart_000_0033_01C14777.4ECF18C0--


From zhigang.c.liu@nokia.com  Thu Sep 27 16:21:14 2001
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 QAA16788
	for ; Thu, 27 Sep 2001 16:21:12 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.americas.nokia.com [172.18.194.216])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8RKLK721132
	for ; Thu, 27 Sep 2001 23:21:20 +0300 (EET DST)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8RKKj313903
	for ; Thu, 27 Sep 2001 15:20:45 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 27 Sep 2001 15:20:44 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 27 Sep 2001 15:20:51 -0500
content-class: urn:content-classes:message
Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP
Date: Thu, 27 Sep 2001 15:20:43 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rohc] RE: [Simple] MESSAGE sessions - over TCP
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFHZoqoIRoOlrMWEdWQZAAAhl1B4gAIgutw
From: "Liu Zhigang.C (NRC/Dallas)" 
To: , "'ext Lawrence Conroy'" ,
        "Isomaki Markus (NRC/Helsinki)" ,
        , 
X-OriginalArrivalTime: 27 Sep 2001 20:20:51.0156 (UTC) FILETIME=[E6D3E140:01C14791]
Content-Length: 3706
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id QAA16788
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: 

Hans,

> I agree that the negotiation whether to apply compression 
> between two parties or not should be taken care of before (in 
> the case of SIP) the first SIP INVITE messages. Thus, this 
> can not be done by SigComp itself.
                     ^^^^^^^
I guess you mean SIP?
 
> However, there might be a need to negotiate other parameters, 
> e.g. The usage of a Codebook/Byte-buffer, buffer memory etc., 
> But, we have to think of the complexity issue with too many 
> parameters to set/negotiate, and also if SigComp itself 
> should do this kind of negotiation or if some other protocol 
> should do this, e.g. according to 
> http://search.ietf.org/internet-drafts/draft-spbs-sip-negotiat
> e-00.txt . My belief is that SigComp should not have its own 
> negotiation procedure.

Sorry, I haven't had time to read through the sip-negotiate draft. 
I agree with you that we should keep the number of parameters to 
minimal. However, I feel that the parameters you just mentioned
are closer to SigComp than to SIP. They are really tied to the
algorithms/procedures of SigComp. In my view, the negotiation 
should be either defined with SigComp in one document or in 
a separate document (brother/sister of SigComp). But in either 
case, we should draw a line between SIP (the "user" of SigComp) 
and SigComp (the service provider). The interface between
the two is the negotiation protocol. 

For example, SIP can trigger the negotiation by sending a request
like (SIP, UDP, port #) to the SigComp negotiation. The negotiation
then setup the rest. This what I meant in my previous email. 
Similarly, an RTSP module can trigger the negotiation by 
(RTSP, UDP, port #). 

> Also how to decide to use a Codebook or a Byte-buffer is 
> suggested by Jan Christoffersson in:
> http://www.cdt.luth.se/rohc/msg02686.html . 

That's one important issue, i.e. token formats and context 
structure. I've suggested an alternative to merge codebook
with byte-buffer in http://www.cdt.luth.se/robhc/msg02649.html.
As to the token formats, one simple (perhaps dumb) solution
is to define two sets of token formats: one for LZSS (byte-buffer)
and one for LZW (codebook). Then we only need one bit in the 
header part to signal which set should be used to process a
compressed message. For example, if the flag set to 0,
READ = (pointer, length), referring to byte buffer. Otherwise,
READ = (index), referring to codebook.

> > Note that although the negotiation procedure is out of SIP (again,
> > to be generic), it may be triggered by SIP as a service request. 
> 
> The scheme is still generic even though it uses e.g. SIP to 
> negotiate its usage. The same compression scheme can still be 
> applied to e.g. RTSP. If we define what has to be negotiated 
> (if any) it should be up to the application to make this happen.    

Pleae see my comment above.

> > However, the two endpoints 
> > should periodically verify they are still in sync (e.g. between 
> > sessions when traffic is relatively idle).
> 
> What should be verified? The settings of the compression 
> scheme or its dictionaries/Code-books.

Both (they together constitute the compression context).
 
> > Re Markus' question about the requirement, the location of the peer
> > compression entities is not addressed (to make SigComp generic).
> > However, the need of negotiation is mentioned/implied in current
> > requirement draft (e.g. 3a - compatibility, 6 - Scalability).
> 
> Yes, negotiation is needed, but the question is how we do it.

We can take the ideas from SCRIBE. The exact parameters to
be negotiate may not be the same. But the basic mechanism
is already there (packet type, CRC, handshake procedures, etc.).

BR,
Zhigang

From Hans.Hannu@epl.ericsson.se  Fri Sep 28 05:43:02 2001
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19140
	for ; Fri, 28 Sep 2001 05:42:57 -0400 (EDT)
Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f8S9gbK18246;
	Fri, 28 Sep 2001 11:42:37 +0200 (MEST)
Received: by lms001.lu.erisoft.se id LAA18022; Fri, 28 Sep 2001 11:42:36 +0200 (MET DST)
Reply-To: 
From: "Hans Hannu" 
To: "'Liu Zhigang.C (NRC/Dallas)'" ,
        "'ext Lawrence Conroy'" ,
        "'Isomaki Markus (NRC/Helsinki)'" ,
        , 
Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP
Date: Fri, 28 Sep 2001 11:40:30 +0200
Message-ID: <000401c14801$9d399b90$0eb08496@e0000865d41e2.epl.ericsson.se>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0005_01C14812.60C26B90"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MS-TNEF-Correlator: 00000000255E33C6958DD511B6B70000865D41E2443B2400
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Importance: Normal
In-Reply-To: 
Content-Length: 7040
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C14812.60C26B90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

See comments inline.

> > I agree that the negotiation whether to apply compression
> > between two parties or not should be taken care of before (in
> > the case of SIP) the first SIP INVITE messages. Thus, this
> > can not be done by SigComp itself.
>                      ^^^^^^^
> I guess you mean SIP?

No, I do not. Whether to apply compression or not should be decided by the
application e.g. SIP. SigComp is just the tool that the application will use
for compression.

Basically, there are two issues:
1) Whether compression is to be applied or not,
2) How to negotiate the SigComp parameters (If any needs to be negotiated).
What we should do is to first define what parameters that we see a need to
negotiate. Then we could start thinking of how to do the negotiation. And
also if the parameters need to be negotiated or if they can be signaled "in
band".

1 - Whether to apply SigComp compression or not should be negotiated by the
application, e.g. SIP. Because it is the application which knows where the
other party is located. If this is done with a new SIP method or according
to: http://www.cdt.luth.se/robhc/msg02358.html
Rosenberg: "My proposal for modeling this as a SIP transport handles this
case. I suspect that the usage of SRV records, a key piece of the SIP
approach, will also work fine for other application protocols, such as
RTSP."


> In my view, the negotiation
> should be either defined with SigComp in one document or in
> a separate document (brother/sister of SigComp). But in either
> case, we should draw a line between SIP (the "user" of SigComp)
> and SigComp (the service provider). The interface between
> the two is the negotiation protocol.

I agree to that we should draw a line between the SIP, which uses
Compression, and SigComp that performs the compression.

> As to the token formats, one simple (perhaps dumb) solution
> is to define two sets of token formats: one for LZSS (byte-buffer)
> and one for LZW (codebook). Then we only need one bit in the
> header part to signal which set should be used to process a
> compressed message. For example, if the flag set to 0,
> READ = (pointer, length), referring to byte buffer. Otherwise,
> READ = (index), referring to codebook.

Yes, this is a simple solution and personally I like it. We could state that
the decompressor implementation must support both a byte-buffer and a
codebook. I believe that the extra complexity of supporting both is very
small. This will then also exclude one parameter to negotiate.

BR
/Hans H

------=_NextPart_000_0005_01C14812.60C26B90
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+Ih8JAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCQAcAAsAKAAAAAUANQEB
A5AGAFwLAAArAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA
AAAAAwA2AAAAAAAeAHAAAQAAADAAAABbcm9oY10gUkU6IFtTaW1wbGVdIE1FU1NBR0Ugc2Vzc2lv
bnMgLSBvdmVyIFRDUAACAXEAAQAAABYAAAABwUgBnHTq30Xas9cR1ZBkAACGXUHiAAACAR0MAQAA
ACAAAABTTVRQOkhBTlMuSEFOTlVARVBMLkVSSUNTU09OLlNFAAsAAQ4AAAAAQAAGDgDYkIoBSMEB
AgEKDgEAAAAYAAAAAAAAACVeM8aVjdURtrcAAIZdQeLCgAAAAwAUDgEAAAALAB8OAQAAAAMABhB8
ZOMBAwAHEMEHAAAeAAgQAQAAAGUAAABISSxTRUVDT01NRU5UU0lOTElORUlBR1JFRVRIQVRUSEVO
RUdPVElBVElPTldIRVRIRVJUT0FQUExZQ09NUFJFU1NJT05CRVRXRUVOVFdPUEFSVElFU09STk9U
U0hPVUxEQkVUAAAAAAIBCRABAAAAfAYAAHgGAADHCwAATFpGdSrz1cwDAAoAcmNwZzEyNeIyA0N0
ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRG
E7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAULMLCQFkMzYWUAunYwEw8CBIaSwKogqECoAGYPRlIAWg
bQeAAjAEIAuAkmwLgGUuHWo+ICAgyEkgYQnCIHQT4AVAxyDgHkAfMGdvdAcwIbA5AiAgdyFAITEF
wHRv1SBwcAtQeR5ScBggBBBrIfIfyGIUIHcJ4SDQd18iwAqxIbAHkQWxbiGgIGRzaAhgbGQkkSDQ
YZprJPFjCsAeQG9mJJH7AhAncSgLgCP5ITInUBQQISeSU0lQKSEjZmkPFAAFQCnhIFBOVklUNEUg
B4FzIIAHkC4g4FRodXMsINEEACP5bydQA6AmEibBZAIgHkBi8SMgU2lnCFAjYB7gHsB4ZWxmH1Ug
IDAPMFJetzFkH8YgYGcKUAQReQhglytxA5Ep4T8dak5vLGDvIGAuICYCLABXIk8jWSXv/QWBaQEA
JqEjICEyNfIN4Psh1B9AZywAKeE6AS62BCD+aixAIRQ1wAbwINg5GgPw/mwDICxAKlEFsSNJLAAd
au5CKXA5UT1weSxiBJA48a8ncSUiBAEygTodZDEqEP81RiNKLKE1wSbBORM4cTcU5R1VMioQSG8H
4DXBIXbvIMIeQC6mCrFhB4AOsBQA/SgwSSewAHAjIB8wCYBDlvlGB2QpNSIhASTQJkY0wf9DhCp0
AQEfISIhIQFHaSDj+0pyHjFhSINFyywCJPFKcZ8FoCaCKqAlcSxybmsLgH5nJ5ImYEWzNMEhPSwA
QfZuJqAHQHNBISewITJHaf9OVkkrNwJTxCMhA5EmwQCQrGduB0A4cSIoUWIAcMRkIj7cMSAtNT8u
l282XyY6VZk4r24sYDnYQv0FkGE9oi8gQ3M8biyQE9D0IGsmEHcEICIxQNIhQf8hoDWCJWIjICyh
F7A5YQmA/ywASCEsgyyhLiMD8CDgTiN/B+Aq0kehJmBEcwDQBaFkG1ESNcA6UXACQHA6L8Qvd2gw
LmNkNRAKQBUg4C4UEC8DYGJoYwAvbXNnMDIzNfQ4LmfAbQMhHXMIABQQkm4koHJnZ6AiTSMg+SNw
b3Bq4AdAPdMEYh8R32dhLJIpcE4hKtJ0R4AAgP9r8FCRE+BTQFewTVIsoSli92QxJkAsQHAFkCES
IQUsQOMrwSmjUlYgGCBnAixR704wJxBroQiQYyeDRqMq4fc18QNgANBoLGA9U1NzJTD8cmsqYS5B
PeJi1Dkaa8E/NcAXkSxRQWBhoW1xUlS6UzpAIh1qMdcDoG0jIHp2CJB3QEMhax/GJlhl/2VhEoFM
BCagZVMup1vRLkH5LiBjdR6SVjMj6E4wFBBnR2JGcX73KGJ3ITWBL78AkCqgEoEpsi60SfFCaMD/
fnJ8xR/GKWJ0UUqIR4AH4K9OMB8SJJcq0ighMiI9ofxyIoKaf9hTQS6mh1OHwf96QHLxa8F6QASB
SfFPgR7h/UfBZgDQhncfxjtzQRN6n/93Fj7cIGdSAkpMhe8lAXNk/3RRYYM9oQQgLtIjhXJBiWn/
IONwIIwQBbBpkCkUPj8ft/5BQ5M7dCcSlqIhACxRLjK/AJAjYFewKDCWcRPgcGTh/X8gYioQU5Bo
sSHxH8ZDhP9MBSUiFBElwVPRmapnoC4ysT3iTFpTBfCBoHkOsHgtYnUBIItBiNqfqFf/KDAFoAEA
BuCZoItkT7MCIH8jEU5TLjNgEpM0H8YhQGH/BIElUzWyV2RhZRQRJkk9oe9Og2vBcvAEEWGEVyNV
XYH7K4UsAEYFsQ7AR5Ca8SxgvVPFZgtgUTCn0jXBMB1VgSAgUkVBRCA9myG+b4vTLGBXsFEgIOAp
LGD/GCChAQUQZ1MuYUZxoNQsAH5PNXID8YUAra4LgAEAePevnqLWH1tZB5AsZW1Cmrb/nCaJQ5Zx
U5BXkSMRIGAfEP8nEC8RNSFP6UZzIQUFgiNk71ZCmuIekiHUbTsyQWA2AP9uYgbgZXOgiYlDTjC0
VyBR+ySgREF2IMkOwUeAIzNXsP54LyAjICehvMVREr1DLKH1v+ByIyBzAMA9cCwCLKHfPVMhMbdx
U4IOwGMKQAEAL36jR2dOnD77Uh1kL0gVBiJIHWR9yWADABAQAAAAAAMAERAAAAAAHgBCEAEAAABA
AAAAPEI4MUM4OTQwNEE5QkQ2NDk4M0UzNjlCN0Q0NDUzOTQxMEQ1NkVEQGRhZWJlMDA1Lk5PRS5O
b2tpYS5jb20+AAMACVkBAAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAG
AAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMACIAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAA
AwBagAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAANYZAAAeAFuACCAGAAAAAADAAAAAAAAARgAAAABU
hQAAAQAAAAQAAAA4LjUACwBcgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAALAF2ACCAGAAAA
AADAAAAAAAAARgAAAAAOhQAAAAAAAAMAXoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwBf
gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAGCACCAGAAAAAADAAAAAAAAARgAAAAA2hQAA
AQAAAAEAAAAAAAAAHgBhgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AYoAI
IAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAGOACyAGAAAAAADAAAAAAAAARgAA
AAAAiAAAAAAAAAsAZIALIAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAAAgH4DwEAAAAQAAAAJV4z
xpWN1RG2twAAhl1B4gIB+g8BAAAAEAAAACVeM8aVjdURtrcAAIZdQeICAfsPAQAAAGUAAAAAAAAA
OKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XFdJTk5U
XFByb2ZpbGVzXGVwbGhhaHVcUGVyc29uYWxcTWFpbHRvb2wucHN0AAAAAAMA/g8FAAAAAwANNP03
AAACAX8AAQAAADEAAAAwMDAwMDAwMDI1NUUzM0M2OTU4REQ1MTFCNkI3MDAwMDg2NUQ0MUUyNDQz
QjI0MDAAAAAA0Q4=

------=_NextPart_000_0005_01C14812.60C26B90--


From Avshalom@ubique.com  Fri Sep 28 05:43:21 2001
Received: from ubqgate02.lotus.com ([194.196.39.50])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19149;
	Fri, 28 Sep 2001 05:43:18 -0400 (EDT)
From: Avshalom@ubique.com
Subject: RE: [Simple] MESSAGE sessions - over TCP
To: Jonathan Rosenberg 
Cc: Dror@vocaltec.com, "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Fri, 28 Sep 2001 11:41:06 +0200
X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at
 28/09/2001 11:42:00
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 4613
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: 

I think that this all thread started from the following IESG requirement
that was sent by Jon Paterson at 20 August 2001:

<<<
The IESG has some concerns that this mechanism constitutes the use of SIP
as
a transport protocol. In other words, once the session has been established
between the two endpoints by the INVITE, if the MESSAGEs can only go
directly end-to-end, then their headers and related protocol apparatus are
entirely superfluous and may do more harm than good. We saw during the
meeting last week that there were definitely some pitfalls to allowing
methods other than MESSAGE across the IM stream (as well as questions about
overlapping transactions, redirection, forking, and so forth), and it isn't
clear that the overhead is justified if MESSAGE is just an envelope for its
encapsulated MIME payload. The IESG was particularly concerned, in addition
to the protocol overhead, with congestion characteristics of the messaging
session and with the precedent that could be set by using SIP in this
fashion.
>>>

I am not sure if this means that if we define a session and the messages
will not have superfluous headers
then it will be OK with the IESG. I certainly hope so.

avshalom
Sametime/IBM/Lotus



                                                                                                                                
                    Jonathan Rosenberg                                                                                          
                             To:     "'Petri K. Koskelainen'" ,                
                    Sent by:                          Dror@vocaltec.com                                                         
                    simple-admin@mailman.dynam        cc:     simple@mailman.dynamicsoft.com                                    
                    icsoft.com                        Subject:     RE: [Simple] MESSAGE sessions - over TCP                     
                                                                                                                                
                                                                                                                                
                    26/09/2001 22:30                                                                                            
                                                                                                                                
                                                                                                                                







> -----Original Message-----
> From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> Sent: Wednesday, September 26, 2001 1:21 PM
> To: Dror@vocaltec.com
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] MESSAGE sessions - over TCP
>
> Is there a consensus that INVITE-established IM messaging
> session idea is ok ? (in addition to one shot MESSAGEs)
>
>
> If we can agree on that, then we can continue with other
> problems, like:
> - messaging protocol/format inside a session (e.g. SIP
> MESSAGE over TCP)
> - direct end-to-end vs. via signaling proxies vs. via IM servers
> - compression (hopefully this does not have to be discussed here)
>
> There should be a resolution on this asap.

Yes, part of the reason we are circling around is that we have not been
able
to break the problem into pieces. Clearly the first is the question Petri
has asked - can we agree that a session model for messaging (session model
being to wrap it in INVITE/BYE, and the messages are viewed as a media
stream.) THis says nothing about how they are transported, and wouldn't
rule
out sending them over the signaling channel.

I strongly support this need for a session model. I think most have
expressed support for it, with a few notable exceptions (Dean, I think).

I think its time for the chairs to make a ruling on consensus on whether to
pursue a session model as defined above.

We would still retain the paging model of course,

-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 Brian.Rosen@marconi.com  Fri Sep 28 08:26:08 2001
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 IAA19680;
	Fri, 28 Sep 2001 08:26:07 -0400 (EDT)
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 IAA21056;
	Fri, 28 Sep 2001 08:25:54 -0400 (EDT)
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 IAA23282;
	Fri, 28 Sep 2001 08:25:54 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 28 Sep 2001 08:25:52 -0400
Message-ID: <313680C9A886D511A06000204840E1CF57C27B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Avshalom@ubique.com'" 
Cc: Jonathan Rosenberg , Dror@vocaltec.com,
        "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
Subject: RE: [Simple] MESSAGE sessions - over TCP
Date: Fri, 28 Sep 2001 08:25:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Length: 6110
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: 

I'd appreciate staying with Petri's question:
> > Is there a consensus that INVITE-established IM messaging
> > session idea is ok ? (in addition to one shot MESSAGEs)

I agree with it.  I'd like to hear from anyone who doesn't
agree with it before we have more discussion on what
form the INVITE-established IM Messaging takes (both what
the format of the messages are and the transport that they
run on).  The question on the table is only whether we
believe we require sessions of messages initiated by
INVITE.  I think that implies an SDP expressed description
of the format and transport of the session.

If we get a consensus on the need, THEN we can start talking
about format and transport.

Brian

> -----Original Message-----
> From: Avshalom@ubique.com [mailto:Avshalom@ubique.com]
> Sent: Friday, September 28, 2001 5:41 AM
> To: Jonathan Rosenberg
> Cc: Dror@vocaltec.com; 'Petri K. Koskelainen';
> simple@mailman.dynamicsoft.com; simple-admin@mailman.dynamicsoft.com
> Subject: RE: [Simple] MESSAGE sessions - over TCP
> 
> 
> 
> I think that this all thread started from the following IESG 
> requirement
> that was sent by Jon Paterson at 20 August 2001:
> 
> <<<
> The IESG has some concerns that this mechanism constitutes 
> the use of SIP
> as
> a transport protocol. In other words, once the session has 
> been established
> between the two endpoints by the INVITE, if the MESSAGEs can only go
> directly end-to-end, then their headers and related protocol 
> apparatus are
> entirely superfluous and may do more harm than good. We saw during the
> meeting last week that there were definitely some pitfalls to allowing
> methods other than MESSAGE across the IM stream (as well as 
> questions about
> overlapping transactions, redirection, forking, and so 
> forth), and it isn't
> clear that the overhead is justified if MESSAGE is just an 
> envelope for its
> encapsulated MIME payload. The IESG was particularly 
> concerned, in addition
> to the protocol overhead, with congestion characteristics of 
> the messaging
> session and with the precedent that could be set by using SIP in this
> fashion.
> >>>
> 
> I am not sure if this means that if we define a session and 
> the messages
> will not have superfluous headers
> then it will be OK with the IESG. I certainly hope so.
> 
> avshalom
> Sametime/IBM/Lotus
> 
> 
> 
>                                                               
>                                                                   
>                     Jonathan Rosenberg                        
>                                                                   
>                              To:     
> "'Petri K. Koskelainen'" ,                
>                     Sent by:                          
> Dror@vocaltec.com                                             
>             
>                     simple-admin@mailman.dynam        cc:     
> simple@mailman.dynamicsoft.com                                    
>                     icsoft.com                        
> Subject:     RE: [Simple] MESSAGE sessions - over TCP         
>             
>                                                               
>                                                                   
>                                                               
>                                                                   
>                     26/09/2001 22:30                          
>                                                                   
>                                                               
>                                                                   
>                                                               
>                                                                   
> 
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> > Sent: Wednesday, September 26, 2001 1:21 PM
> > To: Dror@vocaltec.com
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] MESSAGE sessions - over TCP
> >
> > Is there a consensus that INVITE-established IM messaging
> > session idea is ok ? (in addition to one shot MESSAGEs)
> >
> >
> > If we can agree on that, then we can continue with other
> > problems, like:
> > - messaging protocol/format inside a session (e.g. SIP
> > MESSAGE over TCP)
> > - direct end-to-end vs. via signaling proxies vs. via IM servers
> > - compression (hopefully this does not have to be discussed here)
> >
> > There should be a resolution on this asap.
> 
> Yes, part of the reason we are circling around is that we 
> have not been
> able
> to break the problem into pieces. Clearly the first is the 
> question Petri
> has asked - can we agree that a session model for messaging 
> (session model
> being to wrap it in INVITE/BYE, and the messages are viewed as a media
> stream.) THis says nothing about how they are transported, 
> and wouldn't
> rule
> out sending them over the signaling channel.
> 
> I strongly support this need for a session model. I think most have
> expressed support for it, with a few notable exceptions 
> (Dean, I think).
> 
> I think its time for the chairs to make a ruling on consensus 
> on whether to
> pursue a session model as defined above.
> 
> We would still retain the paging model of course,
> 
> -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 Avshalom@ubique.com  Fri Sep 28 08:52:01 2001
Received: from ubqgate02.lotus.com ([194.196.39.50])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19787;
	Fri, 28 Sep 2001 08:51:59 -0400 (EDT)
From: Avshalom@ubique.com
Subject: RE: [Simple] MESSAGE sessions - over TCP
To: "Rosen, Brian" 
Cc: Dror@vocaltec.com, Jonathan Rosenberg ,
        "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Fri, 28 Sep 2001 14:49:26 +0200
X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at
 28/09/2001 14:50:42
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 6574
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: 

> I'd appreciate staying with Petri's question:
> > > Is there a consensus that INVITE-established IM messaging
> > > session idea is ok ? (in addition to one shot MESSAGEs)

I think that INVITE-established IM sessions are essential. Especially when
dealing with multi-party chat. Also in one to one, establishing a session
may yield certain benefits as deciding on the encryption to be usedand and
other properties of the session.

avshalom
Sametime/Lotus/IBM



                                                                                                                     
                    "Rosen, Brian"                                                                                   
                                         
                    rconi.com>             cc:     Jonathan Rosenberg , Dror@vocaltec.com,  
                                           "'Petri K. Koskelainen'" ,                        
                    28/09/2001             simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com      
                    14:25                  Subject:     RE: [Simple] MESSAGE sessions - over TCP                     
                                                                                                                     
                                                                                                                     



I'd appreciate staying with Petri's question:
> > Is there a consensus that INVITE-established IM messaging
> > session idea is ok ? (in addition to one shot MESSAGEs)

I agree with it.  I'd like to hear from anyone who doesn't
agree with it before we have more discussion on what
form the INVITE-established IM Messaging takes (both what
the format of the messages are and the transport that they
run on).  The question on the table is only whether we
believe we require sessions of messages initiated by
INVITE.  I think that implies an SDP expressed description
of the format and transport of the session.

If we get a consensus on the need, THEN we can start talking
about format and transport.

Brian

> -----Original Message-----
> From: Avshalom@ubique.com [mailto:Avshalom@ubique.com]
> Sent: Friday, September 28, 2001 5:41 AM
> To: Jonathan Rosenberg
> Cc: Dror@vocaltec.com; 'Petri K. Koskelainen';
> simple@mailman.dynamicsoft.com; simple-admin@mailman.dynamicsoft.com
> Subject: RE: [Simple] MESSAGE sessions - over TCP
>
>
>
> I think that this all thread started from the following IESG
> requirement
> that was sent by Jon Paterson at 20 August 2001:
>
> <<<
> The IESG has some concerns that this mechanism constitutes
> the use of SIP
> as
> a transport protocol. In other words, once the session has
> been established
> between the two endpoints by the INVITE, if the MESSAGEs can only go
> directly end-to-end, then their headers and related protocol
> apparatus are
> entirely superfluous and may do more harm than good. We saw during the
> meeting last week that there were definitely some pitfalls to allowing
> methods other than MESSAGE across the IM stream (as well as
> questions about
> overlapping transactions, redirection, forking, and so
> forth), and it isn't
> clear that the overhead is justified if MESSAGE is just an
> envelope for its
> encapsulated MIME payload. The IESG was particularly
> concerned, in addition
> to the protocol overhead, with congestion characteristics of
> the messaging
> session and with the precedent that could be set by using SIP in this
> fashion.
> >>>
>
> I am not sure if this means that if we define a session and
> the messages
> will not have superfluous headers
> then it will be OK with the IESG. I certainly hope so.
>
> avshalom
> Sametime/IBM/Lotus
>
>
>
>
>
>                     Jonathan Rosenberg
>
>                              To:
> "'Petri K. Koskelainen'" ,
>                     Sent by:
> Dror@vocaltec.com
>
>                     simple-admin@mailman.dynam        cc:
> simple@mailman.dynamicsoft.com
>                     icsoft.com
> Subject:     RE: [Simple] MESSAGE sessions - over TCP
>
>
>
>
>
>                     26/09/2001 22:30
>
>
>
>
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> > Sent: Wednesday, September 26, 2001 1:21 PM
> > To: Dror@vocaltec.com
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] MESSAGE sessions - over TCP
> >
> > Is there a consensus that INVITE-established IM messaging
> > session idea is ok ? (in addition to one shot MESSAGEs)
> >
> >
> > If we can agree on that, then we can continue with other
> > problems, like:
> > - messaging protocol/format inside a session (e.g. SIP
> > MESSAGE over TCP)
> > - direct end-to-end vs. via signaling proxies vs. via IM servers
> > - compression (hopefully this does not have to be discussed here)
> >
> > There should be a resolution on this asap.
>
> Yes, part of the reason we are circling around is that we
> have not been
> able
> to break the problem into pieces. Clearly the first is the
> question Petri
> has asked - can we agree that a session model for messaging
> (session model
> being to wrap it in INVITE/BYE, and the messages are viewed as a media
> stream.) THis says nothing about how they are transported,
> and wouldn't
> rule
> out sending them over the signaling channel.
>
> I strongly support this need for a session model. I think most have
> expressed support for it, with a few notable exceptions
> (Dean, I think).
>
> I think its time for the chairs to make a ruling on consensus
> on whether to
> pursue a session model as defined above.
>
> We would still retain the paging model of course,
>
> -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 sean.olson@ericsson.com  Fri Sep 28 10:53:38 2001
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 KAA20222
	for ; Fri, 28 Sep 2001 10:53:33 -0400 (EDT)
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 f8SErPY15186
	for ; Fri, 28 Sep 2001 09:53:25 -0500 (CDT)
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 f8SErP922864
	for ; Fri, 28 Sep 2001 09:53:25 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Sep 28 09:53:23 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 28 Sep 2001 09:53:23 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Avshalom@ubique.com'" ,
        "Rosen, Brian"
	 
Cc: Dror@vocaltec.com, Jonathan Rosenberg ,
        "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
Subject: RE: [Simple] MESSAGE sessions - over TCP
Date: Fri, 28 Sep 2001 09:53:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1482D.516E0EE0"
Content-Length: 2524
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: 

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_01C1482D.516E0EE0
Content-Type: text/plain;
	charset="iso-8859-1"


>> I'd appreciate staying with Petri's question:
>> > > Is there a consensus that INVITE-established IM messaging
>> > > session idea is ok ? (in addition to one shot MESSAGEs)
>
>I think that INVITE-established IM sessions are essential. 
>Especially when
>dealing with multi-party chat.

I keep hearing statements like this, but it seems
that multi-party chat is actually easier to implement
using a paging model and a implicit session concept.

If you want a chat session, what is wrong with the 
RTP text stuff (ignoring the unicode/MIME issues)

I am personally in favor of INVITE-established IM
messaging as well, but I think its principal 
purpose is efficiency.

Sean Olson
Ericsson Inc.

------_=_NextPart_001_01C1482D.516E0EE0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] MESSAGE sessions - over TCP






>> I'd appreciate staying with Petri's question:

>> > > Is there a consensus that INVITE-established IM messaging

>> > > session idea is ok ? (in addition to one shot MESSAGEs)

>

>I think that INVITE-established IM sessions are essential. 

>Especially when

>dealing with multi-party chat.




I keep hearing statements like this, but it seems

that multi-party chat is actually easier to implement

using a paging model and a implicit session concept.




If you want a chat session, what is wrong with the 

RTP text stuff (ignoring the unicode/MIME issues)




I am personally in favor of INVITE-established IM

messaging as well, but I think its principal 

purpose is efficiency.




Sean Olson

Ericsson Inc.





------_=_NextPart_001_01C1482D.516E0EE0--

From Brian.Rosen@marconi.com  Fri Sep 28 10:59:46 2001
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 KAA20271;
	Fri, 28 Sep 2001 10:59:46 -0400 (EDT)
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 KAA10490;
	Fri, 28 Sep 2001 10:59:35 -0400 (EDT)
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 KAA15261;
	Fri, 28 Sep 2001 10:59:34 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 28 Sep 2001 10:59:32 -0400
Message-ID: <313680C9A886D511A06000204840E1CF57C280@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Sean Olson (EUS)'" ,
        "'Avshalom@ubique.com'" 
Cc: Dror@vocaltec.com, Jonathan Rosenberg ,
        "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
Subject: RE: [Simple] MESSAGE sessions - over TCP
Date: Fri, 28 Sep 2001 10:59:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1482E.1E259700"
Content-Length: 4578
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: 

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_01C1482E.1E259700
Content-Type: text/plain;
	charset="ISO-8859-1"

The reason you want to have sessions, with a transport with flow controls,
is to support large server based systems.  If you were very successful, your
proxy servers may be asked to handle millions of messages.  You want flow
controls for this folks.  It may not matter to the individual endpoints, but
it matters a lot to any aggregation resources.
 
Brian

-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, September 28, 2001 10:53 AM
To: 'Avshalom@ubique.com'; Rosen, Brian
Cc: Dror@vocaltec.com; Jonathan Rosenberg; 'Petri K. Koskelainen';
simple@mailman.dynamicsoft.com; simple-admin@mailman.dynamicsoft.com
Subject: RE: [Simple] MESSAGE sessions - over TCP




>> I'd appreciate staying with Petri's question: 
>> > > Is there a consensus that INVITE-established IM messaging 
>> > > session idea is ok ? (in addition to one shot MESSAGEs) 
> 
>I think that INVITE-established IM sessions are essential. 
>Especially when 
>dealing with multi-party chat. 

I keep hearing statements like this, but it seems 
that multi-party chat is actually easier to implement 
using a paging model and a implicit session concept. 

If you want a chat session, what is wrong with the 
RTP text stuff (ignoring the unicode/MIME issues) 

I am personally in favor of INVITE-established IM 
messaging as well, but I think its principal 
purpose is efficiency. 

Sean Olson 
Ericsson Inc. 


------_=_NextPart_001_01C1482E.1E259700
Content-Type: text/html;
	charset="ISO-8859-1"




RE: [Simple] MESSAGE sessions - over TCP




The reason 
you want to have sessions, with a transport with flow controls, is to support 
large server based systems.  If you were very successful, your proxy 
servers may be asked to handle millions of messages.  You want flow 
controls for this folks.  It may not matter to the individual endpoints, 
but it matters a lot to any aggregation resources.


 


Brian



  
-----Original Message-----
From: Sean Olson (EUS) 
  [mailto:sean.olson@ericsson.com]
Sent: Friday, September 28, 2001 
  10:53 AM
To: 'Avshalom@ubique.com'; Rosen, Brian
Cc: 
  Dror@vocaltec.com; Jonathan Rosenberg; 'Petri K. Koskelainen'; 
  simple@mailman.dynamicsoft.com; 
  simple-admin@mailman.dynamicsoft.com
Subject: RE: [Simple] MESSAGE 
  sessions - over TCP



  
>> I'd appreciate staying with Petri's question: 
  
>> > > Is there a consensus that 
  INVITE-established IM messaging 
>> > > 
  session idea is ok ? (in addition to one shot MESSAGEs) 
> 
>I think that INVITE-established IM 
  sessions are essential. 
>Especially when 
  
>dealing with multi-party chat. 

  
I keep hearing statements like this, but it seems 
  
that multi-party chat is actually easier to implement 
  
using a paging model and a implicit session concept. 
  

  
If you want a chat session, what is wrong with the 
  
RTP text stuff (ignoring the unicode/MIME 
  issues) 

  
I am personally in favor of INVITE-established IM 
  
messaging as well, but I think its principal 
purpose is efficiency. 

  
Sean Olson 
Ericsson Inc. 



------_=_NextPart_001_01C1482E.1E259700--

From petkos@cs.columbia.edu  Fri Sep 28 11:19:37 2001
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 LAA20375;
	Fri, 28 Sep 2001 11:19:36 -0400 (EDT)
Received: from dynamo.cs.columbia.edu (dynamo.cs.columbia.edu [128.59.16.4])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA16909;
	Fri, 28 Sep 2001 11:19:26 -0400 (EDT)
Received: (from petkos@localhost)
	by dynamo.cs.columbia.edu (8.9.3+Sun/8.9.3) id LAA01838;
	Fri, 28 Sep 2001 11:19:24 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200109281519.LAA01838@dynamo.cs.columbia.edu>
Subject: Re: [Simple] MESSAGE sessions - over TCP
To: sean.olson@ericsson.com ("Sean Olson (EUS)")
Date: Fri, 28 Sep 2001 11:19:24 -0400 (EDT)
Cc: Avshalom@ubique.com ('Avshalom@ubique.com'),
        Brian.Rosen@marconi.com (Rosen Brian), Dror@vocaltec.com,
        jdrosen@dynamicsoft.com (Jonathan Rosenberg),
        petkos@cs.columbia.edu ('Petri K. Koskelainen'),
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
In-Reply-To:  from "Sean Olson (EUS)" at Sep 28, 2001 09:53:21 AM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 274
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: 

> If you want a chat session, what is wrong with the 
> RTP text stuff (ignoring the unicode/MIME issues)

Reliability, for instance.


> I am personally in favor of INVITE-established IM
> messaging as well, but I think its principal 
> purpose is efficiency.



--
Petri

From pkyzivat@cisco.com  Fri Sep 28 11:38:36 2001
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 LAA20463;
	Fri, 28 Sep 2001 11:38:36 -0400 (EDT)
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 f8SFbmA14339;
	Fri, 28 Sep 2001 11:37:48 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB05521 (AUTH pkyzivat);
	Fri, 28 Sep 2001 11:39:43 -0400 (EDT)
Message-ID: <3BB4991B.1A4FDC57@cisco.com>
Date: Fri, 28 Sep 2001 11:36:59 -0400
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: "Sean Olson (EUS)" 
CC: "'Avshalom@ubique.com'" ,
        "Rosen, Brian" , Dror@vocaltec.com,
        Jonathan Rosenberg ,
        "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
Subject: Re: [Simple] MESSAGE sessions - over TCP
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 978
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: 


> "Sean Olson (EUS)" wrote:
> 
> >I think that INVITE-established IM sessions are essential.
> >Especially when
> >dealing with multi-party chat.
> 
> I keep hearing statements like this, but it seems
> that multi-party chat is actually easier to implement
> using a paging model and a implicit session concept.

- having an IM session is needed so that you can make a
  call that associates IM and other media that are
  intended to be used together

- having an IM session negotiated with sip invite means
  you can use standard sip call control techniques to
  request transfer, conferencing, etc. This becomes
  especially interesting when the call involves multiple
  media, because then the call control switches all the
  media in a parallel, coordinated way.

It may be possible to simulate the above features using
paging mode IM with no IM session, but doing so will
require new call control techniques that treat IM as a
special case.

	Paul Kyzivat
	Cisco Systems

From Basavaraj.Patil@nokia.com  Fri Sep 28 12:14:46 2001
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 MAA20625
	for ; Fri, 28 Sep 2001 12:14:45 -0400 (EDT)
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 f8SGFB709866
	for ; Fri, 28 Sep 2001 19:15:11 +0300 (EET DST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8SGEoC29629
	for ; Fri, 28 Sep 2001 11:14:51 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 28 Sep 2001 11:14:34 -0500
Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 28 Sep 2001 11:14:34 -0500
content-class: urn:content-classes:message
Subject: RE: [Simple] MESSAGE sessions - over TCP
Date: Fri, 28 Sep 2001 11:14:41 -0500
Message-ID: <697DAA22C5004B4596E033803A7CEF441E8771@daebe007.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] MESSAGE sessions - over TCP
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFGtkghIhG/2bKpEdWJUwAIx6TWpQBgh7Ng
From: "Patil Basavaraj (NET/Dallas)" 
To: "'ext Petri K. Koskelainen'" , 
Cc: 
X-OriginalArrivalTime: 28 Sep 2001 16:14:34.0537 (UTC) FILETIME=[A9B08190:01C14838]
Content-Length: 1452
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA20625
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: 

>
>If you have just one message to send, you don't have to 
>establish a session. Just send a MESSAGE. 
>No need for INVITE then.
>
>In general, IM session is just another media stream just like 
>audio or video stream.
>Often it is established at the same time than the
>audio and video streams (one m line for each media stream).
>This is the ideal situation since it allows all the
>control and flexibility of INVITE for IM session 
>(e.g. mobility, record-route, multi-party IM..).
>

mobility???

>Still, one-shot MESSAGEs can be sent if someone does
>not want to use the session model.
>

Exactly. You can achieve the same effect of an IM session with a set
of one-shot MESSAGE exchanges between the two end-points. So what is
the gain in doing an INVITE before exchanging a number of MESSAGEs. 

>Is there a consensus that INVITE-established IM messaging 
>session idea is ok ? (in addition to one shot MESSAGEs)
>

Not (yet) entirely convinced on the need for IM sessions. Hopefully
there are others who think IM sessions are really a critical feature
for IM and voice their opinions. 

>
>If we can agree on that, then we can continue with other problems,
like:
>- messaging protocol/format inside a session (e.g. SIP MESSAGE over
TCP)
>- direct end-to-end vs. via signaling proxies vs. via IM servers 
>- compression (hopefully this does not have to be discussed here)
> 
>There should be a resolution on this asap.
>
>--
>Petri

-Basavaraj

From sriramp@nortelnetworks.com  Fri Sep 28 12:40:22 2001
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 MAA20727
	for ; Fri, 28 Sep 2001 12:40:21 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA01358
	for ; Fri, 28 Sep 2001 11:40:06 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 28 Sep 2001 11:33:28 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 28 Sep 2001 11:39:49 -0500
Message-ID: <9A9367D1556AD21182C40000F80930AB04411DF4@crchy28b.us.nortel.com>
From: "Sriram Parameswar" 
To: "'Patil Basavaraj (NET/Dallas)'" ,
        "'ext Petri K. Koskelainen'" ,
        Dror 
Cc: simple 
Subject: RE: [Simple] MESSAGE sessions - over TCP
Date: Fri, 28 Sep 2001 11:39:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1483C.269A5250"
X-Orig: 
Content-Length: 5114
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: 

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_01C1483C.269A5250
Content-Type: text/plain;
	charset="iso-8859-1"

Just a thought in-line. 

Regards,

Sriram

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



>Still, one-shot MESSAGEs can be sent if someone does
>not want to use the session model.
>

[bpatil]Exactly. You can achieve the same effect of an IM session with a set
of one-shot MESSAGE exchanges between the two end-points. So what is
the gain in doing an INVITE before exchanging a number of MESSAGEs. 

[Sriram] At the UA it is easier to tie multiple different converstations
together if it has been set up using an INVITE. For example all messages in
a session show up in one window while all one-shot messages show up in a
pop up box (yes... I know this is an implementation issue, still there is
merit in looking at it). Other methods suggested on the list of using
one-shot
messages and tie them together into a session are hacks IMHO.

>Is there a consensus that INVITE-established IM messaging 
>session idea is ok ? (in addition to one shot MESSAGEs)
>

[bpatil]Not (yet) entirely convinced on the need for IM sessions. Hopefully
there are others who think IM sessions are really a critical feature
for IM and voice their opinions. 

[Sriram] Another example is when Messaging is added to an existing session,
it would be simpler to re-invite and add on another media. An example of
the applicability would be - call to a help-center to set up a 
product (foo); they open a messaging window in the context of the 
existing session and send you line-by-line written instructions.

I would think there is a fair bit of consensus.

------_=_NextPart_001_01C1483C.269A5250
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] MESSAGE sessions - over TCP




Just a thought in-line. 




Regards,




Sriram




__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-685-3563

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com








>Still, one-shot MESSAGEs can be sent if someone =
does

>not want to use the session model.

>




[bpatil]Exactly. You can achieve the same effect of =
an IM session with a set

of one-shot MESSAGE exchanges between the two =
end-points. So what is

the gain in doing an INVITE before exchanging a =
number of MESSAGEs. 




[Sriram] At the UA it is easier to tie multiple =
different converstations

together if it has been set up using an INVITE. For =
example all messages in

a session show up in one window while all one-shot =
messages show up in a

pop up box (yes... I know this is an implementation =
issue, still there is

merit in looking at it). Other methods suggested on =
the list of using one-shot

messages and tie them together into a session are =
hacks IMHO.




>Is there a consensus that INVITE-established IM =
messaging 

>session idea is ok ? (in addition to one shot =
MESSAGEs)

>




[bpatil]Not (yet) entirely convinced on the need for =
IM sessions. Hopefully

there are others who think IM sessions are really a =
critical feature

for IM and voice their opinions. 




[Sriram] Another example is when Messaging is added =
to an existing session,

it would be simpler to re-invite and add on another =
media. An example of

the applicability would be - call to a help-center =
to set up a 

product (foo); they open a messaging window in the =
context of the 

existing session and send you line-by-line written =
instructions.




I would think there is a fair bit of =
consensus.





------_=_NextPart_001_01C1483C.269A5250--

From bstucker@nortelnetworks.com  Fri Sep 28 16:48:00 2001
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 QAA21472
	for ; Fri, 28 Sep 2001 16:48:00 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA17939
	for ; Fri, 28 Sep 2001 15:47:46 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Fri, 28 Sep 2001 15:47:40 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 28 Sep 2001 15:47:24 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E2E4665@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: simple 
Date: Fri, 28 Sep 2001 15:47:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1485E.C27381C0"
Content-Length: 8059
Subject: [Simple] Migration and client PA as a definitive authority.
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: 

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_01C1485E.C27381C0
Content-Type: text/plain;
	charset="iso-8859-1"

Question about presence migration. Still looking at it, and the new 03 draft
clears a lot of questions up, but one still remains for me...
 
How do we go about ensuring that a PUA that signals that it wishes to become
the PA for the presentity, by migrating the PA away
from the presence server, is the definitive source of the aggregated
presence information?
 
As I understand it, the PUAs feed presence fragments to the PA via the
REGISTER method, which a client UA shouldn't be receiving
as it's not a registrar. Therefore, if the client PA/PUA doesn't have a way
of getting the presence fragments from the other various
PUAs (at least not through SIP), should it be allowed to migrate the PA
function away from the presence server? I know we could signal
across devices using some means other than SIP, but looking at this as a
state agent handling state synchronization within an event
framework, shouldn't there be defined a method to use the same protocol for
this job (SIP) as a baseline mechanism?
 
I noticed in the documentation under the migration and forking sections text
that said that it was best for a network PA to do aggregation,
and I agree with that. How do we ensure that the aggregation is handled
correctly when the PA is no longer in the network?
 
Another question that I have regards what is really saved by migrating to a
client device? We still have to keep the presence server in the route
in order to detect migration back to the presence server from the client
PA/PUA. The notifications still have to travel through the presence server
because they must follow the same route as was established in the SUBSCRIBE.
So it seems that all we're saving is the aggregation piece, which
seems relatively simple to do from a centralized server.
 
The reason I bring the last bit up is because one way I was thinking the PUA
information could be dealt with is by making the presence server a
reflector of the information fed in by PUAs in registrations by way of
having the PA/PUA subscribe to itself at the presence server (which would
always be allowed, and this portion of the PA would not migrate). That way
the registrations cause a NOTIFY to be sent back to the migrated PA to
keep it in sync.
 
Does this make any sense, or am I seriously off in the weeds somewhere?
 
Thanks all,
 
Brian

------_=_NextPart_001_01C1485E.C27381C0
Content-Type: text/html;
	charset="iso-8859-1"




RE: [Simple] MESSAGE sessions - over TCP




Question about presence migration. Still looking at it, and the new 
03 draft clears a lot of questions up, but one still remains for 
me...


 


How do 
we go about ensuring that a PUA that signals that it wishes to become the PA for 
the presentity, by migrating the PA away


from 
the presence server, is the definitive source of the aggregated presence 
information?


 


As I 
understand it, the PUAs feed presence fragments to the PA via the REGISTER 
method, which a client UA shouldn't be receiving


as 
it's not a registrar. Therefore, if the client PA/PUA doesn't have a way of 
getting the presence fragments from the other various


PUAs 
(at least not through SIP), should it be allowed to migrate the PA function away 
from the presence server? I know we could signal


across 
devices using some means other than SIP, but looking at this as a state agent 
handling state synchronization within an event


framework, shouldn't there be defined a method to use the same protocol 
for this job (SIP) as a baseline mechanism?


 


I 
noticed in the documentation under the migration and forking sections text that 
said that it was best for a network PA to do aggregation,


and I 
agree with that. How do we ensure that the aggregation is handled correctly when 
the PA is no longer in the network?


 


Another question that I have regards what is really saved by migrating to 
a client device? We still have to keep the presence server in the 
route


in 
order to detect migration back to the presence server from the client PA/PUA. 
The notifications still have to travel through the presence 
server


because they must follow the same route as was established in the 
SUBSCRIBE. So it seems that all we're saving is the aggregation piece, 
which


seems 
relatively simple to do from a centralized server.


 


The 
reason I bring the last bit up is because one way I was thinking the PUA 
information could be dealt with is by making the presence server 
a


reflector of the information fed in by PUAs in registrations by way of 
having the PA/PUA subscribe to itself at the presence server (which 
would


always 
be allowed, and this portion of the PA would not migrate). That way the 
registrations cause a NOTIFY to be sent back to the migrated PA 
to


keep 
it in sync.


 


Does 
this make any sense, or am I seriously off in the weeds 
somewhere?


 


Thanks 
all,


 


Brian


------_=_NextPart_001_01C1485E.C27381C0--

From zhigang.c.liu@nokia.com  Fri Sep 28 19:56:48 2001
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 TAA22053
	for ; Fri, 28 Sep 2001 19:56:47 -0400 (EDT)
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 f8SNv0306712
	for ; Sat, 29 Sep 2001 02:57:00 +0300 (EET DST)
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 f8SNuR310016
	for ; Fri, 28 Sep 2001 18:56:27 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 28 Sep 2001 18:56:26 -0500
Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 28 Sep 2001 18:56:26 -0500
content-class: urn:content-classes:message
Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP
Date: Fri, 28 Sep 2001 18:56:33 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [rohc] RE: [Simple] MESSAGE sessions - over TCP
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFIAZx06t9F2rPXEdWQZAAAhl1B4gAcE7Sw
From: "Liu Zhigang.C (NRC/Dallas)" 
To: , "'ext Lawrence Conroy'" ,
        "Isomaki Markus (NRC/Helsinki)" ,
        , 
X-OriginalArrivalTime: 28 Sep 2001 23:56:26.0129 (UTC) FILETIME=[2F15E010:01C14879]
Content-Length: 929
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id TAA22053
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: 

> Whether to apply compression or not should be 
> decided by the application e.g. SIP. SigComp is just the tool 
> that the application will use for compression. 

Of course. That is what I meant by "user" and "service 
provider" (and the line between them) in my email.


> Basically, there are two issues:
> 1) Whether compression is to be applied or not,
> 2) How to negotiate the SigComp parameters (If any needs to 
> be negotiated). What we should do is to first define what 
> parameters that we see a need to negotiate. Then we could 
> start thinking of how to do the negotiation. And also if the 
> parameters need to be negotiated or if they can be signaled 
> "in band". 

Agree. While 1) is the agreement between the two users (e.g.
two SIP modules), 2) should be negotiated in a user independent
way between the peer SigComp modules which know the dirty
details. And of course, 2) is triggered by 1).

BR,
Zhigang

From roberbr@microsoft.com  Sat Sep 29 21:12:19 2001
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26564
	for ; Sat, 29 Sep 2001 21:12:15 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Sat, 29 Sep 2001 18:11:58 -0700
Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 29 Sep 2001 18:11:58 -0700
Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Sat, 29 Sep 2001 18:11:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: [Simple] Migration and client PA as a definitive authority.
Date: Sat, 29 Sep 2001 18:11:57 -0700
Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C3418@red-msg-05.redmond.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Migration and client PA as a definitive authority.
Thread-Index: AcFIX8b48U4NUy/ZS2SOW6f+LDZ58wA6wHEQ
From: "Robert Brown" 
To: "Brian Stucker" ,
        "simple" 
X-OriginalArrivalTime: 30 Sep 2001 01:11:57.0715 (UTC) FILETIME=[E688C630:01C1494C]
Content-Length: 16831
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: 

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1494C.E66CA54F"

------_=_NextPart_001_01C1494C.E66CA54F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hey, if you're off in the weeds, I think I'm somewhere nearby :-)

=20

Actually, I think REGISTER is only meant to be an example of one way an
implementer might want to publish presence to the PA.  You've hit on one
of the examples of why this isn't a great idea (and I agree).  A few
other reasons I don't like using REGISTER to publish presence: 1)
REGISTER is something you'll want to send pretty frequently unless you
have a very stable and static network, but you only need to send new
presence status when you actually have some new state; 2) there are only
so many ways you can overload REGISTER and complicate its semantics -
it's better IMHO just to invent a different method or do something out
of band; or do something tricky like have the PA subscribe to the PUA;
3) why should I be registered in order to publish presence?

=20

IMHO subscribing to your own URI is an excellent way to keep track of
what your PA is telling people and keeping in synch.  We've done it for
non-SIP implementations and it works like a charm.

=20

Anyway, that's just my $0.02.

=20

- Rob

=20

=20

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]=20
Sent: Friday, September 28, 2001 1:47 PM
To: simple
Subject: [Simple] Migration and client PA as a definitive authority.

=20

Question about presence migration. Still looking at it, and the new 03
draft clears a lot of questions up, but one still remains for me...

=20

How do we go about ensuring that a PUA that signals that it wishes to
become the PA for the presentity, by migrating the PA away

from the presence server, is the definitive source of the aggregated
presence information?

=20

As I understand it, the PUAs feed presence fragments to the PA via the
REGISTER method, which a client UA shouldn't be receiving

as it's not a registrar. Therefore, if the client PA/PUA doesn't have a
way of getting the presence fragments from the other various

PUAs (at least not through SIP), should it be allowed to migrate the PA
function away from the presence server? I know we could signal

across devices using some means other than SIP, but looking at this as a
state agent handling state synchronization within an event

framework, shouldn't there be defined a method to use the same protocol
for this job (SIP) as a baseline mechanism?

=20

I noticed in the documentation under the migration and forking sections
text that said that it was best for a network PA to do aggregation,

and I agree with that. How do we ensure that the aggregation is handled
correctly when the PA is no longer in the network?

=20

Another question that I have regards what is really saved by migrating
to a client device? We still have to keep the presence server in the
route

in order to detect migration back to the presence server from the client
PA/PUA. The notifications still have to travel through the presence
server

because they must follow the same route as was established in the
SUBSCRIBE. So it seems that all we're saving is the aggregation piece,
which

seems relatively simple to do from a centralized server.

=20

The reason I bring the last bit up is because one way I was thinking the
PUA information could be dealt with is by making the presence server a

reflector of the information fed in by PUAs in registrations by way of
having the PA/PUA subscribe to itself at the presence server (which
would

always be allowed, and this portion of the PA would not migrate). That
way the registrations cause a NOTIFY to be sent back to the migrated PA
to

keep it in sync.

=20

Does this make any sense, or am I seriously off in the weeds somewhere?

=20

Thanks all,

=20

Brian


------_=_NextPart_001_01C1494C.E66CA54F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







RE: [Simple] MESSAGE sessions - over TCP











Hey, if you’re off in the =
weeds, I
think I’m somewhere nearby :-)



 



Actually, I think REGISTER is only =
meant
to be an example of one way an implementer might want to publish =
presence to
the PA.  You’ve hit on one of the examples of why this =
isn’t a
great idea (and I agree).  A few other reasons I don’t like =
using
REGISTER to publish presence: 1) REGISTER is something you’ll want =
to
send pretty frequently unless you have a very stable and static network, =
but
you only need to send new presence status when you actually have some =
new state;
2) there are only so many ways you can overload REGISTER and complicate =
its
semantics – it’s better IMHO just to invent a different =
method or
do something out of band; or do something tricky like have the PA =
subscribe to
the PUA; 3) why should I be registered in order to publish =
presence?



 



IMHO subscribing to your own URI is =
an
excellent way to keep track of what your PA is telling people and =
keeping in
synch.  We’ve done it for non-SIP implementations and it =
works like
a charm.



 



Anyway, that’s just my =
$0.02.



 



- Rob



 



 



-----Original =
Message-----

From: Brian Stucker
[mailto:bstucker@nortelnetworks.com] 

Sent: Friday,
 September 28, 2001 1:47 PM

To: simple

Subject: [Simple] =
Migration and
client PA as a definitive authority.



 






Question about
presence migration. Still looking at it, and the new 03 draft =
clears a lot
of questions up, but one still remains for me...









 









How do we go =
about
ensuring that a PUA that signals that it wishes to become the PA for the
presentity, by migrating the PA away









from the =
presence server,
is the definitive source of the aggregated presence =
information?









 









As I understand =
it, the
PUAs feed presence fragments to the PA via the REGISTER method, which a =
client
UA shouldn't be receiving









as it's not a =
registrar.
Therefore, if the client PA/PUA doesn't have a way of getting the =
presence
fragments from the other various









PUAs (at least =
not
through SIP), should it be allowed to migrate the PA function away from =
the
presence server? I know we could signal









across devices =
using some
means other than SIP, but looking at this as a state agent handling =
state
synchronization within an event









framework, =
shouldn't
there be defined a method to use the same protocol for this job (SIP) as =
a
baseline mechanism?









 









I noticed in the
documentation under the migration and forking sections text that said =
that it
was best for a network PA to do aggregation,









and I agree with =
that.
How do we ensure that the aggregation is handled correctly when the PA =
is no
longer in the network?









 









Another question =
that I
have regards what is really saved by migrating to a client device? We =
still
have to keep the presence server in the route









in order to =
detect
migration back to the presence server from the client PA/PUA. The =
notifications
still have to travel through the presence server









because they =
must follow
the same route as was established in the SUBSCRIBE. So it seems that all =
we're
saving is the aggregation piece, which









seems relatively =
simple
to do from a centralized server.









 









The reason I =
bring the
last bit up is because one way I was thinking the PUA information could =
be
dealt with is by making the presence server a









reflector of the
information fed in by PUAs in registrations by way of having the PA/PUA
subscribe to itself at the presence server (which =
would









always be =
allowed, and
this portion of the PA would not migrate). That way the registrations =
cause a
NOTIFY to be sent back to the migrated PA to









keep it in =
sync.









 









Does this make =
any sense,
or am I seriously off in the weeds somewhere?









 









Thanks =
all,









 









Brian











=00
------_=_NextPart_001_01C1494C.E66CA54F--

--------------InterScan_NT_MIME_Boundary--


From Dror@vocaltec.com  Mon Oct  1 07:34:27 2001
Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11182
	for ; Mon, 1 Oct 2001 07:34:25 -0400 (EDT)
From: Dror@vocaltec.com
Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135])
	by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id NAA12498;
	Mon, 1 Oct 2001 13:29:33 +0200 (IST)
To: Jonathan Rosenberg 
Cc: "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] MESSAGE sessions - over TCP
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: 
Date: Mon, 1 Oct 2001 13:26:39 +0200
X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 10/01/2001 01:26:44 PM,
	Serialize complete at 10/01/2001 01:26:44 PM
Content-Type: multipart/alternative; boundary="=_alternative 003EEC7D42256AD8_="
Content-Length: 6917
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: 

This is a multipart message in MIME format.
--=_alternative 003EEC7D42256AD8_=
Content-Type: text/plain; charset="us-ascii"

I think message chats should be wrapped by an INVITE/BYE, as a chat 
session is indeed a session.
However, unlike other media types, a chat starts with a single message, 
and it seems to me a burden (for the SIP network) to require that a single 
message be sent using an INVITE wrapper.
The actual session will be initiated by the callee of this initial message 
(so he can send the reply within the session)The only protocol change 
required is a way to associate the original message (which was sent before 
the SIP session was created) with that session.






Jonathan Rosenberg 
26/09/2001 22:30

 
        To:     "'Petri K. Koskelainen'" , Dror@vocaltec.com
        cc:     simple@mailman.dynamicsoft.com
        Subject:        RE: [Simple] MESSAGE sessions - over TCP






> -----Original Message-----
> From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> Sent: Wednesday, September 26, 2001 1:21 PM
> To: Dror@vocaltec.com
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] MESSAGE sessions - over TCP
>
> Is there a consensus that INVITE-established IM messaging
> session idea is ok ? (in addition to one shot MESSAGEs)
>
>
> If we can agree on that, then we can continue with other
> problems, like:
> - messaging protocol/format inside a session (e.g. SIP
> MESSAGE over TCP)
> - direct end-to-end vs. via signaling proxies vs. via IM servers
> - compression (hopefully this does not have to be discussed here)
>
> There should be a resolution on this asap.

Yes, part of the reason we are circling around is that we have not been 
able
to break the problem into pieces. Clearly the first is the question Petri
has asked - can we agree that a session model for messaging (session model
being to wrap it in INVITE/BYE, and the messages are viewed as a media
stream.) THis says nothing about how they are transported, and wouldn't 
rule
out sending them over the signaling channel.

I strongly support this need for a session model. I think most have
expressed support for it, with a few notable exceptions (Dean, I think).

I think its time for the chairs to make a ruling on consensus on whether 
to
pursue a session model as defined above.

We would still retain the paging model of course,

-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



--=_alternative 003EEC7D42256AD8_=
Content-Type: text/html; charset="us-ascii"



I think message chats should be wrapped by an INVITE/BYE, as a chat session is indeed a session.

However, unlike other media types, a chat starts with a single message, and it seems to me a burden (for the SIP network) to require that a single message be sent using an INVITE wrapper.

The actual session will be initiated by the callee of this initial message (so he can send the reply within the session)The only protocol change required is a way to associate the original message (which was sent before the SIP session was created) with that session.















Jonathan Rosenberg <jdrosen@dynamicsoft.com>

26/09/2001 22:30



        

        To:        "'Petri K. Koskelainen'" <petkos@cs.columbia.edu>, Dror@vocaltec.com

        cc:        simple@mailman.dynamicsoft.com

        Subject:        RE: [Simple] MESSAGE sessions - over TCP














> -----Original Message-----

> From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]

> Sent: Wednesday, September 26, 2001 1:21 PM

> To: Dror@vocaltec.com

> Cc: simple@mailman.dynamicsoft.com

> Subject: Re: [Simple] MESSAGE sessions - over TCP

>

> Is there a consensus that INVITE-established IM messaging

> session idea is ok ? (in addition to one shot MESSAGEs)

>

>

> If we can agree on that, then we can continue with other

> problems, like:

> - messaging protocol/format inside a session (e.g. SIP

> MESSAGE over TCP)

> - direct end-to-end vs. via signaling proxies vs. via IM servers

> - compression (hopefully this does not have to be discussed here)

>

> There should be a resolution on this asap.



Yes, part of the reason we are circling around is that we have not been able

to break the problem into pieces. Clearly the first is the question Petri

has asked - can we agree that a session model for messaging (session model

being to wrap it in INVITE/BYE, and the messages are viewed as a media

stream.) THis says nothing about how they are transported, and wouldn't rule

out sending them over the signaling channel.



I strongly support this need for a session model. I think most have

expressed support for it, with a few notable exceptions (Dean, I think).



I think its time for the chairs to make a ruling on consensus on whether to

pursue a session model as defined above.



We would still retain the paging model of course,



-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






--=_alternative 003EEC7D42256AD8_=--

From pkyzivat@cisco.com  Mon Oct  1 09:19:01 2001
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 JAA11543
	for ; Mon, 1 Oct 2001 09:19:00 -0400 (EDT)
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 f91DIAA19077;
	Mon, 1 Oct 2001 09:18:14 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB15812 (AUTH pkyzivat);
	Mon, 1 Oct 2001 09:20:07 -0400 (EDT)
Message-ID: <3BB86CD8.F1BFB837@cisco.com>
Date: Mon, 01 Oct 2001 09:17:12 -0400
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: Dror@vocaltec.com
CC: Jonathan Rosenberg ,
        "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] MESSAGE sessions - over TCP
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1280
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: 


Dror@vocaltec.com wrote:
> 
> I think message chats should be wrapped by an INVITE/BYE, as a chat
> session is indeed a session.
> However, unlike other media types, a chat starts with a single
                                            ^^^^^^
                                            may start

> message, and it seems to me a burden (for the SIP network) to require
> that a single message be sent using an INVITE wrapper.
> The actual session will be initiated by the callee of this initial
> message (so he can send the reply within the session)The only protocol
> change required is a way to associate the original message (which was
> sent before the SIP session was created) with that session.

What you suggest is one usage model, where the sender of the first
message doesn't anticipate a conversation, but the recipient decides a
session is required. But it certainly isn't the only usage model - it
quite possible that the need for a session is anticipated from the
beginning.

Certainly both of these scenarios can be supported. Yours is simply a
combination of paging mode usage plus session mode usage. It does get a
bit complicated if you wish to tie the session to the initial page, but
I don't know if that is really required.

	Paul Kyzivat
	Cisco Systems

From jon.peterson@NeuStar.com  Mon Oct  1 15:07:55 2001
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12673
	for ; Mon, 1 Oct 2001 15:07:51 -0400 (EDT)
Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f91J77q17572
	for ; Mon, 1 Oct 2001 15:07:22 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 1 Oct 2001 14:05:38 -0500
Message-ID: <70565611B164D511957A001083FCDD56478B31@va02.va.neustar.com>
From: "Peterson, Jon" 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Mon, 1 Oct 2001 14:05:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 413
Subject: [Simple] Consensus on INVITE-established IM
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: 

It sounds like pretty much no one out there is vehemently opposed to the
concept of INVITE-established IM sessions (independent of what, exactly, the
transport for these IM will be), and that a rough consensus supports this
protocol concept. If there is in fact any new argument to be made for
excluding this concept, this would be a good time for someone to raise it.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

From Gur_Kimchi@vocaltec.com  Mon Oct  1 15:32:32 2001
Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12793
	for ; Mon, 1 Oct 2001 15:32:32 -0400 (EDT)
From: Gur_Kimchi@vocaltec.com
Subject: Re: [Simple] Consensus on INVITE-established IM
To: "Peterson, Jon" ,
        "'simple@mailman.dynamicsoft.com'" 
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: 
Date: Mon, 1 Oct 2001 15:24:21 -0500
X-MIMETrack: Serialize by Router on USNIMO/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 10/01/2001 03:24:24 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 2055
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: 

go with INVITE-established IM sessions - as long as there is a way to
associate a one-time MESSAGE
with a later session of MESSAGEs.

Gur Kimchi
VocalTec Communications



                                                                                                                      
                    "Peterson, Jon"                                                                                   
                            To:     "'simple@mailman.dynamicsoft.com'"                      
                    Sent by:                                                          
                    simple-admin@mailman.dynam        cc:                                                             
                    icsoft.com                        Subject:     [Simple] Consensus on INVITE-established IM        
                                                                                                                      
                                                                                                                      
                    10/01/2001 02:05 PM                                                                               
                                                                                                                      
                                                                                                                      




It sounds like pretty much no one out there is vehemently opposed to the
concept of INVITE-established IM sessions (independent of what, exactly,
the
transport for these IM will be), and that a rough consensus supports this
protocol concept. If there is in fact any new argument to be made for
excluding this concept, this would be a good time for someone to raise it.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple





From jdrosen@dynamicsoft.com  Mon Oct  1 17:28:45 2001
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 RAA13189
	for ; Mon, 1 Oct 2001 17:28:45 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f91LQi8P027888;
	Mon, 1 Oct 2001 17:26:45 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SMYTZ>; Mon, 1 Oct 2001 17:27:47 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Liu Zhigang.C (NRC/Dallas)'" ,
        Hans.Hannu@epl.ericsson.se, "'ext Lawrence Conroy'" ,
        "Isomaki Markus (NRC/Helsinki)" ,
        simple@mailman.dynamicsoft.com, rohc@cdt.luth.se
Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP
Date: Mon, 1 Oct 2001 17:27:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2285
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: 


 

> -----Original Message-----
> From: Liu Zhigang.C (NRC/Dallas) [mailto:zhigang.c.liu@nokia.com]
> Sent: Thursday, September 27, 2001 4:21 PM
> To: Hans.Hannu@epl.ericsson.se; 'ext Lawrence Conroy'; Isomaki Markus
> (NRC/Helsinki); simple@mailman.dynamicsoft.com; rohc@cdt.luth.se
> Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP
> 
> > However, there might be a need to negotiate other parameters, 
> > e.g. The usage of a Codebook/Byte-buffer, buffer memory etc., 
> > But, we have to think of the complexity issue with too many 
> > parameters to set/negotiate, and also if SigComp itself 
> > should do this kind of negotiation or if some other protocol 
> > should do this, e.g. according to 
> > http://search.ietf.org/internet-drafts/draft-spbs-sip-negotiat
> > e-00.txt . My belief is that SigComp should not have its own 
> > negotiation procedure.
> 
> Sorry, I haven't had time to read through the sip-negotiate draft. 
> I agree with you that we should keep the number of parameters to 
> minimal. However, I feel that the parameters you just mentioned
> are closer to SigComp than to SIP. They are really tied to the
> algorithms/procedures of SigComp. In my view, the negotiation 
> should be either defined with SigComp in one document or in 
> a separate document (brother/sister of SigComp). But in either 
> case, we should draw a line between SIP (the "user" of SigComp) 
> and SigComp (the service provider). The interface between
> the two is the negotiation protocol. 

I agree. Most of the parameters that need to be negotiated are SigComp and
belong in that protocol. The only thing SIP needs to "negotiate" is whether
this is used at all. That is easily done using SRV, or more generally, using
the whole set of SIP techniques for determining what transport protocol to
use (its quite like negotiating TLS usage, which is a shim ontop of TCP.
Sigcomp is a shim ontop of UDP).

-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

From jdrosen@dynamicsoft.com  Tue Oct  2 01:54:09 2001
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 BAA14680
	for ; Tue, 2 Oct 2001 01:54:09 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f925qt8P029461;
	Tue, 2 Oct 2001 01:52:55 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SMZ2V>; Tue, 2 Oct 2001 01:53:59 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Sean Olson ,
        Robert Sparks
	 ,
        "'simple@mailman.dynamicsoft.com'"
	 
Subject: RE: [Simple] Final day - WG LAST CALL : draft-ietf-simple-presenc
	 e-02
Date: Tue, 2 Oct 2001 01:53:58 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3711
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: 


  
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, September 21, 2001 4:36 PM
To: 'Robert Sparks'; 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Final day - WG LAST CALL : draft-ietf-simple-presenc
e-02


>Hello, 
>Here are some minor comments. Hope they are 
>not too late. 

Well, I was hoping that -03 would be OK, but I won't refuse comments
received after the end of the official last call.


>1) Section 3, second paragraph, second sentence 
>   ",using either a SIP URL." should become 
>   ",using either a SIP URL or a presence URL [4]". 

Right, thanks. Section 4 has it correct, but it needs to be consistent.

>2) Section 5.6, second to last paragraph 
>   I think it would be useful to move the text 
>   about generation of subscription refreshes 
>   from Section 5.10 to here. The text I am 
>   referring to is: 
>   "Furthermore, when refreshing the subscription, 
>    the refresh SHOULD make use of the tags from 
>    the 202 and make use of any Contact: or 
>    Record-Route: headers in order to deliver the 
>    SUBSCRIBE back to the same PA that sent the 202" 
>    This text makes sense not only for the forking case 
>    but also for the case where pres: URLs are used. 
>    That is, I believe that if the first SUBSCRIBE request 
>    contained a pres: URL in the Request-URI, subsequent 
>    refreshes of that SUBSCRIBE should take advantage of 
>    the SIP URL present in the Contact: of the 202 response 
>    to avoid that lookup again (particularly when the 
>    client generating the SUBSCRIBE cannot directly handle 
>    the pres: URL lookup) 

Good point. I will move this text to 5.6.


>3) Section 5.7 
>    Regarding the use of the Remote-Party-ID header in a 
>    SUBSCRIBE, do you intend to allow pres: URLs as well 
>    or only SIP URLs? (very small point) 

Sure; the text doesn't seem to imply otherwise. I see no need for any
additional text to state this explicitly.

>4) Section 5.12, description of three phases of migration 
>   It seems that there is a fourth (optional) phase 
>   missing before the current PA sends NOTIFYs with a 
>   Subscription-Expires: of 0 to force the current 
>   subscribers to migrate. This phase would push the 
>   current presence information from the current PA 
>   to the new target PA using the same potential 
>   mechanisms described in Section 6.3 
>   The reason for doing so is to allow the new PA client 
>   to act on behalf of other non-PA UserAgent:s for this 
>   presentity. 

THe assumption is that any entity that is a PA for a particular presentity
knows the full presence state for that presentity. How the PA knows this, is
outside the scope of the spec. One way is for someone who does know, to push
it to the PA. However, that is really orthogonal to the issue of migration.
As such, I don't really see that as a separate phase of migration.

>5) Section 8 
>   You might want to add a "Content-Length: 0" to 
>   appropriate messages. 

OK.

>   You may also want to show an example Notifier 
>   migration triggered by a REGISTER request 
>   with ";methods="SUBSCRIBE,MESSAGE". This would 
>  show the use of the Subscription-Expires header. 

The examples section is already really long; I don't think we need to show
all cases, so I'd rather not add more at this point.

-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

From jdrosen@dynamicsoft.com  Tue Oct  2 02:16:24 2001
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 CAA14770
	for ; Tue, 2 Oct 2001 02:16:24 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f926F58P029579;
	Tue, 2 Oct 2001 02:15:05 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SMZJZ>; Tue, 2 Oct 2001 02:16:09 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brian Stucker'" ,
        Jonathan Rosenberg
	 ,
        Jonathan Rosenberg ,
        "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Questions on the current presence draft.
Date: Tue, 2 Oct 2001 02:16:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 10981
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: 


  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Monday, September 24, 2001 5:33 PM
To: Jonathan Rosenberg; Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Questions on the current presence draft.



>I'm just trying to protect from implementations that don't try to actively
keep their 
>subscription state synced. Just seems like relying solely on the PA to help
watchers 
>coordinate their state, without some degree of fetching by the watcher
could cause things 
>to get out of sync in some easy error scenarios.

Subscriptions are soft state, so they should always eventually re-sync.

> The flood bit was about the watcher 
>trying to refresh their subscriptions, and getting 481's back (possibly) a
couple of times 
>before the subscription refreshes correctly. 

Why would it be a couple of times? After the first 481 on a routed/tagged
subscription, it should retry without the Route and tags right away. 

> Since it'd be a self-induced flood, well, I 
>guess that's the problem that the watcher has to deal with, however, I'm
trying to think 
>of ways of protecting the network in this case from using this as an attack
of some sort.

I still don't get it. What flood? Are you worried about the case where the
PA sends a bunch of NOTIFY with Subscription-Expires, causing all the
watchers to resubscribe at the same time? This can be fixed as a local
implementation decision by gradually migrating subscriptions rather than all
at the same time. I'll mention that, but I'm not sure thats what you're
talking about.

>If the watcher gets a 481 back from the presence server because a presence
agent has 
>migrated, how is it to tell that this was because it missed the
subscription expiration, 
>rather than it simply making a bad request on the presence server?

For SUBSCRIBE, 481 should always mean "try again without your tags/Routes
since this doesn't exist where you thought it should". In the case of a PA
that hasn't migrated, but has forgotten its subscription state because it
expired, the refresh shouldn't really generate a 481. Rather, the SUBSCRIBE
should re-establish the subscription state - thats the definition of
soft-state. In this case, the response is a 2xx. The PA would only send a
481 if its not able to reconstruct the subscription state. In that case, the
client does the right thing - tries again without the tags/Routes to rebuild
it from ground zero.

Now, all of this is definitely not clear in sip-events, which is where it
all belongs. I have several emails into Adam to get these things clarified.


-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, September 19, 2001 10:09 AM 
To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com' 
Subject: RE: [Simple] Questions on the current presence draft. 


>Thanks for the clairification. 
>I'd like to make the problem of the watcher not getting a notification that

their 
>subscription has expired (due to a migration) because of a temporary 
failure at the 
>watcher, 
>or in the network, go away without a huge hassle if that is possible. 
Thats generally a good design goal ;) 
>The scenario I'm thinking of would cause problems if the watcher simply 
decided to go 
>offline 
>when the migration occurred. No network failure needed, they just had their

machine turned 
>off 
>during that time. The problem that I see is that you're right, and you'd 
wind up likely 
>creating 
>a flood of network traffic at some point to recover from this. 
Why is it a flood? When the watcher comes back, they refresh their 
subscriptions. This is just a set of refreshes from one watcher. 
>Maybe a note in there somewhere that when a watcher has been SIP 
unreachable (powered down, 
>client 
>software not running, etc.), they need to fetch their subscriptions again 
(at a reasonable 
>rate) 
>in case a migration has occurred? 
The problem is easy when the watcher knows they have been unreachable. I'm 
not sure anything needs to be said here, as this is not really any different

from basic subscribe. The spec doesn't dictate a system, so I can't rightly 
tell people when they have to send SUBSCRIBE; thats the job of the RFP, not 
the RFC. 
When a host is SIP unreachable, but doesn't know it, this is quite a hard 
problem that affects things far broader than presence, or sip-events even 
(what if I miss the BYE, for example, of an ongoing call?). So, I'd rather 
not try to address that in this document. 


Thanks, 
Brian 


--- 
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: Tuesday, September 18, 2001 6:28 AM 
To: Stucker, Brian [NGB:B651:EXCH]; 'simple@mailman.dynamicsoft.com' 
Subject: RE: [Simple] Questions on the current presence draft. 




  
-----Original Message----- 
From: Brian Stucker [mailto:bstucker@nortelnetworks.com] 
Sent: Tuesday, September 11, 2001 3:30 PM 
To: 'simple@mailman.dynamicsoft.com' 
Subject: [Simple] Questions on the current presence draft. 


>I was reading through the current draft, and noticed a few things that I 
>was looking for clairification on. 
>In the section on presence migration, the last sentence of the description 
>for the second phase of presence migration states: "...This informs the 
subscribers that 
>their 
>subscription was destroyed, and should be re-established with a new 
SUBSCRIBE (with a new 
>Call-ID)." 
>I was wondering, if a watcher was offline when the NOTIFY containing the 
"Subscription- 
>Expires" header 
>to destroy the current subscription, what are the implications with the 
call id? I would 
>imagine when the 
>watcher comes back online, and tries to refresh the subscription, it would 
use the old 
>call-id (since it doesn't 
>know that it needs to reselect), which gets proxied to the new PA (after 
the migration 
>occurred). This seems like a gap to me. 
There are two cases here. In case 1, when the subscriber goes "offline", all

subscriptions state is lost. This would happen when a PC application is 
terminated, for example. In that case, when the watcher comes back, it will 
have no record of previous subscription state. So, it creates a new 
subscription with a brand new call ID. No problems. 
In case 2, the subscriber goes "offline" in the sense that its network 
connectivity is lost, so it won't get the NOTIFY, but it still retains 
subscription state. THis would be the case, for example, with a mobile phone

that goes out of range. When the mobile comes back in range, it will 
re-subscribe with the old call-id/route-set, in order to obtain the latest 
data it may have missed while out of range. Since this subscribe has a route

set, the request will arrive at the presence server (the one that formerly 
owned the subscriptions, but has since migrated them) with the URL of the 
presence server in the request URI (like sip:presence-server-1.foo.com). 
Since the URL points to itself, the presence server knows that it should 
process it. Since no subscriptions exist, this request would be rejected 
with a 481. Should it be proxied anyway to the PUA now handling the 
subscription, it would probably also be rejected with a 481 because the tags

don't match those of any existing subscriptions at the PUA. 
The 481 would trigger the subscriber to retry the subscription with a fresh 
call-id and no route set. 
The specifications are not clear at the moment about the handling of the 
case when you get a subscribe with a tag in the To field that doesn't match 
an existing subscription. That needs to be clarified in the events framework

spec. I'll send a note to Adam about it. 
> 
>Also, what happens if the watchers (previous to the migration) never 
receive the NOTIFY to 
>update their 
>subscriptions to cause a refresh. Unless they do a fetch, the new PA 
doesn't know that 
>they exist, so their 
>subscriptions will be effectively moot, but they won't be aware of this 
fact. They won't 
>get any notifications, and 
>won't know that their subscriptions are being ignored. 
I think this is the same problem I discussed above. The question you need to

ask is why the watcher would not have gotten the NOTIFY. Assuming the 
watcher application is running the whole time, the only reason this would 
occur is a network failure of some sort, or a failure of the presence server

itself. Network failures that occur because the mobile has gone out of range

are generally detectable, and so the mobile can do something about it. 
Network failures in the middle of the network which occur for long enough to

prevent a notification from being delivered (in excess of 16s) are hard to 
deal with in any protocol. A "nice" presence agent could retain the 
subscription state unless it gets a positive response to the NOTIFY, but 
that can be used as a DoS attack. So, I don't know how solve this particular

failure case. There will be a gap in the delivery of notifications for the 
duration of a refresh period. Given the scope of the failure that must occur

for that to happen, I think thats acceptable. 
Failures of the presence server itself can be handled using traditional 
mechanisms, such as replication of subscription state to a hot standby. 


> 
>In section 8, there are mixed uses of the presence URL and SIP URL's. Is 
this done 
>intentionally? 
No. My error. I've changed them all to sip URLs. Thanks. 
> 
>Finally, can someone point a link to the draft listed as [4] in the 
bibliography? It 
>doesn't seem to be available 
>at the IETF webpage. 
It just recently expired. The impp chairs have been pinging the editor to 
resubmit an update. 
Until then, you can get a copy from google's cached version of the draft: 
http://www.google.com/search?q=cache:jdFIIPRBPY0:www.ietf.org/internet-draft

s/draft-ietf-impp-cpim-01.txt+draft-ietf-impp-cpim&hl=en 
Thanks for your comments, 
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 

From jdrosen@dynamicsoft.com  Tue Oct  2 02:49:59 2001
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 CAA14890
	for ; Tue, 2 Oct 2001 02:49:59 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f926mi8P029705;
	Tue, 2 Oct 2001 02:48:44 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SMZLC>; Tue, 2 Oct 2001 02:49:49 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'James Undery'" 
Cc: SIMPLE 
Date: Tue, 2 Oct 2001 02:49:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1856
Subject: [Simple] RE: draft-ietf-simple-presence-03.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: 


 

> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Tuesday, September 25, 2001 6:32 AM
> To: Jonathan Rosenberg
> Cc: SIMPLE
> Subject: draft-ietf-simple-presence-03.txt
> 
> 
> Hi,
> 
> This is really late I know, and I failed to read the 02 draft at all.
> 
> Section 3. Once authenticated I'd expect a 202, once authorised I'd
> expect a 200. 

Yup. More legacy text from when we were mandated a 202 in all cases. I've
fixed.

> (I've also a nit about saying "subscription is carried
> as any other INVITE" I think "non-INVITE" is better, but I don't
> really care about that.)

Actually, "request" is the right term, and I updated to use that.

> 
> Section 5.7 The use of the word accepted to have a different meaning
> to "202 Accepted", is confusing, authorised is probably better.

Changed. I also clarified that all 2xx responses generate a NOTIFY, and that
this NOTIFY SHOULD be bogus for pending subscriptions.

> Also I
> believe polite blocking is best done with 202 I think 200 should show
> I am authorised (as per previous text in this section).

No, I disagree. The definition of polite blocking is that the subscriber
can't tell that they've been blocked, and it looks like its been okayed.
This would imply a 200.

> 
> Section 5.8 Should say "a NOTIFY MUST be sent after a 2xx response to
> the SUBSCRIBE has been sent." i.e. s/200/2xx/

Fixed.

> 
> Section 5.9 first paragraph only s/200/2xx/

Fixed.

Thanks for your comments.

-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

From jdrosen@dynamicsoft.com  Tue Oct  2 03:10:03 2001
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 DAA14978
	for ; Tue, 2 Oct 2001 03:10:03 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9278o8P029790;
	Tue, 2 Oct 2001 03:08:51 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SMZL5>; Tue, 2 Oct 2001 03:09:55 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Paul Kyzivat'" 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Updated presence spec
Date: Tue, 2 Oct 2001 03:09:52 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 2555
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: 


 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, September 25, 2001 5:36 PM
> To: Jonathan Rosenberg
> Cc: 'simple@mailman.dynamicsoft.com'
> Subject: Re: [Simple] Updated presence spec
> 
> 
> Jonathan,
> 
> In reviewing the new document, I noticed something 
> troublesome about the
> migration description:
> 
> It suggests that a PUA can indicate ability to act as a PA by 
> sending a
> REGISTER with a caller preferences "methods" parameter listing
> SUBSCRIBE, and goes on to say that a PUA MUST NOT do this unless it
> knows definitively that it has complete presence information 
> for a user.
> The problem with this is that the PUA may also be a UA for 
> reasons other
> than presence, and may need to support SUBSCRIBE for event packages
> other than presence. Then it is stuck - it is forced to implement PUA
> functionality as a precondition to advertising support for the other
> event package.

This is an excellent observation.

Fortunately, its not required to implement PUA functionality for all
packages. If it should end up getting a request for a package it doesn't
support, it simply generates a 489. This would be a problem if the text
about not forking were still in there; but its not. A proxy will fork the
SUBSCRIBE to all registered contacts that support it, and so long as one PUA
supports the event package thats been requested, things work fine. In a
world where there are lots of packages, this could cause more useless
traffic to the PUA than you might otherwise want. I'll note this in the
spec.

The right way to fix this, ultimately, is to use caller preferences some
more. Caller preferences is extensible, so that one can define new
attributes. You would simply define "events" as another attribute, which
indicates the set of events it supports. A proxy server could then use this
to route requests with specific Event headers to those contacts which have
explicitly supported it. That would eliminate all unecessary overheads.

However, I suspect this is a problem in theory only for the time being, and
we can fix it with the caller prefs parameters when the time comes where it
is a real problem.

-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

From jdrosen@dynamicsoft.com  Tue Oct  2 03:18:27 2001
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 DAA15042
	for ; Tue, 2 Oct 2001 03:18:27 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f927HE8P029865;
	Tue, 2 Oct 2001 03:17:14 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SMZM2>; Tue, 2 Oct 2001 03:18:19 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Markus.Isomaki@nokia.com'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Different verbosity levels of presence information
Date: Tue, 2 Oct 2001 03:18:16 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3375
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: 


 

> -----Original Message-----
> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> Sent: Wednesday, September 26, 2001 10:11 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Different verbosity levels of presence information
> 
> 
> Hi,
> 
> I have a couple of basic questions about the subscription of presence
> information. 
> 
> What I think would be required is that a watcher is able to 
> subscribe to
> different "verbosity levels" of presence information of a 
> given presentity.
> If the presence document is large having a lot of attributes 
> and changing
> often, it might be an overkill in wireless and small handset 
> environment.
> That's why it would be nice to be able to subscribe either to 
> the full or
> partial presence state of a presentity.

Full state/partial state is one thing, used just for the purposes of message
efficiency. Another issue is subscription to a subset of the state of the
presentity. For example, if a presentity has eight contact addresses, I
might like to receive notifications only when there are changes in the IM
contact, and only receive information about that contact (whether its
through full state or partial updates). This would reduce the size of the
NOTIFYs, and also their frequency.

The ability to restrict subscriptions in the second manner is described in
the presence spec as "filters". There are documents carried in the bodies of
subscribe. There are no defined filters at this time, and its still a
somewhat vague concept. When we get to the point where presence docs really
do contain a lot of stuff, we can figure out exactly what the requirements
are and begin defining them. All the presence spec needs to do is leave a
place holder for them, which it does.


> 
> Can this be done by doing different SIP event packages with 
> different levels
> of presence information associated with them or is there some
> architecturally better way? The watcher would then decide 
> which one of them
> to subscribe.

It would be done with filters, as I mention above.

> 
> Another question is about subscription to a list of 
> presentities (buddy list
> etc.). I guess there is no sound way of doing that in a 
> single SIP subscribe
> transaction, so again some kind of sub-package would be 
> needed? But even in
> that case how is the list of URIs delivered? Is this outside 
> the scope of
> SIP? Again the problem raises from the desire to protect the limited
> bandwith available over the air.

I would envision this working much like a regular sip invitation to a URL
that happens to be a group. The identities of the group participants would
be established out of band, so that the request URI in the subscribe merely
identifies the group. Whether this is a sub-package, a new package, or even
just the regular presence package, remains to be discussed. I would tend to
think its a sub-package (group subscriptions make sense for all packages).
What the data format is for the NOTIFY is a good question...

-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

From lachlan.brazier@siemens.at  Tue Oct  2 05:45:55 2001
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 FAA15545
	for ; Tue, 2 Oct 2001 05:45:55 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f929jku01200
	for ; Tue, 2 Oct 2001 11:45:46 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id LAA06866
	for ; Tue, 2 Oct 2001 11:45:45 +0200 (MET DST)
Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta)
	id xma029861; Tue, 2 Oct 01 11:41:50 +0200
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id ; Tue, 2 Oct 2001 11:41:48 +0200
Message-ID: 
From: Brazier Lachlan 
To: "'SIMPLE Mailinglist'" 
Date: Tue, 2 Oct 2001 11:41:42 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1094
Subject: [Simple] Multiple 200 Ok
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: 

Hello,
I refer to "5.10 Handling of Forked Requests" in
"draft-ietf-simple-presence-03.txt".
.....
....Some of these may respond with a 2xx response to the SUBSCRIBE. Based on
the forking rules in SIP, only one of these
   responses is passed to the subscriber. ...
.....

As far as I remember, a proxy always passes a 2xx response upstream. Even if
a forking proxy cancels other branches on receiving a 2xx, the CANCEL can
still cross on the line with a 2xx response. A scenario would be, that one
branch returns a 202 response first, and then another branch returns a 200
Ok response.

So, if the proxy passes all 2xx message upstream, does the subscriber have
finally subscribed to more than one user? How can a subscriber realize, that
a forking proxy forked to a different user (this can happen when I am on
holiday, and I register my working collegue with my working SIP Url - and
then somebody wants to subscribe for me)?

Please excuse if I messed a discussion about this. If yes, could you please
point me there.

Thanks is advance

Lachlan Brazier

mailto:lachlan.brazier@siemens.at


From ndeason@ubiquity.net  Tue Oct  2 07:35:37 2001
Received: from drago1.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 HAA15899
	for ; Tue, 2 Oct 2001 07:35:35 -0400 (EDT)
Received: from mailhost.ubiquity.net by drago1.ubiquity.net
          via smtpd (for [63.113.40.50]) with SMTP; 2 Oct 2001 11:35:25 UT
Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 2 Oct 2001 12:35:41 +0100
From: "Neil Deason" 
To: "Brazier Lachlan" ,
        "'SIMPLE Mailinglist'" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Tue, 2 Oct 2001 12:35:41 +0100
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
Importance: Normal
In-Reply-To: 
X-OriginalArrivalTime: 02 Oct 2001 11:35:41.0858 (UTC) FILETIME=[5DE35020:01C14B36]
Content-Length: 1938
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: 

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Brazier
> Lachlan
> Sent: 02 October 2001 10:42
> To: 'SIMPLE Mailinglist'
> Subject: [Simple] Multiple 200 Ok
> 
> 
> Hello,
> I refer to "5.10 Handling of Forked Requests" in
> "draft-ietf-simple-presence-03.txt".
> .....
> ....Some of these may respond with a 2xx response to the 
> SUBSCRIBE. Based on
> the forking rules in SIP, only one of these
>    responses is passed to the subscriber. ...
> .....
> 
> As far as I remember, a proxy always passes a 2xx response 
> upstream. Even if
> a forking proxy cancels other branches on receiving a 2xx, 
> the CANCEL can
> still cross on the line with a 2xx response. A scenario would 
> be, that one
> branch returns a 202 response first, and then another branch 
> returns a 200
> Ok response.

For non-INVITEs a proxy must forward only a single response 
upstream, 2xx or otherwise. INVITEs are a special case
where all 2xxs must be forwarded. This is because of the
different reliability mechanisms at play. Non-INVITEs 
requests are retransmitted until a response is received.
Therefore only a single response can ever be transmitted
reliably. 2xxs for INVITEs have end to end reliability 
so all of them must be sent back so they can be ACK'd
by the UAC. See section 14 of bis for the full details.

Cheers,
Neil
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

> So, if the proxy passes all 2xx message upstream, does the 
> subscriber have
> finally subscribed to more than one user? How can a 
> subscriber realize, that
> a forking proxy forked to a different user (this can happen 
> when I am on
> holiday, and I register my working collegue with my working 
> SIP Url - and
> then somebody wants to subscribe for me)?
> 
> Please excuse if I messed a discussion about this. If yes, 
> could you please point me there.



From www@blanc.contact.net  Tue Oct  2 09:03:08 2001
Received: from blanc.contact.net (bleu.contact.net [209.41.145.2])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16180
	for ; Tue, 2 Oct 2001 09:03:08 -0400 (EDT)
Received: (from www@localhost)
	by blanc.contact.net (8.9.3/8.9.3) id JAA12977;
	Tue, 2 Oct 2001 09:02:33 -0400
Date: Tue, 2 Oct 2001 09:02:33 -0400
Message-Id: <200110021302.JAA12977@blanc.contact.net>
To: siavl@hotmail.com, sievans@lisp.com.au, silverwolf79@hotmail.com,
        silvrtaln7@yahoo.com, simeons@allaire.com, simonmungo@yahoo.com,
        simple@mailman.dynamicsoft.com, simsample@hotmail.com,
        sinccjersey@yahoo.com, sincla@walpow.com
From: rareasiannudes@xxxasia.com ()
Content-Length: 862
Subject: [Simple] do you like asian pussy?
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: 

Below is the result of your feedback form.  It was submitted by
 (rareasiannudes@xxxasia.com) on Tuesday, October 2, 2001 at 09:02:33
---------------------------------------------------------------------------

: please visit these following sites if you want access to THOUSANDS OF RARE PHOTOS and LIVE FEEDS most of these PHOTOS/MOVIES ARE BANNED IN ASIA! GET EM WHILE THEY'RE HOT!



(best viewed with IE. thanks)

WWW.JAPANBITCH.COM



WWW.ASIANHEARTS.COM



WWW.JAPANWHORE.COM



FREE ASIAN GALLERY



---------------------------------------------------------------------------


From pkyzivat@cisco.com  Tue Oct  2 09:35:28 2001
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 JAA16335
	for ; Tue, 2 Oct 2001 09:35:28 -0400 (EDT)
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 f92DYeA25143;
	Tue, 2 Oct 2001 09:34:41 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB23877 (AUTH pkyzivat);
	Tue, 2 Oct 2001 09:36:37 -0400 (EDT)
Message-ID: <3BB9C23A.307B5E67@cisco.com>
Date: Tue, 02 Oct 2001 09:33:46 -0400
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] Updated presence spec
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 4667
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: 

Jonathan,

You have satisfactorily answered my concerns, but the text doesn't
really reflect what you have said. How about something like the
following: 

 "The first of these phases can occur through configuration, or through
  dynamic means. One dynamic means for a presence server to discover
  that the function can migrate to a PUA through the REGISTER message.
                                        ^
                                        is
  Specifically, if a PUA wishes to indicate support for the PA
  function, it SHOULD include a contact address in its registration
  with a caller preferences "methods" parameter listing SUBSCRIBE [13].
  This indicates that it is capable of terminating and processing
  SUBSCRIBE, and therefore can act as a PA. A PUA MUST NOT do this
                           ^^^                             ^^^^^^^
                           may be able to                  act as a PA
  unless it knows definitively that it has complete presence
  information for a user. Because of the forking rules described in
  Section 5.10, a subscriber will only get presence information from
  one PA, and this information has to be complete."


I am however still concerned with the notion that a PUA can know
definitively that it has complete presence information. Once a PUA as
assumed the role of PA, there is nothing to prevent another UA from
registering with the original proxy, without notifying the PA of this. I
believe the result will simply be unreliable presence information.

I also have a question about the relationship between presence and
callerprefs:

Suppose a UAS uses callerprefs when registering with a registrar (using
callerpref parameters on the Contact headers in the REGISTER). And
suppose the registrar is also a PA. Has there been any consideration for
reporting the callerpref information in the resulting presence
notifications? (I don't see any provision for it now in
draft-ietf-impp-cpim-pidf-00.) 

	Paul

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Tuesday, September 25, 2001 5:36 PM
> > To: Jonathan Rosenberg
> > Cc: 'simple@mailman.dynamicsoft.com'
> > Subject: Re: [Simple] Updated presence spec
> >
> >
> > Jonathan,
> >
> > In reviewing the new document, I noticed something
> > troublesome about the
> > migration description:
> >
> > It suggests that a PUA can indicate ability to act as a PA by
> > sending a
> > REGISTER with a caller preferences "methods" parameter listing
> > SUBSCRIBE, and goes on to say that a PUA MUST NOT do this unless it
> > knows definitively that it has complete presence information
> > for a user.
> > The problem with this is that the PUA may also be a UA for
> > reasons other
> > than presence, and may need to support SUBSCRIBE for event packages
> > other than presence. Then it is stuck - it is forced to implement PUA
> > functionality as a precondition to advertising support for the other
> > event package.
> 
> This is an excellent observation.
> 
> Fortunately, its not required to implement PUA functionality for all
> packages. If it should end up getting a request for a package it doesn't
> support, it simply generates a 489. This would be a problem if the text
> about not forking were still in there; but its not. A proxy will fork the
> SUBSCRIBE to all registered contacts that support it, and so long as one PUA
> supports the event package thats been requested, things work fine. In a
> world where there are lots of packages, this could cause more useless
> traffic to the PUA than you might otherwise want. I'll note this in the
> spec.
> 
> The right way to fix this, ultimately, is to use caller preferences some
> more. Caller preferences is extensible, so that one can define new
> attributes. You would simply define "events" as another attribute, which
> indicates the set of events it supports. A proxy server could then use this
> to route requests with specific Event headers to those contacts which have
> explicitly supported it. That would eliminate all unecessary overheads.
> 
> However, I suspect this is a problem in theory only for the time being, and
> we can fix it with the caller prefs parameters when the time comes where it
> is a real problem.
> 
> -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

From jdrosen@dynamicsoft.com  Tue Oct  2 10:08:19 2001
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 KAA16460
	for ; Tue, 2 Oct 2001 10:08:19 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f92E708P001610;
	Tue, 2 Oct 2001 10:07:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SMZ0X>; Tue, 2 Oct 2001 10:08:03 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Neil Deason'" ,
        Brazier Lachlan
	 ,
        "'SIMPLE Mailinglist'"
	 
Subject: RE: [Simple] Multiple 200 Ok
Date: Tue, 2 Oct 2001 10:08:02 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2782
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: 


 

> -----Original Message-----
> From: Neil Deason [mailto:ndeason@ubiquity.net]
> Sent: Tuesday, October 02, 2001 7:36 AM
> To: Brazier Lachlan; 'SIMPLE Mailinglist'
> Subject: RE: [Simple] Multiple 200 Ok
> 
> 
> > -----Original Message-----
> > From: simple-admin@mailman.dynamicsoft.com
> > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Brazier
> > Lachlan
> > Sent: 02 October 2001 10:42
> > To: 'SIMPLE Mailinglist'
> > Subject: [Simple] Multiple 200 Ok
> > 
> > 
> > Hello,
> > I refer to "5.10 Handling of Forked Requests" in
> > "draft-ietf-simple-presence-03.txt".
> > .....
> > ....Some of these may respond with a 2xx response to the 
> > SUBSCRIBE. Based on
> > the forking rules in SIP, only one of these
> >    responses is passed to the subscriber. ...
> > .....
> > 
> > As far as I remember, a proxy always passes a 2xx response 
> > upstream. Even if
> > a forking proxy cancels other branches on receiving a 2xx, 
> > the CANCEL can
> > still cross on the line with a 2xx response. A scenario would 
> > be, that one
> > branch returns a 202 response first, and then another branch 
> > returns a 200
> > Ok response.
> 
> For non-INVITEs a proxy must forward only a single response 
> upstream, 2xx or otherwise. INVITEs are a special case
> where all 2xxs must be forwarded. This is because of the
> different reliability mechanisms at play. Non-INVITEs 
> requests are retransmitted until a response is received.
> Therefore only a single response can ever be transmitted
> reliably. 2xxs for INVITEs have end to end reliability 
> so all of them must be sent back so they can be ACK'd
> by the UAC. See section 14 of bis for the full details.

Right.

> > So, if the proxy passes all 2xx message upstream, does the 
> > subscriber have
> > finally subscribed to more than one user? How can a 
> > subscriber realize, that
> > a forking proxy forked to a different user (this can happen 
> > when I am on
> > holiday, and I register my working collegue with my working 
> > SIP Url - and
> > then somebody wants to subscribe for me)?

Even without multiple 200 OK being forwarded to the subscriber, a single
SUBSCRIBE can still fork, and result in the creation of multiple
subscriptions. The subscriber will find out about these from the NOTIFY that
get sent, and will respond with a 481 to all but one, cancelling them. This
is all described in Section 5.12 of the presence spec.

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

From jdrosen@dynamicsoft.com  Tue Oct  2 10:21:50 2001
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 KAA16529
	for ; Tue, 2 Oct 2001 10:21:50 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f92EKc8P001819;
	Tue, 2 Oct 2001 10:20:38 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SM5CG>; Tue, 2 Oct 2001 10:21:41 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Paul Kyzivat'" 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Updated presence spec
Date: Tue, 2 Oct 2001 10:21:41 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 4861
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: 


 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, October 02, 2001 9:34 AM
> To: Jonathan Rosenberg
> Cc: 'simple@mailman.dynamicsoft.com'
> Subject: Re: [Simple] Updated presence spec
> 
> 
> Jonathan,
> 
> You have satisfactorily answered my concerns, but the text doesn't
> really reflect what you have said. How about something like the
> following: 
> 
>  "The first of these phases can occur through configuration, 
> or through
>   dynamic means. One dynamic means for a presence server to discover
>   that the function can migrate to a PUA through the REGISTER message.
>                                         ^
>                                         is

Fixed.

>   Specifically, if a PUA wishes to indicate support for the PA
>   function, it SHOULD include a contact address in its registration
>   with a caller preferences "methods" parameter listing 
> SUBSCRIBE [13].
>   This indicates that it is capable of terminating and processing
>   SUBSCRIBE, and therefore can act as a PA. A PUA MUST NOT do this
>                            ^^^                             ^^^^^^^
>                            may be able to                  act as a PA

Since a PA is specifically defined for the presence event package, the
statement "can" is correct, I believe. In fact, the next sentence validates
that it can, since it MUST NOT perform this registration if it can't.

I fixed "do this" as you describe. I also added text at the end of this
paragraph:

 Because the ``methods'' parameter does not convey the
set of event packages for which the PUA can accept SUBSCRIBE, it is
possible that the PUA will begin receiving SUBSCRIBE requests for
other packages, possibly ones it doesn't support. As specified in
\cite{draft-ietf-sip-events}, the PUA {\SHOULD} reject those requests
with a 489.


> 
> I am however still concerned with the notion that a PUA can know
> definitively that it has complete presence information. Once a PUA as
> assumed the role of PA, there is nothing to prevent another UA from
> registering with the original proxy, without notifying the PA 
> of this. I
> believe the result will simply be unreliable presence information.

There are really only two choices here. The first choice is that we allow
multiple PA for a presentity, each of which has access to different subsets
of the presence information. This means that we would need to change the
forking behavior, and then mandate that subscribers be able to merge
multiple independent presence documents received from multiple sources. We
discussed that, and elected NOT to do it, since (1) this is a significant
burden on the watcher, (2) the correct merging process is very policy
specific, and can only be done reasonably at the presentity's domain where
the policy resides. 

The second choice is what is documented now - mandate that any PA have
complete presence state. Enforcement of that can be difficult, but is easily
done on a system level. Consider, for example, a provider foo.com that is
ONLY supporting instant messaging services using SIP. They also provide
presence to indicate IM status, and only allow one client registered at a
time. Since foo.com owns and runs the whole system, they can be sure that
any presence client that has IM status has complete presence state, and
therefore there is no problem in migrating subscriptions.

Effectively, enforcement of this requirement cannot be done at an element
level, but it can be done at a system level. 

I welcome other ideas on how to improve the story on this.


> 
> I also have a question about the relationship between presence and
> callerprefs:
> 
> Suppose a UAS uses callerprefs when registering with a 
> registrar (using
> callerpref parameters on the Contact headers in the REGISTER). And
> suppose the registrar is also a PA. Has there been any 
> consideration for
> reporting the callerpref information in the resulting presence
> notifications? (I don't see any provision for it now in
> draft-ietf-impp-cpim-pidf-00.) 

Sure, definitely. Not all can be mapped, but many of them have obvious
useful presence implications. At one point, we were going to go through the
exercise of mapping the caller prefs parameters to the presence data format.
However, we decided that this mapping is a matter of local implementation.
If a client wishes to directly affect their presence information, they
should instead upload a presence document that describes it explicitly. 

-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

From bstucker@nortelnetworks.com  Tue Oct  2 10:22:29 2001
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 KAA16552
	for ; Tue, 2 Oct 2001 10:22:29 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA22507
	for ; Tue, 2 Oct 2001 09:22:18 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Tue, 2 Oct 2001 09:21:56 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 2 Oct 2001 09:21:51 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E3501FD@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Jonathan Rosenberg ,
        Jonathan Rosenberg ,
        Jonathan Rosenberg ,
        "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Questions on the current presence draft.
Date: Tue, 2 Oct 2001 09:21:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14B4D.906E7E90"
Content-Length: 5886
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: 

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_01C14B4D.906E7E90
Content-Type: text/plain;
	charset="iso-8859-1"

Replies embedded.

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, October 02, 2001 1:16 AM
To: Stucker, Brian [NGB:B621:EXCH]; Jonathan Rosenberg; Jonathan
Rosenberg; 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Questions on the current presence draft.


> Since it'd be a self-induced flood, well, I 
>guess that's the problem that the watcher has to deal with, however, I'm
trying to think 
>of ways of protecting the network in this case from using this as an attack
of some sort.

I still don't get it. What flood? Are you worried about the case where the
PA sends a bunch of NOTIFY with Subscription-Expires, causing all the
watchers to resubscribe at the same time? This can be fixed as a local
implementation decision by gradually migrating subscriptions rather than all
at the same time. I'll mention that, but I'm not sure thats what you're
talking about.

*** [Brian S]  Yes, this is what I'm talking about. I think a mention is all
that
it warrants.

>If the watcher gets a 481 back from the presence server because a presence
agent has 
>migrated, how is it to tell that this was because it missed the
subscription expiration, 
>rather than it simply making a bad request on the presence server?

For SUBSCRIBE, 481 should always mean "try again without your tags/Routes
since this doesn't exist where you thought it should". In the case of a PA
that hasn't migrated, but has forgotten its subscription state because it
expired, the refresh shouldn't really generate a 481. Rather, the SUBSCRIBE
should re-establish the subscription state - thats the definition of
soft-state. In this case, the response is a 2xx. The PA would only send a
481 if its not able to reconstruct the subscription state. In that case, the
client does the right thing - tries again without the tags/Routes to rebuild
it from ground zero.

Now, all of this is definitely not clear in sip-events, which is where it
all belongs. I have several emails into Adam to get these things clarified.

*** [Brian S] Yes, you are correct. It is. Thanks, Jonathan.



------_=_NextPart_001_01C14B4D.906E7E90
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Questions on the current presence draft.




Replies embedded.




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Tuesday, October 02, 2001 1:16 AM

To: Stucker, Brian [NGB:B621:EXCH]; Jonathan Rosenberg; Jonathan

Rosenberg; 'simple@mailman.dynamicsoft.com'

Subject: RE: [Simple] Questions on the current presence draft.






> Since it'd be a self-induced flood, well, I 

>guess that's the problem that the watcher has to deal with, however, I'm

trying to think 

>of ways of protecting the network in this case from using this as an attack

of some sort.




I still don't get it. What flood? Are you worried about the case where the

PA sends a bunch of NOTIFY with Subscription-Expires, causing all the

watchers to resubscribe at the same time? This can be fixed as a local

implementation decision by gradually migrating subscriptions rather than all

at the same time. I'll mention that, but I'm not sure thats what you're

talking about.




*** [Brian S]  Yes, this is what I'm talking about. I think a mention is all that

it warrants.




>If the watcher gets a 481 back from the presence server because a presence

agent has 

>migrated, how is it to tell that this was because it missed the

subscription expiration, 

>rather than it simply making a bad request on the presence server?




For SUBSCRIBE, 481 should always mean "try again without your tags/Routes

since this doesn't exist where you thought it should". In the case of a PA

that hasn't migrated, but has forgotten its subscription state because it

expired, the refresh shouldn't really generate a 481. Rather, the SUBSCRIBE

should re-establish the subscription state - thats the definition of

soft-state. In this case, the response is a 2xx. The PA would only send a

481 if its not able to reconstruct the subscription state. In that case, the

client does the right thing - tries again without the tags/Routes to rebuild

it from ground zero.




Now, all of this is definitely not clear in sip-events, which is where it

all belongs. I have several emails into Adam to get these things clarified.




*** [Brian S] Yes, you are correct. It is. Thanks, Jonathan.







------_=_NextPart_001_01C14B4D.906E7E90--

From jdrosen@dynamicsoft.com  Tue Oct  2 10:59:27 2001
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 KAA16717
	for ; Tue, 2 Oct 2001 10:59:27 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f92EtJ8P002374;
	Tue, 2 Oct 2001 10:55:19 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SM5JB>; Tue, 2 Oct 2001 10:56:22 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brian Stucker'" ,
        simple
	 
Subject: RE: [Simple] Migration and client PA as a definitive authority.
Date: Tue, 2 Oct 2001 10:56:21 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4654
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: 


  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Friday, September 28, 2001 4:47 PM
To: simple
Subject: [Simple] Migration and client PA as a definitive authority.


>Question about presence migration. Still looking at it, and the new 03
draft clears a lot 
>of questions up, but one still remains for me...
>
>How do we go about ensuring that a PUA that signals that it wishes to
become the PA for 
>the presentity, by migrating the PA away
>from the presence server, is the definitive source of the aggregated
presence 
>information?

I took a stab at answering this in a separate thread:
http://mailman.dynamicsoft.com/pipermail/simple/2001-October/000844.html

The basic answer is that its a system level decision. I think that
eventually, it will be almost impossible to do this migration as the sources
of presence become large.

>
>As I understand it, the PUAs feed presence fragments to the PA via the
REGISTER method, 
>which a client UA shouldn't be receiving
>as it's not a registrar.

As Robert indicated, REGISTER is one way. The requirement for migrating is
that whatever the inputs to presence, a PUA have access to all of them. If
presence is effectively being fed to the presence server through
registrations from a single client, then the client also has complete
presence information.

>Therefore, if the client PA/PUA doesn't have a way of getting 
>the presence fragments from the other various
>PUAs (at least not through SIP), should it be allowed to migrate the PA
function away 
>from the presence server?

I say no.

>I know we could signal
>across devices using some means other than SIP, but looking at this as a
state agent 
>handling state synchronization within an event
>framework, shouldn't there be defined a method to use the same protocol for
this job 
>(SIP) as a baseline mechanism?

In that case, you haven't really migrated at all, since the presence server
is still acting as a UA, but just for one subscription (from the PUA which
is know trying to act as a PA). I hadn't thought about doing this. It can be
done within the bounds of the protocol, but I suspect that the complexity
will buy you little.

>I noticed in the documentation under the migration and forking sections
text that said 
>that it was best for a network PA to do aggregation,
>and I agree with that. How do we ensure that the aggregation is handled
correctly when 
>the PA is no longer in the network?

You can't - which is why the spec says you shouldn't migrate the function
unless the PUA is sure its effectively the only source. 

>Another question that I have regards what is really saved by migrating to a
client 
>device? We still have to keep the presence server in the route
>in order to detect migration back to the presence server from the client
PA/PUA. The 
>notifications still have to travel through the presence server
>because they must follow the same route as was established in the
SUBSCRIBE. So it seems 
>that all we're saving is the aggregation piece, which
>seems relatively simple to do from a centralized server.

No, you gain a lot in terms of fault tolerance. The presence server is now a
proxy, not a PA, which means it has no state and has a much better story for
fault tolerance. The overall system performance will also be a lot better.
You no longer have a centralized component managing subscriptions  - that
task is delegated out to clients. 


>The reason I bring the last bit up is because one way I was thinking the
PUA information 
>could be dealt with is by making the presence server a
>reflector of the information fed in by PUAs in registrations by way of
having the PA/PUA 
>subscribe to itself at the presence server (which would
>always be allowed, and this portion of the PA would not migrate). That way
the 
>registrations cause a NOTIFY to be sent back to the migrated PA to
>keep it in sync.

Well, one can build a system that works this way. I'm not sure I want to go
into this in the specification, though. I'd rather not be migrating in cases
like this.

>Does this make any sense, or am I seriously off in the weeds somewhere?

No, it makes sense. Migration is an odd and complex topic. 

I welcome suggested text to help improve the clarity of this issue in the
specification.

-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

From pkyzivat@cisco.com  Tue Oct  2 11:04:43 2001
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 LAA16752
	for ; Tue, 2 Oct 2001 11:04:30 -0400 (EDT)
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 f92F3eA02309;
	Tue, 2 Oct 2001 11:03:40 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB24792 (AUTH pkyzivat);
	Tue, 2 Oct 2001 11:05:37 -0400 (EDT)
Message-ID: <3BB9D716.92DC6BB9@cisco.com>
Date: Tue, 02 Oct 2001 11:02:46 -0400
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] Updated presence spec
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 6691
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: 

Comments below.

	Paul

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Tuesday, October 02, 2001 9:34 AM
> > To: Jonathan Rosenberg
> > Cc: 'simple@mailman.dynamicsoft.com'
> > Subject: Re: [Simple] Updated presence spec
> >
> >
> > Jonathan,
> >
> > You have satisfactorily answered my concerns, but the text doesn't
> > really reflect what you have said. How about something like the
> > following:
> >
> >  "The first of these phases can occur through configuration,
> > or through
> >   dynamic means. One dynamic means for a presence server to discover
> >   that the function can migrate to a PUA through the REGISTER message.
> >                                         ^
> >                                         is
> 
> Fixed.
> 
> >   Specifically, if a PUA wishes to indicate support for the PA
> >   function, it SHOULD include a contact address in its registration
> >   with a caller preferences "methods" parameter listing
> > SUBSCRIBE [13].
> >   This indicates that it is capable of terminating and processing
> >   SUBSCRIBE, and therefore can act as a PA. A PUA MUST NOT do this
> >                            ^^^                             ^^^^^^^
> >                            may be able to                  act as a PA
> 
> Since a PA is specifically defined for the presence event package, the
> statement "can" is correct, I believe. In fact, the next sentence validates
> that it can, since it MUST NOT perform this registration if it can't.

I think there is still something wrong here, or at least subject to
misinterpretation.

If a PUA wishes to indicate support for the PA function, it can do as
you say, and it may believe that this indicates that it can act as a PA.
But the situation is different from the point of view of the registrar
that is acting as a PA. It receives the register listing the SUBSCRIBE
method, but it can't know whether this is from a server wishing to act
as a PA, or simply a server that wants to support some other event
package. So from the point of view of the registrar, this only means the
server MAY be able to act as a PA.

It seems like this has further implications for migration of the PA
function. If a PA/REGISTRAR receives a registration that suggests the
possibility of migrating the PA function, it should verify this before
beginning the migration. It could test it by sending a SUBSCRIBE to the
candidate PA and awaiting a successful response.

I think this would work, but it might not be nice for a UAS registering
to handle subscriptions for some other event package. Every time it
updates its subscription it might get dinged by PA testing to see if it
can now handle presence.

> 
> I fixed "do this" as you describe. I also added text at the end of this
> paragraph:
> 
>  Because the ``methods'' parameter does not convey the
> set of event packages for which the PUA can accept SUBSCRIBE, it is
> possible that the PUA will begin receiving SUBSCRIBE requests for
> other packages, possibly ones it doesn't support. As specified in
> \cite{draft-ietf-sip-events}, the PUA {\SHOULD} reject those requests
> with a 489.

Is 489 the best response? What about 305?

The above paragraph covers PAs that inadvertently receive subscriptions
for event packages other than presence. Maybe you need a similar
paragraph for UASs that inadvertently receive subscriptions for
presence:

  Similarly it is possible that a server supporting event 
  packages other than presence will receive SUBSCRIBE requests 
  for the presence package. 

> > I am however still concerned with the notion that a PUA can know
> > definitively that it has complete presence information. Once a PUA as
> > assumed the role of PA, there is nothing to prevent another UA from
> > registering with the original proxy, without notifying the PA
> > of this. I
> > believe the result will simply be unreliable presence information.
> 
> There are really only two choices here. The first choice is that we allow
> multiple PA for a presentity, each of which has access to different subsets
> of the presence information. This means that we would need to change the
> forking behavior, and then mandate that subscribers be able to merge
> multiple independent presence documents received from multiple sources. We
> discussed that, and elected NOT to do it, since (1) this is a significant
> burden on the watcher, (2) the correct merging process is very policy
> specific, and can only be done reasonably at the presentity's domain where
> the policy resides.
> 
> The second choice is what is documented now - mandate that any PA have
> complete presence state. Enforcement of that can be difficult, but is easily
> done on a system level. Consider, for example, a provider foo.com that is
> ONLY supporting instant messaging services using SIP. They also provide
> presence to indicate IM status, and only allow one client registered at a
> time. Since foo.com owns and runs the whole system, they can be sure that
> any presence client that has IM status has complete presence state, and
> therefore there is no problem in migrating subscriptions.
> 
> Effectively, enforcement of this requirement cannot be done at an element
> level, but it can be done at a system level.
> 
> I welcome other ideas on how to improve the story on this.

This is clearly a hard problem, and I don't claim to have a complete
answer. Clearly there are special cases where migration can work fine -
such as when there is only one UAS registered for an address. In other
cases the safest policy is probably to not do the migration.

> > I also have a question about the relationship between presence and
> > callerprefs:
> >
> > Suppose a UAS uses callerprefs when registering with a
> > registrar (using
> > callerpref parameters on the Contact headers in the REGISTER). And
> > suppose the registrar is also a PA. Has there been any
> > consideration for
> > reporting the callerpref information in the resulting presence
> > notifications? (I don't see any provision for it now in
> > draft-ietf-impp-cpim-pidf-00.)
> 
> Sure, definitely. Not all can be mapped, but many of them have obvious
> useful presence implications. At one point, we were going to go through the
> exercise of mapping the caller prefs parameters to the presence data format.
> However, we decided that this mapping is a matter of local implementation.

Why? This simply guarantees a lack of interoperability.
The mapping of registration to presence provides a base level
of standardization. To the extent that callerprefs is a standard
extension to registration, it also ought to map in a standard way.

From jdrosen@dynamicsoft.com  Tue Oct  2 11:09:29 2001
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 LAA16803
	for ; Tue, 2 Oct 2001 11:09:28 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f92F0C8P002511;
	Tue, 2 Oct 2001 11:00:12 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SM5KQ>; Tue, 2 Oct 2001 11:01:15 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Robert Brown'" ,
        Brian Stucker
	 ,
        simple 
Subject: RE: [Simple] Migration and client PA as a definitive authority.
Date: Tue, 2 Oct 2001 11:01:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 2016
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: 


  
-----Original Message-----
From: Robert Brown [mailto:roberbr@microsoft.com]
Sent: Saturday, September 29, 2001 9:12 PM
To: Brian Stucker; simple
Subject: RE: [Simple] Migration and client PA as a definitive authority.


>Actually, I think REGISTER is only meant to be an example of one way an
implementer might 
>want to publish presence to the PA.  You've hit on one of the examples of
why this isn't 
>a great idea (and I agree).  A few other reasons I don't like using
REGISTER to publish 
>presence:

REGISTER is not a good way to publish general presence docs, I agree.
However, its an excellent INPUT to the PA process of generating a presence
doc, since it naturally conveys information about a user. A registration
tells the server whether the user is connected to receive invitations to
sessions, and that is presence data.

> 1) REGISTER is something you'll want to send pretty frequently unless you
have 
>a very stable and static network, but you only need to send new presence
status when you 
>actually have some new state; 2) there are only so many ways you can
overload REGISTER 
>and complicate its semantics - it's better IMHO just to invent a different
method or do 
>something out of band; or do something tricky like have the PA subscribe to
the PUA; 3) 
>why should I be registered in order to publish presence?

All of these are good reasons why REGISTER is not the right way for a client
to push presence specific data to a server. Its for that reason that Steve
Donovan wrote up some requirements on a more appropriate publication
protocol:

http://www.ietf.org/internet-drafts/draft-donovan-publish-requirements-00.tx
t

-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

From pkyzivat@cisco.com  Tue Oct  2 11:33:21 2001
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 LAA16924
	for ; Tue, 2 Oct 2001 11:33:21 -0400 (EDT)
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 f92FWZA04790;
	Tue, 2 Oct 2001 11:32:35 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB25115 (AUTH pkyzivat);
	Tue, 2 Oct 2001 11:34:32 -0400 (EDT)
Message-ID: <3BB9DDDD.551E0EE1@cisco.com>
Date: Tue, 02 Oct 2001 11:31:41 -0400
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: "'Robert Brown'" ,
        Brian Stucker ,
        simple 
Subject: Re: [Simple] Migration and client PA as a definitive authority.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3495
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: 

I agree with Jonathan that REGISTER is a good way to convey information
that can be used to create a presence document, but perhaps is not a
good way to transmit a presence document.

But I will go further - I don't see the advantage in any kind of
presence document other than the one that can be created from
registration information. If you create a presence document some other
way, then it runs the risk of being inconsistent with registrations.
This will simply lead to surprises when a presence client takes action
based on the presence document.

Of course the presence document can carry nuances to presence that
aren't available from registrations, but most of those probably indicate
limitations in the registration mechanism. Most of the nuances that I
imagine could be useful can be expressed using callerprefs. What is
needed is an agreement on how that information will be represented in
the presence document.

If PUAs have some added nuance to state about their presence, I think it
would be better to convey a document in their REGISTER message that is
incorporated (in a well defined way) as an extra section in the presence
document that the registrar syntasizes. 

	Paul Kyzivat

Jonathan Rosenberg wrote:
> 
> 
> -----Original Message-----
> From: Robert Brown [mailto:roberbr@microsoft.com]
> Sent: Saturday, September 29, 2001 9:12 PM
> To: Brian Stucker; simple
> Subject: RE: [Simple] Migration and client PA as a definitive authority.
> 
> >Actually, I think REGISTER is only meant to be an example of one way an
> implementer might
> >want to publish presence to the PA.  You've hit on one of the examples of
> why this isn't
> >a great idea (and I agree).  A few other reasons I don't like using
> REGISTER to publish
> >presence:
> 
> REGISTER is not a good way to publish general presence docs, I agree.
> However, its an excellent INPUT to the PA process of generating a presence
> doc, since it naturally conveys information about a user. A registration
> tells the server whether the user is connected to receive invitations to
> sessions, and that is presence data.
> 
> > 1) REGISTER is something you'll want to send pretty frequently unless you
> have
> >a very stable and static network, but you only need to send new presence
> status when you
> >actually have some new state; 2) there are only so many ways you can
> overload REGISTER
> >and complicate its semantics - it's better IMHO just to invent a different
> method or do
> >something out of band; or do something tricky like have the PA subscribe to
> the PUA; 3)
> >why should I be registered in order to publish presence?
> 
> All of these are good reasons why REGISTER is not the right way for a client
> to push presence specific data to a server. Its for that reason that Steve
> Donovan wrote up some requirements on a more appropriate publication
> protocol:
> 
> http://www.ietf.org/internet-drafts/draft-donovan-publish-requirements-00.tx
> t
> 
> -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 lachlan.brazier@siemens.at  Tue Oct  2 12:03:41 2001
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 MAA17080
	for ; Tue, 2 Oct 2001 12:03:40 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f92G3Ru11882;
	Tue, 2 Oct 2001 18:03:27 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id SAA08001;
	Tue, 2 Oct 2001 18:03:26 +0200 (MET DST)
Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta)
	id xma007596; Tue, 2 Oct 01 18:02:56 +0200
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id ; Tue, 2 Oct 2001 18:02:55 +0200
Message-ID: 
From: Brazier Lachlan 
To: "'Jonathan Rosenberg'" ,
        "'Neil Deason'"
	 ,
        "'SIMPLE Mailinglist'"
	 
Subject: AW: [Simple] Multiple 200 Ok
Date: Tue, 2 Oct 2001 18:02:53 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 811
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: 

Hello,
thank you for your clarification. There is still this one point open:

> > > How can a 
> > > subscriber realize, that
> > > a forking proxy forked to a different user (this can happen 
> > > when I am on
> > > holiday, and I register my working collegue with my working 
> > > SIP Url - and
> > > then somebody wants to subscribe for me)?


I believe, the problem can occur, when a proxy changes the request-URI. This
would mean, that the proxy sends a SUBSCRIBE to another presentity. I still
can't see, how the subscriber knows, that his SUBSCRIBE request was handled
by a different user.

I could imagine, that in the first NOTIFY after receiving the SUBSCRIBE
request, the FROM header is different than the To header from the SUBSCRIBE
request. Is this valid with the draft?


thanks again 
Lachlan

From akristensen@dynamicsoft.com  Tue Oct  2 20:24:28 2001
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 UAA18780
	for ; Tue, 2 Oct 2001 20:24:28 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.156])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f930N78P007459;
	Tue, 2 Oct 2001 20:23:09 -0400 (EDT)
Message-ID: <3BBA5AAA.429CF6F4@dynamicsoft.com>
Date: Tue, 02 Oct 2001 20:24:10 -0400
From: Anders Kristensen 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Sean Olson (EUS)" 
CC: "'Jonathan Rosenberg'" ,
        "'Robert Brown'" ,
        Avshalom Houri , simple@mailman.dynamicsoft.com,
        "Adam Roach (E-mail)" 
Subject: Re: [Simple] Partial Notifies?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 4795
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: 


"Sean Olson (EUS)" wrote:
> 
> I realize this has been pushed off to future work,
> but I thought I would throw my two cents in now.
> I think we could have a reasonable first draft
> of a partial NOTIFY mechanism completed in a
> couple of weeks.

Yup.

> 
> >That sure sounds like way too much. The draft I had in mind was
> >http://www.ietf.org/internet-drafts/draft-mogul-http-delta-08.txt
> >
> >This details how various diff algorithms (textual or binary - the
> >mechanism works with either) can be used to reduce the message
> >size when
> >the client has an old version of some resource. It seems like it
> should
> >be fairly straightforward to apply the same ideas to SIP.
> 
> I agree. This is much simpler. Can we make a baseline
> requirement for either vcdiff or gdiff? Both support
> binary data. gdiff seems simpler, but vcdiff supports
> compression. If I had to choose, I would mandate support
> for vcdiff.

I'd prefer a recommendation over a hard requirement for a particular
format/algorithm. I agree that vcdiff seems like the better choice.

> 
> >So here's a sketch of how this might work in SIP.
> >
> >Clients would indicate support for one or more delta encoding
> >mechanisms
> >in SUBSCRIBEs by listing extension token 'delta' in a Supported
> header
> >and the actual "instance manipulations" supported in an A-IM header
> >(A-IM stands for Accept-Instance-Manipulations and is defined in the
> >http draft as is the IM header used in NOTIFYes):
> >
> >        SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
> >        Supported: delta
> >        A-IM: diffe, vcdiff
> >        Event: presence
> >        ...
> 
> Can we use the A-IM: header as an implicit indicator
> of support for delta encoding?

Sounds reasonable.

> 
> >the server would make a note of supported alg's in the subscription
> >"record".
> >
> >The server then has to know what version of a particular subscription
> 
> >doc a watcher has received, and when it sends a NOTIFY for a watcher
> it
> >may send only a delta if that guy has indicated support for it, e.g.:
> 
> >
> >        NOTIFY sip:user@watcherhost.example.com SIP/2.0
> >        Require: delta
> >        IM: diffe
> >        Delta-Base: "abc"
> >        Etag: "ghi"
> >        Event: presence
> >        Content-Type: application/cpim-pidf+xml
> >
> >        ...
> >
> >Unlike the http case there's no request in which a version number/tag
> 
> >can be carried so presumably the server has to just know what
> >version of
> >the presence doc (or whatever) the client knows about, or else assume
> 
> >that it knows about the previous version.  If for some reason
> >the client
> >doesn't, it would return some error response which would tell
> >the server
> >to send the whole resource/document. The error response would also
> list
> >the A-IM and Supported header as appropriate.
> 
> I assume we can do something like:
> SUBSCRIBE sip:presentity@pres.example.com?Etag="ghi" SIP/2.0
> to at least indicate what version the client has at the
> time of subscription. The first NOTIFY could then include
> either the full state or the appropriate delta encoding to
> bring the client in sync with the server. Or use a
> "If-None-Match:" header as in HTTP/1.1.

I like the idea of the client telling the server which version it has in
the SUBSCRIBE but I think it's preferable to put the version number in
an ETag header as in HTTP.

> 
> I don't see a reason to return an error response to the server.
> Do a one-time SUBSCRIBE with no "A-IM" header instead. It costs
> two extra messages, but simplifies the life of the presence server.
> 
> >
> >The Delta-Base header gives the version of the resource that the
> delta
> >should be applied to (and which the client is assumed to possess).
> The
> >ETag gives an identifier for the new resource.
> 
> Sounds good.
> 
> >
> >A presence server that doesn't know about the delta extension just
> >ignores the A-IM header and sends the full update every time.
> 
> Sounds reasonable. Some things that need to be fleshed out include:
> 
> 1) How would the server indicate in the initial NOTIFY that the
>    client state is already up-to-date? (HTTP 1.1 uses a
>    "304 Not Modified" response code. Do we want to do something
>    similar?) This would be particularly useful for a fetch operation.

It may be enough to send a NOTIFY with identical values in the ETag and
Delta-Base headers and an empty body (or whatever ).

> 
> 2) Do we want to allow compression manipulations in addition to the
>    delta encoding? Or can we just apply Content-Encodings on top
>    of the delta encoding? I assume the later is fine.

I'm not sure why HTTP includes both but I see no reason for excluding
compressions. There's no requirement to support any, of course.

> 
> /sean

Anders

From jdrosen@dynamicsoft.com  Tue Oct  2 22:38:20 2001
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 WAA19200
	for ; Tue, 2 Oct 2001 22:38:19 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f932b58P007877;
	Tue, 2 Oct 2001 22:37:05 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SM7Q5>; Tue, 2 Oct 2001 22:38:09 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brazier Lachlan'" ,
        Jonathan Rosenberg
	 ,
        "'Neil Deason'" ,
        "'SIMPLE Mailinglist'" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Tue, 2 Oct 2001 22:38:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1815
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: 


 

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Tuesday, October 02, 2001 12:03 PM
> To: 'Jonathan Rosenberg'; 'Neil Deason'; 'SIMPLE Mailinglist'
> Subject: AW: [Simple] Multiple 200 Ok
> 
> 
> Hello,
> thank you for your clarification. There is still this one point open:
> 
> > > > How can a 
> > > > subscriber realize, that
> > > > a forking proxy forked to a different user (this can happen 
> > > > when I am on
> > > > holiday, and I register my working collegue with my working 
> > > > SIP Url - and
> > > > then somebody wants to subscribe for me)?
> 
> 
> I believe, the problem can occur, when a proxy changes the 
> request-URI. This
> would mean, that the proxy sends a SUBSCRIBE to another 
> presentity. 

Changing the request URI does not imply chaging the presentity. Changing it
may occur in order to address the request to the presentity at a different
location.


I still
> can't see, how the subscriber knows, that his SUBSCRIBE 
> request was handled
> by a different user.

The entity that finally responds to the SUBSCRIBE will place, in the 2xx, a
Contact header that contains their URL.


> 
> I could imagine, that in the first NOTIFY after receiving the 
> SUBSCRIBE
> request, the FROM header is different than the To header from 
> the SUBSCRIBE
> request. Is this valid with the draft?

No; as it stands, the To/From are flipped in the NOTIFY from the presentity.


-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

From lachlan.brazier@siemens.at  Wed Oct  3 02:52:07 2001
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 CAA20004
	for ; Wed, 3 Oct 2001 02:52:06 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f936psu07985;
	Wed, 3 Oct 2001 08:51:55 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id IAA04938;
	Wed, 3 Oct 2001 08:51:53 +0200 (MET DST)
Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta)
	id xma003805; Wed, 3 Oct 01 08:51:05 +0200
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id ; Wed, 3 Oct 2001 08:51:04 +0200
Message-ID: 
From: Brazier Lachlan 
To: "'Jonathan Rosenberg '" ,
        Brazier Lachlan
	 ,
        "''Neil Deason' '" ,
        "''SIMPLE Mailinglist' '" 
Subject: AW: [Simple] Multiple 200 Ok
Date: Wed, 3 Oct 2001 08:51:02 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2978
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: 

 Hello,
as far as I see, the problem lays in the registration. Is there a way to
tell a registrar, that the registered address belongs to a different user?

I really believe a subscriber should know if he is subscribed to the right
person. As example imagine a subscriber, who subscribes for you, and when
you are online, sends you private documents automaticly. You probably don't
want this to happen.

I think the same might be true for INVITE. Imagine a video service, where a
video provider starts a video session, without knowing that you are not the
right customer, and not knowing that you are on holiday. (An example would
be a timed wakeup call or something like this) 

A solution I might think of, is to add a new parameter to the Contact
header, indicating if I am really the user addressed to, or in a REGISTER
request, to tell the registrar if the registered address "belongs" to me or
a different user at all.

Is this nonsense I am talking? 

Lachlan

-----Originalnachricht-----
Von: Jonathan Rosenberg
An: 'Brazier Lachlan'; Jonathan Rosenberg; 'Neil Deason'; 'SIMPLE
Mailinglist'
Gesendet: 03.10.01 04:38
Betreff: RE: [Simple] Multiple 200 Ok



 

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Tuesday, October 02, 2001 12:03 PM
> To: 'Jonathan Rosenberg'; 'Neil Deason'; 'SIMPLE Mailinglist'
> Subject: AW: [Simple] Multiple 200 Ok
> 
> 
> Hello,
> thank you for your clarification. There is still this one point open:
> 
> > > > How can a 
> > > > subscriber realize, that
> > > > a forking proxy forked to a different user (this can happen 
> > > > when I am on
> > > > holiday, and I register my working collegue with my working 
> > > > SIP Url - and
> > > > then somebody wants to subscribe for me)?
> 
> 
> I believe, the problem can occur, when a proxy changes the 
> request-URI. This
> would mean, that the proxy sends a SUBSCRIBE to another 
> presentity. 

Changing the request URI does not imply chaging the presentity. Changing
it
may occur in order to address the request to the presentity at a
different
location.


I still
> can't see, how the subscriber knows, that his SUBSCRIBE 
> request was handled
> by a different user.

The entity that finally responds to the SUBSCRIBE will place, in the
2xx, a
Contact header that contains their URL.


> 
> I could imagine, that in the first NOTIFY after receiving the 
> SUBSCRIBE
> request, the FROM header is different than the To header from 
> the SUBSCRIBE
> request. Is this valid with the draft?

No; as it stands, the To/From are flipped in the NOTIFY from the
presentity.


-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

From Dror@vocaltec.com  Wed Oct  3 04:39:36 2001
Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20350
	for ; Wed, 3 Oct 2001 04:39:35 -0400 (EDT)
From: Dror@vocaltec.com
Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135])
	by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id KAA25768;
	Wed, 3 Oct 2001 10:38:17 +0200 (IST)
To: Paul Kyzivat 
Cc: Jonathan Rosenberg ,
        "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] MESSAGE sessions - over TCP
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: 
Date: Wed, 3 Oct 2001 10:35:26 +0200
X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 10/03/2001 10:35:27 AM,
	Serialize complete at 10/03/2001 10:35:27 AM
Content-Type: multipart/alternative; boundary="=_alternative 002F3FC042256ADA_="
Content-Length: 6619
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: 

This is a multipart message in MIME format.
--=_alternative 002F3FC042256ADA_=
Content-Type: text/plain; charset="us-ascii"

This suggested combined page-session mode comes to overcome the limitation 
of either mode.
page-mode messaging is a burden on the SIP proxy network, as it requires 
all messages to go through the proxies, while p2p session-mode requires 
much higher first-message sending time, and indeed many times the session 
is one-message only.
This combined mode tries to get these two modes into one. namely, start in 
page-mode, and transition to session mode.
Still, if the end user actively want to initiate a session (that is, 
selects "chat with..." menu option instead of "send a message to..." 
option), then the session-mode can be initiated. But I find most chat 
sessions start with a single page-mode message, which is often left as a 
single-message-session.

----------------------------------------------------------------
Dror Tirosh 
VocalTec Communications, Ltd
--------------------------------------------------------------




Paul Kyzivat 
01/10/2001 15:17

 
        To:     Dror@vocaltec.com
        cc:     Jonathan Rosenberg , "'Petri K. Koskelainen'" 
, simple@mailman.dynamicsoft.com
        Subject:        Re: [Simple] MESSAGE sessions - over TCP




Dror@vocaltec.com wrote:
>
> I think message chats should be wrapped by an INVITE/BYE, as a chat
> session is indeed a session.
> However, unlike other media types, a chat starts with a single
                                            ^^^^^^
                                            may start

> message, and it seems to me a burden (for the SIP network) to require
> that a single message be sent using an INVITE wrapper.
> The actual session will be initiated by the callee of this initial
> message (so he can send the reply within the session)The only protocol
> change required is a way to associate the original message (which was
> sent before the SIP session was created) with that session.

What you suggest is one usage model, where the sender of the first
message doesn't anticipate a conversation, but the recipient decides a
session is required. But it certainly isn't the only usage model - it
quite possible that the need for a session is anticipated from the
beginning.

Certainly both of these scenarios can be supported. Yours is simply a
combination of paging mode usage plus session mode usage. It does get a
bit complicated if you wish to tie the session to the initial page, but
I don't know if that is really required.

        Paul Kyzivat
        Cisco Systems


--=_alternative 002F3FC042256ADA_=
Content-Type: text/html; charset="us-ascii"



This suggested combined page-session mode comes to overcome the limitation of either mode.

page-mode messaging is a burden on the SIP proxy network, as it requires all messages to go through the proxies, while p2p session-mode requires much higher first-message sending time, and indeed many times the session is one-message only.

This combined mode tries to get these two modes into one. namely, start in page-mode, and transition to session mode.

Still, if the end user actively want to initiate a session (that is, selects "chat with..." menu option instead of "send a message to..." option), then the session-mode can be initiated. But I find most chat sessions start with a single page-mode message, which is often left as a single-message-session.



----------------------------------------------------------------

Dror Tirosh <dror@vocaltec.com>

VocalTec Communications, Ltd

--------------------------------------------------------------











Paul Kyzivat <pkyzivat@cisco.com>

01/10/2001 15:17



        

        To:        Dror@vocaltec.com

        cc:        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, "'Petri K. Koskelainen'" <petkos@cs.columbia.edu>, simple@mailman.dynamicsoft.com

        Subject:        Re: [Simple] MESSAGE sessions - over TCP










Dror@vocaltec.com wrote:

>

> I think message chats should be wrapped by an INVITE/BYE, as a chat

> session is indeed a session.

> However, unlike other media types, a chat starts with a single

                                            ^^^^^^

                                            may start



> message, and it seems to me a burden (for the SIP network) to require

> that a single message be sent using an INVITE wrapper.

> The actual session will be initiated by the callee of this initial

> message (so he can send the reply within the session)The only protocol

> change required is a way to associate the original message (which was

> sent before the SIP session was created) with that session.



What you suggest is one usage model, where the sender of the first

message doesn't anticipate a conversation, but the recipient decides a

session is required. But it certainly isn't the only usage model - it

quite possible that the need for a session is anticipated from the

beginning.



Certainly both of these scenarios can be supported. Yours is simply a

combination of paging mode usage plus session mode usage. It does get a

bit complicated if you wish to tie the session to the initial page, but

I don't know if that is really required.



        Paul Kyzivat

        Cisco Systems




--=_alternative 002F3FC042256ADA_=--

From rsparks@dynamicsoft.com  Wed Oct  3 10:17:17 2001
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 KAA21442
	for ; Wed, 3 Oct 2001 10:17:17 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f93EG48P010305
	for ; Wed, 3 Oct 2001 10:16:04 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SM839>; Wed, 3 Oct 2001 10:17:07 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E64A@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Wed, 3 Oct 2001 10:17:03 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 454
Subject: [Simple] FYI: SIMPLE list policy change
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: 

The SIMPLE list has been around long enough to be
a consistant spam target.

To help reduce the probability of spam making it
to the list and to protect the individual list members,
we've made two changes:

1) You must be subscribed to the list in order to post.

2) Only the list administrators can view the current
   list membership.

If either of these somehow interfere with your ability
to participate in the working group, please contact me.

RjS

From rsparks@dynamicsoft.com  Wed Oct  3 10:59:26 2001
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 KAA21625
	for ; Wed, 3 Oct 2001 10:59:26 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f93EwC8P010876
	for ; Wed, 3 Oct 2001 10:58:12 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SM8V9>; Wed, 3 Oct 2001 10:59:16 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E64D@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] FYI: SIMPLE list policy change
Date: Wed, 3 Oct 2001 10:59:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1031
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: 

If you have multiple address you post from, you
can subscribe each of them, turning delivery off
(setting the nomail option) for all but one of them.

RjS

> -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: Wednesday, October 03, 2001 9:17 AM
> To: 'simple@mailman.dynamicsoft.com'
> Subject: [Simple] FYI: SIMPLE list policy change
> 
> 
> The SIMPLE list has been around long enough to be
> a consistant spam target.
> 
> To help reduce the probability of spam making it
> to the list and to protect the individual list members,
> we've made two changes:
> 
> 1) You must be subscribed to the list in order to post.
> 
> 2) Only the list administrators can view the current
>    list membership.
> 
> If either of these somehow interfere with your ability
> to participate in the working group, please contact me.
> 
> RjS
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From petkos@cs.columbia.edu  Wed Oct  3 14:05:56 2001
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 OAA22294
	for ; Wed, 3 Oct 2001 14:05:55 -0400 (EDT)
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 OAA23816
	for ; Wed, 3 Oct 2001 14:05:46 -0400 (EDT)
Received: (from petkos@localhost)
	by diamond.cs.columbia.edu (8.9.3+Sun/8.9.3) id OAA21187
	for simple@mailman.dynamicsoft.com; Wed, 3 Oct 2001 14:05:45 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110031805.OAA21187@diamond.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Wed, 3 Oct 2001 14:05:45 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1721
Subject: [Simple] Consensus on INVITE-established IM
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: 


Great that we finally have a consensus on that.
Now to the IM transport issue..

There are several possible transports for IM sessions.
IM transport has to be defined in SDP (probably in m line).

I'd like to continue at least with SIP MESSAGE (over TCP).
The message format is ready, parsers are widely
available and interop tested. Also, any new format
would be very similar to SIP MESSAGE format anyway
(To, From, Content-Type etc are needed in any case).
This is also something which can hopefully be finalized asap
without waiting 2 years and re-inventing SIP MESSAGE with
slightly different syntax.

SIP MESSAGE session draft is already work-in-progress.
Wouldn't it make sense to finalize it with TCP-only statement ?

It seems that there already is a wide support for using
MESSAGE as an IM transport. Do we have a consensus on that?

It is probably good idea to have consensus on that first.
If there is a consensus on that, then it is time to discuss
the details, e.g:
- associating MESSAGE with later session or not 
- direct e2e vs. via proxies etc
- compression signaling
etc


--
Petri



             
From: "Peterson, Jon"          
To:     "'simple@mailman.dynamicsoft.com'"                      
Subject:     [Simple] Consensus on INVITE-established IM        


It sounds like pretty much no one out there is vehemently opposed to the
concept of INVITE-established IM sessions (independent of what, exactly, the
transport for these IM will be), and that a rough consensus supports this
protocol concept. If there is in fact any new argument to be made for
excluding this concept, this would be a good time for someone to raise it.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

From akristensen@dynamicsoft.com  Wed Oct  3 15:05:59 2001
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 PAA22497
	for ; Wed, 3 Oct 2001 15:05:59 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.156])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f93J4B8P013374;
	Wed, 3 Oct 2001 15:04:11 -0400 (EDT)
Message-ID: <3BBB616B.51FACC84@dynamicsoft.com>
Date: Wed, 03 Oct 2001 15:05:15 -0400
From: Anders Kristensen 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Petri K. Koskelainen" 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport
References: <200110031805.OAA21187@diamond.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 775
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: 


"Petri K. Koskelainen" wrote:
> 
> Great that we finally have a consensus on that.
> Now to the IM transport issue..
> 
> There are several possible transports for IM sessions.
> IM transport has to be defined in SDP (probably in m line).
> 
> I'd like to continue at least with SIP MESSAGE (over TCP).
> The message format is ready, parsers are widely
> available and interop tested. Also, any new format
> would be very similar to SIP MESSAGE format anyway
> (To, From, Content-Type etc are needed in any case).

Umm, no. If the IM session has already been negotiated through an INVITE
there's no need to resend From and To in each MESSAGE. Seems to me that
only the ability to transport MIME bodies is really needed -- basically
MIME with the Content-* headers.

Anders

From hgs@cs.columbia.edu  Wed Oct  3 15:11:27 2001
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22539
	for ; Wed, 3 Oct 2001 15:11:26 -0400 (EDT)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA11512;
	Wed, 3 Oct 2001 15:11:14 -0400 (EDT)
Message-ID: <3BBB62D1.21C42662@cs.columbia.edu>
Date: Wed, 03 Oct 2001 15:11:13 -0400
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen 
CC: "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport
References: <200110031805.OAA21187@diamond.cs.columbia.edu> <3BBB616B.51FACC84@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 989
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: 

Anders Kristensen wrote:
> 
> "Petri K. Koskelainen" wrote:
> >
> > Great that we finally have a consensus on that.
> > Now to the IM transport issue..
> >
> > There are several possible transports for IM sessions.
> > IM transport has to be defined in SDP (probably in m line).
> >
> > I'd like to continue at least with SIP MESSAGE (over TCP).
> > The message format is ready, parsers are widely
> > available and interop tested. Also, any new format
> > would be very similar to SIP MESSAGE format anyway
> > (To, From, Content-Type etc are needed in any case).
> 
> Umm, no. If the IM session has already been negotiated through an INVITE
> there's no need to resend From and To in each MESSAGE. Seems to me that
> only the ability to transport MIME bodies is really needed -- basically
> MIME with the Content-* headers.
> 

That is true only if the TCP connection serves exactly one IM session.
That may or may not be true.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From petkos@cs.columbia.edu  Wed Oct  3 15:13:37 2001
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 PAA22570
	for ; Wed, 3 Oct 2001 15:13:35 -0400 (EDT)
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 PAA28663;
	Wed, 3 Oct 2001 15:13:23 -0400 (EDT)
Received: (from petkos@localhost)
	by diamond.cs.columbia.edu (8.9.3+Sun/8.9.3) id PAA22898;
	Wed, 3 Oct 2001 15:13:22 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110031913.PAA22898@diamond.cs.columbia.edu>
Subject: Re: [Simple] IM transport
To: akristensen@dynamicsoft.com (Anders Kristensen)
Date: Wed, 3 Oct 2001 15:13:22 -0400 (EDT)
Cc: petkos@cs.columbia.edu (Petri K. Koskelainen),
        simple@mailman.dynamicsoft.com
In-Reply-To: <3BBB616B.51FACC84@dynamicsoft.com> from "Anders Kristensen" at Oct 03, 2001 03:05:15 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 670
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: 

> > would be very similar to SIP MESSAGE format anyway
> > (To, From, Content-Type etc are needed in any case).
> 
> Umm, no. If the IM session has already been negotiated through an INVITE
> there's no need to resend From and To in each MESSAGE. Seems to me that
> only the ability to transport MIME bodies is really needed -- basically
> MIME with the Content-* headers.
> 

Actually, I think they are useful in many cases.
For example, multi-party chat in which you have a session
with the group server does not identify the sender of
the message. You may want to know whether Bob or Tim sent 
the message instead of knowing that it was sent by ServerXYZ.


--
Petri

From akristensen@dynamicsoft.com  Wed Oct  3 15:38:40 2001
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 PAA22690
	for ; Wed, 3 Oct 2001 15:38:40 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.156])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f93Jas8P013998;
	Wed, 3 Oct 2001 15:36:54 -0400 (EDT)
Message-ID: <3BBB6916.246FF3A1@dynamicsoft.com>
Date: Wed, 03 Oct 2001 15:37:58 -0400
From: Anders Kristensen 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Petri K. Koskelainen" ,
        Henning Schulzrinne 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport
References: <200110031913.PAA22898@diamond.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1241
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: 

Fair enough. Yours and Hennings points are well taken. Still, adding
sender identification is a far cry from full fledged SIP. Presumably
there's no need to send responses, to add Vias, to have CSeqs, to do
routing, loop detection, retransmissions etc. etc.  If all that stuff
goes we're arguably not even talking about SIP any longer.

Anders


"Petri K. Koskelainen" wrote:
> 
> > > would be very similar to SIP MESSAGE format anyway
> > > (To, From, Content-Type etc are needed in any case).
> >
> > Umm, no. If the IM session has already been negotiated through an INVITE
> > there's no need to resend From and To in each MESSAGE. Seems to me that
> > only the ability to transport MIME bodies is really needed -- basically
> > MIME with the Content-* headers.
> >
> 
> Actually, I think they are useful in many cases.
> For example, multi-party chat in which you have a session
> with the group server does not identify the sender of
> the message. You may want to know whether Bob or Tim sent
> the message instead of knowing that it was sent by ServerXYZ.
> 
> --
> Petri
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From petkos@cs.columbia.edu  Wed Oct  3 15:46:18 2001
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 PAA22757
	for ; Wed, 3 Oct 2001 15:46:17 -0400 (EDT)
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 PAA01241;
	Wed, 3 Oct 2001 15:46:07 -0400 (EDT)
Received: (from petkos@localhost)
	by diamond.cs.columbia.edu (8.9.3+Sun/8.9.3) id PAA23246;
	Wed, 3 Oct 2001 15:46:07 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110031946.PAA23246@diamond.cs.columbia.edu>
Subject: Re: [Simple] IM transport
To: akristensen@dynamicsoft.com (Anders Kristensen)
Date: Wed, 3 Oct 2001 15:46:07 -0400 (EDT)
Cc: petkos@cs.columbia.edu (Petri K. Koskelainen),
        schulzrinne@cs.columbia.edu (Henning Schulzrinne),
        simple@mailman.dynamicsoft.com
In-Reply-To: <3BBB6916.246FF3A1@dynamicsoft.com> from "Anders Kristensen" at Oct 03, 2001 03:37:58 PM
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 669
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: 

> Fair enough. Yours and Hennings points are well taken. Still, adding
> sender identification is a far cry from full fledged SIP. Presumably
> there's no need to send responses, to add Vias, to have CSeqs, to do
> routing, loop detection, retransmissions etc. etc.  If all that stuff
> goes we're arguably not even talking about SIP any longer.
> 

Hmm, we need responses (with the server) and retransmissions.
Having reliable TCP does not mean that we can forget application
level responses.
Also, MESSAGEs may traverse proxies so you probably
need Vias etc.

Basically, it is still a standard SIP transaction
even if it has been established with INVITE.


--
Petri

From hgs@cs.columbia.edu  Wed Oct  3 15:51:31 2001
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22808
	for ; Wed, 3 Oct 2001 15:51:30 -0400 (EDT)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA13844;
	Wed, 3 Oct 2001 15:51:09 -0400 (EDT)
Message-ID: <3BBB6C2D.B22B4B25@cs.columbia.edu>
Date: Wed, 03 Oct 2001 15:51:09 -0400
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen 
CC: "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport
References: <200110031913.PAA22898@diamond.cs.columbia.edu> <3BBB6916.246FF3A1@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 819
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: 

Anders Kristensen wrote:
> 
> Fair enough. Yours and Hennings points are well taken. Still, adding
> sender identification is a far cry from full fledged SIP. Presumably
> there's no need to send responses, to add Vias, to have CSeqs, to do
> routing, loop detection, retransmissions etc. etc.  If all that stuff
> goes we're arguably not even talking about SIP any longer.
> 

As long as it's a valid SIP message, even a subset, you can re-use
existing parsers and existing specifications. This also makes message
relaying from UDP (paging mode) to TCP much easier. 

Thus, while I wouldn't want to require that the MESSAGE-on-TCP has full
SIP headers, it should be permissible to stick a full page-mode MESSAGE
into TCP without the receiver losing its lunch.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From Avshalom@ubique.com  Wed Oct  3 16:26:37 2001
Received: from ubqgate02.lotus.com (outbound-pat-address.lotus.co.uk [194.196.39.50])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22949;
	Wed, 3 Oct 2001 16:26:35 -0400 (EDT)
From: Avshalom@ubique.com
Subject: Re: [Simple] IM transport
To: "Henning G. Schulzrinne" 
Cc: Anders Kristensen ,
        "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Wed, 3 Oct 2001 22:24:59 +0200
X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at
 03/10/2001 22:25:17
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 3507
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: 

I wish we could forget about this but what about the IESG requirement sent
by Jon Paterson at 20 August 2001:

<<<
The IESG has some concerns that this mechanism constitutes the use of SIP
as a transport protocol. In other words, once the session has been
established
between the two endpoints by the INVITE, if the MESSAGEs can only go
directly end-to-end, then their headers and related protocol apparatus are
entirely superfluous and may do more harm than good. We saw during the
meeting last week that there were definitely some pitfalls to allowing
methods other than MESSAGE across the IM stream (as well as questions about
overlapping transactions, redirection, forking, and so forth), and it isn't
clear that the overhead is justified if MESSAGE is just an envelope for its
encapsulated MIME payload. The IESG was particularly concerned, in addition
to the protocol overhead, with congestion characteristics of the messaging
session and with the precedent that could be set by using SIP in this
fashion.
>>>

I am not sure what will be considered as superfluous headers.

avshalom
Sametime/Lotus/IBM



                                                                                                                                
                    "Henning G. Schulzrinne"                                                                                    
                                 To:     Anders Kristensen                    
                    Sent by:                          cc:     "Petri K. Koskelainen" ,                  
                    simple-admin@mailman.dynam        simple@mailman.dynamicsoft.com                                            
                    icsoft.com                        Subject:     Re: [Simple] IM transport                                    
                                                                                                                                
                                                                                                                                
                    03/10/2001 21:51                                                                                            
                                                                                                                                
                                                                                                                                



Anders Kristensen wrote:
>
> Fair enough. Yours and Hennings points are well taken. Still, adding
> sender identification is a far cry from full fledged SIP. Presumably
> there's no need to send responses, to add Vias, to have CSeqs, to do
> routing, loop detection, retransmissions etc. etc.  If all that stuff
> goes we're arguably not even talking about SIP any longer.
>

As long as it's a valid SIP message, even a subset, you can re-use
existing parsers and existing specifications. This also makes message
relaying from UDP (paging mode) to TCP much easier.

Thus, while I wouldn't want to require that the MESSAGE-on-TCP has full
SIP headers, it should be permissible to stick a full page-mode MESSAGE
into TCP without the receiver losing its lunch.
--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple





From bcampbell@dynamicsoft.com  Wed Oct  3 16:54:23 2001
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 QAA23065
	for ; Wed, 3 Oct 2001 16:54:22 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f93Knfi01800;
	Wed, 3 Oct 2001 15:49:42 -0500
Message-ID: <3BBB79E5.9030508@dynamicsoft.com>
Date: Wed, 03 Oct 2001 15:49:41 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Anders Kristensen 
CC: "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport
References: <200110031805.OAA21187@diamond.cs.columbia.edu> <3BBB616B.51FACC84@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1555
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: 

Right. And there is a lot of other stuff in a SIP message that are not 
needed in an IM session negotiated with an INVITE.

We had previous discussion of using message/cpim directly. Since the 
message/cpim format allows for metadata that includes to and from 
information, it seems to fit.

Additionally, it provides for end-to-end signatures and encryption, 
which could be very nice to have.

So, as a concrete counter-proposal to MESSAGE over TCP, I propose CPIM 
over TCP (or TLS, SCTP, etc.)

Is there any strong reason why it can't work (and MESSAGE can)?



Anders Kristensen wrote:

> 
> "Petri K. Koskelainen" wrote:
> 
>>Great that we finally have a consensus on that.
>>Now to the IM transport issue..
>>
>>There are several possible transports for IM sessions.
>>IM transport has to be defined in SDP (probably in m line).
>>
>>I'd like to continue at least with SIP MESSAGE (over TCP).
>>The message format is ready, parsers are widely
>>available and interop tested. Also, any new format
>>would be very similar to SIP MESSAGE format anyway
>>(To, From, Content-Type etc are needed in any case).
>>
> 
> Umm, no. If the IM session has already been negotiated through an INVITE
> there's no need to resend From and To in each MESSAGE. Seems to me that
> only the ability to transport MIME bodies is really needed -- basically
> MIME with the Content-* headers.
> 
> Anders
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 




From bcampbell@dynamicsoft.com  Wed Oct  3 17:25:08 2001
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 RAA23204
	for ; Wed, 3 Oct 2001 17:25:07 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f93LKdi01830;
	Wed, 3 Oct 2001 16:20:39 -0500
Message-ID: <3BBB8127.3020907@dynamicsoft.com>
Date: Wed, 03 Oct 2001 16:20:39 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Peterson, Jon" 
CC: "'simple@mailman.dynamicsoft.com'" 
Subject: Re: [Simple] Consensus on INVITE-established IM
References: <70565611B164D511957A001083FCDD56478B31@va02.va.neustar.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1208
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: 

We seem to have concensus on that point.

I do have a requirements question, though: If we _do_ have a concept of 
INVITE-established IM sessions, does that session have to be able to 
cross a CPIM compliant gateway, perhaps to another protocol that does 
not support sessions?

My first reaction is to say yes, but I can think of a lot of strangeness 
here. For example, if I think I am end a session, but the opposite 
end-point does not know about sessions, how can it send me a message 
that is part of the session? How can it send me a message that is _not_ 
part of the session?



Peterson, Jon wrote:

> It sounds like pretty much no one out there is vehemently opposed to the
> concept of INVITE-established IM sessions (independent of what, exactly, the
> transport for these IM will be), and that a rough consensus supports this
> protocol concept. If there is in fact any new argument to be made for
> excluding this concept, this would be a good time for someone to raise it.
> 
> Jon Peterson
> NeuStar, Inc
> SIMPLE co-chair
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 




From pkyzivat@cisco.com  Wed Oct  3 18:48:23 2001
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 SAA23487
	for ; Wed, 3 Oct 2001 18:48:23 -0400 (EDT)
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 f93MlUA01303;
	Wed, 3 Oct 2001 18:47:33 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB35172 (AUTH pkyzivat);
	Wed, 3 Oct 2001 18:49:29 -0400 (EDT)
Message-ID: <3BBB954A.2F1EBA8B@cisco.com>
Date: Wed, 03 Oct 2001 18:46:34 -0400
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: "Henning G. Schulzrinne" 
CC: Anders Kristensen ,
        "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport
References: <200110031805.OAA21187@diamond.cs.columbia.edu> <3BBB616B.51FACC84@dynamicsoft.com> <3BBB62D1.21C42662@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2872
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: 

Some questions about using SIP as a transport for MESSAGE sessions...

Does this mean establishing or reusing a sip tcp connection to an
address specified in SDP, using a port that is potentially shared with
other message sessions and other sip signaling, or to a port dedicated
to this message session?

Dedicating a port must be wrong - it eliminates many of the potential
advantages of the approach, such as firewall penetration. So I presume
it must be a shared server, probably running on a well known port,
serving possibly several message streams, and probably standard sip
signalling as well.

If so, how can individual sessions be distinguished at the server? I
think the answer is that they must be assigned sip addresses with unique
user parts. So, if my normal sip address is
sip:pkyzivat@kyzivat.cisco.com, then perhaps my message sessions will be
addressed to sip:pkyzivat.NNN@kyzivat.cisco.com. There need not be any
standard way to do this - it is up to the UA to figure out when
processing the invitation - but something of this sort seems
appropriate.

Next, if one of the goals is to do the media point-to-point in order to
avoid swamping proxies with media traffic, how do we ensure that this
happens? Suppose a UA normally uses an outbound proxy - must it bypass
this and establish a sip tcp connection directly to the other endpoint?

What about firewall problems? In which direction is the tcp connection
established? Do we follow the comedia draft? (It has expired, so it will
need to be revived, and extended to support sip as a transport.)

So many problems, so little time! :-)

	Paul Kyzivat
	Cisco Systems

"Henning G. Schulzrinne" wrote:
> 
> Anders Kristensen wrote:
> >
> > "Petri K. Koskelainen" wrote:
> > >
> > > Great that we finally have a consensus on that.
> > > Now to the IM transport issue..
> > >
> > > There are several possible transports for IM sessions.
> > > IM transport has to be defined in SDP (probably in m line).
> > >
> > > I'd like to continue at least with SIP MESSAGE (over TCP).
> > > The message format is ready, parsers are widely
> > > available and interop tested. Also, any new format
> > > would be very similar to SIP MESSAGE format anyway
> > > (To, From, Content-Type etc are needed in any case).
> >
> > Umm, no. If the IM session has already been negotiated through an INVITE
> > there's no need to resend From and To in each MESSAGE. Seems to me that
> > only the ability to transport MIME bodies is really needed -- basically
> > MIME with the Content-* headers.
> >
> 
> That is true only if the TCP connection serves exactly one IM session.
> That may or may not be true.
> 
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From jon.peterson@NeuStar.com  Wed Oct  3 19:44:34 2001
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23679
	for ; Wed, 3 Oct 2001 19:44:33 -0400 (EDT)
Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f93NhKq03074;
	Wed, 3 Oct 2001 19:43:35 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 3 Oct 2001 18:41:52 -0500
Message-ID: <70565611B164D511957A001083FCDD56478B46@va02.va.neustar.com>
From: "Peterson, Jon" 
To: "'Petri K. Koskelainen'" ,
        akristensen@dynamicsoft.com
Cc: schulzrinne@cs.columbia.edu, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM transport
Date: Wed, 3 Oct 2001 18:41:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2317
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: 

A note about the 'MESSAGEs may traverse proxies so you probably need Vias
etc.' comment below.

I don't think the consenus to use INVITEs to establish sessions entails a
requirement that the session transport protocol used for the conveyence of
IMs can or should be sent through SIP proxy servers (and moreover that SIP
proxy servers would need to access headers to route IMs). 

Some time ago Jonathan sent out a list of requirements for this transport
protocol:

http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000583.html

I would suggest that we revisit these criteria to make sure this is what
we're looking for (I recall that conferencing was added as a requirement to
this list) and then attempt to find a protocol that satisfies these
requirements.

Initially I see no reason why all of the apparatus of SIP headers, much of
which is used for message routing, should be necessary in the transport
protocol. If we really need SIP proxies to route IMs, we should be sending
them in paging mode. The point of having an alternative to paging mode was,
as I understood it, precisely to enjoy the benefits of -not- sending IMs
through proxy servers.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

-----Original Message-----
From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
Sent: Wednesday, October 03, 2001 12:46 PM
To: akristensen@dynamicsoft.com
Cc: petkos@cs.columbia.edu; schulzrinne@cs.columbia.edu;
simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport



> Fair enough. Yours and Hennings points are well taken. Still, adding
> sender identification is a far cry from full fledged SIP. Presumably
> there's no need to send responses, to add Vias, to have CSeqs, to do
> routing, loop detection, retransmissions etc. etc.  If all that stuff
> goes we're arguably not even talking about SIP any longer.
> 

Hmm, we need responses (with the server) and retransmissions.
Having reliable TCP does not mean that we can forget application
level responses.
Also, MESSAGEs may traverse proxies so you probably
need Vias etc.

Basically, it is still a standard SIP transaction
even if it has been established with INVITE.


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

From jdrosen@dynamicsoft.com  Wed Oct  3 20:05:22 2001
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 UAA23798
	for ; Wed, 3 Oct 2001 20:05:22 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9403a8P016243;
	Wed, 3 Oct 2001 20:03:36 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SM05Y>; Wed, 3 Oct 2001 20:04:40 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Peterson, Jon'" ,
        "'Petri K. Koskelainen'"
	 ,
        Anders Kristensen
	 
Cc: schulzrinne@cs.columbia.edu, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM transport
Date: Wed, 3 Oct 2001 20:04:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2892
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: 


 

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.com]
> Sent: Wednesday, October 03, 2001 7:42 PM
> To: 'Petri K. Koskelainen'; akristensen@dynamicsoft.com
> Cc: schulzrinne@cs.columbia.edu; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] IM transport
> 
> Some time ago Jonathan sent out a list of requirements for 
> this transport
> protocol:
> 
> http://mailman.dynamicsoft.com/pipermail/simple/2001-August/00
> 0583.html
> 
> I would suggest that we revisit these criteria to make sure 
> this is what
> we're looking for (I recall that conferencing was added as a 
> requirement to
> this list) and then attempt to find a protocol that satisfies these
> requirements.

I agree. It will really help, I think.

Some more to add based on list discussions:

* must support transport intermediaries for firewall traversal
* must support multiplexed transport of messages over shared connections
between intermediaries
* must provide an identification of the originator
* e2e acknowledgement of message receipt (question: do we really need this?
CPIM requires it, but its really meant for the paging model, not the session
model)


> Initially I see no reason why all of the apparatus of SIP 
> headers, much of
> which is used for message routing, should be necessary in the 
> transport
> protocol. If we really need SIP proxies to route IMs, we 
> should be sending
> them in paging mode. The point of having an alternative to 
> paging mode was,
> as I understood it, precisely to enjoy the benefits of -not- 
> sending IMs
> through proxy servers.

Well, thats one benefit. THe primary benefit is that wrapping things in
INVITE/BYE provides the ability to use other SIP mechanisms for IM - things
like refer, conferencing, etc.

Its also worth considering which SIP features "get in the way" of what we
want to do for IM transport. Assume we go with the idea of sending the IMs
as MESSAGEs within the call leg, with some kind of SDP indicator of doing
this. What limitations are introduced?

One clear one is throughput. non-INVITE requests are limited to one per RTT
at best, since you can't initiate a second non-INVITE transaction within a
call leg while one is in progress. Large IM will also affect call setup
times of other things going through the proxies. Proxies are likely to
record-route INVITE not just for firewall traversal, but for features. These
proxies wouldn't normally want to see an IM. THe result is increased latency
for IMs, and increased load on proxies.

-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

From jon.peterson@NeuStar.com  Wed Oct  3 20:10:25 2001
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23843
	for ; Wed, 3 Oct 2001 20:10:25 -0400 (EDT)
Received: from chi02.npac.com (dmz1.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f9409Sq07554;
	Wed, 3 Oct 2001 20:09:43 -0400
Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 3 Oct 2001 19:10:03 -0500
Message-ID: <70565611B164D511957A001083FCDD56478B47@va02.va.neustar.com>
From: "Peterson, Jon" 
To: "'Ben Campbell'" 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Consensus on INVITE-established IM
Date: Wed, 3 Oct 2001 19:07:49 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2142
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: 

I don't think 'sessions' need to cross CPIM boundaries, because there is no
requirement for CPIM protocols to have a concept of a session (as we are
using the term) and we can therefore safely assume that some such protocols
will not.

What this does entail is a potential requirement for CPIM gateways to keep
state information associated with an INVITE-established session in order to
transmit the complete context of the session with each instant message that
it relays. Of course, this requirement only would apply if the information
contained in each session-based IM did not provide sufficient information,
on its own, to construct a CPIM message.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
Sent: Wednesday, October 03, 2001 2:21 PM
To: Peterson, Jon
Cc: 'simple@mailman.dynamicsoft.com'
Subject: Re: [Simple] Consensus on INVITE-established IM


We seem to have concensus on that point.

I do have a requirements question, though: If we _do_ have a concept of 
INVITE-established IM sessions, does that session have to be able to 
cross a CPIM compliant gateway, perhaps to another protocol that does 
not support sessions?

My first reaction is to say yes, but I can think of a lot of strangeness 
here. For example, if I think I am end a session, but the opposite 
end-point does not know about sessions, how can it send me a message 
that is part of the session? How can it send me a message that is _not_ 
part of the session?



Peterson, Jon wrote:

> It sounds like pretty much no one out there is vehemently opposed to the
> concept of INVITE-established IM sessions (independent of what, exactly,
the
> transport for these IM will be), and that a rough consensus supports this
> protocol concept. If there is in fact any new argument to be made for
> excluding this concept, this would be a good time for someone to raise it.
> 
> Jon Peterson
> NeuStar, Inc
> SIMPLE co-chair
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 



From Gur_Kimchi@vocaltec.com  Wed Oct  3 15:44:02 2001
Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22732
	for ; Wed, 3 Oct 2001 15:44:02 -0400 (EDT)
From: Gur_Kimchi@vocaltec.com
Subject: Re: [Simple] IM transport
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: 
Date: Wed, 3 Oct 2001 15:35:48 -0500
X-MIMETrack: Serialize by Router on USNIMO/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 10/03/2001 03:35:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 604
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: 

Anders wrote:

>> Umm, no. If the IM session has already been negotiated through an INVITE
>> there's no need to resend From and To in each MESSAGE. Seems to me that
>> only the ability to transport MIME bodies is really needed -- basically
>> MIME with the Content-* headers.

well for multi-person sessions via a Proxies you will need at least the

unless you base user-recognition on network layer information which is not
a
good idea.

I would recommend that we keep the MESSAGE-over-TCP stream as close as
possible
to MESSAGE-over-SIP, its the same software handling both after all.

- gur




From hgs@cs.columbia.edu  Wed Oct  3 22:47:12 2001
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 WAA24363
	for ; Wed, 3 Oct 2001 22:47:12 -0400 (EDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA04233;
	Wed, 3 Oct 2001 22:47:02 -0400 (EDT)
Received: from cs.columbia.edu (localhost [127.0.0.1])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id WAA10189;
	Wed, 3 Oct 2001 22:46:57 -0400 (EDT)
Message-ID: <3BBBCDAA.61D18685@cs.columbia.edu>
Date: Wed, 03 Oct 2001 22:47:06 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Peterson, Jon'" ,
        "'Petri K. Koskelainen'" ,
        Anders Kristensen ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1220
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: 

Paint me confused. I thought the point was that this was a session, but
over "plain" TCP and possibly in the future SCTP, not routed through SIP
proxies. Thus, it's SIP MESSAGE, but all the normal SIP routing headers
are ignored, if present (if we choose that format).

What you're saying below sounds like it's using the normal SIP message
forwarding.

> 
> Its also worth considering which SIP features "get in the way" of what we
> want to do for IM transport. Assume we go with the idea of sending the IMs
> as MESSAGEs within the call leg, with some kind of SDP indicator of doing
              ^^^^^^^^^^^^^^^^^^^
                 this is where my confusion comes in

> this. What limitations are introduced?
> 
> One clear one is throughput. non-INVITE requests are limited to one per RTT
> at best, since you can't initiate a second non-INVITE transaction within a
> call leg while one is in progress. Large IM will also affect call setup
> times of other things going through the proxies. Proxies are likely to
> record-route INVITE not just for firewall traversal, but for features. These
> proxies wouldn't normally want to see an IM. THe result is increased latency
> for IMs, and increased load on proxies.

From Dror@vocaltec.com  Thu Oct  4 05:57:05 2001
Received: from sumo.vocaltec.co.il (vocaltec.co.il [199.203.72.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25658
	for ; Thu, 4 Oct 2001 05:57:04 -0400 (EDT)
From: Dror@vocaltec.com
Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135])
	by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id LAA09063;
	Thu, 4 Oct 2001 11:55:45 +0200 (IST)
To: Anders Kristensen 
Cc: "Adam Roach (E-mail)" ,
        Avshalom Houri ,
        "'Jonathan Rosenberg'" ,
        "'Robert Brown'" ,
        "Sean Olson (EUS)" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Partial Notifies?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.6a  January 17, 2001
Message-ID: 
Date: Thu, 4 Oct 2001 11:52:56 +0200
X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 10/04/2001 11:52:54 AM,
	Serialize complete at 10/04/2001 11:52:54 AM
Content-Type: multipart/alternative; boundary="=_alternative 0036584A42256ADB_="
Content-Length: 17054
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: 

This is a multipart message in MIME format.
--=_alternative 0036584A42256ADB_=
Content-Type: text/plain; charset="us-ascii"

Actually, I'm concerened about using generic diff algorithm. It requires 
the server to build the entire document, and perform a diff operation to 
create the partial document to send to the client.
However, the "document" returned which requires this partial update us 
actually a list of items, updated at different times.
Thus, in most cases, the server can create a list of changed items without 
rebuilding the entire list.
e.g.: generating a list of all updated items since date X can be much 
simpler than fetching the entire list
In some situations, an update counter might be easier to use than "date of 
updates".

My suggestion for partial list:
1. whenever a server returns the list to the client, it also returns an 
"update-cookie". This cookie is treated as an opaque string.
2. whenever the client wants to update its local list, it will send this 
"update-cookie" to the server.
3. the server will see whether the cookie makes sense, and will try to 
return partial update of changes since the time the cookie was generated.
4. if the cookie denotes an up-to-date list, the server will return 
nothing
5. if the server fails to parse the cookie, it will return a full update 
to the client.
6. in any case, the server returns a new "update-cookie" to the client.

----------------------------------------------------------------
Dror Tirosh 
VocalTec Communications, Ltd
--------------------------------------------------------------





Anders Kristensen 
Sent by: simple-admin@mailman.dynamicsoft.com
03/10/2001 02:24

 
        To:     "Sean Olson (EUS)" 
        cc:     "'Jonathan Rosenberg'" , "'Robert Brown'" 
, Avshalom Houri , 
simple@mailman.dynamicsoft.com, "Adam Roach (E-mail)" 

        Subject:        Re: [Simple] Partial Notifies?




"Sean Olson (EUS)" wrote:
>
> I realize this has been pushed off to future work,
> but I thought I would throw my two cents in now.
> I think we could have a reasonable first draft
> of a partial NOTIFY mechanism completed in a
> couple of weeks.

Yup.

>
> >That sure sounds like way too much. The draft I had in mind was
> >http://www.ietf.org/internet-drafts/draft-mogul-http-delta-08.txt
> >
> >This details how various diff algorithms (textual or binary - the
> >mechanism works with either) can be used to reduce the message
> >size when
> >the client has an old version of some resource. It seems like it
> should
> >be fairly straightforward to apply the same ideas to SIP.
>
> I agree. This is much simpler. Can we make a baseline
> requirement for either vcdiff or gdiff? Both support
> binary data. gdiff seems simpler, but vcdiff supports
> compression. If I had to choose, I would mandate support
> for vcdiff.

I'd prefer a recommendation over a hard requirement for a particular
format/algorithm. I agree that vcdiff seems like the better choice.

>
> >So here's a sketch of how this might work in SIP.
> >
> >Clients would indicate support for one or more delta encoding
> >mechanisms
> >in SUBSCRIBEs by listing extension token 'delta' in a Supported
> header
> >and the actual "instance manipulations" supported in an A-IM header
> >(A-IM stands for Accept-Instance-Manipulations and is defined in the
> >http draft as is the IM header used in NOTIFYes):
> >
> >        SUBSCRIBE sip:presentity@pres.example.com SIP/2.0
> >        Supported: delta
> >        A-IM: diffe, vcdiff
> >        Event: presence
> >        ...
>
> Can we use the A-IM: header as an implicit indicator
> of support for delta encoding?

Sounds reasonable.

>
> >the server would make a note of supported alg's in the subscription
> >"record".
> >
> >The server then has to know what version of a particular subscription
>
> >doc a watcher has received, and when it sends a NOTIFY for a watcher
> it
> >may send only a delta if that guy has indicated support for it, e.g.:
>
> >
> >        NOTIFY sip:user@watcherhost.example.com SIP/2.0
> >        Require: delta
> >        IM: diffe
> >        Delta-Base: "abc"
> >        Etag: "ghi"
> >        Event: presence
> >        Content-Type: application/cpim-pidf+xml
> >
> >        ...
> >
> >Unlike the http case there's no request in which a version number/tag
>
> >can be carried so presumably the server has to just know what
> >version of
> >the presence doc (or whatever) the client knows about, or else assume
>
> >that it knows about the previous version.  If for some reason
> >the client
> >doesn't, it would return some error response which would tell
> >the server
> >to send the whole resource/document. The error response would also
> list
> >the A-IM and Supported header as appropriate.
>
> I assume we can do something like:
> SUBSCRIBE sip:presentity@pres.example.com?Etag="ghi" SIP/2.0
> to at least indicate what version the client has at the
> time of subscription. The first NOTIFY could then include
> either the full state or the appropriate delta encoding to
> bring the client in sync with the server. Or use a
> "If-None-Match:" header as in HTTP/1.1.

I like the idea of the client telling the server which version it has in
the SUBSCRIBE but I think it's preferable to put the version number in
an ETag header as in HTTP.

>
> I don't see a reason to return an error response to the server.
> Do a one-time SUBSCRIBE with no "A-IM" header instead. It costs
> two extra messages, but simplifies the life of the presence server.
>
> >
> >The Delta-Base header gives the version of the resource that the
> delta
> >should be applied to (and which the client is assumed to possess).
> The
> >ETag gives an identifier for the new resource.
>
> Sounds good.
>
> >
> >A presence server that doesn't know about the delta extension just
> >ignores the A-IM header and sends the full update every time.
>
> Sounds reasonable. Some things that need to be fleshed out include:
>
> 1) How would the server indicate in the initial NOTIFY that the
>    client state is already up-to-date? (HTTP 1.1 uses a
>    "304 Not Modified" response code. Do we want to do something
>    similar?) This would be particularly useful for a fetch operation.

It may be enough to send a NOTIFY with identical values in the ETag and
Delta-Base headers and an empty body (or whatever ).

>
> 2) Do we want to allow compression manipulations in addition to the
>    delta encoding? Or can we just apply Content-Encodings on top
>    of the delta encoding? I assume the later is fine.

I'm not sure why HTTP includes both but I see no reason for excluding
compressions. There's no requirement to support any, of course.

>
> /sean

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


--=_alternative 0036584A42256ADB_=
Content-Type: text/html; charset="us-ascii"



Actually, I'm concerened about using generic diff algorithm. It requires the server to build the entire document, and perform a diff operation to create the partial document to send to the client.

However, the "document" returned which requires this partial update us actually a list of items, updated at different times.

Thus, in most cases, the server can create a list of changed items without rebuilding the entire list.

e.g.: generating a list of all updated items since date X can be much simpler than fetching the entire list

In some situations, an update counter might be easier to use than "date of updates".



My suggestion for partial list:

1. whenever a server returns the list to the client, it also returns an "update-cookie". This cookie is treated as an opaque string.

2. whenever the client wants to update its local list, it will send this "update-cookie" to the server.

3. the server will see whether the cookie makes sense, and will try to return partial update of changes since the time the cookie was generated.

4. if the cookie denotes an up-to-date list, the server will return nothing

5. if the server fails to parse the cookie, it will return a full update to the client.

6. in any case, the server returns a new "update-cookie" to the client.



----------------------------------------------------------------

Dror Tirosh <dror@vocaltec.com>

VocalTec Communications, Ltd

--------------------------------------------------------------













Anders Kristensen <akristensen@dynamicsoft.com>

Sent by: simple-admin@mailman.dynamicsoft.com

03/10/2001 02:24



        

        To:        "Sean Olson (EUS)" <sean.olson@ericsson.com>

        cc:        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, "'Robert Brown'" <roberbr@microsoft.com>, Avshalom Houri <avshalom@ubique.com>, simple@mailman.dynamicsoft.com, "Adam Roach (E-mail)" <adam.roach@ericsson.com>

        Subject:        Re: [Simple] Partial Notifies?










"Sean Olson (EUS)" wrote:

>

> I realize this has been pushed off to future work,

> but I thought I would throw my two cents in now.

> I think we could have a reasonable first draft

> of a partial NOTIFY mechanism completed in a

> couple of weeks.



Yup.



>

> >That sure sounds like way too much. The draft I had in mind was

> >http://www.ietf.org/internet-drafts/draft-mogul-http-delta-08.txt

> >

> >This details how various diff algorithms (textual or binary - the

> >mechanism works with either) can be used to reduce the message

> >size when

> >the client has an old version of some resource. It seems like it

> should

> >be fairly straightforward to apply the same ideas to SIP.

>

> I agree. This is much simpler. Can we make a baseline

> requirement for either vcdiff or gdiff? Both support

> binary data. gdiff seems simpler, but vcdiff supports

> compression. If I had to choose, I would mandate support

> for vcdiff.



I'd prefer a recommendation over a hard requirement for a particular

format/algorithm. I agree that vcdiff seems like the better choice.



>

> >So here's a sketch of how this might work in SIP.

> >

> >Clients would indicate support for one or more delta encoding

> >mechanisms

> >in SUBSCRIBEs by listing extension token 'delta' in a Supported

> header

> >and the actual "instance manipulations" supported in an A-IM header

> >(A-IM stands for Accept-Instance-Manipulations and is defined in the

> >http draft as is the IM header used in NOTIFYes):

> >

> >        SUBSCRIBE sip:presentity@pres.example.com SIP/2.0

> >        Supported: delta

> >        A-IM: diffe, vcdiff

> >        Event: presence

> >        ...

>

> Can we use the A-IM: header as an implicit indicator

> of support for delta encoding?



Sounds reasonable.



>

> >the server would make a note of supported alg's in the subscription

> >"record".

> >

> >The server then has to know what version of a particular subscription

>

> >doc a watcher has received, and when it sends a NOTIFY for a watcher

> it

> >may send only a delta if that guy has indicated support for it, e.g.:

>

> >

> >        NOTIFY sip:user@watcherhost.example.com SIP/2.0

> >        Require: delta

> >        IM: diffe

> >        Delta-Base: "abc"

> >        Etag: "ghi"

> >        Event: presence

> >        Content-Type: application/cpim-pidf+xml

> >

> >        ...

> >

> >Unlike the http case there's no request in which a version number/tag

>

> >can be carried so presumably the server has to just know what

> >version of

> >the presence doc (or whatever) the client knows about, or else assume

>

> >that it knows about the previous version.  If for some reason

> >the client

> >doesn't, it would return some error response which would tell

> >the server

> >to send the whole resource/document. The error response would also

> list

> >the A-IM and Supported header as appropriate.

>

> I assume we can do something like:

> SUBSCRIBE sip:presentity@pres.example.com?Etag="ghi" SIP/2.0

> to at least indicate what version the client has at the

> time of subscription. The first NOTIFY could then include

> either the full state or the appropriate delta encoding to

> bring the client in sync with the server. Or use a

> "If-None-Match:" header as in HTTP/1.1.



I like the idea of the client telling the server which version it has in

the SUBSCRIBE but I think it's preferable to put the version number in

an ETag header as in HTTP.



>

> I don't see a reason to return an error response to the server.

> Do a one-time SUBSCRIBE with no "A-IM" header instead. It costs

> two extra messages, but simplifies the life of the presence server.

>

> >

> >The Delta-Base header gives the version of the resource that the

> delta

> >should be applied to (and which the client is assumed to possess).

> The

> >ETag gives an identifier for the new resource.

>

> Sounds good.

>

> >

> >A presence server that doesn't know about the delta extension just

> >ignores the A-IM header and sends the full update every time.

>

> Sounds reasonable. Some things that need to be fleshed out include:

>

> 1) How would the server indicate in the initial NOTIFY that the

>    client state is already up-to-date? (HTTP 1.1 uses a

>    "304 Not Modified" response code. Do we want to do something

>    similar?) This would be particularly useful for a fetch operation.



It may be enough to send a NOTIFY with identical values in the ETag and

Delta-Base headers and an empty body (or whatever ).



>

> 2) Do we want to allow compression manipulations in addition to the

>    delta encoding? Or can we just apply Content-Encodings on top

>    of the delta encoding? I assume the later is fine.



I'm not sure why HTTP includes both but I see no reason for excluding

compressions. There's no requirement to support any, of course.



>

> /sean



Anders

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple




--=_alternative 0036584A42256ADB_=--

From Avshalom@ubique.com  Thu Oct  4 06:37:10 2001
Received: from ubqgate02.lotus.com ([194.196.39.199])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25810
	for ; Thu, 4 Oct 2001 06:37:06 -0400 (EDT)
From: Avshalom@ubique.com
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Thu, 4 Oct 2001 12:34:58 +0200
X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at
 04/10/2001 12:35:50
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 538
Subject: [Simple] IM over the signaling connection
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: 

It seems that the possibility of sending MESSAGEs of sessions over the
signaling connection is being ignored.
I am not sure that there is a consensus not to use it.

It think that we can agree on sending MESSAGEs of sessions on the control
connection. We should keep the
header of the MESSAGEs to a necessary minimum and agree on a maximum length
of MESSAGEs to be sent
on the signaling connection. Given this, the impact on the control
connection will not be different from a one time
MESSAGE and NOTIFYs.

avshalom
Sametime/Lotus/IBM



From pkyzivat@cisco.com  Thu Oct  4 09:10:02 2001
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 JAA26303
	for ; Thu, 4 Oct 2001 09:10:02 -0400 (EDT)
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 f94D9AC21121;
	Thu, 4 Oct 2001 09:09:10 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB36986 (AUTH pkyzivat);
	Thu, 4 Oct 2001 09:11:08 -0400 (EDT)
Message-ID: <3BBC5F3C.7E7D033B@cisco.com>
Date: Thu, 04 Oct 2001 09:08:12 -0400
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: "'Peterson, Jon'" ,
        "'Petri K. Koskelainen'" ,
        Anders Kristensen ,
        schulzrinne@cs.columbia.edu, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1248
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: 


Jonathan Rosenberg wrote:
>
[snip] 
> Some more to add based on list discussions:
> 
> * must support transport intermediaries for firewall traversal
> * must support multiplexed transport of messages over shared connections
> between intermediaries
> * must provide an identification of the originator
> * e2e acknowledgement of message receipt (question: do we really need this?
> CPIM requires it, but its really meant for the paging model, not the session
> model)

I think the last is needed, at least optionally. Especially consider a
case of an IM conference. It may be important to know when everyone in
the conference has received your message. This could be especially true
if you are sending something other than text messages (e.g. graphics).

Consider a conference involving both voice and IM media, where the IM is
used to deliver slides and the voice channel is used to discuss them.
You might like to know that a slide has been received by all parties
before beginning to talk about it.

e2e acknowledgement can provide this if the conference server manages
the acknowledgements properly. This could be a policy in the server. A
different (store and forward) policy would ack before distributing when
e2e is not important.

	Paul

From rrroy@att.com  Thu Oct  4 10:18:09 2001
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 KAA26530
	for ; Thu, 4 Oct 2001 10:18:09 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f94EHB329655;
	Thu, 4 Oct 2001 10:17:19 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id KAA21126; Thu, 4 Oct 2001 10:15:46 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 4 Oct 2001 10:17:07 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Paul Kyzivat ,
        Jonathan Rosenberg
	 
Cc: "'Peterson, Jon'" ,
        "'Petri K. Koskelainen'"
	 ,
        Anders Kristensen
	 ,
        schulzrinne@cs.columbia.edu, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM transport
Date: Thu, 4 Oct 2001 10:16:53 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 648
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: 

My comments as stated below [RRR]:

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Thursday, October 04, 2001 9:08 AM

....

e2e acknowledgement can provide this if the conference server manages
the acknowledgements properly. This could be a policy in the server. A
different (store and forward) policy would ack before distributing when
e2e is not important.

[RRR] If "message" is sent as "media" on e2e after establishing the session,
does the Ack not to be taken care of by the transport protocol itself (e.g.,
TCP)? (For signaling part, SIP's ACK is already taken care-of, I guess.) Am
I missing something?

	

From bcampbell@dynamicsoft.com  Thu Oct  4 11:29:01 2001
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 LAA26770
	for ; Thu, 4 Oct 2001 11:29:00 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f94FO5i02540;
	Thu, 4 Oct 2001 10:24:05 -0500
Message-ID: <3BBC7F15.30102@dynamicsoft.com>
Date: Thu, 04 Oct 2001 10:24:05 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Peterson, Jon" 
CC: "'simple@mailman.dynamicsoft.com'" 
Subject: Re: [Simple] Consensus on INVITE-established IM
References: <70565611B164D511957A001083FCDD56478B47@va02.va.neustar.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1357
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: 

Peterson, Jon wrote:

> I don't think 'sessions' need to cross CPIM boundaries, because there is no
> requirement for CPIM protocols to have a concept of a session (as we are
> using the term) and we can therefore safely assume that some such protocols
> will not.
> 
> What this does entail is a potential requirement for CPIM gateways to keep
> state information associated with an INVITE-established session in order to
> transmit the complete context of the session with each instant message that
> it relays. Of course, this requirement only would apply if the information
> contained in each session-based IM did not provide sufficient information,
> on its own, to construct a CPIM message.


That is one option. Another would be to say the gateway in its simplist 
form just does not accept INVITES. That is, treat IM sessions as 
optional to implement. This could save us a lot of trouble with dealing 
with the semantics of gatewaying between a session on one side and no 
session on the other. It might also remove requirements for responses to 
in-session messages over a reliable transport.

I do not think the messages inside a session should have enough info to 
construct a CPIM message. If in-session messages must cross a gateway, 
then we must establish a session with that gateway.


> 
> Jon Peterson
> NeuStar, Inc
> SIMPLE co-chair



From bcampbell@dynamicsoft.com  Thu Oct  4 11:33:18 2001
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 LAA26808
	for ; Thu, 4 Oct 2001 11:33:18 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f94FSLi02544;
	Thu, 4 Oct 2001 10:28:21 -0500
Message-ID: <3BBC8014.9040707@dynamicsoft.com>
Date: Thu, 04 Oct 2001 10:28:21 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Avshalom@ubique.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 867
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: 

It is not so much that it is being ignored as that the IESG has told us 
they will not approve it.


Avshalom@ubique.com wrote:

> It seems that the possibility of sending MESSAGEs of sessions over the
> signaling connection is being ignored.
> I am not sure that there is a consensus not to use it.
> 
> It think that we can agree on sending MESSAGEs of sessions on the control
> connection. We should keep the
> header of the MESSAGEs to a necessary minimum and agree on a maximum length
> of MESSAGEs to be sent
> on the signaling connection. Given this, the impact on the control
> connection will not be different from a one time
> MESSAGE and NOTIFYs.
> 
> avshalom
> Sametime/Lotus/IBM
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 




From pkyzivat@cisco.com  Thu Oct  4 11:49:41 2001
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 LAA26889
	for ; Thu, 4 Oct 2001 11:49:41 -0400 (EDT)
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 f94FmpC02648;
	Thu, 4 Oct 2001 11:48:51 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB38477 (AUTH pkyzivat);
	Thu, 4 Oct 2001 11:50:49 -0400 (EDT)
Message-ID: <3BBC84A8.BAF2775E@cisco.com>
Date: Thu, 04 Oct 2001 11:47:52 -0400
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: "Roy, Radhika R, ALCTA" 
CC: Jonathan Rosenberg ,
        "'Peterson, Jon'" ,
        "'Petri K. Koskelainen'" ,
        Anders Kristensen ,
        schulzrinne@cs.columbia.edu, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM transport
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1506
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: 


"Roy, Radhika R, ALCTA" wrote:
> 
> My comments as stated below [RRR]:
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, October 04, 2001 9:08 AM
> 
> ....
> 
> e2e acknowledgement can provide this if the conference server manages
> the acknowledgements properly. This could be a policy in the server. A
> different (store and forward) policy would ack before distributing when
> e2e is not important.
> 
> [RRR] If "message" is sent as "media" on e2e after establishing the session,
> does the Ack not to be taken care of by the transport protocol itself (e.g.,
> TCP)? (For signaling part, SIP's ACK is already taken care-of, I guess.) Am
> I missing something?

Depends on what you mean by ACK and e2e.

When sip messages are sent over tcp explicit acks are still sent back.
When MESSAGEs are sent over sip in paging mode there is an explicit 200
OK. A similar sort of explicit acknowledgement can be part of session
mode IM if we choose to make it so.

If this is done, then the definition of e2e becomes important. In a two
party session this may be fairly obvious. But if you establish a
conference using a conference mixer for the IM, there may be several
session legs. Then e2e may be defined to cover only a single leg, or it
may be defined to include all legs. It is up to the conference mixer to
decide this. If we have explicit acknowledgement of each message, then
the conference mixer can choose to do the acknowledgement either way.

	Paul

From rrroy@att.com  Thu Oct  4 12:15:53 2001
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 MAA27014
	for ; Thu, 4 Oct 2001 12:15:52 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f94GFKC21559;
	Thu, 4 Oct 2001 12:15:24 -0400 (EDT)
Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id MAA10033; Thu, 4 Oct 2001 12:15:34 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 4 Oct 2001 12:15:17 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Paul Kyzivat 
Cc: Jonathan Rosenberg ,
        "'Peterson, Jon'"
	 ,
        "'Petri K. Koskelainen'"
	 ,
        Anders Kristensen
	 ,
        schulzrinne@cs.columbia.edu, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM transport
Date: Thu, 4 Oct 2001 12:07:09 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2022
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: 

Hi, Paul:

My comments are provided below [RRR].

Best regards,
Radhika

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Thursday, October 04, 2001 11:48 AM
To: Roy, Radhika R, ALCTA
.
> ....
> 
> e2e acknowledgement can provide this if the conference server manages
> the acknowledgements properly. This could be a policy in the server. A
> different (store and forward) policy would ack before distributing when
> e2e is not important.
> 
> [RRR] If "message" is sent as "media" on e2e after establishing the
session,
> does the Ack not to be taken care of by the transport protocol itself
(e.g.,
> TCP)? (For signaling part, SIP's ACK is already taken care-of, I guess.)
Am
> I missing something?

Depends on what you mean by ACK and e2e.

When sip messages are sent over tcp explicit acks are still sent back.
When MESSAGEs are sent over sip in paging mode there is an explicit 200
OK. 

[RRR] Here, MESSAGE (in paging mode) is considered, as if, as a part of SIP
signaling messages.

A similar sort of explicit acknowledgement can be part of session
mode IM if we choose to make it so.

[RRR] It is also taken care-of when the session is established using usual
SIP signaling messages.

If this is done, then the definition of e2e becomes important. In a two
party session this may be fairly obvious. But if you establish a
conference using a conference mixer for the IM, there may be several
session legs. Then e2e may be defined to cover only a single leg, or it
may be defined to include all legs. It is up to the conference mixer to
decide this. If we have explicit acknowledgement of each message, then
the conference mixer can choose to do the acknowledgement either way.

[RRR] We probably do not need to take any extra precaution because SIP
signaling messages are good enough for this purpose as well. For example,
the draft (draft-khartabil-sip-conferencing-00.txt) shows how MESSAGE
conferencing can be established and, it appears that we do not need to do
anything extra.


From sean.olson@ericsson.com  Thu Oct  4 12:23:12 2001
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 MAA27067
	for ; Thu, 4 Oct 2001 12:23:12 -0400 (EDT)
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 f94GN0Y17639
	for ; Thu, 4 Oct 2001 11:23:00 -0500 (CDT)
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 f94GN0115557
	for ; Thu, 4 Oct 2001 11:23:00 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Oct 04 11:22:59 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <4CP9JL4B>; Thu, 4 Oct 2001 11:22:59 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Dror@vocaltec.com'" ,
        Anders Kristensen
	 
Cc: "Adam Roach (E-mail)" ,
        Avshalom Houri
	 ,
        "'Jonathan Rosenberg'" ,
        "'Robert Brown'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Partial Notifies?
Date: Thu, 4 Oct 2001 11:22:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14CF0.D49151C0"
Content-Length: 8961
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: 

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_01C14CF0.D49151C0
Content-Type: text/plain;
	charset="iso-8859-1"


-----Original Message-----
From: Dror@vocaltec.com [mailto:Dror@vocaltec.com]
Sent: Thursday, October 04, 2001 4:53 AM

>Actually, I'm concerened about using generic diff algorithm. 
>It requires the server to build the entire document, and perform a diff
>operation to create the partial document to send to the client. 

Actually it doesn't. This depends on how the server decides
to implement diffs. It could keep a history ala RCS that makes
it easy to build diffs without having to build the entire document
for every NOTIFY. It builds it once (which it needs to do to satisfy
full updates anyways), then computes a diff with the previous version.
Successive partial NOTIFYs (against the last or earlier versions) can quickly
be built.

>However, the "document" returned which requires this partial update us
>actually a list of items, updated at different times. 
>Thus, in most cases, the server can create a list of changed items without
>rebuilding the entire list. e.g.: generating a list of all updated items 
>since date X can be much simpler than fetching the entire list
>In some situations, an update counter might be easier to use than "date of updates".

A timestamp is probably not a good idea as you mention. There are
a number of ways to compute a "ETag"-like value for versioning purposes
including virtual clocks. 

>My suggestion for partial list: 
>1. whenever a server returns the list to the client, it also returns an
>   "update-cookie". This cookie is treated as an opaque string. 
>2. whenever the client wants to update its local list, it will send this
>   "update-cookie" to the server. 
>3. the server will see whether the cookie makes sense, and will try to return
>   partial update of changes since the time the cookie was generated.

In what format will the server return the partial update? Will it be
XML? If XML, will it be WFF? Will it pass a validating parser? 
It can be difficult to do compact partial updates that satisfy these properties.
Since compactness is the goal of partial notifies, a generic diff algorithm
seemed more appropriate.
 
>4. if the cookie denotes an up-to-date list, the server will return nothing 
>5. if the server fails to parse the cookie, it will return a full update to the client. 
>6. in any case, the server returns a new "update-cookie" to the client.

The "update-cookie" concept is fine. This is exactly what the ETag: header
provides. I think the issue you are raising is how we supply diffs.
Do we use a generic diff algorithm or a "diff" that is tailored to the
format of the information we are sending in the NOTIFY (e.g. application/cpim-pdif+xml)?

Arguments for a generic diff algorithm include:
1) Possible simplicity of implementation (easy to understand and debug)
2) Applicable across applications that use NOTIFY, i.e.
   it won't be tied to presence
3) Could even be applied by intermediate proxies that don't
   understand the content of the NOTIFY payload. Imagine a
   server farm where you have a master server handling full
   updates and a cluster of servers handling partial updates.

>----------------------------------------------------------------
>Dror Tirosh 
>VocalTec Communications, Ltd
>-------------------------------------------------------------- 

Regards,
Sean Olson
Ericsson Inc.

------_=_NextPart_001_01C14CF0.D49151C0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Partial Notifies?






-----Original Message-----

From: Dror@vocaltec.com [mailto:Dror@vocaltec.com]

Sent: Thursday, October 04, 2001 4:53 AM




>Actually, I'm concerened about using generic diff algorithm. 

>It requires the server to build the entire document, and perform a diff

>operation to create the partial document to send to the client. 




Actually it doesn't. This depends on how the server decides

to implement diffs. It could keep a history ala RCS that makes

it easy to build diffs without having to build the entire document

for every NOTIFY. It builds it once (which it needs to do to satisfy

full updates anyways), then computes a diff with the previous version.

Successive partial NOTIFYs (against the last or earlier versions) can quickly

be built.




>However, the "document" returned which requires this partial update us

>actually a list of items, updated at different times. 

>Thus, in most cases, the server can create a list of changed items without

>rebuilding the entire list. e.g.: generating a list of all updated items 

>since date X can be much simpler than fetching the entire list

>In some situations, an update counter might be easier to use than "date of updates".




A timestamp is probably not a good idea as you mention. There are

a number of ways to compute a "ETag"-like value for versioning purposes

including virtual clocks. 




>My suggestion for partial list: 

>1. whenever a server returns the list to the client, it also returns an

>   "update-cookie". This cookie is treated as an opaque string. 

>2. whenever the client wants to update its local list, it will send this

>   "update-cookie" to the server. 

>3. the server will see whether the cookie makes sense, and will try to return

>   partial update of changes since the time the cookie was generated.




In what format will the server return the partial update? Will it be

XML? If XML, will it be WFF? Will it pass a validating parser? 

It can be difficult to do compact partial updates that satisfy these properties.

Since compactness is the goal of partial notifies, a generic diff algorithm

seemed more appropriate.

 

>4. if the cookie denotes an up-to-date list, the server will return nothing 

>5. if the server fails to parse the cookie, it will return a full update to the client. 

>6. in any case, the server returns a new "update-cookie" to the client.




The "update-cookie" concept is fine. This is exactly what the ETag: header

provides. I think the issue you are raising is how we supply diffs.

Do we use a generic diff algorithm or a "diff" that is tailored to the

format of the information we are sending in the NOTIFY (e.g. application/cpim-pdif+xml)?




Arguments for a generic diff algorithm include:

1) Possible simplicity of implementation (easy to understand and debug)

2) Applicable across applications that use NOTIFY, i.e.

   it won't be tied to presence

3) Could even be applied by intermediate proxies that don't

   understand the content of the NOTIFY payload. Imagine a

   server farm where you have a master server handling full

   updates and a cluster of servers handling partial updates.




>----------------------------------------------------------------

>Dror Tirosh <dror@vocaltec.com>

>VocalTec Communications, Ltd

>-------------------------------------------------------------- 




Regards,

Sean Olson

Ericsson Inc.





------_=_NextPart_001_01C14CF0.D49151C0--

From Tim.Moran@nokia.com  Thu Oct  4 13:17:40 2001
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27254
	for ; Thu, 4 Oct 2001 13:17:39 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.americas.nokia.com [172.18.194.217])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f94HMBC06403
	for ; Thu, 4 Oct 2001 20:22:11 +0300 (EET DST)
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 f94HHh722937
	for ; Thu, 4 Oct 2001 12:17:43 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Thu, 4 Oct 2001 12:17:22 -0500
Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 4 Oct 2001 12:17:22 -0500
content-class: urn:content-classes:message
Date: Thu, 4 Oct 2001 12:17:22 -0500
Message-ID: <278B6B0D76698D45BBA872CD23DD496A0A41E5@daebe004.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 200 vs. 202
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcFM+GnIhi0NZ7dVEdWyeAAAhjwGBQ==
From: "Moran Tim (NET/Dallas)" 
To: 
X-OriginalArrivalTime: 04 Oct 2001 17:17:22.0277 (UTC) FILETIME=[6DEA8150:01C14CF8]
Content-Length: 1318
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA27254
Subject: [Simple] 200 vs. 202
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: 

The Simple presence draft Section 3 states,  "Once authorized, the
presence agent sends a 202 Accepted response.".  It also states that the
PA sends an immediate  Notify message.   Section 5.7 states,  "Pending
occurs when the server cannot obtain authorization ... a pending
subscription generates a 202 Accepted response". 

For the case of pending authorization,  what is sent 200 or 202? 

Section  5.7 states that an accepted subscription generates a 200. Now
if a PA sends a 202 (and an immediate Notify) and the user later
authorizes the subscription (e.g. manually), is it to send a 200???
This doesn't make since given 2543 uses the term "final" response for
2XX and above. 

I think some of the answer is that Section 3 is in error and that a 202
is sent by a PA or a 200 but not both. If a 202 is sent, the Notify is
not sent until authorization occurs (i.e. does not have to be
immediately). If authorization can occur immediately, a 200 is sent
immediately followed by a Notify.  Am I close to right?

Relating to forked subscriptions (5.10), what happens if one of the
subscribed-to PAs can authorize and wants to send a 200? Does it instead
send a 202 and immediately send a Notify?  That is, forked-to PAs are
not allowed to send 200? I presume the PA can tell the request has been
forked.

Tim Moran


From Avshalom@ubique.com  Thu Oct  4 16:20:11 2001
Received: from ubqgate02.lotus.com ([194.196.39.199])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27825
	for ; Thu, 4 Oct 2001 16:20:07 -0400 (EDT)
From: Avshalom@ubique.com
Subject: Re: [Simple] IM over the signaling connection
To: Ben Campbell 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Thu, 4 Oct 2001 22:18:35 +0200
X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at
 04/10/2001 22:18:51
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 3174
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: 

We have got the following wording:

<<<
The IESG has some concerns that this mechanism constitutes the use of SIP
as a transport protocol. In other words, once the session has been
established
between the two endpoints by the INVITE, if the MESSAGEs can only go
directly end-to-end, then their headers and related protocol apparatus are
entirely superfluous and may do more harm than good. We saw during the
meeting last week that there were definitely some pitfalls to allowing
methods other than MESSAGE across the IM stream (as well as questions about
overlapping transactions, redirection, forking, and so forth), and it isn't
clear that the overhead is justified if MESSAGE is just an envelope for its
encapsulated MIME payload. The IESG was particularly concerned, in addition
to the protocol overhead, with congestion characteristics of the messaging
session and with the precedent that could be set by using SIP in this
fashion.
>>>

I am not sure if the IESG objects to the use of SIP as transport due to:
1. The signalling connection is for signalling only and not for any media.
2. The overhead it will cause to the protocol.
3. The superfluos headers.

If it is 1, then why a single MESSAGE is allowed? if it 2 or 3, then we can
limit the usage when the
session is held over the signaling connection.

avshalom
Sametime/Lotus/IBM



                                                                                                                       
                    Ben Campbell                                                                                       
                                   cc:     simple@mailman.dynamicsoft.com                                    
                                             Subject:     Re: [Simple] IM over the signaling connection                
                    04/10/2001 17:28                                                                                   
                                                                                                                       
                                                                                                                       



It is not so much that it is being ignored as that the IESG has told us
they will not approve it.


Avshalom@ubique.com wrote:

> It seems that the possibility of sending MESSAGEs of sessions over the
> signaling connection is being ignored.
> I am not sure that there is a consensus not to use it.
>
> It think that we can agree on sending MESSAGEs of sessions on the control
> connection. We should keep the
> header of the MESSAGEs to a necessary minimum and agree on a maximum
length
> of MESSAGEs to be sent
> on the signaling connection. Given this, the impact on the control
> connection will not be different from a one time
> MESSAGE and NOTIFYs.
>
> avshalom
> Sametime/Lotus/IBM
>
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>








From roberbr@microsoft.com  Thu Oct  4 17:06:45 2001
Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA27995
	for ; Thu, 4 Oct 2001 17:06:43 -0400 (EDT)
Received: from 157.54.9.100 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 04 Oct 2001 14:04:44 -0700
Received: from red-msg-05.redmond.corp.microsoft.com ([157.54.12.72]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 4 Oct 2001 14:04:41 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Simple] IM over the signaling connection
Date: Thu, 4 Oct 2001 14:04:41 -0700
Message-ID: <8DC4B82A94A29D4AB708F05E0EB557AB025C3448@red-msg-05.redmond.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] IM over the signaling connection
Thread-Index: AcFNEuzh0oWZhmuOQ0iRT1eSixprywAAb6hg
From: "Robert Brown" 
To: , "Ben Campbell" 
Cc: 
X-OriginalArrivalTime: 04 Oct 2001 21:04:41.0594 (UTC) FILETIME=[2F951DA0:01C14D18]
Content-Length: 4136
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA27995
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: 

In my opinion, while this topic has generated many creative alternative
proposals, *none* of them come close to the simplicity and effectiveness
of using MESSAGE (with/without INVITE) in the signaling band.

I agree with Ashvalom.  I'm completely perplexed by this IESG mandate.
It is totally unclear to me (and it sounds like I'm not alone) what the
actual disadvantage with in-band IM is.  
 
The signaling layer is already polluted with copious presence sessions
and messages.  Actual IM traffic is trivial compared to this.  I've
already posted an example that walks through the reasons for this.

I have seen it mentioned in a few threads that IM could be used to
transfer files or long monologues, hence could be a burden on SIP
proxies.  This is an abuse of the session.  If you want to transfer
files, negotiate a file transfer session.  IM should be text messaging
and the typical bit-rate is the speed of typing.  I could abuse NOTIFY
just as effectively since the presence document is extensible and
there's nothing to stop me including my autobiography, holiday snaps,
listings of all the MP3s on my hard disks, or whatever.

- Rob

-----Original Message-----
From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] 
Sent: Thursday, October 04, 2001 1:19 PM
To: Ben Campbell
Cc: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection


We have got the following wording:

<<<
The IESG has some concerns that this mechanism constitutes the use of
SIP
as a transport protocol. In other words, once the session has been
established
between the two endpoints by the INVITE, if the MESSAGEs can only go
directly end-to-end, then their headers and related protocol apparatus
are
entirely superfluous and may do more harm than good. We saw during the
meeting last week that there were definitely some pitfalls to allowing
methods other than MESSAGE across the IM stream (as well as questions
about
overlapping transactions, redirection, forking, and so forth), and it
isn't
clear that the overhead is justified if MESSAGE is just an envelope for
its
encapsulated MIME payload. The IESG was particularly concerned, in
addition
to the protocol overhead, with congestion characteristics of the
messaging
session and with the precedent that could be set by using SIP in this
fashion.
>>>

I am not sure if the IESG objects to the use of SIP as transport due to:
1. The signalling connection is for signalling only and not for any
media.
2. The overhead it will cause to the protocol.
3. The superfluos headers.

If it is 1, then why a single MESSAGE is allowed? if it 2 or 3, then we
can
limit the usage when the
session is held over the signaling connection.

avshalom
Sametime/Lotus/IBM



 

                    Ben Campbell

                                   cc:
simple@mailman.dynamicsoft.com                                    
                                             Subject:     Re: [Simple]
IM over the signaling connection                
                    04/10/2001 17:28

 

 




It is not so much that it is being ignored as that the IESG has told us
they will not approve it.


Avshalom@ubique.com wrote:

> It seems that the possibility of sending MESSAGEs of sessions over the
> signaling connection is being ignored.
> I am not sure that there is a consensus not to use it.
>
> It think that we can agree on sending MESSAGEs of sessions on the
control
> connection. We should keep the
> header of the MESSAGEs to a necessary minimum and agree on a maximum
length
> of MESSAGEs to be sent
> on the signaling connection. Given this, the impact on the control
> connection will not be different from a one time
> MESSAGE and NOTIFYs.
>
> avshalom
> Sametime/Lotus/IBM
>
>
> _______________________________________________
> 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 jon.peterson@NeuStar.com  Thu Oct  4 17:16:12 2001
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 RAA28051
	for ; Thu, 4 Oct 2001 17:16:11 -0400 (EDT)
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 f94LD0W27399;
	Thu, 4 Oct 2001 16:13:00 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 4 Oct 2001 16:11:41 -0500
Message-ID: <70565611B164D511957A001083FCDD56478B4E@va02.va.neustar.com>
From: "Peterson, Jon" 
To: "'Avshalom@ubique.com'" ,
        Ben Campbell
	 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Thu, 4 Oct 2001 16:11:23 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5233
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: 

Just to be clear about this, I don't think the IESG has expressed disfavor
with the paging model (i.e. sending MESSAGEs outside the context of a
session over the traditional SIP signaling stream). I believe they have
objected to the creation of an explicit session which then uses SIP MESSAGE
as a transport mechanism. I think there is a clear difference between these
alternatives; however, that difference has been obscured by some of the
hybrid architectures that have been proposed on this list.

Initially, there was the concept of paging (which operated over the
signaling network) and chat (which went directly end-to-end). I think there
was a clear consensus to allow the paging model, and a great deal of
subsequent discussion about the form that the chat model should take.

In the midst of this discussion, firewall/NAT traversal and middlebox
concerns were raised, pointing out correctly that chat would not always be
end-to-end. I think that a great deal of confusion has arisen from the
notion that a 'proxy,' either in the sense of a SIP proxy or in the sense of
a middlebox or stun server or some conflation of these roles, would act as
an intermediary in chat sessions, modifying and/or re-routing IMs. This has
led to an argument for sending SIP MESSAGEs in IM sessions in order to use
their routing headers (like Vias) to navigate network intermediaries.

Frankly, it has never really been clear to my why, if network conditions
adverse to the creation of a chat session exist, an IM client can't just
default to the paging method. If the performance requirements of the network
make paging infeasible, then something like a stun server could be
introduced with minimal, if any, impacts to the construction of SIMPLE
messages. Either way, I haven't yet understood the justification for some
sort of hybrid chat-of-MESSAGEs-through-proxies session.

So if there is a need to keep the sort of information you might have found
in MESSAGE headers in chat-based IMs, I would argue it should only be for
session correlation, sequencing and so forth, rather than routing. Perhaps
all of the information we need here is available (or should be available) in
the message/cpim MIME type.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair


-----Original Message-----
From: Avshalom@ubique.com [mailto:Avshalom@ubique.com]
Sent: Thursday, October 04, 2001 1:19 PM
To: Ben Campbell
Cc: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection



We have got the following wording:

<<<
The IESG has some concerns that this mechanism constitutes the use of SIP
as a transport protocol. In other words, once the session has been
established
between the two endpoints by the INVITE, if the MESSAGEs can only go
directly end-to-end, then their headers and related protocol apparatus are
entirely superfluous and may do more harm than good. We saw during the
meeting last week that there were definitely some pitfalls to allowing
methods other than MESSAGE across the IM stream (as well as questions about
overlapping transactions, redirection, forking, and so forth), and it isn't
clear that the overhead is justified if MESSAGE is just an envelope for its
encapsulated MIME payload. The IESG was particularly concerned, in addition
to the protocol overhead, with congestion characteristics of the messaging
session and with the precedent that could be set by using SIP in this
fashion.
>>>

I am not sure if the IESG objects to the use of SIP as transport due to:
1. The signalling connection is for signalling only and not for any media.
2. The overhead it will cause to the protocol.
3. The superfluos headers.

If it is 1, then why a single MESSAGE is allowed? if it 2 or 3, then we can
limit the usage when the
session is held over the signaling connection.

avshalom
Sametime/Lotus/IBM



 

                    Ben Campbell

                                   cc:
simple@mailman.dynamicsoft.com                                    
                                             Subject:     Re: [Simple] IM
over the signaling connection                
                    04/10/2001 17:28

 

 




It is not so much that it is being ignored as that the IESG has told us
they will not approve it.


Avshalom@ubique.com wrote:

> It seems that the possibility of sending MESSAGEs of sessions over the
> signaling connection is being ignored.
> I am not sure that there is a consensus not to use it.
>
> It think that we can agree on sending MESSAGEs of sessions on the control
> connection. We should keep the
> header of the MESSAGEs to a necessary minimum and agree on a maximum
length
> of MESSAGEs to be sent
> on the signaling connection. Given this, the impact on the control
> connection will not be different from a one time
> MESSAGE and NOTIFYs.
>
> avshalom
> Sametime/Lotus/IBM
>
>
> _______________________________________________
> 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 bstucker@nortelnetworks.com  Thu Oct  4 17:23:04 2001
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 RAA28131
	for ; Thu, 4 Oct 2001 17:23:04 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA17503
	for ; Thu, 4 Oct 2001 16:22:40 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Thu, 4 Oct 2001 16:15:53 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 4 Oct 2001 16:21:58 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E3AEC4B@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Paul Kyzivat ,
        Jonathan Rosenberg 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Updated presence spec
Date: Thu, 4 Oct 2001 16:21:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14D1A.99974280"
X-Orig: 
Content-Length: 26378
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: 

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_01C14D1A.99974280
Content-Type: text/plain;
	charset="iso-8859-1"

I would have to agree with Paul on a lot of points.

The major concerns that I have with the current draft (and I apologize for
not voicing them earlier,
but I hadn't yet looked into the draft to the level I now am involved in)
are two-fold:

* Migration, as defined in the specification is unreliable without giving a
mechanism to enforce,
  using SIP, that the active PA is able to ensure it's the definitive source
of presence information
  given the restriction that all of the PUA's are registered. 

* The lack of a clear definition of how the PUA's are supposed to
communicate with the PA, or the 
  presence server their presence related attributes (whether this be
caller-prefs in the REGISTER
  for migration, or simply publishing the presence document fragments). We
can all think of ways to
  do this, I'm particularly worried that we all won't come up with the same
way, and won't be able
  to inter-op. Take for example CPL, if someone were to come along today and
try to use CPL in a SIP
  network, where is the draft or RFC (that hasn't expired) that states how
to do it? I've searched, and I
  couldn't find one. The only reason that I can find that CPL
implementations are inter-oping is because
  of an expired draft that gave the publication mechanism.

Jonathan has listed a couple of options for the migration: allow multiple
PA's and let the watchers figure
out the aggregation, or place the restriction that the PA must have the
complete aggregated picture of what
is going on with the various PUA's. I whole-heartedy agree that the first
option is not a good one. However,
since we are operating with a presence mechanism that uses SIP, saying that
the PA had better be definitive,
without having a mechanism (using SIP) to enforce this seems like a gap. The
only solution that any of us
sound like we're willing to live with to solve this problem is to put the PA
in the network, and not let it
migrate, so why not codify this behavior in the draft? I'd suggest just
removing the migration section 
altogether for now.

For the second concern, and just to make things inter-operable, can we make
the REGISTER method the ONLY
way that PUAs can publish presence information to a PA via SIP? Essentially,
remove the references to this
being an example, and just make it the way it works? This leaves the door
open to all of the non-SIP
ways that presence information may be fed to a PA using whatever protocol
someone cares to use, but gives us
an interoperable way of publishing presence via SIP. This wouldn't mandate
that you have to use SIP to 
publish your presence information necessarily, either. Just that if you want
to use SIP, this is the way to
do it. I think this is the direction the Donovan draft is going to take us
anyhow. Right?

Thoughts?

Brian Stucker
Nortel Networks

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Tuesday, October 02, 2001 10:03 AM
To: Jonathan Rosenberg
Cc: 'simple@mailman.dynamicsoft.com'
Subject: Re: [Simple] Updated presence spec


Comments below.

	Paul

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Tuesday, October 02, 2001 9:34 AM
> > To: Jonathan Rosenberg
> > Cc: 'simple@mailman.dynamicsoft.com'
> > Subject: Re: [Simple] Updated presence spec
> >
> >
> > Jonathan,
> >
> > You have satisfactorily answered my concerns, but the text doesn't
> > really reflect what you have said. How about something like the
> > following:
> >
> >  "The first of these phases can occur through configuration,
> > or through
> >   dynamic means. One dynamic means for a presence server to discover
> >   that the function can migrate to a PUA through the REGISTER message.
> >                                         ^
> >                                         is
> 
> Fixed.
> 
> >   Specifically, if a PUA wishes to indicate support for the PA
> >   function, it SHOULD include a contact address in its registration
> >   with a caller preferences "methods" parameter listing
> > SUBSCRIBE [13].
> >   This indicates that it is capable of terminating and processing
> >   SUBSCRIBE, and therefore can act as a PA. A PUA MUST NOT do this
> >                            ^^^                             ^^^^^^^
> >                            may be able to                  act as a PA
> 
> Since a PA is specifically defined for the presence event package, the
> statement "can" is correct, I believe. In fact, the next sentence
validates
> that it can, since it MUST NOT perform this registration if it can't.

I think there is still something wrong here, or at least subject to
misinterpretation.

If a PUA wishes to indicate support for the PA function, it can do as
you say, and it may believe that this indicates that it can act as a PA.
But the situation is different from the point of view of the registrar
that is acting as a PA. It receives the register listing the SUBSCRIBE
method, but it can't know whether this is from a server wishing to act
as a PA, or simply a server that wants to support some other event
package. So from the point of view of the registrar, this only means the
server MAY be able to act as a PA.

It seems like this has further implications for migration of the PA
function. If a PA/REGISTRAR receives a registration that suggests the
possibility of migrating the PA function, it should verify this before
beginning the migration. It could test it by sending a SUBSCRIBE to the
candidate PA and awaiting a successful response.

I think this would work, but it might not be nice for a UAS registering
to handle subscriptions for some other event package. Every time it
updates its subscription it might get dinged by PA testing to see if it
can now handle presence.

> 
> I fixed "do this" as you describe. I also added text at the end of this
> paragraph:
> 
>  Because the ``methods'' parameter does not convey the
> set of event packages for which the PUA can accept SUBSCRIBE, it is
> possible that the PUA will begin receiving SUBSCRIBE requests for
> other packages, possibly ones it doesn't support. As specified in
> \cite{draft-ietf-sip-events}, the PUA {\SHOULD} reject those requests
> with a 489.

Is 489 the best response? What about 305?

The above paragraph covers PAs that inadvertently receive subscriptions
for event packages other than presence. Maybe you need a similar
paragraph for UASs that inadvertently receive subscriptions for
presence:

  Similarly it is possible that a server supporting event 
  packages other than presence will receive SUBSCRIBE requests 
  for the presence package. 

> > I am however still concerned with the notion that a PUA can know
> > definitively that it has complete presence information. Once a PUA as
> > assumed the role of PA, there is nothing to prevent another UA from
> > registering with the original proxy, without notifying the PA
> > of this. I
> > believe the result will simply be unreliable presence information.
> 
> There are really only two choices here. The first choice is that we allow
> multiple PA for a presentity, each of which has access to different
subsets
> of the presence information. This means that we would need to change the
> forking behavior, and then mandate that subscribers be able to merge
> multiple independent presence documents received from multiple sources. We
> discussed that, and elected NOT to do it, since (1) this is a significant
> burden on the watcher, (2) the correct merging process is very policy
> specific, and can only be done reasonably at the presentity's domain where
> the policy resides.
> 
> The second choice is what is documented now - mandate that any PA have
> complete presence state. Enforcement of that can be difficult, but is
easily
> done on a system level. Consider, for example, a provider foo.com that is
> ONLY supporting instant messaging services using SIP. They also provide
> presence to indicate IM status, and only allow one client registered at a
> time. Since foo.com owns and runs the whole system, they can be sure that
> any presence client that has IM status has complete presence state, and
> therefore there is no problem in migrating subscriptions.
> 
> Effectively, enforcement of this requirement cannot be done at an element
> level, but it can be done at a system level.
> 
> I welcome other ideas on how to improve the story on this.

This is clearly a hard problem, and I don't claim to have a complete
answer. Clearly there are special cases where migration can work fine -
such as when there is only one UAS registered for an address. In other
cases the safest policy is probably to not do the migration.

> > I also have a question about the relationship between presence and
> > callerprefs:
> >
> > Suppose a UAS uses callerprefs when registering with a
> > registrar (using
> > callerpref parameters on the Contact headers in the REGISTER). And
> > suppose the registrar is also a PA. Has there been any
> > consideration for
> > reporting the callerpref information in the resulting presence
> > notifications? (I don't see any provision for it now in
> > draft-ietf-impp-cpim-pidf-00.)
> 
> Sure, definitely. Not all can be mapped, but many of them have obvious
> useful presence implications. At one point, we were going to go through
the
> exercise of mapping the caller prefs parameters to the presence data
format.
> However, we decided that this mapping is a matter of local implementation.

Why? This simply guarantees a lack of interoperability.
The mapping of registration to presence provides a base level
of standardization. To the extent that callerprefs is a standard
extension to registration, it also ought to map in a standard way.
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

------_=_NextPart_001_01C14D1A.99974280
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Updated presence spec




I would have to agree with Paul on a lot of points.




The major concerns that I have with the current draft (and I apologize for not voicing them earlier,

but I hadn't yet looked into the draft to the level I now am involved in) are two-fold:




* Migration, as defined in the specification is unreliable without giving a mechanism to enforce,

  using SIP, that the active PA is able to ensure it's the definitive source of presence information

  given the restriction that all of the PUA's are registered. 




* The lack of a clear definition of how the PUA's are supposed to communicate with the PA, or the 

  presence server their presence related attributes (whether this be caller-prefs in the REGISTER

  for migration, or simply publishing the presence document fragments). We can all think of ways to

  do this, I'm particularly worried that we all won't come up with the same way, and won't be able

  to inter-op. Take for example CPL, if someone were to come along today and try to use CPL in a SIP

  network, where is the draft or RFC (that hasn't expired) that states how to do it? I've searched, and I

  couldn't find one. The only reason that I can find that CPL implementations are inter-oping is because

  of an expired draft that gave the publication mechanism.




Jonathan has listed a couple of options for the migration: allow multiple PA's and let the watchers figure

out the aggregation, or place the restriction that the PA must have the complete aggregated picture of what

is going on with the various PUA's. I whole-heartedy agree that the first option is not a good one. However,

since we are operating with a presence mechanism that uses SIP, saying that the PA had better be definitive,

without having a mechanism (using SIP) to enforce this seems like a gap. The only solution that any of us

sound like we're willing to live with to solve this problem is to put the PA in the network, and not let it

migrate, so why not codify this behavior in the draft? I'd suggest just removing the migration section 

altogether for now.




For the second concern, and just to make things inter-operable, can we make the REGISTER method the ONLY

way that PUAs can publish presence information to a PA via SIP? Essentially, remove the references to this

being an example, and just make it the way it works? This leaves the door open to all of the non-SIP

ways that presence information may be fed to a PA using whatever protocol someone cares to use, but gives us

an interoperable way of publishing presence via SIP. This wouldn't mandate that you have to use SIP to 

publish your presence information necessarily, either. Just that if you want to use SIP, this is the way to

do it. I think this is the direction the Donovan draft is going to take us anyhow. Right?




Thoughts?




Brian Stucker

Nortel Networks




-----Original Message-----

From: Paul Kyzivat [mailto:pkyzivat@cisco.com]

Sent: Tuesday, October 02, 2001 10:03 AM

To: Jonathan Rosenberg

Cc: 'simple@mailman.dynamicsoft.com'

Subject: Re: [Simple] Updated presence spec






Comments below.




        Paul




Jonathan Rosenberg wrote:

> 

> 

> 

> > -----Original Message-----

> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]

> > Sent: Tuesday, October 02, 2001 9:34 AM

> > To: Jonathan Rosenberg

> > Cc: 'simple@mailman.dynamicsoft.com'

> > Subject: Re: [Simple] Updated presence spec

> >

> >

> > Jonathan,

> >

> > You have satisfactorily answered my concerns, but the text doesn't

> > really reflect what you have said. How about something like the

> > following:

> >

> >  "The first of these phases can occur through configuration,

> > or through

> >   dynamic means. One dynamic means for a presence server to discover

> >   that the function can migrate to a PUA through the REGISTER message.

> >                                         ^

> >                                         is

> 

> Fixed.

> 

> >   Specifically, if a PUA wishes to indicate support for the PA

> >   function, it SHOULD include a contact address in its registration

> >   with a caller preferences "methods" parameter listing

> > SUBSCRIBE [13].

> >   This indicates that it is capable of terminating and processing

> >   SUBSCRIBE, and therefore can act as a PA. A PUA MUST NOT do this

> >                            ^^^                             ^^^^^^^

> >                            may be able to                  act as a PA

> 

> Since a PA is specifically defined for the presence event package, the

> statement "can" is correct, I believe. In fact, the next sentence validates

> that it can, since it MUST NOT perform this registration if it can't.




I think there is still something wrong here, or at least subject to

misinterpretation.




If a PUA wishes to indicate support for the PA function, it can do as

you say, and it may believe that this indicates that it can act as a PA.

But the situation is different from the point of view of the registrar

that is acting as a PA. It receives the register listing the SUBSCRIBE

method, but it can't know whether this is from a server wishing to act

as a PA, or simply a server that wants to support some other event

package. So from the point of view of the registrar, this only means the

server MAY be able to act as a PA.




It seems like this has further implications for migration of the PA

function. If a PA/REGISTRAR receives a registration that suggests the

possibility of migrating the PA function, it should verify this before

beginning the migration. It could test it by sending a SUBSCRIBE to the

candidate PA and awaiting a successful response.




I think this would work, but it might not be nice for a UAS registering

to handle subscriptions for some other event package. Every time it

updates its subscription it might get dinged by PA testing to see if it

can now handle presence.




> 

> I fixed "do this" as you describe. I also added text at the end of this

> paragraph:

> 

>  Because the ``methods'' parameter does not convey the

> set of event packages for which the PUA can accept SUBSCRIBE, it is

> possible that the PUA will begin receiving SUBSCRIBE requests for

> other packages, possibly ones it doesn't support. As specified in

> \cite{draft-ietf-sip-events}, the PUA {\SHOULD} reject those requests

> with a 489.




Is 489 the best response? What about 305?




The above paragraph covers PAs that inadvertently receive subscriptions

for event packages other than presence. Maybe you need a similar

paragraph for UASs that inadvertently receive subscriptions for

presence:




  Similarly it is possible that a server supporting event 

  packages other than presence will receive SUBSCRIBE requests 

  for the presence package. 




> > I am however still concerned with the notion that a PUA can know

> > definitively that it has complete presence information. Once a PUA as

> > assumed the role of PA, there is nothing to prevent another UA from

> > registering with the original proxy, without notifying the PA

> > of this. I

> > believe the result will simply be unreliable presence information.

> 

> There are really only two choices here. The first choice is that we allow

> multiple PA for a presentity, each of which has access to different subsets

> of the presence information. This means that we would need to change the

> forking behavior, and then mandate that subscribers be able to merge

> multiple independent presence documents received from multiple sources. We

> discussed that, and elected NOT to do it, since (1) this is a significant

> burden on the watcher, (2) the correct merging process is very policy

> specific, and can only be done reasonably at the presentity's domain where

> the policy resides.

> 

> The second choice is what is documented now - mandate that any PA have

> complete presence state. Enforcement of that can be difficult, but is easily

> done on a system level. Consider, for example, a provider foo.com that is

> ONLY supporting instant messaging services using SIP. They also provide

> presence to indicate IM status, and only allow one client registered at a

> time. Since foo.com owns and runs the whole system, they can be sure that

> any presence client that has IM status has complete presence state, and

> therefore there is no problem in migrating subscriptions.

> 

> Effectively, enforcement of this requirement cannot be done at an element

> level, but it can be done at a system level.

> 

> I welcome other ideas on how to improve the story on this.




This is clearly a hard problem, and I don't claim to have a complete

answer. Clearly there are special cases where migration can work fine -

such as when there is only one UAS registered for an address. In other

cases the safest policy is probably to not do the migration.




> > I also have a question about the relationship between presence and

> > callerprefs:

> >

> > Suppose a UAS uses callerprefs when registering with a

> > registrar (using

> > callerpref parameters on the Contact headers in the REGISTER). And

> > suppose the registrar is also a PA. Has there been any

> > consideration for

> > reporting the callerpref information in the resulting presence

> > notifications? (I don't see any provision for it now in

> > draft-ietf-impp-cpim-pidf-00.)

> 

> Sure, definitely. Not all can be mapped, but many of them have obvious

> useful presence implications. At one point, we were going to go through the

> exercise of mapping the caller prefs parameters to the presence data format.

> However, we decided that this mapping is a matter of local implementation.




Why? This simply guarantees a lack of interoperability.

The mapping of registration to presence provides a base level

of standardization. To the extent that callerprefs is a standard

extension to registration, it also ought to map in a standard way.

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple





------_=_NextPart_001_01C14D1A.99974280--

From bstucker@nortelnetworks.com  Thu Oct  4 19:24:06 2001
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 TAA28549
	for ; Thu, 4 Oct 2001 19:24:05 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA16334
	for ; Thu, 4 Oct 2001 18:23:55 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 4 Oct 2001 18:23:21 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 4 Oct 2001 18:23:26 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E3AED50@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Brazier Lachlan ,
        "'Jonathan Rosenberg '" ,
        "''Neil Deason' '" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Thu, 4 Oct 2001 18:23:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14D2B.8FB96930"
Content-Length: 16262
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: 

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_01C14D2B.8FB96930
Content-Type: text/plain;
	charset="iso-8859-1"

I don't think it's non-sense...

Ugh.. The requestURI bit does cause some serious problems. If you run a
SUBSCRIBE
through a BBUA, that can change the requestURI as well. Yuck. Why don't we
consider
the TO party the presentity instead, and change the wording in the first
paragraph
of section 5.3 to reflect that? Then it becomes a lot nicer. In that case,
if 
the user in the TO of the SUBSCRIBE is not a user served 
by the presence agent that the subscribe was forked to, that presence agent 
should 603 the SUBSCRIBE. In essence, don't use the requestURI for
establishing
the identity of the presentity on the actual presence agent. It could go
through
a BBUA or fork to another user (as you suggest) and get munged along the
way, so
use it just for routing purposes.

I think that'll fix it. Presence agents shouldn't accept subscriptions just
because
they understand how to process a SUBSCRIBE and the requestURI matches them. 
They need to also take into account who they are authorized to represent the

presence for when deciding to accept a SUBSCRIBE or not. 

The other reason that I can think of, and this ties in somewhat with
migration problems,
is if we consider the presence agent for the presentity to be the presence
server. If
a presence server is in the network, clients can't always be expected to
know the
requestURI of the presence server that's serving the presentity they're
interested in
watching. The requestURI would start out (I would think, in general) equal
to the TO
header URI, which would be the user@domain address of the presentity. A
proxy along
the way would have to notice that this is a presence subscription, and
change the
requestURI to be the presence server before forwarding it, or the presence
server
would always have to be included in the list of registered contacts for the
user (which
may require the presence server to make a third party registration to the
presentity).

An exception would have to be made on the requestURI for a presence server
to ever be
able to process the subscription, which again goes back to the idea that the
requestURI
is only for routing, and the TO field identifies the actual presentity we're
interested in.

If this requirement comes from the events framework draft, then the events
framework draft
needs to be changed in order to accomodate BBUA's and things like presence
servers in the mix.

Regards,

Brian Stucker
Nortel Networks

-----Original Message-----
From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
Sent: Wednesday, October 03, 2001 1:51 AM
To: 'Jonathan Rosenberg '; Brazier Lachlan; ''Neil Deason' '; ''SIMPLE
Mailinglist' '
Subject: AW: [Simple] Multiple 200 Ok


 Hello,
as far as I see, the problem lays in the registration. Is there a way to
tell a registrar, that the registered address belongs to a different user?

I really believe a subscriber should know if he is subscribed to the right
person. As example imagine a subscriber, who subscribes for you, and when
you are online, sends you private documents automaticly. You probably don't
want this to happen.

I think the same might be true for INVITE. Imagine a video service, where a
video provider starts a video session, without knowing that you are not the
right customer, and not knowing that you are on holiday. (An example would
be a timed wakeup call or something like this) 

A solution I might think of, is to add a new parameter to the Contact
header, indicating if I am really the user addressed to, or in a REGISTER
request, to tell the registrar if the registered address "belongs" to me or
a different user at all.

Is this nonsense I am talking? 

Lachlan

-----Originalnachricht-----
Von: Jonathan Rosenberg
An: 'Brazier Lachlan'; Jonathan Rosenberg; 'Neil Deason'; 'SIMPLE
Mailinglist'
Gesendet: 03.10.01 04:38
Betreff: RE: [Simple] Multiple 200 Ok



 

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Tuesday, October 02, 2001 12:03 PM
> To: 'Jonathan Rosenberg'; 'Neil Deason'; 'SIMPLE Mailinglist'
> Subject: AW: [Simple] Multiple 200 Ok
> 
> 
> Hello,
> thank you for your clarification. There is still this one point open:
> 
> > > > How can a 
> > > > subscriber realize, that
> > > > a forking proxy forked to a different user (this can happen 
> > > > when I am on
> > > > holiday, and I register my working collegue with my working 
> > > > SIP Url - and
> > > > then somebody wants to subscribe for me)?
> 
> 
> I believe, the problem can occur, when a proxy changes the 
> request-URI. This
> would mean, that the proxy sends a SUBSCRIBE to another 
> presentity. 

Changing the request URI does not imply chaging the presentity. Changing
it
may occur in order to address the request to the presentity at a
different
location.


I still
> can't see, how the subscriber knows, that his SUBSCRIBE 
> request was handled
> by a different user.

The entity that finally responds to the SUBSCRIBE will place, in the
2xx, a
Contact header that contains their URL.


> 
> I could imagine, that in the first NOTIFY after receiving the 
> SUBSCRIBE
> request, the FROM header is different than the To header from 
> the SUBSCRIBE
> request. Is this valid with the draft?

No; as it stands, the To/From are flipped in the NOTIFY from the
presentity.


-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_01C14D2B.8FB96930
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Multiple 200 Ok




I don't think it's non-sense...




Ugh.. The requestURI bit does cause some serious problems. If you run a SUBSCRIBE

through a BBUA, that can change the requestURI as well. Yuck. Why don't we consider

the TO party the presentity instead, and change the wording in the first paragraph

of section 5.3 to reflect that? Then it becomes a lot nicer. In that case, if 

the user in the TO of the SUBSCRIBE is not a user served 

by the presence agent that the subscribe was forked to, that presence agent 

should 603 the SUBSCRIBE. In essence, don't use the requestURI for establishing

the identity of the presentity on the actual presence agent. It could go through

a BBUA or fork to another user (as you suggest) and get munged along the way, so

use it just for routing purposes.




I think that'll fix it. Presence agents shouldn't accept subscriptions just because

they understand how to process a SUBSCRIBE and the requestURI matches them. 

They need to also take into account who they are authorized to represent the 

presence for when deciding to accept a SUBSCRIBE or not. 




The other reason that I can think of, and this ties in somewhat with migration problems,

is if we consider the presence agent for the presentity to be the presence server. If

a presence server is in the network, clients can't always be expected to know the

requestURI of the presence server that's serving the presentity they're interested in

watching. The requestURI would start out (I would think, in general) equal to the TO

header URI, which would be the user@domain address of the presentity. A proxy along

the way would have to notice that this is a presence subscription, and change the

requestURI to be the presence server before forwarding it, or the presence server

would always have to be included in the list of registered contacts for the user (which

may require the presence server to make a third party registration to the presentity).




An exception would have to be made on the requestURI for a presence server to ever be

able to process the subscription, which again goes back to the idea that the requestURI

is only for routing, and the TO field identifies the actual presentity we're interested in.




If this requirement comes from the events framework draft, then the events framework draft

needs to be changed in order to accomodate BBUA's and things like presence servers in the mix.




Regards,




Brian Stucker

Nortel Networks




-----Original Message-----

From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]

Sent: Wednesday, October 03, 2001 1:51 AM

To: 'Jonathan Rosenberg '; Brazier Lachlan; ''Neil Deason' '; ''SIMPLE

Mailinglist' '

Subject: AW: [Simple] Multiple 200 Ok






 Hello,

as far as I see, the problem lays in the registration. Is there a way to

tell a registrar, that the registered address belongs to a different user?




I really believe a subscriber should know if he is subscribed to the right

person. As example imagine a subscriber, who subscribes for you, and when

you are online, sends you private documents automaticly. You probably don't

want this to happen.




I think the same might be true for INVITE. Imagine a video service, where a

video provider starts a video session, without knowing that you are not the

right customer, and not knowing that you are on holiday. (An example would

be a timed wakeup call or something like this) 




A solution I might think of, is to add a new parameter to the Contact

header, indicating if I am really the user addressed to, or in a REGISTER

request, to tell the registrar if the registered address "belongs" to me or

a different user at all.




Is this nonsense I am talking? 




Lachlan




-----Originalnachricht-----

Von: Jonathan Rosenberg

An: 'Brazier Lachlan'; Jonathan Rosenberg; 'Neil Deason'; 'SIMPLE

Mailinglist'

Gesendet: 03.10.01 04:38

Betreff: RE: [Simple] Multiple 200 Ok








 




> -----Original Message-----

> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]

> Sent: Tuesday, October 02, 2001 12:03 PM

> To: 'Jonathan Rosenberg'; 'Neil Deason'; 'SIMPLE Mailinglist'

> Subject: AW: [Simple] Multiple 200 Ok

> 

> 

> Hello,

> thank you for your clarification. There is still this one point open:

> 

> > > > How can a 

> > > > subscriber realize, that

> > > > a forking proxy forked to a different user (this can happen 

> > > > when I am on

> > > > holiday, and I register my working collegue with my working 

> > > > SIP Url - and

> > > > then somebody wants to subscribe for me)?

> 

> 

> I believe, the problem can occur, when a proxy changes the 

> request-URI. This

> would mean, that the proxy sends a SUBSCRIBE to another 

> presentity. 




Changing the request URI does not imply chaging the presentity. Changing

it

may occur in order to address the request to the presentity at a

different

location.






I still

> can't see, how the subscriber knows, that his SUBSCRIBE 

> request was handled

> by a different user.




The entity that finally responds to the SUBSCRIBE will place, in the

2xx, a

Contact header that contains their URL.






> 

> I could imagine, that in the first NOTIFY after receiving the 

> SUBSCRIBE

> request, the FROM header is different than the To header from 

> the SUBSCRIBE

> request. Is this valid with the draft?




No; as it stands, the To/From are flipped in the NOTIFY from the

presentity.






-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_01C14D2B.8FB96930--

From bstucker@nortelnetworks.com  Thu Oct  4 19:29:29 2001
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 TAA28610
	for ; Thu, 4 Oct 2001 19:29:28 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA17213
	for ; Thu, 4 Oct 2001 18:29:19 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 4 Oct 2001 18:28:44 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Thu, 4 Oct 2001 18:28:49 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E3AED52@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: "Moran Tim (NET/Dallas)" ,
        simple 
Subject: RE: [Simple] 200 vs. 202
Date: Thu, 4 Oct 2001 18:28:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14D2C.54CF8330"
Content-Length: 6836
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: 

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_01C14D2C.54CF8330
Content-Type: text/plain;
	charset="iso-8859-1"

I just ran across this same question myself...

I think your interpretation is correct if you correlate the presence draft
with the events framework draft.

Additionally, maybe the wording in section 3, last paragraph to should be
changed remove the 
requirement that if a 202 is sent back, the notifier must also always send
back a NOTIFY as well? 

According to section 5.1.7.2 of the -00 events framework draft, if a 202 is
sent back, the NOTIFY 
acts as an implicit 200. So sending 202 followed by a NOTIFY is as good as
just sending the 200 in the first
place, which defeats the purpose of having the 202 altogether. Otherwise,
you'd get a 200 out of the blue,
and I'm sure that's not what's intended at all. I think that breaks the
rules of SIP at the very least. 

Regards,

Brian Stucker
Nortel Networks



-----Original Message-----
From: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com]
Sent: Thursday, October 04, 2001 12:17 PM
To: simple
Subject: [Simple] 200 vs. 202


The Simple presence draft Section 3 states,  "Once authorized, the
presence agent sends a 202 Accepted response.".  It also states that the
PA sends an immediate  Notify message.   Section 5.7 states,  "Pending
occurs when the server cannot obtain authorization ... a pending
subscription generates a 202 Accepted response". 

For the case of pending authorization,  what is sent 200 or 202? 

Section  5.7 states that an accepted subscription generates a 200. Now
if a PA sends a 202 (and an immediate Notify) and the user later
authorizes the subscription (e.g. manually), is it to send a 200???
This doesn't make since given 2543 uses the term "final" response for
2XX and above. 

I think some of the answer is that Section 3 is in error and that a 202
is sent by a PA or a 200 but not both. If a 202 is sent, the Notify is
not sent until authorization occurs (i.e. does not have to be
immediately). If authorization can occur immediately, a 200 is sent
immediately followed by a Notify.  Am I close to right?

Relating to forked subscriptions (5.10), what happens if one of the
subscribed-to PAs can authorize and wants to send a 200? Does it instead
send a 202 and immediately send a Notify?  That is, forked-to PAs are
not allowed to send 200? I presume the PA can tell the request has been
forked.

Tim Moran

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

------_=_NextPart_001_01C14D2C.54CF8330
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] 200 vs. 202




I just ran across this same question myself...




I think your interpretation is correct if you correlate the presence draft with the events framework draft.




Additionally, maybe the wording in section 3, last paragraph to should be changed remove the 

requirement that if a 202 is sent back, the notifier must also always send back a NOTIFY as well? 




According to section 5.1.7.2 of the -00 events framework draft, if a 202 is sent back, the NOTIFY 

acts as an implicit 200. So sending 202 followed by a NOTIFY is as good as just sending the 200 in the first

place, which defeats the purpose of having the 202 altogether. Otherwise, you'd get a 200 out of the blue,

and I'm sure that's not what's intended at all. I think that breaks the rules of SIP at the very least. 




Regards,




Brian Stucker

Nortel Networks








-----Original Message-----

From: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com]

Sent: Thursday, October 04, 2001 12:17 PM

To: simple

Subject: [Simple] 200 vs. 202






The Simple presence draft Section 3 states,  "Once authorized, the

presence agent sends a 202 Accepted response.".  It also states that the

PA sends an immediate  Notify message.   Section 5.7 states,  "Pending

occurs when the server cannot obtain authorization ... a pending

subscription generates a 202 Accepted response". 




For the case of pending authorization,  what is sent 200 or 202? 




Section  5.7 states that an accepted subscription generates a 200. Now

if a PA sends a 202 (and an immediate Notify) and the user later

authorizes the subscription (e.g. manually), is it to send a 200???

This doesn't make since given 2543 uses the term "final" response for

2XX and above. 




I think some of the answer is that Section 3 is in error and that a 202

is sent by a PA or a 200 but not both. If a 202 is sent, the Notify is

not sent until authorization occurs (i.e. does not have to be

immediately). If authorization can occur immediately, a 200 is sent

immediately followed by a Notify.  Am I close to right?




Relating to forked subscriptions (5.10), what happens if one of the

subscribed-to PAs can authorize and wants to send a 200? Does it instead

send a 202 and immediately send a Notify?  That is, forked-to PAs are

not allowed to send 200? I presume the PA can tell the request has been

forked.




Tim Moran




_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple





------_=_NextPart_001_01C14D2C.54CF8330--

From jdrosen@dynamicsoft.com  Thu Oct  4 22:18:45 2001
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 WAA29143
	for ; Thu, 4 Oct 2001 22:18:40 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f952HO8P026667;
	Thu, 4 Oct 2001 22:17:24 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SND0Y>; Thu, 4 Oct 2001 22:18:27 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brian Stucker'" ,
        Brazier Lachlan
	 ,
        Jonathan Rosenberg
	 ,
        "''Neil Deason' '" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Thu, 4 Oct 2001 22:18:26 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 7081
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: 


  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Thursday, October 04, 2001 7:23 PM
To: Brazier Lachlan; 'Jonathan Rosenberg '; ''Neil Deason' '; ''SIMPLE
Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok


>I don't think it's non-sense... 
>
>Ugh.. The requestURI bit does cause some serious problems. If you run a
SUBSCRIBE 
>through a BBUA, that can change the requestURI as well. Yuck. Why don't we
consider 
>the TO party the presentity instead, and change the wording in the first
paragraph 
>of section 5.3 to reflect that? Then it becomes a lot nicer. In that case,
if 
>the user in the TO of the SUBSCRIBE is not a user served 
>by the presence agent that the subscribe was forked to, that presence agent

>should 603 the SUBSCRIBE.

Absolutely, positively NOT.

It is fundamental to the entire SIP model that a request can traverse many
hops (proxies), each hop modifying the request URI based on local policy,
ultimately reaching a recipient. Any particular hop can only make routing
and processing decisions if the target of the request is within the
namespace managed by that hop. What you are proposing would violate that,
and break the protocol, both SIP and SIMPLE, totally. 

Yes, it is helpful to know who that recipient ultimately is. The COntact
header in the 2xx, as I have already stated, provides some form of identity.
Even better is the Remote-Party-ID header from the privacy extension. 

>In essence, don't use the requestURI for establishing 
>the identity of the presentity on the actual presence agent. It could go
through 
>a BBUA or fork to another user (as you suggest) and get munged along the
way, so 
>use it just for routing purposes. 

Wrong.

>I think that'll fix it. Presence agents shouldn't accept subscriptions just
because 
>they understand how to process a SUBSCRIBE and the requestURI matches them.

>They need to also take into account who they are authorized to represent
the 
>presence for when deciding to accept a SUBSCRIBE or not. 

Generally, if a server receives a request, its because some chain of
processing decisions along the way decided that this server is indeed
ideally suited for doing that. The server can decide not to, and the purpose
of the To field is to provide information to allow it to make that decision
if it chooses. The same holds for INVITE. 

>The other reason that I can think of, and this ties in somewhat with
migration problems, 
>is if we consider the presence agent for the presentity to be the presence
server. If 
>a presence server is in the network, clients can't always be expected to
know the 
>requestURI of the presence server that's serving the presentity they're
interested in 
>watching. The requestURI would start out (I would think, in general) equal
to the TO 
>header URI, which would be the user@domain address of the presentity. A
proxy along 
>the way would have to notice that this is a presence subscription, and
change the 
>requestURI to be the presence server before forwarding it, or the presence
server 
>would always have to be included in the list of registered contacts for the
user (which 
>may require the presence server to make a third party registration to the
presentity). 

This makes no sense whatsoever.

-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: Wednesday, October 03, 2001 1:51 AM 
To: 'Jonathan Rosenberg '; Brazier Lachlan; ''Neil Deason' '; ''SIMPLE 
Mailinglist' ' 
Subject: AW: [Simple] Multiple 200 Ok 


 Hello, 
as far as I see, the problem lays in the registration. Is there a way to 
tell a registrar, that the registered address belongs to a different user? 
I really believe a subscriber should know if he is subscribed to the right 
person. As example imagine a subscriber, who subscribes for you, and when 
you are online, sends you private documents automaticly. You probably don't 
want this to happen. 
I think the same might be true for INVITE. Imagine a video service, where a 
video provider starts a video session, without knowing that you are not the 
right customer, and not knowing that you are on holiday. (An example would 
be a timed wakeup call or something like this) 
A solution I might think of, is to add a new parameter to the Contact 
header, indicating if I am really the user addressed to, or in a REGISTER 
request, to tell the registrar if the registered address "belongs" to me or 
a different user at all. 
Is this nonsense I am talking? 
Lachlan 
-----Originalnachricht----- 
Von: Jonathan Rosenberg 
An: 'Brazier Lachlan'; Jonathan Rosenberg; 'Neil Deason'; 'SIMPLE 
Mailinglist' 
Gesendet: 03.10.01 04:38 
Betreff: RE: [Simple] Multiple 200 Ok 



 
> -----Original Message----- 
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] 
> Sent: Tuesday, October 02, 2001 12:03 PM 
> To: 'Jonathan Rosenberg'; 'Neil Deason'; 'SIMPLE Mailinglist' 
> Subject: AW: [Simple] Multiple 200 Ok 
> 
> 
> Hello, 
> thank you for your clarification. There is still this one point open: 
> 
> > > > How can a 
> > > > subscriber realize, that 
> > > > a forking proxy forked to a different user (this can happen 
> > > > when I am on 
> > > > holiday, and I register my working collegue with my working 
> > > > SIP Url - and 
> > > > then somebody wants to subscribe for me)? 
> 
> 
> I believe, the problem can occur, when a proxy changes the 
> request-URI. This 
> would mean, that the proxy sends a SUBSCRIBE to another 
> presentity. 
Changing the request URI does not imply chaging the presentity. Changing 
it 
may occur in order to address the request to the presentity at a 
different 
location. 


I still 
> can't see, how the subscriber knows, that his SUBSCRIBE 
> request was handled 
> by a different user. 
The entity that finally responds to the SUBSCRIBE will place, in the 
2xx, a 
Contact header that contains their URL. 


> 
> I could imagine, that in the first NOTIFY after receiving the 
> SUBSCRIBE 
> request, the FROM header is different than the To header from 
> the SUBSCRIBE 
> request. Is this valid with the draft? 
No; as it stands, the To/From are flipped in the NOTIFY from the 
presentity. 


-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 jdrosen@dynamicsoft.com  Thu Oct  4 22:28:04 2001
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 WAA29189
	for ; Thu, 4 Oct 2001 22:27:59 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f952Qi8P026713;
	Thu, 4 Oct 2001 22:26:45 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SN1AH>; Thu, 4 Oct 2001 22:27:48 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Moran Tim (NET/Dallas)'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] 200 vs. 202
Date: Thu, 4 Oct 2001 22:27:45 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2771
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: 


 

> -----Original Message-----
> From: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com]
> Sent: Thursday, October 04, 2001 1:17 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] 200 vs. 202
> 
> 
> The Simple presence draft Section 3 states,  "Once authorized, the
> presence agent sends a 202 Accepted response.".  It also 
> states that the
> PA sends an immediate  Notify message.   Section 5.7 states,  "Pending
> occurs when the server cannot obtain authorization ... a pending
> subscription generates a 202 Accepted response". 

Section 3 is in error. It has already been pointed out and has already been
corrected in my running version of -04. The right text is that "If
authorized, the presence agent sends a 200 response"

> 
> For the case of pending authorization,  what is sent 200 or 202? 

202.

> 
> Section  5.7 states that an accepted subscription generates a 200. Now
> if a PA sends a 202 (and an immediate Notify) and the user later
> authorizes the subscription (e.g. manually), is it to send a 200???
> This doesn't make since given 2543 uses the term "final" response for
> 2XX and above. 

No. Lets say the PA has no authorization policy at all. It sends a 202 and a
content-free notify (or something that indicates the status is pending;
yahoo does that). When authorization is obtained, notifications begin with
correct and updated presence state.

> 
> I think some of the answer is that Section 3 is in error and 
> that a 202
> is sent by a PA or a 200 but not both.

Correct.

> If a 202 is sent, the Notify is
> not sent until authorization occurs (i.e. does not have to be
> immediately). 

Compliance with CPIM does require the NOTIFY to be sent even when a 202 is
generated, although I'm not awfully fond of that. 

> If authorization can occur immediately, a 200 is sent
> immediately followed by a Notify. 

Correct.

> Relating to forked subscriptions (5.10), what happens if one of the
> subscribed-to PAs can authorize and wants to send a 200? Does 
> it instead
> send a 202 and immediately send a Notify?  That is, forked-to PAs are
> not allowed to send 200? I presume the PA can tell the 
> request has been
> forked.

I don't understand the problem. Each PUA would decide independely on a
response (200, 202, 600, whatever). The presence server (which is acting as
a proxy now) takes the best response - 200 in this case - and passes it
upstream.

-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

From jdrosen@dynamicsoft.com  Thu Oct  4 22:51:54 2001
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 WAA29264
	for ; Thu, 4 Oct 2001 22:51:49 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f952oU8P026794;
	Thu, 4 Oct 2001 22:50:31 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SN1BG>; Thu, 4 Oct 2001 22:51:34 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brian Stucker'" ,
        Paul Kyzivat
	 ,
        Jonathan Rosenberg 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Updated presence spec
Date: Thu, 4 Oct 2001 22:51:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 13086
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: 


  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Thursday, October 04, 2001 5:22 PM
To: Paul Kyzivat; Jonathan Rosenberg
Cc: 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Updated presence spec


>I would have to agree with Paul on a lot of points. 
>The major concerns that I have with the current draft (and I apologize for
not voicing 
>them earlier, 
>but I hadn't yet looked into the draft to the level I now am involved in)
are two-fold: 
>
>* Migration, as defined in the specification is unreliable without giving a
mechanism to 
>enforce, 
>  using SIP, that the active PA is able to ensure it's the definitive
source of presence 
>information 
>  given the restriction that all of the PUA's are registered. 
>* The lack of a clear definition of how the PUA's are supposed to
communicate with the 
>PA, or the 
>  presence server their presence related attributes (whether this be
caller-prefs in the 
>REGISTER 
>  for migration, or simply publishing the presence document fragments). We
can all think 
>of ways to 
>  do this, I'm particularly worried that we all won't come up with the same
way, and 
>won't be able 
>  to inter-op. Take for example CPL, if someone were to come along today
and try to use 
>CPL in a SIP 
>  network, where is the draft or RFC (that hasn't expired) that states how
to do it? I've 
>searched, and I 
>  couldn't find one. The only reason that I can find that CPL
implementations are inter-
>oping is because 
>  of an expired draft that gave the publication mechanism. 

I agree that the issue of knowing when to register with methods=SUBSCRIBE is
a hard one, as we won't always be able to guarantee it can work. I also
agree we need a way for a PUA to be able to push an explicit presence
document to a presence server for distribution (although whether this is the
document that gets distributed is a matter of policy; more on that below). I
think we can kill both these birds with one stone, based on some ideas
mentioned already on the list and some private discussions I've had.

Forget about this stuff about being definitive. If a PUA has presence to
hand out, it is free to register with methods=SUBSCRIBE. Indeed, it may get
a SUBSCRIBE even if it never did such a registration, since the proxy in
front of it might not support caller preferences. In that case, its free to
accept it.

Consider first the case where a presence server acts as a PA. Its job is to
collect presence information from various components that represent the
presentity, and aggregate them together into a presence document. If a few
clients have registered indicating they support the methods=SUBSCRIBE, the
PA can obtain presence information from those clients by subscribing to them
directly. In this case, the watcher is the presence server itself. The PUA
can each upload presence documents to the presence server in NOTIFY requests
for that subscription. Each PUA only sends the presence information it knows
about. The presence server collects and aggregates these. Everything works
great. We have a standard way for the PUA to send presence documents to the
server (through NOTIFY). 

A presence server SHOULD act as PA whenever it is composing presence data
from multiple independent presence sources. If the PA knows that it is, in
fact, not performing a composition function, but merely passing on presence
documents received from a single PUA, then it can migrate the presence
function to that PUA. In this case, when it gets a SUBSCRIBE, it is proxied
to that single PUA.

This puts the burden of deciding on migration into the presence server,
rather than the client, where it really belongs. Since the presence server
knows what inputs to presence are being used, it also knows whether the
function can in fact be migrated.


>I'd suggest just removing the 
>migration section 
>altogether for now. 

I'm willing to entertain that, but its something that can be done within the
scope of the normative aspects of the specification. Thus, it can be done
even if not documented. Describing it makes some sense, I think, so that its
done right.


>For the second concern, and just to make things inter-operable, can we make
the REGISTER 
>method the ONLY 
>way that PUAs can publish presence information to a PA via SIP? 

Absolutely not. One of the fundamental ideas here is that a PA can collect
many sources of presence data. Some are explicit, where a PUA has said "this
is my presence data", such as the NOTIFY mechanism I proposed above. Others
are implicit, where there is some state in the network that describes a
presentity, even though this state was not established for the sole purpose
of presence. Examples of such implicit presence are registrations and
geolocation information.

How a PA combines the explicit and implicit data it has into a final
presence document is a matter of local policy. We should never dictate that,
nor should we ever dictate what sources can be used to create a presence
document. 

>This wouldn't mandate that you have 
>to use SIP to 
>publish your presence information necessarily, either. Just that if you
want to use SIP, 
>this is the way to 
>do it. I think this is the direction the Donovan draft is going to take us
anyhow. Right? 

By no means was the publish requirements draft aimed at producing a spec
that would eliminate using registrations to derive presence data. The aim
was to produce a spec that would allow a PUA to explicitly upload a presence
document fragment to the server. 

-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: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
Sent: Tuesday, October 02, 2001 10:03 AM 
To: Jonathan Rosenberg 
Cc: 'simple@mailman.dynamicsoft.com' 
Subject: Re: [Simple] Updated presence spec 


Comments below. 
        Paul 
Jonathan Rosenberg wrote: 
> 
> 
> 
> > -----Original Message----- 
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> > Sent: Tuesday, October 02, 2001 9:34 AM 
> > To: Jonathan Rosenberg 
> > Cc: 'simple@mailman.dynamicsoft.com' 
> > Subject: Re: [Simple] Updated presence spec 
> > 
> > 
> > Jonathan, 
> > 
> > You have satisfactorily answered my concerns, but the text doesn't 
> > really reflect what you have said. How about something like the 
> > following: 
> > 
> >  "The first of these phases can occur through configuration, 
> > or through 
> >   dynamic means. One dynamic means for a presence server to discover 
> >   that the function can migrate to a PUA through the REGISTER message. 
> >                                         ^ 
> >                                         is 
> 
> Fixed. 
> 
> >   Specifically, if a PUA wishes to indicate support for the PA 
> >   function, it SHOULD include a contact address in its registration 
> >   with a caller preferences "methods" parameter listing 
> > SUBSCRIBE [13]. 
> >   This indicates that it is capable of terminating and processing 
> >   SUBSCRIBE, and therefore can act as a PA. A PUA MUST NOT do this 
> >                            ^^^                             ^^^^^^^ 
> >                            may be able to                  act as a PA 
> 
> Since a PA is specifically defined for the presence event package, the 
> statement "can" is correct, I believe. In fact, the next sentence
validates 
> that it can, since it MUST NOT perform this registration if it can't. 
I think there is still something wrong here, or at least subject to 
misinterpretation. 
If a PUA wishes to indicate support for the PA function, it can do as 
you say, and it may believe that this indicates that it can act as a PA. 
But the situation is different from the point of view of the registrar 
that is acting as a PA. It receives the register listing the SUBSCRIBE 
method, but it can't know whether this is from a server wishing to act 
as a PA, or simply a server that wants to support some other event 
package. So from the point of view of the registrar, this only means the 
server MAY be able to act as a PA. 
It seems like this has further implications for migration of the PA 
function. If a PA/REGISTRAR receives a registration that suggests the 
possibility of migrating the PA function, it should verify this before 
beginning the migration. It could test it by sending a SUBSCRIBE to the 
candidate PA and awaiting a successful response. 
I think this would work, but it might not be nice for a UAS registering 
to handle subscriptions for some other event package. Every time it 
updates its subscription it might get dinged by PA testing to see if it 
can now handle presence. 
> 
> I fixed "do this" as you describe. I also added text at the end of this 
> paragraph: 
> 
>  Because the ``methods'' parameter does not convey the 
> set of event packages for which the PUA can accept SUBSCRIBE, it is 
> possible that the PUA will begin receiving SUBSCRIBE requests for 
> other packages, possibly ones it doesn't support. As specified in 
> \cite{draft-ietf-sip-events}, the PUA {\SHOULD} reject those requests 
> with a 489. 
Is 489 the best response? What about 305? 
The above paragraph covers PAs that inadvertently receive subscriptions 
for event packages other than presence. Maybe you need a similar 
paragraph for UASs that inadvertently receive subscriptions for 
presence: 
  Similarly it is possible that a server supporting event 
  packages other than presence will receive SUBSCRIBE requests 
  for the presence package. 
> > I am however still concerned with the notion that a PUA can know 
> > definitively that it has complete presence information. Once a PUA as 
> > assumed the role of PA, there is nothing to prevent another UA from 
> > registering with the original proxy, without notifying the PA 
> > of this. I 
> > believe the result will simply be unreliable presence information. 
> 
> There are really only two choices here. The first choice is that we allow 
> multiple PA for a presentity, each of which has access to different
subsets 
> of the presence information. This means that we would need to change the 
> forking behavior, and then mandate that subscribers be able to merge 
> multiple independent presence documents received from multiple sources. We

> discussed that, and elected NOT to do it, since (1) this is a significant 
> burden on the watcher, (2) the correct merging process is very policy 
> specific, and can only be done reasonably at the presentity's domain where

> the policy resides. 
> 
> The second choice is what is documented now - mandate that any PA have 
> complete presence state. Enforcement of that can be difficult, but is
easily 
> done on a system level. Consider, for example, a provider foo.com that is 
> ONLY supporting instant messaging services using SIP. They also provide 
> presence to indicate IM status, and only allow one client registered at a 
> time. Since foo.com owns and runs the whole system, they can be sure that 
> any presence client that has IM status has complete presence state, and 
> therefore there is no problem in migrating subscriptions. 
> 
> Effectively, enforcement of this requirement cannot be done at an element 
> level, but it can be done at a system level. 
> 
> I welcome other ideas on how to improve the story on this. 
This is clearly a hard problem, and I don't claim to have a complete 
answer. Clearly there are special cases where migration can work fine - 
such as when there is only one UAS registered for an address. In other 
cases the safest policy is probably to not do the migration. 
> > I also have a question about the relationship between presence and 
> > callerprefs: 
> > 
> > Suppose a UAS uses callerprefs when registering with a 
> > registrar (using 
> > callerpref parameters on the Contact headers in the REGISTER). And 
> > suppose the registrar is also a PA. Has there been any 
> > consideration for 
> > reporting the callerpref information in the resulting presence 
> > notifications? (I don't see any provision for it now in 
> > draft-ietf-impp-cpim-pidf-00.) 
> 
> Sure, definitely. Not all can be mapped, but many of them have obvious 
> useful presence implications. At one point, we were going to go through
the 
> exercise of mapping the caller prefs parameters to the presence data
format. 
> However, we decided that this mapping is a matter of local implementation.

Why? This simply guarantees a lack of interoperability. 
The mapping of registration to presence provides a base level 
of standardization. To the extent that callerprefs is a standard 
extension to registration, it also ought to map in a standard way. 
_______________________________________________ 
simple mailing list 
simple@mailman.dynamicsoft.com 
http://mailman.dynamicsoft.com/mailman/listinfo/simple 

From hgs@cs.columbia.edu  Fri Oct  5 00:13:43 2001
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 AAA29592
	for ; Fri, 5 Oct 2001 00:13:38 -0400 (EDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id AAA08743;
	Fri, 5 Oct 2001 00:13:12 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id AAA16590;
	Fri, 5 Oct 2001 00:13:08 -0400 (EDT)
Message-ID: <3BBD32C3.D9E7CDF0@cs.columbia.edu>
Date: Fri, 05 Oct 2001 13:10:43 +0900
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Peterson, Jon" 
CC: "'Avshalom@ubique.com'" ,
        Ben Campbell ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: <70565611B164D511957A001083FCDD56478B4E@va02.va.neustar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3981
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: 


"Peterson, Jon" wrote:
> 
> Just to be clear about this, I don't think the IESG has expressed disfavor
> with the paging model (i.e. sending MESSAGEs outside the context of a
> session over the traditional SIP signaling stream). I believe they have
> objected to the creation of an explicit session which then uses SIP MESSAGE

My understanding was that the problem was the use of a non-congestion
controlled delivery mechanism for delivering data of unknown rate and
packet size.

> as a transport mechanism. I think there is a clear difference between these
> alternatives; however, that difference has been obscured by some of the
> hybrid architectures that have been proposed on this list.
> 
> Initially, there was the concept of paging (which operated over the
> signaling network) and chat (which went directly end-to-end). I think there
> was a clear consensus to allow the paging model, and a great deal of
> subsequent discussion about the form that the chat model should take.
> 
> In the midst of this discussion, firewall/NAT traversal and middlebox
> concerns were raised, pointing out correctly that chat would not always be
> end-to-end. I think that a great deal of confusion has arisen from the

> notion that a 'proxy,' either in the sense of a SIP proxy or in the sense of
> a middlebox or stun server or some conflation of these roles, would act as
> an intermediary in chat sessions, modifying and/or re-routing IMs. This has
> led to an argument for sending SIP MESSAGEs in IM sessions in order to use
> their routing headers (like Vias) to navigate network intermediaries.
> 
> Frankly, it has never really been clear to my why, if network conditions
> adverse to the creation of a chat session exist, an IM client can't just
> default to the paging method. If the performance requirements of the network
> make paging infeasible, then something like a stun server could be
> introduced with minimal, if any, impacts to the construction of SIMPLE
> messages. Either way, I haven't yet understood the justification for some
> sort of hybrid chat-of-MESSAGEs-through-proxies session.
> 

If you mean chat-of-MESSAGE-through-SIP-proxies, I agree. If there's a
problem getting direct connectivity, this is a problem for all TCP (and
presumably even more so, UDP-based media). One of the strengths of the
SIP model is the idea that I can transition from a pure MESSAGE chat to
something else, e.g., adding voice. It is very confusing if MESSAGE
works, but then there's no way to set up additional media, some of the
time.

> So if there is a need to keep the sort of information you might have found
> in MESSAGE headers in chat-based IMs, I would argue it should only be for
> session correlation, sequencing and so forth, rather than routing. Perhaps
> all of the information we need here is available (or should be available) in
> the message/cpim MIME type.

The argument for using a SIP MESSAGE format in a session (NOT routed via
proxies) is at least two-fold:

- any implementation already has the SIP parser (and maybe the
compression engine, if needed);

- bridging between page mode and session-mode is very easy (e.g., at a
conference server), without loss of information.  I suspect that this
will be much more common than CPIM, even though this is probably
politically incorrect to say. If you don't have this, you lose
information, as some non-standard headers (or even standard SIP headers,
such as the various *-Info thingies) won't be translatable into CPIM.

A third concern, which may be a non-issue, is whether CPIM is
sufficiently well-specified at this point to actually write parsers.

If you ignore political correctness, what is the advantage of using the
CPIM format? Is it only the extra header overhead and how big,
percentage-wise, would this be? Maybe we should draw up the minimum SIP
MESSAGE format and the corresponding CPIM version to get a better feel
for the trade-offs.

> 
> Jon Peterson
> NeuStar, Inc
> SIMPLE co-chair

From jdrosen@dynamicsoft.com  Fri Oct  5 00:56:54 2001
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 AAA29757
	for ; Fri, 5 Oct 2001 00:56:53 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f954t98P027414;
	Fri, 5 Oct 2001 00:55:09 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4A0SN1H1>; Fri, 5 Oct 2001 00:56:13 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Henning Schulzrinne'" ,
        "Peterson, Jon"
	 
Cc: "'Avshalom@ubique.com'" ,
        Ben Campbell
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Fri, 5 Oct 2001 00:56:13 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 4183
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: 


 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Friday, October 05, 2001 12:11 AM
> To: Peterson, Jon
> Cc: 'Avshalom@ubique.com'; Ben Campbell; 
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] IM over the signaling connection
> 
> 
> > Frankly, it has never really been clear to my why, if 
> network conditions
> > adverse to the creation of a chat session exist, an IM 
> client can't just
> > default to the paging method. If the performance 
> requirements of the network
> > make paging infeasible, then something like a stun server could be
> > introduced with minimal, if any, impacts to the 
> construction of SIMPLE
> > messages. Either way, I haven't yet understood the 
> justification for some
> > sort of hybrid chat-of-MESSAGEs-through-proxies session.
> > 
> 
> If you mean chat-of-MESSAGE-through-SIP-proxies, I agree.

Its worth noting, at least, that chat-of-MESSAGE-through-SIP-proxies is what
has been proposed by numerous people on the list.


> If there's a
> problem getting direct connectivity, this is a problem for 
> all TCP (and
> presumably even more so, UDP-based media). One of the strengths of the
> SIP model is the idea that I can transition from a pure 
> MESSAGE chat to
> something else, e.g., adding voice. It is very confusing if MESSAGE
> works, but then there's no way to set up additional media, some of the
> time.

I agree. We are working through mechanisms to get RTP to work through these
elements, and they inevitably require some kind of forwarding intermediary
for media. So, we would need the same for IM as well. If, based on your
proposal, we use MESSAGE as the transport of IM, when an intermediary is
needed, how is that not a proxy? In that case, once you have decided to use
IM as transport, have you not then decided to do
chat-of-MESSAGE-through-SIP-proxies?

> The argument for using a SIP MESSAGE format in a session (NOT 
> routed via
> proxies) is at least two-fold:
> 
> - any implementation already has the SIP parser (and maybe the
> compression engine, if needed);

I don't think this is a very strong argument. IM needs so few headers that
the parsing is not a major issue. Also, do note that a CPIM message can be
parsed by a SIP parser, as its a valid sip-frag. This was quite on purpose.

> 
> - bridging between page mode and session-mode is very easy (e.g., at a
> conference server), without loss of information.  

If you are doing conferencing, I'm not sure you want page mode at all. There
are things that are quite hard to do (like adding a participant) without a
session model. I don't want to reinvent all that stuff for paging mode.
Doing a "mailing list" kind of function does make sense for paging mode, but
thats hardly a conferencing server.

> If you ignore political correctness, what is the advantage of 
> using the
> CPIM format? Is it only the extra header overhead and how big,
> percentage-wise, would this be? Maybe we should draw up the 
> minimum SIP
> MESSAGE format and the corresponding CPIM version to get a better feel
> for the trade-offs.

IMHO, the benefit of not using SIP as a transport is that these transport
intermediaries can do pure bit level forwarding across connections (stated
more simply, tranport intermediaries can actually operate at the transport
layer). I don't want these intermediaries to even look inside the packet.
The main proponents of the SIP MESSAGE for IM transport argue for it because
they can easily use existing proxies as these intermediaries. These elements
would then need to look at SIP components for forwarding logic. I think
there is a huge difference in ultimate performance between these two cases. 

Whether the headers within this transport are cpim or something new, I
really don't have a strong feeling on that.

-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

From jon.peterson@NeuStar.com  Fri Oct  5 04:28:49 2001
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00451
	for ; Fri, 5 Oct 2001 04:28:49 -0400 (EDT)
Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id f958RZq10457;
	Fri, 5 Oct 2001 04:27:35 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 5 Oct 2001 03:26:16 -0500
Message-ID: <70565611B164D511957A001083FCDD56478B51@va02.va.neustar.com>
From: "Peterson, Jon" 
To: "'Henning Schulzrinne'" 
Cc: "'Avshalom@ubique.com'" ,
        Ben Campbell
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Fri, 5 Oct 2001 03:25:56 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1852
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: 


> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, October 04, 2001 9:11 PM
> To: Peterson, Jon
> Cc: 'Avshalom@ubique.com'; Ben Campbell; 
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] IM over the signaling connection
> 
> 
> 
> 
> "Peterson, Jon" wrote:
> > 
> > Just to be clear about this, I don't think the IESG has 
> expressed disfavor
> > with the paging model (i.e. sending MESSAGEs outside the 
> context of a
> > session over the traditional SIP signaling stream). I 
> believe they have
> > objected to the creation of an explicit session which then 
> uses SIP MESSAGE
> 
> My understanding was that the problem was the use of a non-congestion
> controlled delivery mechanism for delivering data of unknown rate and
> packet size.
> 
>

I think that's only part of it. I hesitate to put words in the IESG's mouth,
but in addition to this issue the transport ADs were also concerned about
the presence of unnecessary headers (just inefficient protocol design) and
as well about the overall precedent set by the use of SIP as a transport
protocol. I think the specter of foo-over-HTTP lampooned in a recent April
fool's RFC (co-authored by one of the transport ADs) suggests something of
the perceived dangers of this sort of precedent. For those that haven't seen
it:

http://www.ietf.org/rfc/rfc3093.txt

Hybrid paging/chat arguments that suggest the use of the MESSAGE method as
transport to aid in firewall traversal are in some respects reminiscent of
the thrust of that document. Once SIP MESSAGEs can be used as transport to
allow IMs to cross network intermediaries, possibly other sorts of
applications could be piggybacked on SIP MESSAGE or INFO methods, and so on.
I believe the IESG doesn't want this sort of law on the books.

Jon Peterson
NeuStar, Inc

 

From lachlan.brazier@siemens.at  Fri Oct  5 04:37:36 2001
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 EAA00509
	for ; Fri, 5 Oct 2001 04:37:19 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f958avu29505;
	Fri, 5 Oct 2001 10:36:57 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id KAA09761;
	Fri, 5 Oct 2001 10:36:56 +0200 (MET DST)
Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta)
	id xma027448; Fri, 5 Oct 01 10:29:42 +0200
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <4JSTG5G5>; Fri, 5 Oct 2001 10:27:24 +0200
Message-ID: 
From: Brazier Lachlan 
To: "'Jonathan Rosenberg'" ,
        "'Brian Stucker'"
	 ,
        "''Neil Deason' '" ,
        "''SIMPLE Mailinglist' '" 
Subject: AW: [Simple] Multiple 200 Ok
Date: Fri, 5 Oct 2001 10:27:18 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 7725
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: 

Hello,

I believe the To header does show who a request was meant for. So, if a PA
receives a request which it could handle, but which it is not authorized to
handle, because it isn't the PA of the user in the To header, which response
would it send back? I would think about either 403 Forbidden, 404 Not Found
or 480 Temporarily Unavailable.


Could the correct awnser be stated in the presence draft?

Lachlan

> 
> >I don't think it's non-sense... 
> >
> >Ugh.. The requestURI bit does cause some serious problems. 
> If you run a
> SUBSCRIBE 
> >through a BBUA, that can change the requestURI as well. 
> Yuck. Why don't we
> consider 
> >the TO party the presentity instead, and change the wording 
> in the first
> paragraph 
> >of section 5.3 to reflect that? Then it becomes a lot nicer. 
> In that case,
> if 
> >the user in the TO of the SUBSCRIBE is not a user served 
> >by the presence agent that the subscribe was forked to, that 
> presence agent
> 
> >should 603 the SUBSCRIBE.
> 
> Absolutely, positively NOT.
> 
> It is fundamental to the entire SIP model that a request can 
> traverse many
> hops (proxies), each hop modifying the request URI based on 
> local policy,
> ultimately reaching a recipient. Any particular hop can only 
> make routing
> and processing decisions if the target of the request is within the
> namespace managed by that hop. What you are proposing would 
> violate that,
> and break the protocol, both SIP and SIMPLE, totally. 
> 
> Yes, it is helpful to know who that recipient ultimately is. 
> The COntact
> header in the 2xx, as I have already stated, provides some 
> form of identity.
> Even better is the Remote-Party-ID header from the privacy extension. 
> 
> >In essence, don't use the requestURI for establishing 
> >the identity of the presentity on the actual presence agent. 
> It could go
> through 
> >a BBUA or fork to another user (as you suggest) and get 
> munged along the
> way, so 
> >use it just for routing purposes. 
> 
> Wrong.
> 
> >I think that'll fix it. Presence agents shouldn't accept 
> subscriptions just
> because 
> >they understand how to process a SUBSCRIBE and the 
> requestURI matches them.
> 
> >They need to also take into account who they are authorized 
> to represent
> the 
> >presence for when deciding to accept a SUBSCRIBE or not. 
> 
> Generally, if a server receives a request, its because some chain of
> processing decisions along the way decided that this server is indeed
> ideally suited for doing that. The server can decide not to, 
> and the purpose
> of the To field is to provide information to allow it to make 
> that decision
> if it chooses. The same holds for INVITE. 
> 
> >The other reason that I can think of, and this ties in somewhat with
> migration problems, 
> >is if we consider the presence agent for the presentity to 
> be the presence
> server. If 
> >a presence server is in the network, clients can't always be 
> expected to
> know the 
> >requestURI of the presence server that's serving the 
> presentity they're
> interested in 
> >watching. The requestURI would start out (I would think, in 
> general) equal
> to the TO 
> >header URI, which would be the user@domain address of the 
> presentity. A
> proxy along 
> >the way would have to notice that this is a presence 
> subscription, and
> change the 
> >requestURI to be the presence server before forwarding it, 
> or the presence
> server 
> >would always have to be included in the list of registered 
> contacts for the
> user (which 
> >may require the presence server to make a third party 
> registration to the
> presentity). 
> 
> This makes no sense whatsoever.
> 
> -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: Wednesday, October 03, 2001 1:51 AM 
> To: 'Jonathan Rosenberg '; Brazier Lachlan; ''Neil Deason' '; 
> ''SIMPLE 
> Mailinglist' ' 
> Subject: AW: [Simple] Multiple 200 Ok 
> 
> 
>  Hello, 
> as far as I see, the problem lays in the registration. Is 
> there a way to 
> tell a registrar, that the registered address belongs to a 
> different user? 
> I really believe a subscriber should know if he is subscribed 
> to the right 
> person. As example imagine a subscriber, who subscribes for 
> you, and when 
> you are online, sends you private documents automaticly. You 
> probably don't 
> want this to happen. 
> I think the same might be true for INVITE. Imagine a video 
> service, where a 
> video provider starts a video session, without knowing that 
> you are not the 
> right customer, and not knowing that you are on holiday. (An 
> example would 
> be a timed wakeup call or something like this) 
> A solution I might think of, is to add a new parameter to the Contact 
> header, indicating if I am really the user addressed to, or 
> in a REGISTER 
> request, to tell the registrar if the registered address 
> "belongs" to me or 
> a different user at all. 
> Is this nonsense I am talking? 
> Lachlan 
> -----Originalnachricht----- 
> Von: Jonathan Rosenberg 
> An: 'Brazier Lachlan'; Jonathan Rosenberg; 'Neil Deason'; 'SIMPLE 
> Mailinglist' 
> Gesendet: 03.10.01 04:38 
> Betreff: RE: [Simple] Multiple 200 Ok 
> 
> 
> 
>  
> > -----Original Message----- 
> > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] 
> > Sent: Tuesday, October 02, 2001 12:03 PM 
> > To: 'Jonathan Rosenberg'; 'Neil Deason'; 'SIMPLE Mailinglist' 
> > Subject: AW: [Simple] Multiple 200 Ok 
> > 
> > 
> > Hello, 
> > thank you for your clarification. There is still this one 
> point open: 
> > 
> > > > > How can a 
> > > > > subscriber realize, that 
> > > > > a forking proxy forked to a different user (this can happen 
> > > > > when I am on 
> > > > > holiday, and I register my working collegue with my working 
> > > > > SIP Url - and 
> > > > > then somebody wants to subscribe for me)? 
> > 
> > 
> > I believe, the problem can occur, when a proxy changes the 
> > request-URI. This 
> > would mean, that the proxy sends a SUBSCRIBE to another 
> > presentity. 
> Changing the request URI does not imply chaging the 
> presentity. Changing 
> it 
> may occur in order to address the request to the presentity at a 
> different 
> location. 
> 
> 
> I still 
> > can't see, how the subscriber knows, that his SUBSCRIBE 
> > request was handled 
> > by a different user. 
> The entity that finally responds to the SUBSCRIBE will place, in the 
> 2xx, a 
> Contact header that contains their URL. 
> 
> 
> > 
> > I could imagine, that in the first NOTIFY after receiving the 
> > SUBSCRIBE 
> > request, the FROM header is different than the To header from 
> > the SUBSCRIBE 
> > request. Is this valid with the draft? 
> No; as it stands, the To/From are flipped in the NOTIFY from the 
> presentity. 
> 
> 
> -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 ndeason@ubiquity.net  Fri Oct  5 05:45:32 2001
Received: from drago1.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 FAA00737
	for ; Fri, 5 Oct 2001 05:45:31 -0400 (EDT)
Received: from mailhost.ubiquity.net by drago1.ubiquity.net
          via smtpd (for [63.113.40.50]) with SMTP; 5 Oct 2001 09:45:21 UT
Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600);
	 Fri, 5 Oct 2001 10:43:53 +0100
From: "Neil Deason" 
To: "Brazier Lachlan" ,
        "'Jonathan Rosenberg'" ,
        "'Brian Stucker'" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Fri, 5 Oct 2001 10:43:53 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: 
X-OriginalArrivalTime: 05 Oct 2001 09:43:53.0617 (UTC) FILETIME=[3EB43810:01C14D82]
Content-Length: 1656
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: 

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
>
> Hello,
> 
> I believe the To header does show who a request was meant 
> for. So, if a PA
> receives a request which it could handle, but which it is not 
> authorized to
> handle, because it isn't the PA of the user in the To header, 
> which response
> would it send back? I would think about either 403 Forbidden, 
> 404 Not Found
> or 480 Temporarily Unavailable.
>
> Could the correct awnser be stated in the presence draft?

Your implementation could respond in this fashion without
adding any complication to the spec. But you should
think about why the PUA is receiving the SUBSCRIBE in the
1st place. If say REGISTER is being used to set up routing
logic for presence subscriptions this means that a third
party must have sent a REGISTER request naming the target
of the subscription in the To header and themselves as a
Contact with a "methods" parameter containing SUBSCRIBE.
In any sensible system this would have to be authenticated
and authorised to prevent identity hijacking for presence,
voice sessions etc. If as the subscriber you want to be 
sure that the responder for presence is the party you were
expecting, and not an authenticated party they have authorised
to act on their behalf, you can look at the Contact headers of 
the NOTIFY request(s) that come in. Of course there has to be
an element of trust here. If you are not satisfied use
the beauty of a converged application to INVITE them to
conference with a voice recognition system ;)

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

> >
 

From pkyzivat@cisco.com  Fri Oct  5 09:05:50 2001
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 JAA01351
	for ; Fri, 5 Oct 2001 09:05:49 -0400 (EDT)
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 f95D4vC18122;
	Fri, 5 Oct 2001 09:05:01 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB43660 (AUTH pkyzivat);
	Fri, 5 Oct 2001 09:06:55 -0400 (EDT)
Message-ID: <3BBDAFBB.1C6F2A2C@cisco.com>
Date: Fri, 05 Oct 2001 09:03:55 -0400
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: "'Moran Tim (NET/Dallas)'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] 200 vs. 202
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 783
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: 

Jonathan Rosenberg wrote:
> 
> > Relating to forked subscriptions (5.10), what happens if one of the
> > subscribed-to PAs can authorize and wants to send a 200? Does
> > it instead
> > send a 202 and immediately send a Notify?  That is, forked-to PAs are
> > not allowed to send 200? I presume the PA can tell the
> > request has been
> > forked.
> 
> I don't understand the problem. Each PUA would decide independely on a
> response (200, 202, 600, whatever). The presence server (which is acting as
> a proxy now) takes the best response - 200 in this case - and passes it
> upstream.

This seems a little surprising. Wouldn't a proxy normally pass the first
200 class response upstream and cancel the rest? Doing otherwise
requires
the proxy to treat SUBSCRIBE specially.

	Paul

From lachlan.brazier@siemens.at  Fri Oct  5 09:11:14 2001
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 JAA01398
	for ; Fri, 5 Oct 2001 09:11:13 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f95DAwu30560;
	Fri, 5 Oct 2001 15:10:58 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id PAA11274;
	Fri, 5 Oct 2001 15:10:57 +0200 (MET DST)
Received: from vies141a.sie.siemens.at(158.226.134.117) by scesie13 via smap (V2.0beta)
	id xma010711; Fri, 5 Oct 01 15:10:24 +0200
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <4JSR8B2N>; Fri, 5 Oct 2001 15:10:22 +0200
Message-ID: 
From: Brazier Lachlan 
To: "'Neil Deason'" ,
        Brazier Lachlan
	 ,
        "'Jonathan Rosenberg'"
	 ,
        "'Brian Stucker'" ,
        "''SIMPLE Mailinglist' '" 
Subject: AW: [Simple] Multiple 200 Ok
Date: Fri, 5 Oct 2001 15:10:22 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3601
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA01398
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: 

Hi,

generally I agree with you about Authorisation and Authentication. 

Let me reformulate the question. Which response do I send back, when I
received a SUBSCRIBE, and I'm not allowed or not willing to be the
presentity (This can happen if someone defines me as presentity without
letting me know - as the way of authorization is not in the scope of the
presence draft, errors might happen)?

----------------------------------

I have a question concerning the Call flows in the draft.
When a PA receives a SUBSCRIBE with an Expires header, the response contains
an Expires header as well. What would an Expires header in a NOTIFY request
sent from the PA to the Watcher mean? Would this update the subscription
expiration time?

An example: 
userA subscribes for user userB. As userB is a friend of userA, he accepts
the subscription and the call flows just get on.
After some time userB doesn't want to be the presentity of userA anymore, or
maybe userB changes the contact information for the SUBSCRIBE request at
it's registrar. 
Now, can userB (better said the PA of userB) send a NOTIFY with an Expires
header with value 0 to tell userA, that it's subscription expiration time is
over?

I think it should be possible to do so, because if not, userB would need to
wait for the next SUBSCRIBE request from userA, before he can tell him, that
the subscription time is over. This could be a time value from seconds to
days, month, years, etc.


If there is another mechanism to do so, which one would it be? Maybe a
NOTIFY with an empty body?

Greetings
Lachlan

---------------------


> -----Ursprüngliche Nachricht-----
> Von: Neil Deason [mailto:ndeason@ubiquity.net]
> Gesendet am: Freitag, 05. Oktober 2001 11:44
> An: Brazier Lachlan; 'Jonathan Rosenberg'; 'Brian Stucker'; ''SIMPLE
> Mailinglist' '
> Betreff: RE: [Simple] Multiple 200 Ok
> 
> > -----Original Message-----
> > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> >
> > Hello,
> > 
> > I believe the To header does show who a request was meant 
> > for. So, if a PA
> > receives a request which it could handle, but which it is not 
> > authorized to
> > handle, because it isn't the PA of the user in the To header, 
> > which response
> > would it send back? I would think about either 403 Forbidden, 
> > 404 Not Found
> > or 480 Temporarily Unavailable.
> >
> > Could the correct awnser be stated in the presence draft?
> 
> Your implementation could respond in this fashion without
> adding any complication to the spec. But you should
> think about why the PUA is receiving the SUBSCRIBE in the
> 1st place. If say REGISTER is being used to set up routing
> logic for presence subscriptions this means that a third
> party must have sent a REGISTER request naming the target
> of the subscription in the To header and themselves as a
> Contact with a "methods" parameter containing SUBSCRIBE.
> In any sensible system this would have to be authenticated
> and authorised to prevent identity hijacking for presence,
> voice sessions etc. If as the subscriber you want to be 
> sure that the responder for presence is the party you were
> expecting, and not an authenticated party they have authorised
> to act on their behalf, you can look at the Contact headers of 
> the NOTIFY request(s) that come in. Of course there has to be
> an element of trust here. If you are not satisfied use
> the beauty of a converged application to INVITE them to
> conference with a voice recognition system ;)
> 
> Cheers,
> Neil.
> --
> Ubiquity Software Corporation, UK        http://www.ubiquity.net
> 
> > >
>  
> 

From hgs@cs.columbia.edu  Fri Oct  5 09:22:49 2001
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 JAA01477
	for ; Fri, 5 Oct 2001 09:22:49 -0400 (EDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA19049;
	Fri, 5 Oct 2001 09:22:39 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id JAA20304;
	Fri, 5 Oct 2001 09:22:36 -0400 (EDT)
Message-ID: <3BBDB38A.7507A224@cs.columbia.edu>
Date: Fri, 05 Oct 2001 22:20:10 +0900
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Peterson, Jon" 
CC: "'Henning Schulzrinne'" ,
        "'Avshalom@ubique.com'" ,
        Ben Campbell ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: <70565611B164D511957A001083FCDD56478B51@va02.va.neustar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 305
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: 

I'm not proposing to use SIP as "transport", but simply as a message
format, carried over TCP or similar reliable, congestion-controlled
protocol. The SIP transport properties (retransmission, etc.) do not
apply here. I fail to see why CPIM-over-TCP is any different in this
regard than MESSAGE-over-TCP.

From bcampbell@dynamicsoft.com  Fri Oct  5 09:49:18 2001
Received: from localhost.localdomain ([63.110.3.232])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01583
	for ; Fri, 5 Oct 2001 09:49:17 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f95DgdS01413;
	Fri, 5 Oct 2001 08:42:39 -0500
Message-ID: <3BBDB8CF.7000706@dynamicsoft.com>
Date: Fri, 05 Oct 2001 08:42:39 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Henning Schulzrinne'" ,
        "Peterson, Jon" ,
        "'Avshalom@ubique.com'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 413
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: 

Jonathan Rosenberg wrote:

[snip]


> 
> I don't think this is a very strong argument. IM needs so few headers
> that the parsing is not a major issue. Also, do note that a CPIM message
> can be parsed by a SIP parser, as its a valid sip-frag. This was quite
> on purpose.


Also consider that an IM endpoint _must_ already have a CPIM parser, 
since message/cpim is a required-to-implement feature.


[snip]





From bcampbell@dynamicsoft.com  Fri Oct  5 10:01:07 2001
Received: from localhost.localdomain ([63.110.3.232])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01651
	for ; Fri, 5 Oct 2001 10:01:06 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f95DtXS01440;
	Fri, 5 Oct 2001 08:55:33 -0500
Message-ID: <3BBDBBD5.8040107@dynamicsoft.com>
Date: Fri, 05 Oct 2001 08:55:33 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Avshalom@ubique.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1688
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: 

Avshalom@ubique.com wrote:

> We have got the following wording:
> 
> <<<
> The IESG has some concerns that this mechanism constitutes the use of SIP
> as a transport protocol. In other words, once the session has been
> established
> between the two endpoints by the INVITE, if the MESSAGEs can only go
> directly end-to-end, then their headers and related protocol apparatus are
> entirely superfluous and may do more harm than good. We saw during the
> meeting last week that there were definitely some pitfalls to allowing
> methods other than MESSAGE across the IM stream (as well as questions about
> overlapping transactions, redirection, forking, and so forth), and it isn't
> clear that the overhead is justified if MESSAGE is just an envelope for its
> encapsulated MIME payload. The IESG was particularly concerned, in addition
> to the protocol overhead, with congestion characteristics of the messaging
> session and with the precedent that could be set by using SIP in this
> fashion.
> 
> 
> I am not sure if the IESG objects to the use of SIP as transport due to:
> 1. The signalling connection is for signalling only and not for any media.
> 2. The overhead it will cause to the protocol.
> 3. The superfluos headers.
> 
> If it is 1, then why a single MESSAGE is allowed? if it 2 or 3, then we can
> limit the usage when the
> session is held over the signaling connection.
> 

The wording mentions 1 and 3 specifically. As far as why we allow 
page-model MESSAGE, there is some belief that chat sessions will 
typically involve more traffic (lots of short messages) than individual 
page-model messaging will.

I do not understand what you mean by limiting the usage.


From petkos@cs.columbia.edu  Fri Oct  5 10:12:15 2001
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 KAA01714
	for ; Fri, 5 Oct 2001 10:12:15 -0400 (EDT)
Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA22025
	for ; Fri, 5 Oct 2001 10:12:05 -0400 (EDT)
Received: (from petkos@localhost)
	by disco.cs.columbia.edu (8.9.3/8.9.3) id KAA06130
	for simple@mailman.dynamicsoft.com; Fri, 5 Oct 2001 10:12:05 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110051412.KAA06130@disco.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Fri, 5 Oct 2001 10:12:05 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1440
Subject: [Simple] IM over the signaling connection
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: 

>> - any implementation already has the SIP parser (and maybe the
>> compression engine, if needed);

>I don't think this is a very strong argument. IM needs so few 
>headers that the parsing is not a major issue. 
>Also, do note that a CPIM message can be parsed by a 
>SIP parser, as its a valid sip-frag. This was quite on purpose.

Actually, they have same header names in CPIM and SIP but different
syntax (like Date and Subject, probably others too). CPIM is rather
complex and big format.

Also, what is the difference between CPIM and SIP if they are used
only as an encapsulation format?

SIP has some extra features and some people have proposed to use those
features also, but we don't have to use them..


>I hesitate to put words in the IESG's mouth, but in addition 
> to this issue the transport ADs were also concerned about
> the presence of unnecessary headers (just inefficient protocol design) 
> and as well about the overall precedent set by the use of SIP as 
> a transport

As said earlier, you don't have to use every header from SIP spec.
Comparing mandatory CPIM headers and SIP headers for IM seems to
indicate that CPIM has more overhead than SIP.


>Also consider that an IM endpoint _must_ already have a 
>CPIM parser, since message/cpim is a 
>required-to-implement feature

I'm not sure at all if this means that all terminals must implement CPIM.
They have SIP there already. No need for CPIM.

--
Petri

From petkos@cs.columbia.edu  Fri Oct  5 10:32:57 2001
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 KAA01820
	for ; Fri, 5 Oct 2001 10:32:57 -0400 (EDT)
Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA23460
	for ; Fri, 5 Oct 2001 10:32:46 -0400 (EDT)
Received: (from petkos@localhost)
	by disco.cs.columbia.edu (8.9.3/8.9.3) id KAA06803
	for simple@mailman.dynamicsoft.com; Fri, 5 Oct 2001 10:32:46 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110051432.KAA06803@disco.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Fri, 5 Oct 2001 10:32:46 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1706
Subject: [Simple] Comparing CPIM and SIP 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: 


There have been a lot of statements that SIP has far more overhead 
than CPIM. This is absolutely not true. See examples below:
Sending an IM with "hello world!". 

CPIM example taken from cpim-draft.
It has probably some not-so-important headers like MyFeatures*.
Note that at least Subject and Date CPIM header have new syntax
so this is incompatibility with SIP spec.

It seems that they have similar message size, depending whether
some special headers are used. In many cases CPIM has more 
overhead than SIP.

So, I don't think that message size or unnecessary headers 
are an issue here. 
Also, CPIM is still work-in-progress while SIP is ready and will
surely be implemented everywhere.


CPIM example:


m: Content-type: message/cpim
s:
h: From: MR SANDERS 
h: To: Depressed Donkey 
h: Date: 2000-12-13T13:40:00-08:00
h: Subject: the weather will be fine today
h: Subject:;lang=fr beau temps prevu pour aujourd'hui
h: NS: MyFeatures 
h: Require: MyFeatures.VitalMessageOption
h: MyFeatures.VitalMessageOption: Confirmation-requested
h: MyFeatures.WackyMessageOption: Use-silly-font
s:
e: Content-type: text/xml; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: 
e: Hello World!
e: 



Similar example with SIP MESSAGE:

MESSAGE sip:eeyore@100akerwood.com SIP/2.0
Via: SIP/2.0/UDP 128.59.19.106:5060
CSeq: 1 MESSAGE
Contact: sip:eeyore@128.59.19.106:5060
From: MR SANDERS 
Date: Fri, 05 Oct 2001 14:16:58 GMT
Call-ID: 472466106@128.59.19.106
Content-Type: text/plain
To: Depressed Donkey 
Content-Length: 13

Hello world!




--
Petri

From Avshalom@ubique.com  Fri Oct  5 10:34:12 2001
Received: from ubqgate02.lotus.com (outbound-pat-address.lotus.co.uk [194.196.39.50])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01851
	for ; Fri, 5 Oct 2001 10:34:10 -0400 (EDT)
From: Avshalom@ubique.com
Subject: Re: [Simple] IM over the signaling connection
To: Ben Campbell 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
Date: Fri, 5 Oct 2001 16:32:26 +0200
X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at
 05/10/2001 16:32:52
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 3812
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: 

> The wording mentions 1 and 3 specifically. As far as why we allow
> page-model MESSAGE, there is some belief that chat sessions will
> typically involve more traffic (lots of short messages) than individual
> page-model messaging will.

What can happen if a session would not be allowed on the signaling
connection
is that people will send everything using page-model MESSAGE, even messages
that
would normally be part of a session. Using a session can save a lot of
headers
since a session id will replace some of the headers and maybe other methods
of
saving bandwidth can be deployed. Thus, permitting MESSAGEs of a session
over the
signaling connection can benefit the protocol rather then the opposite.
Limiting the size and rate of messages in the session negotiation will
help proxies and servers to know what bandwidth to expect and they can
prohibit
sessions that are too big. page-model MESSAGE will not give them these
capabilities.

> I do not understand what you mean by limiting the usage.

I meant limiting the size of the messages in the session negotiation.
Reading your
mail a rate limit seems also reasonable.

avshalom
Sametime/Lotus/IBM




                                                                                                                       
                    Ben Campbell                                                                                       
                                   cc:     simple@mailman.dynamicsoft.com                                    
                                             Subject:     Re: [Simple] IM over the signaling connection                
                    05/10/2001 15:55                                                                                   
                                                                                                                       
                                                                                                                       



Avshalom@ubique.com wrote:

> We have got the following wording:
>
> <<<
> The IESG has some concerns that this mechanism constitutes the use of SIP
> as a transport protocol. In other words, once the session has been
> established
> between the two endpoints by the INVITE, if the MESSAGEs can only go
> directly end-to-end, then their headers and related protocol apparatus
are
> entirely superfluous and may do more harm than good. We saw during the
> meeting last week that there were definitely some pitfalls to allowing
> methods other than MESSAGE across the IM stream (as well as questions
about
> overlapping transactions, redirection, forking, and so forth), and it
isn't
> clear that the overhead is justified if MESSAGE is just an envelope for
its
> encapsulated MIME payload. The IESG was particularly concerned, in
addition
> to the protocol overhead, with congestion characteristics of the
messaging
> session and with the precedent that could be set by using SIP in this
> fashion.
>
>
> I am not sure if the IESG objects to the use of SIP as transport due to:
> 1. The signalling connection is for signalling only and not for any
media.
> 2. The overhead it will cause to the protocol.
> 3. The superfluos headers.
>
> If it is 1, then why a single MESSAGE is allowed? if it 2 or 3, then we
can
> limit the usage when the
> session is held over the signaling connection.
>

The wording mentions 1 and 3 specifically. As far as why we allow
page-model MESSAGE, there is some belief that chat sessions will
typically involve more traffic (lots of short messages) than individual
page-model messaging will.

I do not understand what you mean by limiting the usage.






From bcampbell@dynamicsoft.com  Fri Oct  5 10:34:46 2001
Received: from localhost.localdomain ([63.110.3.232])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01857
	for ; Fri, 5 Oct 2001 10:34:45 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f95ESYS01507;
	Fri, 5 Oct 2001 09:28:34 -0500
Message-ID: <3BBDC392.3060701@dynamicsoft.com>
Date: Fri, 05 Oct 2001 09:28:34 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Henning Schulzrinne 
CC: "Peterson, Jon" ,
        "'Avshalom@ubique.com'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: <70565611B164D511957A001083FCDD56478B4E@va02.va.neustar.com> <3BBD32C3.D9E7CDF0@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 660
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: 

[snip]

> 
> A third concern, which may be a non-issue, is whether CPIM is
> sufficiently well-specified at this point to actually write parsers.
> 


It better be, as it is a must-implement feature for a SIMPLE IM end-point.


> If you ignore political correctness, what is the advantage of using the
> CPIM format? Is it only the extra header overhead and how big,
> percentage-wise, would this be? Maybe we should draw up the minimum SIP
> MESSAGE format and the corresponding CPIM version to get a better feel
> for the trade-offs.
> 


Considering that the SIP MESSAGE message is likely to carry a 
message/cpim body, then it is by definition larger.





From bstucker@nortelnetworks.com  Fri Oct  5 10:51:16 2001
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 KAA01971
	for ; Fri, 5 Oct 2001 10:51:16 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA00457
	for ; Fri, 5 Oct 2001 09:50:56 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Fri, 5 Oct 2001 09:50:29 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 5 Oct 2001 09:50:37 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E410B64@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Jonathan Rosenberg ,
        Paul Kyzivat ,
        Jonathan Rosenberg 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] Updated presence spec
Date: Fri, 5 Oct 2001 09:50:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14DAD.1C8A4830"
Content-Length: 22417
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: 

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_01C14DAD.1C8A4830
Content-Type: text/plain;
	charset="iso-8859-1"

If any PUA is allowed to respond to a SUBSCRIBE, then I think the forking
rules
may cause problems for us. Two questions I would have are:

1. How does the presence server get inserted into the contact list of the
presentity in order to ensure that it sees any inbound SUBSCRIBE requests
for
the user it is serving? Not all proxies are going to be aware of the
presence
server, so would it be the job of the PUA's to register the presence server
as
an additional contact?

2. If a SUBSCRIBE did fork, and it's a free-for-all as to who can respond to
it,
then doesn't this create a race-condition between PA's that have a complete
picture
of the user's presence, and PA's that don't? It would be whomever sends back
the
200 OK the fastest would win out, and you'd wind up with erratic presence
functionality.
Sometimes you'd get the whole picture, sometimes you wouldn't.

...

Using the NOTIFY to publish information from the PUA's to the PA isn't such
a bad idea.
My concerns there would be:

1. How do I push presence information into the network? The network would
have to first
subscribe to my PUA so it could send the NOTIFY.

2. Would we use the same event package for PUA<->PA communication that's
used for PA<->Watcher
communication? If NOTIFY is used, I would argue that we probably shouldn't
use the same event
package so PUA's that don't want to be a PA can discern between a request
for presence information
from a PA, and one from a watcher. The difference being, if a PA is asking
for it, then the PUA can
assume that the presence information is going to be aggregated, whereas with
a watcher, it's not. 

On using the REGISTER, instead of it being the ONLY way, how about making it
the standard way?
People can still send in presence information using NOTIFY, or INVITE, or
whatever else they 
want to use. Just that they need to support at least REGISTER as one of the
ways that they 
publish presence into the network.

...

There's an additional element that is worrying me with migration of the PA
in it's current form.
It leaves additional non-contributory nodes in the routeset between the
watcher
and the PA after a migration has been performed. That worries me. 
Is there a solution to address this that can be put into the draft if the
sections are left in?

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, October 04, 2001 9:51 PM
To: Stucker, Brian [NGB:B621:EXCH]; Paul Kyzivat; Jonathan Rosenberg
Cc: 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Updated presence spec




  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Thursday, October 04, 2001 5:22 PM
To: Paul Kyzivat; Jonathan Rosenberg
Cc: 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] Updated presence spec


>I would have to agree with Paul on a lot of points. 
>The major concerns that I have with the current draft (and I apologize for
not voicing 
>them earlier, 
>but I hadn't yet looked into the draft to the level I now am involved in)
are two-fold: 
>
>* Migration, as defined in the specification is unreliable without giving a
mechanism to 
>enforce, 
>  using SIP, that the active PA is able to ensure it's the definitive
source of presence 
>information 
>  given the restriction that all of the PUA's are registered. 
>* The lack of a clear definition of how the PUA's are supposed to
communicate with the 
>PA, or the 
>  presence server their presence related attributes (whether this be
caller-prefs in the 
>REGISTER 
>  for migration, or simply publishing the presence document fragments). We
can all think 
>of ways to 
>  do this, I'm particularly worried that we all won't come up with the same
way, and 
>won't be able 
>  to inter-op. Take for example CPL, if someone were to come along today
and try to use 
>CPL in a SIP 
>  network, where is the draft or RFC (that hasn't expired) that states how
to do it? I've 
>searched, and I 
>  couldn't find one. The only reason that I can find that CPL
implementations are inter-
>oping is because 
>  of an expired draft that gave the publication mechanism. 

I agree that the issue of knowing when to register with methods=SUBSCRIBE is
a hard one, as we won't always be able to guarantee it can work. I also
agree we need a way for a PUA to be able to push an explicit presence
document to a presence server for distribution (although whether this is the
document that gets distributed is a matter of policy; more on that below). I
think we can kill both these birds with one stone, based on some ideas
mentioned already on the list and some private discussions I've had.

Forget about this stuff about being definitive. If a PUA has presence to
hand out, it is free to register with methods=SUBSCRIBE. Indeed, it may get
a SUBSCRIBE even if it never did such a registration, since the proxy in
front of it might not support caller preferences. In that case, its free to
accept it.

Consider first the case where a presence server acts as a PA. Its job is to
collect presence information from various components that represent the
presentity, and aggregate them together into a presence document. If a few
clients have registered indicating they support the methods=SUBSCRIBE, the
PA can obtain presence information from those clients by subscribing to them
directly. In this case, the watcher is the presence server itself. The PUA
can each upload presence documents to the presence server in NOTIFY requests
for that subscription. Each PUA only sends the presence information it knows
about. The presence server collects and aggregates these. Everything works
great. We have a standard way for the PUA to send presence documents to the
server (through NOTIFY). 

A presence server SHOULD act as PA whenever it is composing presence data
from multiple independent presence sources. If the PA knows that it is, in
fact, not performing a composition function, but merely passing on presence
documents received from a single PUA, then it can migrate the presence
function to that PUA. In this case, when it gets a SUBSCRIBE, it is proxied
to that single PUA.

This puts the burden of deciding on migration into the presence server,
rather than the client, where it really belongs. Since the presence server
knows what inputs to presence are being used, it also knows whether the
function can in fact be migrated.


>I'd suggest just removing the 
>migration section 
>altogether for now. 

I'm willing to entertain that, but its something that can be done within the
scope of the normative aspects of the specification. Thus, it can be done
even if not documented. Describing it makes some sense, I think, so that its
done right.


>For the second concern, and just to make things inter-operable, can we make
the REGISTER 
>method the ONLY 
>way that PUAs can publish presence information to a PA via SIP? 

Absolutely not. One of the fundamental ideas here is that a PA can collect
many sources of presence data. Some are explicit, where a PUA has said "this
is my presence data", such as the NOTIFY mechanism I proposed above. Others
are implicit, where there is some state in the network that describes a
presentity, even though this state was not established for the sole purpose
of presence. Examples of such implicit presence are registrations and
geolocation information.

How a PA combines the explicit and implicit data it has into a final
presence document is a matter of local policy. We should never dictate that,
nor should we ever dictate what sources can be used to create a presence
document. 

>This wouldn't mandate that you have 
>to use SIP to 
>publish your presence information necessarily, either. Just that if you
want to use SIP, 
>this is the way to 
>do it. I think this is the direction the Donovan draft is going to take us
anyhow. Right? 

By no means was the publish requirements draft aimed at producing a spec
that would eliminate using registrations to derive presence data. The aim
was to produce a spec that would allow a PUA to explicitly upload a presence
document fragment to the server. 

-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_01C14DAD.1C8A4830
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Updated presence spec




If any PUA is allowed to respond to a SUBSCRIBE, then I think the forking rules

may cause problems for us. Two questions I would have are:




1. How does the presence server get inserted into the contact list of the

presentity in order to ensure that it sees any inbound SUBSCRIBE requests for

the user it is serving? Not all proxies are going to be aware of the presence

server, so would it be the job of the PUA's to register the presence server as

an additional contact?




2. If a SUBSCRIBE did fork, and it's a free-for-all as to who can respond to it,

then doesn't this create a race-condition between PA's that have a complete picture

of the user's presence, and PA's that don't? It would be whomever sends back the

200 OK the fastest would win out, and you'd wind up with erratic presence functionality.

Sometimes you'd get the whole picture, sometimes you wouldn't.




...




Using the NOTIFY to publish information from the PUA's to the PA isn't such a bad idea.

My concerns there would be:




1. How do I push presence information into the network? The network would have to first

subscribe to my PUA so it could send the NOTIFY.




2. Would we use the same event package for PUA<->PA communication that's used for PA<->Watcher

communication? If NOTIFY is used, I would argue that we probably shouldn't use the same event

package so PUA's that don't want to be a PA can discern between a request for presence information

from a PA, and one from a watcher. The difference being, if a PA is asking for it, then the PUA can

assume that the presence information is going to be aggregated, whereas with a watcher, it's not. 




On using the REGISTER, instead of it being the ONLY way, how about making it the standard way?

People can still send in presence information using NOTIFY, or INVITE, or whatever else they 

want to use. Just that they need to support at least REGISTER as one of the ways that they 

publish presence into the network.




...




There's an additional element that is worrying me with migration of the PA in it's current form.

It leaves additional non-contributory nodes in the routeset between the watcher

and the PA after a migration has been performed. That worries me. 

Is there a solution to address this that can be put into the draft if the sections are left in?




Brian




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Thursday, October 04, 2001 9:51 PM

To: Stucker, Brian [NGB:B621:EXCH]; Paul Kyzivat; Jonathan Rosenberg

Cc: 'simple@mailman.dynamicsoft.com'

Subject: RE: [Simple] Updated presence spec










  

-----Original Message-----

From: Brian Stucker [mailto:bstucker@nortelnetworks.com]

Sent: Thursday, October 04, 2001 5:22 PM

To: Paul Kyzivat; Jonathan Rosenberg

Cc: 'simple@mailman.dynamicsoft.com'

Subject: RE: [Simple] Updated presence spec






>I would have to agree with Paul on a lot of points. 

>The major concerns that I have with the current draft (and I apologize for

not voicing 

>them earlier, 

>but I hadn't yet looked into the draft to the level I now am involved in)

are two-fold: 

>

>* Migration, as defined in the specification is unreliable without giving a

mechanism to 

>enforce, 

>  using SIP, that the active PA is able to ensure it's the definitive

source of presence 

>information 

>  given the restriction that all of the PUA's are registered. 

>* The lack of a clear definition of how the PUA's are supposed to

communicate with the 

>PA, or the 

>  presence server their presence related attributes (whether this be

caller-prefs in the 

>REGISTER 

>  for migration, or simply publishing the presence document fragments). We

can all think 

>of ways to 

>  do this, I'm particularly worried that we all won't come up with the same

way, and 

>won't be able 

>  to inter-op. Take for example CPL, if someone were to come along today

and try to use 

>CPL in a SIP 

>  network, where is the draft or RFC (that hasn't expired) that states how

to do it? I've 

>searched, and I 

>  couldn't find one. The only reason that I can find that CPL

implementations are inter-

>oping is because 

>  of an expired draft that gave the publication mechanism. 




I agree that the issue of knowing when to register with methods=SUBSCRIBE is

a hard one, as we won't always be able to guarantee it can work. I also

agree we need a way for a PUA to be able to push an explicit presence

document to a presence server for distribution (although whether this is the

document that gets distributed is a matter of policy; more on that below). I

think we can kill both these birds with one stone, based on some ideas

mentioned already on the list and some private discussions I've had.




Forget about this stuff about being definitive. If a PUA has presence to

hand out, it is free to register with methods=SUBSCRIBE. Indeed, it may get

a SUBSCRIBE even if it never did such a registration, since the proxy in

front of it might not support caller preferences. In that case, its free to

accept it.




Consider first the case where a presence server acts as a PA. Its job is to

collect presence information from various components that represent the

presentity, and aggregate them together into a presence document. If a few

clients have registered indicating they support the methods=SUBSCRIBE, the

PA can obtain presence information from those clients by subscribing to them

directly. In this case, the watcher is the presence server itself. The PUA

can each upload presence documents to the presence server in NOTIFY requests

for that subscription. Each PUA only sends the presence information it knows

about. The presence server collects and aggregates these. Everything works

great. We have a standard way for the PUA to send presence documents to the

server (through NOTIFY). 




A presence server SHOULD act as PA whenever it is composing presence data

from multiple independent presence sources. If the PA knows that it is, in

fact, not performing a composition function, but merely passing on presence

documents received from a single PUA, then it can migrate the presence

function to that PUA. In this case, when it gets a SUBSCRIBE, it is proxied

to that single PUA.




This puts the burden of deciding on migration into the presence server,

rather than the client, where it really belongs. Since the presence server

knows what inputs to presence are being used, it also knows whether the

function can in fact be migrated.






>I'd suggest just removing the 

>migration section 

>altogether for now. 




I'm willing to entertain that, but its something that can be done within the

scope of the normative aspects of the specification. Thus, it can be done

even if not documented. Describing it makes some sense, I think, so that its

done right.






>For the second concern, and just to make things inter-operable, can we make

the REGISTER 

>method the ONLY 

>way that PUAs can publish presence information to a PA via SIP? 




Absolutely not. One of the fundamental ideas here is that a PA can collect

many sources of presence data. Some are explicit, where a PUA has said "this

is my presence data", such as the NOTIFY mechanism I proposed above. Others

are implicit, where there is some state in the network that describes a

presentity, even though this state was not established for the sole purpose

of presence. Examples of such implicit presence are registrations and

geolocation information.




How a PA combines the explicit and implicit data it has into a final

presence document is a matter of local policy. We should never dictate that,

nor should we ever dictate what sources can be used to create a presence

document. 




>This wouldn't mandate that you have 

>to use SIP to 

>publish your presence information necessarily, either. Just that if you

want to use SIP, 

>this is the way to 

>do it. I think this is the direction the Donovan draft is going to take us

anyhow. Right? 




By no means was the publish requirements draft aimed at producing a spec

that would eliminate using registrations to derive presence data. The aim

was to produce a spec that would allow a PUA to explicitly upload a presence

document fragment to the server. 




-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_01C14DAD.1C8A4830--

From ndeason@ubiquity.net  Fri Oct  5 10:51:30 2001
Received: from drago1.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 KAA01976
	for ; Fri, 5 Oct 2001 10:51:30 -0400 (EDT)
Received: from mailhost.ubiquity.net by drago1.ubiquity.net
          via smtpd (for [63.113.40.50]) with SMTP; 5 Oct 2001 14:51:20 UT
Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600);
	 Fri, 5 Oct 2001 15:51:52 +0100
From: "Neil Deason" 
To: "Brazier Lachlan" ,
        "'Jonathan Rosenberg'" ,
        "'Brian Stucker'" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Fri, 5 Oct 2001 15:51:51 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: 
X-OriginalArrivalTime: 05 Oct 2001 14:51:52.0771 (UTC) FILETIME=[45235930:01C14DAD]
Content-Length: 2132
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: 

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
>
> Hi,
>
> generally I agree with you about Authorisation and Authentication.
>
> Let me reformulate the question. Which response do I send back, when I
> received a SUBSCRIBE, and I'm not allowed or not willing to be the
> presentity (This can happen if someone defines me as
> presentity without
> letting me know - as the way of authorization is not in the
> scope of the
> presence draft, errors might happen)?

403 would do.

> I have a question concerning the Call flows in the draft.
> When a PA receives a SUBSCRIBE with an Expires header, the
> response contains
> an Expires header as well. What would an Expires header in a
> NOTIFY request
> sent from the PA to the Watcher mean? Would this update the
> subscription
> expiration time?
>
> An example:
> userA subscribes for user userB. As userB is a friend of
> userA, he accepts
> the subscription and the call flows just get on.
> After some time userB doesn't want to be the presentity of
> userA anymore, or
> maybe userB changes the contact information for the SUBSCRIBE
> request at
> it's registrar.
> Now, can userB (better said the PA of userB) send a NOTIFY
> with an Expires
> header with value 0 to tell userA, that it's subscription
> expiration time is
> over?
>
> I think it should be possible to do so, because if not, userB
> would need to
> wait for the next SUBSCRIBE request from userA, before he can
> tell him, that
> the subscription time is over. This could be a time value
> from seconds to
> days, month, years, etc.
>
>
> If there is another mechanism to do so, which one would it be? Maybe a
> NOTIFY with an empty body?

There current proposal is to use a new header,
Subscription-Expires in NOTIFY instead of overloading
Expires to indicate when a subscription will end.
draft-ietf-simple-presence-03.txt refers to this in
describing how PA functionality migrates (5.12). This
header still needs to be detailed in a revised 'SIP
specific event notification' draft.

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net


From bcampbell@dynamicsoft.com  Fri Oct  5 11:01:12 2001
Received: from localhost.localdomain ([63.110.3.232])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02093
	for ; Fri, 5 Oct 2001 11:01:11 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f95EtRS01567;
	Fri, 5 Oct 2001 09:55:30 -0500
Message-ID: <3BBDC9DE.3000604@dynamicsoft.com>
Date: Fri, 05 Oct 2001 09:55:26 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Petri K. Koskelainen" 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Comparing CPIM and SIP MESSAGE
References: <200110051432.KAA06803@disco.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3246
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: 

You comparison uses optional meta-data in the cpim example (not to 
mention an xml body part), but only required headers in the MESSAGE 
example, so it is hardly a fair comparison. A closer example (I've taken 
the liberty of removing the only Contact: from the SIP example, since it 
is the only header that I think is not required here):

CPIM example:


Content-type: message/cpim

From: MR SANDERS 
To: Depressed Donkey 
Date: 2000-12-13T13:40:00-08:00
Content-type: text/plain; charset=utf-8

Hello world!



Similar example with SIP MESSAGE:

MESSAGE sip:eeyore@100akerwood.com SIP/2.0
Via: SIP/2.0/UDP 128.59.19.106:5060
CSeq: 1 MESSAGE
From: MR SANDERS 
Date: Fri, 05 Oct 2001 14:16:58 GMT
Call-ID: 472466106@128.59.19.106
Content-Type: text/plain
To: Depressed Donkey 
Content-Length: 13

Hello world!


Note that 3 of the required SIP headers and the start line are there for 
transport reasons, and are not relevant here. But they are still 
required by the SIP spec. We _could_ come up with a relaxed SIP spec for 
this, but that would basically be the same as defining a new message format.



Petri K. Koskelainen wrote:

> 
> There have been a lot of statements that SIP has far more overhead 
> than CPIM. This is absolutely not true. See examples below:
> Sending an IM with "hello world!". 
> 
> CPIM example taken from cpim-draft.
> It has probably some not-so-important headers like MyFeatures*.
> Note that at least Subject and Date CPIM header have new syntax
> so this is incompatibility with SIP spec.
> 
> It seems that they have similar message size, depending whether
> some special headers are used. In many cases CPIM has more 
> overhead than SIP.
> 
> So, I don't think that message size or unnecessary headers 
> are an issue here. 
> Also, CPIM is still work-in-progress while SIP is ready and will
> surely be implemented everywhere.
> 
> 
> CPIM example:
> 
> 
> m: Content-type: message/cpim
> s:
> h: From: MR SANDERS 
> h: To: Depressed Donkey 
> h: Date: 2000-12-13T13:40:00-08:00
> h: Subject: the weather will be fine today
> h: Subject:;lang=fr beau temps prevu pour aujourd'hui
> h: NS: MyFeatures 
> h: Require: MyFeatures.VitalMessageOption
> h: MyFeatures.VitalMessageOption: Confirmation-requested
> h: MyFeatures.WackyMessageOption: Use-silly-font
> s:
> e: Content-type: text/xml; charset=utf-8
> e: Content-ID: <1234567890@foo.com>
> e:
> e: 
> e: Hello World!
> e: 
> 
> 
> 
> Similar example with SIP MESSAGE:
> 
> MESSAGE sip:eeyore@100akerwood.com SIP/2.0
> Via: SIP/2.0/UDP 128.59.19.106:5060
> CSeq: 1 MESSAGE
> Contact: sip:eeyore@128.59.19.106:5060
> From: MR SANDERS 
> Date: Fri, 05 Oct 2001 14:16:58 GMT
> Call-ID: 472466106@128.59.19.106
> Content-Type: text/plain
> To: Depressed Donkey 
> Content-Length: 13
> 
> Hello world!
> 
> 
> 
> 
> --
> Petri
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 




From bstucker@nortelnetworks.com  Fri Oct  5 11:02:34 2001
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 LAA02121
	for ; Fri, 5 Oct 2001 11:02:33 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA04226
	for ; Fri, 5 Oct 2001 10:02:18 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Fri, 5 Oct 2001 10:01:42 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 5 Oct 2001 10:01:49 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E410B94@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Jonathan Rosenberg ,
        Brazier Lachlan ,
        Jonathan Rosenberg ,
        "''Neil Deason' '" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Fri, 5 Oct 2001 10:01:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14DAE.AC5B5700"
Content-Length: 24552
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: 

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_01C14DAE.AC5B5700
Content-Type: text/plain;
	charset="iso-8859-1"

Ok, I think this one got off on the wrong footing... Let me try again.

What I'm suggesting is that when a PA receives a SUBSCRIBE, even if it is
the entity listed in the requestURI (which would need to happen for SIP
routing), it should look at the TO header to make sure that the party listed
in the TO is one that the PA serves. No changes in requestURI processing, or
routing rules along the way. 

That's all. I think it's just a word-smithing item from section 5.3 that 
needs to be added. If the PA that the SUBSCRIBE gets routed to, doesn't 
serve the TO party, it's sends back a 404 (not a 603, I was mistaken there, 
that would imply that it was the correct PA).

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

Regards,

Brian

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




  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Thursday, October 04, 2001 7:23 PM
To: Brazier Lachlan; 'Jonathan Rosenberg '; ''Neil Deason' '; ''SIMPLE
Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok


>I don't think it's non-sense... 
>
>Ugh.. The requestURI bit does cause some serious problems. If you run a
SUBSCRIBE 
>through a BBUA, that can change the requestURI as well. Yuck. Why don't we
consider 
>the TO party the presentity instead, and change the wording in the first
paragraph 
>of section 5.3 to reflect that? Then it becomes a lot nicer. In that case,
if 
>the user in the TO of the SUBSCRIBE is not a user served 
>by the presence agent that the subscribe was forked to, that presence agent

>should 603 the SUBSCRIBE.

Absolutely, positively NOT.

It is fundamental to the entire SIP model that a request can traverse many
hops (proxies), each hop modifying the request URI based on local policy,
ultimately reaching a recipient. Any particular hop can only make routing
and processing decisions if the target of the request is within the
namespace managed by that hop. What you are proposing would violate that,
and break the protocol, both SIP and SIMPLE, totally. 

Yes, it is helpful to know who that recipient ultimately is. The COntact
header in the 2xx, as I have already stated, provides some form of identity.
Even better is the Remote-Party-ID header from the privacy extension. 

>In essence, don't use the requestURI for establishing 
>the identity of the presentity on the actual presence agent. It could go
through 
>a BBUA or fork to another user (as you suggest) and get munged along the
way, so 
>use it just for routing purposes. 

Wrong.

>I think that'll fix it. Presence agents shouldn't accept subscriptions just
because 
>they understand how to process a SUBSCRIBE and the requestURI matches them.

>They need to also take into account who they are authorized to represent
the 
>presence for when deciding to accept a SUBSCRIBE or not. 

Generally, if a server receives a request, its because some chain of
processing decisions along the way decided that this server is indeed
ideally suited for doing that. The server can decide not to, and the purpose
of the To field is to provide information to allow it to make that decision
if it chooses. The same holds for INVITE. 

>The other reason that I can think of, and this ties in somewhat with
migration problems, 
>is if we consider the presence agent for the presentity to be the presence
server. If 
>a presence server is in the network, clients can't always be expected to
know the 
>requestURI of the presence server that's serving the presentity they're
interested in 
>watching. The requestURI would start out (I would think, in general) equal
to the TO 
>header URI, which would be the user@domain address of the presentity. A
proxy along 
>the way would have to notice that this is a presence subscription, and
change the 
>requestURI to be the presence server before forwarding it, or the presence
server 
>would always have to be included in the list of registered contacts for the
user (which 
>may require the presence server to make a third party registration to the
presentity). 

This makes no sense whatsoever.

-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: Wednesday, October 03, 2001 1:51 AM 
To: 'Jonathan Rosenberg '; Brazier Lachlan; ''Neil Deason' '; ''SIMPLE 
Mailinglist' ' 
Subject: AW: [Simple] Multiple 200 Ok 


 Hello, 
as far as I see, the problem lays in the registration. Is there a way to 
tell a registrar, that the registered address belongs to a different user? 
I really believe a subscriber should know if he is subscribed to the right 
person. As example imagine a subscriber, who subscribes for you, and when 
you are online, sends you private documents automaticly. You probably don't 
want this to happen. 
I think the same might be true for INVITE. Imagine a video service, where a 
video provider starts a video session, without knowing that you are not the 
right customer, and not knowing that you are on holiday. (An example would 
be a timed wakeup call or something like this) 
A solution I might think of, is to add a new parameter to the Contact 
header, indicating if I am really the user addressed to, or in a REGISTER 
request, to tell the registrar if the registered address "belongs" to me or 
a different user at all. 
Is this nonsense I am talking? 
Lachlan 
-----Originalnachricht----- 
Von: Jonathan Rosenberg 
An: 'Brazier Lachlan'; Jonathan Rosenberg; 'Neil Deason'; 'SIMPLE 
Mailinglist' 
Gesendet: 03.10.01 04:38 
Betreff: RE: [Simple] Multiple 200 Ok 



 
> -----Original Message----- 
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] 
> Sent: Tuesday, October 02, 2001 12:03 PM 
> To: 'Jonathan Rosenberg'; 'Neil Deason'; 'SIMPLE Mailinglist' 
> Subject: AW: [Simple] Multiple 200 Ok 
> 
> 
> Hello, 
> thank you for your clarification. There is still this one point open: 
> 
> > > > How can a 
> > > > subscriber realize, that 
> > > > a forking proxy forked to a different user (this can happen 
> > > > when I am on 
> > > > holiday, and I register my working collegue with my working 
> > > > SIP Url - and 
> > > > then somebody wants to subscribe for me)? 
> 
> 
> I believe, the problem can occur, when a proxy changes the 
> request-URI. This 
> would mean, that the proxy sends a SUBSCRIBE to another 
> presentity. 
Changing the request URI does not imply chaging the presentity. Changing 
it 
may occur in order to address the request to the presentity at a 
different 
location. 


I still 
> can't see, how the subscriber knows, that his SUBSCRIBE 
> request was handled 
> by a different user. 
The entity that finally responds to the SUBSCRIBE will place, in the 
2xx, a 
Contact header that contains their URL. 


> 
> I could imagine, that in the first NOTIFY after receiving the 
> SUBSCRIBE 
> request, the FROM header is different than the To header from 
> the SUBSCRIBE 
> request. Is this valid with the draft? 
No; as it stands, the To/From are flipped in the NOTIFY from the 
presentity. 


-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_01C14DAE.AC5B5700
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Multiple 200 Ok




Ok, I think this one got off on the wrong footing... Let me try again.




What I'm suggesting is that when a PA receives a SUBSCRIBE, even if it is

the entity listed in the requestURI (which would need to happen for SIP

routing), it should look at the TO header to make sure that the party listed

in the TO is one that the PA serves. No changes in requestURI processing, or

routing rules along the way. 




That's all. I think it's just a word-smithing item from section 5.3 that 

needs to be added. If the PA that the SUBSCRIBE gets routed to, doesn't 

serve the TO party, it's sends back a 404 (not a 603, I was mistaken there, 

that would imply that it was the correct PA).




I'm a bit worried about using the contact header in the 2xx as a means of

identifying the user that processed the SUBSCRIBE. The watcher has no method

of determining the user's contact list to check the contact received

against. So I don't see a reliable method of taking a contact and determining

the user that contact is for unless you're the registrar (and even then it

can be ambiguous). If you have a proxy that straddles a firewall, it will

probably modify the contact address in the 2xx response, so the contact returned

may be one that only the proxy knows who it maps to, and nobody else.




Regards,




Brian




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Thursday, October 04, 2001 9:18 PM

To: Stucker, Brian [NGB:B621:EXCH]; Brazier Lachlan; Jonathan Rosenberg;

''Neil Deason' '; ''SIMPLE Mailinglist' '

Subject: RE: [Simple] Multiple 200 Ok










  

-----Original Message-----

From: Brian Stucker [mailto:bstucker@nortelnetworks.com]

Sent: Thursday, October 04, 2001 7:23 PM

To: Brazier Lachlan; 'Jonathan Rosenberg '; ''Neil Deason' '; ''SIMPLE

Mailinglist' '

Subject: RE: [Simple] Multiple 200 Ok






>I don't think it's non-sense... 

>

>Ugh.. The requestURI bit does cause some serious problems. If you run a

SUBSCRIBE 

>through a BBUA, that can change the requestURI as well. Yuck. Why don't we

consider 

>the TO party the presentity instead, and change the wording in the first

paragraph 

>of section 5.3 to reflect that? Then it becomes a lot nicer. In that case,

if 

>the user in the TO of the SUBSCRIBE is not a user served 

>by the presence agent that the subscribe was forked to, that presence agent




>should 603 the SUBSCRIBE.




Absolutely, positively NOT.




It is fundamental to the entire SIP model that a request can traverse many

hops (proxies), each hop modifying the request URI based on local policy,

ultimately reaching a recipient. Any particular hop can only make routing

and processing decisions if the target of the request is within the

namespace managed by that hop. What you are proposing would violate that,

and break the protocol, both SIP and SIMPLE, totally. 




Yes, it is helpful to know who that recipient ultimately is. The COntact

header in the 2xx, as I have already stated, provides some form of identity.

Even better is the Remote-Party-ID header from the privacy extension. 




>In essence, don't use the requestURI for establishing 

>the identity of the presentity on the actual presence agent. It could go

through 

>a BBUA or fork to another user (as you suggest) and get munged along the

way, so 

>use it just for routing purposes. 




Wrong.




>I think that'll fix it. Presence agents shouldn't accept subscriptions just

because 

>they understand how to process a SUBSCRIBE and the requestURI matches them.




>They need to also take into account who they are authorized to represent

the 

>presence for when deciding to accept a SUBSCRIBE or not. 




Generally, if a server receives a request, its because some chain of

processing decisions along the way decided that this server is indeed

ideally suited for doing that. The server can decide not to, and the purpose

of the To field is to provide information to allow it to make that decision

if it chooses. The same holds for INVITE. 




>The other reason that I can think of, and this ties in somewhat with

migration problems, 

>is if we consider the presence agent for the presentity to be the presence

server. If 

>a presence server is in the network, clients can't always be expected to

know the 

>requestURI of the presence server that's serving the presentity they're

interested in 

>watching. The requestURI would start out (I would think, in general) equal

to the TO 

>header URI, which would be the user@domain address of the presentity. A

proxy along 

>the way would have to notice that this is a presence subscription, and

change the 

>requestURI to be the presence server before forwarding it, or the presence

server 

>would always have to be included in the list of registered contacts for the

user (which 

>may require the presence server to make a third party registration to the

presentity). 




This makes no sense whatsoever.




-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: Wednesday, October 03, 2001 1:51 AM 

To: 'Jonathan Rosenberg '; Brazier Lachlan; ''Neil Deason' '; ''SIMPLE 

Mailinglist' ' 

Subject: AW: [Simple] Multiple 200 Ok 






 Hello, 

as far as I see, the problem lays in the registration. Is there a way to 

tell a registrar, that the registered address belongs to a different user? 

I really believe a subscriber should know if he is subscribed to the right 

person. As example imagine a subscriber, who subscribes for you, and when 

you are online, sends you private documents automaticly. You probably don't 

want this to happen. 

I think the same might be true for INVITE. Imagine a video service, where a 

video provider starts a video session, without knowing that you are not the 

right customer, and not knowing that you are on holiday. (An example would 

be a timed wakeup call or something like this) 

A solution I might think of, is to add a new parameter to the Contact 

header, indicating if I am really the user addressed to, or in a REGISTER 

request, to tell the registrar if the registered address "belongs" to me or 

a different user at all. 

Is this nonsense I am talking? 

Lachlan 

-----Originalnachricht----- 

Von: Jonathan Rosenberg 

An: 'Brazier Lachlan'; Jonathan Rosenberg; 'Neil Deason'; 'SIMPLE 

Mailinglist' 

Gesendet: 03.10.01 04:38 

Betreff: RE: [Simple] Multiple 200 Ok 








 

> -----Original Message----- 

> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] 

> Sent: Tuesday, October 02, 2001 12:03 PM 

> To: 'Jonathan Rosenberg'; 'Neil Deason'; 'SIMPLE Mailinglist' 

> Subject: AW: [Simple] Multiple 200 Ok 

> 

> 

> Hello, 

> thank you for your clarification. There is still this one point open: 

> 

> > > > How can a 

> > > > subscriber realize, that 

> > > > a forking proxy forked to a different user (this can happen 

> > > > when I am on 

> > > > holiday, and I register my working collegue with my working 

> > > > SIP Url - and 

> > > > then somebody wants to subscribe for me)? 

> 

> 

> I believe, the problem can occur, when a proxy changes the 

> request-URI. This 

> would mean, that the proxy sends a SUBSCRIBE to another 

> presentity. 

Changing the request URI does not imply chaging the presentity. Changing 

it 

may occur in order to address the request to the presentity at a 

different 

location. 






I still 

> can't see, how the subscriber knows, that his SUBSCRIBE 

> request was handled 

> by a different user. 

The entity that finally responds to the SUBSCRIBE will place, in the 

2xx, a 

Contact header that contains their URL. 






> 

> I could imagine, that in the first NOTIFY after receiving the 

> SUBSCRIBE 

> request, the FROM header is different than the To header from 

> the SUBSCRIBE 

> request. Is this valid with the draft? 

No; as it stands, the To/From are flipped in the NOTIFY from the 

presentity. 






-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_01C14DAE.AC5B5700--

From bcampbell@dynamicsoft.com  Fri Oct  5 11:04:05 2001
Received: from localhost.localdomain ([63.110.3.232])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02167
	for ; Fri, 5 Oct 2001 11:04:04 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f95EwQS01573;
	Fri, 5 Oct 2001 09:58:26 -0500
Message-ID: <3BBDCA92.4040604@dynamicsoft.com>
Date: Fri, 05 Oct 2001 09:58:26 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Petri K. Koskelainen" 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: <200110051412.KAA06130@disco.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 457
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: 

[snip]

> 
> 
> 
>>Also consider that an IM endpoint _must_ already have a 
>>CPIM parser, since message/cpim is a 
>>required-to-implement feature
>>
> 
> I'm not sure at all if this means that all terminals must implement CPIM.
> They have SIP there already. No need for CPIM.


The simple-im (page model, not session) draft says that an IM endpoint 
MUST be prepared to receive message/cpim, and MAY send message/cpim. I 
think that is pretty clear.





From bstucker@nortelnetworks.com  Fri Oct  5 11:10:35 2001
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 LAA02230
	for ; Fri, 5 Oct 2001 11:10:34 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA07111
	for ; Fri, 5 Oct 2001 10:10:24 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 5 Oct 2001 10:03:35 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 5 Oct 2001 10:09:52 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E410BBB@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Neil Deason ,
        Brazier Lachlan ,
        "'Jonathan Rosenberg'" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Fri, 5 Oct 2001 10:09:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C14DAF.CCE638E0"
X-Orig: 
Content-Length: 8629
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: 

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_01C14DAF.CCE638E0
Content-Type: text/plain;
	charset="iso-8859-1"

Would it be a 403 forbidden? If a 403 were sent back because the
only routable PA wasn't willing to process the subscription, wouldn't
this cause the would-be watcher to not try again later when other
PA's may be available (via forking) that could process the request?

I would think a 404 or a 488 response would be a better fit.

...

When is that new events draft going to appear? Until that comes out
the NOTIFY with expires = 0 is the way you force-expire a subscription.

Regards,

Brian

-----Original Message-----
From: Neil Deason [mailto:ndeason@ubiquity.net]
Sent: Friday, October 05, 2001 9:52 AM
To: Brazier Lachlan; 'Jonathan Rosenberg'; Stucker, Brian
[NGB:B621:EXCH]; ''SIMPLE Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok


> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
>
> Hi,
>
> generally I agree with you about Authorisation and Authentication.
>
> Let me reformulate the question. Which response do I send back, when I
> received a SUBSCRIBE, and I'm not allowed or not willing to be the
> presentity (This can happen if someone defines me as
> presentity without
> letting me know - as the way of authorization is not in the
> scope of the
> presence draft, errors might happen)?

403 would do.

> I have a question concerning the Call flows in the draft.
> When a PA receives a SUBSCRIBE with an Expires header, the
> response contains
> an Expires header as well. What would an Expires header in a
> NOTIFY request
> sent from the PA to the Watcher mean? Would this update the
> subscription
> expiration time?
>
> An example:
> userA subscribes for user userB. As userB is a friend of
> userA, he accepts
> the subscription and the call flows just get on.
> After some time userB doesn't want to be the presentity of
> userA anymore, or
> maybe userB changes the contact information for the SUBSCRIBE
> request at
> it's registrar.
> Now, can userB (better said the PA of userB) send a NOTIFY
> with an Expires
> header with value 0 to tell userA, that it's subscription
> expiration time is
> over?
>
> I think it should be possible to do so, because if not, userB
> would need to
> wait for the next SUBSCRIBE request from userA, before he can
> tell him, that
> the subscription time is over. This could be a time value
> from seconds to
> days, month, years, etc.
>
>
> If there is another mechanism to do so, which one would it be? Maybe a
> NOTIFY with an empty body?

There current proposal is to use a new header,
Subscription-Expires in NOTIFY instead of overloading
Expires to indicate when a subscription will end.
draft-ietf-simple-presence-03.txt refers to this in
describing how PA functionality migrates (5.12). This
header still needs to be detailed in a revised 'SIP
specific event notification' draft.

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net


------_=_NextPart_001_01C14DAF.CCE638E0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Multiple 200 Ok




Would it be a 403 forbidden? If a 403 were sent back because the

only routable PA wasn't willing to process the subscription, wouldn't

this cause the would-be watcher to not try again later when other

PA's may be available (via forking) that could process the request?




I would think a 404 or a 488 response would be a better fit.




...




When is that new events draft going to appear? Until that comes out

the NOTIFY with expires = 0 is the way you force-expire a subscription.




Regards,




Brian




-----Original Message-----

From: Neil Deason [mailto:ndeason@ubiquity.net]

Sent: Friday, October 05, 2001 9:52 AM

To: Brazier Lachlan; 'Jonathan Rosenberg'; Stucker, Brian

[NGB:B621:EXCH]; ''SIMPLE Mailinglist' '

Subject: RE: [Simple] Multiple 200 Ok






> -----Original Message-----

> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]

>

> Hi,

>

> generally I agree with you about Authorisation and Authentication.

>

> Let me reformulate the question. Which response do I send back, when I

> received a SUBSCRIBE, and I'm not allowed or not willing to be the

> presentity (This can happen if someone defines me as

> presentity without

> letting me know - as the way of authorization is not in the

> scope of the

> presence draft, errors might happen)?




403 would do.




> I have a question concerning the Call flows in the draft.

> When a PA receives a SUBSCRIBE with an Expires header, the

> response contains

> an Expires header as well. What would an Expires header in a

> NOTIFY request

> sent from the PA to the Watcher mean? Would this update the

> subscription

> expiration time?

>

> An example:

> userA subscribes for user userB. As userB is a friend of

> userA, he accepts

> the subscription and the call flows just get on.

> After some time userB doesn't want to be the presentity of

> userA anymore, or

> maybe userB changes the contact information for the SUBSCRIBE

> request at

> it's registrar.

> Now, can userB (better said the PA of userB) send a NOTIFY

> with an Expires

> header with value 0 to tell userA, that it's subscription

> expiration time is

> over?

>

> I think it should be possible to do so, because if not, userB

> would need to

> wait for the next SUBSCRIBE request from userA, before he can

> tell him, that

> the subscription time is over. This could be a time value

> from seconds to

> days, month, years, etc.

>

>

> If there is another mechanism to do so, which one would it be? Maybe a

> NOTIFY with an empty body?




There current proposal is to use a new header,

Subscription-Expires in NOTIFY instead of overloading

Expires to indicate when a subscription will end.

draft-ietf-simple-presence-03.txt refers to this in

describing how PA functionality migrates (5.12). This

header still needs to be detailed in a revised 'SIP

specific event notification' draft.




Cheers,

Neil.

--

Ubiquity Software Corporation, UK        http://www.ubiquity.net





------_=_NextPart_001_01C14DAF.CCE638E0--

From jdrosen@dynamicsoft.com  Fri Oct  5 11:23:29 2001
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 LAA02308
	for ; Fri, 5 Oct 2001 11:23:29 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f95FLh8P003365;
	Fri, 5 Oct 2001 11:21:43 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4KFCAH9W>; Fri, 5 Oct 2001 11:22:48 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Ben Campbell ,
        "Petri K. Koskelainen"
	 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Comparing CPIM and SIP MESSAGE
Date: Fri, 5 Oct 2001 11:22:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 2386
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: 


 

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Friday, October 05, 2001 10:55 AM
> To: Petri K. Koskelainen
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Comparing CPIM and SIP MESSAGE
> 
> 
> You comparison uses optional meta-data in the cpim example (not to 
> mention an xml body part), but only required headers in the MESSAGE 
> example, so it is hardly a fair comparison. A closer example 
> (I've taken 
> the liberty of removing the only Contact: from the SIP 
> example, since it 
> is the only header that I think is not required here):

First off, I think this particular debate is really about minutiae. The main
issue is what the underlying "switching" fabric for the transport is;
whether its SIP proxies, or something based on port mapping and IP address
logic. That is really the fundamental question. Those who favor SIP do so
because of the existence of a "routing fabric" of SIP proxies that can
easily get MESSAGE from A to B through various firewall and nat scenarios.
Doing such routing at a transport layer is perhaps newer and more difficult
to deploy; that remains to be determined precisely.

If we have decided that the underlying routing mechanism is not SIP, but
transport layer stuff, we are then free to decide what the format of the
messages is. We have requirements, and starting from that, we can do it with
a fairly small amount of overhead, compared to SIP and CPIM even. We can
choose to use all of the CPIM headers, some of them, or none of them. The
resulting thing could even be made to look like a sip fragment, so Henning
can reuse his parsers, and also look like a compliant CPIM message.
Something like:

From: sip:user@host
Content-Length: 12
Content-Type: text/plain

Hello world.


for example. This is the minimum to meet our requirements for framing,
content type identification and source identification.

So, I would rather focus on how the underlying forwarding is done rather
than on the header syntax.

-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

From petkos@cs.columbia.edu  Fri Oct  5 11:23:33 2001
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 LAA02313
	for ; Fri, 5 Oct 2001 11:23:32 -0400 (EDT)
Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA26243;
	Fri, 5 Oct 2001 11:23:22 -0400 (EDT)
Received: (from petkos@localhost)
	by disco.cs.columbia.edu (8.9.3/8.9.3) id LAA09054;
	Fri, 5 Oct 2001 11:23:22 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110051523.LAA09054@disco.cs.columbia.edu>
Subject: Re: [Simple] Comparing CPIM and SIP MESSAGE
To: bcampbell@dynamicsoft.com (Ben Campbell)
Date: Fri, 5 Oct 2001 11:23:22 -0400 (EDT)
Cc: petkos@cs.columbia.edu (Petri K. Koskelainen),
        simple@mailman.dynamicsoft.com
In-Reply-To: <3BBDC9DE.3000604@dynamicsoft.com> from "Ben Campbell" at Oct 05, 2001 09:55:26 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 939
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: 

> 
> You comparison uses optional meta-data in the cpim example (not to 
> mention an xml body part), but only required headers in the MESSAGE 
> example, so it is hardly a fair comparison. A closer example (I've taken 

You are right, I just took it directly from cpim-draft.

Anyway, in high-speed links this minor overhead is not an issue
and in low-speed links there will (in most cases) be compression
which eliminates the overhead. So I don't think that
the message size is an issue here.

Also, some people have proposed that CPIM is carried in SIP
payload. This means that there are duplicate headers and
information. 

Also, as said earlier, CPIM borrows some headers from SIP
but they have different syntax and CPIM-draft is still 
work-in-progress. Also, full CPIM parser is probably needed
unless we define a subset "CPIM format for IM" which does not
use any extensions.

Therefore, I vote for SIP MESSAGE format.

--
Petri



From Tim.Moran@nokia.com  Fri Oct  5 11:33:04 2001
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 LAA02398
	for ; Fri, 5 Oct 2001 11:33:03 -0400 (EDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.americas.nokia.com [172.18.194.216])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f95FVCY14856
	for ; Fri, 5 Oct 2001 18:31:12 +0300 (EET DST)
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 f95FWrw08883
	for ; Fri, 5 Oct 2001 10:32:53 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 5 Oct 2001 10:32:49 -0500
Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 5 Oct 2001 10:32:57 -0500
content-class: urn:content-classes:message
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 5 Oct 2001 10:32:48 -0500
Message-ID: <278B6B0D76698D45BBA872CD23DD496A0A41E7@daebe004.NOE.Nokia.com>
MIME-Version: 1.0
X-MS-Has-Attach: 
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C14DB2.FCC85B18"
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] 200 vs. 202
Thread-Index: AcFNnnCQbFFiU7mQEdWBTABQi2X+DwAEVoEw
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Moran Tim (NET/Dallas)" 
To: "'ext Paul Kyzivat'" ,
        "Jonathan Rosenberg" 
Cc: 
X-OriginalArrivalTime: 05 Oct 2001 15:32:57.0856 (UTC) FILETIME=[02717800:01C14DB3]
Content-Length: 6515
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: 

This is a multi-part message in MIME format.

------_=_NextPart_001_01C14DB2.FCC85B18
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My comments are in line.

> -----Original Message-----
> From: ext Paul Kyzivat [ 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
>
>
> Jonathan Rosenberg wrote:
> >
> > > Relating to forked subscriptions (5.10), what happens if
> one of the
> > > subscribed-to PAs can authorize and wants to send a 200? Does
> > > it instead
> > > send a 202 and immediately send a Notify?  That is,
> forked-to PAs are
> > > not allowed to send 200? I presume the PA can tell the
> > > request has been
> > > forked.
> >
> > I don't understand the problem. Each PUA would decide
> independely on a
> > response (200, 202, 600, whatever). The presence server
> (which is acting as
> > a proxy now) takes the best response - 200 in this case -
> and passes it
> > upstream.

While 5.7 paragraph 6 indicates that the Notifier can send whatever, the
first paragraph of 5.10 states "Each of these [PA] will respond with a
202 response to the SUBSCRIBE."  The later does not imply whatever can
be sent..

Given your comments are correct, then I would suggest changing the 1st
paragraph of 5.10 so as not to restrict what can be sent by the PA
(After all - can the Notifier (PA) even tell it is a 5.7 subscribe vs. a
5.10 (forked) subscribe?). On a side note, the doc uses Notifier for
section titles wherein the text uses e.g. PA. Is this semantically
correct? Are we really intending to talk about PA Notifiers vs. other
type of Notifiers? Don't mean to be picky but I'm not sure if this is
intentional, and thus adds explicit meaning, or just loose use of
terminology.


>
> This seems a little surprising. Wouldn't a proxy normally
> pass the first
> 200 class response upstream and cancel the rest? Doing otherwise
> requires
> the proxy to treat SUBSCRIBE specially.

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.

>
>       Paul
>=20


------_=_NextPart_001_01C14DB2.FCC85B18
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









My comments are in line.

> =
-----Original=20
Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
>=
 Sent:=20
Friday, October 05, 2001 8:04 AM
> To: Jonathan Rosenberg
> =
Cc:=20
Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com
> Subject: =
Re:=20
[Simple] 200 vs. 202
>
>
> Jonathan Rosenberg =
wrote:
>=20
>
> > > Relating to forked subscriptions (5.10), what =
happens=20
if
> one of the
> > > subscribed-to PAs can authorize =
and=20
wants to send a 200? Does
> > > it instead
> > > =
send a=20
202 and immediately send a Notify?  That is,
> forked-to PAs=20
are
> > > not allowed to send 200? I presume the PA can tell =

the
> > > request has been
> > > forked.
> =

>
> > I don't understand the problem. Each PUA would =
decide
>=20
independely on a
> > response (200, 202, 600, whatever). The =
presence=20
server
> (which is acting as
> > a proxy now) takes the =
best=20
response - 200 in this case -
> and passes it
> >=20
upstream.

While 5.7 paragraph 6 indicates that the Notifier =
can send=20
whatever, the first paragraph of 5.10 states "Each of these [PA] will =
respond=20
with a 202 response to the SUBSCRIBE."  The later does not imply =
whatever=20
can be sent..

Given your comments are correct, then I would =
suggest=20
changing the 1st paragraph of 5.10 so as not to restrict what can be =
sent by the=20
PA (After all - can the Notifier (PA) even tell it is a 5.7 subscribe =
vs. a 5.10=20
(forked) subscribe?). On a side note, the doc uses Notifier for section =
titles=20
wherein the text uses e.g. PA. Is this semantically correct? Are we =
really=20
intending to talk about PA Notifiers vs. other type of Notifiers? Don't =
mean to=20
be picky but I'm not sure if this is intentional, and thus adds explicit =

meaning, or just loose use of terminology.


>
> =
This=20
seems a little surprising. Wouldn't a proxy normally
> pass the=20
first
> 200 class response upstream and cancel the rest? Doing=20
otherwise
> requires
> the proxy to treat SUBSCRIBE=20
specially.

Seems you are both saying the same thing. I seem =
to recall=20
an earlier 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 =
proxy=20
capabilities) will wait some predetermined amount of time to collect all =
of the=20
responses (or until all are received whichever comes first) and send =
back the=20
best response. If the best is a 202, then does the proxy wait for the =
Notify and=20
send the 202+Notify or just the 202 and the Notify later? I guess I =
don't see=20
the need for a 202 indicating pending followed immediately by another =
message=20
(Notify with no real status) which adds no =
value.

>
>=20
      Paul
> 


------_=_NextPart_001_01C14DB2.FCC85B18--

From c-Dai.Ngo@WCOM.Com  Fri Oct  5 11:45:28 2001
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 LAA02485
	for ; Fri, 5 Oct 2001 11:45:28 -0400 (EDT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.wcom.com (PMDF V5.2-32 #42257)
 with ESMTP id <0GKQ00BPBP3DKY@firewall.wcom.com> for
 simple@mailman.dynamicsoft.com; Fri,  5 Oct 2001 15:45:13 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0GKQ00K01P350I@pmismtp02.wcomnet.com>;
 Fri, 05 Oct 2001 15:45:13 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0GKQ00GJCP30RQ@pmismtp02.wcomnet.com>; Fri,
 05 Oct 2001 15:45:01 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 05 Oct 2001 15:45:00 +0000
Content-return: allowed
Date: Fri, 05 Oct 2001 15:44:59 +0000
From: "Ngo, Dai (c)" 
Subject: RE: [Simple] Comparing CPIM and SIP MESSAGE
To: "'Ben Campbell'" ,
        "Petri K. Koskelainen" 
Cc: simple@mailman.dynamicsoft.com
Message-id: <492EB4A3F68CD411ABE800508B69362E6C4E2F@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; CHARSET=US-ASCII
Content-Length: 3875
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: 

I'm confused. Will CPIM message be transported via some mechanism/agents? If
so, to be a fair comparison, there should be other headers to be counted
towards the total length of the CPIM message, as in the example of SIP
MESSAGE.

-- Dai 

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] 
Sent: Friday, October 05, 2001 9:55 AM
To: Petri K. Koskelainen
Cc: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Comparing CPIM and SIP MESSAGE

You comparison uses optional meta-data in the cpim example (not to 
mention an xml body part), but only required headers in the MESSAGE 
example, so it is hardly a fair comparison. A closer example (I've taken 
the liberty of removing the only Contact: from the SIP example, since it 
is the only header that I think is not required here):

CPIM example:


Content-type: message/cpim

From: MR SANDERS 
To: Depressed Donkey 
Date: 2000-12-13T13:40:00-08:00
Content-type: text/plain; charset=utf-8

Hello world!



Similar example with SIP MESSAGE:

MESSAGE sip:eeyore@100akerwood.com SIP/2.0
Via: SIP/2.0/UDP 128.59.19.106:5060
CSeq: 1 MESSAGE
From: MR SANDERS 
Date: Fri, 05 Oct 2001 14:16:58 GMT
Call-ID: 472466106@128.59.19.106
Content-Type: text/plain
To: Depressed Donkey 
Content-Length: 13

Hello world!


Note that 3 of the required SIP headers and the start line are there for 
transport reasons, and are not relevant here. But they are still 
required by the SIP spec. We _could_ come up with a relaxed SIP spec for 
this, but that would basically be the same as defining a new message format.



Petri K. Koskelainen wrote:

> 
> There have been a lot of statements that SIP has far more overhead 
> than CPIM. This is absolutely not true. See examples below:
> Sending an IM with "hello world!". 
> 
> CPIM example taken from cpim-draft.
> It has probably some not-so-important headers like MyFeatures*.
> Note that at least Subject and Date CPIM header have new syntax
> so this is incompatibility with SIP spec.
> 
> It seems that they have similar message size, depending whether
> some special headers are used. In many cases CPIM has more 
> overhead than SIP.
> 
> So, I don't think that message size or unnecessary headers 
> are an issue here. 
> Also, CPIM is still work-in-progress while SIP is ready and will
> surely be implemented everywhere.
> 
> 
> CPIM example:
> 
> 
> m: Content-type: message/cpim
> s:
> h: From: MR SANDERS 
> h: To: Depressed Donkey 
> h: Date: 2000-12-13T13:40:00-08:00
> h: Subject: the weather will be fine today
> h: Subject:;lang=fr beau temps prevu pour aujourd'hui
> h: NS: MyFeatures 
> h: Require: MyFeatures.VitalMessageOption
> h: MyFeatures.VitalMessageOption: Confirmation-requested
> h: MyFeatures.WackyMessageOption: Use-silly-font
> s:
> e: Content-type: text/xml; charset=utf-8
> e: Content-ID: <1234567890@foo.com>
> e:
> e: 
> e: Hello World!
> e: 
> 
> 
> 
> Similar example with SIP MESSAGE:
> 
> MESSAGE sip:eeyore@100akerwood.com SIP/2.0
> Via: SIP/2.0/UDP 128.59.19.106:5060
> CSeq: 1 MESSAGE
> Contact: sip:eeyore@128.59.19.106:5060
> From: MR SANDERS 
> Date: Fri, 05 Oct 2001 14:16:58 GMT
> Call-ID: 472466106@128.59.19.106
> Content-Type: text/plain
> To: Depressed Donkey 
> Content-Length: 13
> 
> Hello world!
> 
> 
> 
> 
> --
> Petri
> _______________________________________________
> 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 bcampbell@dynamicsoft.com  Fri Oct  5 11:49:33 2001
Received: from localhost.localdomain ([63.110.3.232])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02519
	for ; Fri, 5 Oct 2001 11:49:33 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f95FhsS01680;
	Fri, 5 Oct 2001 10:43:54 -0500
Message-ID: <3BBDD53A.1040401@dynamicsoft.com>
Date: Fri, 05 Oct 2001 10:43:54 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Comparing CPIM and SIP MESSAGE
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2617
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: 

>>
> 
> First off, I think this particular debate is really about minutiae. The
> main issue is what the underlying "switching" fabric for the transport
> is; whether its SIP proxies, or something based on port mapping and IP
> address logic. That is really the fundamental question. Those who favor
> SIP do so because of the existence of a "routing fabric" of SIP proxies
> that can easily get MESSAGE from A to B through various firewall and nat
> scenarios. Doing such routing at a transport layer is perhaps newer and
> more difficult to deploy; that remains to be determined precisely.


Actually, Henning proposed we use MESSAGE, but without using the SIP 
routing fabric. Only some of the MESSAGE proponents expect to use SIP 
routing.

I propose that the method actually used for routing is dependent on the 
receiver implementation or local policy. The receiver may indeed use 
port mapping, or may choose to route based on a To: header or somesuch. 
The sender, however, must include enough information for a non-port 
mapping receiver.

The port-mapping approach has the advantage of being very easy to signal 
in SDP. Mapping based on a header value requires us to signal that 
header value in the INVITE somehow. We already ran into some issues of 
how to do that with a URL when we were considering sessions of SIP messages.

> 
> If we have decided that the underlying routing mechanism is not SIP, but
> transport layer stuff, we are then free to decide what the format of the
> messages is. We have requirements, and starting from that, we can do it
> with a fairly small amount of overhead, compared to SIP and CPIM even.
> We can choose to use all of the CPIM headers, some of them, or none of
> them. The resulting thing could even be made to look like a sip
> fragment, so Henning can reuse his parsers, and also look like a
> compliant CPIM message. Something like:
> 
> From: sip:user@host
> Content-Length: 12
> Content-Type: text/plain
> 
> Hello world.
> 
> 
> for example. This is the minimum to meet our requirements for framing,
> content type identification and source identification.
> 
> So, I would rather focus on how the underlying forwarding is done rather
> than on the header syntax.
> 




> -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
> 




From petkos@cs.columbia.edu  Fri Oct  5 11:49:33 2001
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 LAA02521
	for ; Fri, 5 Oct 2001 11:49:33 -0400 (EDT)
Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA28114;
	Fri, 5 Oct 2001 11:49:23 -0400 (EDT)
Received: (from petkos@localhost)
	by disco.cs.columbia.edu (8.9.3/8.9.3) id LAA10386;
	Fri, 5 Oct 2001 11:49:23 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110051549.LAA10386@disco.cs.columbia.edu>
Subject: Re: [Simple] IM over the signaling connection
To: bcampbell@dynamicsoft.com (Ben Campbell)
Date: Fri, 5 Oct 2001 11:49:22 -0400 (EDT)
Cc: petkos@cs.columbia.edu (Petri K. Koskelainen),
        simple@mailman.dynamicsoft.com
In-Reply-To: <3BBDCA92.4040604@dynamicsoft.com> from "Ben Campbell" at Oct 05, 2001 09:58:26 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 569
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: 

> 
> The simple-im (page model, not session) draft says that an IM endpoint 
> MUST be prepared to receive message/cpim, and MAY send message/cpim. I 
> think that is pretty clear.
> 

Yep, it may receive it and respond with 415 Unsupported Media Type.
 
I'm not convinced that CPIM will ever be used in real world
even if one day CPIM format (or the proposed new CPIM-based 
SIP-like format for instant messages) is ready.
In most cases, text/plain will do the job without extra overhead
in SIP payload and the need to create and test yet another format. 


--
Petri


From petkos@cs.columbia.edu  Fri Oct  5 12:00:30 2001
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 MAA02643
	for ; Fri, 5 Oct 2001 12:00:29 -0400 (EDT)
Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA28745;
	Fri, 5 Oct 2001 12:00:17 -0400 (EDT)
Received: (from petkos@localhost)
	by disco.cs.columbia.edu (8.9.3/8.9.3) id MAA10987;
	Fri, 5 Oct 2001 12:00:16 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110051600.MAA10987@disco.cs.columbia.edu>
Subject: Re: [Simple] Comparing CPIM and SIP MESSAGE
To: c-Dai.Ngo@WCOM.Com ("Ngo, Dai (c)")
Date: Fri, 5 Oct 2001 12:00:16 -0400 (EDT)
Cc: bcampbell@dynamicsoft.com ('Ben Campbell'),
        petkos@cs.columbia.edu (Petri K. Koskelainen),
        simple@mailman.dynamicsoft.com
In-Reply-To: <492EB4A3F68CD411ABE800508B69362E6C4E2F@RIPEXCH002.wcomnet.com> from "Ngo, Dai (c)" at Oct 05, 2001 03:44:59 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 593
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: 

> I'm confused. Will CPIM message be transported via some mechanism/agents? If
> so, to be a fair comparison, there should be other headers to be counted
> towards the total length of the CPIM message, as in the example of SIP
> MESSAGE.
> 

You are right.

At least three different CPIM transports have been proposed:
- CPIM over TCP
- CPIM over SIP MESSAGE over TCP
- new SIP-like CPIM subset for instant messages over whatever 

CPIM over SIP makes sense since one-shot messages might (at least in 
paper) use CPIM, but then there is huge and unnecessary 
overhead (SIP+CPIM).


--
Petri 

From tony@att.com  Fri Oct  5 12:20:02 2001
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 MAA02760
	for ; Fri, 5 Oct 2001 12:20:01 -0400 (EDT)
Received: from dns.maillennium.att.com ([135.25.114.99])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f95GJmC01439
	for ; Fri, 5 Oct 2001 12:19:49 -0400 (EDT)
Received: from att.com ([135.210.75.2])
          by maillennium.att.com (labmail) with SMTP
          id <2001100516194809900fbguqe>
          (Authid: tony@maillennium.att.com);
          Fri, 5 Oct 2001 16:19:48 +0000
Message-ID: <3BBDDCE9.97DBCD6B@att.com>
Date: Fri, 05 Oct 2001 12:16:41 -0400
From: Tony Hansen 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Comparing CPIM and SIP MESSAGE
References: <200110051600.MAA10987@disco.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 750
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: 

One other suggestion made was to use beep or apex as the transport.

	Tony Hansen
	tony@att.com

"Petri K. Koskelainen" wrote:
> 
> > I'm confused. Will CPIM message be transported via some mechanism/agents? If
> > so, to be a fair comparison, there should be other headers to be counted
> > towards the total length of the CPIM message, as in the example of SIP
> > MESSAGE.
> 
> You are right.
> 
> At least three different CPIM transports have been proposed:
> - CPIM over TCP
> - CPIM over SIP MESSAGE over TCP
> - new SIP-like CPIM subset for instant messages over whatever
> 
> CPIM over SIP makes sense since one-shot messages might (at least in
> paper) use CPIM, but then there is huge and unnecessary
> overhead (SIP+CPIM).
> 
> --
> Petri

From c-Dai.Ngo@WCOM.Com  Fri Oct  5 12:53:22 2001
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02910
	for ; Fri, 5 Oct 2001 12:53:22 -0400 (EDT)
Received: from dgismtp04.wcomnet.com ([166.38.58.144])
 by firewall.wcom.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GKQ0085WS8640@firewall.wcom.com> for
 simple@mailman.dynamicsoft.com; Fri,  5 Oct 2001 16:52:55 +0000 (GMT)
Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0GKQ00H01S7L22@dgismtp04.wcomnet.com>;
 Fri, 05 Oct 2001 16:52:54 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0GKQ00FA0S7CQ0@dgismtp04.wcomnet.com>; Fri,
 05 Oct 2001 16:52:25 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2653.19)
	id ; Fri, 05 Oct 2001 16:52:24 +0000
Content-return: allowed
Date: Fri, 05 Oct 2001 16:52:20 +0000
From: "Ngo, Dai (c)" 
Subject: RE: [Simple] 200 vs. 202
To: "'Moran Tim (NET/Dallas)'" ,
        "'ext Paul Kyzivat'" ,
        Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
Message-id: <492EB4A3F68CD411ABE800508B69362E6C4E30@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_1rzI5oDFHmyV8tj9GhuWWw)"
Content-Length: 8830
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: 

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_1rzI5oDFHmyV8tj9GhuWWw)
Content-type: text/plain; CHARSET=US-ASCII

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] 
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
 ]
> 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.

 

--Boundary_(ID_1rzI5oDFHmyV8tj9GhuWWw)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable

























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] 

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]

> 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.



 









--Boundary_(ID_1rzI5oDFHmyV8tj9GhuWWw)--

From dean.willis@softarmor.com  Fri Oct  5 14:47:17 2001
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 OAA03297
	for ; Fri, 5 Oct 2001 14:47:16 -0400 (EDT)
Received: from flak (localhost.localdomain [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f95IqkD09980
	for ; Fri, 5 Oct 2001 13:52:46 -0500
Message-ID: <00f501c14dce$1d2f37c0$892e713f@flak>
From: "Dean Willis" 
To: 
References:  <3BBC8014.9040707@dynamicsoft.com>
Subject: Re: [Simple] IM over the signaling connection
Date: Fri, 5 Oct 2001 13:46:57 -0500
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
Content-Length: 1977
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: 

That is correct. I have held further converse with the AD (Allison Mankin)
on the topic, and the position is that SIP is not and has not been designed
as an effective transport protocol, and it is therefore innapropriate to
transport multi-message sessions over SIP. It's simply too dangerous to turn
loose a protocol that lacks effective congestion avoidance.

And yes, Allison does seem to like bxxp as a message transport protocol . .
. of course, that's just my interpretation of what I thought I heard.

I suggest we give bxxp a reexamination relative to the requirements that
have been coming forth for a transport protocol for sessions.

--
Dean

----- Original Message -----
From: "Ben Campbell" 
To: 
Cc: 
Sent: Thursday, October 04, 2001 10:28 AM
Subject: Re: [Simple] IM over the signaling connection


> It is not so much that it is being ignored as that the IESG has told us
> they will not approve it.
>
>
> Avshalom@ubique.com wrote:
>
> > It seems that the possibility of sending MESSAGEs of sessions over the
> > signaling connection is being ignored.
> > I am not sure that there is a consensus not to use it.
> >
> > It think that we can agree on sending MESSAGEs of sessions on the
control
> > connection. We should keep the
> > header of the MESSAGEs to a necessary minimum and agree on a maximum
length
> > of MESSAGEs to be sent
> > on the signaling connection. Given this, the impact on the control
> > connection will not be different from a one time
> > MESSAGE and NOTIFYs.
> >
> > avshalom
> > Sametime/Lotus/IBM
> >
> >
> > _______________________________________________
> > 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 petkos@cs.columbia.edu  Fri Oct  5 14:58:55 2001
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 OAA03361
	for ; Fri, 5 Oct 2001 14:58:53 -0400 (EDT)
Received: from disco.cs.columbia.edu (disco.cs.columbia.edu [128.59.16.7])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA20426
	for ; Fri, 5 Oct 2001 14:58:39 -0400 (EDT)
Received: (from petkos@localhost)
	by disco.cs.columbia.edu (8.9.3/8.9.3) id OAA18776
	for simple@mailman.dynamicsoft.com; Fri, 5 Oct 2001 14:58:38 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110051858.OAA18776@disco.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Fri, 5 Oct 2001 14:58:38 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 767
Subject: [Simple] IM over the signaling connection
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: 

I guess you are talking about SIP over UDP.
SIP MESSAGE sessions over TCP does not lack congestion control.
Can you clarify that statement?

Only real problem left seems to be that there are 2-3 extra SIP
headers which are overhead (if SIP is used only as an encapsulation).

I don't see this as a major problem.

--
Petri


----- Original Message -----
From: "Dean Willis"  


That is correct. I have held further converse with the AD (Allison Mankin)
on the topic, and the position is that SIP is not and has not been designed
as an effective transport protocol, and it is therefore innapropriate to
transport multi-message sessions over SIP. It's simply too dangerous to turn
loose a protocol that lacks effective congestion avoidance.

From jdrosen@dynamicsoft.com  Fri Oct  5 15:16:34 2001
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 PAA03445
	for ; Fri, 5 Oct 2001 15:16:34 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f95JEh8P006509;
	Fri, 5 Oct 2001 15:14:43 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4KFCAJ1J>; Fri, 5 Oct 2001 15:15:48 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Fri, 5 Oct 2001 15:15:47 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1375
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: 


 

> -----Original Message-----
> From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> Sent: Friday, October 05, 2001 2:59 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] IM over the signaling connection
> 
> 
> 
> I guess you are talking about SIP over UDP.
> SIP MESSAGE sessions over TCP does not lack congestion control.
> Can you clarify that statement?
> 
> Only real problem left seems to be that there are 2-3 extra SIP
> headers which are overhead (if SIP is used only as an encapsulation).
> 
> I don't see this as a major problem.

Somehow my last point has not come across.

Forget about the syntax. Just, forget about it. 

THe ***>>>***!!!>>>MAIN<<; Fri, 5 Oct 2001 16:00:42 -0400 (EDT)
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 QAA22207;
	Fri, 5 Oct 2001 16:00:28 -0400 (EDT)
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 QAA15788;
	Fri, 5 Oct 2001 16:00:27 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 5 Oct 2001 16:00:27 -0400
Message-ID: <313680C9A886D511A06000204840E1CF57C319@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Jonathan Rosenberg'" ,
        "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Fri, 5 Oct 2001 16:00:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Length: 4145
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: 

We're getting wrapped around the axle because there are 4, 
not 3, not 2, not 1 variables. They aren't completely independent, 
but there are FOUR (4) of them!

1) Message format
2) Encapsulation
2) Transport protocol
3) Routing

We really do have a lot of combinations, but we should make
decisions independently for the four variables.

a) Do we want SIP MESSAGE, or CPIM?
Please don't confuse this with transport or routing.
If you want to talk about message choice, fine, we can do that.
For a while, I really thought Ben was wrong and we didn't need
to support CPIM in all cases.  If he is right, one format works
best, wouldn't you all agree?  So, if Ben is right, can we stop 
with the "Message" idea?

b) Do we want to wrap the message with SIP headers, or use something
like BXXP, or invent something new?  Somewhat related to format.
Seems to me if you do decide on cpim, then having the basic SIP
headers is duplicative.  Is that a big problem?  Probably not,
but it's really annoying.  You can turn it around and say use
SIP headers and Message, but you may ALSO have to deal with
cpim.  Even messier IMO.  Do we want anything that BXXP gives us?
There are some nice features -- do we care?
All we really need is a message delimiter if you use CPIM.  
Two CRLFs anyone?

Please keep in mind that pager mode is a given. 
Need one solution that works for both.  
This affects choices - argues for not using BXXP for example.

c) Do we agree on TCP for transport?  There is no other real choice
on the table unless folks want to argue with the ADs on UDP.
Can we just settle on TCP now?

d) Do we want to route on the SIP signalling path, or direct
UA-to-UA?  This is an independent problem folks, treat it like one.
My opinion here is that we want direct UA-to-UA.  The firewall
argument looms large, but we have to solve it for SIP, and the
same solution works for IM.  Yes, it's related to some of the
above, because if you DO want to route via the signalling
path, then you need SIP headers, and that pushes you in
a particular direction.  Maybe that implies we have to settle
this one first, BUT IT'S AN INDEPENDENT PROBLEM.

Now, are we all thinking clearly????

So, IMO:
	Direct UA-to-UA routing
	TCP transport
	SIP Headers
	cpim Body

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, October 05, 2001 3:16 PM
> To: 'Petri K. Koskelainen'; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] IM over the signaling connection
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> > Sent: Friday, October 05, 2001 2:59 PM
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] IM over the signaling connection
> > 
> > 
> > 
> > I guess you are talking about SIP over UDP.
> > SIP MESSAGE sessions over TCP does not lack congestion control.
> > Can you clarify that statement?
> > 
> > Only real problem left seems to be that there are 2-3 extra SIP
> > headers which are overhead (if SIP is used only as an 
> encapsulation).
> > 
> > I don't see this as a major problem.
> 
> Somehow my last point has not come across.
> 
> Forget about the syntax. Just, forget about it. 
> 
> THe ***>>>***!!!>>>MAIN<< forwarding of these things through intermediaries. If you are 
> saying that
> SIP MESSAGE is used for transport, then SIP proxies do the 
> forwarding, and
> things work using normal SIP proxy rules. THis means that you 
> cannot predict
> the transport, as it may change to UDP between proxies. 
> 
> -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 bcampbell@dynamicsoft.com  Fri Oct  5 16:14:47 2001
Received: from localhost.localdomain ([63.110.3.232])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03697
	for ; Fri, 5 Oct 2001 16:14:46 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f95K8nS02462;
	Fri, 5 Oct 2001 15:08:49 -0500
Message-ID: <3BBE1351.4000708@dynamicsoft.com>
Date: Fri, 05 Oct 2001 15:08:49 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Petri K. Koskelainen" 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: <200110051549.LAA10386@disco.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1104
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: 

As the writer of the draft, that was not the interpretation I intended, 
nor do I think it was the consensus at the time. In fact, it does not 
distinguish it in any way from saying it needs to be able to receive "foo."

That requirement was in the draft to reflect the requirement that any 
endpoint should be able to handle messages that came via a CPIM 
compliant gatway in a useful way. I believe we had a clear consensus on 
that point; perhaps the chairs could clarify.

Petri K. Koskelainen wrote:

>>The simple-im (page model, not session) draft says that an IM endpoint 
>>MUST be prepared to receive message/cpim, and MAY send message/cpim. I 
>>think that is pretty clear.
>>
>>
> 
> Yep, it may receive it and respond with 415 Unsupported Media Type.
>  
> I'm not convinced that CPIM will ever be used in real world
> even if one day CPIM format (or the proposed new CPIM-based 
> SIP-like format for instant messages) is ready.
> In most cases, text/plain will do the job without extra overhead
> in SIP payload and the need to create and test yet another format. 
> 
> 
> --
> Petri
> 




From lra101@yahoo.com  Fri Oct  5 17:55:04 2001
Received: from web9807.mail.yahoo.com (web9807.mail.yahoo.com [216.136.129.32])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA04119
	for ; Fri, 5 Oct 2001 17:55:03 -0400 (EDT)
Message-ID: <20011005215453.8694.qmail@web9807.mail.yahoo.com>
Received: from [208.12.45.177] by web9807.mail.yahoo.com via HTTP; Fri, 05 Oct 2001 14:54:53 PDT
Date: Fri, 5 Oct 2001 14:54:53 -0700 (PDT)
From: a c 
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 809
Subject: [Simple] Possible IM Message solution??
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: 

hello,

 What do you all think about the following:

- IM session established as a regular sip session
- SDP contains m=message line
- SDP also contains a message server line
  ms=x.x.x.x, port (invite,200ok)

- All signalling flows as follows:

	e <---> proxies <---> e

- message as follows:

	e <---> message server <---> e

*  proxy server communicates to messaging server as to
which sessions (ip address/udp-tcp port numbers)
   are active.
 
advantages:

	- CPU utilization ok on proxy
	- IM with sessions
	- can do monitoring on the media server 
          if needed
	- conferencing should work
	- ??

comments?

alex

__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

From lra101@yahoo.com  Fri Oct  5 18:18:00 2001
Received: from web9806.mail.yahoo.com (web9806.mail.yahoo.com [216.136.129.29])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA04226
	for ; Fri, 5 Oct 2001 18:17:59 -0400 (EDT)
Message-ID: <20011005221749.72559.qmail@web9806.mail.yahoo.com>
Received: from [208.12.45.177] by web9806.mail.yahoo.com via HTTP; Fri, 05 Oct 2001 15:17:49 PDT
Date: Fri, 5 Oct 2001 15:17:49 -0700 (PDT)
From: a c 
Subject: [Simple] Possible IM Message solution?? 
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 918
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: 

The scanario below requires the endpoints to agree on
a messaging server. 

--------------------------
>hello,

 What do you all think about the following:

- IM session established as a regular sip session
- SDP contains m=message line
- SDP also contains a message server line
  ms=x.x.x.x, port (invite,200ok)

- All signalling flows as follows:

	e <---> proxies <---> e

- message as follows:

	e <---> message server <---> e

*  proxy server communicates to messaging server as to
which sessions (ip address/udp-tcp port numbers)
   are active.
 
advantages:

	- CPU utilization ok on proxy
	- IM with sessions
	- can do monitoring on the >message< server 
          if needed
	- conferencing should work
	- ??

comments?

alex



__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

From rrroy@att.com  Sun Oct  7 11:56:05 2001
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 LAA12485
	for ; Sun, 7 Oct 2001 11:56:04 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f97FtZ323165;
	Sun, 7 Oct 2001 11:55:36 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id LAA02383; Sun, 7 Oct 2001 11:54:15 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <42H4G8B3>; Sun, 7 Oct 2001 11:55:35 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: "Rosen, Brian" 
Cc: "'Jonathan Rosenberg'" ,
        "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Sun, 7 Oct 2001 11:55:33 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 7933
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: 

Hi, Brian:

I like to add other dimensions to yours one (Message format, Encapsulation,
Transport protocol, and Routing): a. Signaling and b. Media.

I. Paging Mode

A confusion is that both "signaling" and "message as media" can be
considered as "data." (For example, we are sending some data in the form of
paging as a part of signaling messages. This is also creating confusions.)

In paging mode, the "paging data" is sent over the signaling (MESSAGE) path
by "default" and, a SIP proxy is able to manipulate the routing of the
signaling messages. Indirectly, the "paging data" also gets the benefits of
"application layer routing " over the SIP signaling proxies. However, the
signaling message (plus, indirectly, the "paging data") is still carried
over a transport protocol (e.g., TCP or UDP). In this mode, the signaling
message (and paging data) is getting the benefits two types of
control/routing: 1. Application layer control/routing that SIP provides on
the top of the transport protocol (e.g. TCP or UDP) and 2. Transport layer
control/routing that TCP/IP (or others) provides.

II. Session  Mode

In session mode, there are two separate things: 1. Establishment of MESSAGE
session using the SIP signaling messages and 2. Sending of message as media
(media like audio or video). The first thing is that the SIP signaling
messages will be routed via SIP proxies using the usual SIP rules (however,
unlike paging, no data is sent). It will have the benefits of
control/routing of both SIP and TCP/IP layer as discussed in the case of
paging model.

But, in session mode, the message as "media [data]" is sent end-to-end (as
it is done in the case of audio or video in SIP). No SIP header is required
to send the media between the source and destination. Unlike paging mode,
"message as data" is not controlled using the SIP rules or not routed over
the SIP signaling proxies. "Message as data" is controlled/routed using the
TCP/IP or other transport rules (no application layer SIP rules for control
or routing are applicable).

The question that has been raised whether the "message as data" can also be
routed over the SIP signaling path as it has been done in the case of paging
mode (in addition to the end-to-end). This is something new in SIP model.
Let us talk about this why we need to do this. Then we can suggest some
solutions along with their pros and cons.

III. Reconciliation between Paging and Session Mode

There can be several ways to reconcile these two modes of communications.
Some of the solutions may be radical in nature and may invite to reconsider
some fundamental aspects of SIP defining new methods. I would like to keep
this discussion away until such time when we can establish the clear needs
for reconciliation between these two schemes. In the meantime, let us
consider that the paging mode is a special case of one-way "data" transfer
in SIP.

IV. SIP as Transport?

I could not clearly understand the buzzword like "SIP as Transport." Can
anyone clearly define this with technical specifications before we interpret
it? Unless it is clearly define in technical terms, we will remain subject
to misinterpretations.

I have just expanded the discussion of "transport protocol" and "routing"
part only. If we could clarify these two aspects first, the rest can also be
addressed later.

Best regards,

Radhika R. Roy
rrroy@att.com


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, October 05, 2001 4:00 PM
To: 'Jonathan Rosenberg'; 'Petri K. Koskelainen';
simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection


We're getting wrapped around the axle because there are 4, 
not 3, not 2, not 1 variables. They aren't completely independent, 
but there are FOUR (4) of them!

1) Message format
2) Encapsulation
2) Transport protocol
3) Routing

We really do have a lot of combinations, but we should make
decisions independently for the four variables.

a) Do we want SIP MESSAGE, or CPIM?
Please don't confuse this with transport or routing.
If you want to talk about message choice, fine, we can do that.
For a while, I really thought Ben was wrong and we didn't need
to support CPIM in all cases.  If he is right, one format works
best, wouldn't you all agree?  So, if Ben is right, can we stop 
with the "Message" idea?

b) Do we want to wrap the message with SIP headers, or use something
like BXXP, or invent something new?  Somewhat related to format.
Seems to me if you do decide on cpim, then having the basic SIP
headers is duplicative.  Is that a big problem?  Probably not,
but it's really annoying.  You can turn it around and say use
SIP headers and Message, but you may ALSO have to deal with
cpim.  Even messier IMO.  Do we want anything that BXXP gives us?
There are some nice features -- do we care?
All we really need is a message delimiter if you use CPIM.  
Two CRLFs anyone?

Please keep in mind that pager mode is a given. 
Need one solution that works for both.  
This affects choices - argues for not using BXXP for example.

c) Do we agree on TCP for transport?  There is no other real choice
on the table unless folks want to argue with the ADs on UDP.
Can we just settle on TCP now?

d) Do we want to route on the SIP signalling path, or direct
UA-to-UA?  This is an independent problem folks, treat it like one.
My opinion here is that we want direct UA-to-UA.  The firewall
argument looms large, but we have to solve it for SIP, and the
same solution works for IM.  Yes, it's related to some of the
above, because if you DO want to route via the signalling
path, then you need SIP headers, and that pushes you in
a particular direction.  Maybe that implies we have to settle
this one first, BUT IT'S AN INDEPENDENT PROBLEM.

Now, are we all thinking clearly????

So, IMO:
	Direct UA-to-UA routing
	TCP transport
	SIP Headers
	cpim Body

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, October 05, 2001 3:16 PM
> To: 'Petri K. Koskelainen'; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] IM over the signaling connection
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> > Sent: Friday, October 05, 2001 2:59 PM
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] IM over the signaling connection
> > 
> > 
> > 
> > I guess you are talking about SIP over UDP.
> > SIP MESSAGE sessions over TCP does not lack congestion control.
> > Can you clarify that statement?
> > 
> > Only real problem left seems to be that there are 2-3 extra SIP
> > headers which are overhead (if SIP is used only as an 
> encapsulation).
> > 
> > I don't see this as a major problem.
> 
> Somehow my last point has not come across.
> 
> Forget about the syntax. Just, forget about it. 
> 
> THe ***>>>***!!!>>>MAIN<< forwarding of these things through intermediaries. If you are 
> saying that
> SIP MESSAGE is used for transport, then SIP proxies do the 
> forwarding, and
> things work using normal SIP proxy rules. THis means that you 
> cannot predict
> the transport, as it may change to UDP between proxies. 
> 
> -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 jundery@ubiquity.net  Mon Oct  8 06:11:48 2001
Received: from drago1.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 GAA00566
	for ; Mon, 8 Oct 2001 06:11:47 -0400 (EDT)
Received: from mailhost.ubiquity.net by drago1.ubiquity.net
          via smtpd (for [63.113.40.50]) with SMTP; 8 Oct 2001 10:11:36 UT
Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 8 Oct 2001 11:12:14 +0100
From: "James Undery" 
To: "Ngo, Dai \(c\)" ,
        "'Moran Tim \(NET/Dallas\)'" ,
        "'ext Paul Kyzivat'" ,
        "Jonathan Rosenberg" 
Cc: 
Subject: RE: [Simple] 200 vs. 202
Date: Mon, 8 Oct 2001 11:11:49 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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.4807.1700
Importance: Normal
In-Reply-To: <492EB4A3F68CD411ABE800508B69362E6C4E30@RIPEXCH002.wcomnet.com>
X-OriginalArrivalTime: 08 Oct 2001 10:12:14.0512 (UTC) FILETIME=[B3C17300:01C14FE1]
Content-Length: 1820
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: 

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]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]
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]
> 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.




From jundery@ubiquity.net  Mon Oct  8 06:24:26 2001
Received: from drago1.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 GAA00636
	for ; Mon, 8 Oct 2001 06:24:26 -0400 (EDT)
Received: from mailhost.ubiquity.net by drago1.ubiquity.net
          via smtpd (for [63.113.40.50]) with SMTP; 8 Oct 2001 10:24:14 UT
Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 8 Oct 2001 11:24:57 +0100
From: "James Undery" 
To: "Brian Stucker" ,
        "Neil Deason" ,
        "Brazier Lachlan" ,
        "'Jonathan Rosenberg'" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Mon, 8 Oct 2001 11:24:32 +0100
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.4807.1700
Importance: Normal
In-Reply-To: <933FADF5E673D411B8A30002A5608A0E410BBB@zrc2c012.us.nortel.com>
X-OriginalArrivalTime: 08 Oct 2001 10:24:57.0005 (UTC) FILETIME=[7A3CA5D0:01C14FE3]
Content-Length: 3417
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: 

Hi,

403 is definately better than 488 which is more SDP related. If a PA
exists 403 would be better than 404, 404 is better if no routable PA
exists.

Then again I'd be happy to be contridicted on any of the above if it
results in a clear ruling.

James


-----Original Message-----
From: simple-admin@mailman.dynamicsoft.com
[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Brian
Stucker
Sent: 05 October 2001 16:10
To: Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg'; ''SIMPLE
Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok


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


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


From mhammer@cisco.com  Mon Oct  8 10:26:28 2001
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 KAA01405
	for ; Mon, 8 Oct 2001 10:26:28 -0400 (EDT)
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 KAA16780; Mon, 8 Oct 2001 10:26:10 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (rtp-vpn2-222.cisco.com [10.82.240.222])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ARV01043;
	Mon, 8 Oct 2001 10:26:14 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011008101815.00b21f10@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 08 Oct 2001 10:30:29 -0400
To: Jonathan Rosenberg 
From: Michael Hammer 
Subject: RE: [Simple] IM over the signaling connection
Cc: "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 2602
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: 

Jonathan,

Those that describe SIP as Transport do not have a proper understanding of 
the protocol stack.  You could likewise talk about SMTP as Transport.

I think the real issue here is addressing the congestion question.  For 
that, I think the main discriminator is why UDP or TCP or SCTP is used as 
the Transport Layer.  I believe that there is not an objection to using UDP 
for signaling and real-time media, as that is a requirement of the 
application.  While instant messaging is NEAR-real-time, it is not 
necessary to be real-time.  If TCP (or equivalent) was required for any 
MESSAGE (or equivalent) IM media transfer, would this not answer the 
congestion question?  We can dance around this question many ways, but I 
believe that until we come to that conclusion, the IESG will not be happy.

As for the MESSAGE headers question, I think that an adequate justification 
of the need for whatever parameters are used will answer that issue.

Mike



At 03:15 PM 10/5/2001 -0400, Jonathan Rosenberg wrote:


>
>
> > -----Original Message-----
> > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> > Sent: Friday, October 05, 2001 2:59 PM
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] IM over the signaling connection
> >
> >
> >
> > I guess you are talking about SIP over UDP.
> > SIP MESSAGE sessions over TCP does not lack congestion control.
> > Can you clarify that statement?
> >
> > Only real problem left seems to be that there are 2-3 extra SIP
> > headers which are overhead (if SIP is used only as an encapsulation).
> >
> > I don't see this as a major problem.
>
>Somehow my last point has not come across.
>
>Forget about the syntax. Just, forget about it.
>
>THe ***>>>***!!!>>>MAIN<<forwarding of these things through intermediaries. If you are saying that
>SIP MESSAGE is used for transport, then SIP proxies do the forwarding, and
>things work using normal SIP proxy rules. THis means that you cannot predict
>the transport, as it may change to UDP between proxies.
>
>-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 rrroy@att.com  Mon Oct  8 10:58:10 2001
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 KAA01528
	for ; Mon, 8 Oct 2001 10:58:09 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f98Evgk14410;
	Mon, 8 Oct 2001 10:57:44 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id KAA11480; Mon, 8 Oct 2001 10:57:57 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <42H4H3JN>; Mon, 8 Oct 2001 10:57:41 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Michael Hammer ,
        Jonathan Rosenberg
	 
Cc: "'Petri K. Koskelainen'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Mon, 8 Oct 2001 10:57:37 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3949
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: 

Hi, Mike:

I agree with you. Please see my comments below [RRR].

Best regards,
Radhika

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: Monday, October 08, 2001 10:30 AM


Jonathan,

Those that describe SIP as Transport do not have a proper understanding of 
the protocol stack.  You could likewise talk about SMTP as Transport.

I think the real issue here is addressing the congestion question.  For 
that, I think the main discriminator is why UDP or TCP or SCTP is used as 
the Transport Layer.  I believe that there is not an objection to using UDP 
for signaling and real-time media, as that is a requirement of the 
application.

[RRR] I agree with you. I think that we can provide a preferred transport
(e.g., TCP) for IM, but provisions should be kept for using other transports
as well.

While instant messaging is NEAR-real-time, it is not 
necessary to be real-time.  If TCP (or equivalent) was required for any 
MESSAGE (or equivalent) IM media transfer, would this not answer the 
congestion question?  We can dance around this question many ways, but I 
believe that until we come to that conclusion, the IESG will not be happy.

[RRR] If a MESSAGE session is established using SIP signaling schemes, the
media (IM) is sent over the transport network using a transport protocol
(e.g., TCP/IP). The transport protocol needs to be able to take care-of the
congestion control as it does for all other application and, no application
layer SIP headers will be allowed to control the lower layer transport
protocol. Because it will be violation of the protocol layering. (By the
way, options also be allowed to send the media [IM] using UDP/IP or other
transports).

As for the MESSAGE headers question, I think that an adequate justification 
of the need for whatever parameters are used will answer that issue.

[RRR] All required information will be provided in MESSAGE headers while the
session will be established. You are right that proper justification needs
to be provided why the other parameters are needed. For example, people can
expect that a centralized data bridge is needed for multi-party message
chat. The SIP signaling layer SHOULD be good enough to provide indication
that the media (IM) needs to go via a centralized bridge, and the media (IM)
will be transferred accordingly using the transport protocol (and, no
additional SIP headers are needed).

Mike



At 03:15 PM 10/5/2001 -0400, Jonathan Rosenberg wrote:


>
>
> > -----Original Message-----
> > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> > Sent: Friday, October 05, 2001 2:59 PM
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] IM over the signaling connection
> >
> >
> >
> > I guess you are talking about SIP over UDP.
> > SIP MESSAGE sessions over TCP does not lack congestion control.
> > Can you clarify that statement?
> >
> > Only real problem left seems to be that there are 2-3 extra SIP
> > headers which are overhead (if SIP is used only as an encapsulation).
> >
> > I don't see this as a major problem.
>
>Somehow my last point has not come across.
>
>Forget about the syntax. Just, forget about it.
>
>THe ***>>>***!!!>>>MAIN<<forwarding of these things through intermediaries. If you are saying that
>SIP MESSAGE is used for transport, then SIP proxies do the forwarding, and
>things work using normal SIP proxy rules. THis means that you cannot
predict
>the transport, as it may change to UDP between proxies.
>
>-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
>_______________________________________________

From amesbrn@yahoo.com  Fri Oct  5 17:28:53 2001
Received: from web14702.mail.yahoo.com (web14702.mail.yahoo.com [216.136.224.119])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA03983
	for ; Fri, 5 Oct 2001 17:28:53 -0400 (EDT)
Message-ID: <20011005211834.61365.qmail@web14702.mail.yahoo.com>
Received: from [208.12.45.177] by web14702.mail.yahoo.com via HTTP; Fri, 05 Oct 2001 14:18:34 PDT
Date: Fri, 5 Oct 2001 14:18:34 -0700 (PDT)
From: ames brown 
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 813
Subject: [Simple] Possible IM Message solution??
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: 

hello,

 What do you all think about the following:

- IM session established as a regular sip session
- SDP contains m=message line
- SDP also contains a message server line
  ms=x.x.x.x, port (invite,200ok)

- All signalling flows as follows:

	e <---> proxies <---> e

- Media as follows:

	e <---> message server <---> e

*  proxy server communicates to messaging server as to
which sessions (ip address/udp-tcp port numbers) are
active.
 
advantages:

	- CPU utilization ok on proxy
	- IM with sessions
	- can do monitoring on the media server 
          if needed
	- conferencing should work
	- ??

comments?

ames
	

=====


__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

From rrroy@att.com  Mon Oct  8 12:31:48 2001
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 MAA01871
	for ; Mon, 8 Oct 2001 12:31:48 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f98GVR309613;
	Mon, 8 Oct 2001 12:31:28 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id MAA07722; Mon, 8 Oct 2001 12:30:03 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <42H4H45T>; Mon, 8 Oct 2001 12:31:23 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: ames brown , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Possible IM Message solution??
Date: Mon, 8 Oct 2001 12:31:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1877
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: 

Hi, Ames:

On theory, you are extending the signaling layer (e.g., SDP) and, are not
violating the protocol layering.

The extension that you have proposed in SDP is entirely a different
dimension: Routing of Media via the media (application) server(s). You can
think a scenario where multiple servers may also be involved. (I hope that
you are NOT proposing routing of media via network layer devices like
routers.)

I imagine that it will open entirely a new area for SDP: Routing of media
via media (application) servers (similar to routing of signaling messages
via SIP proxies).

What are the implications of such extensions in SDP?

Experts opinions are needed.

Best regards,

Radhika R. Roy
rrroy@att.com

-----Original Message-----
From: ames brown [mailto:amesbrn@yahoo.com]
Sent: Friday, October 05, 2001 5:19 PM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] Possible IM Message solution??


hello,

 What do you all think about the following:

- IM session established as a regular sip session
- SDP contains m=message line
- SDP also contains a message server line
  ms=x.x.x.x, port (invite,200ok)

- All signalling flows as follows:

	e <---> proxies <---> e

- Media as follows:

	e <---> message server <---> e

*  proxy server communicates to messaging server as to
which sessions (ip address/udp-tcp port numbers) are
active.
 
advantages:

	- CPU utilization ok on proxy
	- IM with sessions
	- can do monitoring on the media server 
          if needed
	- conferencing should work
	- ??

comments?

ames
	

=====


__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just
$8.95/month.
http://geocities.yahoo.com/ps/info1
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

From HUITEMA@windows.microsoft.com  Mon Oct  8 13:12:05 2001
Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA02014
	for ; Mon, 8 Oct 2001 13:12:04 -0400 (EDT)
Received: from 157.54.1.52 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 10:09:09 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 8 Oct 2001 10:09:08 -0700
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);
	 Mon, 8 Oct 2001 10:09:00 -0700
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(5.0.2195.2966);
	 Mon, 8 Oct 2001 10:06:37 -0700
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Simple] IM over the signaling connection
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Date: Mon, 8 Oct 2001 10:06:36 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] IM over the signaling connection
Thread-Index: AcFOvNTradMS7nhhQdm1D3svlrrTZQBXTIEw
From: "Christian Huitema" 
To: "Ben Campbell" ,
        "Jonathan Rosenberg" 
Cc: "Henning Schulzrinne" ,
        "Peterson, Jon" , ,
        
X-OriginalArrivalTime: 08 Oct 2001 17:06:37.0022 (UTC) FILETIME=[96F767E0:01C1501B]
Content-Length: 1017
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA02014
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: 

There are two points that I keep in mind in this debate:

1) SMS, the messaging service of cell phones, uses the page mode and is
carried at least in part over the signaling channel. 

2) CPIM's Message function looks a lot like the page mode.

It seems that the first step forward is to recognize this and assume
that we will indeed use "MESSAGE over SIP" in the page mode for a
significant fraction of our exchanges. I suggest that the first order
action of SIMPLE is to just nail this one, so it be behind us.

The page mode has well known limitations: it creates a lot of overhead
in long sessions, and it does not extend easily to multi-party
operation. This is the rationale for the "IM session" extensions, i.e.
IM after INVITE. However, whatever we do in the session mode, we will
have to go on interworking with SMS and with CPIM; this means that we
will have to bring in the session some members who can only use the page
mode. Obviously, a "session of messages" makes this very easy.

-- Christian Huitema

From mhammer@cisco.com  Mon Oct  8 13:41:59 2001
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 NAA02136
	for ; Mon, 8 Oct 2001 13:41:58 -0400 (EDT)
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 NAA24331; Mon, 8 Oct 2001 13:41:46 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (rtp-vpn2-222.cisco.com [10.82.240.222])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ARW01824;
	Mon, 8 Oct 2001 13:41:49 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011008134317.00b0e848@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 08 Oct 2001 13:46:04 -0400
To: "Christian Huitema" 
From: Michael Hammer 
Subject: RE: [Simple] IM over the signaling connection
Cc: "Ben Campbell" ,
        "Jonathan Rosenberg" ,
        "Henning Schulzrinne" ,
        "Peterson, Jon" , ,
        
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 1515
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: 

Christian,

The only problem with this comparison is that the SMS messages are limited 
in size, I believe, to 256 octets, maybe less.  If volume is not restricted 
this could be a problem.  This could be an interworking issue.

Is CPIM limited in any way?

Mike


At 10:06 AM 10/8/2001 -0700, Christian Huitema wrote:
>There are two points that I keep in mind in this debate:
>
>1) SMS, the messaging service of cell phones, uses the page mode and is
>carried at least in part over the signaling channel.
>
>2) CPIM's Message function looks a lot like the page mode.
>
>It seems that the first step forward is to recognize this and assume
>that we will indeed use "MESSAGE over SIP" in the page mode for a
>significant fraction of our exchanges. I suggest that the first order
>action of SIMPLE is to just nail this one, so it be behind us.
>
>The page mode has well known limitations: it creates a lot of overhead
>in long sessions, and it does not extend easily to multi-party
>operation. This is the rationale for the "IM session" extensions, i.e.
>IM after INVITE. However, whatever we do in the session mode, we will
>have to go on interworking with SMS and with CPIM; this means that we
>will have to bring in the session some members who can only use the page
>mode. Obviously, a "session of messages" makes this very easy.
>
>-- Christian Huitema
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple


From bstucker@nortelnetworks.com  Mon Oct  8 14:54:49 2001
Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02371
	for ; Mon, 8 Oct 2001 14:54:46 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f98IrmS04998
	for ; Mon, 8 Oct 2001 14:53:48 -0400 (EDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Mon, 8 Oct 2001 13:47:43 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 8 Oct 2001 13:53:59 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E4DF359@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: James Undery , "Ngo, Dai (c)" ,
        "'Moran Tim (NET/Dallas)'" ,
        "'ext Paul Kyzivat'" ,
        Jonathan Rosenberg 
Cc: simple 
Subject: RE: [Simple] 200 vs. 202
Date: Mon, 8 Oct 2001 13:53:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1502A.93D89DE0"
X-Orig: 
Content-Length: 8269
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: 

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_01C1502A.93D89DE0
Content-Type: text/plain;
	charset="windows-1252"

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]
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]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]
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]
> 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

------_=_NextPart_001_01C1502A.93D89DE0
Content-Type: text/html;
	charset="windows-1252"
Content-Transfer-Encoding: quoted-printable






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]

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]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]

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]=


> 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=






------_=_NextPart_001_01C1502A.93D89DE0--

From adam.roach@ericsson.com  Mon Oct  8 15:13:42 2001
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 PAA02447
	for ; Mon, 8 Oct 2001 15:13:40 -0400 (EDT)
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 f98JCQ000857;
	Mon, 8 Oct 2001 14:12:26 -0500 (CDT)
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 f98JCQr14506;
	Mon, 8 Oct 2001 14:12:26 -0500 (CDT)
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 OAA14500; Mon, 8 Oct 2001 14:12:25 -0500 (CDT)
Reply-To: 
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
Date: Mon, 8 Oct 2001 14:12:23 -0500
Message-ID: <61D824C63B99D311975E00508B0CC98502C66B69@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: <933FADF5E673D411B8A30002A5608A0E4DF359@zrc2c012.us.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 3662
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: 

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]
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]
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]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]
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]
> 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


From bstucker@nortelnetworks.com  Mon Oct  8 15:21:09 2001
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 PAA02492
	for ; Mon, 8 Oct 2001 15:21:06 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA06806
	for ; Mon, 8 Oct 2001 14:20:43 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Mon, 8 Oct 2001 14:19:47 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 8 Oct 2001 14:20:06 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E4DF3D5@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: "adam.roach" ,
        James Undery ,
        "Ngo, Dai (c)" ,
        "'Moran Tim (NET/Dallas)'" ,
        "'ext Paul Kyzivat'" 
Cc: simple 
Subject: RE: [Simple] 200 vs. 202
Date: Mon, 8 Oct 2001 14:20:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1502E.3B3373F0"
Content-Length: 13504
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: 

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_01C1502E.3B3373F0
Content-Type: text/plain;
	charset="iso-8859-1"

Forking of SUBSCRIBEs in a general sense is very useful. I agree. What
I'm concerned with is that the event state that is being created is being
created according to the needs of the application. Some applications may not
be very strict about how this is done.

With presence, I think we need to be more strict about it than the current 
draft suggests.

Section 5.1.7.2 of your events -00 draft says that the NOTIFY after a 202
acts as notification that the subscription has finally been processed. I'm
all
for that model. What seems to make no sense is sending a NOTIFY that doesn't
really mean anything, then sending another NOTIFY later on that signifies
that
the subscription has finally been processed.

According to the revision of your draft that I have available to me, the 
meaningless NOTIFY after the 202 makes the 202 irrelevant. It's as good as
sending
a 200 in the first place in the general event framework.

Am I misreading 5.1.7.2?

Brian

-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Monday, October 08, 2001 2:12 PM
To: Stucker, Brian [NGB:B621:EXCH]; 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]
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]
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]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]
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]
> 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


------_=_NextPart_001_01C1502E.3B3373F0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] 200 vs. 202




Forking of SUBSCRIBEs in a general sense is very useful. I agree. What

I'm concerned with is that the event state that is being created is being

created according to the needs of the application. Some applications may not

be very strict about how this is done.




With presence, I think we need to be more strict about it than the current 

draft suggests.




Section 5.1.7.2 of your events -00 draft says that the NOTIFY after a 202

acts as notification that the subscription has finally been processed. I'm all

for that model. What seems to make no sense is sending a NOTIFY that doesn't

really mean anything, then sending another NOTIFY later on that signifies that

the subscription has finally been processed.




According to the revision of your draft that I have available to me, the 

meaningless NOTIFY after the 202 makes the 202 irrelevant. It's as good as sending

a 200 in the first place in the general event framework.




Am I misreading 5.1.7.2?




Brian




-----Original Message-----

From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]

Sent: Monday, October 08, 2001 2:12 PM

To: Stucker, Brian [NGB:B621:EXCH]; 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]

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]

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]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]

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]

> 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





------_=_NextPart_001_01C1502E.3B3373F0--

From lra101@yahoo.com  Mon Oct  8 16:42:50 2001
Received: from web9807.mail.yahoo.com (web9807.mail.yahoo.com [216.136.129.32])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA02794
	for ; Mon, 8 Oct 2001 16:42:49 -0400 (EDT)
Message-ID: <20011008204233.94581.qmail@web9807.mail.yahoo.com>
Received: from [208.12.45.206] by web9807.mail.yahoo.com via HTTP; Mon, 08 Oct 2001 13:42:33 PDT
Date: Mon, 8 Oct 2001 13:42:33 -0700 (PDT)
From: a c 
Subject: [Simple] Possible IM Message solution?? 
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1323
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: 

hello Radhika,

>(I hope that you are NOT proposing routing of media
via network layer devices like routers.)

no. This is an application server which processes 
IM messages and routes them to their endpoints. 
It cannot be used for voice due to the realtime
constraints. But it can definetly be used for 
IM traffic. It can do much more than  just 
passing traffic. For example : language 
translation,  calea, etc..

The only requirement is that it talks to 
the proxy. The proxy can instruct the 
application server to implement a certain feature 
per call. 

other advantages:

- drastically cuts down on header tags (no header 
  tags. Why do we need them when signalling 
  is taking care of it). 
- If no headers in the message, then it is easier 
  to convert to other protocols (e.g. cpim). No 
  parsing of headers for each message
- congestion control (app server initiated 
  congestion control)
- capability to do end to end or thru server

Addresses Brian Rosen's 4 variables:

        Direct UA-to-UA routing - can do both
        TCP transport - / udp
        SIP Headers - not necessary
        cpim Body - no problem

alex

__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

From Vasilis.Polychronidis@Openwave.com  Mon Oct  8 16:43:15 2001
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 QAA02811
	for ; Mon, 8 Oct 2001 16:43:15 -0400 (EDT)
Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26])
          by oe-mp1.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011008204043.RIRA13960.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>;
          Mon, 8 Oct 2001 15:40:43 -0500
Received: from Openwave.com ([64.14.128.39]) by oe-ismta1.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011008204249.BRQX1932.oe-ismta1.bizmailsrvcs.net@Openwave.com>;
          Mon, 8 Oct 2001 15:42:49 -0500
Message-ID: <3BC20FBE.1DB1B1B0@Openwave.com>
Date: Mon, 08 Oct 2001 13:42:38 -0700
From: Vasilis Polychronidis 
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema 
CC: Ben Campbell ,
        Jonathan Rosenberg ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: 
Content-Type: multipart/alternative;
 boundary="------------B54E569DCB368FB163587DDD"
Content-Length: 5661
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: 

--------------B54E569DCB368FB163587DDD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christian Huitema wrote:

> There are two points that I keep in mind in this debate:
>
> 1) SMS, the messaging service of cell phones, uses the page mode and is
> carried at least in part over the signaling channel.

Correct. However Operators realized that SMS was the wrong (was very
successful financially) technical solution for messaging.
Remind you that when the people designed (late 80s) SMS they did not have
any idea of how successful commercial service will be.
That is why the next generation of multimedia messaging is using HTTP as the
transport.
I understand that this is a difficult point to understand with some people
in the list.
Let me remind you that the telephony people with more than hundred years of
experience realized in the late seventies that
in order to scale and have very reliable networks you had to separate
signaling from transport (initially signaling was mixed with transport -
that is the current case for all the analog lines going from home to the
local switch --> DTMF) and they created SS7 and ISUP.
Actually people invented SIP using ISUP as their guide.
That was one of the initial arguments of SIP: separate proxies from
transport of user data.
It seems to me that certain people want to regress in time and mix signaling
and user data.
Let us please learn from the history and lets try not to repeat the same
mistakes.

>
>
> 2) CPIM's Message function looks a lot like the page mode.
>
> It seems that the first step forward is to recognize this and assume
> that we will indeed use "MESSAGE over SIP" in the page mode for a
> significant fraction of our exchanges. I suggest that the first order
> action of SIMPLE is to just nail this one, so it be behind us.
>
> The page mode has well known limitations: it creates a lot of overhead
> in long sessions, and it does not extend easily to multi-party
> operation. This is the rationale for the "IM session" extensions, i.e.
> IM after INVITE. However, whatever we do in the session mode, we will
> have to go on interworking with SMS and with CPIM; this means that we
> will have to bring in the session some members who can only use the page
> mode. Obviously, a "session of messages" makes this very easy.
>
> -- Christian Huitema
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

--------------B54E569DCB368FB163587DDD
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Christian Huitema wrote:

There are two points that I keep in mind in this
debate:

1) SMS, the messaging service of cell phones, uses the page mode and
is

carried at least in part over the signaling channel.

Correct. However Operators realized that SMS was
the wrong (was very successful financially) technical solution for messaging.

Remind you that when the people designed (late
80s) SMS they did not have any idea of how successful commercial service
will be.

That is why the next generation of multimedia
messaging is using HTTP as the transport.

I understand that this is a difficult point to
understand with some people in the list.

Let me remind you that the telephony people with
more than hundred years of experience realized in the late seventies that

in order to scale and have very reliable networks
you had to separate signaling from transport (initially signaling was mixed
with transport -

that is the current case for all the analog lines
going from home to the local switch --> DTMF) and they created SS7 and
ISUP.

Actually people invented SIP using ISUP as their
guide.

That was one of the initial arguments of SIP:
separate proxies from transport of user data.

It seems to me that certain people want to regress
in time and mix signaling and user data.

Let us please learn from the history and lets
try not to repeat the same mistakes.

 

2) CPIM's Message function looks a lot like the page mode.

It seems that the first step forward is to recognize this and assume

that we will indeed use "MESSAGE over SIP" in the page mode for a

significant fraction of our exchanges. I suggest that the first order

action of SIMPLE is to just nail this one, so it be behind us.

The page mode has well known limitations: it creates a lot of overhead

in long sessions, and it does not extend easily to multi-party

operation. This is the rationale for the "IM session" extensions, i.e.

IM after INVITE. However, whatever we do in the session mode, we will

have to go on interworking with SMS and with CPIM; this means that
we

will have to bring in the session some members who can only use the
page

mode. Obviously, a "session of messages" makes this very easy.

-- Christian Huitema

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple



--------------B54E569DCB368FB163587DDD--




From lra101@yahoo.com  Mon Oct  8 16:51:55 2001
Received: from web9801.mail.yahoo.com (web9801.mail.yahoo.com [216.136.129.211])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA02865
	for ; Mon, 8 Oct 2001 16:51:52 -0400 (EDT)
Message-ID: <20011008205134.51570.qmail@web9801.mail.yahoo.com>
Received: from [208.12.45.206] by web9801.mail.yahoo.com via HTTP; Mon, 08 Oct 2001 13:51:34 PDT
Date: Mon, 8 Oct 2001 13:51:34 -0700 (PDT)
From: a c 
Subject: [Simple] Possible IM Message solution?? 
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1592
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: 

It is something like the IN call model where the
Service Logic Layer is instructing the SSP to do
certain things. With SIP, you would like to have all
the features implemented at the endpoints but it is
not always possible without compromising other things.

alex

>>>
hello Radhika,

>(I hope that you are NOT proposing routing of media
via network layer devices like routers.)

no. This is an application server which processes 
IM messages and routes them to their endpoints. 
It cannot be used for voice due to the realtime
constraints. But it can definetly be used for 
IM traffic. It can do much more than  just 
passing traffic. For example : language 
translation,  calea, etc..

The only requirement is that it talks to 
the proxy. The proxy can instruct the 
application server to implement a certain feature 
per call. 

other advantages:

- drastically cuts down on header tags (no header 
  tags. Why do we need them when signalling 
  is taking care of it). 
- If no headers in the message, then it is easier 
  to convert to other protocols (e.g. cpim). No 
  parsing of headers for each message
- congestion control (app server initiated 
  congestion control)
- capability to do end to end or thru server

Addresses Brian Rosen's 4 variables:

        Direct UA-to-UA routing - can do both
        TCP transport - / udp
        SIP Headers - not necessary
        cpim Body - no problem

alex

__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

From Tim.Moran@nokia.com  Mon Oct  8 19:16:51 2001
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 TAA03330
	for ; Mon, 8 Oct 2001 19:16:50 -0400 (EDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.americas.nokia.com [172.18.194.217])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f98NH8f21616
	for ; Tue, 9 Oct 2001 02:17:09 +0300 (EET DST)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f98NGsQ22822
	for ; Mon, 8 Oct 2001 18:16:55 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 8 Oct 2001 18:16:30 -0500
Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 8 Oct 2001 18:16:30 -0500
content-class: urn:content-classes:message
Subject: RE: [Simple] 200 vs. 202
Date: Mon, 8 Oct 2001 18:16:30 -0500
Message-ID: <278B6B0D76698D45BBA872CD23DD496A0A41EA@daebe004.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1504F.4303D21B"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] 200 vs. 202
Thread-Index: AcFQLVX1QZvYZLwZEdWJUwAIx6TWpQAHS5Kg
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Moran Tim (NET/Dallas)" 
To: , "'Brian Stucker'" ,
        "James Undery" ,
        "Ngo, Dai (c)" ,
        "'ext Paul Kyzivat'" ,
        "Jonathan Rosenberg" 
Cc: "simple" 
X-OriginalArrivalTime: 08 Oct 2001 23:16:30.0335 (UTC) FILETIME=[433638F0:01C1504F]
Content-Length: 14711
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: 

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1504F.4303D21B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 ...

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

*=09
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]
> 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]
> 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]
> 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]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]
> 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]
> > 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
>=20


------_=_NextPart_001_01C1504F.4303D21B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Three-way handshake in my dictionary implies A->B, =
A<-B,=20
and then a A->B again. This is not the case in a Subscribe, 200/202 =
and then=20
a Notify in  the same direction as the 2xx.. I am also puzzled by =
your=20
"immediate" 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 =

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


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


So let's say a =
Subscribe is=20
forked and all the PAs respond with 202. The best one is returned to the =
watcher=20
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=20
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 would=20
be dropped. The PA which sent the 200 sends a Notify (immediately) which =
is=20
forwarded but there is no preceding 200 so the watcher drops it?  =
There is=20
the out-of-sequence clause, but if the 200 never appears wouldn't the =
notify be=20
rejected? Nodes which know they can't authorize at the time of =
subscription may=20
respond 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=20
notify.


Tim M.





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



------_=_NextPart_001_01C1504F.4303D21B--

From bstucker@nortelnetworks.com  Mon Oct  8 19:34:48 2001
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 TAA03402
	for ; Mon, 8 Oct 2001 19:34:47 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id SAA07468
	for ; Mon, 8 Oct 2001 18:34:31 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Mon, 8 Oct 2001 18:27:43 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 8 Oct 2001 18:33:58 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E4DF72B@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: "Moran Tim (NET/Dallas)" ,
        "adam.roach" ,
        James Undery ,
        "Ngo, Dai (c)" ,
        "'ext Paul Kyzivat'" ,
        Jonathan Rosenberg 
Cc: simple 
Subject: RE: [Simple] 200 vs. 202
Date: Mon, 8 Oct 2001 18:33:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15051.AE3693F0"
X-Orig: 
Content-Length: 19592
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: 

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_01C15051.AE3693F0
Content-Type: text/plain;
	charset="iso-8859-1"

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]
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]
> 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]
> 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]
> 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]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]
> 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]
> > 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
> 

------_=_NextPart_001_01C15051.AE3693F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






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]

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]

> 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]

> 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]

> 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]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]

> 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]=


> > 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=


> 





------_=_NextPart_001_01C15051.AE3693F0--

From francoisx.lessing@intel.com  Mon Oct  8 20:35:40 2001
Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03634
	for ; Mon, 8 Oct 2001 20:35:39 -0400 (EDT)
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id AAA12149
	for ; Tue, 9 Oct 2001 00:35:26 GMT
Received: from intel.com ([10.242.97.86])
 by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.6) with SMTP id M2001100817363216075
 ; Mon, 08 Oct 2001 17:36:32 -0700
Message-ID: <3BC2464D.84FD8A6B@intel.com>
Date: Mon, 08 Oct 2001 17:35:25 -0700
From: "Lessing, Francois" 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; 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
Content-Length: 1492
Subject: [Simple] Re-use of Call leg information in SUBCRIBE-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: 

Hi everyone,

The event notification drafts 'discourages' re-use of
call leg information [1] (see quote from draft at end of mail)

Does this mean we sometimes allow a SUBSCRIBE
request on an existing  call leg created by INVITE ?

To me this would not make sense, it seems to
go against the broader intention of the draft.

The only reason I can think where this might be
useful, is to SUBSCRIBE to a resource that is
associated with an existing call leg.

But, an event is only allowed to be identified
by event type, Request URI, and message body
as per the event notification draft [2]

If this behaviour is allowed, it also opens the door
for other questions that have not been addressed:

Q.How would a subscription terminate ?
A.When its associated call leg dies due to BYE ?
A. Wen it receives a SUBSCRIBE with expires = 0 ?
etc.

Is there a reason that we cannot replace the 'discouraged'
at the end of  [1] with a "NOT ALLOWED" ?

Any thoughts would be apreciated,

Francois Lessing
Trillium Digital Systems, an Intel company.


References:

[1] SIP-Specific Event Notification, Section 5.1.1:
"The relationship between subscriptions and (INVITE-initiated)
 sessions sharing the same call leg identification information is
 undefined. Re-using call leg information for subscriptions is
 discouraged."


[2] SIP-Specific Event Notification, Section 5.1.1:
Identification of events is provided by three pieces of
information: Request URI, Event Type, and (optionally)
message body.



From lachlan.brazier@siemens.at  Tue Oct  9 04:38:25 2001
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 EAA05094
	for ; Tue, 9 Oct 2001 04:38:24 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f998c5u02622;
	Tue, 9 Oct 2001 10:38:05 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id KAA20323;
	Tue, 9 Oct 2001 10:38:03 +0200 (MET DST)
Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta)
	id xma007358; Tue, 9 Oct 01 10:29:28 +0200
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <4QHX5QNR>; Tue, 9 Oct 2001 10:29:25 +0200
Message-ID: 
From: Brazier Lachlan 
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
Date: Tue, 9 Oct 2001 10:29:24 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 9724
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA05094
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: 

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
 ] 
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
 ] 
> 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
 ] 
> 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
 ] 
> 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
 ]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
 ] 
> 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
 ] 
> > 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
  
> 


From lachlan.brazier@siemens.at  Tue Oct  9 04:41:35 2001
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 EAA05121
	for ; Tue, 9 Oct 2001 04:41:35 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f998fNu03110;
	Tue, 9 Oct 2001 10:41:23 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id KAA25589;
	Tue, 9 Oct 2001 10:41:22 +0200 (MET DST)
Received: from vies194a.sie.siemens.at(158.226.134.124) by scesie13 via smap (V2.0beta)
	id xma012396; Tue, 9 Oct 01 10:32:49 +0200
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <4QHX5QR1>; Tue, 9 Oct 2001 10:32:43 +0200
Message-ID: 
From: Brazier Lachlan 
To: "'Michael Hammer'" ,
        Christian Huitema
	 
Cc: Ben Campbell ,
        Jonathan Rosenberg
	 ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: AW: [Simple] IM over the signaling connection
Date: Tue, 9 Oct 2001 10:32:42 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2305
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA05121
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: 

Hi,

there are websites where you can enter more than 256 octets (I think it's
restricted to 160 octets)
These "long" messages result into several SMS's at the receiver point.

Lachlan

> -----Ursprüngliche Nachricht-----
> Von: Michael Hammer [mailto:mhammer@cisco.com]
> Gesendet am: Montag, 08. Oktober 2001 19:46
> An: Christian Huitema
> Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
> Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
> Betreff: RE: [Simple] IM over the signaling connection
> 
> Christian,
> 
> The only problem with this comparison is that the SMS 
> messages are limited 
> in size, I believe, to 256 octets, maybe less.  If volume is 
> not restricted 
> this could be a problem.  This could be an interworking issue.
> 
> Is CPIM limited in any way?
> 
> Mike
> 
> 
> At 10:06 AM 10/8/2001 -0700, Christian Huitema wrote:
> >There are two points that I keep in mind in this debate:
> >
> >1) SMS, the messaging service of cell phones, uses the page 
> mode and is
> >carried at least in part over the signaling channel.
> >
> >2) CPIM's Message function looks a lot like the page mode.
> >
> >It seems that the first step forward is to recognize this and assume
> >that we will indeed use "MESSAGE over SIP" in the page mode for a
> >significant fraction of our exchanges. I suggest that the first order
> >action of SIMPLE is to just nail this one, so it be behind us.
> >
> >The page mode has well known limitations: it creates a lot 
> of overhead
> >in long sessions, and it does not extend easily to multi-party
> >operation. This is the rationale for the "IM session" 
> extensions, i.e.
> >IM after INVITE. However, whatever we do in the session mode, we will
> >have to go on interworking with SMS and with CPIM; this means that we
> >will have to bring in the session some members who can only 
> use the page
> >mode. Obviously, a "session of messages" makes this very easy.
> >
> >-- Christian Huitema
> >_______________________________________________
> >simple mailing list
> >simple@mailman.dynamicsoft.com
> >http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From salvatore.loreto@libero.it  Tue Oct  9 04:55:47 2001
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 EAA05188
	for ; Tue, 9 Oct 2001 04:55:47 -0400 (EDT)
Received: from libero.it (193.70.192.61) by smtp1.libero.it (6.0.024)
        id 3BB9DA440023ED93 for simple@mailman.dynamicsoft.com; Tue, 9 Oct 2001 10:55:29 +0200
Date: Tue,  9 Oct 2001 10:55:29 +0200
Message-Id: 
	
MIME-Version: 1.0
Content-Type: text/plain
From: "sal"
To: simple@mailman.dynamicsoft.com
X-XaM3-API-Version: 1.1.9.1.39.1.2
X-SenderIP: 212.177.57.193
Content-Length: 275
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA05188
Subject: [Simple] notify after terminating subscription
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: 

Hi,

i'm looking, on the presence's draft,
the flow messages "Client to Client Subscription
 with Presentity State Change"

why when the watcher terminating the subscription
it receive after a 200OK also an other NOTIFY from
that presentity?
i don't understood ... 

thanks


From rrroy@att.com  Tue Oct  9 08:47:52 2001
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 IAA05927
	for ; Tue, 9 Oct 2001 08:47:51 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f99ClbC12212;
	Tue, 9 Oct 2001 08:47:38 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id IAA15519; Tue, 9 Oct 2001 08:47:54 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <4QWPLX53>; Tue, 9 Oct 2001 08:47:37 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: a c , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Possible IM Message solution?? 
Date: Tue, 9 Oct 2001 08:47:36 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2397
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: 

Hi, Alex:

The way I understand your proposal is as follows:

1. Routing information of the MESSAGE signaling is pushed back to SDP.

2. Based on the routing information of the MESSAGE signaling path, one needs
to find out the media routing path over the message servers.

The question is: Why can we not generalize it so that we can see the big
picture where this proposal will lead us analyzing all implications? For
example, there can be multiple proxies and multiple media servers. It will
not be used for point-to-point communications, but will also be for
multipoint communications. Why can this principle not be used for other
media as well? Will this create conflicts with the already established
notions in SDP?

Radhika

-----Original Message-----
From: a c [mailto:lra101@yahoo.com]
Sent: Monday, October 08, 2001 4:43 PM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] Possible IM Message solution?? 


hello Radhika,

>(I hope that you are NOT proposing routing of media
via network layer devices like routers.)

no. This is an application server which processes 
IM messages and routes them to their endpoints. 
It cannot be used for voice due to the realtime
constraints. But it can definetly be used for 
IM traffic. It can do much more than  just 
passing traffic. For example : language 
translation,  calea, etc..

The only requirement is that it talks to 
the proxy. The proxy can instruct the 
application server to implement a certain feature 
per call. 

other advantages:

- drastically cuts down on header tags (no header 
  tags. Why do we need them when signalling 
  is taking care of it). 
- If no headers in the message, then it is easier 
  to convert to other protocols (e.g. cpim). No 
  parsing of headers for each message
- congestion control (app server initiated 
  congestion control)
- capability to do end to end or thru server

Addresses Brian Rosen's 4 variables:

        Direct UA-to-UA routing - can do both
        TCP transport - / udp
        SIP Headers - not necessary
        cpim Body - no problem

alex

__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just
$8.95/month.
http://geocities.yahoo.com/ps/info1
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

From rrroy@att.com  Tue Oct  9 09:12:58 2001
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 JAA06021
	for ; Tue, 9 Oct 2001 09:12:57 -0400 (EDT)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f99DCa318551;
	Tue, 9 Oct 2001 09:12:36 -0400 (EDT)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id JAA11599; Tue, 9 Oct 2001 09:12:52 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <4QWPLZQY>; Tue, 9 Oct 2001 09:12:35 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Brazier Lachlan 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Tue, 9 Oct 2001 09:12:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2630
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA06021
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: 

Hi, All:

The idea would be to limit the "maximum" size of data in paging mode.

The longer message will create multiple paging streams, and let the
application take care-of this (although it will be discouraged to make the
message size longer).

Radhika

-----Original Message-----
From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
Sent: Tuesday, October 09, 2001 4:33 AM
To: 'Michael Hammer'; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: AW: [Simple] IM over the signaling connection


Hi,

there are websites where you can enter more than 256 octets (I think it's
restricted to 160 octets)
These "long" messages result into several SMS's at the receiver point.

Lachlan

> -----Ursprüngliche Nachricht-----
> Von: Michael Hammer [mailto:mhammer@cisco.com]
> Gesendet am: Montag, 08. Oktober 2001 19:46
> An: Christian Huitema
> Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
> Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
> Betreff: RE: [Simple] IM over the signaling connection
> 
> Christian,
> 
> The only problem with this comparison is that the SMS 
> messages are limited 
> in size, I believe, to 256 octets, maybe less.  If volume is 
> not restricted 
> this could be a problem.  This could be an interworking issue.
> 
> Is CPIM limited in any way?
> 
> Mike
> 
> 
> At 10:06 AM 10/8/2001 -0700, Christian Huitema wrote:
> >There are two points that I keep in mind in this debate:
> >
> >1) SMS, the messaging service of cell phones, uses the page 
> mode and is
> >carried at least in part over the signaling channel.
> >
> >2) CPIM's Message function looks a lot like the page mode.
> >
> >It seems that the first step forward is to recognize this and assume
> >that we will indeed use "MESSAGE over SIP" in the page mode for a
> >significant fraction of our exchanges. I suggest that the first order
> >action of SIMPLE is to just nail this one, so it be behind us.
> >
> >The page mode has well known limitations: it creates a lot 
> of overhead
> >in long sessions, and it does not extend easily to multi-party
> >operation. This is the rationale for the "IM session" 
> extensions, i.e.
> >IM after INVITE. However, whatever we do in the session mode, we will
> >have to go on interworking with SMS and with CPIM; this means that we
> >will have to bring in the session some members who can only 
> use the page
> >mode. Obviously, a "session of messages" makes this very easy.
> >
> >-- Christian Huitema
> >_______________________________________________
> >

From rrroy@att.com  Tue Oct  9 09:24:20 2001
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 JAA06080
	for ; Tue, 9 Oct 2001 09:24:09 -0400 (EDT)
Received: from mo3980r1.ems.att.com ([135.38.12.14])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f99DNak25455;
	Tue, 9 Oct 2001 09:23:39 -0400 (EDT)
Received: from njb140bh3.ems.att.com by mo3980r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id JAA19849; Tue, 9 Oct 2001 09:18:33 -0400 (EDT)
Received: by njb140bh3.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <4QWRS78Z>; Tue, 9 Oct 2001 09:23:31 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Vasilis Polychronidis ,
        Christian Huitema 
Cc: Ben Campbell ,
        Jonathan Rosenberg
	 ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Tue, 9 Oct 2001 09:23:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C150C5.955D3EA0"
Content-Length: 7988
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: 

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_01C150C5.955D3EA0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi, Vasilis:
 
Good that you have reminded the very important lesson from the past.
 
Would please let us know your opinion what do we do in the case of "Paging"
in SIP?
 
Of course, we have another scheme: MESSAGE as session.
 
Radhika

-----Original Message-----
From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com]
Sent: Monday, October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection


Christian Huitema wrote: 

There are two points that I keep in mind in this debate: 

1) SMS, the messaging service of cell phones, uses the page mode and is 
carried at least in part over the signaling channel.

Correct. However Operators realized that SMS was the wrong (was very
successful financially) technical solution for messaging. 
Remind you that when the people designed (late 80s) SMS they did not have
any idea of how successful commercial service will be. 
That is why the next generation of multimedia messaging is using HTTP as the
transport. 
I understand that this is a difficult point to understand with some people
in the list. 
Let me remind you that the telephony people with more than hundred years of
experience realized in the late seventies that 
in order to scale and have very reliable networks you had to separate
signaling from transport (initially signaling was mixed with transport - 
that is the current case for all the analog lines going from home to the
local switch --> DTMF) and they created SS7 and ISUP. 
Actually people invented SIP using ISUP as their guide. 
That was one of the initial arguments of SIP: separate proxies from
transport of user data. 
It seems to me that certain people want to regress in time and mix signaling
and user data. 
Let us please learn from the history and lets try not to repeat the same
mistakes. 

  

2) CPIM's Message function looks a lot like the page mode. 


It seems that the first step forward is to recognize this and assume 
that we will indeed use "MESSAGE over SIP" in the page mode for a 
significant fraction of our exchanges. I suggest that the first order 
action of SIMPLE is to just nail this one, so it be behind us. 


The page mode has well known limitations: it creates a lot of overhead 
in long sessions, and it does not extend easily to multi-party 
operation. This is the rationale for the "IM session" extensions, i.e. 
IM after INVITE. However, whatever we do in the session mode, we will 
have to go on interworking with SMS and with CPIM; this means that we 
will have to bring in the session some members who can only use the page 
mode. Obviously, a "session of messages" makes this very easy. 


-- Christian Huitema 
_______________________________________________ 



------_=_NextPart_001_01C150C5.955D3EA0
Content-Type: text/html;
	charset="iso-8859-1"









Hi, 
Vasilis:


 


Good 
that you have reminded the very important lesson from the 
past.


 


Would 
please let us know your opinion what do we do in the case of "Paging" in 
SIP?


 


Of 
course, we have another scheme: MESSAGE as session.


 


Radhika



  
-----Original Message-----
From: Vasilis Polychronidis 
  [mailto:Vasilis.Polychronidis@openwave.com]
Sent: Monday, October 
  08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; 
  Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon; Avshalom@ubique.com; 
  simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the 
  signaling connection

Christian Huitema wrote: 
  
There are two points that I keep in mind in this 
    debate: 
    
1) SMS, the messaging service of cell phones, uses the page mode and is 
    
carried at least in part over the signaling channel.
Correct. However Operators realized that SMS was the wrong (was 
  very successful financially) technical solution for messaging. 
  
Remind you that when the people designed (late 80s) 
  SMS they did not have any idea of how successful commercial service will 
  be. 
That is why the next generation of 
  multimedia messaging is using HTTP as the transport. 
I understand that this is a difficult point to understand with 
  some people in the list. 
Let me remind you that 
  the telephony people with more than hundred years of experience realized in 
  the late seventies that 
in order to scale and 
  have very reliable networks you had to separate signaling from transport 
  (initially signaling was mixed with transport - 
that is the current case for all the analog lines going from 
  home to the local switch --> DTMF) and they created SS7 and ISUP. 
  
Actually people invented SIP using ISUP as their 
  guide. 
That was one of the initial arguments of 
  SIP: separate proxies from transport of user data. 
It seems to me that certain people want to regress in time and 
  mix signaling and user data. 
Let us please 
  learn from the history and lets try not to repeat the same mistakes. 
  
  
    
2) CPIM's Message function looks a lot like the page mode. 
    
It seems that the first step forward is to recognize this and assume 
    
that we will indeed use "MESSAGE over SIP" in the page mode for a 
    
significant fraction of our exchanges. I suggest that the first order 
    
action of SIMPLE is to just nail this one, so it be behind us. 
    
The page mode has well known limitations: it creates a lot of overhead 
    
in long sessions, and it does not extend easily to multi-party 
    
operation. This is the rationale for the "IM session" extensions, i.e. 
    
IM after INVITE. However, whatever we do in the session mode, we will 
    
have to go on interworking with SMS and with CPIM; this means that we 
    
will have to bring in the session some members who can only use the page 
    
mode. Obviously, a "session of messages" makes this very easy. 
    
-- Christian Huitema 
_______________________________________________ 
    


------_=_NextPart_001_01C150C5.955D3EA0--

From c-Dai.Ngo@WCOM.Com  Tue Oct  9 09:33:13 2001
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 JAA06147
	for ; Tue, 9 Oct 2001 09:33:12 -0400 (EDT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.wcom.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GKX0037UXMM1H@firewall.wcom.com> for
 simple@mailman.dynamicsoft.com; Tue,  9 Oct 2001 13:32:47 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0GKX00G01XMDMX@pmismtp02.wcomnet.com>;
 Tue, 09 Oct 2001 13:32:46 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0GKX00F4LXM8WD@pmismtp02.wcomnet.com>; Tue,
 09 Oct 2001 13:32:32 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2653.19)
	id ; Tue, 09 Oct 2001 13:32:32 +0000
Content-return: allowed
Date: Tue, 09 Oct 2001 13:32:27 +0000
From: "Ngo, Dai (c)" 
Subject: RE: [Simple] 200 vs. 202
To: "'Brazier Lachlan'" ,
        "'Brian Stucker'" ,
        "Moran Tim (NET/Dallas)" ,
        "adam.roach" ,
        James Undery ,
        "'ext Paul Kyzivat'" ,
        Jonathan Rosenberg 
Cc: simple 
Message-id: <492EB4A3F68CD411ABE800508B69362E6C4E34@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=ISO-8859-1
Content-Length: 10862
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA06147
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: 

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
 ] 
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
 ] 
> 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
 ] 
> 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
 ] 
> 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
 ]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
 ] 
> 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
 ] 
> > 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
  
> 

From bstucker@nortelnetworks.com  Tue Oct  9 10:52:22 2001
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 KAA06404
	for ; Tue, 9 Oct 2001 10:52:21 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA06455
	for ; Tue, 9 Oct 2001 09:52:04 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Tue, 9 Oct 2001 09:51:08 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 9 Oct 2001 09:51:29 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E4DFA98@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Brazier Lachlan ,
        "Moran Tim (NET/Dallas)" ,
        "adam.roach" ,
        James Undery ,
        "Ngo, Dai (c)" ,
        "'ext Paul Kyzivat'" ,
        Jonathan Rosenberg 
Cc: simple 
Subject: RE: [Simple] 200 vs. 202
Date: Tue, 9 Oct 2001 09:51:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C150D1.DD882A80"
Content-Length: 33346
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: 

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_01C150D1.DD882A80
Content-Type: text/plain;
	charset="iso-8859-1"

I think I'm seeing the light a bit more... The events draft does state that
you need to
be ready to get a NOTIFY before the SUBSCRIBE finished (due to dropped
packets), so I guess
the tag matching isn't so strict on the first NOTIFY, and not having the TO
tag from the
SUBSCRIBE response isn't considered to be a problem.

The text that seems to be causing the confusion is in section 3:

"...Once authorized, the presence agent sends a 202 Accepted response. It
also sends an
immediate NOTIFY message containing the state of the presentity..."

The -00 revision of the events draft (unless I'm missing it in my reading)
says:

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

5.1.7.2:
"...Upon successful creation or refreshing of a subscription,
     notifiers MUST send a NOTIFY message as soon as practical to
     communicate the current resource state to the subscriber...."

"...If the response to the SUBSCRIBE message was 202, this initial
     NOTIFY will serve as indication that the subscription has finally
     been processed...."

Having read it again, I think I now understand what Adam meant by a 3-way
handshake, and it
does exist in the -00 version of the draft. I think the wording in section
5.1.7.2 does not 
apply to a NOTIFY that is empty. An empty NOTIFY does not create a
subscription (I think).

If we look at it this way, then you can see the three-way handshake, and why
the empty NOTIFY
after a 202 is important after all (just realizing this).

The SUBSCRIBE is the first leg of the handshake A->B, the 2xx/empty NOTIFY
is the second leg of
the handshake B->A, and the response to the empty NOTIFY is the third leg
A->B.

This makes a ton more sense (at least to me). The wording is a bit vague,
but if you take the
position that an empty NOTIFY signifies nothing regarding the subscription
status, and that the 202
response isn't telling the subscriber that there's going to be a delay
before ANY NOTIFY is sent, but
instead before a meaningful NOTIFY is sent, then this makes sense.

There's even a blurb about getting a NOTIFY with expires=0 after a 202 is to
be treated as a 603 decline
by the subscriber. So I think this was the behaviour that was intended.

Thoughts?

Brian

-----Original Message-----
From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
Sent: Tuesday, October 09, 2001 3:29 AM
To: Stucker, Brian [NGB:B621:EXCH]; 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
 ] 
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
 ] 
> 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
 ] 
> 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
 ] 
> 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
 ]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
 ] 
> 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
 ] 
> > 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
  
> 


------_=_NextPart_001_01C150D1.DD882A80
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] 200 vs. 202




I think I'm seeing the light a bit more... The events draft does state that you need to

be ready to get a NOTIFY before the SUBSCRIBE finished (due to dropped packets), so I guess

the tag matching isn't so strict on the first NOTIFY, and not having the TO tag from the

SUBSCRIBE response isn't considered to be a problem.




The text that seems to be causing the confusion is in section 3:




"...Once authorized, the presence agent sends a 202 Accepted response. It also sends an

immediate NOTIFY message containing the state of the presentity..."




The -00 revision of the events draft (unless I'm missing it in my reading) says:




5.1.7.1:

"A 202 response indicates that there may be a sizable delay before a notification 

is received, pending the actual creation of the subscription."




5.1.7.2:

"...Upon successful creation or refreshing of a subscription,

     notifiers MUST send a NOTIFY message as soon as practical to

     communicate the current resource state to the subscriber...."




"...If the response to the SUBSCRIBE message was 202, this initial

     NOTIFY will serve as indication that the subscription has finally

     been processed...."




Having read it again, I think I now understand what Adam meant by a 3-way handshake, and it

does exist in the -00 version of the draft. I think the wording in section 5.1.7.2 does not 

apply to a NOTIFY that is empty. An empty NOTIFY does not create a subscription (I think).




If we look at it this way, then you can see the three-way handshake, and why the empty NOTIFY

after a 202 is important after all (just realizing this).




The SUBSCRIBE is the first leg of the handshake A->B, the 2xx/empty NOTIFY is the second leg of

the handshake B->A, and the response to the empty NOTIFY is the third leg A->B.




This makes a ton more sense (at least to me). The wording is a bit vague, but if you take the

position that an empty NOTIFY signifies nothing regarding the subscription status, and that the 202

response isn't telling the subscriber that there's going to be a delay before ANY NOTIFY is sent, but

instead before a meaningful NOTIFY is sent, then this makes sense.




There's even a blurb about getting a NOTIFY with expires=0 after a 202 is to be treated as a 603 decline

by the subscriber. So I think this was the behaviour that was intended.




Thoughts?




Brian




-----Original Message-----

From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]

Sent: Tuesday, October 09, 2001 3:29 AM

To: Stucker, Brian [NGB:B621:EXCH]; 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_01C150D1.DD882A80--

From mhammer@cisco.com  Tue Oct  9 11:46:21 2001
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 LAA06618
	for ; Tue, 9 Oct 2001 11:46:20 -0400 (EDT)
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 LAA14615; Tue, 9 Oct 2001 11:46:09 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (rtp-vpn2-208.cisco.com [10.82.240.208])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ARW08892;
	Tue, 9 Oct 2001 11:46:13 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011009114345.00b3cc00@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 09 Oct 2001 11:50:29 -0400
To: "Roy, Radhika R, ALCTA" 
From: Michael Hammer 
Subject: RE: [Simple] IM over the signaling connection
Cc: Brazier Lachlan ,
        simple@mailman.dynamicsoft.com
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Length: 4517
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: 


All,



I still think there is the issue of volume, be it in one message or
many.  I don't think you want the signal path flooded with media
messages.  With SMS it may have initially been limited to how fast
people could keypress in data, and even then it affected signaling. 
This could be further harmed by automatons transmitting large messages at
an even faster rate.  While the router network may carry both
together and have capacity, the delay within the signaling proxy may be
an issue.



If a proxy path is needed, is there any thought to having media proxies
separate from signaling proxies?  This could be discovered
separately or identified by certain (but not all) signaling=20
proxies.



Mike





At 09:12 AM 10/9/2001 -0400, Roy, Radhika R, ALCTA wrote:


Hi, All:



The idea would be to limit the "maximum" size of data in paging
mode.



The longer message will create multiple paging streams, and let the

application take care-of this (although it will be discouraged to make
the

message size longer).



Radhika



-----Original Message-----

From: Brazier Lachlan
[mailto:lachlan.brazier@siemens.at]

Sent: Tuesday, October 09, 2001 4:33 AM

To: 'Michael Hammer'; Christian Huitema

Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;=20
Peterson,

Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com

Subject: AW: [Simple] IM over the signaling connection





Hi,



there are websites where you can enter more than 256 octets (I think
it's

restricted to 160 octets)

These "long" messages result into several SMS's at the receiver
point.



Lachlan



> -----Urspr=FCngliche Nachricht-----

> Von: Michael Hammer
[mailto:mhammer@cisco.com]

> Gesendet am: Montag, 08. Oktober 2001 19:46

> An: Christian Huitema

> Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;
Peterson,

> Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com

> Betreff: RE: [Simple] IM over the signaling connection

> 

> Christian,

> 

> The only problem with this comparison is that the SMS 

> messages are limited 

> in size, I believe, to 256 octets, maybe less.  If volume is


> not restricted 

> this could be a problem.  This could be an interworking
issue.

> 

> Is CPIM limited in any way?

> 

> Mike

> 

> 

> At 10:06 AM 10/8/2001 -0700, Christian Huitema wrote:

> >There are two points that I keep in mind in this debate:

> >

> >1) SMS, the messaging service of cell phones, uses the page


> mode and is

> >carried at least in part over the signaling channel.

> >

> >2) CPIM's Message function looks a lot like the page mode.

> >

> >It seems that the first step forward is to recognize this and
assume

> >that we will indeed use "MESSAGE over SIP" in the page
mode for a

> >significant fraction of our exchanges. I suggest that the first
order

> >action of SIMPLE is to just nail this one, so it be behind
us.

> >

> >The page mode has well known limitations: it creates a lot=20


> of overhead

> >in long sessions, and it does not extend easily to
multi-party

> >operation. This is the rationale for the "IM session"


> extensions, i.e.

> >IM after INVITE. However, whatever we do in the session mode, we
will

> >have to go on interworking with SMS and with CPIM; this means
that we

> >will have to bring in the session some members who can only


> use the page

> >mode. Obviously, a "session of messages" makes this
very easy.

> >

> >-- Christian Huitema

> >_______________________________________________

> >

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple




From rrroy@att.com  Tue Oct  9 12:14:38 2001
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 MAA06746
	for ; Tue, 9 Oct 2001 12:14:37 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f99GEHC24967;
	Tue, 9 Oct 2001 12:14:18 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id MAA13738; Tue, 9 Oct 2001 12:12:54 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <4QWJPPJH>; Tue, 9 Oct 2001 12:14:13 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Michael Hammer 
Cc: Brazier Lachlan ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Tue, 9 Oct 2001 12:14:02 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4606
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA06746
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: 

 

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: Tuesday, October 09, 2001 11:50 AM
To: Roy, Radhika R, ALCTA
Cc: Brazier Lachlan; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection


All,

I still think there is the issue of volume, be it in one message or many.  I
don't think you want the signal path flooded with media messages.  With SMS
it may have initially been limited to how fast people could keypress in
data, and even then it affected signaling.  This could be further harmed by
automatons transmitting large messages at an even faster rate.  While the
router network may carry both together and have capacity, the delay within
the signaling proxy may be an issue.
[Roy, Radhika R, ALARC]  Yes, this danger is always there - how soon a given
mechanism can be mis-used once people will have the option to do so.  This
danger is real. (In fact, the "sending of media [data] over the signaling
path is breaking the "original" SIP model where media and signaling path
need to be separated.)

If a proxy path is needed, is there any thought to having media proxies
separate from signaling proxies?  This could be discovered separately or
identified by certain (but not all) signaling proxies.
[Roy, Radhika R, ALARC] Media proxies (severs) can be thought a kind of
media application servers. As I mentioned earlier in response to Alex's
email, it will open a new area in SIP/SDP. However, SIP is also solving the
problems of media servers indirectly (as I mentioned in an example of data
bridge where media is bridged). One way of doing is: Let the signaling
messages indicate how the media will be passed (as if, media servers are
becoming parties [directly or indirectly]). It is entirely a new area to
explore.

Mike


At 09:12 AM 10/9/2001 -0400, Roy, Radhika R, ALCTA wrote:


Hi, All:

The idea would be to limit the "maximum" size of data in paging mode.

The longer message will create multiple paging streams, and let the
application take care-of this (although it will be discouraged to make the
message size longer).

Radhika

-----Original Message-----
From: Brazier Lachlan [ mailto:lachlan.brazier@siemens.at
 ]
Sent: Tuesday, October 09, 2001 4:33 AM
To: 'Michael Hammer'; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: AW: [Simple] IM over the signaling connection


Hi,

there are websites where you can enter more than 256 octets (I think it's
restricted to 160 octets)
These "long" messages result into several SMS's at the receiver point.

Lachlan

> -----Ursprüngliche Nachricht-----
> Von: Michael Hammer [ mailto:mhammer@cisco.com 
]
> Gesendet am: Montag, 08. Oktober 2001 19:46
> An: Christian Huitema
> Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
> Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
> Betreff: RE: [Simple] IM over the signaling connection
> 
> Christian,
> 
> The only problem with this comparison is that the SMS 
> messages are limited 
> in size, I believe, to 256 octets, maybe less.  If volume is 
> not restricted 
> this could be a problem.  This could be an interworking issue.
> 
> Is CPIM limited in any way?
> 
> Mike
> 
> 
> At 10:06 AM 10/8/2001 -0700, Christian Huitema wrote:
> >There are two points that I keep in mind in this debate:
> >
> >1) SMS, the messaging service of cell phones, uses the page 
> mode and is
> >carried at least in part over the signaling channel.
> >
> >2) CPIM's Message function looks a lot like the page mode.
> >
> >It seems that the first step forward is to recognize this and assume
> >that we will indeed use "MESSAGE over SIP" in the page mode for a
> >significant fraction of our exchanges. I suggest that the first order
> >action of SIMPLE is to just nail this one, so it be behind us.
> >
> >The page mode has well known limitations: it creates a lot 
> of overhead
> >in long sessions, and it does not extend easily to multi-party
> >operation. This is the rationale for the "IM session" 
> extensions, i.e.
> >IM after INVITE. However, whatever we do in the session mode, we will
> >have to go on interworking with SMS and with CPIM; this means that we
> >will have to bring in the session some members who can only 
> use the page
> >mode. Obviously, a "session of messages" makes this very easy.
> >
> >-- Christian Huitema
> >_______________________________________________
> >
_______________________________________________



From rrroy@att.com  Tue Oct  9 13:21:42 2001
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 NAA07024
	for ; Tue, 9 Oct 2001 13:21:41 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f99HLQk27218;
	Tue, 9 Oct 2001 13:21:27 -0400 (EDT)
Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id NAA04172; Tue, 9 Oct 2001 13:20:06 -0400 (EDT)
Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <4QWJPYGC>; Tue, 9 Oct 2001 13:21:25 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Christian Huitema ,
        Vasilis Polychronidis 
Cc: Ben Campbell ,
        Jonathan Rosenberg
	 ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Tue, 9 Oct 2001 13:21:17 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4795
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: 

 

-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.microsoft.com]
Sent: Tuesday, October 09, 2001 1:09 PM
To: Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection


Note that my point was not to ignore the lessons of the past, but to point
out that widely deployed systems such as SMS are not going to disappear in a
day, or in a year -- they are with us for at least one or two upgrade
cycles, i.e. at least 4 to 6 years.
  
[Roy, Radhika R, ALARC]  Agreed. 
 
Also note that if the usage is actually a page, then a "message" is less
taxing on the infrastructure than an "invite" + the necessary session
clean-up. Let's compare:
 
1) Message: one signalling message + one response per IM.
 
2) Session: INVITE + response; ACK; BYE+response; + additional cost of
setting the message channel; IM messages on channel.
 
From a pure signalling point of view, the session mode is only beneficial
when there are at least 3 IM exchanged in a session.

[Roy, Radhika R, ALARC]  Yes, there is also a clear efficiency, but it has a
real danger as well: 1. People might mis-use it overloading the signaling
path through sending the larger messages or increasing the frequency of
shorter messages (had been explained earlier) and 2. It also breaks the
original SIP model - separation between signaling and media path. Proposals
need to be there to address these two concerns.
 
-- Christian Huitema
 
-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] 
Sent: Tuesday, October 09, 2001 6:23 AM
To: Vasilis Polychronidis; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection



Hi, Vasilis:
 
Good that you have reminded the very important lesson from the past.
 
Would please let us know your opinion what do we do in the case of "Paging"
in SIP?
 
Of course, we have another scheme: MESSAGE as session.
 
Radhika

-----Original Message-----
From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com]
Sent: Monday, October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection


Christian Huitema wrote: 

There are two points that I keep in mind in this debate: 

1) SMS, the messaging service of cell phones, uses the page mode and is 
carried at least in part over the signaling channel.

Correct. However Operators realized that SMS was the wrong (was very
successful financially) technical solution for messaging. 
Remind you that when the people designed (late 80s) SMS they did not have
any idea of how successful commercial service will be. 
That is why the next generation of multimedia messaging is using HTTP as the
transport. 
I understand that this is a difficult point to understand with some people
in the list. 
Let me remind you that the telephony people with more than hundred years of
experience realized in the late seventies that 
in order to scale and have very reliable networks you had to separate
signaling from transport (initially signaling was mixed with transport - 
that is the current case for all the analog lines going from home to the
local switch --> DTMF) and they created SS7 and ISUP. 
Actually people invented SIP using ISUP as their guide. 
That was one of the initial arguments of SIP: separate proxies from
transport of user data. 
It seems to me that certain people want to regress in time and mix signaling
and user data. 
Let us please learn from the history and lets try not to repeat the same
mistakes. 

  

2) CPIM's Message function looks a lot like the page mode. 


It seems that the first step forward is to recognize this and assume 
that we will indeed use "MESSAGE over SIP" in the page mode for a 
significant fraction of our exchanges. I suggest that the first order 
action of SIMPLE is to just nail this one, so it be behind us. 


The page mode has well known limitations: it creates a lot of overhead 
in long sessions, and it does not extend easily to multi-party 
operation. This is the rationale for the "IM session" extensions, i.e. 
IM after INVITE. However, whatever we do in the session mode, we will 
have to go on interworking with SMS and with CPIM; this means that we 
will have to bring in the session some members who can only use the page 
mode. Obviously, a "session of messages" makes this very easy. 


-- Christian Huitema 
_______________________________________________ 



From bstucker@nortelnetworks.com  Tue Oct  9 15:28:26 2001
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 PAA07549
	for ; Tue, 9 Oct 2001 15:28:23 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA10734
	for ; Tue, 9 Oct 2001 14:27:58 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Tue, 9 Oct 2001 14:27:02 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 9 Oct 2001 14:27:24 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E4E009B@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
Date: Tue, 9 Oct 2001 14:27:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C150F8.69019F30"
Content-Length: 32606
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: 

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_01C150F8.69019F30
Content-Type: text/plain;
	charset="iso-8859-1"

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
 ] 
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
 ] 
> 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
 ] 
> 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
 ] 
> 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
 ]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
 ] 
> 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
 ] 
> > 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
  
> 

------_=_NextPart_001_01C150F8.69019F30
Content-Type: text/html;
	charset="iso-8859-1"






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_01C150F8.69019F30--

From HUITEMA@windows.microsoft.com  Tue Oct  9 13:12:55 2001
Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA06966
	for ; Tue, 9 Oct 2001 13:12:54 -0400 (EDT)
Received: from 157.54.7.70 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Oct 2001 10:09:09 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 9 Oct 2001 10:09:08 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 9 Oct 2001 10:09:07 -0700
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(5.0.2195.2966);
	 Tue, 9 Oct 2001 10:08:45 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: [Simple] IM over the signaling connection
Date: Tue, 9 Oct 2001 10:08:45 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] IM over the signaling connection
Thread-Index: AcFQxgoP2jZ9JC8YQqaisc+RThfSUgAHcuqw
From: "Christian Huitema" 
To: "Roy, Radhika R, ALCTA" ,
        "Vasilis Polychronidis" 
Cc: "Ben Campbell" ,
        "Jonathan Rosenberg" ,
        "Henning Schulzrinne" ,
        "Peterson, Jon" , ,
        
X-OriginalArrivalTime: 09 Oct 2001 17:08:45.0961 (UTC) FILETIME=[0E3BAF90:01C150E5]
Content-Length: 12668
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: 

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C150E5.0E070118"

------_=_NextPart_001_01C150E5.0E070118
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Note that my point was not to ignore the lessons of the past, but to
point out that widely deployed systems such as SMS are not going to
disappear in a day, or in a year -- they are with us for at least one or
two upgrade cycles, i.e. at least 4 to 6 years.
=20
Also note that if the usage is actually a page, then a "message" is less
taxing on the infrastructure than an "invite" + the necessary session
clean-up. Let's compare:
=20
1) Message: one signalling message + one response per IM.
=20
2) Session: INVITE + response; ACK; BYE+response; + additional cost of
setting the message channel; IM messages on channel.
=20
From a pure signalling point of view, the session mode is only
beneficial when there are at least 3 IM exchanged in a session.
=20
-- Christian Huitema
=20
-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com]=20
Sent: Tuesday, October 09, 2001 6:23 AM
To: Vasilis Polychronidis; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection



	Hi, Vasilis:
	=20
	Good that you have reminded the very important lesson from the
past.
	=20
	Would please let us know your opinion what do we do in the case
of "Paging" in SIP?
	=20
	Of course, we have another scheme: MESSAGE as session.
	=20
	Radhika

		-----Original Message-----
		From: Vasilis Polychronidis
[mailto:Vasilis.Polychronidis@openwave.com]
		Sent: Monday, October 08, 2001 4:43 PM
		To: Christian Huitema
		Cc: Ben Campbell; Jonathan Rosenberg; Henning
Schulzrinne; Peterson, Jon; Avshalom@ubique.com;
simple@mailman.dynamicsoft.com
		Subject: Re: [Simple] IM over the signaling connection
	=09
	=09
		Christian Huitema wrote:=20

			There are two points that I keep in mind in this
debate:=20

			1) SMS, the messaging service of cell phones,
uses the page mode and is=20
			carried at least in part over the signaling
channel.

		Correct. However Operators realized that SMS was the
wrong (was very successful financially) technical solution for
messaging.=20
		Remind you that when the people designed (late 80s) SMS
they did not have any idea of how successful commercial service will be.

		That is why the next generation of multimedia messaging
is using HTTP as the transport.=20
		I understand that this is a difficult point to
understand with some people in the list.=20
		Let me remind you that the telephony people with more
than hundred years of experience realized in the late seventies that=20
		in order to scale and have very reliable networks you
had to separate signaling from transport (initially signaling was mixed
with transport -=20
		that is the current case for all the analog lines going
from home to the local switch --> DTMF) and they created SS7 and ISUP.=20
		Actually people invented SIP using ISUP as their guide.=20
		That was one of the initial arguments of SIP: separate
proxies from transport of user data.=20
		It seems to me that certain people want to regress in
time and mix signaling and user data.=20
		Let us please learn from the history and lets try not to
repeat the same mistakes.=20

			 =20

			2) CPIM's Message function looks a lot like the
page mode.=20

			It seems that the first step forward is to
recognize this and assume=20
			that we will indeed use "MESSAGE over SIP" in
the page mode for a=20
			significant fraction of our exchanges. I suggest
that the first order=20
			action of SIMPLE is to just nail this one, so it
be behind us.=20

			The page mode has well known limitations: it
creates a lot of overhead=20
			in long sessions, and it does not extend easily
to multi-party=20
			operation. This is the rationale for the "IM
session" extensions, i.e.=20
			IM after INVITE. However, whatever we do in the
session mode, we will=20
			have to go on interworking with SMS and with
CPIM; this means that we=20
			will have to bring in the session some members
who can only use the page=20
			mode. Obviously, a "session of messages" makes
this very easy.=20

			-- Christian Huitema=20
			_______________________________________________=20
		=09


------_=_NextPart_001_01C150E5.0E070118
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable


Message




Note=20
that my point was not to ignore the lessons of the past, but to point =
out that=20
widely deployed systems such as SMS are not going to disappear in a day, =
or in a=20
year -- they are with us for at least one or two upgrade cycles, i.e. at =
least 4=20
to 6 years.


 


Also=20
note that if the usage is actually a page, then a "message" is less =
taxing on=20
the infrastructure than an "invite" + the necessary session clean-up. =
Let's=20
compare:


 


1)=20
Message: one signalling message + one response per =
IM.


 


2)=20
Session: INVITE + response; ACK; BYE+response; + additional cost of =
setting the=20
message channel; IM messages on channel.


 


From a=20
pure signalling point of view, the session mode is only beneficial when =
there=20
are at least 3 IM exchanged in a session.


 


--=20
Christian Huitema


 




-----Original =
Message-----
From: Roy,=20
Radhika R, ALCTA [mailto:rrroy@att.com] 
Sent: Tuesday, =
October 09,=20
2001 6:23 AM
To: Vasilis Polychronidis; Christian=20
Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning =
Schulzrinne;=20
Peterson, Jon; Avshalom@ubique.com;=20
simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over =
the=20
signaling connection




  
Hi,=20
  Vasilis:

  
 

  
Good=20
  that you have reminded the very important lesson from the=20
  past.

  
 

  
Would please let us know your opinion what =
do we do=20
  in the case of "Paging" in SIP?

  
 

  
Of=20
  course, we have another scheme: MESSAGE as =
session.

  
 

  
Radhika

  

    
-----Original Message-----
From: Vasilis =
Polychronidis=20
    [mailto:Vasilis.Polychronidis@openwave.com]
Sent: Monday, =
October=20
    08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben =
Campbell;=20
    Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon; =
Avshalom@ubique.com;=20
    simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM =
over the=20
    signaling connection

Christian Huitema wrote:=20
    
There are two points that I keep in mind =
in this=20
      debate:=20
      
1) SMS, the messaging service of cell phones, uses the page =
mode and is=20
      
carried at least in part over the signaling=20
    channel.
Correct. However =
Operators=20
    realized that SMS was the wrong (was very successful financially) =
technical=20
    solution for messaging. 
Remind you =
that when=20
    the people designed (late 80s) SMS they did not have any idea of how =

    successful commercial service will be. 
That=20
    is why the next generation of multimedia messaging is using HTTP as =
the=20
    transport. 
I understand that this =
is a=20
    difficult point to understand with some people in the list. =

Let me remind you that the telephony people with =
more than=20
    hundred years of experience realized in the late seventies =
that=20
    
in order to scale and have very reliable =
networks=20
    you had to separate signaling from transport (initially signaling =
was mixed=20
    with transport - 
that is the =
current case for=20
    all the analog lines going from home to the local switch --> =
DTMF) and=20
    they created SS7 and ISUP. 
Actually =
people=20
    invented SIP using ISUP as their guide. 
That=20
    was one of the initial arguments of SIP: separate proxies from =
transport of=20
    user data. 
It seems to me that =
certain people=20
    want to regress in time and mix signaling and user data. =

Let us please learn from the history and lets try =
not to=20
    repeat the same mistakes.=20
    
 =20
      
2) CPIM's Message function looks a lot like the page mode.=20
      
It seems that the first step forward is to recognize this and =
assume=20
      
that we will indeed use "MESSAGE over SIP" in the page mode =
for a=20
      
significant fraction of our exchanges. I suggest that the =
first order=20
      
action of SIMPLE is to just nail this one, so it be behind us. =

      
The page mode has well known limitations: it creates a lot of =
overhead=20
      
in long sessions, and it does not extend easily to multi-party =

      
operation. This is the rationale for the "IM session" =
extensions, i.e.=20
      
IM after INVITE. However, whatever we do in the session mode, =
we will=20
      
have to go on interworking with SMS and with CPIM; this means =
that we=20
      
will have to bring in the session some members who can only =
use the=20
      page 
mode. Obviously, a "session of messages" makes this very =
easy.=20
      
-- Christian Huitema=20
      
_______________________________________________=20
  

=00
------_=_NextPart_001_01C150E5.0E070118--

--------------InterScan_NT_MIME_Boundary--


From bcampbell@dynamicsoft.com  Tue Oct  9 15:40:36 2001
Received: from localhost.localdomain ([63.110.3.232])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07632
	for ; Tue, 9 Oct 2001 15:40:35 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f99JdkN09189;
	Tue, 9 Oct 2001 14:39:51 -0500
Message-ID: <3BC35281.2040203@dynamicsoft.com>
Date: Tue, 09 Oct 2001 14:39:45 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Christian Huitema 
CC: "Roy, Radhika R, ALCTA" ,
        Vasilis Polychronidis ,
        Jonathan Rosenberg ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 5045
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: 

I agree with Christian here--I really want to discourage session mode 
unless one expects a stream of messages. One shot text messages should 
normally be page mode.

Christian Huitema wrote:

> Note that my point was not to ignore the lessons of the past, but to 
> point out that widely deployed systems such as SMS are not going to 
> disappear in a day, or in a year -- they are with us for at least one or 
> two upgrade cycles, i.e. at least 4 to 6 years.
> 
>  
> 
> Also note that if the usage is actually a page, then a "message" is less 
> taxing on the infrastructure than an "invite" + the necessary session 
> clean-up. Let's compare:
> 
>  
> 
> 1) Message: one signalling message + one response per IM.
> 
>  
> 
> 2) Session: INVITE + response; ACK; BYE+response; + additional cost of 
> setting the message channel; IM messages on channel.
> 
>  
> 
>  From a pure signalling point of view, the session mode is only 
> beneficial when there are at least 3 IM exchanged in a session.
> 
>  
> 
> -- Christian Huitema
> 
>  
> 
> -----Original Message-----
> *From:* Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
> *Sent:* Tuesday, October 09, 2001 6:23 AM
> *To:* Vasilis Polychronidis; Christian Huitema
> *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, 
> Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
> *Subject:* RE: [Simple] IM over the signaling connection
> 
>     Hi, Vasilis:
> 
>      
> 
>     Good that you have reminded the very important lesson from the past.
> 
>      
> 
>     Would please let us know your opinion what do we do in the case of
>     "Paging" in SIP?
> 
>      
> 
>     Of course, we have another scheme: MESSAGE as session.
> 
>      
> 
>     Radhika
> 
>         -----Original Message-----
>         *From:* Vasilis Polychronidis
>         [mailto:Vasilis.Polychronidis@openwave.com]
>         *Sent:* Monday, October 08, 2001 4:43 PM
>         *To:* Christian Huitema
>         *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;
>         Peterson, Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
>         *Subject:* Re: [Simple] IM over the signaling connection
> 
>         Christian Huitema wrote:
> 
>             There are two points that I keep in mind in this debate:
> 
>             1) SMS, the messaging service of cell phones, uses the page
>             mode and is
>             carried at least in part over the signaling channel.
> 
>         Correct. However Operators realized that SMS was the wrong (was
>         very successful financially) technical solution for messaging.
>         Remind you that when the people designed (late 80s) SMS they did
>         not have any idea of how successful commercial service will be.
>         That is why the next generation of multimedia messaging is using
>         HTTP as the transport.
>         I understand that this is a difficult point to understand with
>         some people in the list.
>         Let me remind you that the telephony people with more than
>         hundred years of experience realized in the late seventies that
>         in order to scale and have very reliable networks you had to
>         separate signaling from transport (initially signaling was mixed
>         with transport -
>         that is the current case for all the analog lines going from
>         home to the local switch --> DTMF) and they created SS7 and ISUP.
>         Actually people invented SIP using ISUP as their guide.
>         That was one of the initial arguments of SIP: separate proxies
>         from transport of user data.
>         It seems to me that certain people want to regress in time and
>         mix signaling and user data.
>         Let us please learn from the history and lets try not to repeat
>         the same mistakes.
> 
>              
> 
>             2) CPIM's Message function looks a lot like the page mode.
> 
>             It seems that the first step forward is to recognize this
>             and assume
>             that we will indeed use "MESSAGE over SIP" in the page mode
>             for a
>             significant fraction of our exchanges. I suggest that the
>             first order
>             action of SIMPLE is to just nail this one, so it be behind us.
> 
>             The page mode has well known limitations: it creates a lot
>             of overhead
>             in long sessions, and it does not extend easily to multi-party
>             operation. This is the rationale for the "IM session"
>             extensions, i.e.
>             IM after INVITE. However, whatever we do in the session
>             mode, we will
>             have to go on interworking with SMS and with CPIM; this
>             means that we
>             will have to bring in the session some members who can only
>             use the page
>             mode. Obviously, a "session of messages" makes this very easy.
> 
>             -- Christian Huitema
>             _______________________________________________
> 




From rrroy@att.com  Tue Oct  9 15:55:59 2001
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 PAA07738
	for ; Tue, 9 Oct 2001 15:55:58 -0400 (EDT)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f99JtI306409;
	Tue, 9 Oct 2001 15:55:19 -0400 (EDT)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id PAA24367; Tue, 9 Oct 2001 15:53:57 -0400 (EDT)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <4QWPMYLW>; Tue, 9 Oct 2001 15:55:17 -0400
Message-ID: 
From: "Roy, Radhika R, ALCTA" 
To: Ben Campbell ,
        Christian Huitema
	 
Cc: Vasilis Polychronidis ,
        Jonathan Rosenberg ,
        Henning Schulzrinne
	 ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Tue, 9 Oct 2001 15:55:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5794
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: 


-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
Sent: Tuesday, October 09, 2001 3:40 PM

I agree with Christian here--I really want to discourage session mode 
unless one expects a stream of messages. One shot text messages should 
normally be page mode.

[RRR] No one is disagreeing with the benefits for transferring the paging
mode text messages via signaling path, I guess. The two concerns
(implications of mis-usage and breaking of original SIP model) mentioned
earlier also need to be addressed appropriately.

[RRR] Implications of mis-use: Can we avoid the mis-use of this by putting
appropriate restrictions for not overloading the signaling path?

[RRR] Breaking of original SIP Model: Can we make appropriate suggestions
that this is a special case in SIP for sending the paging text data only?

[RRR] Will these suggestions be acceptable to all to clarify all issues?

Christian Huitema wrote:

> Note that my point was not to ignore the lessons of the past, but to 
> point out that widely deployed systems such as SMS are not going to 
> disappear in a day, or in a year -- they are with us for at least one or 
> two upgrade cycles, i.e. at least 4 to 6 years.
> 
>  
> 
> Also note that if the usage is actually a page, then a "message" is less 
> taxing on the infrastructure than an "invite" + the necessary session 
> clean-up. Let's compare:
> 
>  
> 
> 1) Message: one signalling message + one response per IM.
> 
>  
> 
> 2) Session: INVITE + response; ACK; BYE+response; + additional cost of 
> setting the message channel; IM messages on channel.
> 
>  
> 
>  From a pure signalling point of view, the session mode is only 
> beneficial when there are at least 3 IM exchanged in a session.
> 
>  
> 
> -- Christian Huitema
> 
>  
> 
> -----Original Message-----
> *From:* Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
> *Sent:* Tuesday, October 09, 2001 6:23 AM
> *To:* Vasilis Polychronidis; Christian Huitema
> *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, 
> Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
> *Subject:* RE: [Simple] IM over the signaling connection
> 
>     Hi, Vasilis:
> 
>      
> 
>     Good that you have reminded the very important lesson from the past.
> 
>      
> 
>     Would please let us know your opinion what do we do in the case of
>     "Paging" in SIP?
> 
>      
> 
>     Of course, we have another scheme: MESSAGE as session.
> 
>      
> 
>     Radhika
> 
>         -----Original Message-----
>         *From:* Vasilis Polychronidis
>         [mailto:Vasilis.Polychronidis@openwave.com]
>         *Sent:* Monday, October 08, 2001 4:43 PM
>         *To:* Christian Huitema
>         *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;
>         Peterson, Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
>         *Subject:* Re: [Simple] IM over the signaling connection
> 
>         Christian Huitema wrote:
> 
>             There are two points that I keep in mind in this debate:
> 
>             1) SMS, the messaging service of cell phones, uses the page
>             mode and is
>             carried at least in part over the signaling channel.
> 
>         Correct. However Operators realized that SMS was the wrong (was
>         very successful financially) technical solution for messaging.
>         Remind you that when the people designed (late 80s) SMS they did
>         not have any idea of how successful commercial service will be.
>         That is why the next generation of multimedia messaging is using
>         HTTP as the transport.
>         I understand that this is a difficult point to understand with
>         some people in the list.
>         Let me remind you that the telephony people with more than
>         hundred years of experience realized in the late seventies that
>         in order to scale and have very reliable networks you had to
>         separate signaling from transport (initially signaling was mixed
>         with transport -
>         that is the current case for all the analog lines going from
>         home to the local switch --> DTMF) and they created SS7 and ISUP.
>         Actually people invented SIP using ISUP as their guide.
>         That was one of the initial arguments of SIP: separate proxies
>         from transport of user data.
>         It seems to me that certain people want to regress in time and
>         mix signaling and user data.
>         Let us please learn from the history and lets try not to repeat
>         the same mistakes.
> 
>              
> 
>             2) CPIM's Message function looks a lot like the page mode.
> 
>             It seems that the first step forward is to recognize this
>             and assume
>             that we will indeed use "MESSAGE over SIP" in the page mode
>             for a
>             significant fraction of our exchanges. I suggest that the
>             first order
>             action of SIMPLE is to just nail this one, so it be behind us.
> 
>             The page mode has well known limitations: it creates a lot
>             of overhead
>             in long sessions, and it does not extend easily to multi-party
>             operation. This is the rationale for the "IM session"
>             extensions, i.e.
>             IM after INVITE. However, whatever we do in the session
>             mode, we will
>             have to go on interworking with SMS and with CPIM; this
>             means that we
>             will have to bring in the session some members who can only
>             use the page
>             mode. Obviously, a "session of messages" makes this very easy.
> 
>             -- Christian Huitema
>             _______________________________________________
> 



From Vasilis.Polychronidis@Openwave.com  Tue Oct  9 16:49:07 2001
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 QAA08000
	for ; Tue, 9 Oct 2001 16:49:06 -0400 (EDT)
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27])
          by oe-mp2.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011009204800.IJEL28504.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>
          for ;
          Tue, 9 Oct 2001 15:48:00 -0500
Received: from Openwave.com ([4.41.19.164]) by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011009204716.XWJI13982.oe-ismta2.bizmailsrvcs.net@Openwave.com>
          for ;
          Tue, 9 Oct 2001 15:47:16 -0500
Message-ID: <3BC362B4.B5404029@Openwave.com>
Date: Tue, 09 Oct 2001 13:48:53 -0700
From: Vasilis Polychronidis 
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: multipart/mixed;
 boundary="------------8438B673F9B74DF1546BB284"
Content-Length: 2961
Subject: [Simple] [Fwd: Your message to simple awaits moderator approval]
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: 

This is a multi-part message in MIME format.
--------------8438B673F9B74DF1546BB284
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I do not understand I just hit "Reply All"
Too many restriction and filters in this list :-)

-Vasilis

--------------8438B673F9B74DF1546BB284
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: 
Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26])
          by oe-mp1.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011009203139.WUON13960.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>
          for ;
          Tue, 9 Oct 2001 15:31:39 -0500
Received: from mail1.dynamicsoft.com ([63.113.40.10])
          by oe-ismta1.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011009203349.EEWT1932.oe-ismta1.bizmailsrvcs.net@mail1.dynamicsoft.com>
          for ;
          Tue, 9 Oct 2001 15:33:49 -0500
Received: from mailman.dynamicsoft.com ([192.168.4.50])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f99KWi8P001598
	for ; Tue, 9 Oct 2001 16:32:44 -0400 (EDT)
Received: from mailman.dynamicsoft.com (localhost [127.0.0.1])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07949
	for ; Tue, 9 Oct 2001 16:34:02 -0400 (EDT)
Date: Tue, 9 Oct 2001 16:34:02 -0400 (EDT)
Message-Id: <200110092034.QAA07949@mailman.dynamicsoft.com>
Subject: Your message to simple awaits moderator approval
From: simple-admin@mailman.dynamicsoft.com
To: vasilis.polychronidis@openwave.com
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
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 
X-Mozilla-Status2: 00000000

Your mail to 'simple' with the subject

    Re: [Simple] IM over the signaling connection

Is being held until the list moderator can review it for approval.

The reason it is being held:

    Too many recipients to the message

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.


--------------8438B673F9B74DF1546BB284--




From Brian.Rosen@marconi.com  Tue Oct  9 16:21:11 2001
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 QAA07848
	for ; Tue, 9 Oct 2001 16:21:10 -0400 (EDT)
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 QAA06018;
	Tue, 9 Oct 2001 16:20:50 -0400 (EDT)
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 QAA18089;
	Tue, 9 Oct 2001 16:20:50 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 9 Oct 2001 16:20:49 -0400
Message-ID: <313680C9A886D511A06000204840E1CF57C345@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Christian Huitema'" ,
        "Roy, Radhika R, ALCTA" ,
        Vasilis Polychronidis
	 
Cc: Ben Campbell ,
        Jonathan Rosenberg
	 ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Tue, 9 Oct 2001 16:20:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C150FF.D67D4120"
Content-Length: 15978
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: 

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_01C150FF.D67D4120
Content-Type: text/plain;
	charset="ISO-8859-1"

I think that the "usual" IM usage is many more than 3 messages per session.
I think the problem is distinguishing the cases based on user input; you
don't
want the user to decide, you want the system to decide.
 
I think that, without needing standardization, some simple heuristic like
two or
three messages in a minute means start a session.
 
Please remember that the problem with congestion control is NOT an
individual
user.   The problem is a system supporting millions of users.   What is 3 or
4 IMs in a minute is 6-12 protocol messages times millions per minute.
You need flow control for that.  Millions of page messages will be
problematic
for a single system.  Millions of end-to-end messages between pairs of
endpoints
with flow control won't.
 
Brian

-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.microsoft.com]
Sent: Tuesday, October 09, 2001 1:09 PM
To: Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection


Note that my point was not to ignore the lessons of the past, but to point
out that widely deployed systems such as SMS are not going to disappear in a
day, or in a year -- they are with us for at least one or two upgrade
cycles, i.e. at least 4 to 6 years.
 
Also note that if the usage is actually a page, then a "message" is less
taxing on the infrastructure than an "invite" + the necessary session
clean-up. Let's compare:
 
1) Message: one signalling message + one response per IM.
 
2) Session: INVITE + response; ACK; BYE+response; + additional cost of
setting the message channel; IM messages on channel.
 
From a pure signalling point of view, the session mode is only beneficial
when there are at least 3 IM exchanged in a session.
 
-- Christian Huitema
 
-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] 
Sent: Tuesday, October 09, 2001 6:23 AM
To: Vasilis Polychronidis; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection



Hi, Vasilis:
 
Good that you have reminded the very important lesson from the past.
 
Would please let us know your opinion what do we do in the case of "Paging"
in SIP?
 
Of course, we have another scheme: MESSAGE as session.
 
Radhika

-----Original Message-----
From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com]
Sent: Monday, October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection


Christian Huitema wrote: 

There are two points that I keep in mind in this debate: 

1) SMS, the messaging service of cell phones, uses the page mode and is 
carried at least in part over the signaling channel.

Correct. However Operators realized that SMS was the wrong (was very
successful financially) technical solution for messaging. 
Remind you that when the people designed (late 80s) SMS they did not have
any idea of how successful commercial service will be. 
That is why the next generation of multimedia messaging is using HTTP as the
transport. 
I understand that this is a difficult point to understand with some people
in the list. 
Let me remind you that the telephony people with more than hundred years of
experience realized in the late seventies that 
in order to scale and have very reliable networks you had to separate
signaling from transport (initially signaling was mixed with transport - 
that is the current case for all the analog lines going from home to the
local switch --> DTMF) and they created SS7 and ISUP. 
Actually people invented SIP using ISUP as their guide. 
That was one of the initial arguments of SIP: separate proxies from
transport of user data. 
It seems to me that certain people want to regress in time and mix signaling
and user data. 
Let us please learn from the history and lets try not to repeat the same
mistakes. 

  

2) CPIM's Message function looks a lot like the page mode. 


It seems that the first step forward is to recognize this and assume 
that we will indeed use "MESSAGE over SIP" in the page mode for a 
significant fraction of our exchanges. I suggest that the first order 
action of SIMPLE is to just nail this one, so it be behind us. 


The page mode has well known limitations: it creates a lot of overhead 
in long sessions, and it does not extend easily to multi-party 
operation. This is the rationale for the "IM session" extensions, i.e. 
IM after INVITE. However, whatever we do in the session mode, we will 
have to go on interworking with SMS and with CPIM; this means that we 
will have to bring in the session some members who can only use the page 
mode. Obviously, a "session of messages" makes this very easy. 


-- Christian Huitema 
_______________________________________________ 



------_=_NextPart_001_01C150FF.D67D4120
Content-Type: text/html;
	charset="ISO-8859-1"




Message




I think that 
the "usual" IM usage is many more than 3 messages per 
session.


I think the 
problem is distinguishing the cases based on user input; you 
don't


want the user 
to decide, you want the system to decide.


 


I think that, 
without needing standardization, some simple heuristic like two 
or


three 
messages in a minute means start a session.


 


Please 
remember that the problem with congestion control is NOT an 
individual


user.   The problem is a system supporting millions of 
users.   What is 3 or


4 IMs in a 
minute is 6-12 protocol messages times millions per minute.


You need flow 
control for that.  Millions of page messages will be 
problematic


for a single 
system.  Millions of end-to-end messages between pairs of 
endpoints


with flow 
control won't.


 


Brian



  
-----Original Message-----
From: Christian Huitema 
  [mailto:huitema@windows.microsoft.com]
Sent: Tuesday, October 09, 
  2001 1:09 PM
To: Roy, Radhika R, ALCTA; Vasilis 
  Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning 
  Schulzrinne; Peterson, Jon; Avshalom@ubique.com; 
  simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the 
  signaling connection


  
Note 
  that my point was not to ignore the lessons of the past, but to point out that 
  widely deployed systems such as SMS are not going to disappear in a day, or in 
  a year -- they are with us for at least one or two upgrade cycles, i.e. at 
  least 4 to 6 years.

  
 

  
Also 
  note that if the usage is actually a page, then a "message" is less taxing on 
  the infrastructure than an "invite" + the necessary session clean-up. Let's 
  compare:

  
 

  
1) 
  Message: one signalling message + one response per IM.

  
 

  
2) 
  Session: INVITE + response; ACK; BYE+response; + additional cost of setting 
  the message channel; IM messages on channel.

  
 

  
From 
  a pure signalling point of view, the session mode is only beneficial when 
  there are at least 3 IM exchanged in a session.

  
 

  
-- 
  Christian Huitema

  
 

  

  
-----Original Message-----
From: Roy, 
  Radhika R, ALCTA [mailto:rrroy@att.com] 
Sent: Tuesday, October 09, 
  2001 6:23 AM
To: Vasilis Polychronidis; Christian 
  Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; 
  Peterson, Jon; Avshalom@ubique.com; 
  simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the 
  signaling connection


  

    
Hi, Vasilis:

    
 

    
Good that you have reminded the very important 
    lesson from the past.

    
 

    
Would please let us know your opinion what do we do 
    in the case of "Paging" in SIP?

    
 

    
Of 
    course, we have another scheme: MESSAGE as session.

    
 

    
Radhika

    

      
-----Original Message-----
From: Vasilis Polychronidis 
      [mailto:Vasilis.Polychronidis@openwave.com]
Sent: Monday, 
      October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben 
      Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon; 
      Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: Re: 
      [Simple] IM over the signaling connection

Christian 
      Huitema wrote: 
      
There are two points that I keep in mind in this 
        debate: 
        
1) SMS, the messaging service of cell phones, uses the page mode and 
        is 
carried at least in part over the signaling 
      channel.
Correct. However Operators 
      realized that SMS was the wrong (was very successful financially) 
      technical solution for messaging. 
Remind 
      you that when the people designed (late 80s) SMS they did not have any 
      idea of how successful commercial service will be. 
That is why the next generation of multimedia messaging is 
      using HTTP as the transport. 
I understand 
      that this is a difficult point to understand with some people in the 
      list. 
Let me remind you that the telephony 
      people with more than hundred years of experience realized in the late 
      seventies that 
in order to scale and have 
      very reliable networks you had to separate signaling from transport 
      (initially signaling was mixed with transport - 
that is the current case for all the analog lines going from 
      home to the local switch --> DTMF) and they created SS7 and 
      ISUP. 
Actually people invented SIP using 
      ISUP as their guide. 
That was one of the 
      initial arguments of SIP: separate proxies from transport of user 
      data. 
It seems to me that certain people 
      want to regress in time and mix signaling and user data. 
Let us please learn from the history and lets try not to 
      repeat the same mistakes. 
      
  
        
2) CPIM's Message function looks a lot like the page mode. 
        
It seems that the first step forward is to recognize this and assume 
        
that we will indeed use "MESSAGE over SIP" in the page mode for a 
        
significant fraction of our exchanges. I suggest that the first 
        order 
action of SIMPLE is to just nail this one, so it be behind us. 

        
The page mode has well known limitations: it creates a lot of 
        overhead 
in long sessions, and it does not extend easily to 
        multi-party 
operation. This is the rationale for the "IM session" 
        extensions, i.e. 
IM after INVITE. However, whatever we do in the 
        session mode, we will 
have to go on interworking with SMS and with 
        CPIM; this means that we 
will have to bring in the session some 
        members who can only use the page 
mode. Obviously, a "session of 
        messages" makes this very easy. 
        
-- Christian Huitema 
        
_______________________________________________ 
    


------_=_NextPart_001_01C150FF.D67D4120--

From Vasilis.Polychronidis@Openwave.com  Tue Oct  9 16:24:29 2001
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 QAA07875
	for ; Tue, 9 Oct 2001 16:24:29 -0400 (EDT)
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27])
          by oe-mp2.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011009202315.HNTS28504.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Tue, 9 Oct 2001 15:23:15 -0500
Received: from Openwave.com ([4.41.19.164]) by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011009202230.XUXB13982.oe-ismta2.bizmailsrvcs.net@Openwave.com>;
          Tue, 9 Oct 2001 15:22:30 -0500
Message-ID: <3BC35CE1.91451C90@Openwave.com>
Date: Tue, 09 Oct 2001 13:24:01 -0700
From: Vasilis Polychronidis 
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Roy, Radhika R, ALCTA" 
CC: Christian Huitema ,
        Ben Campbell ,
        Jonathan Rosenberg ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: 
Content-Type: multipart/alternative;
 boundary="------------2490DA46D3D9DF8A6F1E4359"
Content-Length: 8610
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: 

--------------2490DA46D3D9DF8A6F1E4359
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Roy, Radhika R, ALCTA" wrote:

> Hi, Vasilis:Good that you have reminded the very important lesson from
> the past.Would please let us know your opinion what do we do in the
> case of "Paging" in SIP?

Personally I do not like it because:
1) It mixes signaling and media (breaks the SIP model)
2) It will be misused
However since the fathers of SIP are behind it (page mode) I will speak
no more on this issue.

> Of course, we have another scheme: MESSAGE as session.Radhika
>
>      -----Original Message-----
>      From: Vasilis Polychronidis
>      [mailto:Vasilis.Polychronidis@openwave.com]
>      Sent: Monday, October 08, 2001 4:43 PM
>      To: Christian Huitema
>      Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;
>      Peterson, Jon; Avshalom@ubique.com;
>      simple@mailman.dynamicsoft.com
>      Subject: Re: [Simple] IM over the signaling connection
>      Christian Huitema wrote:
>
>     > There are two points that I keep in mind in this debate:
>     >
>     > 1) SMS, the messaging service of cell phones, uses the
>     > page mode and is
>     > carried at least in part over the signaling channel.
>
>      Correct. However Operators realized that SMS was the wrong
>      (was very successful financially) technical solution for
>      messaging.
>      Remind you that when the people designed (late 80s) SMS they
>      did not have any idea of how successful commercial service
>      will be.
>      That is why the next generation of multimedia messaging is
>      using HTTP as the transport.
>      I understand that this is a difficult point to understand
>      with some people in the list.
>      Let me remind you that the telephony people with more than
>      hundred years of experience realized in the late seventies
>      that
>      in order to scale and have very reliable networks you had to
>      separate signaling from transport (initially signaling was
>      mixed with transport -
>      that is the current case for all the analog lines going from
>      home to the local switch --> DTMF) and they created SS7 and
>      ISUP.
>      Actually people invented SIP using ISUP as their guide.
>      That was one of the initial arguments of SIP: separate
>      proxies from transport of user data.
>      It seems to me that certain people want to regress in time
>      and mix signaling and user data.
>      Let us please learn from the history and lets try not to
>      repeat the same mistakes.
>
>     >
>     >
>     > 2) CPIM's Message function looks a lot like the page mode.
>     >
>     > It seems that the first step forward is to recognize this
>     > and assume
>     > that we will indeed use "MESSAGE over SIP" in the page
>     > mode for a
>     > significant fraction of our exchanges. I suggest that the
>     > first order
>     > action of SIMPLE is to just nail this one, so it be behind
>     > us.
>     >
>     > The page mode has well known limitations: it creates a lot
>     > of overhead
>     > in long sessions, and it does not extend easily to
>     > multi-party
>     > operation. This is the rationale for the "IM session"
>     > extensions, i.e.
>     > IM after INVITE. However, whatever we do in the session
>     > mode, we will
>     > have to go on interworking with SMS and with CPIM; this
>     > means that we
>     > will have to bring in the session some members who can
>     > only use the page
>     > mode. Obviously, a "session of messages" makes this very
>     > easy.
>     >
>     > -- Christian Huitema
>     > _______________________________________________
>

--------------2490DA46D3D9DF8A6F1E4359
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Roy, Radhika R, ALCTA" wrote:

Hi,
Vasilis:Good
that you have reminded the very important lesson from the past.Would
please let us know your opinion what do we do in the case of "Paging" in
SIP?

Personally I do not like it because:

1) It mixes signaling and media (breaks the SIP model)

2) It will be misused

However since the fathers of SIP are behind it (page mode) I will speak
no more on this issue.

Of
course, we have another scheme: MESSAGE as session.Radhika



-----Original
Message-----

From: Vasilis Polychronidis
[mailto:Vasilis.Polychronidis@openwave.com]

Sent: Monday, October
08, 2001 4:43 PM

To: Christian Huitema

Cc: Ben Campbell;
Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon; Avshalom@ubique.com;
simple@mailman.dynamicsoft.com

Subject: Re: [Simple]
IM over the signaling connection

Christian Huitema wrote:

There are two points that I keep in mind in this
debate:

1) SMS, the messaging service of cell phones, uses the page mode and
is

carried at least in part over the signaling channel.

Correct. However Operators realized that SMS was
the wrong (was very successful financially) technical solution for messaging.

Remind you that when the people designed (late
80s) SMS they did not have any idea of how successful commercial service
will be.

That is why the next generation of multimedia
messaging is using HTTP as the transport.

I understand that this is a difficult point to
understand with some people in the list.

Let me remind you that the telephony people with
more than hundred years of experience realized in the late seventies that

in order to scale and have very reliable networks
you had to separate signaling from transport (initially signaling was mixed
with transport -

that is the current case for all the analog lines
going from home to the local switch --> DTMF) and they created SS7 and
ISUP.

Actually people invented SIP using ISUP as their
guide.

That was one of the initial arguments of SIP:
separate proxies from transport of user data.

It seems to me that certain people want to regress
in time and mix signaling and user data.

Let us please learn from the history and lets
try not to repeat the same mistakes.

 

2) CPIM's Message function looks a lot like the page mode.

It seems that the first step forward is to recognize this and assume

that we will indeed use "MESSAGE over SIP" in the page mode for a

significant fraction of our exchanges. I suggest that the first order

action of SIMPLE is to just nail this one, so it be behind us.

The page mode has well known limitations: it creates a lot of overhead

in long sessions, and it does not extend easily to multi-party

operation. This is the rationale for the "IM session" extensions, i.e.

IM after INVITE. However, whatever we do in the session mode, we will

have to go on interworking with SMS and with CPIM; this means that
we

will have to bring in the session some members who can only use the
page

mode. Obviously, a "session of messages" makes this very easy.

-- Christian Huitema

_______________________________________________







--------------2490DA46D3D9DF8A6F1E4359--




From mhammer@cisco.com  Tue Oct  9 16:31:56 2001
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 QAA07913
	for ; Tue, 9 Oct 2001 16:31:55 -0400 (EDT)
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 QAA26238; Tue, 9 Oct 2001 16:31:42 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (rtp-vpn2-208.cisco.com [10.82.240.208])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ARW11836;
	Tue, 9 Oct 2001 16:31:45 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011009162017.00b05818@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 09 Oct 2001 16:36:01 -0400
To: Ben Campbell 
From: Michael Hammer 
Subject: Re: [Simple] IM over the signaling connection
Cc: Christian Huitema ,
        "Roy, Radhika R, ALCTA" ,
        Vasilis Polychronidis ,
        Jonathan Rosenberg ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3BC35281.2040203@dynamicsoft.com>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 5900
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: 

Ben,

Whether a message appears as a single IM or a stream of IM right now 
appears to be more of an implementation detail, absent a maximum IM 
size.  (Did I miss that definition?) Given that an application may send a 1 
Mbyte message as:

1) one 1 M IM,
2) two 512 K IMs,
3) four 256 K IMs,
...
n-2) 256 4 K IMs
n-1) 512 2 K IMs
n) 1024 1K IMs

Does IM size count at all or just message and response counts?
Do we care that SIP may need to segment to some max message size, say 1500 
bytes?
Do we care that a lower layer may need to segment the message prior to 
transmission?
Do we care if the IP layer has to fragment during transmission?
Are there some unstated assumptions in your calculation?

Mike


At 02:39 PM 10/9/2001 -0500, Ben Campbell wrote:
>I agree with Christian here--I really want to discourage session mode 
>unless one expects a stream of messages. One shot text messages should 
>normally be page mode.
>
>Christian Huitema wrote:
>
>>Note that my point was not to ignore the lessons of the past, but to 
>>point out that widely deployed systems such as SMS are not going to 
>>disappear in a day, or in a year -- they are with us for at least one or 
>>two upgrade cycles, i.e. at least 4 to 6 years.
>>
>>Also note that if the usage is actually a page, then a "message" is less 
>>taxing on the infrastructure than an "invite" + the necessary session 
>>clean-up. Let's compare:
>>
>>1) Message: one signalling message + one response per IM.
>>
>>2) Session: INVITE + response; ACK; BYE+response; + additional cost of 
>>setting the message channel; IM messages on channel.
>>
>>  From a pure signalling point of view, the session mode is only 
>> beneficial when there are at least 3 IM exchanged in a session.
>>
>>-- Christian Huitema
>>
>>-----Original Message-----
>>*From:* Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
>>*Sent:* Tuesday, October 09, 2001 6:23 AM
>>*To:* Vasilis Polychronidis; Christian Huitema
>>*Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, 
>>Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
>>*Subject:* RE: [Simple] IM over the signaling connection
>>     Hi, Vasilis:
>>
>>     Good that you have reminded the very important lesson from the past.
>>
>>     Would please let us know your opinion what do we do in the case of
>>     "Paging" in SIP?
>>
>>     Of course, we have another scheme: MESSAGE as session.
>>
>>     Radhika
>>         -----Original Message-----
>>         *From:* Vasilis Polychronidis
>>         [mailto:Vasilis.Polychronidis@openwave.com]
>>         *Sent:* Monday, October 08, 2001 4:43 PM
>>         *To:* Christian Huitema
>>         *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;
>>         Peterson, Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
>>         *Subject:* Re: [Simple] IM over the signaling connection
>>         Christian Huitema wrote:
>>             There are two points that I keep in mind in this debate:
>>             1) SMS, the messaging service of cell phones, uses the page
>>             mode and is
>>             carried at least in part over the signaling channel.
>>         Correct. However Operators realized that SMS was the wrong (was
>>         very successful financially) technical solution for messaging.
>>         Remind you that when the people designed (late 80s) SMS they did
>>         not have any idea of how successful commercial service will be.
>>         That is why the next generation of multimedia messaging is using
>>         HTTP as the transport.
>>         I understand that this is a difficult point to understand with
>>         some people in the list.
>>         Let me remind you that the telephony people with more than
>>         hundred years of experience realized in the late seventies that
>>         in order to scale and have very reliable networks you had to
>>         separate signaling from transport (initially signaling was mixed
>>         with transport -
>>         that is the current case for all the analog lines going from
>>         home to the local switch --> DTMF) and they created SS7 and ISUP.
>>         Actually people invented SIP using ISUP as their guide.
>>         That was one of the initial arguments of SIP: separate proxies
>>         from transport of user data.
>>         It seems to me that certain people want to regress in time and
>>         mix signaling and user data.
>>         Let us please learn from the history and lets try not to repeat
>>         the same mistakes.
>>
>>             2) CPIM's Message function looks a lot like the page mode.
>>             It seems that the first step forward is to recognize this
>>             and assume
>>             that we will indeed use "MESSAGE over SIP" in the page mode
>>             for a
>>             significant fraction of our exchanges. I suggest that the
>>             first order
>>             action of SIMPLE is to just nail this one, so it be behind us.
>>             The page mode has well known limitations: it creates a lot
>>             of overhead
>>             in long sessions, and it does not extend easily to multi-party
>>             operation. This is the rationale for the "IM session"
>>             extensions, i.e.
>>             IM after INVITE. However, whatever we do in the session
>>             mode, we will
>>             have to go on interworking with SMS and with CPIM; this
>>             means that we
>>             will have to bring in the session some members who can only
>>             use the page
>>             mode. Obviously, a "session of messages" makes this very easy.
>>             -- Christian Huitema
>>             _______________________________________________
>
>
>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple


From Vasilis.Polychronidis@Openwave.com  Tue Oct  9 16:33:41 2001
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 QAA07937
	for ; Tue, 9 Oct 2001 16:33:40 -0400 (EDT)
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27])
          by oe-mp2.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011009203234.HVSU28504.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Tue, 9 Oct 2001 15:32:34 -0500
Received: from Openwave.com ([4.41.19.164]) by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with ESMTP
          id <20011009203146.XVKT13982.oe-ismta2.bizmailsrvcs.net@Openwave.com>;
          Tue, 9 Oct 2001 15:31:46 -0500
Message-ID: <3BC35F12.E555B3D6@Openwave.com>
Date: Tue, 09 Oct 2001 13:33:22 -0700
From: Vasilis Polychronidis 
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema 
CC: "Roy, Radhika R, ALCTA" ,
        Ben Campbell ,
        Jonathan Rosenberg ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References: 
Content-Type: multipart/alternative;
 boundary="------------6DE42AAE8652362630204079"
Content-Length: 13103
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: 

--------------6DE42AAE8652362630204079
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christian Huitema wrote:

> Note that my point was not to ignore the lessons of the past, but to
> point out that widely deployed systems such as SMS are not going to
> disappear in a day, or in a year -- they are with us for at least one
> or two upgrade cycles, i.e. at least 4 to 6 years.

I agree but I do not understand what IM has to do with SMS.
If you referring on how to interface a SIMPLE IM system with SMS this
will be accomplished via a gateway and on the one
side of the GW you will speak SMS and the other side SIMPLE (session or
page mode).
If you mean that having the page mode simplifies the GW function I agree
but I do not see this as a big driver for choosing page mode over
session mode.
Anyway I am not against the page mode (I promised not to talk about it
anymore) and my understanding is that we agreed to have a
session mode too. I am happy if we provide both options.

> Also note that if the usage is actually a page, then a "message" is
> less taxing on the infrastructure than an "invite" + the necessary
> session clean-up. Let's compare:1) Message: one signalling message +
> one response per IM.2) Session: INVITE + response; ACK; BYE+response;
> + additional cost of setting the message channel; IM messages on
> channel.From a pure signalling point of view, the session mode is only
> beneficial when there are at least 3 IM exchanged in a session.--
> Christian Huitema-----Original Message-----
> From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
> Sent: Tuesday, October 09, 2001 6:23 AM
> To: Vasilis Polychronidis; Christian Huitema
> Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
> Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] IM over the signaling connection
>
>
>      Hi, Vasilis:Good that you have reminded the very important
>      lesson from the past.Would please let us know your opinion
>      what do we do in the case of "Paging" in SIP?Of course, we
>      have another scheme: MESSAGE as session.Radhika
>
>           -----Original Message-----
>           From: Vasilis Polychronidis
>           [mailto:Vasilis.Polychronidis@openwave.com]
>           Sent: Monday, October 08, 2001 4:43 PM
>           To: Christian Huitema
>           Cc: Ben Campbell; Jonathan Rosenberg; Henning
>           Schulzrinne; Peterson, Jon; Avshalom@ubique.com;
>           simple@mailman.dynamicsoft.com
>           Subject: Re: [Simple] IM over the signaling
>           connection
>           Christian Huitema wrote:
>
>          > There are two points that I keep in mind in this
>          > debate:
>          >
>          > 1) SMS, the messaging service of cell phones,
>          > uses the page mode and is
>          > carried at least in part over the signaling
>          > channel.
>
>           Correct. However Operators realized that SMS was
>           the wrong (was very successful financially)
>           technical solution for messaging.
>           Remind you that when the people designed (late
>           80s) SMS they did not have any idea of how
>           successful commercial service will be.
>           That is why the next generation of multimedia
>           messaging is using HTTP as the transport.
>           I understand that this is a difficult point to
>           understand with some people in the list.
>           Let me remind you that the telephony people with
>           more than hundred years of experience realized in
>           the late seventies that
>           in order to scale and have very reliable networks
>           you had to separate signaling from transport
>           (initially signaling was mixed with transport -
>           that is the current case for all the analog lines
>           going from home to the local switch --> DTMF) and
>           they created SS7 and ISUP.
>           Actually people invented SIP using ISUP as their
>           guide.
>           That was one of the initial arguments of SIP:
>           separate proxies from transport of user data.
>           It seems to me that certain people want to regress
>           in time and mix signaling and user data.
>           Let us please learn from the history and lets try
>           not to repeat the same mistakes.
>
>          >
>          >
>          > 2) CPIM's Message function looks a lot like the
>          > page mode.
>          >
>          > It seems that the first step forward is to
>          > recognize this and assume
>          > that we will indeed use "MESSAGE over SIP" in
>          > the page mode for a
>          > significant fraction of our exchanges. I suggest
>          > that the first order
>          > action of SIMPLE is to just nail this one, so it
>          > be behind us.
>          >
>          > The page mode has well known limitations: it
>          > creates a lot of overhead
>          > in long sessions, and it does not extend easily
>          > to multi-party
>          > operation. This is the rationale for the "IM
>          > session" extensions, i.e.
>          > IM after INVITE. However, whatever we do in the
>          > session mode, we will
>          > have to go on interworking with SMS and with
>          > CPIM; this means that we
>          > will have to bring in the session some members
>          > who can only use the page
>          > mode. Obviously, a "session of messages" makes
>          > this very easy.
>          >
>          > -- Christian Huitema
>          > _______________________________________________
>

--------------6DE42AAE8652362630204079
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Christian Huitema wrote:

Note
that my point was not to ignore the lessons of the past, but to point out
that widely deployed systems such as SMS are not going to disappear in
a day, or in a year -- they are with us for at least one or two upgrade
cycles, i.e. at least 4 to 6 years.

I agree but I do not understand what IM has to do with SMS.

If you referring on how to interface a SIMPLE IM system with SMS this
will be accomplished via a gateway and on the one

side of the GW you will speak SMS and the other side SIMPLE (session
or page mode).

If you mean that having the page mode simplifies the GW function I
agree but I do not see this as a big driver for choosing page mode over
session mode.

Anyway I am not against the page mode (I promised not to talk about
it anymore) and my understanding is that we agreed to have a

session mode too. I am happy if we provide both options.

Also
note that if the usage is actually a page, then a "message" is less taxing
on the infrastructure than an "invite" + the necessary session clean-up.
Let's compare:1)
Message: one signalling message + one response per IM.2)
Session: INVITE + response; ACK; BYE+response; + additional cost of setting
the message channel; IM messages on channel.From
a pure signalling point of view, the session mode is only beneficial when
there are at least 3 IM exchanged in a session.--
Christian Huitema-----Original
Message-----

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

Sent: Tuesday, October 09,
2001 6:23 AM

To: Vasilis Polychronidis;
Christian Huitema

Cc: Ben Campbell; Jonathan
Rosenberg; Henning Schulzrinne; Peterson, Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com

Subject: RE: [Simple] IM over
the signaling connection

 

Hi,
Vasilis:Good
that you have reminded the very important lesson from the past.Would
please let us know your opinion what do we do in the case of "Paging" in
SIP?Of
course, we have another scheme: MESSAGE as session.Radhika



-----Original
Message-----

From: Vasilis Polychronidis
[mailto:Vasilis.Polychronidis@openwave.com]

Sent: Monday, October
08, 2001 4:43 PM

To: Christian Huitema

Cc: Ben Campbell;
Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon; Avshalom@ubique.com;
simple@mailman.dynamicsoft.com

Subject: Re: [Simple]
IM over the signaling connection

Christian Huitema wrote:

There are two points that I keep in mind in this
debate:

1) SMS, the messaging service of cell phones, uses the page mode and
is

carried at least in part over the signaling channel.

Correct. However Operators realized that SMS was
the wrong (was very successful financially) technical solution for messaging.

Remind you that when the people designed (late
80s) SMS they did not have any idea of how successful commercial service
will be.

That is why the next generation of multimedia
messaging is using HTTP as the transport.

I understand that this is a difficult point to
understand with some people in the list.

Let me remind you that the telephony people with
more than hundred years of experience realized in the late seventies that

in order to scale and have very reliable networks
you had to separate signaling from transport (initially signaling was mixed
with transport -

that is the current case for all the analog lines
going from home to the local switch --> DTMF) and they created SS7 and
ISUP.

Actually people invented SIP using ISUP as their
guide.

That was one of the initial arguments of SIP:
separate proxies from transport of user data.

It seems to me that certain people want to regress
in time and mix signaling and user data.

Let us please learn from the history and lets
try not to repeat the same mistakes.

 

2) CPIM's Message function looks a lot like the page mode.

It seems that the first step forward is to recognize this and assume

that we will indeed use "MESSAGE over SIP" in the page mode for a

significant fraction of our exchanges. I suggest that the first order

action of SIMPLE is to just nail this one, so it be behind us.

The page mode has well known limitations: it creates a lot of overhead

in long sessions, and it does not extend easily to multi-party

operation. This is the rationale for the "IM session" extensions, i.e.

IM after INVITE. However, whatever we do in the session mode, we will

have to go on interworking with SMS and with CPIM; this means that
we

will have to bring in the session some members who can only use the
page

mode. Obviously, a "session of messages" makes this very easy.

-- Christian Huitema

_______________________________________________









--------------6DE42AAE8652362630204079--




From lachlan.brazier@siemens.at  Tue Oct  9 16:59:48 2001
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 QAA08070
	for ; Tue, 9 Oct 2001 16:59:48 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f99KxYu03630;
	Tue, 9 Oct 2001 22:59:34 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id WAA04260;
	Tue, 9 Oct 2001 22:59:33 +0200 (MET DST)
Received: from vies141a.sie.siemens.at(158.226.134.117) by scesie13 via smap (V2.0beta)
	id xma003848; Tue, 9 Oct 01 22:59:12 +0200
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <4QHX1G1C>; Tue, 9 Oct 2001 22:59:09 +0200
Message-ID: 
From: Brazier Lachlan 
To: "'Roy, Radhika R, ALCTA '" ,
        "'Christian Huitema '"
	 ,
        "'Vasilis Polychronidis '"
	 
Cc: "'Ben Campbell '" ,
        "'Jonathan Rosenberg '"
	 ,
        "'Henning Schulzrinne '" ,
        "'Peterson, Jon '" ,
        "'Avshalom@ubique.com '"
	 ,
        "'simple@mailman.dynamicsoft.com '"
	 
Subject: AW: [Simple] IM over the signaling connection
Date: Tue, 9 Oct 2001 22:59:09 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 6768
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: 

 Hello,

I believe that IM should be set up through an INVITE request, because this
way we seperate signalling and content information.

BUT:
1) Sending ANY message with ANY content in not forbidden in SIP. Nobody can
stop me sending anything. UAS can complain about my request because of
several reasons (size, kind of request, security, ...), but it still has to
handle my request.

2) Sometimes it makes more sense to send a single message, than building a
whole session. Example: An operator wants to inform a user who just
registered at it's registrar, how many calls were missed, how many calls are
on the awnsering machine, how much money the user won in the national
lottery, etc.. I really believe, a lot of applications will want to send
information without starting a session.

3) Generating and handling of simple Messages is absolutely easy to
implement and use.

For these reasons I think people will use simple messages to send data. So I
believe, we should have a well defined way of handling it properly.

There was the argument that requests with huge data in the body could block
proxies on the signaling path (if I understood that argument). This is
another reason, we should define how to handle these requests, otherwise we
will always have problems with load balancing or server availability.

Hm, I think that's what I wanted to say. Please note again, that for IM I
vote for setting it up through an INVITE. Still we need to deal with
messages, not belonging to a session.


Lachlan




-----Originalnachricht-----
Von: Roy, Radhika R, ALCTA
An: Christian Huitema; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Gesendet: 09.10.01 19:21
Betreff: RE: [Simple] IM over the signaling connection

 

-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.microsoft.com]
Sent: Tuesday, October 09, 2001 1:09 PM
To: Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection


Note that my point was not to ignore the lessons of the past, but to
point
out that widely deployed systems such as SMS are not going to disappear
in a
day, or in a year -- they are with us for at least one or two upgrade
cycles, i.e. at least 4 to 6 years.
  
[Roy, Radhika R, ALARC]  Agreed. 
 
Also note that if the usage is actually a page, then a "message" is less
taxing on the infrastructure than an "invite" + the necessary session
clean-up. Let's compare:
 
1) Message: one signalling message + one response per IM.
 
2) Session: INVITE + response; ACK; BYE+response; + additional cost of
setting the message channel; IM messages on channel.
 
From a pure signalling point of view, the session mode is only
beneficial
when there are at least 3 IM exchanged in a session.

[Roy, Radhika R, ALARC]  Yes, there is also a clear efficiency, but it
has a
real danger as well: 1. People might mis-use it overloading the
signaling
path through sending the larger messages or increasing the frequency of
shorter messages (had been explained earlier) and 2. It also breaks the
original SIP model - separation between signaling and media path.
Proposals
need to be there to address these two concerns.
 
-- Christian Huitema
 
-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] 
Sent: Tuesday, October 09, 2001 6:23 AM
To: Vasilis Polychronidis; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection



Hi, Vasilis:
 
Good that you have reminded the very important lesson from the past.
 
Would please let us know your opinion what do we do in the case of
"Paging"
in SIP?
 
Of course, we have another scheme: MESSAGE as session.
 
Radhika

-----Original Message-----
From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com]
Sent: Monday, October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection


Christian Huitema wrote: 

There are two points that I keep in mind in this debate: 

1) SMS, the messaging service of cell phones, uses the page mode and is 
carried at least in part over the signaling channel.

Correct. However Operators realized that SMS was the wrong (was very
successful financially) technical solution for messaging. 
Remind you that when the people designed (late 80s) SMS they did not
have
any idea of how successful commercial service will be. 
That is why the next generation of multimedia messaging is using HTTP as
the
transport. 
I understand that this is a difficult point to understand with some
people
in the list. 
Let me remind you that the telephony people with more than hundred years
of
experience realized in the late seventies that 
in order to scale and have very reliable networks you had to separate
signaling from transport (initially signaling was mixed with transport -

that is the current case for all the analog lines going from home to the
local switch --> DTMF) and they created SS7 and ISUP. 
Actually people invented SIP using ISUP as their guide. 
That was one of the initial arguments of SIP: separate proxies from
transport of user data. 
It seems to me that certain people want to regress in time and mix
signaling
and user data. 
Let us please learn from the history and lets try not to repeat the same
mistakes. 

  

2) CPIM's Message function looks a lot like the page mode. 


It seems that the first step forward is to recognize this and assume 
that we will indeed use "MESSAGE over SIP" in the page mode for a 
significant fraction of our exchanges. I suggest that the first order 
action of SIMPLE is to just nail this one, so it be behind us. 


The page mode has well known limitations: it creates a lot of overhead 
in long sessions, and it does not extend easily to multi-party 
operation. This is the rationale for the "IM session" extensions, i.e. 
IM after INVITE. However, whatever we do in the session mode, we will 
have to go on interworking with SMS and with CPIM; this means that we 
will have to bring in the session some members who can only use the page

mode. Obviously, a "session of messages" makes this very easy. 


-- Christian Huitema 
_______________________________________________ 


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

From gur@vocaltec.com  Tue Oct  9 23:14:59 2001
Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09361;
	Tue, 9 Oct 2001 23:14:58 -0400 (EDT)
From: gur@vocaltec.com
Subject: Re: [Simple] IM over the signaling connection
To: Ben Campbell 
Cc: Avshalom@ubique.com, Henning Schulzrinne ,
        Christian Huitema ,
        Jonathan Rosenberg ,
        "Peterson, Jon" ,
        "Roy, Radhika R, ALCTA" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Vasilis Polychronidis 
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: 
Date: Tue, 9 Oct 2001 19:35:39 -0500
X-MIMETrack: Serialize by Router on USNIMO/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 10/09/2001 11:06:34 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 2298
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: 

you are both correct - BUT in many cases two domain MESSAGE proxies will
maintain a long-lived session that will multiplex multiple messages
from multiple users, and of course this becomes even more common in
message clearinghouses (which do exist in the SMS world).

DOMAIN A                                    DOMAIN B
=====================..........=====================

UA1 <----> ++++++++++          ++++++++++ <----> UA4
           +        +          +        +
UA2 <----> + PROXY1 + <------> + PROXY2 + <----> UA5
           +        +          +        +
UA3 <----> ++++++++++          ++++++++++ <----> UA6

...To establish-a-TCP (or anything else that has congestion control) per
message  does not make sense
between proxies - most modern app protocols multiplex (which can be done
using simple  and ) at proxy2proxy links, have some timeout
mechanism to close the connection if it not used for  time, and
potentially open multiple parallel sessions based on some
users/messages/sec/session logic.  You can also imagine maintaining several
sessions between the proxies, each with a different QoS SLA etc.

It is possible that UAs will use page mode on the UA-PROXY leg and the
PROXY-PROXY leg will multiplex into an existing session (and back to a page
mode on the other side)

[slight subject change]

and - I don't see a problem with using TCP with some HTTP/SIP framing as
the
transport - run it as a separate TCP session but have as much commonality
between the two models (page/session) as possible.

- gur

Gur Kimchi
Chief Architect
VocalTec Communications

> Ben Campbell wrote:
>
> I agree with Christian here--I really want to discourage session mode
> unless one expects a stream of messages. One shot text messages should
> normally be page mode.
>
> Christian Huitema wrote:
>
> Note that my point was not to ignore the lessons of the past, but to
> point out that widely deployed systems such as SMS are not going to
> disappear in a day, or in a year -- they are with us for at least one or
> two upgrade cycles, i.e. at least 4 to 6 years.
>
> Also note that if the usage is actually a page, then a "message" is less
> taxing on the infrastructure than an "invite" + the necessary session
> clean-up. [snip]




From peter.lewis@upperside.fr  Wed Oct 10 05:24:44 2001
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10527
	for ; Wed, 10 Oct 2001 05:24:44 -0400 (EDT)
Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.cluster.oleane.net with SMTP id f9A9OSR84187 for ; Wed, 10 Oct 2001 11:24:29 +0200 (CEST)
Message-ID: <004301c1516d$1fbdc4a0$0601a8c0@oleane.com>
From: "Peter Lewis" 
To: 
Date: Wed, 10 Oct 2001 11:22:43 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0040_01C1517D.E1709C20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Length: 1209
Subject: [Simple] The International SIP conference
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0040_01C1517D.E1709C20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The International SIP conference will take place January 15 to 18, 2002 =
in Paris (Sofitel Bercy).=20
More details at:
http://www.upperside.fr/sip2002/sip2002intro.htm


------=_NextPart_000_0040_01C1517D.E1709C20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











The International SIP conference will take place =
January 15 to=20
18, 2002 in Paris (Sofitel Bercy). 


More details at:


http://www.uppe=
rside.fr/sip2002/sip2002intro.htm


 


------=_NextPart_000_0040_01C1517D.E1709C20--


From lra101@yahoo.com  Wed Oct 10 14:38:28 2001
Received: from web9808.mail.yahoo.com (web9808.mail.yahoo.com [216.136.129.34])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id OAA12232
	for ; Wed, 10 Oct 2001 14:38:28 -0400 (EDT)
Message-ID: <20011010183813.85495.qmail@web9808.mail.yahoo.com>
Received: from [208.12.45.206] by web9808.mail.yahoo.com via HTTP; Wed, 10 Oct 2001 11:38:13 PDT
Date: Wed, 10 Oct 2001 11:38:13 -0700 (PDT)
From: a c 
Subject: [Simple] Possible IM Message solution?? 
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 3362
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: 

>1. Routing information of the MESSAGE signaling is
pushed back to SDP.

yes. SDP would contain additional media server fields 
 ms1=x.x.x.x/1234 
 ms2=x.x.x.y/2345

>2. Based on the routing information of the MESSAGE
signaling path, one needs to find out the media
routing path over the message servers.

yes. shouldn't be a problem since each proxy would
know which media servers it controls. 

One shot IMs/Paging mode:
------------------------
When an IM session starts, the messages are relayed by
the proxy but ms keeps track of the number of messages
(or size) sent/received, if it exceeds a certain
threashold, then it informs the proxy. Proxy can then
do a re-invite(something like that) to switch the
media stream over to the ms.*** MS should already know
who the parties are in the session.

Assumptions:

- Number of media servers <= Number of proxies
- If media server in call then proxy in call (is 
  this a valid assumption?). Since you need the 
  proxy to tell the media server to release 
  resources.

>Will this create conflicts with the already
established
notions in SDP? 

experts?

>Hi, Alex:

The way I understand your proposal is as follows:

1. Routing information of the MESSAGE signaling is
pushed back to SDP.

2. Based on the routing information of the MESSAGE
signaling path, one needs
to find out the media routing path over the message
servers.

The question is: Why can we not generalize it so that
we can see the big
picture where this proposal will lead us analyzing all
implications? For
example, there can be multiple proxies and multiple
media servers. It will
not be used for point-to-point communications, but
will also be for
multipoint communications. Why can this principle not
be used for other
media as well? Will this create conflicts with the
already established
notions in SDP?

Radhika

-----Original Message-----
From: a c [mailto:lra101@yahoo.com]
Sent: Monday, October 08, 2001 4:43 PM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] Possible IM Message solution?? 


hello Radhika,

>(I hope that you are NOT proposing routing of media
via network layer devices like routers.)

no. This is an application server which processes 
IM messages and routes them to their endpoints. 
It cannot be used for voice due to the realtime
constraints. But it can definetly be used for 
IM traffic. It can do much more than  just 
passing traffic. For example : language 
translation,  calea, etc..

The only requirement is that it talks to 
the proxy. The proxy can instruct the 
application server to implement a certain feature 
per call. 

other advantages:

- drastically cuts down on header tags (no header 
  tags. Why do we need them when signalling 
  is taking care of it). 
- If no headers in the message, then it is easier 
  to convert to other protocols (e.g. cpim). No 
  parsing of headers for each message
- congestion control (app server initiated 
  congestion control)
- capability to do end to end or thru server

Addresses Brian Rosen's 4 variables:

        Direct UA-to-UA routing - can do both
        TCP transport - / udp
        SIP Headers - not necessary
        cpim Body - no problem

alex

__________________________________________________



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

From lra101@yahoo.com  Wed Oct 10 15:11:41 2001
Received: from web9802.mail.yahoo.com (web9802.mail.yahoo.com [216.136.129.212])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA12369
	for ; Wed, 10 Oct 2001 15:11:40 -0400 (EDT)
Message-ID: <20011010191124.71090.qmail@web9802.mail.yahoo.com>
Received: from [208.12.45.206] by web9802.mail.yahoo.com via HTTP; Wed, 10 Oct 2001 12:11:24 PDT
Date: Wed, 10 Oct 2001 12:11:24 -0700 (PDT)
From: a c 
Subject: [Simple] Possible IM Message solution?? 
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 736
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: 

the counter can also be kept on the proxy (probably
better) and the re-invite(?) made by the proxy. MS
should already know who the parties are in the session
and should be expecting media.


>One shot IMs/Paging mode:
------------------------
When an IM session starts, the messages are relayed by
the proxy but ms keeps track of the number of messages
(or size) sent/received, if it exceeds a certain
threashold, then it informs the proxy. Proxy can then
do a re-invite(something like that) to switch the
media stream over to the ms.*** MS should already know
who the parties are in the session.

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

From mhammer@cisco.com  Wed Oct 10 16:02:09 2001
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 QAA12553
	for ; Wed, 10 Oct 2001 16:02:08 -0400 (EDT)
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 QAA20821; Wed, 10 Oct 2001 16:01:56 -0400 (EDT)
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 ARX03731;
	Wed, 10 Oct 2001 16:01:59 -0400 (EDT)
Message-Id: <4.3.2.7.2.20011010155924.00b38a20@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 10 Oct 2001 16:06:18 -0400
To: Brazier Lachlan 
From: Michael Hammer 
Subject: Re: AW: [Simple] IM over the signaling connection
Cc: "'Roy, Radhika R, ALCTA '" ,
        "'Christian Huitema '" ,
        "'Vasilis Polychronidis '" ,
        "'Ben Campbell '" ,
        "'Jonathan Rosenberg '" ,
        "'Henning Schulzrinne '" ,
        "'Peterson, Jon '" ,
        "'Avshalom@ubique.com '" ,
        "'simple@mailman.dynamicsoft.com '" 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Content-Length: 8796
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: 


All,



Random thought:  Is this discussion of connection-oriented versus
connectionless any different than the one that resulted in the Fast
Select procedure used in X.25 networks?  Small amount of data
carried in the connection request (Invite) which is then declined for
connection setup purposes, but the data gets delivered.  If the
receiving party wishes to reply with data, connection is accepted.



Mike





At 10:59 PM 10/9/2001 +0200, Brazier Lachlan wrote:


 Hello,



I believe that IM should be set up through an INVITE request, because
this

way we seperate signalling and content information.



BUT:

1) Sending ANY message with ANY content in not forbidden in SIP. Nobody
can

stop me sending anything. UAS can complain about my request because
of

several reasons (size, kind of request, security, ...), but it still has
to

handle my request.



2) Sometimes it makes more sense to send a single message, than building
a

whole session. Example: An operator wants to inform a user who just

registered at it's registrar, how many calls were missed, how many calls
are

on the awnsering machine, how much money the user won in the
national

lottery, etc.. I really believe, a lot of applications will want to
send

information without starting a session.



3) Generating and handling of simple Messages is absolutely easy to

implement and use.



For these reasons I think people will use simple messages to send data.
So I

believe, we should have a well defined way of handling it properly.



There was the argument that requests with huge data in the body could
block

proxies on the signaling path (if I understood that argument). This
is

another reason, we should define how to handle these requests, otherwise
we

will always have problems with load balancing or server
availability.



Hm, I think that's what I wanted to say. Please note again, that for IM
I

vote for setting it up through an INVITE. Still we need to deal 
with

messages, not belonging to a session.





Lachlan









-----Originalnachricht-----

Von: Roy, Radhika R, ALCTA

An: Christian Huitema; Vasilis Polychronidis

Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon;

Avshalom@ubique.com; simple@mailman.dynamicsoft.com

Gesendet: 09.10.01 19:21

Betreff: RE: [Simple] IM over the signaling connection



 



-----Original Message-----

From: Christian Huitema
[mailto:huitema@windows.microsoft.com]

Sent: Tuesday, October 09, 2001 1:09 PM

To: Roy, Radhika R, ALCTA; Vasilis Polychronidis

Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; 
Peterson,

Jon;

Avshalom@ubique.com; simple@mailman.dynamicsoft.com

Subject: RE: [Simple] IM over the signaling connection





Note that my point was not to ignore the lessons of the past, but 
to

point

out that widely deployed systems such as SMS are not going to
disappear

in a

day, or in a year -- they are with us for at least one or two
upgrade

cycles, i.e. at least 4 to 6 years.

  

[Roy, Radhika R, ALARC]  Agreed. 

 

Also note that if the usage is actually a page, then a
"message" is less

taxing on the infrastructure than an "invite" + the necessary
session

clean-up. Let's compare:

 

1) Message: one signalling message + one response per IM.

 

2) Session: INVITE + response; ACK; BYE+response; + additional cost
of

setting the message channel; IM messages on channel.

 

 From a pure signalling point of view, the session mode is only

beneficial

when there are at least 3 IM exchanged in a session.



[Roy, Radhika R, ALARC]  Yes, there is also a clear efficiency, but
it

has a

real danger as well: 1. People might mis-use it overloading the

signaling

path through sending the larger messages or increasing the frequency
of

shorter messages (had been explained earlier) and 2. It also breaks
the

original SIP model - separation between signaling and media path.

Proposals

need to be there to address these two concerns.

 

-- Christian Huitema

 

-----Original Message-----

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


Sent: Tuesday, October 09, 2001 6:23 AM

To: Vasilis Polychronidis; Christian Huitema

Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; 
Peterson,

Jon;

Avshalom@ubique.com; simple@mailman.dynamicsoft.com

Subject: RE: [Simple] IM over the signaling connection







Hi, Vasilis:

 

Good that you have reminded the very important lesson from the 
past.

 

Would please let us know your opinion what do we do in the case of

"Paging"

in SIP?

 

Of course, we have another scheme: MESSAGE as session.

 

Radhika



-----Original Message-----

From: Vasilis Polychronidis
[mailto:Vasilis.Polychronidis@openwave.com]

Sent: Monday, October 08, 2001 4:43 PM

To: Christian Huitema

Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; 
Peterson,

Jon;

Avshalom@ubique.com; simple@mailman.dynamicsoft.com

Subject: Re: [Simple] IM over the signaling connection





Christian Huitema wrote: 



There are two points that I keep in mind in this debate: 



1) SMS, the messaging service of cell phones, uses the page mode and is


carried at least in part over the signaling channel.



Correct. However Operators realized that SMS was the wrong (was 
very

successful financially) technical solution for messaging. 

Remind you that when the people designed (late 80s) SMS they did 
not

have

any idea of how successful commercial service will be. 

That is why the next generation of multimedia messaging is using HTTP
as

the

transport. 

I understand that this is a difficult point to understand with some

people

in the list. 

Let me remind you that the telephony people with more than hundred
years

of

experience realized in the late seventies that 

in order to scale and have very reliable networks you had to
separate

signaling from transport (initially signaling was mixed with transport
-



that is the current case for all the analog lines going from home to
the

local switch --> DTMF) and they created SS7 and ISUP. 

Actually people invented SIP using ISUP as their guide. 

That was one of the initial arguments of SIP: separate proxies from

transport of user data. 

It seems to me that certain people want to regress in time and mix

signaling

and user data. 

Let us please learn from the history and lets try not to repeat the
same

mistakes. 



  



2) CPIM's Message function looks a lot like the page mode. 





It seems that the first step forward is to recognize this and assume


that we will indeed use "MESSAGE over SIP" in the page mode for
a 

significant fraction of our exchanges. I suggest that the first order


action of SIMPLE is to just nail this one, so it be behind us. 





The page mode has well known limitations: it creates a lot of overhead


in long sessions, and it does not extend easily to multi-party 

operation. This is the rationale for the "IM session"
extensions, i.e. 

IM after INVITE. However, whatever we do in the session mode, we will


have to go on interworking with SMS and with CPIM; this means that we


will have to bring in the session some members who can only use the
page



mode. Obviously, a "session of messages" makes this very easy.






-- Christian Huitema 

_______________________________________________ 





_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple



From jdrosen@dynamicsoft.com  Thu Oct 11 12:06:40 2001
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 MAA16205;
	Thu, 11 Oct 2001 12:06:39 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9BG4A8P015855;
	Thu, 11 Oct 2001 12:04:10 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4QPLLC7V>; Thu, 11 Oct 2001 12:05:17 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'gur@vocaltec.com'" ,
        Ben Campbell
	 
Cc: Avshalom@ubique.com, Henning Schulzrinne ,
        Christian Huitema ,
        Jonathan Rosenberg
	 ,
        "Peterson, Jon" ,
        "Roy, Radhika R, ALCTA" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Vasilis Polychronidis
	 
Subject: RE: [Simple] IM over the signaling connection
Date: Thu, 11 Oct 2001 12:05:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 7719
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: 

Just for the sake of education, people should be aware that SIP does indeed
support persistent connections between servers. This is described (although
not well) in the current bis; bis-05 will be substantially clearer in its
usage. My own companies proxy ships with this capability today. As Gur
suggests, we maintain the connections until some period of inactivity after
which they are closed.

However, I am not suggesting that we use SIP proxies for message transport.
Using Brian's decomposition, I think a reasonable path is:

format: some subset of sip headers (From, Content-Type, Content-Length)
encapsulation: no additional encapsulation layer
transport: tcp or sctp

Routing is the hard one. If we use SIP proxies, we have two choices. Choice
1 is that we reuse the SIP proxies we already have, and that a IM during a
session is sent over the same set of proxies which record-routed. I.e., in
this case, the IMs are sent over the same path as a re-INVITE would be.
However, I expect that:

(1) many proxies will record-route for reasons that have nothing to do with
firewall traversal, but rather for signaling and services, so we get
increased message traffic and worse performance from our proxies.
(2) many of the hops between proxies for a route set will be UDP, not TCP

Thus, using the route set from the signaling path will not provide
sufficient congestion control in many cases. I believe that is the primary
problem.

So, if we deploy separate proxies, which ALWAYS use tcp/sctp, and then use
them for routing, we are already incurring the additional cost of such
deployment. We also get the following drawbacks:

(1) sheer message/s rate of a sip proxy forwarding logic will be far less
than could be accomplished with pure transport layer routing logic (i.e.,
based on IP/ports or something else)
(2) these elements cannot support routing of other media types, so we will
need to deploy a third component as well.

The key is to focus on system cost for a complete communicatins system, not
IM alone. Anyone doing IM these days is also doing voice already at least.

I would further argue that if we want muxing of messages between proxies,
SCTP is probably the best solution for that. Indeed, it provides the nice
benefit of a demux within a connection, using stream IDs. I believe (someone
correct me if I am wrong) that you do not need to set up a stream, you can
simply use a stream ID within an association. This means that we can do the
routing at the IP/port layer for non-multipexed transports, and use
IP/port/stream ID for muxing. Let me give an example:

User A ------- proxy A ------ proxy B ----- user B

Between proxy A and proxy B is SCTP. user A sends an INVITE to proxy A, and
indicates usage of comedia. That invite indicates he'd like to receive IM
via a tcp connection made to IP/port A1/A2 (thus, he's passive). THis goes
to proxy A. Proxy A rewrites the SDP, so that it indicates that IM for this
call should be received on SCTP assocation on IP/port/streamID A3/A4/A5.
THis goes to proxy B, which rewrites the SDP to indicate that IM for this
session should be received on TCP with IP/port B1/B2. User B gets this, and
sends a 200 OK, indicating that he's active for this (and therefore, no
IP/ports are provided). The 200 OK is propagated back to user A. B then
opens a TCP connection to B1/B2 on the proxy. The proxy receives this, and
maps data received on B1/B2 to SCTP association connection to A3/A4 (which
already exists) with streamID A5. Proxy A opens a tcp connection to B1/B2
and associates it with data received/sent on the SCTP connaction with stream
ID A5. Now, B sends data, and it travels to A using the shared SCTP
association between proxy A and proxy B.

There is no reason this TCP/SCTP shuffling function needs to be co-resident
in the proxy, and it can be moved off of it if you like. Add UDP shuffling
and it works for RTP traffic as well. Now, we have a generic element for
supporting all media types. It scales independently of the proxy. We get
shared connections between enterprises. We get reasonable congestion control
w/o HOL blocking, which is really good for IM, IMHO. The solution also will
result in direct e2e IM when there are no firewalls, since if the proxies do
nothing instead that will be the result.

If you do split off this TCP/SCTP shuffler, you need to control it from the
proxy. There are many ways to do that, including megaco, mgcp, and whatever
midcom eventually looks like.

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

> -----Original Message-----
> From: gur@vocaltec.com [mailto:gur@vocaltec.com]
> Sent: Tuesday, October 09, 2001 8:36 PM
> To: Ben Campbell
> Cc: Avshalom@ubique.com; Henning Schulzrinne; Christian Huitema;
> Jonathan Rosenberg; Peterson, Jon; Roy, Radhika R, ALCTA;
> simple@mailman.dynamicsoft.com; simple-admin@mailman.dynamicsoft.com;
> Vasilis Polychronidis
> Subject: Re: [Simple] IM over the signaling connection
> 
> 
> you are both correct - BUT in many cases two domain MESSAGE 
> proxies will
> maintain a long-lived session that will multiplex multiple messages
> from multiple users, and of course this becomes even more common in
> message clearinghouses (which do exist in the SMS world).
> 
> DOMAIN A                                    DOMAIN B
> =====================..........=====================
> 
> UA1 <----> ++++++++++          ++++++++++ <----> UA4
>            +        +          +        +
> UA2 <----> + PROXY1 + <------> + PROXY2 + <----> UA5
>            +        +          +        +
> UA3 <----> ++++++++++          ++++++++++ <----> UA6
> 
> ...To establish-a-TCP (or anything else that has congestion 
> control) per
> message  does not 
> make sense
> between proxies - most modern app protocols multiplex (which 
> can be done
> using simple  and ) at proxy2proxy links, have some timeout
> mechanism to close the connection if it not used for  time, and
> potentially open multiple parallel sessions based on some
> users/messages/sec/session logic.  You can also imagine 
> maintaining several
> sessions between the proxies, each with a different QoS SLA etc.
> 
> It is possible that UAs will use page mode on the UA-PROXY leg and the
> PROXY-PROXY leg will multiplex into an existing session (and 
> back to a page
> mode on the other side)
> 
> [slight subject change]
> 
> and - I don't see a problem with using TCP with some HTTP/SIP 
> framing as
> the
> transport - run it as a separate TCP session but have as much 
> commonality
> between the two models (page/session) as possible.
> 
> - gur
> 
> Gur Kimchi
> Chief Architect
> VocalTec Communications
> 
> > Ben Campbell wrote:
> >
> > I agree with Christian here--I really want to discourage 
> session mode
> > unless one expects a stream of messages. One shot text 
> messages should
> > normally be page mode.
> >
> > Christian Huitema wrote:
> >
> > Note that my point was not to ignore the lessons of the past, but to
> > point out that widely deployed systems such as SMS are not going to
> > disappear in a day, or in a year -- they are with us for at 
> least one or
> > two upgrade cycles, i.e. at least 4 to 6 years.
> >
> > Also note that if the usage is actually a page, then a 
> "message" is less
> > taxing on the infrastructure than an "invite" + the 
> necessary session
> > clean-up. [snip]
> 
> 
> 

From jdrosen@dynamicsoft.com  Thu Oct 11 12:11:44 2001
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 MAA16246
	for ; Thu, 11 Oct 2001 12:11:44 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9BG9o8P015953;
	Thu, 11 Oct 2001 12:09:50 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4QPLLC8Y>; Thu, 11 Oct 2001 12:10:57 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Rosen, Brian'" ,
        "'Christian Huitema'"
	 ,
        "Roy, Radhika R, ALCTA" ,
        Vasilis Polychronidis 
Cc: Ben Campbell ,
        Jonathan Rosenberg
	 ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection
Date: Thu, 11 Oct 2001 12:10:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 6801
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: 

One additional thing to consider is a point raised by Gur on the list.

Do we need to provide a way to correlate IMs sent in page mode with IMs sent
through a session that is later established? If not, the user experience
might not be so great. It seems like we might want to provide a correlation
capability so that usage of sessions can be done in such a way that a client
can be built for whom the transition is natural. 

To some degree, we are doing the wrong thing by providing two ways of
solving the same problem; IETF guidelines general advise to "pick one". I do
think there are sufficient use case scenarios to warrant both page and
session models, but to make up for having done both we probably need to
consider a story on how they can be correlated.

Adding some kind of correlation ID to the message meta-data is the simplest
way. For sessions, its right there with the other headers, for page mode, it
could be a SIP header, or a meta-data header like the CPIM headers are.

-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: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, October 09, 2001 4:20 PM
To: 'Christian Huitema'; Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection


I think that the "usual" IM usage is many more than 3 messages per session.
I think the problem is distinguishing the cases based on user input; you
don't
want the user to decide, you want the system to decide.

I think that, without needing standardization, some simple heuristic like
two or
three messages in a minute means start a session.

Please remember that the problem with congestion control is NOT an
individual
user.   The problem is a system supporting millions of users.   What is 3 or
4 IMs in a minute is 6-12 protocol messages times millions per minute.
You need flow control for that.  Millions of page messages will be
problematic
for a single system.  Millions of end-to-end messages between pairs of
endpoints
with flow control won't.

Brian
-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.microsoft.com]
Sent: Tuesday, October 09, 2001 1:09 PM
To: Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection


Note that my point was not to ignore the lessons of the past, but to point
out that widely deployed systems such as SMS are not going to disappear in a
day, or in a year -- they are with us for at least one or two upgrade
cycles, i.e. at least 4 to 6 years.

Also note that if the usage is actually a page, then a "message" is less
taxing on the infrastructure than an "invite" + the necessary session
clean-up. Let's compare:

1) Message: one signalling message + one response per IM.

2) Session: INVITE + response; ACK; BYE+response; + additional cost of
setting the message channel; IM messages on channel.

From a pure signalling point of view, the session mode is only beneficial
when there are at least 3 IM exchanged in a session.

-- Christian Huitema

-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] 
Sent: Tuesday, October 09, 2001 6:23 AM
To: Vasilis Polychronidis; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM over the signaling connection


Hi, Vasilis:

Good that you have reminded the very important lesson from the past.

Would please let us know your opinion what do we do in the case of "Paging"
in SIP?

Of course, we have another scheme: MESSAGE as session.

Radhika
-----Original Message-----
From: Vasilis Polychronidis [mailto:Vasilis.Polychronidis@openwave.com]
Sent: Monday, October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
Avshalom@ubique.com; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection


Christian Huitema wrote: 
There are two points that I keep in mind in this debate: 
1) SMS, the messaging service of cell phones, uses the page mode and is 
carried at least in part over the signaling channel.
Correct. However Operators realized that SMS was the wrong (was very
successful financially) technical solution for messaging. 
Remind you that when the people designed (late 80s) SMS they did not have
any idea of how successful commercial service will be. 
That is why the next generation of multimedia messaging is using HTTP as the
transport. 
I understand that this is a difficult point to understand with some people
in the list. 
Let me remind you that the telephony people with more than hundred years of
experience realized in the late seventies that 
in order to scale and have very reliable networks you had to separate
signaling from transport (initially signaling was mixed with transport - 
that is the current case for all the analog lines going from home to the
local switch --> DTMF) and they created SS7 and ISUP. 
Actually people invented SIP using ISUP as their guide. 
That was one of the initial arguments of SIP: separate proxies from
transport of user data. 
It seems to me that certain people want to regress in time and mix signaling
and user data. 
Let us please learn from the history and lets try not to repeat the same
mistakes. 
  
2) CPIM's Message function looks a lot like the page mode. 
It seems that the first step forward is to recognize this and assume 
that we will indeed use "MESSAGE over SIP" in the page mode for a 
significant fraction of our exchanges. I suggest that the first order 
action of SIMPLE is to just nail this one, so it be behind us. 
The page mode has well known limitations: it creates a lot of overhead 
in long sessions, and it does not extend easily to multi-party 
operation. This is the rationale for the "IM session" extensions, i.e. 
IM after INVITE. However, whatever we do in the session mode, we will 
have to go on interworking with SMS and with CPIM; this means that we 
will have to bring in the session some members who can only use the page 
mode. Obviously, a "session of messages" makes this very easy. 
-- Christian Huitema 
_______________________________________________ 

From Gur_Kimchi@vocaltec.com  Thu Oct 11 16:26:39 2001
Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17036;
	Thu, 11 Oct 2001 16:26:37 -0400 (EDT)
From: Gur_Kimchi@vocaltec.com
Subject: RE: [Simple] IM over the signaling connection
To: Jonathan Rosenberg 
Cc: Avshalom@ubique.com, Ben Campbell ,
        "'Rosen, Brian'" ,
        Henning Schulzrinne ,
        "'Christian Huitema'" ,
        Jonathan Rosenberg ,
        "Peterson, Jon" ,
        "Roy, Radhika R, ALCTA" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Vasilis Polychronidis 
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: 
Date: Thu, 11 Oct 2001 16:17:52 -0500
X-MIMETrack: Serialize by Router on USNIMO/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 10/11/2001 04:25:56 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 1107
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: 

>> Jonathan R. Wrote:
>>
>> Adding some kind of correlation ID to the message meta-data is the
simplest
>> way. For sessions, its right there with the other headers, for page
mode, it
>> could be a SIP header, or a meta-data header like the CPIM headers are.

Providing messages with two optional headers:  and 
allows the sender to choose to

(1) provide message identification for later processing (if this is not
clear then imagine some message indexing at the server to allow message
access by non-SIP elements, like web-browsers via an App Server, WAP etc)

and

(2) to associate a specific message with a thread-of-messages - this way
if a message arrives using page mode, and a later session is established
and a new message arrives with the same Thread-ID, the UA knows it is part
of the same session - this also allows muxing multiple threads within a
session without any transport muxing.

(of course both IDs are generated by the originating UA, the two headers
should
be optional - many apps do not need them).

- gur

Gur Kimchi
Chief Architect
VocalTec Communications.


From pkyzivat@cisco.com  Thu Oct 11 19:30:48 2001
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 TAA17665;
	Thu, 11 Oct 2001 19:30:48 -0400 (EDT)
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 f9BNTkC11090;
	Thu, 11 Oct 2001 19:29:46 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAB78686 (AUTH pkyzivat);
	Thu, 11 Oct 2001 19:31:48 -0400 (EDT)
Message-ID: <3BC62B25.EDC6D758@cisco.com>
Date: Thu, 11 Oct 2001 19:28:37 -0400
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: Gur_Kimchi@vocaltec.com
CC: Jonathan Rosenberg , Avshalom@ubique.com,
        Ben Campbell ,
        "'Rosen, Brian'" ,
        Henning Schulzrinne ,
        "'Christian Huitema'" ,
        "Peterson, Jon" ,
        "Roy, Radhika R, ALCTA" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Vasilis Polychronidis 
Subject: Re: [Simple] IM over the signaling connection
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1383
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: 

In addition to  and , it would be useful to have
an  header, so that proper message ordering can be
achieved. In theory the  is sufficient to define a thread,
but in practice it probably isn't, so having both is useful.

On the other hand, having  might encourage abuse of paging
mode by providing another way to implement sessions. Just having
 and  would be sufficient to tie a new session
to a preceding page mode message.

	Paul Kyzivat

Gur_Kimchi@vocaltec.com wrote:
> 
> Providing messages with two optional headers:  and 
> allows the sender to choose to
> 
> (1) provide message identification for later processing (if this is not
> clear then imagine some message indexing at the server to allow message
> access by non-SIP elements, like web-browsers via an App Server, WAP etc)
> 
> and
> 
> (2) to associate a specific message with a thread-of-messages - this way
> if a message arrives using page mode, and a later session is established
> and a new message arrives with the same Thread-ID, the UA knows it is part
> of the same session - this also allows muxing multiple threads within a
> session without any transport muxing.
> 
> (of course both IDs are generated by the originating UA, the two headers
> should
> be optional - many apps do not need them).

From gur@vocaltec.com  Thu Oct 11 20:01:31 2001
Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17790;
	Thu, 11 Oct 2001 20:01:31 -0400 (EDT)
From: gur@vocaltec.com
Subject: Re: [Simple] IM over the signaling connection
To: Paul Kyzivat 
Cc: Avshalom@ubique.com, Ben Campbell ,
        "'Rosen, Brian'" ,
        Henning Schulzrinne ,
        "'Christian Huitema'" ,
        Jonathan Rosenberg ,
        "Peterson, Jon" ,
        "Roy, Radhika R, ALCTA" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Vasilis Polychronidis 
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: 
Date: Thu, 11 Oct 2001 19:52:53 -0500
X-MIMETrack: Serialize by Router on USNIMO/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 10/11/2001 08:00:47 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 2876
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: 

Paul -

not having the Session-ID and only relaying on the  has
some increased statfullness requirements on proxies - and again, my
original
point that while we --hope-- many IM sessions will be end2end, in
reality many inter-domain IM sessions will traverse some DMZ
IM or SIP proxy that will provide authentication and authorization -
domain policy ("this user is blacklisted", "translate between English and
French")
should be done when entering the network, not by the UA.

And of course if the proxy is no longer needed it can replace the u2p2u
session
with an u2u one - another advantage of using standard SIP setup for IM
sessions.

Also - I believe messages, regardless if sent using pages or in sessions,
should be associated with a "thread-of-messages ID" - this makes for a much
cleaner design - not needed in every case mind you, but in many
person2person
scenarios.  Also this provides a stateless way for both UAs and Proxies
to continue past sessions - just choosing some arbitrary time for a session
to expire -because the transport closed- or -some timer fired- is less
then optimal.  I may, as a user, as I do many times, continue a
conversation
I finished last night - and it should contextually be the same "thread" -
while clearly the transport will be replaced and a new session created.

so while I am not objecting to an additional optional  header,
I dont think it replaced .

- gur

> Paul Kyzivat Wrote:
>
> In addition to  and , it would be useful to have
> an  header, so that proper message ordering can be
> achieved. In theory the  is sufficient to define a thread,
> but in practice it probably isn't, so having both is useful.
>
> On the other hand, having  might encourage abuse of paging
> mode by providing another way to implement sessions. Just having
>  and  would be sufficient to tie a new session
> to a preceding page mode message.
>
>
>> Gur_Kimchi@vocaltec.com wrote:
>>
>> Providing messages with two optional headers:  and

>> allows the sender to choose to
>>
>> (1) provide message identification for later processing (if this is not
>> clear then imagine some message indexing at the server to allow message
>> access by non-SIP elements, like web-browsers via an App Server, WAP
etc)
>>
>> and
>>
>> (2) to associate a specific message with a thread-of-messages - this way
>> if a message arrives using page mode, and a later session is established
>> and a new message arrives with the same Thread-ID, the UA knows it is
part
>> of the same session - this also allows muxing multiple threads within a
>> session without any transport muxing.
>>
>> (of course both IDs are generated by the originating UA, the two headers
>> should
>> be optional - many apps do not need them).


From petkos@cs.columbia.edu  Fri Oct 12 13:51:31 2001
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 NAA21044
	for ; Fri, 12 Oct 2001 13:51:29 -0400 (EDT)
Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA26586
	for ; Fri, 12 Oct 2001 13:51:13 -0400 (EDT)
Received: (from petkos@localhost)
	by dynasty.cs.columbia.edu (8.9.3/8.9.3) id NAA12067
	for simple@mailman.dynamicsoft.com; Fri, 12 Oct 2001 13:51:12 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200110121751.NAA12067@dynasty.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Fri, 12 Oct 2001 13:51:12 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 956
Subject: [Simple] IM format
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: 

Hi,

Message and thread identification is essential for 
session based IM format as described in 
"Group Messaging in SIP" draft.

Thread identification is not very useful in two-party chat,
but in multi-party chat (and some non-chat applicatios)
it is a necessity.

Thread-id header itself is not needed. 
Instead, thread identification can be achieved 
with Message-id and References headers.
It allows also nested threads.

We also need (optional) Subject header since the subject may
change inside a chat session (e.g. new sub-thread).

Message-id and References headers may be added into SIP format 
or into new (SIP/CPIM like) IM format. 
The amount of headers needed for IM format seems to be
relative high and finalizing the new format will be 
time-consuming. Also, given that SIP compression eliminates
the overhead in low-speed links there isn't any reason
trying to invent new IM format (just to save 2-3 transport related
headers).


--
Petri

From jdrosen@dynamicsoft.com  Sat Oct 13 10:29:19 2001
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 KAA24710
	for ; Sat, 13 Oct 2001 10:29:19 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9DERw8P000405;
	Sat, 13 Oct 2001 10:27:58 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <4QPLL2WN>; Sat, 13 Oct 2001 10:29:07 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Lessing, Francois'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY
Date: Sat, 13 Oct 2001 10:29:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 2983
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: 

We have debated this before, with the general conclusion that a SUBSCRIBE
within a call leg should behave no differently than one outside of the leg.
The fact that its already within a leg simply means that the route sets and
CSeq are established, rather than needing to have been established by an
initial INVITE. The fact that its in a call leg would change nothing about
identifying whats being subscribed to.

I see no particular benefit to placing a subscription within a call leg
(although I do see benefit in using the route headers from an existing call
leg), but I see no strong reason to forbid it.

-Jonathan R.
 

> -----Original Message-----
> From: Lessing, Francois [mailto:francoisx.lessing@intel.com]
> Sent: Monday, October 08, 2001 8:35 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY
> 
> 
> Hi everyone,
> 
> The event notification drafts 'discourages' re-use of
> call leg information [1] (see quote from draft at end of mail)
> 
> Does this mean we sometimes allow a SUBSCRIBE
> request on an existing  call leg created by INVITE ?
> 
> To me this would not make sense, it seems to
> go against the broader intention of the draft.
> 
> The only reason I can think where this might be
> useful, is to SUBSCRIBE to a resource that is
> associated with an existing call leg.
> 
> But, an event is only allowed to be identified
> by event type, Request URI, and message body
> as per the event notification draft [2]
> 
> If this behaviour is allowed, it also opens the door
> for other questions that have not been addressed:
> 
> Q.How would a subscription terminate ?
> A.When its associated call leg dies due to BYE ?
> A. Wen it receives a SUBSCRIBE with expires = 0 ?
> etc.
> 
> Is there a reason that we cannot replace the 'discouraged'
> at the end of  [1] with a "NOT ALLOWED" ?
> 
> Any thoughts would be apreciated,
> 
> Francois Lessing
> Trillium Digital Systems, an Intel company.
> 
> 
> References:
> 
> [1] SIP-Specific Event Notification, Section 5.1.1:
> "The relationship between subscriptions and (INVITE-initiated)
>  sessions sharing the same call leg identification information is
>  undefined. Re-using call leg information for subscriptions is
>  discouraged."
> 
> 
> [2] SIP-Specific Event Notification, Section 5.1.1:
> Identification of events is provided by three pieces of
> information: Request URI, Event Type, and (optionally)
> message body.
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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


From bstucker@nortelnetworks.com  Mon Oct 15 18:46:31 2001
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 SAA02821
	for ; Mon, 15 Oct 2001 18:46:31 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id RAA14135
	for ; Mon, 15 Oct 2001 17:46:14 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Mon, 15 Oct 2001 17:39:32 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Mon, 15 Oct 2001 17:45:43 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E6A0592@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Jonathan Rosenberg ,
        "'Lessing, Francois'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY
Date: Mon, 15 Oct 2001 17:45:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C155CB.1C153B00"
X-Orig: 
Content-Length: 11656
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: 

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_01C155CB.1C153B00
Content-Type: text/plain;
	charset="iso-8859-1"

What about tag matching from forking interactions? I figured that the
requirement to keep in the same call leg was simply put there to help out
with tag matching.

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Saturday, October 13, 2001 9:29 AM
To: 'Lessing, Francois'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY



We have debated this before, with the general conclusion that a SUBSCRIBE
within a call leg should behave no differently than one outside of the leg.
The fact that its already within a leg simply means that the route sets and
CSeq are established, rather than needing to have been established by an
initial INVITE. The fact that its in a call leg would change nothing about
identifying whats being subscribed to.

I see no particular benefit to placing a subscription within a call leg
(although I do see benefit in using the route headers from an existing call
leg), but I see no strong reason to forbid it.

-Jonathan R.
 

> -----Original Message-----
> From: Lessing, Francois [mailto:francoisx.lessing@intel.com]
> Sent: Monday, October 08, 2001 8:35 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY
> 
> 
> Hi everyone,
> 
> The event notification drafts 'discourages' re-use of
> call leg information [1] (see quote from draft at end of mail)
> 
> Does this mean we sometimes allow a SUBSCRIBE
> request on an existing  call leg created by INVITE ?
> 
> To me this would not make sense, it seems to
> go against the broader intention of the draft.
> 
> The only reason I can think where this might be
> useful, is to SUBSCRIBE to a resource that is
> associated with an existing call leg.
> 
> But, an event is only allowed to be identified
> by event type, Request URI, and message body
> as per the event notification draft [2]
> 
> If this behaviour is allowed, it also opens the door
> for other questions that have not been addressed:
> 
> Q.How would a subscription terminate ?
> A.When its associated call leg dies due to BYE ?
> A. Wen it receives a SUBSCRIBE with expires = 0 ?
> etc.
> 
> Is there a reason that we cannot replace the 'discouraged'
> at the end of  [1] with a "NOT ALLOWED" ?
> 
> Any thoughts would be apreciated,
> 
> Francois Lessing
> Trillium Digital Systems, an Intel company.
> 
> 
> References:
> 
> [1] SIP-Specific Event Notification, Section 5.1.1:
> "The relationship between subscriptions and (INVITE-initiated)
>  sessions sharing the same call leg identification information is
>  undefined. Re-using call leg information for subscriptions is
>  discouraged."
> 
> 
> [2] SIP-Specific Event Notification, Section 5.1.1:
> Identification of events is provided by three pieces of
> information: Request URI, Event Type, and (optionally)
> message body.
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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

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

------_=_NextPart_001_01C155CB.1C153B00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Re-use of Call leg information in =
SUBCRIBE-NOTIFY




What about tag matching from forking interactions? I =
figured that the requirement to keep in the same call leg was simply =
put there to help out with tag matching.



Brian




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Saturday, October 13, 2001 9:29 AM

To: 'Lessing, Francois'; =
simple@mailman.dynamicsoft.com

Subject: RE: [Simple] Re-use of Call leg information =
in SUBCRIBE-NOTIFY








We have debated this before, with the general =
conclusion that a SUBSCRIBE

within a call leg should behave no differently than =
one outside of the leg.

The fact that its already within a leg simply means =
that the route sets and

CSeq are established, rather than needing to have =
been established by an

initial INVITE. The fact that its in a call leg =
would change nothing about

identifying whats being subscribed to.




I see no particular benefit to placing a subscription =
within a call leg

(although I do see benefit in using the route =
headers from an existing call

leg), but I see no strong reason to forbid =
it.




-Jonathan R.

 




> -----Original Message-----

> From: Lessing, Francois [mailto:francoisx.lessing@int=
el.com]

> Sent: Monday, October 08, 2001 8:35 PM

> To: simple@mailman.dynamicsoft.com

> Subject: [Simple] Re-use of Call leg =
information in SUBCRIBE-NOTIFY

> 

> 

> Hi everyone,

> 

> The event notification drafts 'discourages' =
re-use of

> call leg information [1] (see quote from draft =
at end of mail)

> 

> Does this mean we sometimes allow a =
SUBSCRIBE

> request on an existing  call leg created =
by INVITE ?

> 

> To me this would not make sense, it seems =
to

> go against the broader intention of the =
draft.

> 

> The only reason I can think where this might =
be

> useful, is to SUBSCRIBE to a resource that =
is

> associated with an existing call leg.

> 

> But, an event is only allowed to be =
identified

> by event type, Request URI, and message =
body

> as per the event notification draft [2]

> 

> If this behaviour is allowed, it also opens the =
door

> for other questions that have not been =
addressed:

> 

> Q.How would a subscription terminate ?

> A.When its associated call leg dies due to BYE =
?

> A. Wen it receives a SUBSCRIBE with expires =3D =
0 ?

> etc.

> 

> Is there a reason that we cannot replace the =
'discouraged'

> at the end of  [1] with a "NOT =
ALLOWED" ?

> 

> Any thoughts would be apreciated,

> 

> Francois Lessing

> Trillium Digital Systems, an Intel =
company.

> 

> 

> References:

> 

> [1] SIP-Specific Event Notification, Section =
5.1.1:

> "The relationship between subscriptions =
and (INVITE-initiated)

>  sessions sharing the same call leg =
identification information is

>  undefined. Re-using call leg information =
for subscriptions is

>  discouraged."

> 

> 

> [2] SIP-Specific Event Notification, Section =
5.1.1:

> Identification of events is provided by three =
pieces of

> information: Request URI, Event Type, and =
(optionally)

> message body.

> 

> 

> =
_______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple=


> 




---

Jonathan D. Rosenberg, =
Ph.D.           &=
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_01C155CB.1C153B00--

From lachlan.brazier@siemens.at  Tue Oct 16 03:49:53 2001
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 DAA04443
	for ; Tue, 16 Oct 2001 03:49:51 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id f9G7nZT14811
	for ; Tue, 16 Oct 2001 09:49:35 +0200
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id JAA19041
	for ; Tue, 16 Oct 2001 09:49:34 +0200 (MET DST)
Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta)
	id xma018009; Tue, 16 Oct 01 09:48:40 +0200
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <47HVV7XF>; Tue, 16 Oct 2001 09:48:30 +0200
Message-ID: 
From: Brazier Lachlan 
To: simple@mailman.dynamicsoft.com
Date: Tue, 16 Oct 2001 09:48:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 484
Subject: [Simple] Contact header in MESSAGE 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: 

Hello,
 
I've been reading draft-ietf-simple-im-01, and at the end I read Appendix A.
Requirements Evaluation.
 
   "Requirement 4.1.3. The common message format MUST include a return
      address for the receiver to reply to the sender with another
      INSTANT MESSAGE." This is done through the Contact headers
      defined in SIP. 
 
Does this mean that the Contact header is mandatory in an MESSAGE request?
It's not according to the table of header fields.
 
Thanks
Lachlan 

From jdrosen@dynamicsoft.com  Thu Oct 18 09:55:44 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14146
	for ; Thu, 18 Oct 2001 09:55:44 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9IDsM8P025265
	for ; Thu, 18 Oct 2001 09:54:22 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <495WQNV6>; Thu, 18 Oct 2001 09:55:32 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Thu, 18 Oct 2001 09:55:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 353
Subject: [Simple] test - please ignore
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 


---
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
 

From MLipfo01@sprintspectrum.com  Fri Oct 19 18:02:24 2001
Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19867
	for ; Fri, 19 Oct 2001 18:02:24 -0400 (EDT)
Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139])
	by smtpgw5.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id f9JM27e06882
	for ; Fri, 19 Oct 2001 17:02:07 -0500 (CDT)
Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2654.89)
	id <4YT3KDKJ>; Fri, 19 Oct 2001 17:02:07 -0500
Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7B66@pkcexv018.sprintspectrum.com>
From: "Lipford, Mark" 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Fri, 19 Oct 2001 17:02:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 486
Subject: [Simple] Question on status of the work
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 

I have just joined the group and I've been trying to determine the status of
your I-D's.  We are interested in the possible use of SIP for instant
messaging and need feedback on what the timeframe for RFC status of this
work may be.

Any feedback is appreciated.

Thanks,

Mark A. Lipford
Sprint PCS
Manager, Wireless Industry Standards - Data Technology
15405 College Blvd.
Mailstop: KSLNXZ0201-2148
Lenexa, KS  66219

(913) 890+4248 (office)
(913) 890-4291 (fax)
(913) 226-9060 (PCS)

From ndeason@ubiquity.net  Wed Oct 24 09:58:24 2001
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged))
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA00250
	for ; Wed, 24 Oct 2001 09:58:20 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for [63.113.40.50]) with SMTP; 24 Oct 2001 13:58:06 UT
Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600);
	 Wed, 24 Oct 2001 11:54:16 +0100
From: "Neil Deason" 
To: "Jonathan Rosenberg" ,
        "Brian Stucker" ,
        "Brazier Lachlan" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Wed, 24 Oct 2001 11:54:15 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: 
X-OriginalArrivalTime: 24 Oct 2001 10:54:16.0144 (UTC) FILETIME=[395FF500:01C15C7A]
Content-Length: 5440
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: 

I would agree with this. The usage of a 403 needs to
be clear that it doesn't mean the SUBSCRIBE should
never be repeated as that may not be obvious from
the HTTP inherited meaning.

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 24 October 2001 01:45
> To: Brian Stucker; Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg';
> ''SIMPLE Mailinglist' '
> Subject: RE: [Simple] Multiple 200 Ok
>
>
> Another old issue that I want to make sure is closed.
>
> Let me summarize the discussion. The question was this: if a PA gets a
> request, and the request-uri matches that of a user that the
> PA represents,
> but the To field doesn't, what do you do? The conclusion of
> this thread is
> that it is up to the policy of the PA as to whether it
> accepts subscriptions
> that were originally targeted at a different UA (which is
> what it means when
> the r-uri and to field don't identify the same user). This is
> not presence
> specific at all, as this happens with sip in general when requests are
> forwarded. The only question was this: what response code to
> use in this
> case?
>
> I believe 403 is correct; it does not imply that the
> subscription can never
> be retried, just that right now, retrying it against this PA
> won't help any
> more.
>
> Furthermore, this is not presence specific, and belongs in SIP itself.
> bis-05 actually has a subsection on UAS processing which
> describes how a uas
> determines if it should process a request. The section
> provides response
> codes to use in specific cases, and this case, and the 403, will be
> described there. I will also mention this case in the presence spec.
>
> -Jonathan R.
>
>
>
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> -----Original Message-----
> From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
> Sent: Friday, October 05, 2001 11:10 AM
> To: Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg'; ''SIMPLE
> Mailinglist' '
> Subject: RE: [Simple] Multiple 200 Ok
>
>
> Would it be a 403 forbidden? If a 403 were sent back because the
> only routable PA wasn't willing to process the subscription, wouldn't
> this cause the would-be watcher to not try again later when other
> PA's may be available (via forking) that could process the request?
> I would think a 404 or a 488 response would be a better fit.
> ...
> When is that new events draft going to appear? Until that comes out
> the NOTIFY with expires = 0 is the way you force-expire a
> subscription.
> Regards,
> Brian
> -----Original Message-----
> From: Neil Deason [mailto:ndeason@ubiquity.net]
> Sent: Friday, October 05, 2001 9:52 AM
> To: Brazier Lachlan; 'Jonathan Rosenberg'; Stucker, Brian
> [NGB:B621:EXCH]; ''SIMPLE Mailinglist' '
> Subject: RE: [Simple] Multiple 200 Ok
>
>
> > -----Original Message-----
> > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> >
> > Hi,
> >
> > generally I agree with you about Authorisation and Authentication.
> >
> > Let me reformulate the question. Which response do I send
> back, when I
> > received a SUBSCRIBE, and I'm not allowed or not willing to be the
> > presentity (This can happen if someone defines me as
> > presentity without
> > letting me know - as the way of authorization is not in the
> > scope of the
> > presence draft, errors might happen)?
> 403 would do.
> > I have a question concerning the Call flows in the draft.
> > When a PA receives a SUBSCRIBE with an Expires header, the
> > response contains
> > an Expires header as well. What would an Expires header in a
> > NOTIFY request
> > sent from the PA to the Watcher mean? Would this update the
> > subscription
> > expiration time?
> >
> > An example:
> > userA subscribes for user userB. As userB is a friend of
> > userA, he accepts
> > the subscription and the call flows just get on.
> > After some time userB doesn't want to be the presentity of
> > userA anymore, or
> > maybe userB changes the contact information for the SUBSCRIBE
> > request at
> > it's registrar.
> > Now, can userB (better said the PA of userB) send a NOTIFY
> > with an Expires
> > header with value 0 to tell userA, that it's subscription
> > expiration time is
> > over?
> >
> > I think it should be possible to do so, because if not, userB
> > would need to
> > wait for the next SUBSCRIBE request from userA, before he can
> > tell him, that
> > the subscription time is over. This could be a time value
> > from seconds to
> > days, month, years, etc.
> >
> >
> > If there is another mechanism to do so, which one would it
> be? Maybe a
> > NOTIFY with an empty body?
> There current proposal is to use a new header,
> Subscription-Expires in NOTIFY instead of overloading
> Expires to indicate when a subscription will end.
> draft-ietf-simple-presence-03.txt refers to this in
> describing how PA functionality migrates (5.12). This
> header still needs to be detailed in a revised 'SIP
> specific event notification' draft.
> Cheers,
> Neil.
> --
> Ubiquity Software Corporation, UK        http://www.ubiquity.net


From jdrosen@dynamicsoft.com  Wed Oct 24 10:07:35 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00297
	for ; Wed, 24 Oct 2001 10:07:35 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9O0iQPI014277;
	Tue, 23 Oct 2001 20:44:29 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Oct 2001 20:45:38 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: sal , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] notify after terminating subscription
Date: Tue, 23 Oct 2001 20:45:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1375
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: 

The reason that a NOTIFY is still sent is that we want the behavior of
SUBSCRIBE to be consistent; a 200 OK response to SUBSCRIBE always generates
a NOTIFY, independent of the duration of the subscription. This allows a
single primitive to be used for fetch, terminating a subscription, creating
one, and refreshing one. 

-Jonathan R.

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

> -----Original Message-----
> From: sal [mailto:salvatore.loreto@libero.it]
> Sent: Tuesday, October 09, 2001 4:55 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] notify after terminating subscription
> 
> 
> Hi,
> 
> i'm looking, on the presence's draft,
> the flow messages "Client to Client Subscription
>  with Presentity State Change"
> 
> why when the watcher terminating the subscription
> it receive after a 200OK also an other NOTIFY from
> that presentity?
> i don't understood ... 
> 
> thanks
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jdrosen@dynamicsoft.com  Wed Oct 24 10:07:36 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00303
	for ; Wed, 24 Oct 2001 10:07:36 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9O0iQPI014276;
	Tue, 23 Oct 2001 20:44:26 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Oct 2001 20:45:38 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Brian Stucker ,
        Jonathan Rosenberg
	 ,
        Brazier Lachlan ,
        Jonathan Rosenberg ,
        "''Neil Deason' '"
	 ,
        "''SIMPLE Mailinglist' '"
	 
Subject: RE: [Simple] Multiple 200 Ok
Date: Tue, 23 Oct 2001 20:45:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1866
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: 

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

Response inline.

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


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

I agree that Contact is far from ideal.

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

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

-Jonathan R.


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


From jdrosen@dynamicsoft.com  Wed Oct 24 10:07:36 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00299
	for ; Wed, 24 Oct 2001 10:07:35 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9O0iFPI014256;
	Tue, 23 Oct 2001 20:44:16 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Oct 2001 20:45:28 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "Moran Tim (NET/Dallas)" ,
        "'ext Paul Kyzivat'"
	 ,
        Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] 200 vs. 202
Date: Tue, 23 Oct 2001 20:45:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1761
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: 


  
-----Original Message-----
From: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com]
Sent: Friday, October 05, 2001 11:33 AM
To: 'ext Paul Kyzivat'; Jonathan Rosenberg
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] 200 vs. 202
>
>While 5.7 paragraph 6 indicates that the Notifier can send whatever, the
first paragraph 
>of 5.10 states "Each of these [PA] will respond with a 202 response to the
SUBSCRIBE."  
>The later does not imply whatever can be sent..

You are looking at an older version of the specification. This was true in
-02. -03 has a 2xx where 202 appears, and has thus fixed this problem you
have found.


>
>Given your comments are correct, then I would suggest changing the 1st
paragraph of 5.10 
>so as not to restrict what can be sent by the PA (After all - can the
Notifier (PA) even 
>tell it is a 5.7 subscribe vs. a 5.10 (forked) subscribe?). On a side note,
the doc uses 
>Notifier for section titles wherein the text uses e.g. PA. Is this
semantically correct? 
>Are we really intending to talk about PA Notifiers vs. other type of
Notifiers? Don't 
>mean to be picky but I'm not sure if this is intentional, and thus adds
explicit meaning, 
>or just loose use of terminology.

The section titles follow the section titles in sip-events. A Notifier = PA;
that is, a PA is a notifier for the presence package. I will state this in
the terminology section.

-Jonathan R.

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

From jdrosen@dynamicsoft.com  Wed Oct 24 10:07:36 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00307
	for ; Wed, 24 Oct 2001 10:07:36 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9O0iQPI014278;
	Tue, 23 Oct 2001 20:44:26 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Oct 2001 20:45:38 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Brian Stucker ,
        Neil Deason
	 ,
        Brazier Lachlan ,
        "'Jonathan Rosenberg'" ,
        "''SIMPLE Mailinglist' '"
	 
Subject: RE: [Simple] Multiple 200 Ok
Date: Tue, 23 Oct 2001 20:45:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4733
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: 

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

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

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

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

-Jonathan R.



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


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


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

From jdrosen@dynamicsoft.com  Wed Oct 24 10:07:40 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00320
	for ; Wed, 24 Oct 2001 10:07:40 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N1CgPI007264;
	Mon, 22 Oct 2001 21:12:42 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <495WQY4A>; Mon, 22 Oct 2001 21:13:54 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] IM format
Date: Mon, 22 Oct 2001 21:13:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1421
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: 


 

> -----Original Message-----
> From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> Sent: Friday, October 12, 2001 1:51 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] IM format
> 
> 
> Hi,
> 
> Message and thread identification is essential for 
> session based IM format as described in 
> "Group Messaging in SIP" draft.
> 
> Thread identification is not very useful in two-party chat,
> but in multi-party chat (and some non-chat applicatios)
> it is a necessity.
>
> Thread-id header itself is not needed. 
> Instead, thread identification can be achieved 
> with Message-id and References headers.
> It allows also nested threads.

Sounds like good reasons not to try and do multiparty chat with the paging
model. We have spent much time on getting multiparty communications working
with SIP. Using session model allows all of that to be reused. If you want
to support multiparty chats in page model, you will be reinventing a
completely new and orthogonal mechanisms for much the same thing. I think
that this is a bad thing.

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

From jdrosen@dynamicsoft.com  Wed Oct 24 10:07:41 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00324
	for ; Wed, 24 Oct 2001 10:07:40 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N1CePI007252;
	Mon, 22 Oct 2001 21:12:53 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <495WQYT8>; Mon, 22 Oct 2001 21:13:52 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Brazier Lachlan ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Contact header in MESSAGE request
Date: Mon, 22 Oct 2001 21:13:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2994
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: 


 

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Tuesday, October 16, 2001 3:48 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Contact header in MESSAGE request
> 
> 
> Hello,
>  
> I've been reading draft-ietf-simple-im-01, and at the end I 
> read Appendix A.
> Requirements Evaluation.
>  
>    "Requirement 4.1.3. The common message format MUST include a return
>       address for the receiver to reply to the sender with another
>       INSTANT MESSAGE." This is done through the Contact headers
>       defined in SIP. 
>  
> Does this mean that the Contact header is mandatory in an 
> MESSAGE request?
> It's not according to the table of header fields.

This is something that has changed a bit as the session model has evolved
into a separate entity. The initial model was that MESSAGE itself set up a
session, but this was discarded as we didn't want multiple ways to establish
an interaction communicastions session, and certainly voice/video could be
part of that. In this initial model, since MESSAGE was like INVITE, it had a
Contact header that was used for sending subsequent messages within the
session. 

Then, with the paging model, MESSAGE became a "one-shot" kind of thing.
There is no session or context for the messages. Since Contact is meant to
provide an endpoint address, its not very useful for paging mode. In these
cases, you can't really provide a a host address, since these things change,
and the duration during which that address would remain useful is unknown.
Providing a direct host address is only useful where there is a session, and
we can change it if the host moves (SIP provides this ability). So, Contact
doesn't make sense anymore. Thats why its not in the table.

However, one might want to provide a reply address that isn't a host IP or
hostname. Rather, we want to provide a logical address to send messages in
reply. Normally, the From is used for this kind of thing, but certainly the
address for sending a response could be something else.

Right now, there is no Reply-To header in SIP. It would be a useful thing to
have, as it makes sense for initiating calls as well (If I call you, and
you're not there, I can provide a logical address to use to call me back at
any point later on). In fact, this is a current open issue in the bis
specification itself (whether or not to add a Reply-To address). Oddly, bis
does have an In-Reply-To header that identifies the specific call that a new
call is in reply to.

Since we have multiple cases where it is needed, sounds like its something
that should be added.

-Jonathan R.

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

From jdrosen@dynamicsoft.com  Wed Oct 24 10:07:41 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00330
	for ; Wed, 24 Oct 2001 10:07:41 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N1CePI007253;
	Mon, 22 Oct 2001 21:12:40 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <495WQYT7>; Mon, 22 Oct 2001 21:13:52 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Brian Stucker ,
        Jonathan Rosenberg
	 ,
        "'Lessing, Francois'"
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY
Date: Mon, 22 Oct 2001 21:13:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4597
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: 

I'm not sure I know what you mean by this. 

If you want to subscribe to some state associated with a call leg, then the
subscribe has to identify that call leg. This identification should be
explicit (i.e., carried somewhere in the subscription), rather than implicit
based on the fact that it arrived on a particular call leg.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Monday, October 15, 2001 6:46 PM
To: Jonathan Rosenberg; 'Lessing, Francois'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY


What about tag matching from forking interactions? I figured that the
requirement to keep in the same call leg was simply put there to help out
with tag matching.
Brian 
-----Original Message----- 
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent: Saturday, October 13, 2001 9:29 AM 
To: 'Lessing, Francois'; simple@mailman.dynamicsoft.com 
Subject: RE: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY 



We have debated this before, with the general conclusion that a SUBSCRIBE 
within a call leg should behave no differently than one outside of the leg. 
The fact that its already within a leg simply means that the route sets and 
CSeq are established, rather than needing to have been established by an 
initial INVITE. The fact that its in a call leg would change nothing about 
identifying whats being subscribed to. 
I see no particular benefit to placing a subscription within a call leg 
(although I do see benefit in using the route headers from an existing call 
leg), but I see no strong reason to forbid it. 
-Jonathan R. 
  
> -----Original Message----- 
> From: Lessing, Francois [mailto:francoisx.lessing@intel.com] 
> Sent: Monday, October 08, 2001 8:35 PM 
> To: simple@mailman.dynamicsoft.com 
> Subject: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY 
> 
> 
> Hi everyone, 
> 
> The event notification drafts 'discourages' re-use of 
> call leg information [1] (see quote from draft at end of mail) 
> 
> Does this mean we sometimes allow a SUBSCRIBE 
> request on an existing  call leg created by INVITE ? 
> 
> To me this would not make sense, it seems to 
> go against the broader intention of the draft. 
> 
> The only reason I can think where this might be 
> useful, is to SUBSCRIBE to a resource that is 
> associated with an existing call leg. 
> 
> But, an event is only allowed to be identified 
> by event type, Request URI, and message body 
> as per the event notification draft [2] 
> 
> If this behaviour is allowed, it also opens the door 
> for other questions that have not been addressed: 
> 
> Q.How would a subscription terminate ? 
> A.When its associated call leg dies due to BYE ? 
> A. Wen it receives a SUBSCRIBE with expires = 0 ? 
> etc. 
> 
> Is there a reason that we cannot replace the 'discouraged' 
> at the end of  [1] with a "NOT ALLOWED" ? 
> 
> Any thoughts would be apreciated, 
> 
> Francois Lessing 
> Trillium Digital Systems, an Intel company. 
> 
> 
> References: 
> 
> [1] SIP-Specific Event Notification, Section 5.1.1: 
> "The relationship between subscriptions and (INVITE-initiated) 
>  sessions sharing the same call leg identification information is 
>  undefined. Re-using call leg information for subscriptions is 
>  discouraged." 
> 
> 
> [2] SIP-Specific Event Notification, Section 5.1.1: 
> Identification of events is provided by three pieces of 
> information: Request URI, Event Type, and (optionally) 
> message body. 
> 
> 
> _______________________________________________ 
> simple mailing list 
> simple@mailman.dynamicsoft.com 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple 
> 
--- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave. 
Chief Scientist                             First Floor 
dynamicsoft                                 East Hanover, NJ 07936 
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050 
http://www.jdrosen.net                      PHONE: (973) 952-5000 
http://www.dynamicsoft.com 
_______________________________________________ 
simple mailing list 
simple@mailman.dynamicsoft.com 
http://mailman.dynamicsoft.com/mailman/listinfo/simple 

From jdrosen@dynamicsoft.com  Wed Oct 24 10:07:40 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00315;
	Wed, 24 Oct 2001 10:07:37 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N2m3PI007488;
	Mon, 22 Oct 2001 22:48:03 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <495WQYX2>; Mon, 22 Oct 2001 22:49:16 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'gur@vocaltec.com'" ,
        Paul Kyzivat
	 
Cc: Avshalom@ubique.com, Ben Campbell ,
        "'Rosen, Brian'" ,
        Henning Schulzrinne
	 ,
        "'Christian Huitema'"
	 ,
        Jonathan Rosenberg
	 ,
        "Peterson, Jon" ,
        "Roy, Radhika R, ALCTA" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Vasilis Polychronidis
	 
Subject: RE: [Simple] IM over the signaling connection
Date: Mon, 22 Oct 2001 22:49:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 4237
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: 

One thing I do want to note.... I think that whatever we do for thread IDs,
in-reply-to's or whatever should not hold up the basic paging model. All of
those things are primarily needed to facilitate integration with a session
model, and therefore we should worry about those things later. Lets get the
basic paging model done. 

-Jonathan R.

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

> -----Original Message-----
> From: gur@vocaltec.com [mailto:gur@vocaltec.com]
> Sent: Thursday, October 11, 2001 8:53 PM
> To: Paul Kyzivat
> Cc: Avshalom@ubique.com; Ben Campbell; 'Rosen, Brian'; Henning
> Schulzrinne; 'Christian Huitema'; Jonathan Rosenberg; Peterson, Jon;
> Roy, Radhika R, ALCTA; simple@mailman.dynamicsoft.com;
> simple-admin@mailman.dynamicsoft.com; Vasilis Polychronidis
> Subject: Re: [Simple] IM over the signaling connection
> 
> 
> Paul -
> 
> not having the Session-ID and only relaying on the  has
> some increased statfullness requirements on proxies - and again, my
> original
> point that while we --hope-- many IM sessions will be end2end, in
> reality many inter-domain IM sessions will traverse some DMZ
> IM or SIP proxy that will provide authentication and authorization -
> domain policy ("this user is blacklisted", "translate between 
> English and
> French")
> should be done when entering the network, not by the UA.
> 
> And of course if the proxy is no longer needed it can replace 
> the u2p2u
> session
> with an u2u one - another advantage of using standard SIP setup for IM
> sessions.
> 
> Also - I believe messages, regardless if sent using pages or 
> in sessions,
> should be associated with a "thread-of-messages ID" - this 
> makes for a much
> cleaner design - not needed in every case mind you, but in many
> person2person
> scenarios.  Also this provides a stateless way for both UAs 
> and Proxies
> to continue past sessions - just choosing some arbitrary time 
> for a session
> to expire -because the transport closed- or -some timer fired- is less
> then optimal.  I may, as a user, as I do many times, continue a
> conversation
> I finished last night - and it should contextually be the 
> same "thread" -
> while clearly the transport will be replaced and a new 
> session created.
> 
> so while I am not objecting to an additional optional 
>  header,
> I dont think it replaced .
> 
> - gur
> 
> > Paul Kyzivat Wrote:
> >
> > In addition to  and , it would be 
> useful to have
> > an  header, so that proper message ordering can be
> > achieved. In theory the  is sufficient to 
> define a thread,
> > but in practice it probably isn't, so having both is useful.
> >
> > On the other hand, having  might encourage abuse 
> of paging
> > mode by providing another way to implement sessions. Just having
> >  and  would be sufficient to tie a 
> new session
> > to a preceding page mode message.
> >
> >
> >> Gur_Kimchi@vocaltec.com wrote:
> >>
> >> Providing messages with two optional headers:  and
> 
> >> allows the sender to choose to
> >>
> >> (1) provide message identification for later processing 
> (if this is not
> >> clear then imagine some message indexing at the server to 
> allow message
> >> access by non-SIP elements, like web-browsers via an App 
> Server, WAP
> etc)
> >>
> >> and
> >>
> >> (2) to associate a specific message with a 
> thread-of-messages - this way
> >> if a message arrives using page mode, and a later session 
> is established
> >> and a new message arrives with the same Thread-ID, the UA 
> knows it is
> part
> >> of the same session - this also allows muxing multiple 
> threads within a
> >> session without any transport muxing.
> >>
> >> (of course both IDs are generated by the originating UA, 
> the two headers
> >> should
> >> be optional - many apps do not need them).
> 

From jdrosen@dynamicsoft.com  Wed Oct 24 10:07:42 2001
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00339;
	Wed, 24 Oct 2001 10:07:42 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N1CiPI007267;
	Mon, 22 Oct 2001 21:12:44 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <495WQY4B>; Mon, 22 Oct 2001 21:13:56 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Paul Kyzivat , Gur_Kimchi@vocaltec.com
Cc: Jonathan Rosenberg , Avshalom@ubique.com,
        Ben Campbell ,
        "'Rosen, Brian'"
	 ,
        Henning Schulzrinne ,
        "'Christian Huitema'" ,
        "Peterson, Jon"
	 ,
        "Roy, Radhika R, ALCTA" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Vasilis Polychronidis 
Subject: RE: [Simple] IM over the signaling connection
Date: Mon, 22 Oct 2001 21:13:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1482
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: 



> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, October 11, 2001 7:29 PM
> To: Gur_Kimchi@vocaltec.com
> Cc: Jonathan Rosenberg; Avshalom@ubique.com; Ben Campbell; 'Rosen,
> Brian'; Henning Schulzrinne; 'Christian Huitema'; Peterson, Jon; Roy,
> Radhika R, ALCTA; simple@mailman.dynamicsoft.com;
> simple-admin@mailman.dynamicsoft.com; Vasilis Polychronidis
> Subject: Re: [Simple] IM over the signaling connection
> 
> 
> In addition to  and , it would be 
> useful to have
> an  header, so that proper message ordering can be
> achieved. In theory the  is sufficient to define 
> a thread,
> but in practice it probably isn't, so having both is useful.

SIP actually has an In-Reply-To, which lists the call-id of the message that
this request is "replying" to. Effectively, this means that the call-id acts
as our message ID in the paging model. Based on the sip definition, call-id
is globally unqiue for each request outside of a call-leg. Since paging mode
doesn't set up a leg, this has the desired property.

-Jonathan R.

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

From bstucker@nortelnetworks.com  Wed Oct 24 10:30:06 2001
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00761
	for ; Wed, 24 Oct 2001 10:30:06 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA01927
	for ; Wed, 24 Oct 2001 09:29:44 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 24 Oct 2001 09:22:54 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 24 Oct 2001 09:29:00 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E880613@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Jonathan Rosenberg ,
        Neil Deason ,
        Brazier Lachlan ,
        "'Jonathan Rosenberg'" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Wed, 24 Oct 2001 09:28:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15C98.37E56750"
X-Orig: 
Content-Length: 15249
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: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15C98.37E56750
Content-Type: text/plain;
	charset="iso-8859-1"

That'll work.

Thanks.

Brian

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


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

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

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

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

-Jonathan R.



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


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


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

------_=_NextPart_001_01C15C98.37E56750
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Multiple 200 Ok




That'll work.




Thanks.




Brian




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Tuesday, October 23, 2001 7:45 PM

To: Stucker, Brian [NGB:B621:EXCH]; Neil Deason; =
Brazier Lachlan;

'Jonathan Rosenberg'; ''SIMPLE Mailinglist' '

Subject: RE: [Simple] Multiple 200 Ok






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




Let me summarize the discussion. The question was =
this: if a PA gets a

request, and the request-uri matches that of a user =
that the PA represents,

but the To field doesn't, what do you do? The =
conclusion of this thread is

that it is up to the policy of the PA as to whether =
it accepts subscriptions

that were originally targeted at a different UA =
(which is what it means when

the r-uri and to field don't identify the same =
user). This is not presence

specific at all, as this happens with sip in general =
when requests are

forwarded. The only question was this: what response =
code to use in this

case?




I believe 403 is correct; it does not imply that the =
subscription can never

be retried, just that right now, retrying it against =
this PA won't help any

more.




Furthermore, this is not presence specific, and =
belongs in SIP itself.

bis-05 actually has a subsection on UAS processing =
which describes how a uas

determines if it should process a request. The =
section provides response

codes to use in specific cases, and this case, and =
the 403, will be

described there. I will also mention this case in =
the presence spec.




-Jonathan R.








---

Jonathan D. Rosenberg, =
Ph.D.           &=
nbsp;    72 Eagle Rock Ave.

Chief =
Scientist          &nb=
sp;           &nb=
sp;      First Floor

dynamicsoft        &nbs=
p;           &nbs=
p;            =
East Hanover, NJ 07936

jdrosen@dynamicsoft.com      &nbs=
p;           &nbs=
p;  FAX:   (973) 952-5050

http://www.jdrosen.net    &nbs=
p;           &nbs=
p;     PHONE: (973) 952-5000

http://www.dynamicsoft.com

  

-----Original Message-----

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

Sent: Friday, October 05, 2001 11:10 AM

To: Neil Deason; Brazier Lachlan; 'Jonathan =
Rosenberg'; ''SIMPLE

Mailinglist' '

Subject: RE: [Simple] Multiple 200 Ok






Would it be a 403 forbidden? If a 403 were sent back =
because the 

only routable PA wasn't willing to process the =
subscription, wouldn't 

this cause the would-be watcher to not try again =
later when other 

PA's may be available (via forking) that could =
process the request? 

I would think a 404 or a 488 response would be a =
better fit. 

... 

When is that new events draft going to appear? Until =
that comes out 

the NOTIFY with expires =3D 0 is the way you =
force-expire a subscription. 

Regards, 

Brian 

-----Original Message----- 

From: Neil Deason [mailto:ndeason@ubiquity.net] =


Sent: Friday, October 05, 2001 9:52 AM 

To: Brazier Lachlan; 'Jonathan Rosenberg'; Stucker, =
Brian 

[NGB:B621:EXCH]; ''SIMPLE Mailinglist' ' 

Subject: RE: [Simple] Multiple 200 Ok 






> -----Original Message----- 

> From: Brazier Lachlan [mailto:lachlan.brazier@siemen=
s.at] 

> 

> Hi, 

> 

> generally I agree with you about Authorisation =
and Authentication. 

> 

> Let me reformulate the question. Which response =
do I send back, when I 

> received a SUBSCRIBE, and I'm not allowed or =
not willing to be the 

> presentity (This can happen if someone defines =
me as 

> presentity without 

> letting me know - as the way of authorization =
is not in the 

> scope of the 

> presence draft, errors might happen)? 

403 would do. 

> I have a question concerning the Call flows in =
the draft. 

> When a PA receives a SUBSCRIBE with an Expires =
header, the 

> response contains 

> an Expires header as well. What would an =
Expires header in a 

> NOTIFY request 

> sent from the PA to the Watcher mean? Would =
this update the 

> subscription 

> expiration time? 

> 

> An example: 

> userA subscribes for user userB. As userB is a =
friend of 

> userA, he accepts 

> the subscription and the call flows just get =
on. 

> After some time userB doesn't want to be the =
presentity of 

> userA anymore, or 

> maybe userB changes the contact information for =
the SUBSCRIBE 

> request at 

> it's registrar. 

> Now, can userB (better said the PA of userB) =
send a NOTIFY 

> with an Expires 

> header with value 0 to tell userA, that it's =
subscription 

> expiration time is 

> over? 

> 

> I think it should be possible to do so, because =
if not, userB 

> would need to 

> wait for the next SUBSCRIBE request from userA, =
before he can 

> tell him, that 

> the subscription time is over. This could be a =
time value 

> from seconds to 

> days, month, years, etc. 

> 

> 

> If there is another mechanism to do so, which =
one would it be? Maybe a 

> NOTIFY with an empty body? 

There current proposal is to use a new header, =


Subscription-Expires in NOTIFY instead of =
overloading 

Expires to indicate when a subscription will end. =


draft-ietf-simple-presence-03.txt refers to this in =


describing how PA functionality migrates (5.12). =
This 

header still needs to be detailed in a revised 'SIP =


specific event notification' draft. 

Cheers, 

Neil. 

-- 

Ubiquity Software Corporation, =
UK        http://www.ubiquity.net 





------_=_NextPart_001_01C15C98.37E56750--

From bstucker@nortelnetworks.com  Wed Oct 24 10:31:43 2001
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00789
	for ; Wed, 24 Oct 2001 10:31:43 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA02628
	for ; Wed, 24 Oct 2001 09:31:21 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Wed, 24 Oct 2001 09:24:27 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 24 Oct 2001 09:30:34 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E88064F@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: "Brian Stucker" ,
        Brazier Lachlan ,
        "Moran Tim (NET/Dallas)" ,
        "adam.roach" ,
        James Undery ,
        "Ngo, Dai (c)" ,
        "'ext Paul Kyzivat'" ,
        Jonathan Rosenberg 
Cc: simple 
Subject: RE: [Simple] 200 vs. 202
Date: Wed, 24 Oct 2001 09:30:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15C98.6EC03840"
X-Orig: 
Content-Length: 7605
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: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15C98.6EC03840
Content-Type: text/plain;
	charset="iso-8859-1"

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

Thanks,

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


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

------_=_NextPart_001_01C15C98.6EC03840
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] 200 vs. 202




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

debate stand?




Thanks,




Brian Stucker

Nortel Networks

-----Original Message-----

From: Stucker, Brian [NGB:B621:EXCH] 

Sent: Tuesday, October 09, 2001 9:51 AM

To: Brazier Lachlan; Moran Tim (NET/Dallas); =
adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan =
Rosenberg



Cc: simple

Subject: RE: [Simple] 200 vs. 202






I think I'm seeing the light a bit more... The events =
draft does state that you need to 

be ready to get a NOTIFY before the SUBSCRIBE =
finished (due to dropped packets), so I guess 

the tag matching isn't so strict on the first =
NOTIFY, and not having the TO tag from the 

SUBSCRIBE response isn't considered to be a problem. =


The text that seems to be causing the confusion is =
in section 3: 

"...Once authorized, the presence agent sends a =
202 Accepted response. It also sends an 

immediate NOTIFY message containing the state of the =
presentity..." 

The -00 revision of the events draft (unless I'm =
missing it in my reading) says: 

5.1.7.1: 

"A 202 response indicates that there may be a =
sizable delay before a notification 

is received, pending the actual creation of the =
subscription." 

5.1.7.2: 

"...Upon successful creation or refreshing of a =
subscription, 

     notifiers MUST send a =
NOTIFY message as soon as practical to 

     communicate the current =
resource state to the subscriber...." 

"...If the response to the SUBSCRIBE message =
was 202, this initial 

     NOTIFY will serve as =
indication that the subscription has finally 

     been processed...." =


Having read it again, I think I now understand what =
Adam meant by a 3-way handshake, and it 

does exist in the -00 version of the draft. I think =
the wording in section 5.1.7.2 does not 

apply to a NOTIFY that is empty. An empty NOTIFY =
does not create a subscription (I think). 

If we look at it this way, then you can see the =
three-way handshake, and why the empty NOTIFY 

after a 202 is important after all (just realizing =
this). 

The SUBSCRIBE is the first leg of the handshake =
A->B, the 2xx/empty NOTIFY is the second leg of 

the handshake B->A, and the response to the empty =
NOTIFY is the third leg A->B. 

This makes a ton more sense (at least to me). The =
wording is a bit vague, but if you take the 

position that an empty NOTIFY signifies nothing =
regarding the subscription status, and that the 202 

response isn't telling the subscriber that there's =
going to be a delay before ANY NOTIFY is sent, but 

instead before a meaningful NOTIFY is sent, then =
this makes sense. 

There's even a blurb about getting a NOTIFY with =
expires=3D0 after a 202 is to be treated as a 603 decline 

by the subscriber. So I think this was the behaviour =
that was intended. 

Thoughts? 

Brian 





------_=_NextPart_001_01C15C98.6EC03840--

From sriramp@nortelnetworks.com  Wed Oct 24 11:46:45 2001
Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01115
	for ; Wed, 24 Oct 2001 11:46:44 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA03981
	for ; Wed, 24 Oct 2001 10:46:28 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Wed, 24 Oct 2001 10:44:12 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 24 Oct 2001 10:45:29 -0500
Message-ID: 
From: "Sriram Parameswar" 
To: "'Jonathan Rosenberg'" ,
        "Brian Stucker" ,
        Brazier Lachlan ,
        "''Neil Deason' '" ,
        "''SIMPLE Mailinglist' '" 
Subject: RE: [Simple] Multiple 200 Ok
Date: Wed, 24 Oct 2001 10:45:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C15CA2.E6938750"
Content-Length: 8599
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: 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C15CA2.E6938750
Content-Type: text/plain;
	charset="iso-8859-1"


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

Regards,

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


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


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

Response inline.

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


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

I agree that Contact is far from ideal.

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

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

-Jonathan R.


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

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

------_=_NextPart_001_01C15CA2.E6938750
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Multiple 200 Ok






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



Regards,




Sriram

__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-685-3563

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com






-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Tuesday, October 23, 2001 7:45 PM

To: Stucker, Brian [NGB:B621:EXCH]; Jonathan =
Rosenberg; Brazier Lachlan;

Jonathan Rosenberg; ''Neil Deason' '; ''SIMPLE =
Mailinglist' '

Subject: RE: [Simple] Multiple 200 Ok






Another old thread. The issue was how a subscriber =
knows the identity of the

actual PA which answered the SUBSCRIBE, since it may =
have been forwarded.




Response inline.




  

-----Original Message-----

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

Sent: Friday, October 05, 2001 11:02 AM

To: Jonathan Rosenberg; Brazier Lachlan; Jonathan =
Rosenberg; ''Neil Deason'

'; ''SIMPLE Mailinglist' '

Subject: RE: [Simple] Multiple 200 Ok






>I'm a bit worried about using the contact header =
in the 2xx as a means of 

>identifying the user that processed the =
SUBSCRIBE. The watcher has no

method 

>of determining the user's contact list to check =
the contact received 

>against. So I don't see a reliable method of =
taking a contact and

determining 

>the user that contact is for unless you're the =
registrar (and even then it 

>can be ambiguous). If you have a proxy that =
straddles a firewall, it will 

>probably modify the contact address in the 2xx =
response, so the contact

returned 

>may be one that only the proxy knows who it maps =
to, and nobody else. 




I agree that Contact is far from ideal.




Remote-Party-ID is really much better, since it =
provides a logical identity,

and thats exactly what you want.




I don't want to mandate the usage of R-PID for this, =
as it introduces a

dependency. So, I will simply indicate that the =
privacy spec can be used if

you want to provide the identity of the PA which =
actually answered. This

makes the reference non-normative and therefore =
there is no dependency.




-Jonathan R.






---

Jonathan D. Rosenberg, Ph.D.    &=
nbsp;           72 =
Eagle Rock Ave.

Chief =
Scientist          &nb=
sp;           &nb=
sp;      First Floor

dynamicsoft        &nbs=
p;           &nbs=
p;            =
East Hanover, NJ 07936

jdrosen@dynamicsoft.com      &nbs=
p;           &nbs=
p;  FAX:   (973) 952-5050

http://www.jdrosen.net    &nbs=
p;           &nbs=
p;     PHONE: (973) 952-5000

http://www.dynamicsoft.com




_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple=






------_=_NextPart_001_01C15CA2.E6938750--

From drage@lucent.com  Wed Oct 24 13:17:06 2001
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01478
	for ; Wed, 24 Oct 2001 13:17:05 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9OHGff02933
	for ; Wed, 24 Oct 2001 13:16:45 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21)
	id <4C4S1TG7>; Wed, 24 Oct 2001 18:16:33 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB001AC3418@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" 
To: Brazier Lachlan ,
        simple@mailman.dynamicsoft.com,
        "'Jonathan Rosenberg'"
	 
Subject: RE: [Simple] Contact header in MESSAGE request
Date: Wed, 24 Oct 2001 18:16:31 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4406
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: 

Jonathan states that there is no Reply-To header in SIP.

I would note that one of the forms of the Remote-Party-ID header (privacy
draft) is to provide an address for returning a call to, rather than this is
the address that made the call.

Current definition as follows:

   Return session identity (rpi-id-type="return")

     This identifies the point to which the party wishes return
     sessions to be addressed. For example a business may wish to
     provide a 'freephone' identity to encourage return calls. If
     absent, this is assumed to be the same as the subscriber identity.

From the discussion I have read, surely this would fulfil the function
rather than inventing a new header. It would of course mean extenting the
usage of the Remote-Party-ID to another method.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com

> ----------
> From: 	Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com]
> Sent: 	23 October 2001 2:13
> To: 	Brazier Lachlan; simple@mailman.dynamicsoft.com
> Subject: 	RE: [Simple] Contact header in MESSAGE request
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > Sent: Tuesday, October 16, 2001 3:48 AM
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] Contact header in MESSAGE request
> > 
> > 
> > Hello,
> >  
> > I've been reading draft-ietf-simple-im-01, and at the end I 
> > read Appendix A.
> > Requirements Evaluation.
> >  
> >    "Requirement 4.1.3. The common message format MUST include a return
> >       address for the receiver to reply to the sender with another
> >       INSTANT MESSAGE." This is done through the Contact headers
> >       defined in SIP. 
> >  
> > Does this mean that the Contact header is mandatory in an 
> > MESSAGE request?
> > It's not according to the table of header fields.
> 
> This is something that has changed a bit as the session model has evolved
> into a separate entity. The initial model was that MESSAGE itself set up a
> session, but this was discarded as we didn't want multiple ways to
> establish
> an interaction communicastions session, and certainly voice/video could be
> part of that. In this initial model, since MESSAGE was like INVITE, it had
> a
> Contact header that was used for sending subsequent messages within the
> session. 
> 
> Then, with the paging model, MESSAGE became a "one-shot" kind of thing.
> There is no session or context for the messages. Since Contact is meant to
> provide an endpoint address, its not very useful for paging mode. In these
> cases, you can't really provide a a host address, since these things
> change,
> and the duration during which that address would remain useful is unknown.
> Providing a direct host address is only useful where there is a session,
> and
> we can change it if the host moves (SIP provides this ability). So,
> Contact
> doesn't make sense anymore. Thats why its not in the table.
> 
> However, one might want to provide a reply address that isn't a host IP or
> hostname. Rather, we want to provide a logical address to send messages in
> reply. Normally, the From is used for this kind of thing, but certainly
> the
> address for sending a response could be something else.
> 
> Right now, there is no Reply-To header in SIP. It would be a useful thing
> to
> have, as it makes sense for initiating calls as well (If I call you, and
> you're not there, I can provide a logical address to use to call me back
> at
> any point later on). In fact, this is a current open issue in the bis
> specification itself (whether or not to add a Reply-To address). Oddly,
> bis
> does have an In-Reply-To header that identifies the specific call that a
> new
> call is in reply to.
> 
> Since we have multiple cases where it is needed, sounds like its something
> that should be added.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From bcampbell@dynamicsoft.com  Wed Oct 24 17:58:33 2001
Received: from localhost.localdomain ([63.110.3.137])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02408;
	Wed, 24 Oct 2001 17:58:17 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f9OLrv101988;
	Wed, 24 Oct 2001 16:53:57 -0500
Message-ID: <3BD73874.2040702@dynamicsoft.com>
Date: Wed, 24 Oct 2001 16:53:56 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Gur_Kimchi@vocaltec.com
CC: Jonathan Rosenberg ,
        Paul Kyzivat , Avshalom@ubique.com,
        "'Rosen, Brian'" ,
        Henning Schulzrinne ,
        "'Christian Huitema'" ,
        "Peterson, Jon" ,
        "Roy, Radhika R, ALCTA" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Vasilis Polychronidis 
Subject: Re: [Simple] IM over the signaling connection
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1322
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: 

If we had those headers, would you expect them to be in SIP headers or 
in the meta-data of message/cpim? It seems to me the second makes more 
sense, as this is information that may need to be delivered end-to-end 
across a CPIM boundery.

Gur_Kimchi@vocaltec.com wrote:

> Jonathan -
> 
> I agree we should not hold up the basic page mode - but I feel the ability
> to associate MESSAGEs with a "thread of MESSAGES" is needed regardless if
> it in a page or in an INVITE-established session - again I am not asking
> for
> anything mandatory - but I do feel unique optional  and
> 
> headers should be in the draft now.
> 
> I think the use of these optional headers (+In-Reply-To) is obvious, and
> documenting them should not be controversial - but I have been wrong
> before...
> 
> at the same time, I have not heard an objection yet to their inclusion.
> 
> - gur
> 
> 
>>>-Jonathan R. Wrote:
>>>
>>>One thing I do want to note.... I think that whatever we do for thread
>>>
> IDs,
> 
>>>in-reply-to's or whatever should not hold up the basic paging model. All
>>>
> of
> 
>>>those things are primarily needed to facilitate integration with a
>>>
> session
> 
>>>model, and therefore we should worry about those things later. Lets get
>>>
> the
> 
>>>basic paging model done.
>>>
> 
> 
> 




From bcampbell@dynamicsoft.com  Wed Oct 24 18:14:38 2001
Received: from localhost.localdomain ([63.110.3.137])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02514
	for ; Wed, 24 Oct 2001 18:14:37 -0400 (EDT)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f9OM9m102040;
	Wed, 24 Oct 2001 17:09:48 -0500
Message-ID: <3BD73C2C.7060701@dynamicsoft.com>
Date: Wed, 24 Oct 2001 17:09:48 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
To: Michael Hammer 
CC: Christian Huitema ,
        "Roy, Radhika R, ALCTA" ,
        Vasilis Polychronidis ,
        Jonathan Rosenberg ,
        Henning Schulzrinne ,
        "Peterson, Jon" , Avshalom@ubique.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM over the signaling connection
References:  <4.3.2.7.2.20011009162017.00b05818@cia.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 6798
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: 

I think I should have said "series" of messages, rather than "stream" of 
messages, because I think I conveyed the wrong idea. The current draft 
assumes a one to one correspondence between MESSAGE requests and IMs. It 
does mention that if you want to send something larger than the maximum 
UDP size, you should use TCP.

If we are talking about MESSAGE as a file transfer protocol, I think 
this would be better modeled using an INVITE initiated file transfer 
session of some sort.

Michael Hammer wrote:

> Ben,
> 
> Whether a message appears as a single IM or a stream of IM right now 
> appears to be more of an implementation detail, absent a maximum IM 
> size.  (Did I miss that definition?) Given that an application may send 
> a 1 Mbyte message as:
> 
> 1) one 1 M IM,
> 2) two 512 K IMs,
> 3) four 256 K IMs,
> ...
> n-2) 256 4 K IMs
> n-1) 512 2 K IMs
> n) 1024 1K IMs
> 
> Does IM size count at all or just message and response counts?
> Do we care that SIP may need to segment to some max message size, say 
> 1500 bytes?
> Do we care that a lower layer may need to segment the message prior to 
> transmission?
> Do we care if the IP layer has to fragment during transmission?
> Are there some unstated assumptions in your calculation?
> 
> Mike
> 
> 
> At 02:39 PM 10/9/2001 -0500, Ben Campbell wrote:
> 
>> I agree with Christian here--I really want to discourage session mode 
>> unless one expects a stream of messages. One shot text messages should 
>> normally be page mode.
>>
>> Christian Huitema wrote:
>>
>>> Note that my point was not to ignore the lessons of the past, but to 
>>> point out that widely deployed systems such as SMS are not going to 
>>> disappear in a day, or in a year -- they are with us for at least one 
>>> or two upgrade cycles, i.e. at least 4 to 6 years.
>>>
>>> Also note that if the usage is actually a page, then a "message" is 
>>> less taxing on the infrastructure than an "invite" + the necessary 
>>> session clean-up. Let's compare:
>>>
>>> 1) Message: one signalling message + one response per IM.
>>>
>>> 2) Session: INVITE + response; ACK; BYE+response; + additional cost 
>>> of setting the message channel; IM messages on channel.
>>>
>>>  From a pure signalling point of view, the session mode is only 
>>> beneficial when there are at least 3 IM exchanged in a session.
>>>
>>> -- Christian Huitema
>>>
>>> -----Original Message-----
>>> *From:* Roy, Radhika R, ALCTA [mailto:rrroy@att.com]
>>> *Sent:* Tuesday, October 09, 2001 6:23 AM
>>> *To:* Vasilis Polychronidis; Christian Huitema
>>> *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; 
>>> Peterson, Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com
>>> *Subject:* RE: [Simple] IM over the signaling connection
>>>     Hi, Vasilis:
>>>
>>>     Good that you have reminded the very important lesson from the past.
>>>
>>>     Would please let us know your opinion what do we do in the case of
>>>     "Paging" in SIP?
>>>
>>>     Of course, we have another scheme: MESSAGE as session.
>>>
>>>     Radhika
>>>         -----Original Message-----
>>>         *From:* Vasilis Polychronidis
>>>         [mailto:Vasilis.Polychronidis@openwave.com]
>>>         *Sent:* Monday, October 08, 2001 4:43 PM
>>>         *To:* Christian Huitema
>>>         *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;
>>>         Peterson, Jon; Avshalom@ubique.com; 
>>> simple@mailman.dynamicsoft.com
>>>         *Subject:* Re: [Simple] IM over the signaling connection
>>>         Christian Huitema wrote:
>>>             There are two points that I keep in mind in this debate:
>>>             1) SMS, the messaging service of cell phones, uses the page
>>>             mode and is
>>>             carried at least in part over the signaling channel.
>>>         Correct. However Operators realized that SMS was the wrong (was
>>>         very successful financially) technical solution for messaging.
>>>         Remind you that when the people designed (late 80s) SMS they did
>>>         not have any idea of how successful commercial service will be.
>>>         That is why the next generation of multimedia messaging is using
>>>         HTTP as the transport.
>>>         I understand that this is a difficult point to understand with
>>>         some people in the list.
>>>         Let me remind you that the telephony people with more than
>>>         hundred years of experience realized in the late seventies that
>>>         in order to scale and have very reliable networks you had to
>>>         separate signaling from transport (initially signaling was mixed
>>>         with transport -
>>>         that is the current case for all the analog lines going from
>>>         home to the local switch --> DTMF) and they created SS7 and 
>>> ISUP.
>>>         Actually people invented SIP using ISUP as their guide.
>>>         That was one of the initial arguments of SIP: separate proxies
>>>         from transport of user data.
>>>         It seems to me that certain people want to regress in time and
>>>         mix signaling and user data.
>>>         Let us please learn from the history and lets try not to repeat
>>>         the same mistakes.
>>>
>>>             2) CPIM's Message function looks a lot like the page mode.
>>>             It seems that the first step forward is to recognize this
>>>             and assume
>>>             that we will indeed use "MESSAGE over SIP" in the page mode
>>>             for a
>>>             significant fraction of our exchanges. I suggest that the
>>>             first order
>>>             action of SIMPLE is to just nail this one, so it be 
>>> behind us.
>>>             The page mode has well known limitations: it creates a lot
>>>             of overhead
>>>             in long sessions, and it does not extend easily to 
>>> multi-party
>>>             operation. This is the rationale for the "IM session"
>>>             extensions, i.e.
>>>             IM after INVITE. However, whatever we do in the session
>>>             mode, we will
>>>             have to go on interworking with SMS and with CPIM; this
>>>             means that we
>>>             will have to bring in the session some members who can only
>>>             use the page
>>>             mode. Obviously, a "session of messages" makes this very 
>>> easy.
>>>             -- Christian Huitema
>>>             _______________________________________________
>>
>>
>>
>>
>> _______________________________________________
>> simple mailing list
>> simple@mailman.dynamicsoft.com
>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple




From Gur_Kimchi@vocaltec.com  Wed Oct 24 18:48:37 2001
Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02687;
	Wed, 24 Oct 2001 18:48:36 -0400 (EDT)
From: Gur_Kimchi@vocaltec.com
Subject: Re: [Simple] IM over the signaling connection
To: Ben Campbell 
Cc: Jonathan Rosenberg ,
        Paul Kyzivat , Avshalom@ubique.com,
        "'Rosen, Brian'" ,
        Henning Schulzrinne ,
        "'Christian Huitema'" ,
        "Peterson, Jon" ,
        "Roy, Radhika R, ALCTA" ,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Vasilis Polychronidis 
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: 
Date: Thu, 25 Oct 2001 01:47:17 +0200
X-MIMETrack: Serialize by Router on USNIMO/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March
 2000) at 10/24/2001 06:47:25 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 1772
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: 

>> Ben Campbell Wrote:
>>
>> If we had those headers, would you expect them to be in SIP headers or
>> in the meta-data of message/cpim? It seems to me the second makes more
>> sense, as this is information that may need to be delivered end-to-end
>> across a CPIM boundery.

out of the two choices It does makes more sense to put it into the
individual
cpim header - with multipart mime I could see multiple messages in one
MESSAGE body
(think forwarding/aggregating proxy).

>> Ben Campbell Wrote:
>>
>> I think I should have said "series" of messages, rather than "stream" of

>> messages, because I think I conveyed the wrong idea. The current draft
>> assumes a one to one correspondence between MESSAGE requests and IMs. It

>> does mention that if you want to send something larger than the maximum
>> UDP size, you should use TCP.
>>
>> If we are talking about MESSAGE as a file transfer protocol, I think
>> this would be better modeled using an INVITE initiated file transfer
>> session of some sort.

There is no problem limiting the size of IMs to some very small size-
the usual solution when needing to send large amounts of data is to send
"by reference" - e.g. send a URL to the file you want the other side to
get,
instead of the file itself.  I see no problem with limiting sizes of IMs to
under
512 bytes, allowing both UDP and TCP to be used.

remember that on the largest IM system in the world (GSM-SMS) the maximum
size
is 160 chars - I dont think we are here to solve file/image/XYZ transfer
problems,
if you want to send anything that is not an IM (and the definition is
clear) -
INVITE to a specific-media session or MESSAGE a URL of where the resource
can be found.

(http://www1.ics.uci.edu/pub/ietf/uri/draft-antti-gsm-sms-url-04.txt)

- gur


From salvatore.loreto@libero.it  Thu Oct 25 11:03:55 2001
Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05682
	for ; Thu, 25 Oct 2001 11:03:53 -0400 (EDT)
Received: from libero.it (193.70.192.41) by smtp3.libero.it (6.0.032)
        id 3BD43E25000FE192 for simple@mailman.dynamicsoft.com; Thu, 25 Oct 2001 17:03:17 +0200
Date: Thu, 25 Oct 2001 17:03:17 +0200
Message-Id: 
	
MIME-Version: 1.0
Content-Type: text/plain
From: "sal"
To: simple@mailman.dynamicsoft.com
X-XaM3-API-Version: 1.1.9.1.39.1.2
X-SenderIP: 193.205.164.115
Content-Length: 258
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA05682
Subject: [Simple] upload Presence Document
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 

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




From dean.willis@softarmor.com  Thu Nov  1 02:45:36 2001
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
Date: Thu, 1 Nov 2001 00:39:45 -0600
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
Content-Length: 782
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: 

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
>
>


From salvatore.loreto@libero.it  Thu Nov  1 05:55:45 2001
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
Date: 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-Length: 1498
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: 

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
> 

From ndeason@ubiquity.net  Thu Nov  1 07:06:16 2001
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
Date: Thu, 1 Nov 2001 12:07:58 -0000
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]
Content-Length: 1926
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: 

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


From c-Dai.Ngo@WCOM.Com  Thu Nov  1 11:27:49 2001
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
Date: Thu, 01 Nov 2001 16:26:58 +0000
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)"
Content-Length: 54311
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: 

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)--

From bstucker@nortelnetworks.com  Thu Nov  1 11:50:21 2001
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
Date: Thu, 1 Nov 2001 10:49:15 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C162F5.2407E010"
X-Orig: 
Content-Length: 59990
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: 

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--

From Tim.Moran@nokia.com  Thu Nov  1 12:36:25 2001
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
Date: Thu, 1 Nov 2001 11:35:58 -0600
Message-ID: <278B6B0D76698D45BBA872CD23DD496A0A421B@daebe004.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C162FB.AA81F77C"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
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]
Content-Length: 63916
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: 

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--

From rsparks@dynamicsoft.com  Thu Nov  1 13:45:42 2001
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'" 
Date: Thu, 1 Nov 2001 13:45:22 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 233
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: 

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

From bstucker@nortelnetworks.com  Thu Nov  1 13:41:11 2001
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
Date: Thu, 1 Nov 2001 12:40:07 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16304.A1446E40"
X-Orig: 
Content-Length: 70516
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: 

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--

From bstucker@nortelnetworks.com  Thu Nov  1 13:41:11 2001
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
Date: Thu, 1 Nov 2001 12:40:07 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16304.A1446E40"
X-Orig: 
Content-Length: 70516
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: 

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--

From bstucker@nortelnetworks.com  Thu Nov  1 13:53:23 2001
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
Date: Thu, 1 Nov 2001 12:52:09 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16306.4F63AAD0"
X-Orig: 
Content-Length: 11607
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: 

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--

From Tim.Moran@nokia.com  Thu Nov  1 19:12:21 2001
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
Date: Thu, 1 Nov 2001 18:11:49 -0600
Message-ID: <278B6B0D76698D45BBA872CD23DD496A0A421E@daebe004.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16332.F768BA78"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
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]
Content-Length: 19301
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: 

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. 
    
  2. Some number of notifiers send=20
    202. 
    3. 
    
  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. 
    
  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--

From salvatore.loreto@libero.it  Fri Nov  2 05:00:24 2001
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
Date: Fri,  2 Nov 2001 10:59:45 +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-Length: 1402
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: 

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 ?

From hakan.jonsson@bluelabs.se  Fri Nov  2 05:55:59 2001
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?
Date: Fri, 2 Nov 2001 12:05:13 +0100
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-Length: 3558
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: 

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
> 


From jsonnet@indigosw.com  Fri Nov  2 12:38:29 2001
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>
Date: Fri, 02 Nov 2001 18:37:56 +0100
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
Content-Length: 207
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: 

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.


From bstucker@nortelnetworks.com  Fri Nov  2 15:11:17 2001
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?
Date: Fri, 2 Nov 2001 14:09:38 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C163DA.4CB11AA0"
X-Orig: 
Content-Length: 12676
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: 

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--

From rsparks@dynamicsoft.com  Fri Nov  2 16:27:00 2001
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?
Date: Fri, 2 Nov 2001 16:26:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C163E5.095DD710"
Content-Length: 18196
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: 

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--

From bstucker@nortelnetworks.com  Fri Nov  2 16:49:00 2001
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?
Date: Fri, 2 Nov 2001 15:47:48 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C163E8.0343EBF0"
X-Orig: 
Content-Length: 19968
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: 

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--

From sriramp@nortelnetworks.com  Fri Nov  2 16:50:59 2001
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?
Date: Fri, 2 Nov 2001 15:49:42 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C163E8.47692480"
X-Orig: 
Content-Length: 21493
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: 

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--

From rsparks@dynamicsoft.com  Fri Nov  2 17:08:07 2001
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?
Date: Fri, 2 Nov 2001 17:07:33 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C163EA.C5EC2850"
Content-Length: 26667
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: 

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--

From rsparks@dynamicsoft.com  Fri Nov  2 17:12:34 2001
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'" 
Date: Fri, 2 Nov 2001 17:12:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1691
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: 

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


From c-Dai.Ngo@WCOM.Com  Fri Nov  2 17:23:41 2001
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
Date: Fri, 02 Nov 2001 22:23:05 +0000
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
Content-Length: 2299
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: 

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

From rsparks@dynamicsoft.com  Fri Nov  2 17:31:09 2001
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
Date: Fri, 2 Nov 2001 17:30:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 355
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: 

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

From jdrosen@dynamicsoft.com  Tue Nov  6 00:11:04 2001
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
Date: Tue, 6 Nov 2001 00:10:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 6745
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: 


  
-----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 
  
  
  

From lachlan.brazier@siemens.at  Tue Nov  6 04:31:31 2001
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
Date: Tue, 6 Nov 2001 10:30:24 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2135
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: 

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

From rsparks@dynamicsoft.com  Tue Nov  6 09:54:09 2001
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
Date: Tue, 6 Nov 2001 09:49:15 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5237
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: 

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
> 

From rsparks@dynamicsoft.com  Tue Nov  6 09:57:24 2001
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'" 
Date: Tue, 6 Nov 2001 09:57:00 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 408
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: 

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

From rsparks@dynamicsoft.com  Tue Nov  6 10:54:19 2001
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
Date: Tue, 6 Nov 2001 10:46:35 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 882
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: 

> > >  * 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

From jundery@ubiquity.net  Tue Nov  6 11:04:14 2001
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
Date: Tue, 6 Nov 2001 16:06:14 -0000
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]
Content-Length: 1104
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: 

> > > >  * 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


From bstucker@nortelnetworks.com  Tue Nov  6 21:39:47 2001
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
Date: Tue, 6 Nov 2001 20:38:21 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16735.43FB6100"
Content-Length: 5611
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: 

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--

From jdrosen@dynamicsoft.com  Wed Nov  7 02:58:36 2001
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
Date: Wed, 7 Nov 2001 02:58:06 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2292
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: 



> -----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
 

From jdrosen@dynamicsoft.com  Wed Nov  7 03:03:31 2001
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
Date: Wed, 7 Nov 2001 03:03:03 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2151
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: 


 

> -----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

From bstucker@nortelnetworks.com  Wed Nov  7 04:36:49 2001
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
Date: Wed, 7 Nov 2001 03:35:22 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1676F.85B02970"
X-Orig: 
Content-Length: 10663
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: 

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--

From jdrosen@dynamicsoft.com  Wed Nov  7 09:35:50 2001
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
Date: Wed, 7 Nov 2001 09:35:26 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2394
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: 


  
-----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 
  

From bstucker@nortelnetworks.com  Wed Nov  7 17:06:42 2001
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
Date: Wed, 7 Nov 2001 16:04:55 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C167D8.3BCE57A0"
Content-Length: 9329
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: 

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--

From sean.olson@ericsson.com  Wed Nov  7 17:29:03 2001
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
Date: Wed, 7 Nov 2001 16:28:40 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C167DB.8CC62860"
Content-Length: 10843
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: 

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--

From bstucker@nortelnetworks.com  Wed Nov  7 17:57:33 2001
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
Date: Wed, 7 Nov 2001 16:55:58 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C167DF.5D51BB90"
Content-Length: 12569
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: 

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--

From lachlan.brazier@siemens.at  Wed Nov  7 23:30:43 2001
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
Date: Thu, 8 Nov 2001 05:30:08 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3033
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: 

 
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 
  

From aboaventura@lucent.com  Thu Nov  8 08:05:31 2001
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'"
	 
Date: Thu, 8 Nov 2001 11:04:54 -0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 630
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: 

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.

From rrroy@att.com  Thu Nov  8 09:49:41 2001
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
Date: Thu, 8 Nov 2001 09:45:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2592
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: 

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

From adam.roach@ericsson.com  Thu Nov  8 11:17:28 2001
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
Date: Thu, 8 Nov 2001 10:09:55 -0600
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
Content-Length: 3101
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: 

> 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


From bstucker@nortelnetworks.com  Thu Nov  8 11:50:14 2001
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
Date: Thu, 8 Nov 2001 10:48:06 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16875.24000D10"
X-Orig: 
Content-Length: 12835
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: 

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--

From lachlan.brazier@siemens.at  Fri Nov  9 06:11:43 2001
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
Date: Fri, 9 Nov 2001 12:10:24 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5472
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: 

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 


From lachlan.brazier@siemens.at  Fri Nov  9 08:58:50 2001
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'"
	 
Date: Fri, 9 Nov 2001 14:57:59 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 897
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: 

> >
> > 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

From bstucker@nortelnetworks.com  Fri Nov  9 11:04:08 2001
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
Date: Fri, 9 Nov 2001 10:02:45 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16937.F8949790"
Content-Length: 21052
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: 

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--

From bstucker@nortelnetworks.com  Fri Nov  9 12:39:48 2001
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'" 
Date: Fri, 9 Nov 2001 11:38:19 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16945.525DBF60"
X-Orig: 
Content-Length: 5315
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: 

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--

From jdrosen@dynamicsoft.com  Fri Nov  9 15:28:56 2001
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
Date: Fri, 9 Nov 2001 15:28:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5907
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: 


  
-----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 

From jdrosen@dynamicsoft.com  Fri Nov  9 15:43:58 2001
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
Date: Fri, 9 Nov 2001 15:43:26 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 8021
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: 


  
-----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 

From MLipfo01@sprintspectrum.com  Fri Nov  9 16:00:32 2001
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'"
	 
Date: Fri, 9 Nov 2001 15:00:10 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1457
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: 

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.

From lachlan.brazier@siemens.at  Fri Nov  9 18:59:25 2001
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
Date: Sat, 10 Nov 2001 00:58:39 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 9826
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: 

 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 

From aki.niemi@nokia.com  Mon Nov 12 10:56:35 2001
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
Date: Mon, 12 Nov 2001 17:54:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 575
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: 

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 

From sean.olson@ericsson.com  Mon Nov 12 12:41:05 2001
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
Date: Mon, 12 Nov 2001 11:40:33 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16BA1.213F5570"
Content-Length: 2930
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: 

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--

From rsparks@dynamicsoft.com  Mon Nov 12 12:53:24 2001
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'" 
Date: Mon, 12 Nov 2001 12:53:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1762
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: 

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

From aki.niemi@nokia.com  Mon Nov 12 13:56:59 2001
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
Date: Mon, 12 Nov 2001 20:56:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 315
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: 

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

From sean.olson@ericsson.com  Mon Nov 12 14:25:15 2001
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
Date: Mon, 12 Nov 2001 13:24:54 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16BAF.B4ED3D60"
Content-Length: 2548
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: 

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--

From rsparks@dynamicsoft.com  Mon Nov 12 15:57:32 2001
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
Date: Mon, 12 Nov 2001 15:57:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16BBC.971B58A0"
Content-Length: 6038
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: 

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--

From rrroy@att.com  Mon Nov 12 16:08:52 2001
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
Date: Mon, 12 Nov 2001 16:07:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1883
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: 

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 
> 


From rsparks@dynamicsoft.com  Mon Nov 12 16:50:05 2001
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
Date: Mon, 12 Nov 2001 16:49:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3129
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: 

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 
> > 
> 

From jdrosen@dynamicsoft.com  Mon Nov 12 16:55:20 2001
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
Date: Mon, 12 Nov 2001 16:54:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4338
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: 

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
> 

From jdrosen@dynamicsoft.com  Mon Nov 12 17:02:19 2001
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)
Date: Mon, 12 Nov 2001 17:01:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2620
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: 


 

> -----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

From rsparks@dynamicsoft.com  Mon Nov 12 17:21:20 2001
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)
Date: Mon, 12 Nov 2001 17:18:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2852
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: 

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


From lachlan.brazier@siemens.at  Tue Nov 13 03:06:27 2001
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)
Date: Tue, 13 Nov 2001 09:03:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3921
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: 

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

From lachlan.brazier@siemens.at  Tue Nov 13 03:42:13 2001
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'" 
Date: Tue, 13 Nov 2001 09:40:15 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 164
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: 

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

From jundery@ubiquity.net  Tue Nov 13 05:24:35 2001
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)
Date: Tue, 13 Nov 2001 10:26:55 -0000
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]
Content-Length: 3987
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: 

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


From Avshalom@ubique.com  Tue Nov 13 06:00:01 2001
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: 
Date: Tue, 13 Nov 2001 12:58:57 +0200
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
Content-Length: 4490
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: 

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





From jundery@ubiquity.net  Tue Nov 13 06:05:51 2001
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)
Date: Tue, 13 Nov 2001 11:08:10 -0000
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]
Content-Length: 452
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: 


> -----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


From rrroy@att.com  Tue Nov 13 10:08:56 2001
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
Date: Tue, 13 Nov 2001 10:07:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4602
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: 

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 
> > 
> 

From jdrosen@dynamicsoft.com  Tue Nov 13 10:13:25 2001
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
Date: Tue, 13 Nov 2001 10:13:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 979
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: 

 

> -----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

From rsparks@dynamicsoft.com  Tue Nov 13 10:49:53 2001
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)
Date: Tue, 13 Nov 2001 10:49:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1455
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: 


> > > 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.

From aki.niemi@nokia.com  Tue Nov 13 11:09:57 2001
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
Date: Tue, 13 Nov 2001 18:09:20 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 557
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: 

> 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

From jundery@ubiquity.net  Tue Nov 13 11:28:59 2001
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)
Date: Tue, 13 Nov 2001 16:31:18 -0000
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]
Content-Length: 2220
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: 



> > 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


From adam.roach@ericsson.com  Tue Nov 13 12:25:37 2001
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)
Date: Tue, 13 Nov 2001 11:25:09 -0600
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>
Content-Length: 463
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: 

> 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


From adam.roach@ericsson.com  Tue Nov 13 12:29:58 2001
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
Date: Tue, 13 Nov 2001 11:29:26 -0600
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>
Content-Length: 781
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: 

> -----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


From adam.roach@ericsson.com  Tue Nov 13 12:30:06 2001
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
Date: Tue, 13 Nov 2001 11:20:05 -0600
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>
Content-Length: 1022
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: 

> -----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


From aki.niemi@nokia.com  Tue Nov 13 13:02:21 2001
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
Date: Tue, 13 Nov 2001 20:01:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1164
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: 

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

From pkyzivat@cisco.com  Tue Nov 13 13:52:24 2001
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>
Date: Tue, 13 Nov 2001 13:49:13 -0500
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
Content-Length: 2953
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: 

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

From rsparks@dynamicsoft.com  Tue Nov 13 14:04:20 2001
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)
Date: Tue, 13 Nov 2001 14:03:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 964
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: 

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
> 

From pkyzivat@cisco.com  Tue Nov 13 14:07:31 2001
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>
Date: Tue, 13 Nov 2001 14:04:19 -0500
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
Content-Length: 1974
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: 

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

From bstucker@nortelnetworks.com  Tue Nov 13 14:20:17 2001
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
Date: Tue, 13 Nov 2001 13:18:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16C77.F7D62880"
X-Orig: 
Content-Length: 14905
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: 

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--

From adam.roach@ericsson.com  Tue Nov 13 14:30:44 2001
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
Date: Tue, 13 Nov 2001 13:30:08 -0600
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>
Content-Length: 806
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: 

> -----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


From adam.roach@ericsson.com  Tue Nov 13 15:21:28 2001
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
Date: Tue, 13 Nov 2001 14:15:35 -0600
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>
Content-Length: 656
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: 

> 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


From rrroy@att.com  Tue Nov 13 15:32:44 2001
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
Date: Tue, 13 Nov 2001 15:29:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1472
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: 

-----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.

...


From bstucker@nortelnetworks.com  Tue Nov 13 16:04:25 2001
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
Date: Tue, 13 Nov 2001 15:02:39 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16C86.8744E020"
X-Orig: 
Content-Length: 10961
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: 

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--

From pkyzivat@cisco.com  Tue Nov 13 18:16:29 2001
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>
Date: Tue, 13 Nov 2001 18:13:16 -0500
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
Content-Length: 1819
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: 

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.

From bcampbell@dynamicsoft.com  Tue Nov 13 23:00:06 2001
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>
Date: Tue, 13 Nov 2001 21:56:36 -0600
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
Content-Length: 3501
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: 

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
> 



From Pekka.Pessi@nokia.com  Wed Nov 14 02:44:11 2001
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>
Date: 14 Nov 2001 09:45:43 +0200
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"
Content-Length: 1148
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: 

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

From rsparks@dynamicsoft.com  Wed Nov 14 09:02:36 2001
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
Date: Wed, 14 Nov 2001 09:02:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1933
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: 

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
> 

From jdrosen@dynamicsoft.com  Wed Nov 14 15:17:21 2001
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'" 
Date: Wed, 14 Nov 2001 15:17:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1142
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: 

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
 

From jdrosen@dynamicsoft.com  Wed Nov 14 15:50:27 2001
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'" 
Date: Wed, 14 Nov 2001 15:50:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 716
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: 

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
 

From sean.olson@ericsson.com  Wed Nov 14 16:15:08 2001
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
Date: Wed, 14 Nov 2001 15:14:34 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C16D51.5C038E40"
Content-Length: 6421
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: 

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--

From petkos@cs.columbia.edu  Wed Nov 14 17:41:43 2001
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
Date: Wed, 14 Nov 2001 17:41:20 -0500 (EST)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 845
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: 

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

From pkyzivat@cisco.com  Wed Nov 14 18:36:24 2001
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>
Date: Wed, 14 Nov 2001 18:33:08 -0500
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
Content-Length: 4210
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: 

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

From Hakan.Jonsson@bluelabs.se  Thu Nov 15 08:24:49 2001
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: 
Date: Thu, 15 Nov 2001 14:24:25 +0100
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-Length: 1671
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: 

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


From bstucker@nortelnetworks.com  Thu Nov 15 16:14:07 2001
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
Date: Thu, 15 Nov 2001 15:12:31 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16E1A.3D2FEA80"
Content-Length: 7366
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: 

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--

From wamontgomery@worldnet.att.net  Thu Nov 15 20:35:25 2001
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
Date: Thu, 15 Nov 2001 19:35:27 -0600
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
Content-Length: 1124
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: 

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


From pkyzivat@cisco.com  Fri Nov 16 10:15:18 2001
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>
Date: Fri, 16 Nov 2001 10:11:57 -0500
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
Content-Length: 1709
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: 

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

From jdrosen@dynamicsoft.com  Fri Nov 16 23:45:58 2001
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
Date: Fri, 16 Nov 2001 23:45:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 7246
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: 

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. 
... 

From jdrosen@dynamicsoft.com  Fri Nov 16 23:54:12 2001
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
Date: Fri, 16 Nov 2001 23:53:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3440
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: 


  
-----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 

From jdrosen@dynamicsoft.com  Fri Nov 16 23:59:54 2001
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
Date: Fri, 16 Nov 2001 23:59:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 4418
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: 


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


From jdrosen@dynamicsoft.com  Sat Nov 17 00:04:36 2001
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
Date: Sat, 17 Nov 2001 00:04:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2604
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: 


 

> -----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

From jdrosen@dynamicsoft.com  Sat Nov 17 01:29:40 2001
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
Date: Sat, 17 Nov 2001 01:29:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2643
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: 


 

> -----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

From jdrosen@dynamicsoft.com  Sat Nov 17 01:34:18 2001
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
Date: Sat, 17 Nov 2001 01:33:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 4757
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: 

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
> 

From jdrosen@dynamicsoft.com  Sat Nov 17 01:36:46 2001
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
Date: Sat, 17 Nov 2001 01:36:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1513
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: 


 

> -----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
 

From bstucker@nortelnetworks.com  Sat Nov 17 14:34:09 2001
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
Date: Sat, 17 Nov 2001 13:32:46 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C16F9E.A262E2B0"
X-Orig: 
Content-Length: 12369
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: 

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--

From tony@att.com  Mon Nov 19 10:32:40 2001
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>
Date: Mon, 19 Nov 2001 10:31:42 -0500
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
Content-Length: 763
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: 

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

From adam.roach@ericsson.com  Mon Nov 19 11:12:00 2001
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
Date: Mon, 19 Nov 2001 10:06:08 -0600
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: 
Content-Length: 581
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: 

> -----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


From jdrosen@dynamicsoft.com  Mon Nov 19 17:17:39 2001
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
Date: Mon, 19 Nov 2001 17:16:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1589
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: 


 

> -----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

From adam.roach@ericsson.com  Mon Nov 19 17:52:40 2001
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
Date: Mon, 19 Nov 2001 16:42:33 -0600
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: 
Content-Length: 2418
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: 

> -----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


From bstucker@nortelnetworks.com  Mon Nov 19 18:37:16 2001
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
Date: Mon, 19 Nov 2001 17:35:19 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C17152.D9839220"
X-Orig: 
Content-Length: 11759
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: 

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--

From adam.roach@ericsson.com  Mon Nov 19 18:58:50 2001
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
Date: Mon, 19 Nov 2001 17:52:25 -0600
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>
Content-Length: 4349
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: 

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


From adam.roach@ericsson.com  Mon Nov 19 19:09:50 2001
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
Date: Mon, 19 Nov 2001 18:04:16 -0600
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>
Content-Length: 3963
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: 

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


From jdrosen@dynamicsoft.com  Tue Nov 20 00:15:53 2001
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
Date: Tue, 20 Nov 2001 00:13:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5177
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: 


 

> -----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

From jdrosen@dynamicsoft.com  Tue Nov 20 00:26:09 2001
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
Date: Tue, 20 Nov 2001 00:24:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3840
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: 


 

> -----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


From pkyzivat@cisco.com  Tue Nov 20 09:32:31 2001
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>
Date: Tue, 20 Nov 2001 09:29:06 -0500
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
Content-Length: 493
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: 

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

From bstucker@nortelnetworks.com  Tue Nov 20 10:07:17 2001
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
Date: Tue, 20 Nov 2001 09:05:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C171D4.C4304DF0"
X-Orig: 
Content-Length: 13467
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: 

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--

From mhammer@cisco.com  Tue Nov 20 10:10:14 2001
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
Date: Tue, 20 Nov 2001 10:15:07 -0500
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
Content-Length: 4865
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: 

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


From bstucker@nortelnetworks.com  Tue Nov 20 10:27:52 2001
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
Date: Tue, 20 Nov 2001 09:26:04 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C171D7.AB0EDD70"
Content-Length: 19502
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: 

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--

From bcampbell@dynamicsoft.com  Tue Nov 20 11:16:15 2001
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>
Date: Tue, 20 Nov 2001 10:13:55 -0600
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
Content-Length: 3931
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: 

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
> 



From bcampbell@dynamicsoft.com  Tue Nov 20 11:21:47 2001
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>
Date: Tue, 20 Nov 2001 10:19:34 -0600
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
Content-Length: 941
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: 

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
> 



From jdrosen@dynamicsoft.com  Tue Nov 20 11:23:14 2001
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
Date: Tue, 20 Nov 2001 11:22:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1852
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: 

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
> > 
> 
> 

From adam.roach@ericsson.com  Tue Nov 20 16:18:38 2001
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
Date: Tue, 20 Nov 2001 15:18:10 -0600
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>
Content-Length: 2550
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: 

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


From bstucker@nortelnetworks.com  Tue Nov 20 16:20:30 2001
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
Date: Tue, 20 Nov 2001 15:18:40 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C17208.ED3B35F0"
X-Orig: 
Content-Length: 2671
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: 

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--

From adam.roach@ericsson.com  Tue Nov 20 16:40:46 2001
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'" ,
        
Date: Tue, 20 Nov 2001 15:34:11 -0600
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>
Content-Length: 1726
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: 

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


From bstucker@nortelnetworks.com  Tue Nov 20 16:56:45 2001
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" 
Date: Tue, 20 Nov 2001 15:55:05 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1720E.03823CA0"
X-Orig: 
Content-Length: 8159
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: 

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--

From adam.roach@ericsson.com  Tue Nov 20 17:28:35 2001
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" 
Date: Tue, 20 Nov 2001 16:17:01 -0600
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>
Content-Length: 2640
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: 

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


From theodore.havinis@openwave.com  Tue Nov 20 17:34:01 2001
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: 
Date: Tue, 20 Nov 2001 14:38:00 -0800
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
Content-Length: 2161
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: 

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
_____________________________________





From bstucker@nortelnetworks.com  Tue Nov 20 18:26:59 2001
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" 
Date: Tue, 20 Nov 2001 17:25:13 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1721A.9AA5FC50"
Content-Length: 13463
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: 

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--

From adam.roach@ericsson.com  Tue Nov 20 18:56:14 2001
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" 
Date: Tue, 20 Nov 2001 17:49:38 -0600
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
Content-Length: 2497
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: 

>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


From pkyzivat@cisco.com  Tue Nov 20 19:35:51 2001
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>
Date: Tue, 20 Nov 2001 19:32:10 -0500
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
Content-Length: 3402
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: 

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
> > >
> >
> >

From jdrosen@dynamicsoft.com  Wed Nov 21 01:38:19 2001
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
Date: Wed, 21 Nov 2001 01:37:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 2985
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: 


 

> -----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

From jdrosen@dynamicsoft.com  Wed Nov 21 01:48:21 2001
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
Date: Wed, 21 Nov 2001 01:47:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4063
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: 


 

> -----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

From jdrosen@dynamicsoft.com  Wed Nov 21 01:58:59 2001
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.
Date: Wed, 21 Nov 2001 01:58:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3831
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: 

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
> 

From salvatore.loreto@libero.it  Wed Nov 21 06:52:47 2001
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
Date: Wed, 21 Nov 2001 12:52:24 +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-Length: 390
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: 

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?

From nsyracus@cnri.reston.va.us  Wed Nov 21 06:59:25 2001
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
Date: Wed, 21 Nov 2001 06:59:03 -0500
Content-Length: 2555
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: 

--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--



From c-Dai.Ngo@WCOM.Com  Wed Nov 21 10:05:54 2001
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
Date: Wed, 21 Nov 2001 15:04:35 +0000
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
Content-Length: 848
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: 

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

From jdrosen@dynamicsoft.com  Wed Nov 21 10:10:27 2001
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
Date: Wed, 21 Nov 2001 10:10:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1279
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: 


 

> -----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

From mhammer@cisco.com  Wed Nov 21 10:14:28 2001
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
Date: Wed, 21 Nov 2001 10:10:46 -0500
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
Content-Length: 4657
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: 

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


From rsparks@dynamicsoft.com  Wed Nov 21 10:40:04 2001
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
Date: Wed, 21 Nov 2001 10:39:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1247
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: 

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   

From rsparks@dynamicsoft.com  Wed Nov 21 10:42:20 2001
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
Date: Wed, 21 Nov 2001 10:41:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1335
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: 

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   

From theodore.havinis@openwave.com  Wed Nov 21 11:40:22 2001
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 ???
Date: Wed, 21 Nov 2001 08:44:14 -0800
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: 
Content-Length: 6504
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: 

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
>




From Brian.Rosen@marconi.com  Wed Nov 21 13:38:39 2001
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 ???
Date: Wed, 21 Nov 2001 13:38:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 8821
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: 

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
> 

From bstucker@nortelnetworks.com  Wed Nov 21 14:24:46 2001
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
Date: Wed, 21 Nov 2001 13:23:05 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C172C1.F2126170"
X-Orig: 
Content-Length: 11288
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: 

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--

From jdrosen@dynamicsoft.com  Wed Nov 21 15:00:53 2001
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
Date: Wed, 21 Nov 2001 14:59:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5187
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: 

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 

From jon.peterson@neustar.biz  Wed Nov 21 15:17:21 2001
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
Date: Wed, 21 Nov 2001 14:19:22 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C172C9.CE92E190"
Content-Length: 3872
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: 

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--

From bcampbell@dynamicsoft.com  Wed Nov 21 15:58:19 2001
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>
Date: Wed, 21 Nov 2001 14:55:31 -0600
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
Content-Length: 811
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: 


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.


From theodore.havinis@openwave.com  Wed Nov 21 16:47:28 2001
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 ???
Date: Wed, 21 Nov 2001 13:51:27 -0800
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>
Content-Length: 2481
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: 

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












From jdrosen@dynamicsoft.com  Wed Nov 21 17:06:10 2001
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'" 
Date: Wed, 21 Nov 2001 17:05:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1235
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: 

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
 

From tsearle@antihe.ro  Thu Nov 22 05:52:18 2001
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
Date: Thu, 22 Nov 2001 02:51:54 -0800
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
Content-Length: 1124
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: 

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

From lachlan.brazier@siemens.at  Thu Nov 22 05:56:00 2001
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
Date: Thu, 22 Nov 2001 11:53:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5647
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: 

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

From tsearle@antihe.ro  Thu Nov 22 06:07:38 2001
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
Date: Thu, 22 Nov 2001 03:07:15 -0800
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
Content-Length: 609
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: 

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

From Hakan.Jonsson@bluelabs.se  Fri Nov 23 05:17:21 2001
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: 
Date: Fri, 23 Nov 2001 11:16:54 +0100
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-Length: 1040
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: 

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


From theodore.havinis@openwave.com  Fri Nov 23 10:01:27 2001
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 ???
Date: Fri, 23 Nov 2001 07:05:29 -0800
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>
Content-Length: 9945
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: 


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
>



From bstucker@nortelnetworks.com  Mon Nov 26 03:16:52 2001
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.
Date: Mon, 26 Nov 2001 02:15:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C17652.72765CC0"
X-Orig: 
Content-Length: 23043
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: 

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--

From bstucker@nortelnetworks.com  Mon Nov 26 04:05:47 2001
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.
Date: Mon, 26 Nov 2001 03:04:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C17659.5582FFE0"
Content-Length: 28699
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: 

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--

From HUITEMA@windows.microsoft.com  Sat Nov 24 00:40:03 2001
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.
Date: Fri, 23 Nov 2001 21:38:25 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
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-Length: 6524
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: 

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

From bcampbell@dynamicsoft.com  Mon Nov 26 10:43:03 2001
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>
Date: Mon, 26 Nov 2001 09:39:24 -0600
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
Content-Length: 4298
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: 

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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



From bcampbell@dynamicsoft.com  Mon Nov 26 10:53:43 2001
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>
Date: Mon, 26 Nov 2001 09:50:07 -0600
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
Content-Length: 2333
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: 

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
> 



From adam.roach@ericsson.com  Mon Nov 26 13:10:01 2001
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
Date: Mon, 26 Nov 2001 11:14:23 -0600
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
Content-Length: 6295
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: 

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 
> 


From pkyzivat@cisco.com  Mon Nov 26 13:48:20 2001
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>
Date: Mon, 26 Nov 2001 13:44:53 -0500
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
Content-Length: 2687
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: 

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

From bstucker@nortelnetworks.com  Mon Nov 26 14:17:04 2001
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
Date: Mon, 26 Nov 2001 13:12:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C176AE.53144930"
X-Orig: 
Content-Length: 22259
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: 

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--

From jdrosen@dynamicsoft.com  Mon Nov 26 14:34:06 2001
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
Date: Mon, 26 Nov 2001 14:33:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3248
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: 


 

> -----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

From jdrosen@dynamicsoft.com  Mon Nov 26 14:52:44 2001
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
Date: Mon, 26 Nov 2001 14:42:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2187
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: 


 

> -----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

From rrroy@att.com  Mon Nov 26 15:37:51 2001
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 
Date: Mon, 26 Nov 2001 15:35:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 619
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: 

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  

From jdrosen@dynamicsoft.com  Mon Nov 26 15:45:21 2001
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.
Date: Mon, 26 Nov 2001 15:03:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 3341
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: 


 

> -----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

From jdrosen@dynamicsoft.com  Mon Nov 26 16:06:05 2001
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
Date: Mon, 26 Nov 2001 16:05:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1311
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: 


 

> -----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

From jdrosen@dynamicsoft.com  Mon Nov 26 16:10:57 2001
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
Date: Mon, 26 Nov 2001 16:10:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1861
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: 


 

> -----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

From pkyzivat@cisco.com  Mon Nov 26 16:24:50 2001
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>
Date: Mon, 26 Nov 2001 16:21:20 -0500
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
Content-Length: 7751
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: 

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

From pkyzivat@cisco.com  Mon Nov 26 18:14:02 2001
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>
Date: Mon, 26 Nov 2001 18:10:30 -0500
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
Content-Length: 8978
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: 

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

From pkyzivat@cisco.com  Mon Nov 26 18:37:06 2001
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>
Date: Mon, 26 Nov 2001 18:33:39 -0500
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
Content-Length: 891
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: 

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

From adam.roach@ericsson.com  Mon Nov 26 19:16:49 2001
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
Date: Mon, 26 Nov 2001 18:11:15 -0600
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
Content-Length: 1636
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: 

> 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


From adam.roach@ericsson.com  Mon Nov 26 19:26:50 2001
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
Date: Mon, 26 Nov 2001 17:24:38 -0600
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
Content-Length: 10345
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: 

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
> 


From Hakan.Jonsson@bluelabs.se  Tue Nov 27 03:19:25 2001
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: 
Date: Tue, 27 Nov 2001 09:18:55 +0100
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-Length: 1783
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: 





>> > 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




From jon.peterson@neustar.biz  Tue Nov 27 04:03:37 2001
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 
Date: Tue, 27 Nov 2001 03:05:27 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2899
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: 

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  
> 

From pkyzivat@cisco.com  Tue Nov 27 08:43:06 2001
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>
Date: Tue, 27 Nov 2001 08:39:35 -0500
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
Content-Length: 1995
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: 

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

From rrroy@att.com  Tue Nov 27 10:46:43 2001
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 
Date: Tue, 27 Nov 2001 10:45:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3831
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: 

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  
> 

From Brian.Rosen@marconi.com  Tue Nov 27 17:50:54 2001
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 ???
Date: Tue, 27 Nov 2001 17:50:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 11466
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: 

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
> >
> 
> 

From jdrosen@dynamicsoft.com  Wed Nov 28 00:37:42 2001
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
Date: Wed, 28 Nov 2001 00:37:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 4096
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: 


 

> -----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

From bstucker@nortelnetworks.com  Wed Nov 28 01:16:54 2001
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.
Date: Wed, 28 Nov 2001 00:15:13 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C177D4.0A2BCFA0"
Content-Length: 14965
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: 

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--

From tsearle@antihe.ro  Wed Nov 28 13:07:52 2001
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
Date: Wed, 28 Nov 2001 10:07:26 -0800
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
Content-Length: 190
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: 

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

From bstucker@nortelnetworks.com  Wed Nov 28 13:29:43 2001
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
Date: Wed, 28 Nov 2001 12:26:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1783A.2C131950"
X-Orig: 
Content-Length: 2654
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: 

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--

From rsparks@dynamicsoft.com  Wed Nov 28 16:50:06 2001
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 
Date: Wed, 28 Nov 2001 16:49:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 403
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: 

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


From sean.olson@ericsson.com  Wed Nov 28 17:21:22 2001
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
Date: Wed, 28 Nov 2001 16:20:45 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1785A.ECDC60E0"
Content-Length: 4545
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: 

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--

From pkyzivat@cisco.com  Thu Nov 29 15:04:34 2001
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>
Date: Thu, 29 Nov 2001 15:00:49 -0500
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
Content-Length: 2894
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: 


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

From salvatore.loreto@libero.it  Fri Nov 30 04:18:12 2001
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
Date: 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-Length: 639
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: 

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

From nsyracus@cnri.reston.va.us  Mon Dec  3 08:38:50 2001
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 IAA00987
	for ; Mon, 3 Dec 2001 08:38:50 -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 IAA29173;
	Mon, 3 Dec 2001 08:38:23 -0500 (EST)
Message-Id: <200112031338.IAA29173@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
Date: Mon, 03 Dec 2001 08:38:22 -0500
Content-Length: 3000
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-04.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: SIP Extensions for Presence
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-presence-04.txt
	Pages		: 39
	Date		: 30-Nov-01
	
This document proposes an extension to SIP for subscriptions and
notifications of user presence. User presence is defined as the
willingness and ability of a user to communicate with other users on
the network. Historically, presence has been limited to 'on-line' and
'off-line' indicators; the notion of presence here is broader.
Subscriptions and notifications of user presence are supported by
defining an event package within the general SIP event notification
framework. This protocol is also compliant with the Common Presence
and Instant Messaging (CPIM) framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-presence-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-presence-04.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:	<20011130161204.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20011130161204.I-D@ietf.org>

--OtherAccess--

--NextPart--



From rsparks@dynamicsoft.com  Mon Dec  3 15:55:40 2001
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 PAA02345
	for ; Mon, 3 Dec 2001 15:55: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 fB3Krj4I003714;
	Mon, 3 Dec 2001 15:53:45 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 3 Dec 2001 15:55:14 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E866@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: Robert Sparks ,
        "'simple@mailman.dynamicsoft.com'" 
Cc: "Jon' 'Peterson (E-mail)" ,
        Jonathan Rosenberg 
Subject: RE: [Simple] WGLC - watcherinfo
Date: Mon, 3 Dec 2001 15:55:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1082
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: 

There's been one (1) response to this so far - 
if you have a comment get it in before 12/7.

Please drop a note if you think the draft is
good to go as is so we don't misinterpret silence
as lack of consideration.

RjS

> -----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
> 

From jdrosen@dynamicsoft.com  Tue Dec  4 01:03:47 2001
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 BAA03957
	for ; Tue, 4 Dec 2001 01:03:47 -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 fB461r4I005839;
	Tue, 4 Dec 2001 01:01:53 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Dec 2001 01:03:21 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: Sean Olson ,
        Robert Sparks
	 ,
        "'simple@mailman.dynamicsoft.com'"
	 
Cc: "Jon' 'Peterson (E-mail)" ,
        Jonathan Rosenberg 
Subject: RE: [Simple] WGLC - watcherinfo
Date: Tue, 4 Dec 2001 01:03:17 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2565
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: 


  
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Wednesday, November 28, 2001 5:21 PM
To: 'Robert Sparks'; 'simple@mailman.dynamicsoft.com'
Cc: Jon' 'Peterson (E-mail); Jonathan Rosenberg
Subject: 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.

No, and for much the same reason we have asked for various reason phrases in
the Subscription-Expires header for sip-events. If a subscriptions state
goes to terminated, the reason it went there (rejected vs. deactivated)
makes a difference in the subsequent processing.


> 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. 

Good point. I don't know what I was thinking here. I think its useful to
know when they first subscribed, but as soon as the subscription expires,
this data would be lost, and a new subscription would result in a new
"first-subscribed" value.



>What is the purpose of providing 
>(optionally) the "notify-address" in the winfo? 

If there was a reason, it slips my mind at this time.... I'm happy to remove
it.

-Jonathan R.



>-----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 
> 

---
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

From jdrosen@dynamicsoft.com  Tue Dec  4 01:34:35 2001
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 BAA04076
	for ; Tue, 4 Dec 2001 01:34: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 fB46Wg4I005998;
	Tue, 4 Dec 2001 01:32:42 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Dec 2001 01:34:10 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'salvatore.loreto@libero.it'" ,
        Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
Date: Tue, 4 Dec 2001 01:34:09 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1741
Subject: [Simple] RE: 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: 


 

> -----Original Message-----
> From: salvatore.loreto@libero.it [mailto:salvatore.loreto@libero.it]
> Sent: Friday, November 30, 2001 4:18 AM
> To: jdrosen@dynamicsoft.com
> Cc: simple@mailman.dynamicsoft.com
> Subject: Event header in the Register request
> 
> 
> Hi all,
> 
> In the Scenario "Presence Server with Client 
> notifications",there isn't 
> an Event header in the Register Request.

REGISTER doesn't use Event header, only SUBSCRIBE.


> 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.

We've discussed this previously. There is no way, when you REGISTER with
caller-preferences indicating support for a method (like SUBSCRIBE) to
indicate packages you support. In such a case, the client would simply
reject subscriptions for packages it didn't support with a 489. SHould this
become a real problem, we could always add a caller preferences parameter
for packages, but I think this is a problem in theory only at this time.

-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

From jdrosen@dynamicsoft.com  Tue Dec  4 01:37:38 2001
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 BAA04108
	for ; Tue, 4 Dec 2001 01:37:38 -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 fB46ZU4I006055;
	Tue, 4 Dec 2001 01:35:30 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Dec 2001 01:36:58 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brian Stucker'" ,
        Torrey Searle
	 , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Watcher Information
Date: Tue, 4 Dec 2001 01:36:56 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1619
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: 


  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Wednesday, November 28, 2001 1:26 PM
To: Torrey Searle; simple@mailman.dynamicsoft.com
Subject: 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.

I have argued that I thik there should be a unification between these two,
as they do the same thing. The only difference is that one is "in-band", and
this one is "out of band". However, I agree that in either case, knowing the
expiration time would be useful. I will add an attribute for that.

Thanks,
Jonathan R.



-----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 

---
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

From jdrosen@dynamicsoft.com  Tue Dec  4 01:54:44 2001
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 BAA04196
	for ; Tue, 4 Dec 2001 01:54: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 fB46qo4I006146;
	Tue, 4 Dec 2001 01:52:50 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Dec 2001 01:54:18 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brian Stucker'" ,
        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.
Date: Tue, 4 Dec 2001 01:54:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 6454
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: 


  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Wednesday, November 28, 2001 1:15 AM
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.

>
>Good idea (HTTP url)... 

Thanks.

>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? 

Huh? The request URI of the NOTIFY is determine through standard Route
header processing.


>
>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.

I see no need to define a URL format for each document type. You could
either:

1. subscribe to Event: presence.alert, and the Accept header has type
application/uri-list. The NOTIFY would contain URLs to get at the presence
doc, presumably with HTTP URLs. This is the proposal below.

2. subscribe to Event: presence, and the Accept header has type
application/uri-list, which becomes a valid type for NOTIFY. The NOTIFY
comes with the URL list. This is similar to what I have suggested below, but
uses the same 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.

Right. This is exactly what I have proposed below.

-Jonathan R.
-----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 

---
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

From bstucker@nortelnetworks.com  Tue Dec  4 10:56:42 2001
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 KAA05925
	for ; Tue, 4 Dec 2001 10:56:41 -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 JAA04604
	for ; Tue, 4 Dec 2001 09:56:13 -0600 (CST)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 4 Dec 2001 09:49:01 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 4 Dec 2001 09:54:27 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E010C49FB@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Jonathan Rosenberg ,
        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.
Date: Tue, 4 Dec 2001 09:54:25 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C17CDB.F2B2A300"
X-Orig: 
Content-Length: 19711
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: 

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_01C17CDB.F2B2A300
Content-Type: text/plain;
	charset="iso-8859-1"

Great.

So, we'll have the ability to specify application/url-list in the SUBSCRIBE
for presence events in the -05 draft?

Regards,

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, December 04, 2001 12:54 AM
To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'Michael Hammer'
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.

>
>Good idea (HTTP url)... 

Thanks.

>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? 

Huh? The request URI of the NOTIFY is determine through standard Route
header processing.


>
>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.

I see no need to define a URL format for each document type. You could
either:

1. subscribe to Event: presence.alert, and the Accept header has type
application/uri-list. The NOTIFY would contain URLs to get at the presence
doc, presumably with HTTP URLs. This is the proposal below.

2. subscribe to Event: presence, and the Accept header has type
application/uri-list, which becomes a valid type for NOTIFY. The NOTIFY
comes with the URL list. This is similar to what I have suggested below, but
uses the same 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.

Right. This is exactly what I have proposed below.

-Jonathan R.
-----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 

---
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_01C17CDB.F2B2A300
Content-Type: text/html;
	charset="iso-8859-1"






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




Great.




So, we'll have the ability to specify application/url-list in the SUBSCRIBE for presence events in the -05 draft?




Regards,




Brian




-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Tuesday, December 04, 2001 12:54 AM

To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'Michael Hammer'

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.




>

>Good idea (HTTP url)... 




Thanks.




>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? 




Huh? The request URI of the NOTIFY is determine through standard Route

header processing.






>

>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.




I see no need to define a URL format for each document type. You could

either:




1. subscribe to Event: presence.alert, and the Accept header has type

application/uri-list. The NOTIFY would contain URLs to get at the presence

doc, presumably with HTTP URLs. This is the proposal below.




2. subscribe to Event: presence, and the Accept header has type

application/uri-list, which becomes a valid type for NOTIFY. The NOTIFY

comes with the URL list. This is similar to what I have suggested below, but

uses the same 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.




Right. This is exactly what I have proposed below.




-Jonathan R.

-----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 




---

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_01C17CDB.F2B2A300--

From jdrosen@dynamicsoft.com  Tue Dec  4 11:05:50 2001
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 LAA06006
	for ; Tue, 4 Dec 2001 11:05: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 fB4G3j4I008016;
	Tue, 4 Dec 2001 11:03:45 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Dec 2001 11:05:14 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brian Stucker'" ,
        Jonathan Rosenberg
	 ,
        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.
Date: Tue, 4 Dec 2001 11:05:12 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 6917
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: 


  
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Tuesday, December 04, 2001 10:54 AM
To: Jonathan Rosenberg; 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.


>Great. 
>So, we'll have the ability to specify application/url-list in the SUBSCRIBE
for presence 
>events in the -05 draft? 

Well, we need to decide whether thats really a separate package, or just a
different data format for an existing package.

We also need a few more opinions on this subject, since the list has been
faily quiet of late.

-Jonathan R.

-----Original Message----- 
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent: Tuesday, December 04, 2001 12:54 AM 
To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'Michael Hammer' 
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. 
> 
>Good idea (HTTP url)... 
Thanks. 
>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? 
Huh? The request URI of the NOTIFY is determine through standard Route 
header processing. 


> 
>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. 
I see no need to define a URL format for each document type. You could 
either: 
1. subscribe to Event: presence.alert, and the Accept header has type 
application/uri-list. The NOTIFY would contain URLs to get at the presence 
doc, presumably with HTTP URLs. This is the proposal below. 
2. subscribe to Event: presence, and the Accept header has type 
application/uri-list, which becomes a valid type for NOTIFY. The NOTIFY 
comes with the URL list. This is similar to what I have suggested below, but

uses the same 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. 
Right. This is exactly what I have proposed below. 
-Jonathan R. 
-----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 

From seancolson@yahoo.com  Tue Dec  4 11:09:23 2001
Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA06046
	for ; Tue, 4 Dec 2001 11:09:22 -0500 (EST)
Message-ID: <20011204160857.76457.qmail@web11603.mail.yahoo.com>
Received: from [208.237.135.21] by web11603.mail.yahoo.com via HTTP; Tue, 04 Dec 2001 08:08:57 PST
Date: Tue, 4 Dec 2001 08:08:57 -0800 (PST)
From: Sean Olson 
Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP.
To: Jonathan Rosenberg ,
        "'Brian Stucker'" ,
        "'Michael Hammer'" 
Cc: "'adam.roach@ericsson.com'" ,
        simple ,
        Alex Nava ,
        Patrick Sollee ,
        Sanjoy Sen 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 6122
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: 

This is a great idea. I don't see the need
to make this a different package, however.
There are good mechanisms in SIP to negotiate
payloads. This should be sufficient for this
purpose.

/sean

--- Jonathan Rosenberg 
wrote:
> 
> 
>   
> -----Original Message-----
> From: Brian Stucker
> [mailto:bstucker@nortelnetworks.com]
> Sent: Tuesday, December 04, 2001 10:54 AM
> To: Jonathan Rosenberg; 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.
> 
> 
> >Great. 
> >So, we'll have the ability to specify
> application/url-list in the SUBSCRIBE
> for presence 
> >events in the -05 draft? 
> 
> Well, we need to decide whether thats really a
> separate package, or just a
> different data format for an existing package.
> 
> We also need a few more opinions on this subject,
> since the list has been
> faily quiet of late.
> 
> -Jonathan R.
> 
> -----Original Message----- 
> From: Jonathan Rosenberg
> [mailto:jdrosen@dynamicsoft.com] 
> Sent: Tuesday, December 04, 2001 12:54 AM 
> To: Stucker, Brian [NGB:B635:EXCH]; Jonathan
> Rosenberg; 'Michael Hammer' 
> 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. 
> > 
> >Good idea (HTTP url)... 
> Thanks. 
> >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? 
> Huh? The request URI of the NOTIFY is determine
> through standard Route 
> header processing. 
> 
> 
> > 
> >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. 
> I see no need to define a URL format for each
> document type. You could 
> either: 
> 1. subscribe to Event: presence.alert, and the
> Accept header has type 
> application/uri-list. The NOTIFY would contain URLs
> to get at the presence 
> doc, presumably with HTTP URLs. This is the proposal
> below. 
> 2. subscribe to Event: presence, and the Accept
> header has type 
> application/uri-list, which becomes a valid type for
> NOTIFY. The NOTIFY 
> comes with the URL list. This is similar to what I
> have suggested below, but
> 
> uses the same 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. 
> Right. This is exactly what I have proposed below. 
> -Jonathan R. 
> -----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. 
> > 
> 
=== message truncated ===


=====
--
Sean Olson 
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com

From lachlan.brazier@siemens.at  Tue Dec  4 11:32:29 2001
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 LAA06144
	for ; Tue, 4 Dec 2001 11:32:28 -0500 (EST)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id fB4GVwT28231;
	Tue, 4 Dec 2001 17:31:58 +0100
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id RAA24562;
	Tue, 4 Dec 2001 17:31:56 +0100 (MET)
Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta)
	id xma024099; Tue, 4 Dec 01 17:31:38 +0100
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Dec 2001 17:31:33 +0100
Message-ID: 
From: Brazier Lachlan 
To: "'Jonathan Rosenberg'" ,
        "'Brian Stucker'"
	 ,
        "'Michael Hammer'" 
Cc: "'adam.roach@ericsson.com'" ,
        simple
	 ,
        Alex Nava ,
        Patrick Sollee ,
        Sanjoy Sen
	 
Subject: AW: [Simple] RE: Question regarding NOTIFY messages using UDP.
Date: Tue, 4 Dec 2001 17:31:31 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 671
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: 

Hello,

> 
> >Great. 
> >So, we'll have the ability to specify application/url-list 
> in the SUBSCRIBE
> for presence 
> >events in the -05 draft? 
> 
> Well, we need to decide whether thats really a separate 
> package, or just a
> different data format for an existing package.
> 
> We also need a few more opinions on this subject, since the 
> list has been
> faily quiet of late.
> 

does this mean that in the NOTIFY there is no cpim-xpidf+xml document but a
URI or a list of URI's where the client can get the cpim-xpidf+xml document
with HTTP or whatever is specified?

I this correct?
If yes, sounds beautiful. Haven't thought about the packages yet.


Lachlan

From jdrosen@dynamicsoft.com  Tue Dec  4 11:33:02 2001
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 LAA06153
	for ; Tue, 4 Dec 2001 11:33:02 -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 fB4GV64I008340;
	Tue, 4 Dec 2001 11:31:06 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Dec 2001 11:32:35 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Paul Kyzivat'" , adam.roach@ericsson.com
Cc: Jonathan Rosenberg ,
        "'Brian Stucker'"
	 ,
        simple 
Subject: RE: [Simple] 200 vs. 202
Date: Tue, 4 Dec 2001 11:32:27 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 3469
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: 


 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, November 27, 2001 8:40 AM
> To: adam.roach@ericsson.com
> Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; simple
> Subject: Re: [Simple] 200 vs. 202
> 
> 
> 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.

Well, the problem is that we are trying to add forking capabilities into a
method thats not ideally suited for it. Given the frequency that I
realistically expect to see forking SUBSCRIBE, I am not too worried.


> As you 
> say, this
> is really an events issue, not a SIMPLE issue. 

Do we have consensus though? I'd like to declare this issue resolved. Adam's
proposal was to accept the first NOTIFY, and ignore the 2xx. I'd like to
suggest a mild variant to that that I think is even simpler. My proposal is
to accept whatever comes first. If you get a 2xx to SUBSCRIBE first, that
establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes first,
you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE may or may
not be for the dialog that was accepted; it doesn't really matter.

Agreement?

-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

> 
> 	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
> 

From hgs@cs.columbia.edu  Tue Dec  4 11:40:26 2001
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06224
	for ; Tue, 4 Dec 2001 11:40:25 -0500 (EST)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fB4GdeV22207;
	Tue, 4 Dec 2001 11:39:41 -0500 (EST)
Message-ID: <3C0CFC4C.F7D6E86B@cs.columbia.edu>
Date: Tue, 04 Dec 2001 11:39:40 -0500
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Brazier Lachlan 
CC: "'Jonathan Rosenberg'" ,
        "'Brian Stucker'" ,
        "'Michael Hammer'" ,
        "'adam.roach@ericsson.com'" ,
        simple ,
        Alex Nava ,
        Patrick Sollee ,
        Sanjoy Sen 
Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 958
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: 

Brazier Lachlan wrote:
> 

> does this mean that in the NOTIFY there is no cpim-xpidf+xml document but a
> URI or a list of URI's where the client can get the cpim-xpidf+xml document
> with HTTP or whatever is specified?
> 
> I this correct?
> If yes, sounds beautiful. Haven't thought about the packages yet.

As long as you consider the practical problems. For example, you now
need to have the ability to "reach back" to the web server of the
notifier. You need to coordinate authentication. If you used hop-by-hop
transitive trust, that won't work any more and you'll have to resort to
a shared secret, either via TLS from the notified party or standard HTTP
Digest, making sure that the passwords are properly aligned. Also, how
long is the URL valid? Forever? Until the subscription expires?

I'm not against coupling protocols, but one shouldn't ignore the
practical complications that arise.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From jdrosen@dynamicsoft.com  Tue Dec  4 11:41:24 2001
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 LAA06249
	for ; Tue, 4 Dec 2001 11:41: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 fB4GdS4I008563;
	Tue, 4 Dec 2001 11:39:28 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Dec 2001 11:40:57 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Brazier Lachlan'" ,
        Jonathan Rosenberg
	 ,
        "'Brian Stucker'" ,
        "'Michael Hammer'" 
Cc: "'adam.roach@ericsson.com'" ,
        simple
	 ,
        Alex Nava ,
        Patrick Sollee ,
        Sanjoy Sen
	 
Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP.
Date: Tue, 4 Dec 2001 11:40:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2492
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: 


 

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Tuesday, December 04, 2001 11:32 AM
> To: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer'
> Cc: 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick 
> Sollee; Sanjoy
> Sen
> Subject: AW: [Simple] RE: Question regarding NOTIFY messages 
> using UDP.
> 
> 
> Hello,
> 
> > 
> > >Great. 
> > >So, we'll have the ability to specify application/url-list 
> > in the SUBSCRIBE
> > for presence 
> > >events in the -05 draft? 
> > 
> > Well, we need to decide whether thats really a separate 
> > package, or just a
> > different data format for an existing package.
> > 
> > We also need a few more opinions on this subject, since the 
> > list has been
> > faily quiet of late.
> > 
> 
> does this mean that in the NOTIFY there is no cpim-xpidf+xml 
> document but a
> URI or a list of URI's where the client can get the 
> cpim-xpidf+xml document
> with HTTP or whatever is specified?
> 
> I this correct?

Yes.

> If yes, sounds beautiful. Haven't thought about the packages yet.

Let me state the proposal for those who haven't been following the thread.
The current proposal on the table is to allow the SUBSCRIBE to have an
Accept header that contains application/uri-list as a valid type for NOTIFY.
So:

SUBSCRIBE sip:user@domain SIP/2.0
Event: presence
Accept: application/cpim-pidf+xml;q=0.5, application/uri-list;q=1.0

This would ask for notifications preferably as URLs. A NOTIFY would have:

NOTIFY sip:subscriber@domain SIP/2.0
Event: presence
Content-Type: application/uri-list
Content-Length: 23

http://www.domain.com/user/pdoc.xml

And then you would use HTTP to fetch the document. This way, you could have
arbitrarily large documents that would not need to be transferred with SIP. 

We would probably need to define a baseline url scheme (presumably http) to
guarantee interop. Certainly, other URLs, even LDAP say, could be provided.

This is not presence specific, to be honest, and is more useful for event
types with large data formats. I don't expect presence docs to be that large
in general.

-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

From jdrosen@dynamicsoft.com  Tue Dec  4 11:46:17 2001
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 LAA06316
	for ; Tue, 4 Dec 2001 11:46:17 -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 fB4Ghk4I008653;
	Tue, 4 Dec 2001 11:43:46 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Dec 2001 11:45:15 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Henning G. Schulzrinne'" ,
        Brazier Lachlan
	 
Cc: Jonathan Rosenberg ,
        "'Brian Stucker'"
	 ,
        "'Michael Hammer'" ,
        "'adam.roach@ericsson.com'" ,
        simple
	 ,
        Alex Nava ,
        Patrick Sollee ,
        Sanjoy Sen
	 
Subject: RE: AW: [Simple] RE: Question regarding NOTIFY messages using UDP
	.
Date: Tue, 4 Dec 2001 11:45:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1990
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: 


 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, December 04, 2001 11:40 AM
> To: Brazier Lachlan
> Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer';
> 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee; 
> Sanjoy Sen
> Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using
> UDP.
> 
> 
> Brazier Lachlan wrote:
> > 
> 
> > does this mean that in the NOTIFY there is no 
> cpim-xpidf+xml document but a
> > URI or a list of URI's where the client can get the 
> cpim-xpidf+xml document
> > with HTTP or whatever is specified?
> > 
> > I this correct?
> > If yes, sounds beautiful. Haven't thought about the packages yet.
> 
> As long as you consider the practical problems. For example, you now
> need to have the ability to "reach back" to the web server of the
> notifier. You need to coordinate authentication. If you used 
> hop-by-hop
> transitive trust, that won't work any more and you'll have to 
> resort to
> a shared secret, either via TLS from the notified party or 
> standard HTTP
> Digest, making sure that the passwords are properly aligned.

Good point.

If you've been using transitive trust, though, the URL in the NOTIFY may
have been encrypted at each hop, so merely using that URL (so long as it has
sufficient randomness encoded in it) provides some amount of authentication.
Not perfect, for sure.


> Also, how
> long is the URL valid? Forever? Until the subscription expires?

We would need to specify that. I would argue that the URL fetches the
current presence doc until the subscription expires.

-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

From hgs@cs.columbia.edu  Tue Dec  4 11:55:33 2001
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06396
	for ; Tue, 4 Dec 2001 11:55:33 -0500 (EST)
Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.10.2+Sun/8.9.3) with ESMTP id fB4Gt7V23093;
	Tue, 4 Dec 2001 11:55:07 -0500 (EST)
Message-ID: <3C0CFFEB.2ECE561C@cs.columbia.edu>
Date: Tue, 04 Dec 2001 11:55:07 -0500
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: simple 
Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2721
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: 

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Tuesday, December 04, 2001 11:40 AM
> > To: Brazier Lachlan
> > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer';
> > 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee;
> > Sanjoy Sen
> > Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using
> > UDP.
> >
> >
> > Brazier Lachlan wrote:
> > >
> >
> > > does this mean that in the NOTIFY there is no
> > cpim-xpidf+xml document but a
> > > URI or a list of URI's where the client can get the
> > cpim-xpidf+xml document
> > > with HTTP or whatever is specified?
> > >
> > > I this correct?
> > > If yes, sounds beautiful. Haven't thought about the packages yet.
> >
> > As long as you consider the practical problems. For example, you now
> > need to have the ability to "reach back" to the web server of the
> > notifier. You need to coordinate authentication. If you used
> > hop-by-hop
> > transitive trust, that won't work any more and you'll have to
> > resort to
> > a shared secret, either via TLS from the notified party or
> > standard HTTP
> > Digest, making sure that the passwords are properly aligned.
> 
> Good point.
> 
> If you've been using transitive trust, though, the URL in the NOTIFY may
> have been encrypted at each hop, so merely using that URL (so long as it has
> sufficient randomness encoded in it) provides some amount of authentication.
> Not perfect, for sure.

It also means that the notified party has to support TLS to prevent
disclosure of the presence document.

In the pure SIP case, it's viable to have the "WAN" hops use TLS, while
the last hop, hopefully on a more trusted network, may not.

> 
> > Also, how
> > long is the URL valid? Forever? Until the subscription expires?
> 
> We would need to specify that. I would argue that the URL fetches the
> current presence doc until the subscription expires.
> 

Plus caching behavior.

I suspect the biggest problem will be the "get back to notifier" issue.
Effectively, you now have to have a public-Internet web server that the
notifier can control. Since you need to not just create documents but
also delete them after expiration, you need WebDAV or some proprietary
cgi interface, or also implement ftp (and know the file structure of the
server). (Updating the authorization table on the public-Internet web
server will be even messier, since there's no published protocol for
doing that.)

Thus, what seems like a simple proposal ("just include the URL") becomes
just a tad more complicated if you consider all the things that can go
wrong.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

From AVSHALOM@il.ibm.com  Wed Dec  5 08:41:28 2001
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10142;
	Wed, 5 Dec 2001 08:41:27 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id OAA13936;
	Wed, 5 Dec 2001 14:41:00 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB5DfIt98078;
	Wed, 5 Dec 2001 14:41:18 +0100
To: "Henning G. Schulzrinne" 
Cc: Jonathan Rosenberg ,
        simple ,
        simple-admin@mailman.dynamicsoft.com
MIME-Version: 1.0
Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP.
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Wed, 5 Dec 2001 15:41:03 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
 05/12/2001 15:41:13,
	Serialize complete at 05/12/2001 15:41:13
Content-Type: multipart/alternative; boundary="=_alternative 004B28DDC2256B19_="
Content-Length: 9757
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: 

This is a multipart message in MIME format.
--=_alternative 004B28DDC2256B19_=
Content-Type: text/plain; charset="us-ascii"

I agree with Henning. It will become very difficult to deploy. Maybe the 
SUBSCRIBE request can contain an hint whether
the subscribing UA would accept notifies with URLs. This way domains that 
took the trouble to deploy the web server etc.
will be able to optimize it only for clients that can support fetching the 
URL.

------------------------
Avshalom Houri
Lotus Sametime
IBM Software Group

Building 18/D, Science Park
Kiryat Weizmann, P.O. Box 2523
Rehovot 76123 Israel

Email: avshalom@il.ibm.com
Office: +972-8-9409761 X123
Fax: +972-8-9409768
Mobile: +972-54-686021






"Henning G. Schulzrinne" 
Sent by: simple-admin@mailman.dynamicsoft.com
04/12/2001 18:55

 
        To:        Jonathan Rosenberg 
        cc:        simple 
        Subject:        Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP.

 

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Tuesday, December 04, 2001 11:40 AM
> > To: Brazier Lachlan
> > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer';
> > 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee;
> > Sanjoy Sen
> > Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using
> > UDP.
> >
> >
> > Brazier Lachlan wrote:
> > >
> >
> > > does this mean that in the NOTIFY there is no
> > cpim-xpidf+xml document but a
> > > URI or a list of URI's where the client can get the
> > cpim-xpidf+xml document
> > > with HTTP or whatever is specified?
> > >
> > > I this correct?
> > > If yes, sounds beautiful. Haven't thought about the packages yet.
> >
> > As long as you consider the practical problems. For example, you now
> > need to have the ability to "reach back" to the web server of the
> > notifier. You need to coordinate authentication. If you used
> > hop-by-hop
> > transitive trust, that won't work any more and you'll have to
> > resort to
> > a shared secret, either via TLS from the notified party or
> > standard HTTP
> > Digest, making sure that the passwords are properly aligned.
> 
> Good point.
> 
> If you've been using transitive trust, though, the URL in the NOTIFY may
> have been encrypted at each hop, so merely using that URL (so long as it 
has
> sufficient randomness encoded in it) provides some amount of 
authentication.
> Not perfect, for sure.

It also means that the notified party has to support TLS to prevent
disclosure of the presence document.

In the pure SIP case, it's viable to have the "WAN" hops use TLS, while
the last hop, hopefully on a more trusted network, may not.

> 
> > Also, how
> > long is the URL valid? Forever? Until the subscription expires?
> 
> We would need to specify that. I would argue that the URL fetches the
> current presence doc until the subscription expires.
> 

Plus caching behavior.

I suspect the biggest problem will be the "get back to notifier" issue.
Effectively, you now have to have a public-Internet web server that the
notifier can control. Since you need to not just create documents but
also delete them after expiration, you need WebDAV or some proprietary
cgi interface, or also implement ftp (and know the file structure of the
server). (Updating the authorization table on the public-Internet web
server will be even messier, since there's no published protocol for
doing that.)

Thus, what seems like a simple proposal ("just include the URL") becomes
just a tad more complicated if you consider all the things that can go
wrong.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple



--=_alternative 004B28DDC2256B19_=
Content-Type: text/html; charset="us-ascii"



I agree with Henning. It will become very difficult to deploy. Maybe the SUBSCRIBE request can contain an hint whether

the subscribing UA would accept notifies with URLs. This way domains that took the trouble to deploy the web server etc.

will be able to optimize it only for clients that can support fetching the URL.



------------------------

Avshalom Houri

Lotus Sametime

IBM Software Group



Building 18/D, Science Park

Kiryat Weizmann, P.O. Box 2523

Rehovot 76123 Israel



Email: avshalom@il.ibm.com

Office: +972-8-9409761 X123

Fax: +972-8-9409768

Mobile: +972-54-686021















"Henning G. Schulzrinne" <hgs@cs.columbia.edu>

Sent by: simple-admin@mailman.dynamicsoft.com

04/12/2001 18:55



        

        To:        Jonathan Rosenberg <jdrosen@dynamicsoft.com>

        cc:        simple <simple@mailman.dynamicsoft.com>

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



       




Jonathan Rosenberg wrote:

> 

> 

> 

> > -----Original Message-----

> > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]

> > Sent: Tuesday, December 04, 2001 11:40 AM

> > To: Brazier Lachlan

> > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; 'Michael Hammer';

> > 'adam.roach@ericsson.com'; simple; Alex Nava; Patrick Sollee;

> > Sanjoy Sen

> > Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using

> > UDP.

> >

> >

> > Brazier Lachlan wrote:

> > >

> >

> > > does this mean that in the NOTIFY there is no

> > cpim-xpidf+xml document but a

> > > URI or a list of URI's where the client can get the

> > cpim-xpidf+xml document

> > > with HTTP or whatever is specified?

> > >

> > > I this correct?

> > > If yes, sounds beautiful. Haven't thought about the packages yet.

> >

> > As long as you consider the practical problems. For example, you now

> > need to have the ability to "reach back" to the web server of the

> > notifier. You need to coordinate authentication. If you used

> > hop-by-hop

> > transitive trust, that won't work any more and you'll have to

> > resort to

> > a shared secret, either via TLS from the notified party or

> > standard HTTP

> > Digest, making sure that the passwords are properly aligned.

> 

> Good point.

> 

> If you've been using transitive trust, though, the URL in the NOTIFY may

> have been encrypted at each hop, so merely using that URL (so long as it has

> sufficient randomness encoded in it) provides some amount of authentication.

> Not perfect, for sure.



It also means that the notified party has to support TLS to prevent

disclosure of the presence document.



In the pure SIP case, it's viable to have the "WAN" hops use TLS, while

the last hop, hopefully on a more trusted network, may not.



> 

> > Also, how

> > long is the URL valid? Forever? Until the subscription expires?

> 

> We would need to specify that. I would argue that the URL fetches the

> current presence doc until the subscription expires.

> 



Plus caching behavior.



I suspect the biggest problem will be the "get back to notifier" issue.

Effectively, you now have to have a public-Internet web server that the

notifier can control. Since you need to not just create documents but

also delete them after expiration, you need WebDAV or some proprietary

cgi interface, or also implement ftp (and know the file structure of the

server). (Updating the authorization table on the public-Internet web

server will be even messier, since there's no published protocol for

doing that.)



Thus, what seems like a simple proposal ("just include the URL") becomes

just a tad more complicated if you consider all the things that can go

wrong.

-- 

Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple






--=_alternative 004B28DDC2256B19_=--

From seancolson@yahoo.com  Wed Dec  5 10:25:24 2001
Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA10485
	for ; Wed, 5 Dec 2001 10:25:23 -0500 (EST)
Message-ID: <20011205152457.64783.qmail@web11606.mail.yahoo.com>
Received: from [208.237.135.21] by web11606.mail.yahoo.com via HTTP; Wed, 05 Dec 2001 07:24:57 PST
Date: Wed, 5 Dec 2001 07:24:57 -0800 (PST)
From: Sean Olson 
Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using UDP.
To: Avshalom Houri ,
        "Henning G. Schulzrinne" 
Cc: Jonathan Rosenberg ,
        simple ,
        simple-admin@mailman.dynamicsoft.com
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 4586
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: 

We call this the "Accept" header. It is very
straightforward. I don't think this is any more
difficult to deploy than a pure SIP solution and
it very nicely solves the problem of large messages.

/sean

--- Avshalom Houri  wrote:
> I agree with Henning. It will become very difficult
> to deploy. Maybe the 
> SUBSCRIBE request can contain an hint whether
> the subscribing UA would accept notifies with URLs.
> This way domains that 
> took the trouble to deploy the web server etc.
> will be able to optimize it only for clients that
> can support fetching the 
> URL.
> 
> ------------------------
> Avshalom Houri
> Lotus Sametime
> IBM Software Group
> 
> Building 18/D, Science Park
> Kiryat Weizmann, P.O. Box 2523
> Rehovot 76123 Israel
> 
> Email: avshalom@il.ibm.com
> Office: +972-8-9409761 X123
> Fax: +972-8-9409768
> Mobile: +972-54-686021
> 
> 
> 
> 
> 
> 
> "Henning G. Schulzrinne" 
> Sent by: simple-admin@mailman.dynamicsoft.com
> 04/12/2001 18:55
> 
>  
>         To:        Jonathan Rosenberg
> 
>         cc:        simple
> 
>         Subject:        Re: AW: [Simple] RE:
> Question regarding NOTIFY messages using UDP.
> 
>  
> 
> Jonathan Rosenberg wrote:
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Henning G. Schulzrinne
> [mailto:hgs@cs.columbia.edu]
> > > Sent: Tuesday, December 04, 2001 11:40 AM
> > > To: Brazier Lachlan
> > > Cc: 'Jonathan Rosenberg'; 'Brian Stucker';
> 'Michael Hammer';
> > > 'adam.roach@ericsson.com'; simple; Alex Nava;
> Patrick Sollee;
> > > Sanjoy Sen
> > > Subject: Re: AW: [Simple] RE: Question regarding
> NOTIFY messages using
> > > UDP.
> > >
> > >
> > > Brazier Lachlan wrote:
> > > >
> > >
> > > > does this mean that in the NOTIFY there is no
> > > cpim-xpidf+xml document but a
> > > > URI or a list of URI's where the client can
> get the
> > > cpim-xpidf+xml document
> > > > with HTTP or whatever is specified?
> > > >
> > > > I this correct?
> > > > If yes, sounds beautiful. Haven't thought
> about the packages yet.
> > >
> > > As long as you consider the practical problems.
> For example, you now
> > > need to have the ability to "reach back" to the
> web server of the
> > > notifier. You need to coordinate authentication.
> If you used
> > > hop-by-hop
> > > transitive trust, that won't work any more and
> you'll have to
> > > resort to
> > > a shared secret, either via TLS from the
> notified party or
> > > standard HTTP
> > > Digest, making sure that the passwords are
> properly aligned.
> > 
> > Good point.
> > 
> > If you've been using transitive trust, though, the
> URL in the NOTIFY may
> > have been encrypted at each hop, so merely using
> that URL (so long as it 
> has
> > sufficient randomness encoded in it) provides some
> amount of 
> authentication.
> > Not perfect, for sure.
> 
> It also means that the notified party has to support
> TLS to prevent
> disclosure of the presence document.
> 
> In the pure SIP case, it's viable to have the "WAN"
> hops use TLS, while
> the last hop, hopefully on a more trusted network,
> may not.
> 
> > 
> > > Also, how
> > > long is the URL valid? Forever? Until the
> subscription expires?
> > 
> > We would need to specify that. I would argue that
> the URL fetches the
> > current presence doc until the subscription
> expires.
> > 
> 
> Plus caching behavior.
> 
> I suspect the biggest problem will be the "get back
> to notifier" issue.
> Effectively, you now have to have a public-Internet
> web server that the
> notifier can control. Since you need to not just
> create documents but
> also delete them after expiration, you need WebDAV
> or some proprietary
> cgi interface, or also implement ftp (and know the
> file structure of the
> server). (Updating the authorization table on the
> public-Internet web
> server will be even messier, since there's no
> published protocol for
> doing that.)
> 
> Thus, what seems like a simple proposal ("just
> include the URL") becomes
> just a tad more complicated if you consider all the
> things that can go
> wrong.
> -- 
> Henning Schulzrinne  
> http://www.cs.columbia.edu/~hgs
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 
> 


=====
--
Sean Olson 
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Buy the perfect holiday gifts at Yahoo! Shopping.
http://shopping.yahoo.com

From jdrosen@dynamicsoft.com  Wed Dec  5 11:01:17 2001
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 LAA10636
	for ; Wed, 5 Dec 2001 11:01:16 -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 fB5Fwo4I014708;
	Wed, 5 Dec 2001 10:58:50 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 5 Dec 2001 11:00:20 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Henning G. Schulzrinne'" ,
        Jonathan Rosenberg
	 
Cc: simple 
Subject: RE: AW: [Simple] RE: Question regarding NOTIFY messages using UDP
	.
Date: Wed, 5 Dec 2001 11:00:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1720
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: 


 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, December 04, 2001 11:55 AM
> To: Jonathan Rosenberg
> Cc: simple
> Subject: Re: AW: [Simple] RE: Question regarding NOTIFY messages using
> UDP.
> 
> > > Also, how
> > > long is the URL valid? Forever? Until the subscription expires?
> > 
> > We would need to specify that. I would argue that the URL 
> fetches the
> > current presence doc until the subscription expires.
> > 
> 
> Plus caching behavior.
> 
> I suspect the biggest problem will be the "get back to 
> notifier" issue.
> Effectively, you now have to have a public-Internet web 
> server that the
> notifier can control. Since you need to not just create documents but
> also delete them after expiration, you need WebDAV or some proprietary
> cgi interface, or also implement ftp (and know the file 
> structure of the
> server). (Updating the authorization table on the public-Internet web
> server will be even messier, since there's no published protocol for
> doing that.)

Sure; this will require a system with some HTTP/SIP integration. That does
exist already in some products. The whole thing is optional, of course; you
still have to support the presence doc. But, if the server supports this
capability, and the client indicates that they do as well, it can be used.

-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

From bcampbell@dynamicsoft.com  Wed Dec  5 14:53:06 2001
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 OAA11369
	for ; Wed, 5 Dec 2001 14:53:06 -0500 (EST)
Received: from rocinante (rocinante [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fB5JoxA02547;
	Wed, 5 Dec 2001 13:50:59 -0600
Subject: RE: [Simple] WGLC - watcherinfo
From: Ben Campbell 
To: jdrosen@dynamicsoft.com, Robert Sparks 
Cc: simple@mailman.dynamicsoft.com
In-Reply-To: 
	<9BF66EBF6BEFD942915B4D4D45C051F338E866@DYN-TX-EXCH-001.dynamicsoft.com>
References: 
	<9BF66EBF6BEFD942915B4D4D45C051F338E866@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0 (Preview Release)
Date: 05 Dec 2001 13:50:58 -0600
Message-Id: <1007581859.1876.13.camel@rocinante>
Mime-Version: 1.0
Content-Length: 2339
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: 

OK after re-reading this, I have a couple of comments on section 3.6.1
(the FSM section.)

1)  [tiny nit] The state diagram shows a timeout transition between
 and . I don't find anything about that in the text
treatment.

2) Some of the FSM description really seems more a description of the
authorization FSM rather than the watcher info notification FSM. In
particular, the treatment of pending vs. waiting suggests behavior on
the part of the SIP-event service beyond that of watcher reporting. This
section seems more descriptive than normative, so that is probably okay.

3) I know this has come up many times before, and I don't remember the
resolution. Apologies if I am beating a dead horse: I have some concern
about the concept of keeping state around indefinitely for pending
watchers. Could this not be used as a DoS against the server? It's not
nearly so bad as keeping state for denied users, but the threat may
still be there.




On Mon, 2001-12-03 at 14:55, Robert Sparks wrote:
> There's been one (1) response to this so far - 
> if you have a comment get it in before 12/7.
> 
> Please drop a note if you think the draft is
> good to go as is so we don't misinterpret silence
> as lack of consideration.
> 
> RjS
> 
> > -----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
> > 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple



From jdrosen@dynamicsoft.com  Wed Dec  5 15:08:54 2001
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 PAA11464
	for ; Wed, 5 Dec 2001 15:08: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 fB5JvT4I016058;
	Wed, 5 Dec 2001 14:57:30 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 5 Dec 2001 14:59:00 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Fairlie-Cuninghame, Robert'" ,
        "'Brian Stucker'"
	 ,
        Jonathan Rosenberg
	 ,
        "'Bert Culpepper'"
	 ,
        adam.roach@ericsson.com
Cc: "'sip@ietf.org'" ,
        "'simple@mailman.dynamicsoft.com'"
	 
Date: Wed, 5 Dec 2001 14:58:59 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3495
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: 

I'm cc'ing SIMPLE since this is a joint issue that affects both the
watcherinfo work and sip-events. Also, sip-events is a sip work item, not
sipping, so I am changing the list to sip.
 

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
> Sent: Wednesday, November 28, 2001 2:00 PM
> To: 'Brian Stucker'; Jonathan Rosenberg; 'Bert Culpepper';
> adam.roach@ericsson.com
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01
> 
> 
> This sounds like a good suggestion to me Brian.
> 
> I would like to suggest the watherinfo reason codes are 
> expanded a little.
> For instance, the watcherinfo assumes that the pending states 
> is waiting for
> authorization. It could however be pending while waiting for 
> the subscribed
> object to become active (note: I am not referring to the 
> subscribed Event
> package here). This sort of behavior may be typical/useful 
> when you are
> trying to subscribe to an event that has not started yet (and 
> yet you desire
> to have the subscription in place _before_ the event begins). 

OK, but in this case, the subscription itself is not pending, its the state
of the object that is effectively "TBD". This should be reflected in the
presence document delivered in the first NOTIFY, not in the state of the
subscription, IMHO.


> I also think
> the rejection/termination reasons could be expanded a little more.

Suggestions?


Brian Stucker wrote:
> 
> I can't see much use in including the 
> event field since
> (presumably) the watcher will know what event triggered the 
> NOTIFY, and if
> they can't, they can use watcherinfo to get it.

No, these are not events of the presentity, they are events of the
subscription. These events correspond quite closely to the "reason"
parameters Adam has currently specified. In fact, for the rejecttion events,
here is the mapping:

sip-events      watcherinfo
----------      -----------
migration  <->   deactivated
maint      <->    ?
refused    <->   rejected
timeout    <->   expired
 ?         <->   timeout

Clearly, these should be aligned, and should be present in both the
SUbscription-Expires and the watcherinfo format. 

Its not clear to me what the semantics of maint are; should the client retry
after some period? Presuming we can define it conciesely, we should add it
to the watcherinfo package. 

So, here would be my proposal for the unified set:

deactivated: subscription is terminated, but client SHOULD retry immediately
with a new subscription. This handles migration plus other cases
potentially.

probation: subscription is terminated; but client SHOULD retry at some later
time (we could include a Retry-After header in the case of presence in the
Subscription-Expires header)

rejected: subscription terminated due to change in authorization policy.
Retrying will not help.

timeout: subscription terminated because it was not refreshed. 

giveup: could not obtain authorization in a timely fashion, and so the
pending subscription is being terminated. The client can retry and will
likely get put back into pending state.

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

From pkyzivat@cisco.com  Thu Dec  6 17:02:25 2001
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 RAA16135
	for ; Thu, 6 Dec 2001 17:02:24 -0500 (EST)
Received: from cannonat.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 fB6M23c13826;
	Thu, 6 Dec 2001 17:02:03 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannonat.cisco.com (Mirapoint)
	with ESMTP id AAF37188 (AUTH pkyzivat);
	Thu, 6 Dec 2001 17:03:21 -0500 (EST)
Message-ID: <3C0FEA08.1EB987FB@cisco.com>
Date: Thu, 06 Dec 2001 16:58:32 -0500
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: adam.roach@ericsson.com, "'Brian Stucker'" ,
        simple 
Subject: Re: [Simple] 200 vs. 202
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2278
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: 


Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Tuesday, November 27, 2001 8:40 AM
> > To: adam.roach@ericsson.com
> > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; simple
> > Subject: Re: [Simple] 200 vs. 202
> >
> >
> > 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.
> 
> Well, the problem is that we are trying to add forking capabilities into a
> method thats not ideally suited for it.

Can't argue with that. It's unfortunate that we have a forking mechanism
that really only works for INVITE even though it is defined for other
methods and (as we see here) is potentially wanted/needed for them as
well.

> Given the frequency that I
> realistically expect to see forking SUBSCRIBE, I am not too worried.

As devices are deployed that support presence, it seems like there
could develop a problem with undesired forking. You want forking
for invites, and perhaps don't have any simple way to prevent
forking of subscribes as well.

This won't be a problem if the presence function is combined with the
registrar function and driven off registrations. But it will be a
problem with devices that want to handle presence themselves, like the
MS endpoint. All you need is people with both a desktop and laptop
machine that try to maintain one identity for both.

> 
> > As you
> > say, this
> > is really an events issue, not a SIMPLE issue.
> 
> Do we have consensus though? I'd like to declare this issue resolved. Adam's
> proposal was to accept the first NOTIFY, and ignore the 2xx. I'd like to
> suggest a mild variant to that that I think is even simpler. My proposal is
> to accept whatever comes first. If you get a 2xx to SUBSCRIBE first, that
> establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes first,
> you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE may or may
> not be for the dialog that was accepted; it doesn't really matter.
> 
> Agreement?

I don't have a preference between those two alternatives.

I won't stop progress by continuing to argue, but I don't find either
solution very appealing. 

	Paul

From jdrosen@dynamicsoft.com  Fri Dec  7 04:45:46 2001
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 EAA18269
	for ; Fri, 7 Dec 2001 04:45:46 -0500 (EST)
Received: from attrh2i.attrh.att.com ([135.37.94.56])
	by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB79jJW19070
	for ; Fri, 7 Dec 2001 04:45:19 -0500 (EST)
Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh2i.attrh.att.com (5.5.029)
        id 3C06942A001DFBFA; Fri, 7 Dec 2001 04:44:48 -0500
Received: from mail pickup service by occlust04evs1.ugd.att.com with Microsoft SMTPSVC;
	 Fri, 7 Dec 2001 04:44:40 -0500
Received: from occlust02evs1.ugd.att.com ([135.71.164.9]) by occlust04evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.2966);	 Wed, 5 Dec 2001 17:19:02 -0500
Received:  from attrh2i.attrh.att.com ([135.37.94.56]) by mo3980bh3.ems.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YJB1AS9A; Wed, 5 Dec 2001 14:10:18 -0600
Received:  from wsscan.att.com (135.37.94.53) by attrh2i.attrh.att.com (5.5.029) id 3C06942A0013905C for rrroy@ems.att.com; Wed, 5 Dec 2001 15:10:16 -0500
Received:  by wsscan.att.com; id PAA24192; Wed, 5 Dec 2001 15:14:46 -0500 (EST)
Received:  from almsi1.proxy.att.com(192.168.109.69) by cyrus5.wsscan.att.com via csmap (V4.1) id srcAAAtia4pV; Wed, 5 Dec 01 15:14:45 -0500
Received:  from mail1.dynamicsoft.com ([63.113.40.10]) by almsi1.proxy.att.com (AT&T IPNS/MSI-3.0) with ESMTP id fB5KAFG09686 for ; Wed, 5 Dec 2001 15:10: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 fB5K7J4S016205; Wed, 5 Dec 2001 15:08: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 PAA11483; Wed, 5 Dec 2001 15:09: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 PAA11464 for ; Wed, 5 Dec 2001 15:08: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 fB5JvT4I016058; Wed, 5 Dec 2001 14:57:30 -0500 (EST)
MIME-Version: 1.0
Received:  by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 14:59:00 -0500
Content-Type: application/ms-tnef;	name="winmail.dat"
Content-Transfer-Encoding: binary
content-class: urn:content-classes:message
Subject: [Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01
Date: Wed, 5 Dec 2001 14:58:59 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01
X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0
Thread-Index: AcF9yNxQnMe8SOm7EdWjbgCQJ60IGQ==
From: "Jonathan Rosenberg" 
To: "Fairlie-Cuninghame, Robert" ,
        "Brian Stucker" ,
        "Jonathan Rosenberg" ,
        "Bert Culpepper" ,
        
Cc: , 
X-OriginalArrivalTime: 05 Dec 2001 22:19:02.0728 (UTC) FILETIME=[D83CA480:01C17DDA]
Content-Length: 4676
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: 

xŸ>"&ä耀Ñ:;o €Ñ19	€!47BCC79CBBE9D511A36E009027AD0819;|0:'Fairlie-Cuninghame, Robert'0
SMTP0&rfairlie@nuera.com0@:0SMTP:RFAIRLIE@NUERA.COM ::'Fairlie-Cuninghame, Robert'0 'Brian Stucker'0
SMTP08bstucker@nortelnetworks.com0@:0!SMTP:BSTUCKER@NORTELNETWORKS.COM : 'Brian Stucker'0&Jonathan Rosenberg0
SMTP00jdrosen@dynamicsoft.com0@:A0SMTP:JDROSEN@DYNAMICSOFT.COM :&Jonathan Rosenberg0"'Bert Culpepper'0
SMTP0Hbert.culpepper@intervoice-brite.com0@:0)SMTP:BERT.CULPEPPER@INTERVOICE-BRITE.COM :"'Bert Culpepper'00adam.roach@ericsson.com0
SMTP00adam.roach@ericsson.com0@:FO0SMTP:ADAM.ROACH@ERICSSON.COM :0adam.roach@ericsson.com0'sip@ietf.org'0
SMTP0sip@ietf.org0@:0SMTP:SIP@IETF.ORG :'sip@ietf.org'0B'simple@mailman.dynamicsoft.com'0
SMTP0>simple@mailman.dynamicsoft.com0@:FO0$SMTP:SIMPLE@MAILMAN.DYNAMICSOFT.COM :B'simple@mailman.dynamicsoft.com'A
¸'IPM.NOTE&67„[Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01@9€ƒ9GÇ}Á=p„[Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01qÁ}ÈÜPœÇ¼Hé»Õ£n'­&Jonathan Rosenberg„[Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01			OLZFuíu6ü
rcpg125â2CtexA÷ÿ
€¤ä€óPV?U²%Qchá
Àset2Ã%ö3F·0,3ï	÷¶;05"`cPó	d36P¦
ã
€€I'm cc'€gIMPLE nce th ña jo€@×
PÁa@a ^t àÐÁeôw— PÐqn w°k@ndap-ev	ð Ð.Àlso^,#)#1"”i°mÝ$0n!ô#1pÁ$1ý"€I@qàÐÂ!Ql l@t"€#1.Gôåô> -*ÂO(!@ÐsagÖe*Ã*FFa:,Ðpær(°,CuÐà·€$0b@[À#):rf-T@n‘
Pra. m]*FW`0- W	€ndäay$0No#€ÐL28$0Ð012°:Q3 PM*FT/P L'B! StÐká'; J  P'ñëñn.¡g5p4€.²q-Àlpe&ð5B*Fa™1àm.`Ðh@qžc 0R*FCc- ­&Õ@0.°g0§˜ubj ±- RE- T[S&ä]'€m€d0°°OTIFI¾Eð'ã°€#)-3 »*F@.Tâ$-Ðd g(°50Agop`uvg+ð(Ði (ò€ ÿ4“)e@ˆ'" 7@#Bc¿)C4(c!á"& a9aÿ€q1 @—À
°#O	€A(°@leD‡Fÿ±€(Ðp $0G"ÿH ð‚ 3(r7`#ÂÿK‘°!*Uñ!à%àÂ5r7çuаiz÷ PC‘#ÐI@ EÒQ Þw#qÀ. NwàJ€ïOº@—(rðbò. 1ÿ*d.#Y&#w¦N£]²!Wçh*$0HO)e)ì'‘ó$ÂnkTÊ ¸PûNðàÖVÝãScÿ’Xâ!`7P{û¯5ä_ågÿWAPðˆ¢@!àdY!vŸ!` ±)ê( #€up- ÿRXâ.æßðò²sÿ/€sð{c"óYÓu•N6×ýÿ. (3Κƒ¿¦’¢ÚÅ#ß‚ôBbs”plQ×`Ÿ5 ?)N+{ûTHp¾k¢ö5˜{ÿ§cüÍD#Ðc6'$0Ph.M7½@E+àSÑú1A#€ý)eCà Ãá—‘(Ñk¿IFx3F°PVdþy+`9@]À¯	?p(Ñüa2Ar2J 0Ì79 °´jd€6Až@™0R	OCAX- !¦(973Œ 95ð2-50࣢@ïà¨//wð..1°ë?¦P{ÐN<±J3÷/°´_ÿÚ&v~mÔP¤SÀÂ(²ê@/½¡Ÿ:O$v/[(²"R/D°´}!à5CzDö,Eú,òó[Simple] RE%3A [Sipping] Immediate NOTIFIES change in sip-events-01.EMLôõö@0z'PÜÈ}Á@0l
Ë—Ñ}ÁÞ?¯oß?ÿÿÿÿñ?ø?DInternet Mail Service (MO3980BH3)ù?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (MO3980BH3)ú?DInternet Mail Service (MO3980BH3)û?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (MO3980BH3)ý?ä@@0@0jdrosen@dynamicsoft.com1@0jdrosen@dynamicsoft.com8@HINTERNET MAIL CONNECTOR (MO3980BH3)9@0jdrosen@dynamicsoft.com)#H{ 

From lachlan.brazier@siemens.at  Fri Dec  7 06:16:49 2001
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 GAA18762
	for ; Fri, 7 Dec 2001 06:16:48 -0500 (EST)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id fB7BGKT08287;
	Fri, 7 Dec 2001 12:16:20 +0100
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id MAA25344;
	Fri, 7 Dec 2001 12:16:19 +0100 (MET)
Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta)
	id xma022225; Fri, 7 Dec 01 12:14:21 +0100
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id ; Fri, 7 Dec 2001 12:14:18 +0100
Message-ID: 
From: Brazier Lachlan 
To: "'Paul Kyzivat '" ,
        "'Jonathan Rosenberg '"
	 
Cc: "'adam.roach@ericsson.com '" ,
        "''Brian Stucker' '" ,
        "'simple '"
	 
Subject: AW: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 12:14:17 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 2275
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: 

Hello,

I believe the subscriber SHOULD keep all NOTIFY messages which arrive before
the response to the SUBSCRIBE arives. After receiving the response the
subscriber can decide which way to handle the NOTIFY's.

1) Only accept NOTIFY's which fit to the response

2) Accept all NOTIFY's (problem with DoS? - Is it one with firewalls?)

3) Accept only a subset of the NOTIFY's (based on some local policy)

If the subscriber doesn't want to wait for the response to the SUBSCRIBE,
and NOTIFY's arrive before the response, it has the possibilities:

1) Accept the first NOTIFY and ignore the response

2) Accept all NOTIFY's and ignore the response

3) Accept only a subset of the NOTIFY's

4) Accept no NOTIFY. When the response to the SUBSCRIBE arrives, subscribe
again, but then accept the NOTIFY from the sender from the first SUBSCRIBE.
( NOTE: I DON'T propose that)

There was the proposal to accept the dialog which arrives first, be it
response or NOTIFY.


Did I forget another possibility? I think all of them work. Basically all of
them depend on a kind of local policy and on the kind of application, which
shouldn't be controlled anyway by the protocol.

So I vote for 1) as default procedure.

Lachlan


-----Originalnachricht-----
Von: Paul Kyzivat
An: Jonathan Rosenberg
Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
Gesendet: 06.12.01 22:58
Betreff: Re: [Simple] 200 vs. 202

[SNIP]

> 
> Do we have consensus though? I'd like to declare this issue resolved.
Adam's
> proposal was to accept the first NOTIFY, and ignore the 2xx. I'd like
to
> suggest a mild variant to that that I think is even simpler. My
proposal is
> to accept whatever comes first. If you get a 2xx to SUBSCRIBE first,
that
> establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes
first,
> you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE may
or may
> not be for the dialog that was accepted; it doesn't really matter.
> 
> Agreement?

I don't have a preference between those two alternatives.

I won't stop progress by continuing to argue, but I don't find either
solution very appealing. 

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

From adam.roach@ericsson.com  Fri Dec  7 11:17:39 2001
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 LAA19697
	for ; Fri, 7 Dec 2001 11:17:39 -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 fB7GGaH03496;
	Fri, 7 Dec 2001 10:16:37 -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 fB7GGa609114;
	Fri, 7 Dec 2001 10:16: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 KAA21923; Fri, 7 Dec 2001 10:16:35 -0600 (CST)
Reply-To: 
To: "'Christian Huitema'" ,
        "Brazier Lachlan" ,
        "Paul Kyzivat " ,
        "Jonathan Rosenberg " 
Cc: ,
        "'Brian Stucker' " ,
        "simple " 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 10:16:34 -0600
Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF1@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: 
Content-Length: 523
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: 

> From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> 
> So, It seems that much boils down to the expectations of the 
> subscriber,
> and its ability to sort out the mess created by a forking proxy. Do we
> want to add a header line in SIP, such as:
> 
> 	Fork-with-me: Don't you dare
> 
> This would clearly tell proxies to not fork around...

On a more serious note, I often lament the absence of a
"Forking-Proxy-Require" header in the base spec.

But I guess it's too late to do anything about that.

/a


From adam.roach@ericsson.com  Fri Dec  7 11:30:48 2001
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 LAA19761
	for ; Fri, 7 Dec 2001 11:30:48 -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 fB7GDaY18328;
	Fri, 7 Dec 2001 10:13: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 fB7GDaS19701;
	Fri, 7 Dec 2001 10:13: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 KAA21629; Fri, 7 Dec 2001 10:13:35 -0600 (CST)
Reply-To: 
To: "'Brazier Lachlan'" ,
        "'Paul Kyzivat '" ,
        "'Jonathan Rosenberg '" 
Cc: ,
        "''Brian Stucker' '" ,
        "'simple '" 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 10:13:33 -0600
Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF0@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: 
Content-Length: 2956
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: 

Brian:

I can't tell what you're proposing, since you have two points
labelled as "1)." I like the second "1)" just fine, and the
variant in which the first dialog-establishing message (2xx
or NOTIFY) just as well.

/a

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Friday, December 07, 2001 5:14 AM
> To: 'Paul Kyzivat '; 'Jonathan Rosenberg '
> Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple '
> Subject: AW: [Simple] 200 vs. 202
> 
> 
> Hello,
> 
> I believe the subscriber SHOULD keep all NOTIFY messages 
> which arrive before
> the response to the SUBSCRIBE arives. After receiving the response the
> subscriber can decide which way to handle the NOTIFY's.
> 
> 1) Only accept NOTIFY's which fit to the response
> 
> 2) Accept all NOTIFY's (problem with DoS? - Is it one with firewalls?)
> 
> 3) Accept only a subset of the NOTIFY's (based on some local policy)
> 
> If the subscriber doesn't want to wait for the response to 
> the SUBSCRIBE,
> and NOTIFY's arrive before the response, it has the possibilities:
> 
> 1) Accept the first NOTIFY and ignore the response
> 
> 2) Accept all NOTIFY's and ignore the response
> 
> 3) Accept only a subset of the NOTIFY's
> 
> 4) Accept no NOTIFY. When the response to the SUBSCRIBE 
> arrives, subscribe
> again, but then accept the NOTIFY from the sender from the 
> first SUBSCRIBE.
> ( NOTE: I DON'T propose that)
> 
> There was the proposal to accept the dialog which arrives first, be it
> response or NOTIFY.
> 
> 
> Did I forget another possibility? I think all of them work. 
> Basically all of
> them depend on a kind of local policy and on the kind of 
> application, which
> shouldn't be controlled anyway by the protocol.
> 
> So I vote for 1) as default procedure.
> 
> Lachlan
> 
> 
> -----Originalnachricht-----
> Von: Paul Kyzivat
> An: Jonathan Rosenberg
> Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
> Gesendet: 06.12.01 22:58
> Betreff: Re: [Simple] 200 vs. 202
> 
> [SNIP]
> 
> > 
> > Do we have consensus though? I'd like to declare this issue 
> resolved.
> Adam's
> > proposal was to accept the first NOTIFY, and ignore the 
> 2xx. I'd like
> to
> > suggest a mild variant to that that I think is even simpler. My
> proposal is
> > to accept whatever comes first. If you get a 2xx to SUBSCRIBE first,
> that
> > establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes
> first,
> > you accept that. Any other NOTIFY are 481'd. The 2xx to 
> SUBSCRIBE may
> or may
> > not be for the dialog that was accepted; it doesn't really matter.
> > 
> > Agreement?
> 
> I don't have a preference between those two alternatives.
> 
> I won't stop progress by continuing to argue, but I don't find either
> solution very appealing. 
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 


From oran@cisco.com  Fri Dec  7 11:38:10 2001
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19819
	for ; Fri, 7 Dec 2001 11:38:10 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fB7GZ5903705;
	Fri, 7 Dec 2001 08:37:28 -0800 (PST)
Received: from oranlt ([161.44.238.54])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ABP08767;
	Fri, 7 Dec 2001 08:35:09 -0800 (PST)
From: "David R. Oran" 
To: ,
        "'Christian Huitema'" ,
        "'Brazier Lachlan'" ,
        "'Paul Kyzivat '" ,
        "'Jonathan Rosenberg '" 
Cc: "''Brian Stucker' '" ,
        "'simple '" 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 11:35:02 -0500
Organization: Cisco Systems
Message-ID: <017501c17f3d$2048a950$36ee2ca1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3311
In-reply-to: <61D824C63B99D311975E00508B0CC98502C66CF1@eamrcnt717.exu.ericsson.se>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 2430
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: 

There's a set of caller preferences to control forking. From
draft-ietf-caller-pref-04.txt:


        fork-feature: This feature indicates whether a proxy should fork
             a request, or proxy to only a single address. If the server
             is requested not to fork, the server SHOULD proxy the
             request to the "best" address (generally the one with the
             highest q value). The feature is ignored if "redirect" has
             been requested.

There's also:

       recurse-feature: This feature indicates whether a proxy server
             receiving a 300-class response should send requests to the
             addresses listed in the response (i.e., recurse), or
             forward the list of addresses upstream towards the caller.
             The feature is ignored if "redirect" has been requested.

        parallel-feature: For a forking proxy server, this feature
             indicates whether the caller would like the proxy server to
             proxy the request to all known addresses at once, or go
             through them sequentially, contacting the next address only
             after it has received a non-200 or non-600 final response
             for the previous one. The feature is ignored if "redirect"
             has been requested.

Dave.

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com 
> [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of 
> adam.roach@ericsson.com
> Sent: Friday, December 07, 2001 11:17 AM
> To: 'Christian Huitema'; Brazier Lachlan; Paul Kyzivat ; 
> Jonathan Rosenberg 
> Cc: adam.roach@ericsson.com; 'Brian Stucker' ; simple 
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> > 
> > So, It seems that much boils down to the expectations of the
> > subscriber,
> > and its ability to sort out the mess created by a forking 
> proxy. Do we
> > want to add a header line in SIP, such as:
> > 
> > 	Fork-with-me: Don't you dare
> > 
> > This would clearly tell proxies to not fork around...
> 
> On a more serious note, I often lament the absence of a 
> "Forking-Proxy-Require" header in the base spec.
> 
> But I guess it's too late to do anything about that.
> 
> /a
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com 
> http://mailman.dynamicsoft.com/mailman/listinf> o/simple
> 


From lachlan.brazier@siemens.at  Fri Dec  7 11:44:49 2001
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 LAA19866
	for ; Fri, 7 Dec 2001 11:44:48 -0500 (EST)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id fB7GiLT13250;
	Fri, 7 Dec 2001 17:44:21 +0100
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id RAA03477;
	Fri, 7 Dec 2001 17:44:19 +0100 (MET)
Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta)
	id xma003286; Fri, 7 Dec 01 17:44:09 +0100
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id ; Fri, 7 Dec 2001 17:44:07 +0100
Message-ID: 
From: Brazier Lachlan 
To: "'adam.roach@ericsson.com '" ,
        Brazier Lachlan ,
        "''Paul Kyzivat ' '"
	 ,
        "''Jonathan Rosenberg ' '" 
Cc: "'''Brian Stucker' ' '" ,
        "''simple ' '"
	 
Subject: AW: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 17:44:05 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3275
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: 

Ups, sorry,

I meant
1) Only accept NOTIFY's which fit to the response

Lachlan 

-----Originalnachricht-----
Von: adam.roach@ericsson.com
An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg '
Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple '
Gesendet: 07.12.01 17:13
Betreff: RE: [Simple] 200 vs. 202

Brian:

I can't tell what you're proposing, since you have two points
labelled as "1)." I like the second "1)" just fine, and the
variant in which the first dialog-establishing message (2xx
or NOTIFY) just as well.

/a

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Friday, December 07, 2001 5:14 AM
> To: 'Paul Kyzivat '; 'Jonathan Rosenberg '
> Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple '
> Subject: AW: [Simple] 200 vs. 202
> 
> 
> Hello,
> 
> I believe the subscriber SHOULD keep all NOTIFY messages 
> which arrive before
> the response to the SUBSCRIBE arives. After receiving the response the
> subscriber can decide which way to handle the NOTIFY's.
> 
> 1) Only accept NOTIFY's which fit to the response
> 
> 2) Accept all NOTIFY's (problem with DoS? - Is it one with firewalls?)
> 
> 3) Accept only a subset of the NOTIFY's (based on some local policy)
> 
> If the subscriber doesn't want to wait for the response to 
> the SUBSCRIBE,
> and NOTIFY's arrive before the response, it has the possibilities:
> 
> 1) Accept the first NOTIFY and ignore the response
> 
> 2) Accept all NOTIFY's and ignore the response
> 
> 3) Accept only a subset of the NOTIFY's
> 
> 4) Accept no NOTIFY. When the response to the SUBSCRIBE 
> arrives, subscribe
> again, but then accept the NOTIFY from the sender from the 
> first SUBSCRIBE.
> ( NOTE: I DON'T propose that)
> 
> There was the proposal to accept the dialog which arrives first, be it
> response or NOTIFY.
> 
> 
> Did I forget another possibility? I think all of them work. 
> Basically all of
> them depend on a kind of local policy and on the kind of 
> application, which
> shouldn't be controlled anyway by the protocol.
> 
> So I vote for 1) as default procedure.
> 
> Lachlan
> 
> 
> -----Originalnachricht-----
> Von: Paul Kyzivat
> An: Jonathan Rosenberg
> Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
> Gesendet: 06.12.01 22:58
> Betreff: Re: [Simple] 200 vs. 202
> 
> [SNIP]
> 
> > 
> > Do we have consensus though? I'd like to declare this issue 
> resolved.
> Adam's
> > proposal was to accept the first NOTIFY, and ignore the 
> 2xx. I'd like
> to
> > suggest a mild variant to that that I think is even simpler. My
> proposal is
> > to accept whatever comes first. If you get a 2xx to SUBSCRIBE first,
> that
> > establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes
> first,
> > you accept that. Any other NOTIFY are 481'd. The 2xx to 
> SUBSCRIBE may
> or may
> > not be for the dialog that was accepted; it doesn't really matter.
> > 
> > Agreement?
> 
> I don't have a preference between those two alternatives.
> 
> I won't stop progress by continuing to argue, but I don't find either
> solution very appealing. 
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jdrosen@dynamicsoft.com  Fri Dec  7 11:50:08 2001
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 LAA19911
	for ; Fri, 7 Dec 2001 11:50:08 -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 fB7GmB4I027887
	for ; Fri, 7 Dec 2001 11:48:12 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 7 Dec 2001 11:49:43 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: Ben Campbell ,
        Jonathan Rosenberg
	 ,
        Robert Sparks 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] WGLC - watcherinfo
Date: Fri, 7 Dec 2001 11:49:40 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 5000
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: 


 

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Wednesday, December 05, 2001 2:51 PM
> To: jdrosen@dynamicsoft.com; Robert Sparks
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] WGLC - watcherinfo
> 
> 
> 
> OK after re-reading this, I have a couple of comments on section 3.6.1
> (the FSM section.)
> 
> 1)  [tiny nit] The state diagram shows a timeout transition between
>  and . I don't find anything about that 
> in the text
> treatment.

It is in there:

   Of course, policy may never be specified for the subscription. As a
   result, the server can timeout the waiting subscription. The value
   for this timeout is system dependent. It SHOULD be several times
   larger than the default expiration time for the package being
   watched.

Its not clear that this is the timeout event. I've reworded to:

   Of course, policy may never be specified for the subscription. As a
   result, the server can generate a timeout event to move the waiting
   subscription to the terminated state. The value for this timeout is
   system dependent. It {\SHOULD} be several times larger than the
   default expiration time for the package being watched.


> 
> 2) Some of the FSM description really seems more a description of the
> authorization FSM rather than the watcher info notification FSM. In
> particular, the treatment of pending vs. waiting suggests behavior on
> the part of the SIP-event service beyond that of watcher 
> reporting. This
> section seems more descriptive than normative, so that is 
> probably okay.

The section heading is a misnomer. You are right that this FSM is NOT the
description of the winfo FSM. Its a descrption of the FSM for sip-events in
general, or at least a model of that FSM, as a well-defined model is needed
for the watcherinfo package to work. That definitely needs to be clarified.
I updated the text at the top of 3.6 to say:

   Notifications may be generated for watcher information on package foo,
   when the subscription state for a user on package foo changes. The
   watcher information package therefore needs a model of subscription
   state. This is accomplished by specifying a subscription state
   machine, described below, which governs the
   subscription state of a user in any package. Notifications are
   generated on transitions in this state machine. Its important to note
   that this FSM is just a model of the subscription state machinery
   maintained by a server. An implementation would map its own state
   machines to this one in an implementation-specific manner.

and I changed the title of 3.6.1 to "The Subscription State Machine"

> 
> 3) I know this has come up many times before, and I don't remember the
> resolution. Apologies if I am beating a dead horse: I have 
> some concern
> about the concept of keeping state around indefinitely for pending
> watchers. Could this not be used as a DoS against the server? It's not
> nearly so bad as keeping state for denied users, but the threat may
> still be there.

I don't recall what conclusions were made from past discussions.

I do think that it needs to be a policy decision. Remember, we are talking
about authenticated, but not authorized, subscriptions, so that the room for
DoS attacks is narrowed. Of course they can still happen. So, you want the
server to be able to make a policy decision. It should be allowed to move
the subscription to terminated at any time. The "timeout" event exists from
the waiting state to terminated for this reason, but also needs to exist at
the "pending" to "terminated" transition as an allowed event. I will add
that. The spec also says that the server SHOULD set the timeout interval to
be much larger than the refresh interval for subscriptions; i will temper
that to discuss making it shorter to handle potential dos attacks.

So, I added the following text:

   The ``timeout'' event is generated in either the waiting or pending
   states to destroy resources associated with unauthorized
   subscriptions. Servers need to exercise care in selecting this
   value. It needs to be large in order to provide a useful user
   experience; a presentity should be able to log in days later and see
   that someone tried to subscribe to them. However, allocating state to
   unauthorized subscriptions can be used as a source of DoS
   attacks. Therefore, it is RECOMMENDED that servers which retain state
   for unauthorized subscriptions add policies which prohibit a
   particular subscriber from having more than some number of pending or
   waiting subscriptions. 


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

From adam.roach@ericsson.com  Fri Dec  7 11:54:07 2001
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 LAA19975
	for ; Fri, 7 Dec 2001 11:54:07 -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 fB7Gq7H01091;
	Fri, 7 Dec 2001 10:52:07 -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 fB7Gq7S14220;
	Fri, 7 Dec 2001 10:52: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 KAA25742; Fri, 7 Dec 2001 10:52:06 -0600 (CST)
Reply-To: 
To: "'Brazier Lachlan'" ,
        , "''Paul Kyzivat ' '" ,
        "''Jonathan Rosenberg ' '" 
Cc: "'''Brian Stucker' ' '" ,
        "''simple ' '" 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 10:52:06 -0600
Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF3@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: 
Content-Length: 4164
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: 

Ah. In that case, I'm going to have to disagree for the
exact same reasons that I objected when Jonathan proposed
this: it's more complicated to implement, and the NOTIFY
that corresponds to the final response doesn't have any
special meaning. It's no better than any other NOTIFY.

Keep it simple. (No pun intended).

/a

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Friday, December 07, 2001 10:44 AM
> To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul Kyzivat ' ';
> ''Jonathan Rosenberg ' '
> Cc: '''Brian Stucker' ' '; ''simple ' '
> Subject: AW: [Simple] 200 vs. 202
> 
> 
> Ups, sorry,
> 
> I meant
> 1) Only accept NOTIFY's which fit to the response
> 
> Lachlan 
> 
> -----Originalnachricht-----
> Von: adam.roach@ericsson.com
> An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg '
> Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple '
> Gesendet: 07.12.01 17:13
> Betreff: RE: [Simple] 200 vs. 202
> 
> Brian:
> 
> I can't tell what you're proposing, since you have two points
> labelled as "1)." I like the second "1)" just fine, and the
> variant in which the first dialog-establishing message (2xx
> or NOTIFY) just as well.
> 
> /a
> 
> > -----Original Message-----
> > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > Sent: Friday, December 07, 2001 5:14 AM
> > To: 'Paul Kyzivat '; 'Jonathan Rosenberg '
> > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple '
> > Subject: AW: [Simple] 200 vs. 202
> > 
> > 
> > Hello,
> > 
> > I believe the subscriber SHOULD keep all NOTIFY messages 
> > which arrive before
> > the response to the SUBSCRIBE arives. After receiving the 
> response the
> > subscriber can decide which way to handle the NOTIFY's.
> > 
> > 1) Only accept NOTIFY's which fit to the response
> > 
> > 2) Accept all NOTIFY's (problem with DoS? - Is it one with 
> firewalls?)
> > 
> > 3) Accept only a subset of the NOTIFY's (based on some local policy)
> > 
> > If the subscriber doesn't want to wait for the response to 
> > the SUBSCRIBE,
> > and NOTIFY's arrive before the response, it has the possibilities:
> > 
> > 1) Accept the first NOTIFY and ignore the response
> > 
> > 2) Accept all NOTIFY's and ignore the response
> > 
> > 3) Accept only a subset of the NOTIFY's
> > 
> > 4) Accept no NOTIFY. When the response to the SUBSCRIBE 
> > arrives, subscribe
> > again, but then accept the NOTIFY from the sender from the 
> > first SUBSCRIBE.
> > ( NOTE: I DON'T propose that)
> > 
> > There was the proposal to accept the dialog which arrives 
> first, be it
> > response or NOTIFY.
> > 
> > 
> > Did I forget another possibility? I think all of them work. 
> > Basically all of
> > them depend on a kind of local policy and on the kind of 
> > application, which
> > shouldn't be controlled anyway by the protocol.
> > 
> > So I vote for 1) as default procedure.
> > 
> > Lachlan
> > 
> > 
> > -----Originalnachricht-----
> > Von: Paul Kyzivat
> > An: Jonathan Rosenberg
> > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
> > Gesendet: 06.12.01 22:58
> > Betreff: Re: [Simple] 200 vs. 202
> > 
> > [SNIP]
> > 
> > > 
> > > Do we have consensus though? I'd like to declare this issue 
> > resolved.
> > Adam's
> > > proposal was to accept the first NOTIFY, and ignore the 
> > 2xx. I'd like
> > to
> > > suggest a mild variant to that that I think is even simpler. My
> > proposal is
> > > to accept whatever comes first. If you get a 2xx to 
> SUBSCRIBE first,
> > that
> > > establishes a dialog. All other NOTIFYs are 481d. If a 
> NOTIFY comes
> > first,
> > > you accept that. Any other NOTIFY are 481'd. The 2xx to 
> > SUBSCRIBE may
> > or may
> > > not be for the dialog that was accepted; it doesn't really matter.
> > > 
> > > Agreement?
> > 
> > I don't have a preference between those two alternatives.
> > 
> > I won't stop progress by continuing to argue, but I don't 
> find either
> > solution very appealing. 
> > 
> > 	Paul
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 


From jdrosen@dynamicsoft.com  Fri Dec  7 12:04:44 2001
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 MAA20081
	for ; Fri, 7 Dec 2001 12:04: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 fB7H2l4I028162;
	Fri, 7 Dec 2001 12:02:47 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 7 Dec 2001 12:04:18 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'Paul Kyzivat'" ,
        Jonathan Rosenberg
	 
Cc: adam.roach@ericsson.com, "'Brian Stucker'" ,
        simple 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 12:04:14 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 3293
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: 


 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, December 06, 2001 4:59 PM
> To: Jonathan Rosenberg
> Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
> Subject: Re: [Simple] 200 vs. 202
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > Sent: Tuesday, November 27, 2001 8:40 AM
> > > To: adam.roach@ericsson.com
> > > Cc: 'Jonathan Rosenberg'; 'Brian Stucker'; simple
> > > Subject: Re: [Simple] 200 vs. 202
> > >
> > >
> > > 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.
> > 
> > Well, the problem is that we are trying to add forking 
> capabilities into a
> > method thats not ideally suited for it.
> 
> Can't argue with that. It's unfortunate that we have a 
> forking mechanism
> that really only works for INVITE even though it is defined for other
> methods and (as we see here) is potentially wanted/needed for them as
> well.

Well, there are some who think it doesn't work for INVITE all that well
either ;)

Its not clear that you really want it in this scenario, to be honest. If you
did, I might argue that we would need to define a "session presence" model
that used INVITE to establish a presence session with a peer, with the SDP
containing a place to send notifies..... I am not proposing that, mind you.

> 
> > Given the frequency that I
> > realistically expect to see forking SUBSCRIBE, I am not too worried.
> 
> As devices are deployed that support presence, it seems like there
> could develop a problem with undesired forking. You want forking
> for invites, and perhaps don't have any simple way to prevent
> forking of subscribes as well.
> 
> This won't be a problem if the presence function is combined with the
> registrar function and driven off registrations. 

It has nothing to do with being driven off of registrations; it has to do
with whether the PA function is network or UA located. 

> But it will be a
> problem with devices that want to handle presence themselves, like the
> MS endpoint. All you need is people with both a desktop and laptop
> machine that try to maintain one identity for both.

Well, I have argued that for these cases, you just need to impose the
restriction that if you want multiple end system based-PA, you need to have
an aggregation point somewhere in the network. No system today allows for
multiple independent clients to generate presence data for a single
identity, LET ALONE having them do it without a server. So, user and network
admin. expectations are already far below what we can do.


> I won't stop progress by continuing to argue, but I don't find either
> solution very appealing. 

I welcome an alternative workable proposal, as always....

-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

From jdrosen@dynamicsoft.com  Fri Dec  7 12:19:32 2001
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 MAA20168
	for ; Fri, 7 Dec 2001 12:19: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 fB7H7P4I028212;
	Fri, 7 Dec 2001 12:07:25 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 7 Dec 2001 12:08:54 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'adam.roach@ericsson.com'" ,
        "'Brazier Lachlan'" ,
        "''Paul Kyzivat ' '"
	 ,
        Jonathan Rosenberg 
Cc: "'''Brian Stucker' ' '" ,
        "''simple ' '"
	 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 12:08:49 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5272
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: 

What was the problem with my proposal to accept what comes first (200 or
NOTIFY)? Seems to consistently work and be really simple...

-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: Friday, December 07, 2001 11:52 AM
> To: 'Brazier Lachlan'; adam.roach@ericsson.com; ''Paul Kyzivat ' ';
> ''Jonathan Rosenberg ' '
> Cc: '''Brian Stucker' ' '; ''simple ' '
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> Ah. In that case, I'm going to have to disagree for the
> exact same reasons that I objected when Jonathan proposed
> this: it's more complicated to implement, and the NOTIFY
> that corresponds to the final response doesn't have any
> special meaning. It's no better than any other NOTIFY.
> 
> Keep it simple. (No pun intended).
> 
> /a
> 
> > -----Original Message-----
> > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > Sent: Friday, December 07, 2001 10:44 AM
> > To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul Kyzivat ' ';
> > ''Jonathan Rosenberg ' '
> > Cc: '''Brian Stucker' ' '; ''simple ' '
> > Subject: AW: [Simple] 200 vs. 202
> > 
> > 
> > Ups, sorry,
> > 
> > I meant
> > 1) Only accept NOTIFY's which fit to the response
> > 
> > Lachlan 
> > 
> > -----Originalnachricht-----
> > Von: adam.roach@ericsson.com
> > An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg '
> > Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple '
> > Gesendet: 07.12.01 17:13
> > Betreff: RE: [Simple] 200 vs. 202
> > 
> > Brian:
> > 
> > I can't tell what you're proposing, since you have two points
> > labelled as "1)." I like the second "1)" just fine, and the
> > variant in which the first dialog-establishing message (2xx
> > or NOTIFY) just as well.
> > 
> > /a
> > 
> > > -----Original Message-----
> > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > > Sent: Friday, December 07, 2001 5:14 AM
> > > To: 'Paul Kyzivat '; 'Jonathan Rosenberg '
> > > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple '
> > > Subject: AW: [Simple] 200 vs. 202
> > > 
> > > 
> > > Hello,
> > > 
> > > I believe the subscriber SHOULD keep all NOTIFY messages 
> > > which arrive before
> > > the response to the SUBSCRIBE arives. After receiving the 
> > response the
> > > subscriber can decide which way to handle the NOTIFY's.
> > > 
> > > 1) Only accept NOTIFY's which fit to the response
> > > 
> > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with 
> > firewalls?)
> > > 
> > > 3) Accept only a subset of the NOTIFY's (based on some 
> local policy)
> > > 
> > > If the subscriber doesn't want to wait for the response to 
> > > the SUBSCRIBE,
> > > and NOTIFY's arrive before the response, it has the possibilities:
> > > 
> > > 1) Accept the first NOTIFY and ignore the response
> > > 
> > > 2) Accept all NOTIFY's and ignore the response
> > > 
> > > 3) Accept only a subset of the NOTIFY's
> > > 
> > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE 
> > > arrives, subscribe
> > > again, but then accept the NOTIFY from the sender from the 
> > > first SUBSCRIBE.
> > > ( NOTE: I DON'T propose that)
> > > 
> > > There was the proposal to accept the dialog which arrives 
> > first, be it
> > > response or NOTIFY.
> > > 
> > > 
> > > Did I forget another possibility? I think all of them work. 
> > > Basically all of
> > > them depend on a kind of local policy and on the kind of 
> > > application, which
> > > shouldn't be controlled anyway by the protocol.
> > > 
> > > So I vote for 1) as default procedure.
> > > 
> > > Lachlan
> > > 
> > > 
> > > -----Originalnachricht-----
> > > Von: Paul Kyzivat
> > > An: Jonathan Rosenberg
> > > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
> > > Gesendet: 06.12.01 22:58
> > > Betreff: Re: [Simple] 200 vs. 202
> > > 
> > > [SNIP]
> > > 
> > > > 
> > > > Do we have consensus though? I'd like to declare this issue 
> > > resolved.
> > > Adam's
> > > > proposal was to accept the first NOTIFY, and ignore the 
> > > 2xx. I'd like
> > > to
> > > > suggest a mild variant to that that I think is even simpler. My
> > > proposal is
> > > > to accept whatever comes first. If you get a 2xx to 
> > SUBSCRIBE first,
> > > that
> > > > establishes a dialog. All other NOTIFYs are 481d. If a 
> > NOTIFY comes
> > > first,
> > > > you accept that. Any other NOTIFY are 481'd. The 2xx to 
> > > SUBSCRIBE may
> > > or may
> > > > not be for the dialog that was accepted; it doesn't 
> really matter.
> > > > 
> > > > Agreement?
> > > 
> > > I don't have a preference between those two alternatives.
> > > 
> > > I won't stop progress by continuing to argue, but I don't 
> > find either
> > > solution very appealing. 
> > > 
> > > 	Paul
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > 
> 

From adam.roach@ericsson.com  Fri Dec  7 12:39:12 2001
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 MAA20262
	for ; Fri, 7 Dec 2001 12:39:11 -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 fB7HXSH01276;
	Fri, 7 Dec 2001 11:33: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 fB7HXS627754;
	Fri, 7 Dec 2001 11:33: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 LAA00242; Fri, 7 Dec 2001 11:33:27 -0600 (CST)
Reply-To: 
To: "'Jonathan Rosenberg'" ,
        ,
        "'Brazier Lachlan'" ,
        "''Paul Kyzivat ' '" 
Cc: "'''Brian Stucker' ' '" ,
        "''simple ' '" 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 11:33:26 -0600
Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF5@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: 
Content-Length: 6228
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: 

Sorry for the confusion.

I was talking about an earlier suggestion -- the one Brian
reiterates as "Only accept NOTIFY's which fit to the response".

Your revision of my earlier proposal -- which allows SUBSCRIBE
responses to create dialogs -- is the best solution I've seen
proposed so far.

/a

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, December 07, 2001 11:09 AM
> To: 'adam.roach@ericsson.com'; 'Brazier Lachlan'; ''Paul Kyzivat ' ';
> Jonathan Rosenberg
> Cc: '''Brian Stucker' ' '; ''simple ' '
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> What was the problem with my proposal to accept what comes 
> first (200 or
> NOTIFY)? Seems to consistently work and be really simple...
> 
> -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: Friday, December 07, 2001 11:52 AM
> > To: 'Brazier Lachlan'; adam.roach@ericsson.com; ''Paul Kyzivat ' ';
> > ''Jonathan Rosenberg ' '
> > Cc: '''Brian Stucker' ' '; ''simple ' '
> > Subject: RE: [Simple] 200 vs. 202
> > 
> > 
> > Ah. In that case, I'm going to have to disagree for the
> > exact same reasons that I objected when Jonathan proposed
> > this: it's more complicated to implement, and the NOTIFY
> > that corresponds to the final response doesn't have any
> > special meaning. It's no better than any other NOTIFY.
> > 
> > Keep it simple. (No pun intended).
> > 
> > /a
> > 
> > > -----Original Message-----
> > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > > Sent: Friday, December 07, 2001 10:44 AM
> > > To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul 
> Kyzivat ' ';
> > > ''Jonathan Rosenberg ' '
> > > Cc: '''Brian Stucker' ' '; ''simple ' '
> > > Subject: AW: [Simple] 200 vs. 202
> > > 
> > > 
> > > Ups, sorry,
> > > 
> > > I meant
> > > 1) Only accept NOTIFY's which fit to the response
> > > 
> > > Lachlan 
> > > 
> > > -----Originalnachricht-----
> > > Von: adam.roach@ericsson.com
> > > An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg '
> > > Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple '
> > > Gesendet: 07.12.01 17:13
> > > Betreff: RE: [Simple] 200 vs. 202
> > > 
> > > Brian:
> > > 
> > > I can't tell what you're proposing, since you have two points
> > > labelled as "1)." I like the second "1)" just fine, and the
> > > variant in which the first dialog-establishing message (2xx
> > > or NOTIFY) just as well.
> > > 
> > > /a
> > > 
> > > > -----Original Message-----
> > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > > > Sent: Friday, December 07, 2001 5:14 AM
> > > > To: 'Paul Kyzivat '; 'Jonathan Rosenberg '
> > > > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple '
> > > > Subject: AW: [Simple] 200 vs. 202
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > I believe the subscriber SHOULD keep all NOTIFY messages 
> > > > which arrive before
> > > > the response to the SUBSCRIBE arives. After receiving the 
> > > response the
> > > > subscriber can decide which way to handle the NOTIFY's.
> > > > 
> > > > 1) Only accept NOTIFY's which fit to the response
> > > > 
> > > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with 
> > > firewalls?)
> > > > 
> > > > 3) Accept only a subset of the NOTIFY's (based on some 
> > local policy)
> > > > 
> > > > If the subscriber doesn't want to wait for the response to 
> > > > the SUBSCRIBE,
> > > > and NOTIFY's arrive before the response, it has the 
> possibilities:
> > > > 
> > > > 1) Accept the first NOTIFY and ignore the response
> > > > 
> > > > 2) Accept all NOTIFY's and ignore the response
> > > > 
> > > > 3) Accept only a subset of the NOTIFY's
> > > > 
> > > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE 
> > > > arrives, subscribe
> > > > again, but then accept the NOTIFY from the sender from the 
> > > > first SUBSCRIBE.
> > > > ( NOTE: I DON'T propose that)
> > > > 
> > > > There was the proposal to accept the dialog which arrives 
> > > first, be it
> > > > response or NOTIFY.
> > > > 
> > > > 
> > > > Did I forget another possibility? I think all of them work. 
> > > > Basically all of
> > > > them depend on a kind of local policy and on the kind of 
> > > > application, which
> > > > shouldn't be controlled anyway by the protocol.
> > > > 
> > > > So I vote for 1) as default procedure.
> > > > 
> > > > Lachlan
> > > > 
> > > > 
> > > > -----Originalnachricht-----
> > > > Von: Paul Kyzivat
> > > > An: Jonathan Rosenberg
> > > > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
> > > > Gesendet: 06.12.01 22:58
> > > > Betreff: Re: [Simple] 200 vs. 202
> > > > 
> > > > [SNIP]
> > > > 
> > > > > 
> > > > > Do we have consensus though? I'd like to declare this issue 
> > > > resolved.
> > > > Adam's
> > > > > proposal was to accept the first NOTIFY, and ignore the 
> > > > 2xx. I'd like
> > > > to
> > > > > suggest a mild variant to that that I think is even 
> simpler. My
> > > > proposal is
> > > > > to accept whatever comes first. If you get a 2xx to 
> > > SUBSCRIBE first,
> > > > that
> > > > > establishes a dialog. All other NOTIFYs are 481d. If a 
> > > NOTIFY comes
> > > > first,
> > > > > you accept that. Any other NOTIFY are 481'd. The 2xx to 
> > > > SUBSCRIBE may
> > > > or may
> > > > > not be for the dialog that was accepted; it doesn't 
> > really matter.
> > > > > 
> > > > > Agreement?
> > > > 
> > > > I don't have a preference between those two alternatives.
> > > > 
> > > > I won't stop progress by continuing to argue, but I don't 
> > > find either
> > > > solution very appealing. 
> > > > 
> > > > 	Paul
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > 
> > 
> 


From jdrosen@dynamicsoft.com  Fri Dec  7 13:26:08 2001
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 NAA20433
	for ; Fri, 7 Dec 2001 13:26:08 -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 fB7IL34I028845;
	Fri, 7 Dec 2001 13:21:03 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 7 Dec 2001 13:22:33 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'adam.roach@ericsson.com'" ,
        Jonathan Rosenberg ,
        "'Brazier Lachlan'"
	 ,
        "''Paul Kyzivat ' '" 
Cc: "'''Brian Stucker' ' '" ,
        "''simple ' '"
	 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 13:22:26 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 7464
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: 

Adam,

Assuming that the consensus is to use this approach when you want to accept
only a single notification, you agree this belongs in sip-events, right?

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: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> Sent: Friday, December 07, 2001 12:33 PM
> To: 'Jonathan Rosenberg'; adam.roach@ericsson.com; 'Brazier Lachlan';
> ''Paul Kyzivat ' '
> Cc: '''Brian Stucker' ' '; ''simple ' '
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> Sorry for the confusion.
> 
> I was talking about an earlier suggestion -- the one Brian
> reiterates as "Only accept NOTIFY's which fit to the response".
> 
> Your revision of my earlier proposal -- which allows SUBSCRIBE
> responses to create dialogs -- is the best solution I've seen
> proposed so far.
> 
> /a
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Friday, December 07, 2001 11:09 AM
> > To: 'adam.roach@ericsson.com'; 'Brazier Lachlan'; ''Paul 
> Kyzivat ' ';
> > Jonathan Rosenberg
> > Cc: '''Brian Stucker' ' '; ''simple ' '
> > Subject: RE: [Simple] 200 vs. 202
> > 
> > 
> > What was the problem with my proposal to accept what comes 
> > first (200 or
> > NOTIFY)? Seems to consistently work and be really simple...
> > 
> > -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: Friday, December 07, 2001 11:52 AM
> > > To: 'Brazier Lachlan'; adam.roach@ericsson.com; ''Paul 
> Kyzivat ' ';
> > > ''Jonathan Rosenberg ' '
> > > Cc: '''Brian Stucker' ' '; ''simple ' '
> > > Subject: RE: [Simple] 200 vs. 202
> > > 
> > > 
> > > Ah. In that case, I'm going to have to disagree for the
> > > exact same reasons that I objected when Jonathan proposed
> > > this: it's more complicated to implement, and the NOTIFY
> > > that corresponds to the final response doesn't have any
> > > special meaning. It's no better than any other NOTIFY.
> > > 
> > > Keep it simple. (No pun intended).
> > > 
> > > /a
> > > 
> > > > -----Original Message-----
> > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > > > Sent: Friday, December 07, 2001 10:44 AM
> > > > To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul 
> > Kyzivat ' ';
> > > > ''Jonathan Rosenberg ' '
> > > > Cc: '''Brian Stucker' ' '; ''simple ' '
> > > > Subject: AW: [Simple] 200 vs. 202
> > > > 
> > > > 
> > > > Ups, sorry,
> > > > 
> > > > I meant
> > > > 1) Only accept NOTIFY's which fit to the response
> > > > 
> > > > Lachlan 
> > > > 
> > > > -----Originalnachricht-----
> > > > Von: adam.roach@ericsson.com
> > > > An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg '
> > > > Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple '
> > > > Gesendet: 07.12.01 17:13
> > > > Betreff: RE: [Simple] 200 vs. 202
> > > > 
> > > > Brian:
> > > > 
> > > > I can't tell what you're proposing, since you have two points
> > > > labelled as "1)." I like the second "1)" just fine, and the
> > > > variant in which the first dialog-establishing message (2xx
> > > > or NOTIFY) just as well.
> > > > 
> > > > /a
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > > > > Sent: Friday, December 07, 2001 5:14 AM
> > > > > To: 'Paul Kyzivat '; 'Jonathan Rosenberg '
> > > > > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple '
> > > > > Subject: AW: [Simple] 200 vs. 202
> > > > > 
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > I believe the subscriber SHOULD keep all NOTIFY messages 
> > > > > which arrive before
> > > > > the response to the SUBSCRIBE arives. After receiving the 
> > > > response the
> > > > > subscriber can decide which way to handle the NOTIFY's.
> > > > > 
> > > > > 1) Only accept NOTIFY's which fit to the response
> > > > > 
> > > > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with 
> > > > firewalls?)
> > > > > 
> > > > > 3) Accept only a subset of the NOTIFY's (based on some 
> > > local policy)
> > > > > 
> > > > > If the subscriber doesn't want to wait for the response to 
> > > > > the SUBSCRIBE,
> > > > > and NOTIFY's arrive before the response, it has the 
> > possibilities:
> > > > > 
> > > > > 1) Accept the first NOTIFY and ignore the response
> > > > > 
> > > > > 2) Accept all NOTIFY's and ignore the response
> > > > > 
> > > > > 3) Accept only a subset of the NOTIFY's
> > > > > 
> > > > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE 
> > > > > arrives, subscribe
> > > > > again, but then accept the NOTIFY from the sender from the 
> > > > > first SUBSCRIBE.
> > > > > ( NOTE: I DON'T propose that)
> > > > > 
> > > > > There was the proposal to accept the dialog which arrives 
> > > > first, be it
> > > > > response or NOTIFY.
> > > > > 
> > > > > 
> > > > > Did I forget another possibility? I think all of them work. 
> > > > > Basically all of
> > > > > them depend on a kind of local policy and on the kind of 
> > > > > application, which
> > > > > shouldn't be controlled anyway by the protocol.
> > > > > 
> > > > > So I vote for 1) as default procedure.
> > > > > 
> > > > > Lachlan
> > > > > 
> > > > > 
> > > > > -----Originalnachricht-----
> > > > > Von: Paul Kyzivat
> > > > > An: Jonathan Rosenberg
> > > > > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
> > > > > Gesendet: 06.12.01 22:58
> > > > > Betreff: Re: [Simple] 200 vs. 202
> > > > > 
> > > > > [SNIP]
> > > > > 
> > > > > > 
> > > > > > Do we have consensus though? I'd like to declare this issue 
> > > > > resolved.
> > > > > Adam's
> > > > > > proposal was to accept the first NOTIFY, and ignore the 
> > > > > 2xx. I'd like
> > > > > to
> > > > > > suggest a mild variant to that that I think is even 
> > simpler. My
> > > > > proposal is
> > > > > > to accept whatever comes first. If you get a 2xx to 
> > > > SUBSCRIBE first,
> > > > > that
> > > > > > establishes a dialog. All other NOTIFYs are 481d. If a 
> > > > NOTIFY comes
> > > > > first,
> > > > > > you accept that. Any other NOTIFY are 481'd. The 2xx to 
> > > > > SUBSCRIBE may
> > > > > or may
> > > > > > not be for the dialog that was accepted; it doesn't 
> > > really matter.
> > > > > > 
> > > > > > Agreement?
> > > > > 
> > > > > I don't have a preference between those two alternatives.
> > > > > 
> > > > > I won't stop progress by continuing to argue, but I don't 
> > > > find either
> > > > > solution very appealing. 
> > > > > 
> > > > > 	Paul
> > > > > _______________________________________________
> > > > > simple mailing list
> > > > > simple@mailman.dynamicsoft.com
> > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > 
> > > > 
> > > 
> > 
> 

From jdrosen@dynamicsoft.com  Fri Dec  7 13:32:42 2001
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 NAA20476
	for ; Fri, 7 Dec 2001 13:32:41 -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 fB7ISr4I028951;
	Fri, 7 Dec 2001 13:28:53 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 7 Dec 2001 13:30:23 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'David R. Oran'" , adam.roach@ericsson.com,
        "'Christian Huitema'" ,
        "'Brazier Lachlan'"
	 ,
        "'Paul Kyzivat '" ,
        Jonathan Rosenberg 
Cc: "''Brian Stucker' '" ,
        "'simple '"
	 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 13:30:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1489
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: 



 

> -----Original Message-----
> From: David R. Oran [mailto:oran@cisco.com]
> Sent: Friday, December 07, 2001 11:35 AM
> To: adam.roach@ericsson.com; 'Christian Huitema'; 'Brazier Lachlan';
> 'Paul Kyzivat '; 'Jonathan Rosenberg '
> Cc: ''Brian Stucker' '; 'simple '
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> There's a set of caller preferences to control forking. From
> draft-ietf-caller-pref-04.txt:
> 
> 
>         fork-feature: This feature indicates whether a proxy 
> should fork
>              a request, or proxy to only a single address. If 
> the server
>              is requested not to fork, the server SHOULD proxy the
>              request to the "best" address (generally the one with the
>              highest q value). The feature is ignored if 
> "redirect" has
>              been requested.

Its worth noting that the proposal to accept a single NOTIFY amounts to the
same thing, except that we ignore any forked branches rather than having
them not occur in the first place. I should also point out that caller
preferences is optional to obey, so you would have to handle the forking
anyway.

-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

From adam.roach@ericsson.com  Fri Dec  7 14:38:03 2001
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 OAA20713
	for ; Fri, 7 Dec 2001 14:38:03 -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 fB7JMuY25730;
	Fri, 7 Dec 2001 13:22:56 -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 fB7JMuq28358;
	Fri, 7 Dec 2001 13:22:56 -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 NAA10788; Fri, 7 Dec 2001 13:22:55 -0600 (CST)
Reply-To: 
To: "'Jonathan Rosenberg'" ,
        ,
        "'Brazier Lachlan'" ,
        "''Paul Kyzivat ' '" 
Cc: "'''Brian Stucker' ' '" ,
        "''simple ' '" 
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 13:22:54 -0600
Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF6@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: 
Content-Length: 8375
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: 

Yes. The consensus on this topic will be described in detail in sip-events,
and does not need to be reiterated in any SIMPLE documents.

/a

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, December 07, 2001 12:22 PM
> To: 'adam.roach@ericsson.com'; Jonathan Rosenberg; 'Brazier Lachlan';
> ''Paul Kyzivat ' '
> Cc: '''Brian Stucker' ' '; ''simple ' '
> Subject: RE: [Simple] 200 vs. 202
> 
> 
> Adam,
> 
> Assuming that the consensus is to use this approach when you 
> want to accept
> only a single notification, you agree this belongs in 
> sip-events, right?
> 
> 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: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> > Sent: Friday, December 07, 2001 12:33 PM
> > To: 'Jonathan Rosenberg'; adam.roach@ericsson.com; 'Brazier 
> Lachlan';
> > ''Paul Kyzivat ' '
> > Cc: '''Brian Stucker' ' '; ''simple ' '
> > Subject: RE: [Simple] 200 vs. 202
> > 
> > 
> > Sorry for the confusion.
> > 
> > I was talking about an earlier suggestion -- the one Brian
> > reiterates as "Only accept NOTIFY's which fit to the response".
> > 
> > Your revision of my earlier proposal -- which allows SUBSCRIBE
> > responses to create dialogs -- is the best solution I've seen
> > proposed so far.
> > 
> > /a
> > 
> > > -----Original Message-----
> > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > > Sent: Friday, December 07, 2001 11:09 AM
> > > To: 'adam.roach@ericsson.com'; 'Brazier Lachlan'; ''Paul 
> > Kyzivat ' ';
> > > Jonathan Rosenberg
> > > Cc: '''Brian Stucker' ' '; ''simple ' '
> > > Subject: RE: [Simple] 200 vs. 202
> > > 
> > > 
> > > What was the problem with my proposal to accept what comes 
> > > first (200 or
> > > NOTIFY)? Seems to consistently work and be really simple...
> > > 
> > > -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: Friday, December 07, 2001 11:52 AM
> > > > To: 'Brazier Lachlan'; adam.roach@ericsson.com; ''Paul 
> > Kyzivat ' ';
> > > > ''Jonathan Rosenberg ' '
> > > > Cc: '''Brian Stucker' ' '; ''simple ' '
> > > > Subject: RE: [Simple] 200 vs. 202
> > > > 
> > > > 
> > > > Ah. In that case, I'm going to have to disagree for the
> > > > exact same reasons that I objected when Jonathan proposed
> > > > this: it's more complicated to implement, and the NOTIFY
> > > > that corresponds to the final response doesn't have any
> > > > special meaning. It's no better than any other NOTIFY.
> > > > 
> > > > Keep it simple. (No pun intended).
> > > > 
> > > > /a
> > > > 
> > > > > -----Original Message-----
> > > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > > > > Sent: Friday, December 07, 2001 10:44 AM
> > > > > To: 'adam.roach@ericsson.com '; Brazier Lachlan; ''Paul 
> > > Kyzivat ' ';
> > > > > ''Jonathan Rosenberg ' '
> > > > > Cc: '''Brian Stucker' ' '; ''simple ' '
> > > > > Subject: AW: [Simple] 200 vs. 202
> > > > > 
> > > > > 
> > > > > Ups, sorry,
> > > > > 
> > > > > I meant
> > > > > 1) Only accept NOTIFY's which fit to the response
> > > > > 
> > > > > Lachlan 
> > > > > 
> > > > > -----Originalnachricht-----
> > > > > Von: adam.roach@ericsson.com
> > > > > An: 'Brazier Lachlan'; 'Paul Kyzivat '; 'Jonathan Rosenberg '
> > > > > Cc: adam.roach@ericsson.com; ''Brian Stucker' '; 'simple '
> > > > > Gesendet: 07.12.01 17:13
> > > > > Betreff: RE: [Simple] 200 vs. 202
> > > > > 
> > > > > Brian:
> > > > > 
> > > > > I can't tell what you're proposing, since you have two points
> > > > > labelled as "1)." I like the second "1)" just fine, and the
> > > > > variant in which the first dialog-establishing message (2xx
> > > > > or NOTIFY) just as well.
> > > > > 
> > > > > /a
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> > > > > > Sent: Friday, December 07, 2001 5:14 AM
> > > > > > To: 'Paul Kyzivat '; 'Jonathan Rosenberg '
> > > > > > Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 
> 'simple '
> > > > > > Subject: AW: [Simple] 200 vs. 202
> > > > > > 
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > I believe the subscriber SHOULD keep all NOTIFY messages 
> > > > > > which arrive before
> > > > > > the response to the SUBSCRIBE arives. After receiving the 
> > > > > response the
> > > > > > subscriber can decide which way to handle the NOTIFY's.
> > > > > > 
> > > > > > 1) Only accept NOTIFY's which fit to the response
> > > > > > 
> > > > > > 2) Accept all NOTIFY's (problem with DoS? - Is it one with 
> > > > > firewalls?)
> > > > > > 
> > > > > > 3) Accept only a subset of the NOTIFY's (based on some 
> > > > local policy)
> > > > > > 
> > > > > > If the subscriber doesn't want to wait for the response to 
> > > > > > the SUBSCRIBE,
> > > > > > and NOTIFY's arrive before the response, it has the 
> > > possibilities:
> > > > > > 
> > > > > > 1) Accept the first NOTIFY and ignore the response
> > > > > > 
> > > > > > 2) Accept all NOTIFY's and ignore the response
> > > > > > 
> > > > > > 3) Accept only a subset of the NOTIFY's
> > > > > > 
> > > > > > 4) Accept no NOTIFY. When the response to the SUBSCRIBE 
> > > > > > arrives, subscribe
> > > > > > again, but then accept the NOTIFY from the sender from the 
> > > > > > first SUBSCRIBE.
> > > > > > ( NOTE: I DON'T propose that)
> > > > > > 
> > > > > > There was the proposal to accept the dialog which arrives 
> > > > > first, be it
> > > > > > response or NOTIFY.
> > > > > > 
> > > > > > 
> > > > > > Did I forget another possibility? I think all of them work. 
> > > > > > Basically all of
> > > > > > them depend on a kind of local policy and on the kind of 
> > > > > > application, which
> > > > > > shouldn't be controlled anyway by the protocol.
> > > > > > 
> > > > > > So I vote for 1) as default procedure.
> > > > > > 
> > > > > > Lachlan
> > > > > > 
> > > > > > 
> > > > > > -----Originalnachricht-----
> > > > > > Von: Paul Kyzivat
> > > > > > An: Jonathan Rosenberg
> > > > > > Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
> > > > > > Gesendet: 06.12.01 22:58
> > > > > > Betreff: Re: [Simple] 200 vs. 202
> > > > > > 
> > > > > > [SNIP]
> > > > > > 
> > > > > > > 
> > > > > > > Do we have consensus though? I'd like to declare 
> this issue 
> > > > > > resolved.
> > > > > > Adam's
> > > > > > > proposal was to accept the first NOTIFY, and ignore the 
> > > > > > 2xx. I'd like
> > > > > > to
> > > > > > > suggest a mild variant to that that I think is even 
> > > simpler. My
> > > > > > proposal is
> > > > > > > to accept whatever comes first. If you get a 2xx to 
> > > > > SUBSCRIBE first,
> > > > > > that
> > > > > > > establishes a dialog. All other NOTIFYs are 481d. If a 
> > > > > NOTIFY comes
> > > > > > first,
> > > > > > > you accept that. Any other NOTIFY are 481'd. The 2xx to 
> > > > > > SUBSCRIBE may
> > > > > > or may
> > > > > > > not be for the dialog that was accepted; it doesn't 
> > > > really matter.
> > > > > > > 
> > > > > > > Agreement?
> > > > > > 
> > > > > > I don't have a preference between those two alternatives.
> > > > > > 
> > > > > > I won't stop progress by continuing to argue, but I don't 
> > > > > find either
> > > > > > solution very appealing. 
> > > > > > 
> > > > > > 	Paul
> > > > > > _______________________________________________
> > > > > > simple mailing list
> > > > > > simple@mailman.dynamicsoft.com
> > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 


From jdrosen@dynamicsoft.com  Fri Dec  7 14:51:09 2001
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 OAA20821
	for ; Fri, 7 Dec 2001 14:51: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 fB7JnD4I029585;
	Fri, 7 Dec 2001 14:49:13 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 7 Dec 2001 14:50:43 -0500
Message-ID: 
From: Jonathan Rosenberg 
To: "'simple@mailman.dynamicsoft.com'" 
Cc: "'sip@ietf.oeg'" 
Date: Fri, 7 Dec 2001 14:50:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3549
Subject: [Simple] Alginment of sip-events and 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: 

(resend; first attempt seemed to have been garbled)


I'm cc'ing SIMPLE since this is a joint issue that affects both the
watcherinfo work and sip-events. Also, sip-events is a sip work item, not
sipping, so I am changing the list to sip.
 

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
> Sent: Wednesday, November 28, 2001 2:00 PM
> To: 'Brian Stucker'; Jonathan Rosenberg; 'Bert Culpepper';
> adam.roach@ericsson.com
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01
> 
> 
> This sounds like a good suggestion to me Brian.
> 
> I would like to suggest the watherinfo reason codes are 
> expanded a little.
> For instance, the watcherinfo assumes that the pending states 
> is waiting for
> authorization. It could however be pending while waiting for 
> the subscribed
> object to become active (note: I am not referring to the 
> subscribed Event
> package here). This sort of behavior may be typical/useful 
> when you are
> trying to subscribe to an event that has not started yet (and 
> yet you desire
> to have the subscription in place _before_ the event begins). 

OK, but in this case, the subscription itself is not pending, its the state
of the object that is effectively "TBD". This should be reflected in the
presence document delivered in the first NOTIFY, not in the state of the
subscription, IMHO.


> I also think
> the rejection/termination reasons could be expanded a little more.

Suggestions?


Brian Stucker wrote:
> 
> I can't see much use in including the 
> event field since
> (presumably) the watcher will know what event triggered the 
> NOTIFY, and if
> they can't, they can use watcherinfo to get it.

No, these are not events of the presentity, they are events of the
subscription. These events correspond quite closely to the "reason"
parameters Adam has currently specified. In fact, for the rejecttion events,
here is the mapping:

sip-events      watcherinfo
----------      -----------
migration  <->   deactivated
maint      <->    ?
refused    <->   rejected
timeout    <->   expired
 ?         <->   timeout

Clearly, these should be aligned, and should be present in both the
SUbscription-Expires and the watcherinfo format. 

Its not clear to me what the semantics of maint are; should the client retry
after some period? Presuming we can define it conciesely, we should add it
to the watcherinfo package. 

So, here would be my proposal for the unified set:

deactivated: subscription is terminated, but client SHOULD retry immediately
with a new subscription. This handles migration plus other cases
potentially.

probation: subscription is terminated; but client SHOULD retry at some later
time (we could include a Retry-After header in the case of presence in the
Subscription-Expires header)

rejected: subscription terminated due to change in authorization policy.
Retrying will not help.

timeout: subscription terminated because it was not refreshed. 

giveup: could not obtain authorization in a timely fashion, and so the
pending subscription is being terminated. The client can retry and will
likely get put back into pending state.

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
 

From adam.roach@ericsson.com  Fri Dec  7 15:15:22 2001
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 PAA20941
	for ; Fri, 7 Dec 2001 15:15:22 -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 fB7KESY17549;
	Fri, 7 Dec 2001 14:14: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 fB7KERq14841;
	Fri, 7 Dec 2001 14:14:27 -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 OAA16090; Fri, 7 Dec 2001 14:14:26 -0600 (CST)
Reply-To: 
To: "'Paul Kyzivat'" ,
        "Jonathan Rosenberg" 
Cc: "'warren montgomery'" ,
        
Subject: RE: [Simple] New I-D on IM transport
Date: Fri, 7 Dec 2001 14:14:24 -0600
Message-ID: <61D824C63B99D311975E00508B0CC98502C66CF9@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: <3BFA68B2.94C6CEB2@cisco.com>
Content-Length: 973
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: 

Slightly off topic, but just offering an explanation...

> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
>
> 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.

The issue as I understand it is that people want to be able to
design endpoints that do not necessarily have DNS capabilities.
I'm not going to defend this design decision.

If sending of FQDNs is a MAY, then being able to receive them
is necessarily a MUST, lest we end up with a protocol that isn't
compatible with itself.

Conversely, if receiving of FQDNs is not a MUST (to appease the
no-DNS-in-my-endpoint minority), then sending of FQDNs is a 
MUST NOT.

Personally, I think this is a case of letting a very small portion
of the tip of the tail wag the whole elephant...

/a


From pkyzivat@cisco.com  Fri Dec  7 18:27:29 2001
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 SAA21640
	for ; Fri, 7 Dec 2001 18:27:29 -0500 (EST)
Received: from cannonat.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 fB7NR7c18475;
	Fri, 7 Dec 2001 18:27:07 -0500 (EST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannonat.cisco.com (Mirapoint)
	with ESMTP id AAF44903 (AUTH pkyzivat);
	Fri, 7 Dec 2001 18:28:25 -0500 (EST)
Message-ID: <3C114F75.492D4C25@cisco.com>
Date: Fri, 07 Dec 2001 18:23:33 -0500
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 ,
        "'warren montgomery'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] New I-D on IM transport
References: <61D824C63B99D311975E00508B0CC98502C66CF9@eamrcnt717.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1479
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: 

FYI - it was draft-ietf-mmusic-sdp-new-02 and
draft-ietf-mmusic-sdp-new-03 where FQDNs in the c= line were illegal. In
the recently introduced draft-ietf-mmusic-sdp-new-04 they are legal
again.

I have no visibility into why these changes were made.

	Paul

adam.roach@ericsson.com wrote:
> 
> Slightly off topic, but just offering an explanation...
> 
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >
> > 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.
> 
> The issue as I understand it is that people want to be able to
> design endpoints that do not necessarily have DNS capabilities.
> I'm not going to defend this design decision.
> 
> If sending of FQDNs is a MAY, then being able to receive them
> is necessarily a MUST, lest we end up with a protocol that isn't
> compatible with itself.
> 
> Conversely, if receiving of FQDNs is not a MUST (to appease the
> no-DNS-in-my-endpoint minority), then sending of FQDNs is a
> MUST NOT.
> 
> Personally, I think this is a case of letting a very small portion
> of the tip of the tail wag the whole elephant...
> 
> /a
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From HUITEMA@windows.microsoft.com  Fri Dec  7 11:12:06 2001
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 LAA19664
	for ; Fri, 7 Dec 2001 11:12:06 -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, 7 Dec 2001 08:11:40 -0800
Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Dec 2001 08:11:40 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 7 Dec 2001 08:11:40 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 7 Dec 2001 08:11:39 -0800
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0);
	 Fri, 7 Dec 2001 08:10:15 -0800
x-mimeole: Produced By Microsoft Exchange V6.0.6092.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] 200 vs. 202
Date: Fri, 7 Dec 2001 08:10:15 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] 200 vs. 202
Thread-Index: AcF/EOvnZLxycBUgRdqjRoyMRZg4TwAKKV4Q
From: "Christian Huitema" 
To: "Brazier Lachlan" ,
        "Paul Kyzivat " ,
        "Jonathan Rosenberg " 
Cc: ,
        "'Brian Stucker' " ,
        "simple " 
X-OriginalArrivalTime: 07 Dec 2001 16:10:15.0819 (UTC) FILETIME=[A865C5B0:01C17F39]
Content-Length: 3175
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA19664
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: 

So, It seems that much boils down to the expectations of the subscriber,
and its ability to sort out the mess created by a forking proxy. Do we
want to add a header line in SIP, such as:

	Fork-with-me: Don't you dare

This would clearly tell proxies to not fork around...

-- Christian Huitema

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Friday, December 07, 2001 3:14 AM
> To: 'Paul Kyzivat '; 'Jonathan Rosenberg '
> Cc: 'adam.roach@ericsson.com '; ''Brian Stucker' '; 'simple '
> Subject: AW: [Simple] 200 vs. 202
> 
> Hello,
> 
> I believe the subscriber SHOULD keep all NOTIFY messages which arrive
> before
> the response to the SUBSCRIBE arives. After receiving the response the
> subscriber can decide which way to handle the NOTIFY's.
> 
> 1) Only accept NOTIFY's which fit to the response
> 
> 2) Accept all NOTIFY's (problem with DoS? - Is it one with firewalls?)
> 
> 3) Accept only a subset of the NOTIFY's (based on some local policy)
> 
> If the subscriber doesn't want to wait for the response to the
> SUBSCRIBE,
> and NOTIFY's arrive before the response, it has the possibilities:
> 
> 1) Accept the first NOTIFY and ignore the response
> 
> 2) Accept all NOTIFY's and ignore the response
> 
> 3) Accept only a subset of the NOTIFY's
> 
> 4) Accept no NOTIFY. When the response to the SUBSCRIBE arrives,
> subscribe
> again, but then accept the NOTIFY from the sender from the first
> SUBSCRIBE.
> ( NOTE: I DON'T propose that)
> 
> There was the proposal to accept the dialog which arrives first, be it
> response or NOTIFY.
> 
> 
> Did I forget another possibility? I think all of them work. Basically
> all of
> them depend on a kind of local policy and on the kind of application,
> which
> shouldn't be controlled anyway by the protocol.
> 
> So I vote for 1) as default procedure.
> 
> Lachlan
> 
> 
> -----Originalnachricht-----
> Von: Paul Kyzivat
> An: Jonathan Rosenberg
> Cc: adam.roach@ericsson.com; 'Brian Stucker'; simple
> Gesendet: 06.12.01 22:58
> Betreff: Re: [Simple] 200 vs. 202
> 
> [SNIP]
> 
> >
> > Do we have consensus though? I'd like to declare this issue
> resolved.
> Adam's
> > proposal was to accept the first NOTIFY, and ignore the 2xx. I'd
> like
> to
> > suggest a mild variant to that that I think is even simpler. My
> proposal is
> > to accept whatever comes first. If you get a 2xx to SUBSCRIBE first,
> that
> > establishes a dialog. All other NOTIFYs are 481d. If a NOTIFY comes
> first,
> > you accept that. Any other NOTIFY are 481'd. The 2xx to SUBSCRIBE
> may
> or may
> > not be for the dialog that was accepted; it doesn't really matter.
> >
> > Agreement?
> 
> I don't have a preference between those two alternatives.
> 
> I won't stop progress by continuing to argue, but I don't find either
> solution very appealing.
> 
> 	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 rfairlie@nuera.com  Mon Dec 10 19:46:22 2001
Received: from exchange1.nuera.com ([12.105.228.79])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03067
	for ; Mon, 10 Dec 2001 19:46:20 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 10 Dec 2001 16:48:06 -0800
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Jonathan Rosenberg'" ,
        "'sip@ietf.org'"
	 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and watcherinfo
Date: Mon, 10 Dec 2001 16:48:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4741
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: 

Hi Jonathan,

> 
> (resend; first attempt seemed to have been garbled)
> 
> 
> I'm cc'ing SIMPLE since this is a joint issue that affects both the
> watcherinfo work and sip-events. Also, sip-events is a sip 
> work item, not
> sipping, so I am changing the list to sip.
>  

Re-adding SIMPLE after resend.

> > I would like to suggest the watherinfo reason codes are 
> > expanded a little.
> > For instance, the watcherinfo assumes that the pending states 
> > is waiting for
> > authorization. It could however be pending while waiting for 
> > the subscribed
> > object to become active (note: I am not referring to the 
> > subscribed Event
> > package here). This sort of behavior may be typical/useful 
> > when you are
> > trying to subscribe to an event that has not started yet (and 
> > yet you desire
> > to have the subscription in place _before_ the event begins). 
> 
> OK, but in this case, the subscription itself is not pending, 
> its the state
> of the object that is effectively "TBD". This should be 
> reflected in the
> presence document delivered in the first NOTIFY, not in the 
> state of the
> subscription, IMHO.

I disagree. I think this is very much the concern of subscription and not
the Event package. 

Example: If I create a subscription that is associated with a televised
concert that occurs at some time in the future. When the concert finishes,
obviously the subscription should also terminate, the reason for the
termination is that the subscribed object has terminated. This is not an
Event Package related reason. Likewise, every Event Package (e.g., my
"Excessive Decibels" Monitoring Event Package) should not have to deal with
understanding/reporting when the concert is valid (and why the subscription
was terminated) - the package is only concerned with reporting when the
audio component of the associated object exceeds a certain threshold.


This argument applies equally to the pending state. I want to create a
subscription to this concert before it starts so I don't miss the beginning.
So the subscription is not active until the concert actually starts - once
again my Decibel Monitoring Event Package has no concern for this. It is a
function of the subscription itself to know when the object (and hence the
subscription) is pending/active/terminated.

Thus both the terminated & pending reason causes should be
Subscription-Expire reasons and not solely contained in the Event package
bodies themselves. 

> > I also think
> > the rejection/termination reasons could be expanded a little more.
> 
> Suggestions?
> 

I made a couple in my last email (some of which you have already covered):

	- Terminated/rejected because authorization failed
	- Terminated because subscribed object terminated
	- Terminated because subscriber requested termination.
	- Expired. Subscriber did not refresh subscription.
	- Terminated at request of notifier.

Regards,

Robert.

> > 
> > I can't see much use in including the 
> > event field since
> > (presumably) the watcher will know what event triggered the 
> > NOTIFY, and if
> > they can't, they can use watcherinfo to get it.
> 
> No, these are not events of the presentity, they are events of the
> subscription. These events correspond quite closely to the "reason"
> parameters Adam has currently specified. In fact, for the 
> rejecttion events,
> here is the mapping:
> 
> sip-events      watcherinfo
> ----------      -----------
> migration  <->   deactivated
> maint      <->    ?
> refused    <->   rejected
> timeout    <->   expired
>  ?         <->   timeout
> 
> Clearly, these should be aligned, and should be present in both the
> SUbscription-Expires and the watcherinfo format. 
> 
> Its not clear to me what the semantics of maint are; should 
> the client retry
> after some period? Presuming we can define it conciesely, we 
> should add it
> to the watcherinfo package. 
> 
> So, here would be my proposal for the unified set:
> 
> deactivated: subscription is terminated, but client SHOULD 
> retry immediately
> with a new subscription. This handles migration plus other cases
> potentially.
> 
> probation: subscription is terminated; but client SHOULD 
> retry at some later
> time (we could include a Retry-After header in the case of 
> presence in the
> Subscription-Expires header)
> 
> rejected: subscription terminated due to change in 
> authorization policy.
> Retrying will not help.
> 
> timeout: subscription terminated because it was not refreshed. 
> 
> giveup: could not obtain authorization in a timely fashion, and so the
> pending subscription is being terminated. The client can 
> retry and will
> likely get put back into pending state.
> 
> THanks,
> Jonathan R.
> 
 

From bstucker@americasm01.nt.com  Tue Dec 11 02:24:42 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04330
	for ; Tue, 11 Dec 2001 02:24:42 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBB7NVB21296;
	Tue, 11 Dec 2001 01:23:31 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 11 Dec 2001 01:22:19 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E011D816A@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: "'Fairlie-Cuninghame, Robert'" ,
        "'Jonathan Rosenberg'" ,
        "'sip@ietf.org'"
	 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and watcherinfo
Date: Tue, 11 Dec 2001 01:22:34 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C18214.9AAD4CD0"
Content-Length: 21124
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: 

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_01C18214.9AAD4CD0
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
> Sent: Monday, December 10, 2001 6:48 PM
> To: 'Jonathan Rosenberg'; 'sip@ietf.org'
> Cc: 'simple@mailman.dynamicsoft.com'
> Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and 
> watcherinfo
> 
> 
> Hi Jonathan,
> 
> > 
> > (resend; first attempt seemed to have been garbled)
> > 
> > 
> > I'm cc'ing SIMPLE since this is a joint issue that affects both the
> > watcherinfo work and sip-events. Also, sip-events is a sip 
> > work item, not
> > sipping, so I am changing the list to sip.
> >  
> 
> Re-adding SIMPLE after resend.
> 
> > > I would like to suggest the watherinfo reason codes are 
> > > expanded a little.
> > > For instance, the watcherinfo assumes that the pending states 
> > > is waiting for
> > > authorization. It could however be pending while waiting for 
> > > the subscribed
> > > object to become active (note: I am not referring to the 
> > > subscribed Event
> > > package here). This sort of behavior may be typical/useful 
> > > when you are
> > > trying to subscribe to an event that has not started yet (and 
> > > yet you desire
> > > to have the subscription in place _before_ the event begins). 
> > 
> > OK, but in this case, the subscription itself is not pending, 
> > its the state
> > of the object that is effectively "TBD". This should be 
> > reflected in the
> > presence document delivered in the first NOTIFY, not in the 
> > state of the
> > subscription, IMHO.
> 
> I disagree. I think this is very much the concern of 
> subscription and not
> the Event package. 
> 
> Example: If I create a subscription that is associated with a 
> televised
> concert that occurs at some time in the future. When the 
> concert finishes,
> obviously the subscription should also terminate, the reason for the
> termination is that the subscribed object has terminated. 
> This is not an
> Event Package related reason. Likewise, every Event Package (e.g., my
> "Excessive Decibels" Monitoring Event Package) should not 
> have to deal with
> understanding/reporting when the concert is valid (and why 
> the subscription
> was terminated) - the package is only concerned with 
> reporting when the
> audio component of the associated object exceeds a certain threshold.
> 
> 
> This argument applies equally to the pending state. I want to create a
> subscription to this concert before it starts so I don't miss 
> the beginning.
> So the subscription is not active until the concert actually 
> starts - once
> again my Decibel Monitoring Event Package has no concern for 
> this. It is a
> function of the subscription itself to know when the object 
> (and hence the
> subscription) is pending/active/terminated.
> 
> Thus both the terminated & pending reason causes should be
> Subscription-Expire reasons and not solely contained in the 
> Event package
> bodies themselves. 

I would have to disagree (is there any other reason to post to this thread
=). 

I think there's a co-mingling of terms that is going on here, either that or
I've totally misunderstood what you were trying to get across. 

A subscription being pending or active, at least to me when I brought up my
proposal to split out the subscription state from the message body about a
month back, dealt completely with the actual state of the subscription, not
the resource it is watching.

In your scenario, even though the resource is pending (the concert hasn't
started yet), the subscription to it is NOT pending. It's active. You will
receive a notification when that concert begins (should that be the behavoir
that the subscription was setup to handle). If the subscription were
pending, meaning it had not been authorized, you would NOT get a
notification that the concert started necessarily. Likewise, there's no
reason that the subscription needs to be terminated explicitly either. The
server processing your subscription could simply send you a final NOTIFY
(the concert ended) and then dump the subscription in the bit bucket. It's
not very polite, but it's allowed in the draft.

Therefore, the two are distinct. This is what I was trying to avoid by
suggesting that using an "Illegal" message body in the NOTIFY doesn't work
well, and thus, we need a more explicit header to do the job to keep
everything more understandible.

A subscription can be pending to an active resource, or pending to a pending
resource. The two are distinct. They are separate finite state machines, and
thus should be processed separately. The state that the subscription is in
has nothing at all to do with the state of the resource on a basic level.
The resource may cause the subscription to be handled differently, for sure,
but at a generic sip-events level, there is no coupling in my mind.

Cheers,

Brian

> 
> > > I also think
> > > the rejection/termination reasons could be expanded a little more.
> > 
> > Suggestions?
> > 
> 
> I made a couple in my last email (some of which you have 
> already covered):
> 
> 	- Terminated/rejected because authorization failed
> 	- Terminated because subscribed object terminated
> 	- Terminated because subscriber requested termination.
> 	- Expired. Subscriber did not refresh subscription.
> 	- Terminated at request of notifier.
> 
> Regards,
> 
> Robert.
> 
> > > 
> > > I can't see much use in including the 
> > > event field since
> > > (presumably) the watcher will know what event triggered the 
> > > NOTIFY, and if
> > > they can't, they can use watcherinfo to get it.
> > 
> > No, these are not events of the presentity, they are events of the
> > subscription. These events correspond quite closely to the "reason"
> > parameters Adam has currently specified. In fact, for the 
> > rejecttion events,
> > here is the mapping:
> > 
> > sip-events      watcherinfo
> > ----------      -----------
> > migration  <->   deactivated
> > maint      <->    ?
> > refused    <->   rejected
> > timeout    <->   expired
> >  ?         <->   timeout
> > 
> > Clearly, these should be aligned, and should be present in both the
> > SUbscription-Expires and the watcherinfo format. 
> > 
> > Its not clear to me what the semantics of maint are; should 
> > the client retry
> > after some period? Presuming we can define it conciesely, we 
> > should add it
> > to the watcherinfo package. 
> > 
> > So, here would be my proposal for the unified set:
> > 
> > deactivated: subscription is terminated, but client SHOULD 
> > retry immediately
> > with a new subscription. This handles migration plus other cases
> > potentially.
> > 
> > probation: subscription is terminated; but client SHOULD 
> > retry at some later
> > time (we could include a Retry-After header in the case of 
> > presence in the
> > Subscription-Expires header)
> > 
> > rejected: subscription terminated due to change in 
> > authorization policy.
> > Retrying will not help.
> > 
> > timeout: subscription terminated because it was not refreshed. 
> > 
> > giveup: could not obtain authorization in a timely fashion, 
> and so the
> > pending subscription is being terminated. The client can 
> > retry and will
> > likely get put back into pending state.
> > 
> > THanks,
> > Jonathan R.
> > 
>  
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

------_=_NextPart_001_01C18214.9AAD4CD0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Sip] FW: [Simple] Alignment of sip-events and watcherinfo








> -----Original Message-----

> From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]

> Sent: Monday, December 10, 2001 6:48 PM

> To: 'Jonathan Rosenberg'; 'sip@ietf.org'

> Cc: 'simple@mailman.dynamicsoft.com'

> Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and 

> watcherinfo

> 

> 

> Hi Jonathan,

> 

> > 

> > (resend; first attempt seemed to have been garbled)

> > 

> > 

> > I'm cc'ing SIMPLE since this is a joint issue that affects both the

> > watcherinfo work and sip-events. Also, sip-events is a sip 

> > work item, not

> > sipping, so I am changing the list to sip.

> >  

> 

> Re-adding SIMPLE after resend.

> 

> > > I would like to suggest the watherinfo reason codes are 

> > > expanded a little.

> > > For instance, the watcherinfo assumes that the pending states 

> > > is waiting for

> > > authorization. It could however be pending while waiting for 

> > > the subscribed

> > > object to become active (note: I am not referring to the 

> > > subscribed Event

> > > package here). This sort of behavior may be typical/useful 

> > > when you are

> > > trying to subscribe to an event that has not started yet (and 

> > > yet you desire

> > > to have the subscription in place _before_ the event begins). 

> > 

> > OK, but in this case, the subscription itself is not pending, 

> > its the state

> > of the object that is effectively "TBD". This should be 

> > reflected in the

> > presence document delivered in the first NOTIFY, not in the 

> > state of the

> > subscription, IMHO.

> 

> I disagree. I think this is very much the concern of 

> subscription and not

> the Event package. 

> 

> Example: If I create a subscription that is associated with a 

> televised

> concert that occurs at some time in the future. When the 

> concert finishes,

> obviously the subscription should also terminate, the reason for the

> termination is that the subscribed object has terminated. 

> This is not an

> Event Package related reason. Likewise, every Event Package (e.g., my

> "Excessive Decibels" Monitoring Event Package) should not 

> have to deal with

> understanding/reporting when the concert is valid (and why 

> the subscription

> was terminated) - the package is only concerned with 

> reporting when the

> audio component of the associated object exceeds a certain threshold.

> <contrived but it will do>

> 

> This argument applies equally to the pending state. I want to create a

> subscription to this concert before it starts so I don't miss 

> the beginning.

> So the subscription is not active until the concert actually 

> starts - once

> again my Decibel Monitoring Event Package has no concern for 

> this. It is a

> function of the subscription itself to know when the object 

> (and hence the

> subscription) is pending/active/terminated.

> 

> Thus both the terminated & pending reason causes should be

> Subscription-Expire reasons and not solely contained in the 

> Event package

> bodies themselves. 




I would have to disagree (is there any other reason to post to this thread =). 




I think there's a co-mingling of terms that is going on here, either that or I've totally misunderstood what you were trying to get across. 



A subscription being pending or active, at least to me when I brought up my proposal to split out the subscription state from the message body about a month back, dealt completely with the actual state of the subscription, not the resource it is watching.



In your scenario, even though the resource is pending (the concert hasn't started yet), the subscription to it is NOT pending. It's active. You will receive a notification when that concert begins (should that be the behavoir that the subscription was setup to handle). If the subscription were pending, meaning it had not been authorized, you would NOT get a notification that the concert started necessarily. Likewise, there's no reason that the subscription needs to be terminated explicitly either. The server processing your subscription could simply send you a final NOTIFY (the concert ended) and then dump the subscription in the bit bucket. It's not very polite, but it's allowed in the draft.



Therefore, the two are distinct. This is what I was trying to avoid by suggesting that using an "Illegal" message body in the NOTIFY doesn't work well, and thus, we need a more explicit header to do the job to keep everything more understandible.



A subscription can be pending to an active resource, or pending to a pending resource. The two are distinct. They are separate finite state machines, and thus should be processed separately. The state that the subscription is in has nothing at all to do with the state of the resource on a basic level. The resource may cause the subscription to be handled differently, for sure, but at a generic sip-events level, there is no coupling in my mind.



Cheers,




Brian




> 

> > > I also think

> > > the rejection/termination reasons could be expanded a little more.

> > 

> > Suggestions?

> > 

> 

> I made a couple in my last email (some of which you have 

> already covered):

> 

>       - Terminated/rejected because authorization failed

>       - Terminated because subscribed object terminated

>       - Terminated because subscriber requested termination.

>       - Expired. Subscriber did not refresh subscription.

>       - Terminated at request of notifier.

> 

> Regards,

> 

> Robert.

> 

> > > 

> > > I can't see much use in including the 

> > > event field since

> > > (presumably) the watcher will know what event triggered the 

> > > NOTIFY, and if

> > > they can't, they can use watcherinfo to get it.

> > 

> > No, these are not events of the presentity, they are events of the

> > subscription. These events correspond quite closely to the "reason"

> > parameters Adam has currently specified. In fact, for the 

> > rejecttion events,

> > here is the mapping:

> > 

> > sip-events      watcherinfo

> > ----------      -----------

> > migration  <->   deactivated

> > maint      <->    ?

> > refused    <->   rejected

> > timeout    <->   expired

> >  ?         <->   timeout

> > 

> > Clearly, these should be aligned, and should be present in both the

> > SUbscription-Expires and the watcherinfo format. 

> > 

> > Its not clear to me what the semantics of maint are; should 

> > the client retry

> > after some period? Presuming we can define it conciesely, we 

> > should add it

> > to the watcherinfo package. 

> > 

> > So, here would be my proposal for the unified set:

> > 

> > deactivated: subscription is terminated, but client SHOULD 

> > retry immediately

> > with a new subscription. This handles migration plus other cases

> > potentially.

> > 

> > probation: subscription is terminated; but client SHOULD 

> > retry at some later

> > time (we could include a Retry-After header in the case of 

> > presence in the

> > Subscription-Expires header)

> > 

> > rejected: subscription terminated due to change in 

> > authorization policy.

> > Retrying will not help.

> > 

> > timeout: subscription terminated because it was not refreshed. 

> > 

> > giveup: could not obtain authorization in a timely fashion, 

> and so the

> > pending subscription is being terminated. The client can 

> > retry and will

> > likely get put back into pending state.

> > 

> > THanks,

> > Jonathan R.

> > 

>  

> _______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple

> 





------_=_NextPart_001_01C18214.9AAD4CD0--

From seancolson@yahoo.com  Wed Dec 12 16:29:36 2001
Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA11358
	for ; Wed, 12 Dec 2001 16:29:35 -0500 (EST)
Message-ID: <20011212212908.84557.qmail@web11606.mail.yahoo.com>
Received: from [12.131.201.74] by web11606.mail.yahoo.com via HTTP; Wed, 12 Dec 2001 13:29:08 PST
Date: Wed, 12 Dec 2001 13:29:08 -0800 (PST)
From: Sean Olson 
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1128
Subject: [Simple] Duration of URIs in application/uri-list for 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: 

Just a follow up to meeting discussion. 
There seemed to be consensus that there is a 
need to clarify the duration of validity of
URIs carried in application/uri-list body
of a presence NOTIFY.

Since this type of payload in a NOTIFY is 
meant as an alert that a change has occurred
without directly carrying the change in the
body and since there is a desire to maintain
equivalent semantics with the case where the
NOTIFY *does* carry the actual presence document,
I propose the following:

At a default the URI list should contain a HTTP
URL. This HTTP URL should be valid *at least*
for one HTTP GET request. This is exactly the 
guarantee you have when you receive a NOTIFY
with a presence payload. Any duration longer
than a single HTTP fetch should be allowed
but should be completely up to the implementation.

/sean

=====
--
Sean Olson 
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

From pkyzivat@cisco.com  Wed Dec 12 18:29:53 2001
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 SAA11777
	for ; Wed, 12 Dec 2001 18:29:52 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBCNTSn06124;
	Wed, 12 Dec 2001 18:29:28 -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 AAG20495 (AUTH pkyzivat);
	Wed, 12 Dec 2001 18:30:43 -0500 (EST)
Message-ID: <3C17E771.1192E5DF@cisco.com>
Date: Wed, 12 Dec 2001 18:25:37 -0500
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: Sean Olson 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
References: <20011212212908.84557.qmail@web11606.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 650
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: 


Sean Olson wrote:

[snip]

> At a default the URI list should contain a HTTP
> URL. This HTTP URL should be valid *at least*
> for one HTTP GET request. This is exactly the
> guarantee you have when you receive a NOTIFY
> with a presence payload. Any duration longer
> than a single HTTP fetch should be allowed
> but should be completely up to the implementation.

What if the recipient waits a few hours (or days)
before issuing the GET? Must the URL still be valid?
I don't think that you can reasonably mandate that it
must.

Can you really require much more than that the URL
is valid for a GET at the time the message referencing
it is sent?

From seancolson@yahoo.com  Wed Dec 12 18:43:47 2001
Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA11845
	for ; Wed, 12 Dec 2001 18:43:46 -0500 (EST)
Message-ID: <20011212234318.94855.qmail@web11608.mail.yahoo.com>
Received: from [12.131.201.74] by web11608.mail.yahoo.com via HTTP; Wed, 12 Dec 2001 15:43:18 PST
Date: Wed, 12 Dec 2001 15:43:18 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
To: Paul Kyzivat 
Cc: simple@mailman.dynamicsoft.com
In-Reply-To: <3C17E771.1192E5DF@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1379
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: 

Good point. The issue is how long do you keep
this around after the 200 OK for the NOTIFY is
received. Seconds, minutes, hours. My initial
impression is to keep the state around on the
web server for the duration of the subscription.
In any event, couldn't this duration be communicated
in the Expires: header of the NOTIFY?

/sean

--- Paul Kyzivat  wrote:
> 
> 
> Sean Olson wrote:
> 
> [snip]
> 
> > At a default the URI list should contain a HTTP
> > URL. This HTTP URL should be valid *at least*
> > for one HTTP GET request. This is exactly the
> > guarantee you have when you receive a NOTIFY
> > with a presence payload. Any duration longer
> > than a single HTTP fetch should be allowed
> > but should be completely up to the implementation.
> 
> What if the recipient waits a few hours (or days)
> before issuing the GET? Must the URL still be valid?
> I don't think that you can reasonably mandate that
> it
> must.
> 
> Can you really require much more than that the URL
> is valid for a GET at the time the message
> referencing
> it is sent?


=====
--
Sean Olson 
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

From pkyzivat@cisco.com  Wed Dec 12 19:01:06 2001
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 TAA11928
	for ; Wed, 12 Dec 2001 19:01:05 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBD00gg07294;
	Wed, 12 Dec 2001 19:00:42 -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 AAG20609 (AUTH pkyzivat);
	Wed, 12 Dec 2001 19:01:58 -0500 (EST)
Message-ID: <3C17EEC4.D0A64F04@cisco.com>
Date: Wed, 12 Dec 2001 18:56:52 -0500
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: Sean Olson 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
References: <20011212234318.94855.qmail@web11608.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1375
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: 

Sean,

The obvious thing to do, if the web server and the presence server are
sufficiently integrated, is to have the URL encode the identity of the
subscription. Then when a GET is received, the then-current presence
document can be returned. Nothing special need be kept that isn't
already being kept by the presence server. It doesn't matter if the
presence document has changed value serveral times between when the url
was returned and when it is fetched.

But while this is a reasonable and obvious thing to do, I don't think it
ought to be mandated.

Your other suggestion - to use the Expires header to convey how long the
URL will remain valid is another possibility, but one that is perhaps
not very useful. For instance, that duration may not be known, such as
when the technique above is being used. And there is nothing to prevent
returning Expires:0, which would then be accurate but not useful. 

Seems to me that this just has to be left to common sense and the
judgment of the marketplace.

	Paul

Sean Olson wrote:
> 
> Good point. The issue is how long do you keep
> this around after the 200 OK for the NOTIFY is
> received. Seconds, minutes, hours. My initial
> impression is to keep the state around on the
> web server for the duration of the subscription.
> In any event, couldn't this duration be communicated
> in the Expires: header of the NOTIFY?

From seancolson@yahoo.com  Wed Dec 12 19:03:13 2001
Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id TAA11948
	for ; Wed, 12 Dec 2001 19:03:12 -0500 (EST)
Message-ID: <20011213000238.39018.qmail@web11603.mail.yahoo.com>
Received: from [12.131.201.74] by web11603.mail.yahoo.com via HTTP; Wed, 12 Dec 2001 16:02:38 PST
Date: Wed, 12 Dec 2001 16:02:38 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
To: Paul Kyzivat 
Cc: simple@mailman.dynamicsoft.com
In-Reply-To: <3C17EEC4.D0A64F04@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 2088
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: 

I'm perfectly happy to leave this as an implementation
detail -- that is what I argued for in the meeting.
I was just trying to come up with a solution that
would be reasonable to insert in the draft to
satisfy those that thought it should be standardized.
cheers,
sean

--- Paul Kyzivat  wrote:
> Sean,
> 
> The obvious thing to do, if the web server and the
> presence server are
> sufficiently integrated, is to have the URL encode
> the identity of the
> subscription. Then when a GET is received, the
> then-current presence
> document can be returned. Nothing special need be
> kept that isn't
> already being kept by the presence server. It
> doesn't matter if the
> presence document has changed value serveral times
> between when the url
> was returned and when it is fetched.
> 
> But while this is a reasonable and obvious thing to
> do, I don't think it
> ought to be mandated.
> 
> Your other suggestion - to use the Expires header to
> convey how long the
> URL will remain valid is another possibility, but
> one that is perhaps
> not very useful. For instance, that duration may not
> be known, such as
> when the technique above is being used. And there is
> nothing to prevent
> returning Expires:0, which would then be accurate
> but not useful. 
> 
> Seems to me that this just has to be left to common
> sense and the
> judgment of the marketplace.
> 
> 	Paul
> 
> Sean Olson wrote:
> > 
> > Good point. The issue is how long do you keep
> > this around after the 200 OK for the NOTIFY is
> > received. Seconds, minutes, hours. My initial
> > impression is to keep the state around on the
> > web server for the duration of the subscription.
> > In any event, couldn't this duration be
> communicated
> > in the Expires: header of the NOTIFY?


=====
--
Sean Olson 
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

From bstucker@americasm01.nt.com  Thu Dec 13 02:35:16 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13367
	for ; Thu, 13 Dec 2001 02:35:16 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBD7YVY02929;
	Thu, 13 Dec 2001 01:34:31 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 13 Dec 2001 01:33:20 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E011D8180@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: "'Sean Olson'" , Paul Kyzivat 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	e
Date: Thu, 13 Dec 2001 01:33:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C183A8.7E19A9C0"
Content-Length: 14224
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: 

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_01C183A8.7E19A9C0
Content-Type: text/plain;
	charset="iso-8859-1"

While I can see both sides, that it's definitely an implementation detail, I
also think we should go ahead (as I mentioned in the meeting) and try to
come up with a reasonable expectation for the MINIMUM requirement for the
URI.

I could care less if someone wants to keep the document around for a day, or
go off and fetch it hours later. The information is likely to be incorrect
over periods of time that large.

It's also true, as Paul points out very clearly, that it's pretty obvious
that there need not be an actual document. The HTTP URI could point to some
process that creates a new copy of the document right then and there based
off of stored information. 

So, here's a proposal...

Can we all agree that it's a reasonable expectation that a request URI be
valid for AT LEAST:

1. Some trivial interval, say 90 seconds as a starting point, but that it is
somehow conveyed to the user how long to expect that URL to be good for.
2. The next NOTIFY for that subscription.

The reason I bring this up is so we don't have implementations running
around that assume that the client is going to instantly try to fetch that
URL all the time, and so client devices have enough information to know how
long they can reasonably postpone fetching the document if they're up to
something else when they receive the notification (like a phone call on a
narrowband link). Another reason I bring this up, is so we don't have to
worry about overlapping HTTP addresses where we wind up with two possible
outstanding URLs sitting out there. Simply put, we're limiting and
directing, in a very flexible manner what sort of behavoir to expect out of
the client and the server in order to interoperate correctly.

I am shocked at the amount of vehemence that this topic has created. I just
fail to see why it's such a big deal to simply come to an agreement as to
either how long is reasonable for a client to expect a server to keep a
document around if it doesn't tell the client explicitly, or to otherwise
tell the client so it doesn't make a bad assumption.

I wish someone that feels strongly that this shouldn't be specified, or that
a mechanism for communicating the interval of reason shouldn't be specified,
would explain their discomfort beyond simply saying "that's an
implementation detail". It's an interop detail, and to me that puts it into
the realm of what should be specified.

Cheers,

Brian Stucker

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Wednesday, December 12, 2001 6:03 PM
> To: Paul Kyzivat
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presence
> 
> 
> I'm perfectly happy to leave this as an implementation
> detail -- that is what I argued for in the meeting.
> I was just trying to come up with a solution that
> would be reasonable to insert in the draft to
> satisfy those that thought it should be standardized.
> cheers,
> sean
> 
> --- Paul Kyzivat  wrote:
> > Sean,
> > 
> > The obvious thing to do, if the web server and the
> > presence server are
> > sufficiently integrated, is to have the URL encode
> > the identity of the
> > subscription. Then when a GET is received, the
> > then-current presence
> > document can be returned. Nothing special need be
> > kept that isn't
> > already being kept by the presence server. It
> > doesn't matter if the
> > presence document has changed value serveral times
> > between when the url
> > was returned and when it is fetched.
> > 
> > But while this is a reasonable and obvious thing to
> > do, I don't think it
> > ought to be mandated.
> > 
> > Your other suggestion - to use the Expires header to
> > convey how long the
> > URL will remain valid is another possibility, but
> > one that is perhaps
> > not very useful. For instance, that duration may not
> > be known, such as
> > when the technique above is being used. And there is
> > nothing to prevent
> > returning Expires:0, which would then be accurate
> > but not useful. 
> > 
> > Seems to me that this just has to be left to common
> > sense and the
> > judgment of the marketplace.
> > 
> > 	Paul
> > 
> > Sean Olson wrote:
> > > 
> > > Good point. The issue is how long do you keep
> > > this around after the 200 OK for the NOTIFY is
> > > received. Seconds, minutes, hours. My initial
> > > impression is to keep the state around on the
> > > web server for the duration of the subscription.
> > > In any event, couldn't this duration be
> > communicated
> > > in the Expires: header of the NOTIFY?
> 
> 
> =====
> --
> Sean Olson 
> This is from me. Assume nothing else.
> 
> __________________________________________________
> Do You Yahoo!?
> Check out Yahoo! Shopping and Yahoo! Auctions for all of
> your unique holiday gifts! Buy at http://shopping.yahoo.com
> or bid at http://auctions.yahoo.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

------_=_NextPart_001_01C183A8.7E19A9C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Duration of URIs in application/uri-list for =
Presence




While I can see both sides, that it's definitely an =
implementation detail, I also think we should go ahead (as I mentioned =
in the meeting) and try to come up with a reasonable expectation for =
the MINIMUM requirement for the URI.



I could care less if someone wants to keep the =
document around for a day, or go off and fetch it hours later. The =
information is likely to be incorrect over periods of time that =
large.



It's also true, as Paul points out very clearly, that =
it's pretty obvious that there need not be an actual document. The HTTP =
URI could point to some process that creates a new copy of the document =
right then and there based off of stored information. 



So, here's a proposal...




Can we all agree that it's a reasonable expectation =
that a request URI be valid for AT LEAST:




1. Some trivial interval, say 90 seconds as a =
starting point, but that it is somehow conveyed to the user how long to =
expect that URL to be good for.



2. The next NOTIFY for that subscription.




The reason I bring this up is so we don't have =
implementations running around that assume that the client is going to =
instantly try to fetch that URL all the time, and so client devices =
have enough information to know how long they can reasonably postpone =
fetching the document if they're up to something else when they receive =
the notification (like a phone call on a narrowband link). Another =
reason I bring this up, is so we don't have to worry about overlapping =
HTTP addresses where we wind up with two possible outstanding URLs =
sitting out there. Simply put, we're limiting and directing, in a very =
flexible manner what sort of behavoir to expect out of the client and =
the server in order to interoperate correctly.



I am shocked at the amount of vehemence that this =
topic has created. I just fail to see why it's such a big deal to =
simply come to an agreement as to either how long is reasonable for a =
client to expect a server to keep a document around if it doesn't tell =
the client explicitly, or to otherwise tell the client so it doesn't =
make a bad assumption.



I wish someone that feels strongly that this =
shouldn't be specified, or that a mechanism for communicating the =
interval of reason shouldn't be specified, would explain their =
discomfort beyond simply saying "that's an implementation =
detail". It's an interop detail, and to me that puts it into the =
realm of what should be specified.



Cheers,




Brian Stucker




> -----Original Message-----

> From: Sean Olson [mailto:seancolson@yahoo.com]

> Sent: Wednesday, December 12, 2001 6:03 =
PM

> To: Paul Kyzivat

> Cc: simple@mailman.dynamicsoft.com

> Subject: Re: [Simple] Duration of URIs in =
application/uri-list for

> Presence

> 

> 

> I'm perfectly happy to leave this as an =
implementation

> detail -- that is what I argued for in the =
meeting.

> I was just trying to come up with a solution =
that

> would be reasonable to insert in the draft =
to

> satisfy those that thought it should be =
standardized.

> cheers,

> sean

> 

> --- Paul Kyzivat <pkyzivat@cisco.com> =
wrote:

> > Sean,

> > 

> > The obvious thing to do, if the web server =
and the

> > presence server are

> > sufficiently integrated, is to have the =
URL encode

> > the identity of the

> > subscription. Then when a GET is received, =
the

> > then-current presence

> > document can be returned. Nothing special =
need be

> > kept that isn't

> > already being kept by the presence server. =
It

> > doesn't matter if the

> > presence document has changed value =
serveral times

> > between when the url

> > was returned and when it is =
fetched.

> > 

> > But while this is a reasonable and obvious =
thing to

> > do, I don't think it

> > ought to be mandated.

> > 

> > Your other suggestion - to use the Expires =
header to

> > convey how long the

> > URL will remain valid is another =
possibility, but

> > one that is perhaps

> > not very useful. For instance, that =
duration may not

> > be known, such as

> > when the technique above is being used. =
And there is

> > nothing to prevent

> > returning Expires:0, which would then be =
accurate

> > but not useful. 

> > 

> > Seems to me that this just has to be left =
to common

> > sense and the

> > judgment of the marketplace.

> > 

> >     Paul

> > 

> > Sean Olson wrote:

> > > 

> > > Good point. The issue is how long do =
you keep

> > > this around after the 200 OK for the =
NOTIFY is

> > > received. Seconds, minutes, hours. My =
initial

> > > impression is to keep the state =
around on the

> > > web server for the duration of the =
subscription.

> > > In any event, couldn't this duration =
be

> > communicated

> > > in the Expires: header of the =
NOTIFY?

> 

> 

> =3D=3D=3D=3D=3D

> --

> Sean Olson <seancolson@yahoo.com>

> This is from me. Assume nothing else.

> 

> =
__________________________________________________

> Do You Yahoo!?

> Check out Yahoo! Shopping and Yahoo! Auctions =
for all of

> your unique holiday gifts! Buy at http://shopping.yah=
oo.com

> or bid at http://auctions.yahoo.com

> =
_______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple=


> 





------_=_NextPart_001_01C183A8.7E19A9C0--

From lachlan.brazier@siemens.at  Thu Dec 13 03:26:54 2001
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 DAA13552
	for ; Thu, 13 Dec 2001 03:26:53 -0500 (EST)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id fBD8QPT13998;
	Thu, 13 Dec 2001 09:26:25 +0100
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id JAA20308;
	Thu, 13 Dec 2001 09:26:21 +0100 (MET)
Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta)
	id xma019405; Thu, 13 Dec 01 09:24:46 +0100
Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id ; Thu, 13 Dec 2001 09:24:41 +0100
Message-ID: 
From: Brazier Lachlan 
To: "'Brian Stucker'" ,
        "'Sean Olson'"
	 ,
        Paul Kyzivat 
Cc: simple@mailman.dynamicsoft.com
Subject: AW: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Thu, 13 Dec 2001 09:24:40 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3143
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA13552
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: 

Hello

I think it needs to be specified what it means, when the URI isn't valid
anymore (Reasons like broken webserver,
no document, ...).

When something like this happens, does the last valid presence document
count? Is the subscription expired or not? 

It just occurs to me, I don't know what it means, when the presence document
doesn't fit the format it is supposed to be.
Does this touch the subscription state?

Any ideas?

Lachlan


-----Ursprüngliche Nachricht-----
Von: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Gesendet am: Donnerstag, 13. Dezember 2001 08:34
An: 'Sean Olson'; Paul Kyzivat
Cc: simple@mailman.dynamicsoft.com
Betreff: RE: [Simple] Duration of URIs in application/uri-list for Presenc e


While I can see both sides, that it's definitely an implementation detail, I
also think we should go ahead (as I mentioned in the meeting) and try to
come up with a reasonable expectation for the MINIMUM requirement for the
URI.
I could care less if someone wants to keep the document around for a day, or
go off and fetch it hours later. The information is likely to be incorrect
over periods of time that large.
It's also true, as Paul points out very clearly, that it's pretty obvious
that there need not be an actual document. The HTTP URI could point to some
process that creates a new copy of the document right then and there based
off of stored information. 
So, here's a proposal... 
Can we all agree that it's a reasonable expectation that a request URI be
valid for AT LEAST: 
1. Some trivial interval, say 90 seconds as a starting point, but that it is
somehow conveyed to the user how long to expect that URL to be good for.
2. The next NOTIFY for that subscription. 
The reason I bring this up is so we don't have implementations running
around that assume that the client is going to instantly try to fetch that
URL all the time, and so client devices have enough information to know how
long they can reasonably postpone fetching the document if they're up to
something else when they receive the notification (like a phone call on a
narrowband link). Another reason I bring this up, is so we don't have to
worry about overlapping HTTP addresses where we wind up with two possible
outstanding URLs sitting out there. Simply put, we're limiting and
directing, in a very flexible manner what sort of behavoir to expect out of
the client and the server in order to interoperate correctly.
I am shocked at the amount of vehemence that this topic has created. I just
fail to see why it's such a big deal to simply come to an agreement as to
either how long is reasonable for a client to expect a server to keep a
document around if it doesn't tell the client explicitly, or to otherwise
tell the client so it doesn't make a bad assumption.
I wish someone that feels strongly that this shouldn't be specified, or that
a mechanism for communicating the interval of reason shouldn't be specified,
would explain their discomfort beyond simply saying "that's an
implementation detail". It's an interop detail, and to me that puts it into
the realm of what should be specified.
Cheers, 
Brian Stucker 

[DELETE]

From bstucker@americasm01.nt.com  Thu Dec 13 03:40:47 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13642
	for ; Thu, 13 Dec 2001 03:40:47 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBD8YpY03776;
	Thu, 13 Dec 2001 02:34:51 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 13 Dec 2001 02:33:40 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E011D8184@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: "'Brazier Lachlan'" ,
        "'Sean Olson'"
	 ,
        Paul Kyzivat 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Thu, 13 Dec 2001 02:34:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C183B0.EB5E67C0"
Content-Length: 12650
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: 

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_01C183B0.EB5E67C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Good questions. I would argue that if the presence document cannot be
retrieved via the URL, that it does not affect the subscription. It =
would be
analogous to being sent a malformed CPIM-PIDF document in the NOTIFY =
itself
in my mind.

As far as the SIP Events portion of things are concerned, the duty of =
the
sip event draft was completed when the URI was given to the client, and =
what
happens with that URI afterwards has no bearing on the subscription =
itself.

Regards,

Brian

> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at]
> Sent: Thursday, December 13, 2001 2:25 AM
> To: Stucker, Brian [NGB:B635:EXCH]; 'Sean Olson'; Paul Kyzivat
> Cc: simple@mailman.dynamicsoft.com
> Subject: AW: [Simple] Duration of URIs in application/uri-list for
> Presenc e
>=20
>=20
> Hello
>=20
> I think it needs to be specified what it means, when the URI=20
> isn't valid
> anymore (Reasons like broken webserver,
> no document, ...).
>=20
> When something like this happens, does the last valid=20
> presence document
> count? Is the subscription expired or not?=20
>=20
> It just occurs to me, I don't know what it means, when the=20
> presence document
> doesn't fit the format it is supposed to be.
> Does this touch the subscription state?
>=20
> Any ideas?
>=20
> Lachlan
>=20
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: Brian Stucker [mailto:bstucker@nortelnetworks.com]
> Gesendet am: Donnerstag, 13. Dezember 2001 08:34
> An: 'Sean Olson'; Paul Kyzivat
> Cc: simple@mailman.dynamicsoft.com
> Betreff: RE: [Simple] Duration of URIs in=20
> application/uri-list for Presenc e
>=20
>=20
> While I can see both sides, that it's definitely an=20
> implementation detail, I
> also think we should go ahead (as I mentioned in the meeting)=20
> and try to
> come up with a reasonable expectation for the MINIMUM=20
> requirement for the
> URI.
> I could care less if someone wants to keep the document=20
> around for a day, or
> go off and fetch it hours later. The information is likely to=20
> be incorrect
> over periods of time that large.
> It's also true, as Paul points out very clearly, that it's=20
> pretty obvious
> that there need not be an actual document. The HTTP URI could=20
> point to some
> process that creates a new copy of the document right then=20
> and there based
> off of stored information.=20
> So, here's a proposal...=20
> Can we all agree that it's a reasonable expectation that a=20
> request URI be
> valid for AT LEAST:=20
> 1. Some trivial interval, say 90 seconds as a starting point,=20
> but that it is
> somehow conveyed to the user how long to expect that URL to=20
> be good for.
> 2. The next NOTIFY for that subscription.=20
> The reason I bring this up is so we don't have implementations =
running
> around that assume that the client is going to instantly try=20
> to fetch that
> URL all the time, and so client devices have enough=20
> information to know how
> long they can reasonably postpone fetching the document if=20
> they're up to
> something else when they receive the notification (like a=20
> phone call on a
> narrowband link). Another reason I bring this up, is so we=20
> don't have to
> worry about overlapping HTTP addresses where we wind up with=20
> two possible
> outstanding URLs sitting out there. Simply put, we're limiting and
> directing, in a very flexible manner what sort of behavoir to=20
> expect out of
> the client and the server in order to interoperate correctly.
> I am shocked at the amount of vehemence that this topic has=20
> created. I just
> fail to see why it's such a big deal to simply come to an=20
> agreement as to
> either how long is reasonable for a client to expect a server=20
> to keep a
> document around if it doesn't tell the client explicitly, or=20
> to otherwise
> tell the client so it doesn't make a bad assumption.
> I wish someone that feels strongly that this shouldn't be=20
> specified, or that
> a mechanism for communicating the interval of reason=20
> shouldn't be specified,
> would explain their discomfort beyond simply saying "that's an
> implementation detail". It's an interop detail, and to me=20
> that puts it into
> the realm of what should be specified.
> Cheers,=20
> Brian Stucker=20
>=20
> [DELETE]
>=20

------_=_NextPart_001_01C183B0.EB5E67C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Duration of URIs in application/uri-list for =
Presenc e




Good questions. I would argue that if the presence =
document cannot be retrieved via the URL, that it does not affect the =
subscription. It would be analogous to being sent a malformed CPIM-PIDF =
document in the NOTIFY itself in my mind.



As far as the SIP Events portion of things are =
concerned, the duty of the sip event draft was completed when the URI =
was given to the client, and what happens with that URI afterwards has =
no bearing on the subscription itself.



Regards,




Brian




> -----Original Message-----

> From: Brazier Lachlan [mailto:lachlan.brazier@siemen=
s.at]

> Sent: Thursday, December 13, 2001 2:25 =
AM

> To: Stucker, Brian [NGB:B635:EXCH]; 'Sean =
Olson'; Paul Kyzivat

> Cc: simple@mailman.dynamicsoft.com

> Subject: AW: [Simple] Duration of URIs in =
application/uri-list for

> Presenc e

> 

> 

> Hello

> 

> I think it needs to be specified what it means, =
when the URI 

> isn't valid

> anymore (Reasons like broken webserver,

> no document, ...).

> 

> When something like this happens, does the last =
valid 

> presence document

> count? Is the subscription expired or not? =


> 

> It just occurs to me, I don't know what it =
means, when the 

> presence document

> doesn't fit the format it is supposed to =
be.

> Does this touch the subscription state?

> 

> Any ideas?

> 

> Lachlan

> 

> 

> -----Urspr=FCngliche Nachricht-----

> Von: Brian Stucker [mailto:bstucker@nortelnetwor=
ks.com]

> Gesendet am: Donnerstag, 13. Dezember 2001 =
08:34

> An: 'Sean Olson'; Paul Kyzivat

> Cc: simple@mailman.dynamicsoft.com

> Betreff: RE: [Simple] Duration of URIs in =


> application/uri-list for Presenc e

> 

> 

> While I can see both sides, that it's =
definitely an 

> implementation detail, I

> also think we should go ahead (as I mentioned =
in the meeting) 

> and try to

> come up with a reasonable expectation for the =
MINIMUM 

> requirement for the

> URI.

> I could care less if someone wants to keep the =
document 

> around for a day, or

> go off and fetch it hours later. The =
information is likely to 

> be incorrect

> over periods of time that large.

> It's also true, as Paul points out very =
clearly, that it's 

> pretty obvious

> that there need not be an actual document. The =
HTTP URI could 

> point to some

> process that creates a new copy of the document =
right then 

> and there based

> off of stored information. 

> So, here's a proposal... 

> Can we all agree that it's a reasonable =
expectation that a 

> request URI be

> valid for AT LEAST: 

> 1. Some trivial interval, say 90 seconds as a =
starting point, 

> but that it is

> somehow conveyed to the user how long to expect =
that URL to 

> be good for.

> 2. The next NOTIFY for that subscription. =


> The reason I bring this up is so we don't have =
implementations running

> around that assume that the client is going to =
instantly try 

> to fetch that

> URL all the time, and so client devices have =
enough 

> information to know how

> long they can reasonably postpone fetching the =
document if 

> they're up to

> something else when they receive the =
notification (like a 

> phone call on a

> narrowband link). Another reason I bring this =
up, is so we 

> don't have to

> worry about overlapping HTTP addresses where we =
wind up with 

> two possible

> outstanding URLs sitting out there. Simply put, =
we're limiting and

> directing, in a very flexible manner what sort =
of behavoir to 

> expect out of

> the client and the server in order to =
interoperate correctly.

> I am shocked at the amount of vehemence that =
this topic has 

> created. I just

> fail to see why it's such a big deal to simply =
come to an 

> agreement as to

> either how long is reasonable for a client to =
expect a server 

> to keep a

> document around if it doesn't tell the client =
explicitly, or 

> to otherwise

> tell the client so it doesn't make a bad =
assumption.

> I wish someone that feels strongly that this =
shouldn't be 

> specified, or that

> a mechanism for communicating the interval of =
reason 

> shouldn't be specified,

> would explain their discomfort beyond simply =
saying "that's an

> implementation detail". It's an interop =
detail, and to me 

> that puts it into

> the realm of what should be specified.

> Cheers, 

> Brian Stucker 

> 

> [DELETE]

> 





------_=_NextPart_001_01C183B0.EB5E67C0--

From bcampbell@dynamicsoft.com  Thu Dec 13 11:57:15 2001
Received: from localhost.localdomain (143-201-131-12.bellhead.com [12.131.201.143])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15183
	for ; Thu, 13 Dec 2001 11:57:15 -0500 (EST)
Received: from rocinante (rocinante [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBDGoMI02390;
	Thu, 13 Dec 2001 10:50:22 -0600
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
From: Ben Campbell 
To: Paul Kyzivat 
Cc: Sean Olson , simple@mailman.dynamicsoft.com
In-Reply-To: <3C17EEC4.D0A64F04@cisco.com>
References: <20011212234318.94855.qmail@web11608.mail.yahoo.com> 
	<3C17EEC4.D0A64F04@cisco.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0 (Preview Release)
Date: 13 Dec 2001 10:50:22 -0600
Message-Id: <1008262222.1939.8.camel@rocinante>
Mime-Version: 1.0
Content-Length: 1853
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: 

On Wed, 2001-12-12 at 17:56, Paul Kyzivat wrote:
> Sean,
> 
> The obvious thing to do, if the web server and the presence server are
> sufficiently integrated, is to have the URL encode the identity of the
> subscription. Then when a GET is received, the then-current presence
> document can be returned. Nothing special need be kept that isn't
> already being kept by the presence server. It doesn't matter if the
> presence document has changed value serveral times between when the url
> was returned and when it is fetched.
> 
> But while this is a reasonable and obvious thing to do, I don't think it
> ought to be mandated.
> 
> Your other suggestion - to use the Expires header to convey how long the
> URL will remain valid is another possibility, but one that is perhaps
> not very useful. For instance, that duration may not be known, such as
> when the technique above is being used. And there is nothing to prevent
> returning Expires:0, which would then be accurate but not useful. 

How is that different from a normal presence expiration? One assumes
that if the presence state changes before I get around to getting the
data, I would get a new notify if I am still subscribed.


> 
> Seems to me that this just has to be left to common sense and the
> judgment of the marketplace.
> 
> 	Paul
> 
> Sean Olson wrote:
> > 
> > Good point. The issue is how long do you keep
> > this around after the 200 OK for the NOTIFY is
> > received. Seconds, minutes, hours. My initial
> > impression is to keep the state around on the
> > web server for the duration of the subscription.
> > In any event, couldn't this duration be communicated
> > in the Expires: header of the NOTIFY?
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple



From bcampbell@dynamicsoft.com  Thu Dec 13 12:13:35 2001
Received: from localhost.localdomain (143-201-131-12.bellhead.com [12.131.201.143])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15276
	for ; Thu, 13 Dec 2001 12:13:34 -0500 (EST)
Received: from rocinante (rocinante [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBDGtYI02404;
	Thu, 13 Dec 2001 10:55:35 -0600
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e
From: Ben Campbell 
To: Brian Stucker 
Cc: "'Sean Olson'" , Paul Kyzivat ,
        simple@mailman.dynamicsoft.com
In-Reply-To: 
	<933FADF5E673D411B8A30002A5608A0E011D8180@zrc2c012.us.nortel.com>
References: 
	<933FADF5E673D411B8A30002A5608A0E011D8180@zrc2c012.us.nortel.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0 (Preview Release)
Date: 13 Dec 2001 10:55:34 -0600
Message-Id: <1008262535.1939.10.camel@rocinante>
Mime-Version: 1.0
Content-Length: 5979
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: 

On Thu, 2001-12-13 at 01:33, Brian Stucker wrote:
> While I can see both sides, that it's definitely an implementation
> detail, I also think we should go ahead (as I mentioned in the meeting)
> and try to come up with a reasonable expectation for the MINIMUM
> requirement for the URI.
> 
> I could care less if someone wants to keep the document around for a
> day, or go off and fetch it hours later. The information is likely to be
> incorrect over periods of time that large.
> 
> It's also true, as Paul points out very clearly, that it's pretty
> obvious that there need not be an actual document. The HTTP URI could
> point to some process that creates a new copy of the document right then
> and there based off of stored information. 
> 
> So, here's a proposal... 
> 
> Can we all agree that it's a reasonable expectation that a request URI
> be valid for AT LEAST: 
> 
> 1. Some trivial interval, say 90 seconds as a starting point, but that
> it is somehow conveyed to the user how long to expect that URL to be
> good for.

I am not sure that specifying X seconds is really any different than
expecting an instant get, for any value of X. I do think using the
Expires header makes sense, though, which is sort of a variation.

> 
> 2. The next NOTIFY for that subscription. 

I have no problem with that, when combined with the Expires header.

I would also propose subscription termination as another limit for URL
freshness.

> 
> The reason I bring this up is so we don't have implementations running
> around that assume that the client is going to instantly try to fetch
> that URL all the time, and so client devices have enough information to
> know how long they can reasonably postpone fetching the document if
> they're up to something else when they receive the notification (like a
> phone call on a narrowband link). Another reason I bring this up, is so
> we don't have to worry about overlapping HTTP addresses where we wind up
> with two possible outstanding URLs sitting out there. Simply put, we're
> limiting and directing, in a very flexible manner what sort of behavoir
> to expect out of the client and the server in order to interoperate
> correctly.
> 
> I am shocked at the amount of vehemence that this topic has created. I
> just fail to see why it's such a big deal to simply come to an agreement
> as to either how long is reasonable for a client to expect a server to
> keep a document around if it doesn't tell the client explicitly, or to
> otherwise tell the client so it doesn't make a bad assumption.
> 
> I wish someone that feels strongly that this shouldn't be specified, or
> that a mechanism for communicating the interval of reason shouldn't be
> specified, would explain their discomfort beyond simply saying "that's
> an implementation detail". It's an interop detail, and to me that puts
> it into the realm of what should be specified.
> 
> Cheers, 
> 
> Brian Stucker 
> 
> > -----Original Message----- 
> > From: Sean Olson [ mailto:seancolson@yahoo.com
>  ] 
> > Sent: Wednesday, December 12, 2001 6:03 PM 
> > To: Paul Kyzivat 
> > Cc: simple@mailman.dynamicsoft.com 
> > Subject: Re: [Simple] Duration of URIs in application/uri-list for 
> > Presence 
> > 
> > 
> > I'm perfectly happy to leave this as an implementation 
> > detail -- that is what I argued for in the meeting. 
> > I was just trying to come up with a solution that 
> > would be reasonable to insert in the draft to 
> > satisfy those that thought it should be standardized. 
> > cheers, 
> > sean 
> > 
> > --- Paul Kyzivat  wrote: 
> > > Sean, 
> > > 
> > > The obvious thing to do, if the web server and the 
> > > presence server are 
> > > sufficiently integrated, is to have the URL encode 
> > > the identity of the 
> > > subscription. Then when a GET is received, the 
> > > then-current presence 
> > > document can be returned. Nothing special need be 
> > > kept that isn't 
> > > already being kept by the presence server. It 
> > > doesn't matter if the 
> > > presence document has changed value serveral times 
> > > between when the url 
> > > was returned and when it is fetched. 
> > > 
> > > But while this is a reasonable and obvious thing to 
> > > do, I don't think it 
> > > ought to be mandated. 
> > > 
> > > Your other suggestion - to use the Expires header to 
> > > convey how long the 
> > > URL will remain valid is another possibility, but 
> > > one that is perhaps 
> > > not very useful. For instance, that duration may not 
> > > be known, such as 
> > > when the technique above is being used. And there is 
> > > nothing to prevent 
> > > returning Expires:0, which would then be accurate 
> > > but not useful. 
> > > 
> > > Seems to me that this just has to be left to common 
> > > sense and the 
> > > judgment of the marketplace. 
> > > 
> > >     Paul 
> > > 
> > > Sean Olson wrote: 
> > > > 
> > > > Good point. The issue is how long do you keep 
> > > > this around after the 200 OK for the NOTIFY is 
> > > > received. Seconds, minutes, hours. My initial 
> > > > impression is to keep the state around on the 
> > > > web server for the duration of the subscription. 
> > > > In any event, couldn't this duration be 
> > > communicated 
> > > > in the Expires: header of the NOTIFY? 
> > 
> > 
> > ===== 
> > -- 
> > Sean Olson  
> > This is from me. Assume nothing else. 
> > 
> > __________________________________________________ 
> > Do You Yahoo!? 
> > Check out Yahoo! Shopping and Yahoo! Auctions for all of 
> > your unique holiday gifts! Buy at http://shopping.yahoo.com
>   
> > or bid at http://auctions.yahoo.com   
> > _______________________________________________ 
> > simple mailing list 
> > simple@mailman.dynamicsoft.com 
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
>   
> > 
> 



From pkyzivat@cisco.com  Thu Dec 13 13:24:06 2001
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 NAA15514
	for ; Thu, 13 Dec 2001 13:24:05 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBDINhx18757;
	Thu, 13 Dec 2001 13:23: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 AAG25921 (AUTH pkyzivat);
	Thu, 13 Dec 2001 13:24:59 -0500 (EST)
Message-ID: <3C18F146.AE28C2F8@cisco.com>
Date: Thu, 13 Dec 2001 13:19:50 -0500
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: Ben Campbell 
CC: Sean Olson , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
References: <20011212234318.94855.qmail@web11608.mail.yahoo.com> 
		<3C17EEC4.D0A64F04@cisco.com> <1008262222.1939.8.camel@rocinante>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1933
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: 


Ben Campbell wrote:
> 
> On Wed, 2001-12-12 at 17:56, Paul Kyzivat wrote:
> >
> > Your other suggestion - to use the Expires header to convey how long the
> > URL will remain valid is another possibility, but one that is perhaps
> > not very useful. For instance, that duration may not be known, such as
> > when the technique above is being used. And there is nothing to prevent
> > returning Expires:0, which would then be accurate but not useful.
> 
> How is that different from a normal presence expiration? One assumes
> that if the presence state changes before I get around to getting the
> data, I would get a new notify if I am still subscribed.

Perhaps it isn't different, but it depends on how you interpret the
Expires header.

In a NOTIFY there is a difference between Expires and
Subscription-Expires.
Expires applies to the specific notification. 

If you interpret Expires for something like MESSAGE, it presumably says
something about how long the message content is meaningful. This is
probably independent of any other messages that you might subsequently
receive. So if I send you a message asking if you want to go to lunch
today, I can set the expiration to the time I intend to leave for lunch.
I can then send you other unrelated messages with different expirations,
but they leave my lunch invitation unaffected.

With the presence notification however, when sending it I in general
don't know how long it will be valid. Generally it will be valid until I
send another one. I could include an Expires header with the same value
as Subscription-Expires, and that would be correct if there are no
further changes until expiration. But it will be rendered incorrect as
soon as I send out a revised notification.

So at the least, expires values for notifications need to be taken with
a grain of salt. Old ones need to be discarded when new ones are
received, even if the old one has not yet expired.

	Paul

From bcampbell@dynamicsoft.com  Thu Dec 13 13:35:36 2001
Received: from localhost.localdomain (143-201-131-12.bellhead.com [12.131.201.143])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15569
	for ; Thu, 13 Dec 2001 13:35:36 -0500 (EST)
Received: from rocinante (rocinante [127.0.0.1])
	by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fBDITbI02866;
	Thu, 13 Dec 2001 12:29:37 -0600
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
From: Ben Campbell 
To: Paul Kyzivat 
Cc: Sean Olson , simple@mailman.dynamicsoft.com
In-Reply-To: <3C18F146.AE28C2F8@cisco.com>
References: <20011212234318.94855.qmail@web11608.mail.yahoo.com> 
	<3C17EEC4.D0A64F04@cisco.com> <1008262222.1939.8.camel@rocinante> 
	<3C18F146.AE28C2F8@cisco.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Evolution/1.0 (Preview Release)
Date: 13 Dec 2001 12:29:37 -0600
Message-Id: <1008268177.1916.16.camel@rocinante>
Mime-Version: 1.0
Content-Length: 2707
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: 

On Thu, 2001-12-13 at 12:19, Paul Kyzivat wrote:
> 
> 
> Ben Campbell wrote:
> > 
> > On Wed, 2001-12-12 at 17:56, Paul Kyzivat wrote:
> > >
> > > Your other suggestion - to use the Expires header to convey how long the
> > > URL will remain valid is another possibility, but one that is perhaps
> > > not very useful. For instance, that duration may not be known, such as
> > > when the technique above is being used. And there is nothing to prevent
> > > returning Expires:0, which would then be accurate but not useful.
> > 
> > How is that different from a normal presence expiration? One assumes
> > that if the presence state changes before I get around to getting the
> > data, I would get a new notify if I am still subscribed.
> 
> Perhaps it isn't different, but it depends on how you interpret the
> Expires header.
> 
> In a NOTIFY there is a difference between Expires and
> Subscription-Expires.
> Expires applies to the specific notification. 
> 
> If you interpret Expires for something like MESSAGE, it presumably says
> something about how long the message content is meaningful. This is
> probably independent of any other messages that you might subsequently
> receive. So if I send you a message asking if you want to go to lunch
> today, I can set the expiration to the time I intend to leave for lunch.
> I can then send you other unrelated messages with different expirations,
> but they leave my lunch invitation unaffected.
> 
> With the presence notification however, when sending it I in general
> don't know how long it will be valid. Generally it will be valid until I
> send another one. I could include an Expires header with the same value
> as Subscription-Expires, and that would be correct if there are no
> further changes until expiration. But it will be rendered incorrect as
> soon as I send out a revised notification.
> 
> So at the least, expires values for notifications need to be taken with
> a grain of salt. Old ones need to be discarded when new ones are
> received, even if the old one has not yet expired.
> 
> 	Paul

I understand that. Expires in no way guarantees that the presence state
will not change before expiration. It does, however, give you a maximum
time for the presence state, that is, you should assume it is stale
after expiration, unless you have received other information to the
contrary.

That seems to map very closely to the model for the expiration of URLs
in a NOTIFY, if you say that you have a reasonable expectation of the
URL being good if it has not expired and you have not received a new
NOTIFY. The error scenario is when you miss a NOTIFY, but we have that
exact scenario when we deliver full presence docs in the NOTIFY.


From henrik.gustafsson@hotsip.com  Mon Dec 17 09:12:40 2001
Received: from hotsip.com ([212.28.214.249])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01127
	for ; Mon, 17 Dec 2001 09:12:38 -0500 (EST)
Received: from ughugh2 ([212.28.215.24]) by hotsip.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 17 Dec 2001 15:12:04 +0100
From: "Henrik Gustafsson" 
To: 
Date: Mon, 17 Dec 2001 15:10:28 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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.4807.1700
Importance: Normal
X-OriginalArrivalTime: 17 Dec 2001 14:12:04.0936 (UTC) FILETIME=[CE086480:01C18704]
Content-Length: 2345
Subject: [Simple] Message Delivery Notification
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: 

The paging model for messages will probably often
be used to gateway to SMS in the mobile network.
Delivery notification is a very useful service
in such a scenario. I would like a similar support
in the SIMPLE system. This proposal is not that
very thought through and I can see a number of
problems already with this proposal but the
initial requirement is still valid.

Message Progress Notification:
------------------------------
If a MESSAGE is sent with a contact and an
allow-events header:

  MESSAGE sip:hegu@company.com SIP/2.0
  ...
  Allow-Events: messageprogress
  Contact: ;methods="NOTIFY"
  ...

That could be an implicit subscription and later
on different notifications could be sent.

  NOTIFY sip:hegu@host SIP/2.0
  ...
  Event: messageprogress
  ...

  The mobile phone did not accept the message.
  Stored in server.

Later a notification with  "Message delivered.",
"Message read." or "Messages transformed to SMS.
The Message (400 characters) was split into 3
separate messages." could be sent.

This is controversial since the message draft clearly
states that contacts are not allowed in a MESSAGE.
However, this contact will not be used to establish a
message session.

The 200-response is used to end the MESSAGE SIP
transaction. If the receiving element supports
the message progress event package it MAY send
a notification. But you cannot depend on it.

Open Issues:
------------
Is it ok to add a contact to the MESSAGE? Could an
implicit subscription be used this way? How do you
know that the contact is still valid when the event
occurs? When does the "subscription" expire? Could
different elements in the message path generate
notifications? Would that be different to-tags and
would that look like notifies after a forked
subscribe?

This message progress notifications could also be
relevant in a message session ... but considering
non-SIP message transport like IMTP I don’t dare
to start that discussion. But today are well-known
IM user agents sending events like "the other party
is writing on a reply" within the message session.

I have recently started writing a draft on this.
I would really like some input, especially how this
could be done over IMTP or should an explicit
subscription be used? In the paging model I believe
an implicit subscription is the way to go.

/Henrik


From bstucker@americasm01.nt.com  Mon Dec 17 11:54:08 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01656
	for ; Mon, 17 Dec 2001 11:54:08 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBHGrGF28879;
	Mon, 17 Dec 2001 10:53:16 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 17 Dec 2001 10:51:50 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E01334421@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Ben Campbell ,
        Paul Kyzivat
	 
Cc: Sean Olson , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	e
Date: Mon, 17 Dec 2001 10:51:46 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1871B.1CF612C0"
Content-Length: 12294
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: 

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_01C1871B.1CF612C0
Content-Type: text/plain;
	charset="iso-8859-1"

I agree with Ben. Although you raise good points Paul.

Can we all agree to:

1. The URL is good for the interval expressed in the EXPIRES header of the
notification which contained the presence document URL, or the
Subscription-Expires (soon to be Subscription-State), whichever is shorter.
2. If another notification is received during the interval identified in
(1), then the previous URL should be considered stale. The most recent
notification always takes precedence.
3. If the subscription ends, any presence URLs associated with that
subscription should be considered stale.
4. If a notify is received with an EXPIRES set to zero, the URL is
considered dead-on-arrival.
5. If a notify is received without an EXPIRES header, the URL is good for
the duration of the subscription.

Cheers,

Brian

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Thursday, December 13, 2001 12:30 PM
> To: Paul Kyzivat
> Cc: Sean Olson; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presence
> 
> 
> On Thu, 2001-12-13 at 12:19, Paul Kyzivat wrote:
> > 
> > 
> > Ben Campbell wrote:
> > > 
> > > On Wed, 2001-12-12 at 17:56, Paul Kyzivat wrote:
> > > >
> > > > Your other suggestion - to use the Expires header to 
> convey how long the
> > > > URL will remain valid is another possibility, but one 
> that is perhaps
> > > > not very useful. For instance, that duration may not be 
> known, such as
> > > > when the technique above is being used. And there is 
> nothing to prevent
> > > > returning Expires:0, which would then be accurate but 
> not useful.
> > > 
> > > How is that different from a normal presence expiration? 
> One assumes
> > > that if the presence state changes before I get around to 
> getting the
> > > data, I would get a new notify if I am still subscribed.
> > 
> > Perhaps it isn't different, but it depends on how you interpret the
> > Expires header.
> > 
> > In a NOTIFY there is a difference between Expires and
> > Subscription-Expires.
> > Expires applies to the specific notification. 
> > 
> > If you interpret Expires for something like MESSAGE, it 
> presumably says
> > something about how long the message content is meaningful. This is
> > probably independent of any other messages that you might 
> subsequently
> > receive. So if I send you a message asking if you want to 
> go to lunch
> > today, I can set the expiration to the time I intend to 
> leave for lunch.
> > I can then send you other unrelated messages with different 
> expirations,
> > but they leave my lunch invitation unaffected.
> > 
> > With the presence notification however, when sending it I in general
> > don't know how long it will be valid. Generally it will be 
> valid until I
> > send another one. I could include an Expires header with 
> the same value
> > as Subscription-Expires, and that would be correct if there are no
> > further changes until expiration. But it will be rendered 
> incorrect as
> > soon as I send out a revised notification.
> > 
> > So at the least, expires values for notifications need to 
> be taken with
> > a grain of salt. Old ones need to be discarded when new ones are
> > received, even if the old one has not yet expired.
> > 
> > 	Paul
> 
> I understand that. Expires in no way guarantees that the 
> presence state
> will not change before expiration. It does, however, give you 
> a maximum
> time for the presence state, that is, you should assume it is stale
> after expiration, unless you have received other information to the
> contrary.
> 
> That seems to map very closely to the model for the expiration of URLs
> in a NOTIFY, if you say that you have a reasonable expectation of the
> URL being good if it has not expired and you have not received a new
> NOTIFY. The error scenario is when you miss a NOTIFY, but we have that
> exact scenario when we deliver full presence docs in the NOTIFY.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

------_=_NextPart_001_01C1871B.1CF612C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Duration of URIs in application/uri-list for =
Presence




I agree with Ben. Although you raise good points =
Paul.




Can we all agree to:




1. The URL is good for the interval expressed in the =
EXPIRES header of the notification which contained the presence =
document URL, or the Subscription-Expires (soon to be =
Subscription-State), whichever is shorter.



2. If another notification is received during the =
interval identified in (1), then the previous URL should be considered =
stale. The most recent notification always takes precedence.



3. If the subscription ends, any presence URLs =
associated with that subscription should be considered stale.

4. If a notify is received with an EXPIRES set to =
zero, the URL is considered dead-on-arrival.

5. If a notify is received without an EXPIRES =
header, the URL is good for the duration of the subscription.




Cheers,




Brian




> -----Original Message-----

> From: Ben Campbell [mailto:bcampbell@dynamicsoft.c=
om]

> Sent: Thursday, December 13, 2001 12:30 =
PM

> To: Paul Kyzivat

> Cc: Sean Olson; =
simple@mailman.dynamicsoft.com

> Subject: Re: [Simple] Duration of URIs in =
application/uri-list for

> Presence

> 

> 

> On Thu, 2001-12-13 at 12:19, Paul Kyzivat =
wrote:

> > 

> > 

> > Ben Campbell wrote:

> > > 

> > > On Wed, 2001-12-12 at 17:56, Paul =
Kyzivat wrote:

> > > >

> > > > Your other suggestion - to use =
the Expires header to 

> convey how long the

> > > > URL will remain valid is another =
possibility, but one 

> that is perhaps

> > > > not very useful. For instance, =
that duration may not be 

> known, such as

> > > > when the technique above is =
being used. And there is 

> nothing to prevent

> > > > returning Expires:0, which would =
then be accurate but 

> not useful.

> > > 

> > > How is that different from a normal =
presence expiration? 

> One assumes

> > > that if the presence state changes =
before I get around to 

> getting the

> > > data, I would get a new notify if I =
am still subscribed.

> > 

> > Perhaps it isn't different, but it depends =
on how you interpret the

> > Expires header.

> > 

> > In a NOTIFY there is a difference between =
Expires and

> > Subscription-Expires.

> > Expires applies to the specific =
notification. 

> > 

> > If you interpret Expires for something =
like MESSAGE, it 

> presumably says

> > something about how long the message =
content is meaningful. This is

> > probably independent of any other messages =
that you might 

> subsequently

> > receive. So if I send you a message asking =
if you want to 

> go to lunch

> > today, I can set the expiration to the =
time I intend to 

> leave for lunch.

> > I can then send you other unrelated =
messages with different 

> expirations,

> > but they leave my lunch invitation =
unaffected.

> > 

> > With the presence notification however, =
when sending it I in general

> > don't know how long it will be valid. =
Generally it will be 

> valid until I

> > send another one. I could include an =
Expires header with 

> the same value

> > as Subscription-Expires, and that would be =
correct if there are no

> > further changes until expiration. But it =
will be rendered 

> incorrect as

> > soon as I send out a revised =
notification.

> > 

> > So at the least, expires values for =
notifications need to 

> be taken with

> > a grain of salt. Old ones need to be =
discarded when new ones are

> > received, even if the old one has not yet =
expired.

> > 

> >     Paul

> 

> I understand that. Expires in no way guarantees =
that the 

> presence state

> will not change before expiration. It does, =
however, give you 

> a maximum

> time for the presence state, that is, you =
should assume it is stale

> after expiration, unless you have received =
other information to the

> contrary.

> 

> That seems to map very closely to the model for =
the expiration of URLs

> in a NOTIFY, if you say that you have a =
reasonable expectation of the

> URL being good if it has not expired and you =
have not received a new

> NOTIFY. The error scenario is when you miss a =
NOTIFY, but we have that

> exact scenario when we deliver full presence =
docs in the NOTIFY.

> 

> =
_______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple=


> 





------_=_NextPart_001_01C1871B.1CF612C0--

From seancolson@yahoo.com  Mon Dec 17 11:57:36 2001
Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA01685
	for ; Mon, 17 Dec 2001 11:57:35 -0500 (EST)
Message-ID: <20011217165708.48004.qmail@web11606.mail.yahoo.com>
Received: from [194.237.142.30] by web11606.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 08:57:08 PST
Date: Mon, 17 Dec 2001 08:57:08 -0800 (PST)
From: Sean Olson 
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e
To: Brian Stucker ,
        Ben Campbell ,
        Paul Kyzivat 
Cc: Sean Olson , simple@mailman.dynamicsoft.com
In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01334421@zrc2c012.us.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 4928
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: 

This sounds like a very good proposal.
Anything more complex would start to infringe
on the implementors domain.

Cheers,
Sean

--- Brian Stucker  wrote:
> I agree with Ben. Although you raise good points
> Paul.
> 
> Can we all agree to:
> 
> 1. The URL is good for the interval expressed in the
> EXPIRES header of the
> notification which contained the presence document
> URL, or the
> Subscription-Expires (soon to be
> Subscription-State), whichever is shorter.
> 2. If another notification is received during the
> interval identified in
> (1), then the previous URL should be considered
> stale. The most recent
> notification always takes precedence.
> 3. If the subscription ends, any presence URLs
> associated with that
> subscription should be considered stale.
> 4. If a notify is received with an EXPIRES set to
> zero, the URL is
> considered dead-on-arrival.
> 5. If a notify is received without an EXPIRES
> header, the URL is good for
> the duration of the subscription.
> 
> Cheers,
> 
> Brian
> 
> > -----Original Message-----
> > From: Ben Campbell
> [mailto:bcampbell@dynamicsoft.com]
> > Sent: Thursday, December 13, 2001 12:30 PM
> > To: Paul Kyzivat
> > Cc: Sean Olson; simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] Duration of URIs in
> application/uri-list for
> > Presence
> > 
> > 
> > On Thu, 2001-12-13 at 12:19, Paul Kyzivat wrote:
> > > 
> > > 
> > > Ben Campbell wrote:
> > > > 
> > > > On Wed, 2001-12-12 at 17:56, Paul Kyzivat
> wrote:
> > > > >
> > > > > Your other suggestion - to use the Expires
> header to 
> > convey how long the
> > > > > URL will remain valid is another
> possibility, but one 
> > that is perhaps
> > > > > not very useful. For instance, that duration
> may not be 
> > known, such as
> > > > > when the technique above is being used. And
> there is 
> > nothing to prevent
> > > > > returning Expires:0, which would then be
> accurate but 
> > not useful.
> > > > 
> > > > How is that different from a normal presence
> expiration? 
> > One assumes
> > > > that if the presence state changes before I
> get around to 
> > getting the
> > > > data, I would get a new notify if I am still
> subscribed.
> > > 
> > > Perhaps it isn't different, but it depends on
> how you interpret the
> > > Expires header.
> > > 
> > > In a NOTIFY there is a difference between
> Expires and
> > > Subscription-Expires.
> > > Expires applies to the specific notification. 
> > > 
> > > If you interpret Expires for something like
> MESSAGE, it 
> > presumably says
> > > something about how long the message content is
> meaningful. This is
> > > probably independent of any other messages that
> you might 
> > subsequently
> > > receive. So if I send you a message asking if
> you want to 
> > go to lunch
> > > today, I can set the expiration to the time I
> intend to 
> > leave for lunch.
> > > I can then send you other unrelated messages
> with different 
> > expirations,
> > > but they leave my lunch invitation unaffected.
> > > 
> > > With the presence notification however, when
> sending it I in general
> > > don't know how long it will be valid. Generally
> it will be 
> > valid until I
> > > send another one. I could include an Expires
> header with 
> > the same value
> > > as Subscription-Expires, and that would be
> correct if there are no
> > > further changes until expiration. But it will be
> rendered 
> > incorrect as
> > > soon as I send out a revised notification.
> > > 
> > > So at the least, expires values for
> notifications need to 
> > be taken with
> > > a grain of salt. Old ones need to be discarded
> when new ones are
> > > received, even if the old one has not yet
> expired.
> > > 
> > > 	Paul
> > 
> > I understand that. Expires in no way guarantees
> that the 
> > presence state
> > will not change before expiration. It does,
> however, give you 
> > a maximum
> > time for the presence state, that is, you should
> assume it is stale
> > after expiration, unless you have received other
> information to the
> > contrary.
> > 
> > That seems to map very closely to the model for
> the expiration of URLs
> > in a NOTIFY, if you say that you have a reasonable
> expectation of the
> > URL being good if it has not expired and you have
> not received a new
> > NOTIFY. The error scenario is when you miss a
> NOTIFY, but we have that
> > exact scenario when we deliver full presence docs
> in the NOTIFY.
> > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> >
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 


=====
--
Sean Olson 
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

From pkyzivat@cisco.com  Mon Dec 17 12:47:24 2001
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 MAA01875
	for ; Mon, 17 Dec 2001 12:47:24 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBHHl1425882;
	Mon, 17 Dec 2001 12:47:01 -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 AAG46482 (AUTH pkyzivat);
	Mon, 17 Dec 2001 12:48:16 -0500 (EST)
Message-ID: <3C1E2E9C.AB1CDCCC@cisco.com>
Date: Mon, 17 Dec 2001 12:42:52 -0500
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 
CC: Ben Campbell ,
        Sean Olson , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
References: <933FADF5E673D411B8A30002A5608A0E01334421@zrc2c012.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 904
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: 

This is ok with me.

	Paul

> Brian Stucker wrote:
> 
> I agree with Ben. Although you raise good points Paul.
> 
> Can we all agree to:
> 
> 1. The URL is good for the interval expressed in the EXPIRES header of
> the notification which contained the presence document URL, or the
> Subscription-Expires (soon to be Subscription-State), whichever is
> shorter.
> 
> 2. If another notification is received during the interval identified
> in (1), then the previous URL should be considered stale. The most
> recent notification always takes precedence.
> 
> 3. If the subscription ends, any presence URLs associated with that
> subscription should be considered stale.
> 4. If a notify is received with an EXPIRES set to zero, the URL is
> considered dead-on-arrival.
> 5. If a notify is received without an EXPIRES header, the URL is good
> for the duration of the subscription.
> 
> Cheers,
> 
> Brian

From Henry.Sinnreich@wcom.com  Mon Dec 17 16:35:27 2001
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02585
	for ; Mon, 17 Dec 2001 16:35:26 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261)
 id <0GOI00G01BXUFT@firewall.wcom.com> for simple@mailman.dynamicsoft.com; Mon,
 17 Dec 2001 21:34:42 +0000 (GMT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.wcom.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GOI00G0BBXUFK@firewall.wcom.com>; Mon,
 17 Dec 2001 21:34:42 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GOI00L01BXLEC@pmismtp01.wcomnet.com>;
 Mon, 17 Dec 2001 21:34:41 +0000 (GMT)
Received: from hsinnreich2 ([166.42.41.120])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GOI00L3CBXB32@pmismtp01.wcomnet.com>; Mon,
 17 Dec 2001 21:34:28 +0000 (GMT)
Date: Mon, 17 Dec 2001 15:34:16 -0600
From: Henry Sinnreich 
To: Jonathan Rosenberg DynamicSoft ,
        simple@mailman.dynamicsoft.com, jon.peterson@neustar.com,
        rsparks@dynamicsoft.com, "'Allison Mankin'" 
Message-id: <000201c18742$96f16bc0$6801a8c0@hsinnreich2>
Organization: WorldCom, Inc.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook, Build 10.0.3311
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Length: 516
Subject: [Simple] SIPPING discussion at the 52 IETF
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: 

Would like to correct what I said at the discussion about the
architecture presentation by Allison Mankin and Jon Peterson and also
about the question on the draft "SIP Instant Message Sessions"
:

Both the architecture presentation and the draft of SIP session mode go
very well together and make a lot of sense. The session mode for SIP IM
actually meets a significant market pull.

Thanks, Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA
 



From henrik.gustafsson@hotsip.com  Mon Dec 17 16:47:59 2001
Received: from hotsip.com ([212.28.214.249])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02638
	for ; Mon, 17 Dec 2001 16:47:58 -0500 (EST)
Received: from ughugh2 ([212.28.214.198]) by hotsip.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 17 Dec 2001 22:47:22 +0100
From: "Henrik Gustafsson" 
To: "Robert Sparks" ,
        
Subject: RE: [Simple] Message Delivery Notification
Date: Mon, 17 Dec 2001 22:45:45 +0100
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.4807.1700
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E8B9@DYN-TX-EXCH-001.dynamicsoft.com>
Importance: Normal
X-OriginalArrivalTime: 17 Dec 2001 21:47:22.0686 (UTC) FILETIME=[68AE3DE0:01C18744]
Content-Length: 4506
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: 

I believe this is part of the core. If we decide to not 
allow the contact header, the pager model MESSAGE cannot 
work as an implicit subscription. 

And getting notifications about what is happening on 
the other side of the dialog are something today's im 
users expects from an im service. Of course, that could 
be done by sending INFO messages in the message session 
invitation dialog. But the requirements for these 
notifications will be the same as for the messages. If 
we choose IMTP, should the notifications be sent over 
IMTP? Maybe the notifications are MESSAGE requests with 
a special content type. Anyway I believe it is a relevant 
requirement on IMTP. Personally I prefer the 
Allow-Events - Notify model, that gives more control.

/Henrik

> -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: Monday, December 17, 2001 17:33
> To: 'Henrik Gustafsson'; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Message Delivery Notification
> 
> 
> We need to be careful not to break more new ground until
> our core effort is complete. We should make sure
> we aren't overly limiting MESSAGE's future extensibility.
> We should think about the gateway to non-instant systems 
> problem you bring up to make sure we aren't boxing ourselves
> in, but I don't think we should take on solving it as a group
> until we're done with the basic presence and messaging efforts 
> (at least).
> 
> RjS
> 
> > -----Original Message-----
> > From: Henrik Gustafsson [mailto:henrik.gustafsson@hotsip.com]
> > Sent: Monday, December 17, 2001 8:10 AM
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] Message Delivery Notification
> > 
> > 
> > The paging model for messages will probably often
> > be used to gateway to SMS in the mobile network.
> > Delivery notification is a very useful service
> > in such a scenario. I would like a similar support
> > in the SIMPLE system. This proposal is not that
> > very thought through and I can see a number of
> > problems already with this proposal but the
> > initial requirement is still valid.
> > 
> > Message Progress Notification:
> > ------------------------------
> > If a MESSAGE is sent with a contact and an
> > allow-events header:
> > 
> >   MESSAGE sip:hegu@company.com SIP/2.0
> >   ...
> >   Allow-Events: messageprogress
> >   Contact: ;methods="NOTIFY"
> >   ...
> > 
> > That could be an implicit subscription and later
> > on different notifications could be sent.
> > 
> >   NOTIFY sip:hegu@host SIP/2.0
> >   ...
> >   Event: messageprogress
> >   ...
> > 
> >   The mobile phone did not accept the message.
> >   Stored in server.
> > 
> > Later a notification with  "Message delivered.",
> > "Message read." or "Messages transformed to SMS.
> > The Message (400 characters) was split into 3
> > separate messages." could be sent.
> > 
> > This is controversial since the message draft clearly
> > states that contacts are not allowed in a MESSAGE.
> > However, this contact will not be used to establish a
> > message session.
> > 
> > The 200-response is used to end the MESSAGE SIP
> > transaction. If the receiving element supports
> > the message progress event package it MAY send
> > a notification. But you cannot depend on it.
> > 
> > Open Issues:
> > ------------
> > Is it ok to add a contact to the MESSAGE? Could an
> > implicit subscription be used this way? How do you
> > know that the contact is still valid when the event
> > occurs? When does the "subscription" expire? Could
> > different elements in the message path generate
> > notifications? Would that be different to-tags and
> > would that look like notifies after a forked
> > subscribe?
> > 
> > This message progress notifications could also be
> > relevant in a message session ... but considering
> > non-SIP message transport like IMTP I don't dare
> > to start that discussion. But today are well-known
> > IM user agents sending events like "the other party
> > is writing on a reply" within the message session.
> > 
> > I have recently started writing a draft on this.
> > I would really like some input, especially how this
> > could be done over IMTP or should an explicit
> > subscription be used? In the paging model I believe
> > an implicit subscription is the way to go.
> > 
> > /Henrik
> > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 

From lachlan.brazier@siemens.at  Tue Dec 18 04:03:43 2001
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 EAA04722
	for ; Tue, 18 Dec 2001 04:03:42 -0500 (EST)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id fBI93Cp21068;
	Tue, 18 Dec 2001 10:03:12 +0100
Received: (from smap@localhost)
	by scesie13.sie.siemens.at (8.9.3/8.9.3) id KAA29384;
	Tue, 18 Dec 2001 10:02:22 +0100 (MET)
Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta)
	id xmab27077; Tue, 18 Dec 01 10:00:53 +0100
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Dec 2001 10:00:18 +0100
Message-ID: 
From: Brazier Lachlan 
To: "'Brian Stucker'" ,
        Ben Campbell
	 ,
        Paul Kyzivat 
Cc: Sean Olson , simple@mailman.dynamicsoft.com
Subject: AW: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Tue, 18 Dec 2001 10:00:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1128
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA04722
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: 

Sounds good.
 
Lachlan

-----Ursprüngliche Nachricht-----
Von: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Gesendet am: Montag, 17. Dezember 2001 17:52
An: Ben Campbell; Paul Kyzivat
Cc: Sean Olson; simple@mailman.dynamicsoft.com
Betreff: RE: [Simple] Duration of URIs in application/uri-list for Presenc e


I agree with Ben. Although you raise good points Paul. 

Can we all agree to: 

1. The URL is good for the interval expressed in the EXPIRES header of the
notification which contained the presence document URL, or the
Subscription-Expires (soon to be Subscription-State), whichever is shorter.

2. If another notification is received during the interval identified in
(1), then the previous URL should be considered stale. The most recent
notification always takes precedence.

3. If the subscription ends, any presence URLs associated with that
subscription should be considered stale. 
4. If a notify is received with an EXPIRES set to zero, the URL is
considered dead-on-arrival. 
5. If a notify is received without an EXPIRES header, the URL is good for
the duration of the subscription. 

Cheers, 

Brian 


From aki.niemi@nokia.com  Tue Dec 18 04:44:54 2001
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 EAA04862
	for ; Tue, 18 Dec 2001 04:44:53 -0500 (EST)
From: aki.niemi@nokia.com
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 fBI9gCc25355
	for ; Tue, 18 Dec 2001 11:42:12 +0200 (EET)
Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 18 Dec 2001 11:44:24 +0200
Received: by esebh24nok with Internet Mail Service (5.5.2652.78)
	id ; Tue, 18 Dec 2001 11:44:24 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC7F@esebe013.NOE.Nokia.com>
To: bstucker@nortelnetworks.com, bcampbell@dynamicsoft.com, pkyzivat@cisco.com
Cc: seancolson@yahoo.com, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Tue, 18 Dec 2001 11:44:11 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1114
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: 

Hi All,

> I agree with Ben. Although you raise good points Paul. 
> Can we all agree to: 
> 1. The URL is good for the interval expressed in the EXPIRES 
> header of the notification which contained the presence 
> document URL, or the Subscription-Expires (soon to be 
> Subscription-State), whichever is shorter.

Overall, I like the sound of this proposal. However, a distinct linking like
this between the Subscription-Expires and Expires assumes that subscriptions
always establish a session. This assumption makes a fetch of event state
impossible using the URL mechanism.

> 2. If another notification is received during the interval 
> identified in (1), then the previous URL should be considered 
> stale. The most recent notification always takes precedence.
> 3. If the subscription ends, any presence URLs associated 
> with that subscription should be considered stale. 
> 4. If a notify is received with an EXPIRES set to zero, the 
> URL is considered dead-on-arrival. 
> 5. If a notify is received without an EXPIRES header, the URL 
> is good for the duration of the subscription. 

Cheers,
Aki

From seancolson@yahoo.com  Tue Dec 18 09:39:52 2001
Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA05736
	for ; Tue, 18 Dec 2001 09:39:52 -0500 (EST)
Message-ID: <20011218143922.1269.qmail@web11602.mail.yahoo.com>
Received: from [216.51.103.234] by web11602.mail.yahoo.com via HTTP; Tue, 18 Dec 2001 06:39:22 PST
Date: Tue, 18 Dec 2001 06:39:22 -0800 (PST)
From: Sean Olson 
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc  e
To: aki.niemi@nokia.com, bstucker@nortelnetworks.com,
        bcampbell@dynamicsoft.com, pkyzivat@cisco.com
Cc: seancolson@yahoo.com, simple@mailman.dynamicsoft.com
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC7F@esebe013.NOE.Nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 630
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: 

> Overall, I like the sound of this proposal. However,
> a distinct linking like
> this between the Subscription-Expires and Expires
> assumes that subscriptions
> always establish a session. 

For presence at least, they do.

>This assumption makes a
> fetch of event state
> impossible using the URL mechanism.

Why?

/sean


=====
--
Sean Olson 
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

From bstucker@americasm01.nt.com  Tue Dec 18 10:36:40 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05932
	for ; Tue, 18 Dec 2001 10:36:39 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBIFVZF20721;
	Tue, 18 Dec 2001 09:31:36 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Dec 2001 09:30:10 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E0139AB67@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Jonathan Rosenberg , aki.niemi@nokia.com
Cc: bcampbell@dynamicsoft.com, pkyzivat@cisco.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Tue, 18 Dec 2001 09:30:03 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C187D8.DD3AABA0"
Content-Length: 5894
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: 

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_01C187D8.DD3AABA0
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> 
> aki.niemi@nokia.com wrote:
> 
> > Hi All,
> > 
> > 
> >>I agree with Ben. Although you raise good points Paul. 
> >>Can we all agree to: 
> >>1. The URL is good for the interval expressed in the EXPIRES 
> >>header of the notification which contained the presence 
> >>document URL, or the Subscription-Expires (soon to be 
> >>Subscription-State), whichever is shorter.
> >>
> > 
> > Overall, I like the sound of this proposal. However, a 
> distinct linking
> > like
> > this between the Subscription-Expires and Expires assumes that
> > subscriptions
> > always establish a session. This assumption makes a fetch 
> of event state
> > impossible using the URL mechanism.
> 
> 
> Good point.
> 
> Why don't we simplify this, then, and state that the URL is valid for 
> duration in the Expires, if present, otherwise, the duration of the 
> subscription, and that the next NOTIFY overrides the previous 
> URL. This 
> way, if you want the URL validity to be less than the subscription 
> duration, you can do that (Expires < Subscription-Expires), 
> equal to it 
> (no Expires) or greater than it (Expires > Subscription-Expires). We 
> also say that in absense of reasons to do so otherwise, the 
> URL SHOULD 
> be valid for the duration of the subscription, and for 
> fetches, for some 
> reasonable interval, say 2 min.
> 
> That is, we specify semantics that enable any policy, and state a 
> recommended baseline policy.
> 
> -Jonathan R.
> 
> 

Johnathan, that's precisely what was proposed. I don't understand the logic
about the
session making it impossible to fetch a URL. Just because you no longer have
any state in SIP
doesn't mean you can't have state somewhere else. I'd prefer we steer away
from arbitrary timers.

Brian

------_=_NextPart_001_01C187D8.DD3AABA0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Duration of URIs in application/uri-list for Presenc e








> -----Original Message-----

> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

> 

> aki.niemi@nokia.com wrote:

> 

> > Hi All,

> > 

> > 

> >>I agree with Ben. Although you raise good points Paul. 

> >>Can we all agree to: 

> >>1. The URL is good for the interval expressed in the EXPIRES 

> >>header of the notification which contained the presence 

> >>document URL, or the Subscription-Expires (soon to be 

> >>Subscription-State), whichever is shorter.

> >>

> > 

> > Overall, I like the sound of this proposal. However, a 

> distinct linking

> > like

> > this between the Subscription-Expires and Expires assumes that

> > subscriptions

> > always establish a session. This assumption makes a fetch 

> of event state

> > impossible using the URL mechanism.

> 

> 

> Good point.

> 

> Why don't we simplify this, then, and state that the URL is valid for 

> duration in the Expires, if present, otherwise, the duration of the 

> subscription, and that the next NOTIFY overrides the previous 

> URL. This 

> way, if you want the URL validity to be less than the subscription 

> duration, you can do that (Expires < Subscription-Expires), 

> equal to it 

> (no Expires) or greater than it (Expires > Subscription-Expires). We 

> also say that in absense of reasons to do so otherwise, the 

> URL SHOULD 

> be valid for the duration of the subscription, and for 

> fetches, for some 

> reasonable interval, say 2 min.

> 

> That is, we specify semantics that enable any policy, and state a 

> recommended baseline policy.

> 

> -Jonathan R.

> 

> 




Johnathan, that's precisely what was proposed. I don't understand the logic about the

session making it impossible to fetch a URL. Just because you no longer have any state in SIP

doesn't mean you can't have state somewhere else. I'd prefer we steer away from arbitrary timers.




Brian





------_=_NextPart_001_01C187D8.DD3AABA0--

From bstucker@americasm01.nt.com  Tue Dec 18 10:41:16 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05968
	for ; Tue, 18 Dec 2001 10:41:16 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBIFdrF22636;
	Tue, 18 Dec 2001 09:39:53 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Dec 2001 09:38:28 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E0139ABA2@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: aki.niemi@nokia.com, bcampbell@dynamicsoft.com, pkyzivat@cisco.com
Cc: seancolson@yahoo.com, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Tue, 18 Dec 2001 09:38:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C187DA.053404C0"
Content-Length: 3992
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: 

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_01C187DA.053404C0
Content-Type: text/plain;
	charset="iso-8859-1"



> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> 
> 
> Hi All,
> 
> > I agree with Ben. Although you raise good points Paul. 
> > Can we all agree to: 
> > 1. The URL is good for the interval expressed in the EXPIRES 
> > header of the notification which contained the presence 
> > document URL, or the Subscription-Expires (soon to be 
> > Subscription-State), whichever is shorter.
> 
> Overall, I like the sound of this proposal. However, a 
> distinct linking like
> this between the Subscription-Expires and Expires assumes 
> that subscriptions
> always establish a session. This assumption makes a fetch of 
> event state
> impossible using the URL mechanism.
> 
> 
> Cheers,
> Aki
> 

Why? All the expires is telling us to do with the URL is to direct us as to
how long to cache the URL for (if it's to be cached at all). If you did a
fetch, you could get a NOTIFY back with "subscription-state: terminated 0"
and an "expires: 90" (or whatever). The contents of the NOTIFY would be good
for 90 seconds, the subscription has terminated immediately, here's your
URL.

Am I missing something?

Brian Stucker

------_=_NextPart_001_01C187DA.053404C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Duration of URIs in application/uri-list for =
Presenc e








> -----Original Message-----

> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]

> 

> 

> Hi All,

> 

> > I agree with Ben. Although you raise good =
points Paul. 

> > Can we all agree to: 

> > 1. The URL is good for the interval =
expressed in the EXPIRES 

> > header of the notification which contained =
the presence 

> > document URL, or the Subscription-Expires =
(soon to be 

> > Subscription-State), whichever is =
shorter.

> 

> Overall, I like the sound of this proposal. =
However, a 

> distinct linking like

> this between the Subscription-Expires and =
Expires assumes 

> that subscriptions

> always establish a session. This assumption =
makes a fetch of 

> event state

> impossible using the URL mechanism.

> 

> 

> Cheers,

> Aki

> 




Why? All the expires is telling us to do with the URL =
is to direct us as to how long to cache the URL for (if it's to be =
cached at all). If you did a fetch, you could get a NOTIFY back with =
"subscription-state: terminated 0" and an "expires: =
90" (or whatever). The contents of the NOTIFY would be good for 90 =
seconds, the subscription has terminated immediately, here's your =
URL.



Am I missing something?




Brian Stucker





------_=_NextPart_001_01C187DA.053404C0--

From pkyzivat@cisco.com  Tue Dec 18 11:44:30 2001
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 LAA06168
	for ; Tue, 18 Dec 2001 11:44:30 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBIGi4823484;
	Tue, 18 Dec 2001 11:44: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 AAH01361 (AUTH pkyzivat);
	Tue, 18 Dec 2001 11:45:20 -0500 (EST)
Message-ID: <3C1F7158.725CEB64@cisco.com>
Date: Tue, 18 Dec 2001 11:39:52 -0500
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: Brian Stucker , aki.niemi@nokia.com,
        bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presenc	 e
References: <933FADF5E673D411B8A30002A5608A0E0139ABA2@zrc2c012.us.nortel.com> <3C1F6B8E.5010000@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1122
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: 


Jonathan Rosenberg wrote:
> 
> The original proposal was that the URL was valid until either the
> Expires duration ends, or the subscription terminates, whichever happens
> first. Since fetches are nothing more than subscriptions with zero
> duration, this would mean that the URL would be invalidated immediately.

How did you reach the conclusion stated in the last sentence above?

I think one valid implementation might be that a fetch of the URL
returns the same thing that a new subscription with a zero duration
would return. But if so, I don't think that should affect the status of
the original subscription that returned the URL, or the validity of the
URL itself.

Another valid (though perhaps suboptimal) implementation might be for
the notification that returns a URL to actually format the notification,
store it as a file, and return a URL for that file. The file might
remain indefinitely, regardless of what subsequently happens to the
subscription or the state of the presentity subscribed to.

The rules ought to permit both sorts of implementations, and behave in a
comparable way for both.

	Paul

From bstucker@americasm01.nt.com  Tue Dec 18 15:00:18 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06808
	for ; Tue, 18 Dec 2001 15:00:18 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBIJx3F22026;
	Tue, 18 Dec 2001 13:59:04 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Dec 2001 13:57:38 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E0139B069@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Paul Kyzivat ,
        Jonathan Rosenberg
	 ,
        adam.roach@ericsson.com
Cc: aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
		 e
Date: Tue, 18 Dec 2001 13:57:28 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C187FE.389E0E90"
Content-Length: 9409
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: 

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_01C187FE.389E0E90
Content-Type: text/plain;
	charset="iso-8859-1"

The problem is that, the wording that was given earlier meant that a fetch
was not possible because the URL would only last until the subscription
expired.

Ahh.. Now I see it. Ok. Yes, there is a problem Aki.

So the logic needs to be revised, which is what Jonathan was talking about.
Now
I understand. It seems that (nearly) everyone was intent on not specifying a

standard interval for the URL to be good for. So, with that in mind, how
about:

1. The URL is good for the interval expressed in the EXPIRES 
header of the notification which contained the presence 
document URL, or the Subscription-Expires (soon to be 
Subscription-State), whichever is shorter.

2. If another notification is received during the interval 
identified in (1), then the previous URL should be considered 
stale. The most recent notification always takes precedence.

3. If a persistient subscription (not a fetch) ends, any 
presence URLs associated with that subscription should be considered stale. 

4. If a notify is received with an EXPIRES set to zero, the 
URL is considered dead-on-arrival. 

5. If a notify is received without an EXPIRES header, the URL 
is good for the duration of the subscription. 

6. If a notify is received due to a subscription fetch, the URL
is good for the interval expressed in the EXPIRES header of the
notification which contained the presence document URL.

This would require that the sip-events draft change the normative language
in Section 4.3.5 of the -01 draft.

Adam?

Cheers,

Brian Stucker


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, December 18, 2001 10:40 AM
> To: Jonathan Rosenberg
> Cc: Stucker, Brian [NGB:B635:EXCH]; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presenc e
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > The original proposal was that the URL was valid until either the
> > Expires duration ends, or the subscription terminates, 
> whichever happens
> > first. Since fetches are nothing more than subscriptions with zero
> > duration, this would mean that the URL would be invalidated 
> immediately.
> 
> How did you reach the conclusion stated in the last sentence above?
> 
> I think one valid implementation might be that a fetch of the URL
> returns the same thing that a new subscription with a zero duration
> would return. But if so, I don't think that should affect the 
> status of
> the original subscription that returned the URL, or the 
> validity of the
> URL itself.
> 
> Another valid (though perhaps suboptimal) implementation might be for
> the notification that returns a URL to actually format the 
> notification,
> store it as a file, and return a URL for that file. The file might
> remain indefinitely, regardless of what subsequently happens to the
> subscription or the state of the presentity subscribed to.
> 
> The rules ought to permit both sorts of implementations, and 
> behave in a
> comparable way for both.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

------_=_NextPart_001_01C187FE.389E0E90
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Duration of URIs in application/uri-list for Presenc	 e




The problem is that, the wording that was given earlier meant that a fetch

was not possible because the URL would only last until the subscription expired.




Ahh.. Now I see it. Ok. Yes, there is a problem Aki.




So the logic needs to be revised, which is what Jonathan was talking about. Now

I understand. It seems that (nearly) everyone was intent on not specifying a 

standard interval for the URL to be good for. So, with that in mind, how about:




1. The URL is good for the interval expressed in the EXPIRES 

header of the notification which contained the presence 

document URL, or the Subscription-Expires (soon to be 

Subscription-State), whichever is shorter.




2. If another notification is received during the interval 

identified in (1), then the previous URL should be considered 

stale. The most recent notification always takes precedence.




3. If a persistient subscription (not a fetch) ends, any 

presence URLs associated with that subscription should be considered stale. 




4. If a notify is received with an EXPIRES set to zero, the 

URL is considered dead-on-arrival. 




5. If a notify is received without an EXPIRES header, the URL 

is good for the duration of the subscription. 




6. If a notify is received due to a subscription fetch, the URL

is good for the interval expressed in the EXPIRES header of the

notification which contained the presence document URL.




This would require that the sip-events draft change the normative language

in Section 4.3.5 of the -01 draft.




Adam?




Cheers,




Brian Stucker






> -----Original Message-----

> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]

> Sent: Tuesday, December 18, 2001 10:40 AM

> To: Jonathan Rosenberg

> Cc: Stucker, Brian [NGB:B635:EXCH]; aki.niemi@nokia.com;

> bcampbell@dynamicsoft.com; seancolson@yahoo.com;

> simple@mailman.dynamicsoft.com

> Subject: Re: [Simple] Duration of URIs in application/uri-list for

> Presenc e

> 

> 

> 

> 

> Jonathan Rosenberg wrote:

> > 

> > The original proposal was that the URL was valid until either the

> > Expires duration ends, or the subscription terminates, 

> whichever happens

> > first. Since fetches are nothing more than subscriptions with zero

> > duration, this would mean that the URL would be invalidated 

> immediately.

> 

> How did you reach the conclusion stated in the last sentence above?

> 

> I think one valid implementation might be that a fetch of the URL

> returns the same thing that a new subscription with a zero duration

> would return. But if so, I don't think that should affect the 

> status of

> the original subscription that returned the URL, or the 

> validity of the

> URL itself.

> 

> Another valid (though perhaps suboptimal) implementation might be for

> the notification that returns a URL to actually format the 

> notification,

> store it as a file, and return a URL for that file. The file might

> remain indefinitely, regardless of what subsequently happens to the

> subscription or the state of the presentity subscribed to.

> 

> The rules ought to permit both sorts of implementations, and 

> behave in a

> comparable way for both.

> 

>       Paul

> _______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple

> 





------_=_NextPart_001_01C187FE.389E0E90--

From seancolson@yahoo.com  Tue Dec 18 15:29:45 2001
Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA06911
	for ; Tue, 18 Dec 2001 15:29:45 -0500 (EST)
Message-ID: <20011218202914.79284.qmail@web11601.mail.yahoo.com>
Received: from [208.237.135.12] by web11601.mail.yahoo.com via HTTP; Tue, 18 Dec 2001 12:29:14 PST
Date: Tue, 18 Dec 2001 12:29:14 -0800 (PST)
From: Sean Olson 
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc   e
To: Brian Stucker ,
        Paul Kyzivat ,
        Jonathan Rosenberg , adam.roach@ericsson.com
Cc: aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
In-Reply-To: <933FADF5E673D411B8A30002A5608A0E0139B069@zrc2c012.us.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1817
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: 

> 1. The URL is good for the interval expressed in the
> EXPIRES 
> header of the notification which contained the
> presence 
> document URL, or the Subscription-Expires (soon to
> be 
> Subscription-State), whichever is shorter.
> 
> 2. If another notification is received during the
> interval 
> identified in (1), then the previous URL should be
> considered 
> stale. The most recent notification always takes
> precedence.

I would like this to be a "SHOULD" strength
condition and not a "MUST". 

> 
> 3. If a persistient subscription (not a fetch) ends,
> any 
> presence URLs associated with that subscription
> should be considered stale. 

There is no need for a special case here. The
text in bullet 1 covers both a "fetch" as well
as a long running subscription.

> 
> 4. If a notify is received with an EXPIRES set to
> zero, the 
> URL is considered dead-on-arrival. 

This is an extremely odd case. Wouldn't an 
empty body be more appropriate. Can someone
give a real world example of when this would
be used?

> 
> 5. If a notify is received without an EXPIRES
> header, the URL 
> is good for the duration of the subscription. 
> 
> 6. If a notify is received due to a subscription
> fetch, the URL
> is good for the interval expressed in the EXPIRES
> header of the
> notification which contained the presence document
> URL.
> 
> This would require that the sip-events draft change
> the normative language
> in Section 4.3.5 of the -01 draft.
> 
> Adam?
> 
> Cheers, 
> Brian Stucker

/sean


=====
--
Sean Olson 
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

From pkyzivat@cisco.com  Tue Dec 18 16:56:40 2001
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 QAA07183
	for ; Tue, 18 Dec 2001 16:56:40 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBILuHj18425;
	Tue, 18 Dec 2001 16:56:17 -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 AAH04289 (AUTH pkyzivat);
	Tue, 18 Dec 2001 16:57:33 -0500 (EST)
Message-ID: <3C1FBA85.D150C472@cisco.com>
Date: Tue, 18 Dec 2001 16:52:05 -0500
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 
CC: Jonathan Rosenberg , adam.roach@ericsson.com,
        aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
References: <933FADF5E673D411B8A30002A5608A0E0139B069@zrc2c012.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2122
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: 

Comments below.

> Brian Stucker wrote:
> 
> The problem is that, the wording that was given earlier meant that a
> fetch
> was not possible because the URL would only last until the
> subscription expired.
> 
> Ahh.. Now I see it. Ok. Yes, there is a problem Aki.
> 
> So the logic needs to be revised, which is what Jonathan was talking
> about. Now
> I understand. It seems that (nearly) everyone was intent on not
> specifying a
> standard interval for the URL to be good for. So, with that in mind,
> how about:
> 
> 1. The URL is good for the interval expressed in the EXPIRES
> header of the notification which contained the presence
> document URL, or the Subscription-Expires (soon to be
> Subscription-State), whichever is shorter.

I think this is wrong. How about:

  1. If the notification which contained the presence document URL
  also contained an Expires header, the URL is good for the interval
  expressed in that header.

This permits the document referenced by the URL to outlast
the subscription, if that is what the notifier desired.
The case where there is Subscription-Expires but not Expires
is covered by 5.

> 
> 2. If another notification is received during the interval
> identified in (1), then the previous URL should be considered
> stale. The most recent notification always takes precedence.
> 
> 3. If a persistient subscription (not a fetch) ends, any
> presence URLs associated with that subscription should be considered
> stale.
> 
> 4. If a notify is received with an EXPIRES set to zero, the
> URL is considered dead-on-arrival.

It would be stupid to do this. Since it is both stupid and a
special case of 1, no need to mention.

> 
> 5. If a notify is received without an EXPIRES header, the URL
> is good for the duration of the subscription.
> 
> 6. If a notify is received due to a subscription fetch, the URL
> is good for the interval expressed in the EXPIRES header of the
> notification which contained the presence document URL.

I don't understand this. What do you mean by a "subscription fetch"?
Does this say anything not covered by one of the other points?

	Paul

From bstucker@americasm01.nt.com  Tue Dec 18 18:28:07 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07480
	for ; Tue, 18 Dec 2001 18:28:07 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBINR0F06120;
	Tue, 18 Dec 2001 17:27:00 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Dec 2001 17:25:35 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E0139B3C3@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Paul Kyzivat 
Cc: Jonathan Rosenberg , adam.roach@ericsson.com,
        aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	e
Date: Tue, 18 Dec 2001 17:25:33 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1881B.4A848D60"
Content-Length: 11871
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: 

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_01C1881B.4A848D60
Content-Type: text/plain;
	charset="iso-8859-1"

The reason I mention the fetch is because in the sip-events draft, you can
have a NOTIFY with an expires of zero,
and no subscription-expires (the subscription-expires is only a SHOULD,
presumably to keep from deprecating implementations from the -00 draft).

So, if your client KNOWS that it just did a fetch, then the problem as has
been pointed out is that the NOTIFY could come back with no
subscription-expires header, an Expires header set to zero (to denote that
the subscription is over as there never was one), and with a presence URL
(because it's a fetch). In this case the client shouldn't treat the URL as
dead-on-arrival even though the NOTIFY looks just like a "stupid"
dead-on-arrival notify. I think this is what Aki was getting at, and it's a
good point.

Either we agree to a set interval, as Jonathan has suggested (which I'm fine
with), or we agree that when a URL is to be sent back in NOTIFY that was
sent because of a fetch operation, that there MUST be a
subscription-expires, and the expires header can't be zero. Otherwise, URLs
returned as part of a fetch operation where the optional
subscription-expires header isn't present would either be immediately stale
(as Aki pointed out), or would be valid for an undetermined amount of time
(which is what we're trying to avoid).

Regards,

Brian Stucker


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, December 18, 2001 3:52 PM
> To: Stucker, Brian [NGB:B635:EXCH]
> Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presence
> 
> 
> Comments below.
> 
> > Brian Stucker wrote:
> > 
> > The problem is that, the wording that was given earlier meant that a
> > fetch
> > was not possible because the URL would only last until the
> > subscription expired.
> > 
> > Ahh.. Now I see it. Ok. Yes, there is a problem Aki.
> > 
> > So the logic needs to be revised, which is what Jonathan was talking
> > about. Now
> > I understand. It seems that (nearly) everyone was intent on not
> > specifying a
> > standard interval for the URL to be good for. So, with that in mind,
> > how about:
> > 
> > 1. The URL is good for the interval expressed in the EXPIRES
> > header of the notification which contained the presence
> > document URL, or the Subscription-Expires (soon to be
> > Subscription-State), whichever is shorter.
> 
> I think this is wrong. How about:
> 
>   1. If the notification which contained the presence document URL
>   also contained an Expires header, the URL is good for the interval
>   expressed in that header.
> 
> This permits the document referenced by the URL to outlast
> the subscription, if that is what the notifier desired.
> The case where there is Subscription-Expires but not Expires
> is covered by 5.
> 
> > 
> > 2. If another notification is received during the interval
> > identified in (1), then the previous URL should be considered
> > stale. The most recent notification always takes precedence.
> > 
> > 3. If a persistient subscription (not a fetch) ends, any
> > presence URLs associated with that subscription should be considered
> > stale.
> > 
> > 4. If a notify is received with an EXPIRES set to zero, the
> > URL is considered dead-on-arrival.
> 
> It would be stupid to do this. Since it is both stupid and a
> special case of 1, no need to mention.
> 
> > 
> > 5. If a notify is received without an EXPIRES header, the URL
> > is good for the duration of the subscription.
> > 
> > 6. If a notify is received due to a subscription fetch, the URL
> > is good for the interval expressed in the EXPIRES header of the
> > notification which contained the presence document URL.
> 
> I don't understand this. What do you mean by a "subscription fetch"?
> Does this say anything not covered by one of the other points?
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

------_=_NextPart_001_01C1881B.4A848D60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Duration of URIs in application/uri-list for =
Presence




The reason I mention the fetch is because in the =
sip-events draft, you can have a NOTIFY with an expires of zero,

and no subscription-expires (the =
subscription-expires is only a SHOULD, presumably to keep from =
deprecating implementations from the -00 draft).



So, if your client KNOWS that it just did a fetch, =
then the problem as has been pointed out is that the NOTIFY could come =
back with no subscription-expires header, an Expires header set to zero =
(to denote that the subscription is over as there never was one), and =
with a presence URL (because it's a fetch). In this case the client =
shouldn't treat the URL as dead-on-arrival even though the NOTIFY looks =
just like a "stupid" dead-on-arrival notify. I think this is =
what Aki was getting at, and it's a good point.



Either we agree to a set interval, as Jonathan has =
suggested (which I'm fine with), or we agree that when a URL is to be =
sent back in NOTIFY that was sent because of a fetch operation, that =
there MUST be a subscription-expires, and the expires header can't be =
zero. Otherwise, URLs returned as part of a fetch operation where the =
optional subscription-expires header isn't present would either be =
immediately stale (as Aki pointed out), or would be valid for an =
undetermined amount of time (which is what we're trying to =
avoid).



Regards,




Brian Stucker






> -----Original Message-----

> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=


> Sent: Tuesday, December 18, 2001 3:52 PM

> To: Stucker, Brian [NGB:B635:EXCH]

> Cc: Jonathan Rosenberg; =
adam.roach@ericsson.com; aki.niemi@nokia.com;

> bcampbell@dynamicsoft.com; =
seancolson@yahoo.com;

> simple@mailman.dynamicsoft.com

> Subject: Re: [Simple] Duration of URIs in =
application/uri-list for

> Presence

> 

> 

> Comments below.

> 

> > Brian Stucker wrote:

> > 

> > The problem is that, the wording that was =
given earlier meant that a

> > fetch

> > was not possible because the URL would =
only last until the

> > subscription expired.

> > 

> > Ahh.. Now I see it. Ok. Yes, there is a =
problem Aki.

> > 

> > So the logic needs to be revised, which is =
what Jonathan was talking

> > about. Now

> > I understand. It seems that (nearly) =
everyone was intent on not

> > specifying a

> > standard interval for the URL to be good =
for. So, with that in mind,

> > how about:

> > 

> > 1. The URL is good for the interval =
expressed in the EXPIRES

> > header of the notification which contained =
the presence

> > document URL, or the Subscription-Expires =
(soon to be

> > Subscription-State), whichever is =
shorter.

> 

> I think this is wrong. How about:

> 

>   1. If the notification which =
contained the presence document URL

>   also contained an Expires header, =
the URL is good for the interval

>   expressed in that header.

> 

> This permits the document referenced by the URL =
to outlast

> the subscription, if that is what the notifier =
desired.

> The case where there is Subscription-Expires =
but not Expires

> is covered by 5.

> 

> > 

> > 2. If another notification is received =
during the interval

> > identified in (1), then the previous URL =
should be considered

> > stale. The most recent notification always =
takes precedence.

> > 

> > 3. If a persistient subscription (not a =
fetch) ends, any

> > presence URLs associated with that =
subscription should be considered

> > stale.

> > 

> > 4. If a notify is received with an EXPIRES =
set to zero, the

> > URL is considered dead-on-arrival.

> 

> It would be stupid to do this. Since it is both =
stupid and a

> special case of 1, no need to mention.

> 

> > 

> > 5. If a notify is received without an =
EXPIRES header, the URL

> > is good for the duration of the =
subscription.

> > 

> > 6. If a notify is received due to a =
subscription fetch, the URL

> > is good for the interval expressed in the =
EXPIRES header of the

> > notification which contained the presence =
document URL.

> 

> I don't understand this. What do you mean by a =
"subscription fetch"?

> Does this say anything not covered by one of =
the other points?

> 

>       Paul

> =
_______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple=


> 





------_=_NextPart_001_01C1881B.4A848D60--

From pkyzivat@cisco.com  Tue Dec 18 19:52:21 2001
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 TAA07751
	for ; Tue, 18 Dec 2001 19:52:21 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBJ0pwQ26083;
	Tue, 18 Dec 2001 19:51:59 -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 AAH05206 (AUTH pkyzivat);
	Tue, 18 Dec 2001 19:53:14 -0500 (EST)
Message-ID: <3C1FE3B1.DF8B4D91@cisco.com>
Date: Tue, 18 Dec 2001 19:47:45 -0500
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 
CC: Jonathan Rosenberg , adam.roach@ericsson.com,
        aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Duration of URIs in application/uri-list for Presence
References: <933FADF5E673D411B8A30002A5608A0E0139B3C3@zrc2c012.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5148
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: 

I'm sorry, but I am still not sure I understand what you mean about a
subscription fetch. Do you perhaps mean sending a SUBSCRIBE with an
Expires of zero to do a one-time retrieval of the presence document?

If so, I think this does present an ugly case. I think the presence
server must return a non-zero Expires value, or else the client can take
its chances with no guarantees. Note that this is new behavior because
there aren't any presence servers returning URI-LIST yet.

Of course the same problem exists to an extent even if you request the
presence document. But then at least you have the document to look at
even if it has expired. It doesn't have to do anything to be used. With
the URL, the server hosting the URL has to honor it before it is useful.

	Paul


> Brian Stucker wrote:
> 
> The reason I mention the fetch is because in the sip-events draft, you
> can have a NOTIFY with an expires of zero,
> and no subscription-expires (the subscription-expires is only a
> SHOULD, presumably to keep from deprecating implementations from the
> -00 draft).
> 
> So, if your client KNOWS that it just did a fetch, then the problem as
> has been pointed out is that the NOTIFY could come back with no
> subscription-expires header, an Expires header set to zero (to denote
> that the subscription is over as there never was one), and with a
> presence URL (because it's a fetch). In this case the client shouldn't
> treat the URL as dead-on-arrival even though the NOTIFY looks just
> like a "stupid" dead-on-arrival notify. I think this is what Aki was
> getting at, and it's a good point.
> 
> Either we agree to a set interval, as Jonathan has suggested (which
> I'm fine with), or we agree that when a URL is to be sent back in
> NOTIFY that was sent because of a fetch operation, that there MUST be
> a subscription-expires, and the expires header can't be zero.
> Otherwise, URLs returned as part of a fetch operation where the
> optional subscription-expires header isn't present would either be
> immediately stale (as Aki pointed out), or would be valid for an
> undetermined amount of time (which is what we're trying to avoid).
> 
> Regards,
> 
> Brian Stucker
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Tuesday, December 18, 2001 3:52 PM
> > To: Stucker, Brian [NGB:B635:EXCH]
> > Cc: Jonathan Rosenberg; adam.roach@ericsson.com;
> aki.niemi@nokia.com;
> > bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> > simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] Duration of URIs in application/uri-list for
> > Presence
> >
> >
> > Comments below.
> >
> > > Brian Stucker wrote:
> > >
> > > The problem is that, the wording that was given earlier meant that
> a
> > > fetch
> > > was not possible because the URL would only last until the
> > > subscription expired.
> > >
> > > Ahh.. Now I see it. Ok. Yes, there is a problem Aki.
> > >
> > > So the logic needs to be revised, which is what Jonathan was
> talking
> > > about. Now
> > > I understand. It seems that (nearly) everyone was intent on not
> > > specifying a
> > > standard interval for the URL to be good for. So, with that in
> mind,
> > > how about:
> > >
> > > 1. The URL is good for the interval expressed in the EXPIRES
> > > header of the notification which contained the presence
> > > document URL, or the Subscription-Expires (soon to be
> > > Subscription-State), whichever is shorter.
> >
> > I think this is wrong. How about:
> >
> >   1. If the notification which contained the presence document URL
> >   also contained an Expires header, the URL is good for the interval
> 
> >   expressed in that header.
> >
> > This permits the document referenced by the URL to outlast
> > the subscription, if that is what the notifier desired.
> > The case where there is Subscription-Expires but not Expires
> > is covered by 5.
> >
> > >
> > > 2. If another notification is received during the interval
> > > identified in (1), then the previous URL should be considered
> > > stale. The most recent notification always takes precedence.
> > >
> > > 3. If a persistient subscription (not a fetch) ends, any
> > > presence URLs associated with that subscription should be
> considered
> > > stale.
> > >
> > > 4. If a notify is received with an EXPIRES set to zero, the
> > > URL is considered dead-on-arrival.
> >
> > It would be stupid to do this. Since it is both stupid and a
> > special case of 1, no need to mention.
> >
> > >
> > > 5. If a notify is received without an EXPIRES header, the URL
> > > is good for the duration of the subscription.
> > >
> > > 6. If a notify is received due to a subscription fetch, the URL
> > > is good for the interval expressed in the EXPIRES header of the
> > > notification which contained the presence document URL.
> >
> > I don't understand this. What do you mean by a "subscription fetch"?
> 
> > Does this say anything not covered by one of the other points?
> >
> >       Paul
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >

From bstucker@americasm01.nt.com  Tue Dec 18 20:01:25 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07824
	for ; Tue, 18 Dec 2001 20:01:25 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBJ10WF14622;
	Tue, 18 Dec 2001 19:00:32 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 18 Dec 2001 18:59:07 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E0139B450@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Paul Kyzivat 
Cc: Jonathan Rosenberg , adam.roach@ericsson.com,
        aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	e
Date: Tue, 18 Dec 2001 18:58:59 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C18828.5788FF70"
Content-Length: 8722
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: 

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_01C18828.5788FF70
Content-Type: text/plain;
	charset="iso-8859-1"

I didn't understand it at first either, but yes, I am talking about the
expires of zero to do a one-time retrieval of the presence document.

You have a good point about the non-URL case. Jonathan, what's the current
behavior set
for that case? Wouldn't it follow the same pattern?

Brian


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, December 18, 2001 6:48 PM
> To: Stucker, Brian [NGB:B635:EXCH]
> Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Duration of URIs in application/uri-list for
> Presence
> 
> 
> I'm sorry, but I am still not sure I understand what you mean about a
> subscription fetch. Do you perhaps mean sending a SUBSCRIBE with an
> Expires of zero to do a one-time retrieval of the presence document?
> 
> If so, I think this does present an ugly case. I think the presence
> server must return a non-zero Expires value, or else the 
> client can take
> its chances with no guarantees. Note that this is new behavior because
> there aren't any presence servers returning URI-LIST yet.
> 
> Of course the same problem exists to an extent even if you request the
> presence document. But then at least you have the document to look at
> even if it has expired. It doesn't have to do anything to be 
> used. With
> the URL, the server hosting the URL has to honor it before it 
> is useful.
> 
> 	Paul
> 
> 
> > Brian Stucker wrote:
> > 
> > The reason I mention the fetch is because in the sip-events 
> draft, you
> > can have a NOTIFY with an expires of zero,
> > and no subscription-expires (the subscription-expires is only a
> > SHOULD, presumably to keep from deprecating implementations from the
> > -00 draft).
> > 
> > So, if your client KNOWS that it just did a fetch, then the 
> problem as
> > has been pointed out is that the NOTIFY could come back with no
> > subscription-expires header, an Expires header set to zero 
> (to denote
> > that the subscription is over as there never was one), and with a
> > presence URL (because it's a fetch). In this case the 
> client shouldn't
> > treat the URL as dead-on-arrival even though the NOTIFY looks just
> > like a "stupid" dead-on-arrival notify. I think this is what Aki was
> > getting at, and it's a good point.
> > 
> > Either we agree to a set interval, as Jonathan has suggested (which
> > I'm fine with), or we agree that when a URL is to be sent back in
> > NOTIFY that was sent because of a fetch operation, that 
> there MUST be
> > a subscription-expires, and the expires header can't be zero.
> > Otherwise, URLs returned as part of a fetch operation where the
> > optional subscription-expires header isn't present would either be
> > immediately stale (as Aki pointed out), or would be valid for an
> > undetermined amount of time (which is what we're trying to avoid).
> > 
> > Regards,
> > 
> > Brian Stucker

------_=_NextPart_001_01C18828.5788FF70
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Duration of URIs in application/uri-list for Presence




I didn't understand it at first either, but yes, I am talking about the

expires of zero to do a one-time retrieval of the presence document.




You have a good point about the non-URL case. Jonathan, what's the current behavior set

for that case? Wouldn't it follow the same pattern?




Brian






> -----Original Message-----

> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]

> Sent: Tuesday, December 18, 2001 6:48 PM

> To: Stucker, Brian [NGB:B635:EXCH]

> Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com;

> bcampbell@dynamicsoft.com; seancolson@yahoo.com;

> simple@mailman.dynamicsoft.com

> Subject: Re: [Simple] Duration of URIs in application/uri-list for

> Presence

> 

> 

> I'm sorry, but I am still not sure I understand what you mean about a

> subscription fetch. Do you perhaps mean sending a SUBSCRIBE with an

> Expires of zero to do a one-time retrieval of the presence document?

> 

> If so, I think this does present an ugly case. I think the presence

> server must return a non-zero Expires value, or else the 

> client can take

> its chances with no guarantees. Note that this is new behavior because

> there aren't any presence servers returning URI-LIST yet.

> 

> Of course the same problem exists to an extent even if you request the

> presence document. But then at least you have the document to look at

> even if it has expired. It doesn't have to do anything to be 

> used. With

> the URL, the server hosting the URL has to honor it before it 

> is useful.

> 

>       Paul

> 

> 

> > Brian Stucker wrote:

> > 

> > The reason I mention the fetch is because in the sip-events 

> draft, you

> > can have a NOTIFY with an expires of zero,

> > and no subscription-expires (the subscription-expires is only a

> > SHOULD, presumably to keep from deprecating implementations from the

> > -00 draft).

> > 

> > So, if your client KNOWS that it just did a fetch, then the 

> problem as

> > has been pointed out is that the NOTIFY could come back with no

> > subscription-expires header, an Expires header set to zero 

> (to denote

> > that the subscription is over as there never was one), and with a

> > presence URL (because it's a fetch). In this case the 

> client shouldn't

> > treat the URL as dead-on-arrival even though the NOTIFY looks just

> > like a "stupid" dead-on-arrival notify. I think this is what Aki was

> > getting at, and it's a good point.

> > 

> > Either we agree to a set interval, as Jonathan has suggested (which

> > I'm fine with), or we agree that when a URL is to be sent back in

> > NOTIFY that was sent because of a fetch operation, that 

> there MUST be

> > a subscription-expires, and the expires header can't be zero.

> > Otherwise, URLs returned as part of a fetch operation where the

> > optional subscription-expires header isn't present would either be

> > immediately stale (as Aki pointed out), or would be valid for an

> > undetermined amount of time (which is what we're trying to avoid).

> > 

> > Regards,

> > 

> > Brian Stucker





------_=_NextPart_001_01C18828.5788FF70--

From seancolson@yahoo.com  Wed Dec 19 09:48:11 2001
Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA10290
	for ; Wed, 19 Dec 2001 09:48:10 -0500 (EST)
Message-ID: <20011219144740.3875.qmail@web11604.mail.yahoo.com>
Received: from [208.237.135.21] by web11604.mail.yahoo.com via HTTP; Wed, 19 Dec 2001 06:47:40 PST
Date: Wed, 19 Dec 2001 06:47:40 -0800 (PST)
From: Sean Olson 
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc e
To: Brian Stucker ,
        Paul Kyzivat 
Cc: Jonathan Rosenberg , adam.roach@ericsson.com,
        aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
In-Reply-To: <933FADF5E673D411B8A30002A5608A0E0139B3C3@zrc2c012.us.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 5227
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: 

I would argue that if the server wants to return
a list of URLs and if those URLs should be
valid for a duration longer than zero seconds,
then the Expire: header should be non-zero.
A zero value for the expires parameter of the
Subscription-State: header could be used to
indicate that this is a "fetch" with no 
actual subscription session. With this in mind,
there is no reason to define any arbitrary interval.

/sean

--- Brian Stucker  wrote:
> The reason I mention the fetch is because in the
> sip-events draft, you can
> have a NOTIFY with an expires of zero,
> and no subscription-expires (the
> subscription-expires is only a SHOULD,
> presumably to keep from deprecating implementations
> from the -00 draft).
> 
> So, if your client KNOWS that it just did a fetch,
> then the problem as has
> been pointed out is that the NOTIFY could come back
> with no
> subscription-expires header, an Expires header set
> to zero (to denote that
> the subscription is over as there never was one),
> and with a presence URL
> (because it's a fetch). In this case the client
> shouldn't treat the URL as
> dead-on-arrival even though the NOTIFY looks just
> like a "stupid"
> dead-on-arrival notify. I think this is what Aki was
> getting at, and it's a
> good point.
> 
> Either we agree to a set interval, as Jonathan has
> suggested (which I'm fine
> with), or we agree that when a URL is to be sent
> back in NOTIFY that was
> sent because of a fetch operation, that there MUST
> be a
> subscription-expires, and the expires header can't
> be zero. Otherwise, URLs
> returned as part of a fetch operation where the
> optional
> subscription-expires header isn't present would
> either be immediately stale
> (as Aki pointed out), or would be valid for an
> undetermined amount of time
> (which is what we're trying to avoid).
> 
> Regards,
> 
> Brian Stucker
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Tuesday, December 18, 2001 3:52 PM
> > To: Stucker, Brian [NGB:B635:EXCH]
> > Cc: Jonathan Rosenberg; adam.roach@ericsson.com;
> aki.niemi@nokia.com;
> > bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> > simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] Duration of URIs in
> application/uri-list for
> > Presence
> > 
> > 
> > Comments below.
> > 
> > > Brian Stucker wrote:
> > > 
> > > The problem is that, the wording that was given
> earlier meant that a
> > > fetch
> > > was not possible because the URL would only last
> until the
> > > subscription expired.
> > > 
> > > Ahh.. Now I see it. Ok. Yes, there is a problem
> Aki.
> > > 
> > > So the logic needs to be revised, which is what
> Jonathan was talking
> > > about. Now
> > > I understand. It seems that (nearly) everyone
> was intent on not
> > > specifying a
> > > standard interval for the URL to be good for.
> So, with that in mind,
> > > how about:
> > > 
> > > 1. The URL is good for the interval expressed in
> the EXPIRES
> > > header of the notification which contained the
> presence
> > > document URL, or the Subscription-Expires (soon
> to be
> > > Subscription-State), whichever is shorter.
> > 
> > I think this is wrong. How about:
> > 
> >   1. If the notification which contained the
> presence document URL
> >   also contained an Expires header, the URL is
> good for the interval
> >   expressed in that header.
> > 
> > This permits the document referenced by the URL to
> outlast
> > the subscription, if that is what the notifier
> desired.
> > The case where there is Subscription-Expires but
> not Expires
> > is covered by 5.
> > 
> > > 
> > > 2. If another notification is received during
> the interval
> > > identified in (1), then the previous URL should
> be considered
> > > stale. The most recent notification always takes
> precedence.
> > > 
> > > 3. If a persistient subscription (not a fetch)
> ends, any
> > > presence URLs associated with that subscription
> should be considered
> > > stale.
> > > 
> > > 4. If a notify is received with an EXPIRES set
> to zero, the
> > > URL is considered dead-on-arrival.
> > 
> > It would be stupid to do this. Since it is both
> stupid and a
> > special case of 1, no need to mention.
> > 
> > > 
> > > 5. If a notify is received without an EXPIRES
> header, the URL
> > > is good for the duration of the subscription.
> > > 
> > > 6. If a notify is received due to a subscription
> fetch, the URL
> > > is good for the interval expressed in the
> EXPIRES header of the
> > > notification which contained the presence
> document URL.
> > 
> > I don't understand this. What do you mean by a
> "subscription fetch"?
> > Does this say anything not covered by one of the
> other points?
> > 
> > 	Paul
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> >
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 


=====
--
Sean Olson 
This is from me. Assume nothing else.

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

From rsparks@dynamicsoft.com  Wed Dec 19 11:41:56 2001
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 LAA10662
	for ; Wed, 19 Dec 2001 11:41: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 fBJGdqES017218
	for ; Wed, 19 Dec 2001 11:39:52 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 19 Dec 2001 11:41:28 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E8C2@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Wed, 19 Dec 2001 11:41:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 14
Subject: [Simple] administrative test
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: 

please ignore

From bstucker@nortelnetworks.com  Wed Dec 19 14:28:13 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11230
	for ; Wed, 19 Dec 2001 14:28:12 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBJJROP15310;
	Wed, 19 Dec 2001 13:27:24 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 19 Dec 2001 13:25:57 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E013F14D5@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: Sean Olson , Paul Kyzivat 
Cc: Jonathan Rosenberg , adam.roach@ericsson.com,
        aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Wed, 19 Dec 2001 13:25:54 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C188C2.FA20A180"
Content-Length: 20953
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: 

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_01C188C2.FA20A180
Content-Type: text/plain;
	charset="iso-8859-1"

Except that Adam's draft doesn't mandate the Subscription-State in the -01
revision (at least to my reading). So you may not have a Subscription-State
header, and therefore would need the Expires to be zero if it's a fetch.

Yes, otherwise the whole issue is moot. Don't put a non-zero expires in
there, that makes no sense.

Brian

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Wednesday, December 19, 2001 8:48 AM
> To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat
> Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Duration of URIs in application/uri-list for
> Presenc e
> 
> 
> I would argue that if the server wants to return
> a list of URLs and if those URLs should be
> valid for a duration longer than zero seconds,
> then the Expire: header should be non-zero.
> A zero value for the expires parameter of the
> Subscription-State: header could be used to
> indicate that this is a "fetch" with no 
> actual subscription session. With this in mind,
> there is no reason to define any arbitrary interval.
> 
> /sean
> 
> --- Brian Stucker  wrote:
> > The reason I mention the fetch is because in the
> > sip-events draft, you can
> > have a NOTIFY with an expires of zero,
> > and no subscription-expires (the
> > subscription-expires is only a SHOULD,
> > presumably to keep from deprecating implementations
> > from the -00 draft).
> > 
> > So, if your client KNOWS that it just did a fetch,
> > then the problem as has
> > been pointed out is that the NOTIFY could come back
> > with no
> > subscription-expires header, an Expires header set
> > to zero (to denote that
> > the subscription is over as there never was one),
> > and with a presence URL
> > (because it's a fetch). In this case the client
> > shouldn't treat the URL as
> > dead-on-arrival even though the NOTIFY looks just
> > like a "stupid"
> > dead-on-arrival notify. I think this is what Aki was
> > getting at, and it's a
> > good point.
> > 
> > Either we agree to a set interval, as Jonathan has
> > suggested (which I'm fine
> > with), or we agree that when a URL is to be sent
> > back in NOTIFY that was
> > sent because of a fetch operation, that there MUST
> > be a
> > subscription-expires, and the expires header can't
> > be zero. Otherwise, URLs
> > returned as part of a fetch operation where the
> > optional
> > subscription-expires header isn't present would
> > either be immediately stale
> > (as Aki pointed out), or would be valid for an
> > undetermined amount of time
> > (which is what we're trying to avoid).
> > 
> > Regards,
> > 
> > Brian Stucker
> > 
> > 
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > Sent: Tuesday, December 18, 2001 3:52 PM
> > > To: Stucker, Brian [NGB:B635:EXCH]
> > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com;
> > aki.niemi@nokia.com;
> > > bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> > > simple@mailman.dynamicsoft.com
> > > Subject: Re: [Simple] Duration of URIs in
> > application/uri-list for
> > > Presence
> > > 
> > > 
> > > Comments below.
> > > 
> > > > Brian Stucker wrote:
> > > > 
> > > > The problem is that, the wording that was given
> > earlier meant that a
> > > > fetch
> > > > was not possible because the URL would only last
> > until the
> > > > subscription expired.
> > > > 
> > > > Ahh.. Now I see it. Ok. Yes, there is a problem
> > Aki.
> > > > 
> > > > So the logic needs to be revised, which is what
> > Jonathan was talking
> > > > about. Now
> > > > I understand. It seems that (nearly) everyone
> > was intent on not
> > > > specifying a
> > > > standard interval for the URL to be good for.
> > So, with that in mind,
> > > > how about:
> > > > 
> > > > 1. The URL is good for the interval expressed in
> > the EXPIRES
> > > > header of the notification which contained the
> > presence
> > > > document URL, or the Subscription-Expires (soon
> > to be
> > > > Subscription-State), whichever is shorter.
> > > 
> > > I think this is wrong. How about:
> > > 
> > >   1. If the notification which contained the
> > presence document URL
> > >   also contained an Expires header, the URL is
> > good for the interval
> > >   expressed in that header.
> > > 
> > > This permits the document referenced by the URL to
> > outlast
> > > the subscription, if that is what the notifier
> > desired.
> > > The case where there is Subscription-Expires but
> > not Expires
> > > is covered by 5.
> > > 
> > > > 
> > > > 2. If another notification is received during
> > the interval
> > > > identified in (1), then the previous URL should
> > be considered
> > > > stale. The most recent notification always takes
> > precedence.
> > > > 
> > > > 3. If a persistient subscription (not a fetch)
> > ends, any
> > > > presence URLs associated with that subscription
> > should be considered
> > > > stale.
> > > > 
> > > > 4. If a notify is received with an EXPIRES set
> > to zero, the
> > > > URL is considered dead-on-arrival.
> > > 
> > > It would be stupid to do this. Since it is both
> > stupid and a
> > > special case of 1, no need to mention.
> > > 
> > > > 
> > > > 5. If a notify is received without an EXPIRES
> > header, the URL
> > > > is good for the duration of the subscription.
> > > > 
> > > > 6. If a notify is received due to a subscription
> > fetch, the URL
> > > > is good for the interval expressed in the
> > EXPIRES header of the
> > > > notification which contained the presence
> > document URL.
> > > 
> > > I don't understand this. What do you mean by a
> > "subscription fetch"?
> > > Does this say anything not covered by one of the
> > other points?
> > > 
> > > 	Paul
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > >
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > 
> 
> 
> =====
> --
> Sean Olson 
> This is from me. Assume nothing else.
> 
> __________________________________________________
> Do You Yahoo!?
> Check out Yahoo! Shopping and Yahoo! Auctions for all of
> your unique holiday gifts! Buy at http://shopping.yahoo.com
> or bid at http://auctions.yahoo.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

------_=_NextPart_001_01C188C2.FA20A180
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Duration of URIs in application/uri-list for =
Presenc e




Except that Adam's draft doesn't mandate the =
Subscription-State in the -01 revision (at least to my reading). So you =
may not have a Subscription-State header, and therefore would need the =
Expires to be zero if it's a fetch.



Yes, otherwise the whole issue is moot. Don't put a =
non-zero expires in there, that makes no sense.




Brian




> -----Original Message-----

> From: Sean Olson [mailto:seancolson@yahoo.com]

> Sent: Wednesday, December 19, 2001 8:48 =
AM

> To: Stucker, Brian [NGB:B635:EXCH]; Paul =
Kyzivat

> Cc: Jonathan Rosenberg; =
adam.roach@ericsson.com; aki.niemi@nokia.com;

> bcampbell@dynamicsoft.com; =
seancolson@yahoo.com;

> simple@mailman.dynamicsoft.com

> Subject: RE: [Simple] Duration of URIs in =
application/uri-list for

> Presenc e

> 

> 

> I would argue that if the server wants to =
return

> a list of URLs and if those URLs should =
be

> valid for a duration longer than zero =
seconds,

> then the Expire: header should be =
non-zero.

> A zero value for the expires parameter of =
the

> Subscription-State: header could be used =
to

> indicate that this is a "fetch" with =
no 

> actual subscription session. With this in =
mind,

> there is no reason to define any arbitrary =
interval.

> 

> /sean

> 

> --- Brian Stucker =
<bstucker@nortelnetworks.com> wrote:

> > The reason I mention the fetch is because =
in the

> > sip-events draft, you can

> > have a NOTIFY with an expires of =
zero,

> > and no subscription-expires (the

> > subscription-expires is only a =
SHOULD,

> > presumably to keep from deprecating =
implementations

> > from the -00 draft).

> > 

> > So, if your client KNOWS that it just did =
a fetch,

> > then the problem as has

> > been pointed out is that the NOTIFY could =
come back

> > with no

> > subscription-expires header, an Expires =
header set

> > to zero (to denote that

> > the subscription is over as there never =
was one),

> > and with a presence URL

> > (because it's a fetch). In this case the =
client

> > shouldn't treat the URL as

> > dead-on-arrival even though the NOTIFY =
looks just

> > like a "stupid"

> > dead-on-arrival notify. I think this is =
what Aki was

> > getting at, and it's a

> > good point.

> > 

> > Either we agree to a set interval, as =
Jonathan has

> > suggested (which I'm fine

> > with), or we agree that when a URL is to =
be sent

> > back in NOTIFY that was

> > sent because of a fetch operation, that =
there MUST

> > be a

> > subscription-expires, and the expires =
header can't

> > be zero. Otherwise, URLs

> > returned as part of a fetch operation =
where the

> > optional

> > subscription-expires header isn't present =
would

> > either be immediately stale

> > (as Aki pointed out), or would be valid =
for an

> > undetermined amount of time

> > (which is what we're trying to =
avoid).

> > 

> > Regards,

> > 

> > Brian Stucker

> > 

> > 

> > > -----Original Message-----

> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=


> > > Sent: Tuesday, December 18, 2001 3:52 =
PM

> > > To: Stucker, Brian =
[NGB:B635:EXCH]

> > > Cc: Jonathan Rosenberg; =
adam.roach@ericsson.com;

> > aki.niemi@nokia.com;

> > > bcampbell@dynamicsoft.com; =
seancolson@yahoo.com;

> > > simple@mailman.dynamicsoft.com

> > > Subject: Re: [Simple] Duration of =
URIs in

> > application/uri-list for

> > > Presence

> > > 

> > > 

> > > Comments below.

> > > 

> > > > Brian Stucker wrote:

> > > > 

> > > > The problem is that, the wording =
that was given

> > earlier meant that a

> > > > fetch

> > > > was not possible because the URL =
would only last

> > until the

> > > > subscription expired.

> > > > 

> > > > Ahh.. Now I see it. Ok. Yes, =
there is a problem

> > Aki.

> > > > 

> > > > So the logic needs to be =
revised, which is what

> > Jonathan was talking

> > > > about. Now

> > > > I understand. It seems that =
(nearly) everyone

> > was intent on not

> > > > specifying a

> > > > standard interval for the URL to =
be good for.

> > So, with that in mind,

> > > > how about:

> > > > 

> > > > 1. The URL is good for the =
interval expressed in

> > the EXPIRES

> > > > header of the notification which =
contained the

> > presence

> > > > document URL, or the =
Subscription-Expires (soon

> > to be

> > > > Subscription-State), whichever =
is shorter.

> > > 

> > > I think this is wrong. How =
about:

> > > 

> > >   1. If the notification =
which contained the

> > presence document URL

> > >   also contained an Expires =
header, the URL is

> > good for the interval

> > >   expressed in that =
header.

> > > 

> > > This permits the document referenced =
by the URL to

> > outlast

> > > the subscription, if that is what the =
notifier

> > desired.

> > > The case where there is =
Subscription-Expires but

> > not Expires

> > > is covered by 5.

> > > 

> > > > 

> > > > 2. If another notification is =
received during

> > the interval

> > > > identified in (1), then the =
previous URL should

> > be considered

> > > > stale. The most recent =
notification always takes

> > precedence.

> > > > 

> > > > 3. If a persistient subscription =
(not a fetch)

> > ends, any

> > > > presence URLs associated with =
that subscription

> > should be considered

> > > > stale.

> > > > 

> > > > 4. If a notify is received with =
an EXPIRES set

> > to zero, the

> > > > URL is considered =
dead-on-arrival.

> > > 

> > > It would be stupid to do this. Since =
it is both

> > stupid and a

> > > special case of 1, no need to =
mention.

> > > 

> > > > 

> > > > 5. If a notify is received =
without an EXPIRES

> > header, the URL

> > > > is good for the duration of the =
subscription.

> > > > 

> > > > 6. If a notify is received due =
to a subscription

> > fetch, the URL

> > > > is good for the interval =
expressed in the

> > EXPIRES header of the

> > > > notification which contained the =
presence

> > document URL.

> > > 

> > > I don't understand this. What do you =
mean by a

> > "subscription fetch"?

> > > Does this say anything not covered by =
one of the

> > other points?

> > > 

> > >   Paul

> > > ______________________________________=
_________

> > > simple mailing list

> > > simple@mailman.dynamicsoft.com

> > >

> >

> http://mailman.dynamicsoft.com/mailman/listinfo/simple=


> > > 

> > 

> 

> 

> =3D=3D=3D=3D=3D

> --

> Sean Olson <seancolson@yahoo.com>

> This is from me. Assume nothing else.

> 

> =
__________________________________________________

> Do You Yahoo!?

> Check out Yahoo! Shopping and Yahoo! Auctions =
for all of

> your unique holiday gifts! Buy at http://shopping.yahoo.com

> or bid at http://auctions.yahoo.com

> =
_______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple=


> 





------_=_NextPart_001_01C188C2.FA20A180--

From bstucker@nortelnetworks.com  Wed Dec 19 14:32:59 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11263
	for ; Wed, 19 Dec 2001 14:32:59 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBJJSAP15472;
	Wed, 19 Dec 2001 13:28:10 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 19 Dec 2001 13:26:43 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E013F14DB@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: "Brian Stucker" ,
        Sean Olson , Paul Kyzivat 
Cc: Jonathan Rosenberg , adam.roach@ericsson.com,
        aki.niemi@nokia.com, bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Wed, 19 Dec 2001 13:26:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C188C3.165FEC70"
Content-Length: 10338
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: 

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_01C188C3.165FEC70
Content-Type: text/plain;
	charset="iso-8859-1"

Sorry, meant to say don't put a ZERO expires in there. =)

> -----Original Message-----
> From: Stucker, Brian [NGB:B635:EXCH] 
> Sent: Wednesday, December 19, 2001 1:31 PM
> To: 'Sean Olson'; Paul Kyzivat
> Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Duration of URIs in application/uri-list for
> Presenc e
> 
> 
> Except that Adam's draft doesn't mandate the 
> Subscription-State in the -01 revision (at least to my 
> reading). So you may not have a Subscription-State header, 
> and therefore would need the Expires to be zero if it's a fetch.
> 
> Yes, otherwise the whole issue is moot. Don't put a non-zero 
> expires in there, that makes no sense.
> 
> Brian
> 
> > -----Original Message-----
> > From: Sean Olson [mailto:seancolson@yahoo.com]
> > Sent: Wednesday, December 19, 2001 8:48 AM
> > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat
> > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; 
> aki.niemi@nokia.com;
> > bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> > simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Duration of URIs in application/uri-list for
> > Presenc e
> > 
> > 
> > I would argue that if the server wants to return
> > a list of URLs and if those URLs should be
> > valid for a duration longer than zero seconds,
> > then the Expire: header should be non-zero.
> > A zero value for the expires parameter of the
> > Subscription-State: header could be used to
> > indicate that this is a "fetch" with no 
> > actual subscription session. With this in mind,
> > there is no reason to define any arbitrary interval.
> > 
> > /sean
> > 
> > --- Brian Stucker  wrote:
> > > The reason I mention the fetch is because in the
> > > sip-events draft, you can
> > > have a NOTIFY with an expires of zero,
> > > and no subscription-expires (the
> > > subscription-expires is only a SHOULD,
> > > presumably to keep from deprecating implementations
> > > from the -00 draft).
> > > 
> > > So, if your client KNOWS that it just did a fetch,
> > > then the problem as has
> > > been pointed out is that the NOTIFY could come back
> > > with no
> > > subscription-expires header, an Expires header set
> > > to zero (to denote that
> > > the subscription is over as there never was one),
> > > and with a presence URL
> > > (because it's a fetch). In this case the client
> > > shouldn't treat the URL as
> > > dead-on-arrival even though the NOTIFY looks just
> > > like a "stupid"
> > > dead-on-arrival notify. I think this is what Aki was
> > > getting at, and it's a
> > > good point.
> > > 
> > > Either we agree to a set interval, as Jonathan has
> > > suggested (which I'm fine
> > > with), or we agree that when a URL is to be sent
> > > back in NOTIFY that was
> > > sent because of a fetch operation, that there MUST
> > > be a
> > > subscription-expires, and the expires header can't
> > > be zero. Otherwise, URLs
> > > returned as part of a fetch operation where the
> > > optional
> > > subscription-expires header isn't present would
> > > either be immediately stale
> > > (as Aki pointed out), or would be valid for an
> > > undetermined amount of time
> > > (which is what we're trying to avoid).
> > > 
> > > Regards,
> > > 
> > > Brian Stucker
> > > 
> > > 

------_=_NextPart_001_01C188C3.165FEC70
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Duration of URIs in application/uri-list for Presenc e




Sorry, meant to say don't put a ZERO expires in there. =)




> -----Original Message-----

> From: Stucker, Brian [NGB:B635:EXCH] 

> Sent: Wednesday, December 19, 2001 1:31 PM

> To: 'Sean Olson'; Paul Kyzivat

> Cc: Jonathan Rosenberg; adam.roach@ericsson.com; aki.niemi@nokia.com;

> bcampbell@dynamicsoft.com; seancolson@yahoo.com;

> simple@mailman.dynamicsoft.com

> Subject: RE: [Simple] Duration of URIs in application/uri-list for

> Presenc e

> 

> 

> Except that Adam's draft doesn't mandate the 

> Subscription-State in the -01 revision (at least to my 

> reading). So you may not have a Subscription-State header, 

> and therefore would need the Expires to be zero if it's a fetch.

> 

> Yes, otherwise the whole issue is moot. Don't put a non-zero 

> expires in there, that makes no sense.

> 

> Brian

> 

> > -----Original Message-----

> > From: Sean Olson [mailto:seancolson@yahoo.com]

> > Sent: Wednesday, December 19, 2001 8:48 AM

> > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat

> > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; 

> aki.niemi@nokia.com;

> > bcampbell@dynamicsoft.com; seancolson@yahoo.com;

> > simple@mailman.dynamicsoft.com

> > Subject: RE: [Simple] Duration of URIs in application/uri-list for

> > Presenc e

> > 

> > 

> > I would argue that if the server wants to return

> > a list of URLs and if those URLs should be

> > valid for a duration longer than zero seconds,

> > then the Expire: header should be non-zero.

> > A zero value for the expires parameter of the

> > Subscription-State: header could be used to

> > indicate that this is a "fetch" with no 

> > actual subscription session. With this in mind,

> > there is no reason to define any arbitrary interval.

> > 

> > /sean

> > 

> > --- Brian Stucker <bstucker@nortelnetworks.com> wrote:

> > > The reason I mention the fetch is because in the

> > > sip-events draft, you can

> > > have a NOTIFY with an expires of zero,

> > > and no subscription-expires (the

> > > subscription-expires is only a SHOULD,

> > > presumably to keep from deprecating implementations

> > > from the -00 draft).

> > > 

> > > So, if your client KNOWS that it just did a fetch,

> > > then the problem as has

> > > been pointed out is that the NOTIFY could come back

> > > with no

> > > subscription-expires header, an Expires header set

> > > to zero (to denote that

> > > the subscription is over as there never was one),

> > > and with a presence URL

> > > (because it's a fetch). In this case the client

> > > shouldn't treat the URL as

> > > dead-on-arrival even though the NOTIFY looks just

> > > like a "stupid"

> > > dead-on-arrival notify. I think this is what Aki was

> > > getting at, and it's a

> > > good point.

> > > 

> > > Either we agree to a set interval, as Jonathan has

> > > suggested (which I'm fine

> > > with), or we agree that when a URL is to be sent

> > > back in NOTIFY that was

> > > sent because of a fetch operation, that there MUST

> > > be a

> > > subscription-expires, and the expires header can't

> > > be zero. Otherwise, URLs

> > > returned as part of a fetch operation where the

> > > optional

> > > subscription-expires header isn't present would

> > > either be immediately stale

> > > (as Aki pointed out), or would be valid for an

> > > undetermined amount of time

> > > (which is what we're trying to avoid).

> > > 

> > > Regards,

> > > 

> > > Brian Stucker

> > > 

> > > 





------_=_NextPart_001_01C188C3.165FEC70--

From jdrosen@dynamicsoft.com  Wed Dec 19 12:44:54 2001
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 MAA10894
	for ; Wed, 19 Dec 2001 12:44: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 fBJHgnES017951
	for <"simple@mailman.dynamicsoft.com">; Wed, 19 Dec 2001 12:42:49 -0500 (EST)
Received: from dynamicsoft.com (POPE1 [63.113.46.82]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZDFR1M3N; Wed, 19 Dec 2001 12:44:25 -0500
Message-ID: <3C20D1F8.60308@dynamicsoft.com>
Date: Wed, 19 Dec 2001 12:44:24 -0500
From: Jonathan Rosenberg 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: "simple@mailman.dynamicsoft.com"@mail1.dynamicsoft.com
Subject: [Fwd: Re: [Simple] Duration of URIs in application/uri-list for Presenc	 e]
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1739
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: 

Resend due to some unusual mailing problems....

aki.niemi@nokia.com wrote:

 > Hi All,
 >
 >
 >>I agree with Ben. Although you raise good points Paul.
 >>Can we all agree to:
 >>1. The URL is good for the interval expressed in the EXPIRES
 >>header of the notification which contained the presence
 >>document URL, or the Subscription-Expires (soon to be
 >>Subscription-State), whichever is shorter.
 >>
 >
 > Overall, I like the sound of this proposal. However, a distinct linking
 > like
 > this between the Subscription-Expires and Expires assumes that
 > subscriptions
 > always establish a session. This assumption makes a fetch of event state
 > impossible using the URL mechanism.


Good point.

Why don't we simplify this, then, and state that the URL is valid for
duration in the Expires, if present, otherwise, the duration of the
subscription, and that the next NOTIFY overrides the previous URL. This
way, if you want the URL validity to be less than the subscription
duration, you can do that (Expires < Subscription-Expires), equal to it
(no Expires) or greater than it (Expires > Subscription-Expires). We
also say that in absense of reasons to do so otherwise, the URL SHOULD
be valid for the duration of the subscription, and for fetches, for some
reasonable interval, say 2 min.

That is, we specify semantics that enable any policy, and state a
recommended baseline policy.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From aki.niemi@nokia.com  Thu Dec 20 07:00:10 2001
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 HAA14259
	for ; Thu, 20 Dec 2001 07:00:09 -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 fBKBxc913004
	for ; Thu, 20 Dec 2001 13:59:38 +0200 (EET)
Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 20 Dec 2001 13:59:38 +0200
Received: by esebh24nok with Internet Mail Service (5.5.2652.78)
	id ; Thu, 20 Dec 2001 13:59:38 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC84@esebe013.NOE.Nokia.com>
To: bstucker@nortelnetworks.com, seancolson@yahoo.com, pkyzivat@cisco.com
Cc: jdrosen@dynamicsoft.com, adam.roach@ericsson.com,
        bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Thu, 20 Dec 2001 13:59:28 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4034
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: 

Hi,

> Except that Adam's draft doesn't mandate the 
> Subscription-State in the -01 revision (at least to my 
> reading). So you may not have a Subscription-State header, 
> and therefore would need the Expires to be zero if it's a fetch. 

The client knows it's a fetch because:
	
	- It sets the Expires to zero in its SUBSCRIBE
	- the 2xx for the SUBSCRIBE carries an Expires: 0

The Expires in NOTIFY should be scoped to only set the expiry for that
particular message content. Subscription-* is there to communicate the
expiry for the whole session.

I don't see why there needs to be anything else specified for the URI-list
case, other than "If you give a link instead of the document, you SHOULD use
Expires to say how long the link is valid for."

An arriving NOTIFY might override some or all of the information given in a
previous URL, and the content of the URL might be invalid, it doesn't really
matter. If notifications carry documents instead, this is anyway
self-evident; older documents are not necessarily valid, especially after
the subscription has been terminated.

I may be missing a point here, but I don't feel there is need to say
anything more about using Expires in a NOTIFY, than what is already said for
the default usage of Expires.

Regards,
Aki  

 
> Yes, otherwise the whole issue is moot. Don't put a non-zero 
> expires in there, that makes no sense. 
> 
> Brian 
> 
> > -----Original Message----- 
> > From: Sean Olson [mailto:seancolson@yahoo.com] 
> > Sent: Wednesday, December 19, 2001 8:48 AM 
> > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat 
> > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; 
> aki.niemi@nokia.com; 
> > bcampbell@dynamicsoft.com; seancolson@yahoo.com; 
> > simple@mailman.dynamicsoft.com 
> > Subject: RE: [Simple] Duration of URIs in application/uri-list for 
> > Presenc e 
> > 
> > 
> > I would argue that if the server wants to return 
> > a list of URLs and if those URLs should be 
> > valid for a duration longer than zero seconds, 
> > then the Expire: header should be non-zero. 
> > A zero value for the expires parameter of the 
> > Subscription-State: header could be used to 
> > indicate that this is a "fetch" with no 
> > actual subscription session. With this in mind, 
> > there is no reason to define any arbitrary interval. 
> > 
> > /sean 
> > 
> > --- Brian Stucker  wrote: 
> > > The reason I mention the fetch is because in the 
> > > sip-events draft, you can 
> > > have a NOTIFY with an expires of zero, 
> > > and no subscription-expires (the 
> > > subscription-expires is only a SHOULD, 
> > > presumably to keep from deprecating implementations 
> > > from the -00 draft). 
> > > 
> > > So, if your client KNOWS that it just did a fetch, 
> > > then the problem as has 
> > > been pointed out is that the NOTIFY could come back 
> > > with no 
> > > subscription-expires header, an Expires header set 
> > > to zero (to denote that 
> > > the subscription is over as there never was one), 
> > > and with a presence URL 
> > > (because it's a fetch). In this case the client 
> > > shouldn't treat the URL as 
> > > dead-on-arrival even though the NOTIFY looks just 
> > > like a "stupid" 
> > > dead-on-arrival notify. I think this is what Aki was 
> > > getting at, and it's a 
> > > good point. 
> > > 
> > > Either we agree to a set interval, as Jonathan has 
> > > suggested (which I'm fine 
> > > with), or we agree that when a URL is to be sent 
> > > back in NOTIFY that was 
> > > sent because of a fetch operation, that there MUST 
> > > be a 
> > > subscription-expires, and the expires header can't 
> > > be zero. Otherwise, URLs 
> > > returned as part of a fetch operation where the 
> > > optional 
> > > subscription-expires header isn't present would 
> > > either be immediately stale 
> > > (as Aki pointed out), or would be valid for an 
> > > undetermined amount of time 
> > > (which is what we're trying to avoid). 
> > > 
> > > Regards, 
> > > 
> > > Brian Stucker 
> > > 
> > > 

From bstucker@nortelnetworks.com  Thu Dec 20 10:26:02 2001
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14880
	for ; Thu, 20 Dec 2001 10:26:01 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBKFLZ011859;
	Thu, 20 Dec 2001 09:21:35 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 20 Dec 2001 09:20:08 -0600
Message-ID: <933FADF5E673D411B8A30002A5608A0E013F1AAD@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: aki.niemi@nokia.com, seancolson@yahoo.com, pkyzivat@cisco.com
Cc: jdrosen@dynamicsoft.com, adam.roach@ericsson.com,
        bcampbell@dynamicsoft.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Duration of URIs in application/uri-list for Presenc
	 e
Date: Thu, 20 Dec 2001 09:20:08 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C18969.CF7901F0"
Content-Length: 15532
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: 

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_01C18969.CF7901F0
Content-Type: text/plain;
	charset="iso-8859-1"

In the draft (as I read it) if you do not include a subscription-expires
(soon to be
subscription-state) in the NOTIFY of a fetch, it should include instead an
EXPIRES of zero.

That would mean the URL should be immediately treated as stale.

That's the problem. If there's always a subscription-expires header there,
then you can put
whatever you want in the EXPIRES header.

It's the normative language on the subscription-expires that makes the
problem possible.

Brian

> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Thursday, December 20, 2001 5:59 AM
> To: Stucker, Brian [NGB:B635:EXCH]; seancolson@yahoo.com;
> pkyzivat@cisco.com
> Cc: jdrosen@dynamicsoft.com; adam.roach@ericsson.com;
> bcampbell@dynamicsoft.com; seancolson@yahoo.com;
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Duration of URIs in application/uri-list for
> Presenc e
> 
> 
> Hi,
> 
> > Except that Adam's draft doesn't mandate the 
> > Subscription-State in the -01 revision (at least to my 
> > reading). So you may not have a Subscription-State header, 
> > and therefore would need the Expires to be zero if it's a fetch. 
> 
> The client knows it's a fetch because:
> 	
> 	- It sets the Expires to zero in its SUBSCRIBE
> 	- the 2xx for the SUBSCRIBE carries an Expires: 0
> 
> The Expires in NOTIFY should be scoped to only set the expiry for that
> particular message content. Subscription-* is there to communicate the
> expiry for the whole session.
> 
> I don't see why there needs to be anything else specified for 
> the URI-list
> case, other than "If you give a link instead of the document, 
> you SHOULD use
> Expires to say how long the link is valid for."
> 
> An arriving NOTIFY might override some or all of the 
> information given in a
> previous URL, and the content of the URL might be invalid, it 
> doesn't really
> matter. If notifications carry documents instead, this is anyway
> self-evident; older documents are not necessarily valid, 
> especially after
> the subscription has been terminated.
> 
> I may be missing a point here, but I don't feel there is need to say
> anything more about using Expires in a NOTIFY, than what is 
> already said for
> the default usage of Expires.
> 
> Regards,
> Aki  
> 
>  
> > Yes, otherwise the whole issue is moot. Don't put a non-zero 
> > expires in there, that makes no sense. 
> > 
> > Brian 
> > 
> > > -----Original Message----- 
> > > From: Sean Olson [mailto:seancolson@yahoo.com] 
> > > Sent: Wednesday, December 19, 2001 8:48 AM 
> > > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat 
> > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; 
> > aki.niemi@nokia.com; 
> > > bcampbell@dynamicsoft.com; seancolson@yahoo.com; 
> > > simple@mailman.dynamicsoft.com 
> > > Subject: RE: [Simple] Duration of URIs in 
> application/uri-list for 
> > > Presenc e 
> > > 
> > > 
> > > I would argue that if the server wants to return 
> > > a list of URLs and if those URLs should be 
> > > valid for a duration longer than zero seconds, 
> > > then the Expire: header should be non-zero. 
> > > A zero value for the expires parameter of the 
> > > Subscription-State: header could be used to 
> > > indicate that this is a "fetch" with no 
> > > actual subscription session. With this in mind, 
> > > there is no reason to define any arbitrary interval. 
> > > 
> > > /sean 
> > > 
> > > --- Brian Stucker  wrote: 
> > > > The reason I mention the fetch is because in the 
> > > > sip-events draft, you can 
> > > > have a NOTIFY with an expires of zero, 
> > > > and no subscription-expires (the 
> > > > subscription-expires is only a SHOULD, 
> > > > presumably to keep from deprecating implementations 
> > > > from the -00 draft). 
> > > > 
> > > > So, if your client KNOWS that it just did a fetch, 
> > > > then the problem as has 
> > > > been pointed out is that the NOTIFY could come back 
> > > > with no 
> > > > subscription-expires header, an Expires header set 
> > > > to zero (to denote that 
> > > > the subscription is over as there never was one), 
> > > > and with a presence URL 
> > > > (because it's a fetch). In this case the client 
> > > > shouldn't treat the URL as 
> > > > dead-on-arrival even though the NOTIFY looks just 
> > > > like a "stupid" 
> > > > dead-on-arrival notify. I think this is what Aki was 
> > > > getting at, and it's a 
> > > > good point. 
> > > > 
> > > > Either we agree to a set interval, as Jonathan has 
> > > > suggested (which I'm fine 
> > > > with), or we agree that when a URL is to be sent 
> > > > back in NOTIFY that was 
> > > > sent because of a fetch operation, that there MUST 
> > > > be a 
> > > > subscription-expires, and the expires header can't 
> > > > be zero. Otherwise, URLs 
> > > > returned as part of a fetch operation where the 
> > > > optional 
> > > > subscription-expires header isn't present would 
> > > > either be immediately stale 
> > > > (as Aki pointed out), or would be valid for an 
> > > > undetermined amount of time 
> > > > (which is what we're trying to avoid). 
> > > > 
> > > > Regards, 
> > > > 
> > > > Brian Stucker 
> > > > 
> > > > 
> 

------_=_NextPart_001_01C18969.CF7901F0
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] Duration of URIs in application/uri-list for Presenc e




In the draft (as I read it) if you do not include a subscription-expires (soon to be

subscription-state) in the NOTIFY of a fetch, it should include instead an EXPIRES of zero.




That would mean the URL should be immediately treated as stale.




That's the problem. If there's always a subscription-expires header there, then you can put

whatever you want in the EXPIRES header.




It's the normative language on the subscription-expires that makes the problem possible.




Brian




> -----Original Message-----

> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]

> Sent: Thursday, December 20, 2001 5:59 AM

> To: Stucker, Brian [NGB:B635:EXCH]; seancolson@yahoo.com;

> pkyzivat@cisco.com

> Cc: jdrosen@dynamicsoft.com; adam.roach@ericsson.com;

> bcampbell@dynamicsoft.com; seancolson@yahoo.com;

> simple@mailman.dynamicsoft.com

> Subject: RE: [Simple] Duration of URIs in application/uri-list for

> Presenc e

> 

> 

> Hi,

> 

> > Except that Adam's draft doesn't mandate the 

> > Subscription-State in the -01 revision (at least to my 

> > reading). So you may not have a Subscription-State header, 

> > and therefore would need the Expires to be zero if it's a fetch. 

> 

> The client knows it's a fetch because:

>       

>       - It sets the Expires to zero in its SUBSCRIBE

>       - the 2xx for the SUBSCRIBE carries an Expires: 0

> 

> The Expires in NOTIFY should be scoped to only set the expiry for that

> particular message content. Subscription-* is there to communicate the

> expiry for the whole session.

> 

> I don't see why there needs to be anything else specified for 

> the URI-list

> case, other than "If you give a link instead of the document, 

> you SHOULD use

> Expires to say how long the link is valid for."

> 

> An arriving NOTIFY might override some or all of the 

> information given in a

> previous URL, and the content of the URL might be invalid, it 

> doesn't really

> matter. If notifications carry documents instead, this is anyway

> self-evident; older documents are not necessarily valid, 

> especially after

> the subscription has been terminated.

> 

> I may be missing a point here, but I don't feel there is need to say

> anything more about using Expires in a NOTIFY, than what is 

> already said for

> the default usage of Expires.

> 

> Regards,

> Aki  

> 

>  

> > Yes, otherwise the whole issue is moot. Don't put a non-zero 

> > expires in there, that makes no sense. 

> > 

> > Brian 

> > 

> > > -----Original Message----- 

> > > From: Sean Olson [mailto:seancolson@yahoo.com] 

> > > Sent: Wednesday, December 19, 2001 8:48 AM 

> > > To: Stucker, Brian [NGB:B635:EXCH]; Paul Kyzivat 

> > > Cc: Jonathan Rosenberg; adam.roach@ericsson.com; 

> > aki.niemi@nokia.com; 

> > > bcampbell@dynamicsoft.com; seancolson@yahoo.com; 

> > > simple@mailman.dynamicsoft.com 

> > > Subject: RE: [Simple] Duration of URIs in 

> application/uri-list for 

> > > Presenc e 

> > > 

> > > 

> > > I would argue that if the server wants to return 

> > > a list of URLs and if those URLs should be 

> > > valid for a duration longer than zero seconds, 

> > > then the Expire: header should be non-zero. 

> > > A zero value for the expires parameter of the 

> > > Subscription-State: header could be used to 

> > > indicate that this is a "fetch" with no 

> > > actual subscription session. With this in mind, 

> > > there is no reason to define any arbitrary interval. 

> > > 

> > > /sean 

> > > 

> > > --- Brian Stucker <bstucker@nortelnetworks.com> wrote: 

> > > > The reason I mention the fetch is because in the 

> > > > sip-events draft, you can 

> > > > have a NOTIFY with an expires of zero, 

> > > > and no subscription-expires (the 

> > > > subscription-expires is only a SHOULD, 

> > > > presumably to keep from deprecating implementations 

> > > > from the -00 draft). 

> > > > 

> > > > So, if your client KNOWS that it just did a fetch, 

> > > > then the problem as has 

> > > > been pointed out is that the NOTIFY could come back 

> > > > with no 

> > > > subscription-expires header, an Expires header set 

> > > > to zero (to denote that 

> > > > the subscription is over as there never was one), 

> > > > and with a presence URL 

> > > > (because it's a fetch). In this case the client 

> > > > shouldn't treat the URL as 

> > > > dead-on-arrival even though the NOTIFY looks just 

> > > > like a "stupid" 

> > > > dead-on-arrival notify. I think this is what Aki was 

> > > > getting at, and it's a 

> > > > good point. 

> > > > 

> > > > Either we agree to a set interval, as Jonathan has 

> > > > suggested (which I'm fine 

> > > > with), or we agree that when a URL is to be sent 

> > > > back in NOTIFY that was 

> > > > sent because of a fetch operation, that there MUST 

> > > > be a 

> > > > subscription-expires, and the expires header can't 

> > > > be zero. Otherwise, URLs 

> > > > returned as part of a fetch operation where the 

> > > > optional 

> > > > subscription-expires header isn't present would 

> > > > either be immediately stale 

> > > > (as Aki pointed out), or would be valid for an 

> > > > undetermined amount of time 

> > > > (which is what we're trying to avoid). 

> > > > 

> > > > Regards, 

> > > > 

> > > > Brian Stucker 

> > > > 

> > > > 

> 





------_=_NextPart_001_01C18969.CF7901F0--

From jdrosen@dynamicsoft.com  Fri Dec 21 15:59:22 2001
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20183
	for ; Fri, 21 Dec 2001 15:59:22 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.76])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBLKxEVZ000779
	for ; Fri, 21 Dec 2001 15:59:15 -0500 (EST)
Message-ID: <3C23A28C.30606@dynamicsoft.com>
Date: Fri, 21 Dec 2001 15:58:52 -0500
From: Jonathan Rosenberg 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 337
Subject: [Simple] testing - please ignore
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 

sorry...
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From rsparks@dynamicsoft.com  Wed Jan  9 11:13:40 2002
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 LAA10181
	for ; Wed, 9 Jan 2002 11:13:40 -0500 (EST)
Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g09GBMvw017811
	for ; Wed, 9 Jan 2002 11:11:22 -0500 (EST)
Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 9 Jan 2002 11:13:06 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E932@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Wed, 9 Jan 2002 11:13:04 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 23032
Subject: [Simple] Draft minutes SIMPLE meeting IETF52
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: 

Here is a draft of the simple minutes for IETF52.
Please review and submit corrections before Friday 1/11.

RjS

-------------
SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions
Minutes - 12/12/2001 1300-1500 MDT - IETF52
Chairs: Jon Peterson - jon.peterson@neustar.com
        Robert Sparks - rsparks@dynamicsoft.com

Summary:

Charter and logistics

* An update to the SIMPLE charter has been submitted
  reflecting the SIP/SIPPING split, the proposed SIP
  change process, and the watcherinfo/CPIM mapping
  deliverables. Publication has been tabled pending
  outcome of disussions in SIPPING (see the SIPPING
  minutes)

* MESSAGE has been handed off to SIP - currently 
  scheduled for last call in May. Brian Rosen will
  work with us to move that call to an earlier date

draft-ietf-simple-presence:

* The presence draft will be modified to rely directly
  on sip-events, which will in turn rely on sip-bis 
  instead of 2543. The result will be shorter documents
  with less opportunity for unintentional contradiction.

* We will provide Alerts (notification with indirect content).
  Primary remaining issue: Lifetime of URI in an Alert.
  Both the sip-events and presence drafts will have to change
  to reflect this.

* There is consensus to establish a presence subscription
  dialog based on the first arriving NOTIFY or 2xx response
  to the SUBSCRIBE

* There is consensus to leave the current forking
  text as is. Subscribers SHOULD accept only one
  NOTIFY. If merging is required, the burden lies
  on the subscriber.

draft-ietf-simple-winfo-package:
draft-ietf-simple-winfo-format:

* Proposed recent format changes accepted with
  the additional removal of most-recently-subscribed

* Sip-events and the format draft will reconcile the
  descriptions of reasons for terminating subscriptions

draft-mankin-im-session-guide:

* Hum against taking this on as a SIMPLE work item
  Opinion was that work on the draft should continue
  in the transport area

* SIMPLE group urged to internalize its guidelines

* Applicability of the requirements being placed on OPES
  wrt intermediary discovery and disclosure needs to be
  discussed

draft-rosenberg-simple-im-transport:

* Weakly expressed support. Moderately strong hum against
  proceeding with this proposal.
  - concerns over keeping IMTP and SIP syncronized
  
* Alternate proposal solicited - if none appears before
  early January, work will proceed with IMTP

* Split opinions on whether a proposal must be held to 
  mankin-im-session-guide


--------------------------------------------------------------------- 
Full Notes (thanks to Brian Stucker - bstucker@nortelnetworks.com) 

Charter Updates: 
Have submitted a new charter. 
* Charter resubmitted a couple of weeks ago 
* Now reflects SIP/SIPPING split and proposed SIP change process. 
* Presence 'extension' deliverable now 'event package and related 
protocol mechanisms' 
* Presence publication tabled in SIMPLE, currently considered in 
SIPPING. 
* Dec 01- Presence event package, watcherinfo, CPIM mapping. 
* Jan 02 - Messaging drafts 
Transferred deliverables 
* Draft-ietf-simple-im-01/draft-ietf-sip-message-00 
  - Status (any SIP chairs want to speak to schedule?) 
  - SIP drafts page say May 02 - be nice if that could be moved in a 
bit. 
    * Brian Rosen: Drafts dates are based on logistics problems. We can 
move it up if we can get the draft ready, get reviewers, list comment, 
etc. But we can move it up if there is a need? 
    * Jon: Would be nice if we could have this in the first quarter? 
    * Brian: We'll look into it. 
* Draft-donovan-publish-requirements-01 
  - An actual proposal discussed in SIPPING yesterday. 
  - Clear that SIPPING will only do requirements for publication. 
    * Where will it go from there? SIP WG? 
    * The IETF would like to do the right thing, and not get too rule 
bound. Hope is that the same people will spend some time in SIPPING and 
make sure that the right approach is formed.  The method document has 
to come out of SIP. 
    * SIPPING needs to look at the problem of whether or not we need a 
new method. 
    * Question begs, is presence publication urgently needed in SIMPLE, 
and that needs to be looked into. 

------------------------------------ 

Presence Open Issues: 
* Open issues in presence-04 
  - Dependencies and duplication 
    * Currently 
      - Rfc-2543 <- sip events <- presence 
      - Problem is that sip events is duplicating text from bis-05. 
        * Can we simply make sip events dependent on bis, 
          thereby shortening it. 
      - Presence is duplicating text from sip events. 
    * Proposal 
      - Bis <- sip events <- presence 
        * Bis is nearing completion so timing is not going to be 
          much different 
        * Requires cleanup of redundant text across all three documents
          in progress. This will be done. 
  - Alerts 
    * Would be nice to only be notified of change in presence, not 
      actual presence. 
    * Actual presence could then be fetched with HTTP 
    * Why is this useful? 
      - Large presence documents wouldn't get fragmented. 
      - Large presence docs could be fetched when time is good 
        (ie. Not in a call). 
    * Details 
      - SUBSCRIBE would have Accept header indicate support 
      - Presence of application/uri-list 
      - Still have to support application/cpim-pidf+xml 
      - Etc 
    * Issues with Alerts 
      - Broader than presence. Probably belongs in sip-events 
        * Presence would then state that its allowed. 
      - Security issues 
        * Just because SIP can be authenticated, doesn't mean HTTP can. 
          - Transitive trust vs. e2e 
          - Henning brought up concerns on this. 
      - HTTP SIP interactions 
        * Requires a way for SIP server to manipulate content on web server.

          - Henning brought up concerns on this. 
      - Duration of URL validity 
        * Need to specify - presumably subscription duration. 
    * Proposal 
      - Really useful, really simple 
      - Add to sip-events and presence. 

Henning: Similar to web server problem. 
Jonathan: does require an interaction between HTTP and SIP; don't 
have to do it. 
Henning: Must specify something that will work well. 
Brian: Doesn't have to be HTTP, could use other mechanisms. 
Jonathan: Must develop a baseline. 

Call for opinions: 
Sean: I don't see this as a major issue, or a hard thing to do. 
Adam: I'm in support for this, I don't see a problem. The issues 
that Henning brings up are not completely trivial, but they're 
easy to take care of.  Can be added to sip-events, but doesn't 
see a need. 
Rosenberg: Wants a general mechanism the same across all packages 
and to specify behaviors. Need to specify the duration that the 
presence URL is good for. 
Sean/Rohan: Don't go into such detail about the implementation. 
It's unimportant how long the document sticks around. 
Henning: We need to make sure that the semantics are complete and 
equivalent. 
Brian Stucker: Agrees that need to specify amount of time for URL 
to be valid, just as there is one for subscription. Interval 
doesn't need to be specified. 
Sean: There's no guarantee that the semantics are equivalent. 
Adam: This sounds like the argument about how to encode a piece 
of content versus what it means. 
Rosenberg: This is an automata that is processing this URL, so it 
needs to have an idea of how long the URL is good for. 
Jon: Is there any value in leaving this URL open for our 
application? 
Rohan: I don't think that's what Rosenberg is proposing. 
Diana: Likes the consistiency. Does this trickle to general SIP? 
Henning: The semantics that we are arguing about here are buyer 
beware problems. This is a presence document, versus this 
document is not going to be around after a period of time. We 
wouldn't specify that this is a presence document, we're 
specifying other attributes. 
Adam: I don't have a problem with the proposal, but it sounds 
like the semantics of the usage should be in the presence 
document. 
Jonathan: Need to specify what URL means and have well-defined 
semantics to work. 
Henning: sending a JPEG isn't particularly useful. 
Sean: Your implementation has to handle it - doesn't need 
standardization. 
Adam: How is content encoded Vs. what does it mean? 
Jonathan: Wants to define what it means when you return a URL. 
It's important to remember that a person isn't using this URI, 
an automata is.  
Andrew: This is like W3C semantic web problem. 
Jonathan: Disagree - not solving that problem 
Jon: What do we want the Presence URI to mean? 
Rohan: That's not what Jonathan is proposing. 
Henning: 2 issues: what are the time properties and what is the 
content.  In events, this would not be a presence document.  
The semantics being argued are hints to the implementor - these 
are the semantic expectations.   Agree that semantics need to 
be specified. 
Jonathan: Most web browsers accept *.*.  This URI should be 
very specific and have full semantic content, unlike normal web 
request. 
Rosenberg: Presence package would say that this is a one-shot 
document, etc. 

Conclusion: Continue discussion on the list. 

  - NOTIFY/200 Race condition 
    * ASSUME you want to only accept one NOTIFY 
    * Sip-events says you should accept the one that matches 2xx to 
      SUBSCRIBE. 
    * Proposals 
      - Buffer NOTIFYs until 2xx, then 481 all that non-matching ones. 
      - Accept all NOTIFYs, when 2xx arrives, refersh all non-matching. 
      - Accept first NOTIFY 
        * SUB 2xx is ignored 
      - Accept first message 
        * SUB 2xx if its first 
        * NOTIFY it its first 
    * Probably also an issue for sip-events, not presence. 

  - Forking 
    * Definitely the biggest issue. 
    * Some problems are not presence specific 
      - HERFP 
    * Proposal 
      - Keep what's in the document. If they need aggregation, then put 
        a point in the network and leave it be. 
      - If there are multiple PUA, you get partial presence, no 
        guarantees. 
      - Subscribers SHOULD accept only one NOTIFY 
      - Burden is on the subscriber to implement merging if it wants. 
      - Won't generally be needed based on domain requirements and 
        frequently won't happen because HERFP. 

Conclusion: No time for discussion, taken to list. 
---------------------------------------- 
Watcherinfo Open Issues 
  - Events leading to terminated 
    * See previous discussion 
  - State maintenance for pending/waiting 
    * Possible Dos? Sub is authenticated 
    * -01 will talk about setting policy for this 
      - Tradeoff between user experience and state storage 
Stucker: isn't this just a policy issue? Why does this belong in watcher 
info? 
Rosenberg: When you have watcher subs you need to keep state for things 
being watched.  The fact that there's a watcher info on t you need a 
state. Want to specify a caution with regards to potential for attacks. 
The watcherinfo draft defines a model for presence. We shouldn't have this
in sip-events. 
Stucker: Are you going to add when to indicate when subscription is active?

Jonathan: Both have an approved.  Want these to align between 2 documents -
he's only showing error cases where they don't align

Adam: There are 2 other states: Pending and Active.  These are whys for the
failures. 
Jonathan: Should the state machine be in sip-events.  Watcher -info defines
a model; you could have much more states and a more complex state machine.  

  - Elements in data format 
    * Watcherinfo data 
      - Uri of watcher 
      - Status of subscription 
      - Event which triggered notification 
      - Duration time in last state 
      - First-subscribed 
      - Most-recently subscribed 
      - Added: expiration 
      - Removed: Notify-address 
Chris: let's ditch most-recently subscribed, it's not very useful. 
Rosenberg: Okey-dokey. 
Rosenberg: The watcherinfo draft defines a model for presence. We 
shouldn't have this in sip-events. 
  - Status in winfo/sip events proposal on the list. 

Conclusion: No Comments (thus consensus implied) 
--------------------------------------- 
Guidelines for IM Sessions: 
  * Context: 
    - IM payloads are moving away from short-text only, towards 
      * Images 
      * Video clips 
      * Mp3 and other audio data 
      * Etc. 
      * Large populations of users meeting over shared infrastructure 
        (interconnect of AOL, MSN, etc). 
    - Sessions of Messages: 
      * SIP message is the medium. 
    - Transport Background 
      * In order of concern, reliable transport of serious amounts of 
        data raises concerns of: 
        - Congetion collapse 
          * Will congestion of the system invoke protocol actions that 
            increase data sent into the system? (1986 TCP collapse) 
        - Scope of fate-sharing 
          * Can desired end-to-end behavior and properties be achieved 
            and maintained through intermediaries? 
        - Congestion avoidance and shared effects 
          * When J users share a filled or congested path, and adapt, 
            can they get close to each having 1/Jth of capacity? 

Allison Mankin: We have to be that when we do congestion control that TCP 
adapts it's behavior to the congestion on the link. Want to be sure 
that there aren't unanticipated effects from the extremely large amount 
of traffic. 
  * Guidelines Draft 
    - Purpose is to distill transport concerns, with some related 
      architectural and security concerns. 
    - Session model 
      * When data of IM (or session of IM) is carried within headers 
        seen/modified /operated-on by intermediaries 
      * If you took the MESSAGE, without the headers, and threw it onto 
        an end-to-end TCP connection, it wouldn't create any of these
        issues. If you have UDP in the middle, you can run into 
        congestion problems. 
      * If IM clients stop off at the various intermediaries, they get 
        1/N*M bandwidth (N intermediaries, M IM clients) instead 
        of 1/M, which is a significant penalty. It's because of 
        the TCP queuing system. 

Rosenberg: This could happen for a lot of reasons. 
Allison: We don't want congestion collapse, but there are some other 
interesting things going on. 
Rosenberg: If we use TCP then this isn't our problem. 
Allison: No, the answer is that if you use TCP, don't get greedy 
with the number of intermediaries. 
Christian: There is a fundamental problem here, and it's with TCP. 
Allison: I think we still have some value to look into the transport 
dynamic, and moderate the use of intermediaries. Working on another 
paper to fully research this.  This scenario is a worst case. 

    - Multi-Intermediary protocols 
      * Diameter/Apex/Opes/SIP-SIMPLE 
    - Guidelines for Sessions 
      * Signaling MUST be able to negotiate a common underlying 
        transport 
      * MUST not use UDP because of congestion control issues. 
      * Session/transport solution SHOULD support (MUST?) specifying a 
        single transport protocol for entire session path. 
      * MUST not use multiple parallel reliable transport connections. 

David Oran: Why be so harsh, what's wrong with using UDP in a 
congestion safe way? 
Jon (summary): What we're talking about is that this is the session 
model, not setting up the session. 
Allison: Yes, this is a problem with long streams of data. 
   - Guidelines for Sessions 
     * Does design lead to a well-formed session protocol? 
       - Does the design carry the right data over aggregated 
         transport, session membership, data sequencing, 
         identification and so on? 
       - Is it designed right for the security goals? 
       - Draft-iab-opes-00.txt an RFC-t-be from IAB. 
       - Model for some more architectural guidelines: 
         * SHOULD not interpose without consent, by at least one of the 
           parties 
         * MUST support mechanism for discovery of intermediaries 
         * MUST disclose (either in signaling phase or session) the 
           intermediaries 
         * More... need to discuss in email. 

Rosenberg: The intermediaries are not there to modify the content. It's 
just there to deal with NATs, etc.  Such as in SIP. 
Allison: There is an area where the consent issue may be a bit gray. 
It's not a perfect match. 
Jon: I think we're trying to speak as to what the direction should be, 
not where intermediaries should be deployed. If the client is informed 
about what is going on, then it can take action. 
Henning: I would hesitate to draw too close a parallel on that, because 
there are properties in there that make the predictability issue a bit 
harder. There are issues with discovery and finding that we've had for 
some time. The other thing is that content modification (via headers, 
etc) doesn't necessarily match with the consent model in OPES. As long 
as these are transport entities that don't do much, then you can't 
extrapolate for OPES. 
Rosenberg: Why is this not such a problem for email? 
Allison: We're going to have to wrap up, we're running out of time. 
  * Next? 
    - End goal is for SIMPLE WG to internalize and feel ownership of 
      the guidelines 
    - Document should stay individual or be in the set of WG documents? 
Jon: we did make a good try at generalizing these issues. 
Wcom: I believe that the draft is bloated and it confuses signaling and 
transport, so let's get rid of it. 
Jon: That's unfair, we're responding to what this WG has already gotten 
itself into. 
IMPP WG chair: I don't think that this belongs in either working group. 
------------------------- 
IMTP Proposal: 
  * Motivations 
    - Requirements for IM transport 
      * Congest 
      * Reliable 
      * Arbitrary sizes 
      * Framing 
      * Per-im content typing 
      * E2e privacy, integrity, authenticity 
      * Works through nat 
      * Rapid delivery 
      * Lightweight 
      * Parser reuse 
      * Compressible 
      * Support for different content types 
      * Muxing 
      * Logging 
    - The hard configuration (PC in enterprise 1 going through a ent 1 
      proxy to internet, over to proxy in enterprise 2 to a PC in 
      enterprise 2). 
  * How about SIP? 
    - Pros: 
     * Parser reuse 
     * Proxies as intermediaries 
     * NAT traversal easy 
     * Logging, framing, sequencing all done 
    - Cons: 
     * SIP has features that would get in the way 
       - Record-routing 
       - Redirection 
       - Forking 
     * Messages might go over UDP 
     * Performance of Proxy as pure forwarding intermediary is poor. 
  * Idea: Sip Subset 
    - IMTP proper subset of SIP 
      * Remove unneeded features 
        - Forking, redirection, recursion, record-routing and route 
      * Introduce restrictions 
        - Only TCP 
      * Change protocol field to IMTP/1.0 from SIP/2.0 
        - Most proxies won't route 
        - BUT, one-liner to fix that 
        - Want this to be explicit about what protocol is running 
        - Proxy with proper configuration can route IMTP 
      * No forking, no record-routing, no redirect, TCP only 
      * Can use REGISTER to set up IMTP bindings 

Allison: How hard would it be to put in error checking so that if there 
were an inappropriate header were present it could be dealt with. 
Rosenberg: It is a minimal SIP request 
Mic: How do we specify IMTP? Where will this be done, where will 
discussion be held for this since it's a different transport protocol. 
Rosenberg: There will be a separate document for IMTP, and will go into 
this WG. It is burdensome to tie SIP and IMTP together, so let's not. 
Rosenberg: We're working on the end-to-end nature of the protocol to 
specify a key for the session to create an end-to-end solution. We can 
use that key into S/MIME so I can encrypt the content of the message 
path. 

Security:  working on SDP extensions for key exchange (MIKEY) (2 
pass)  Could use key as input to S/MIME to encrypt e2e.   Whatever 
solutions we develop for SIP would apply to IMTP. 

Andrew: What is our reaction? It's not obvious that there's not good 
engineering necessarily here, but this is what we need to do to get 
things done. 
Henry: What is the problem we're trying to solve? We have fast servers, 
we have bandwidth, so why is this a problem. 
Jonathan: Want a session model for SIP.  
Cullen: Can deal with IMTP being a profile in SIP.  Can't deal with 
divergences between the 2.  Should keep synced with SIP. 
Henning: As long as it's done by reference, then it's not as big of a 
problem. 
Rosenberg: It's not that clear, but it's not by reference. 
Dean: Either IMTP reduces to the argument against a session model or 
argues against using SIP how we're using it now.  Believes that if SIP 
as we've defined it doesn't scale then it's broke, but if it's not 
broke, then why can't it be used as is for the session MESSAGE problem.  
Rosenberg: SIP has the idea of finding the user, and the delivery of 
the content. The session model for SIP for SIP works by finding the 
user, then delivering the large data by another piece. SIP is good for 
the discovery problem and NOT good for the delivery of large data. 
Dean: I would argue that if we can't do signaling for call setup, then 
we can't do messaging, and vice versa. If you want to use a new 
protocol, why not use BEEP or another protocol? 

Rosenberg: Nobody has come forth. 
Rohan: I think we should make it so that it absolutely should not go 
through a proxy. 
David Oran: if there is anything to be gained by the MESSAGE method in 
the IMTP versus in SIP then let's converge them. I don't think it's a 
big deal with IMTP being renamed. If people think profiling is a 
reasonable way, then look at MEGACO.  Is there anything to be gained 
from the Message method in paging and the message method in session? 
People have said that it's easier. 
Dave Oran: Could you share a TCP connection with SIP? 
Jonathan: No, but you can share TCP between IMTP. 
Rosenberg: I am getting the feeling that it's not a good consensus. 
Christian: I like this proposal because it's easy to specify. Do we 
just have MESSAGE, nothing else, and enable us to do this? It's easy to 
implement, easy to undertand, etc. 
Henning: We have to solve this problem. 

Chairs consensus gathering: 

* Do we want to pursue this? Hum vote: 
  - Yes? Delayed hum.  
  - No? stronger hum. 

* Is the session model for messaging important? 
  - Yes?  Hum 
  - No? small hum. 

Rohan: Proposes that unless you get alternative proposals within a 
reasonable timeframe, that we should just go with this. 
Jon: We'll  send something out on the list, and if we don't get a 
response by the end of the holidays, we'll go with IMTP by default. 

Chairs consensus gathering: 

* If we are going to have a proposal for Sessions of messages, should 
they adhere to guidelines? 
  - Yes? Hum 
  - No? Equal hum 




From rsparks@dynamicsoft.com  Wed Jan  9 18:02:49 2002
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 SAA11419
	for ; Wed, 9 Jan 2002 18:02:49 -0500 (EST)
Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g09N0Pvw021205
	for ; Wed, 9 Jan 2002 18:00:28 -0500 (EST)
Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 9 Jan 2002 18:02:10 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E93E@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Wed, 9 Jan 2002 18:02:08 -0500 
X-Message-Flag: 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C19961.AAD8F45E"
Content-Length: 3527
Subject: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-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: 

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_01C19961.AAD8F45E
Content-Type: text/plain;
	charset="iso-8859-1"



-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: Tuesday, January 08, 2002 7:46 AM
Subject: I-D ACTION:draft-mrose-simple-exchange-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: IM Simple Exchange (IMSX)
	Author(s)	: M. Rose
	Filename	: draft-mrose-simple-exchange-00.txt
	Pages		: 27
	Date		: 07-Jan-02
	
The Common Presence and Instant Messaging profile (CPIM) is a set of
syntax and semantics for instant messaging (IM) and online presence
services, independent of the underlying transfer infrastructure.  The
Session Initiation Protocol (SIP) negotiates session information for
media streams.  This memo defines a BEEP profile, IMSX, for
exchanging CPIM messages after SIP has performed signalling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-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-mrose-simple-exchange-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-mrose-simple-exchange-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_01C19961.AAD8F45E
Content-Type: message/rfc822

To: 
Subject: 
Date: Wed, 9 Jan 2002 18:02:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C19961.AAD8F45E"


------_=_NextPart_002_01C19961.AAD8F45E
Content-Type: text/plain



------_=_NextPart_002_01C19961.AAD8F45E
Content-Type: application/octet-stream;
	name="ATT06680.txt"
Content-Disposition: attachment;
	filename="ATT06680.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020107135159.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mrose-simple-exchange-00.txt

------_=_NextPart_002_01C19961.AAD8F45E
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-mrose-simple-exchange-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"


------_=_NextPart_002_01C19961.AAD8F45E--

------_=_NextPart_000_01C19961.AAD8F45E--

From mrose+mtr.netnews@dbc.mtview.ca.us  Wed Jan  9 18:24:50 2002
Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11537
	for ; Wed, 9 Jan 2002 18:24:50 -0500 (EST)
Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged))
	by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g09NH9h08906
	for ; Wed, 9 Jan 2002 15:17:09 -0800 (PST)
Message-ID: <085b01c19964$be7d0c10$0301000a@FATORA>
From: "Marshall T. Rose" 
To: 
References: <9BF66EBF6BEFD942915B4D4D45C051F338E93E@DYN-TX-EXCH-001.dynamicsoft.com>
Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt
Date: Wed, 9 Jan 2002 15:24:09 -0800
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.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Length: 226
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: 

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-00.txt

if you prefer the html version, go to:

    http://www.beepcore.org/beepcore/docs/profile-imsx.html

enjoy!

/mtr



From jdrosen@dynamicsoft.com  Thu Jan 10 12:03:14 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14799
	for ; Thu, 10 Jan 2002 12:03:14 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.86])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0AH39VZ012062;
	Thu, 10 Jan 2002 12:03:10 -0500 (EST)
Message-ID: <3C3DC92C.6090902@dynamicsoft.com>
Date: Thu, 10 Jan 2002 12:02:36 -0500
From: Jonathan Rosenberg 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: jack@atosc.org
CC: simple@mailman.dynamicsoft.com
References: <3C3DAC3B.107B48CD@wellx.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1656
Subject: [Simple] Re: [Sip] simple-presence-04
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: 


Aymeric MOIZARD wrote:

> My question is about the tupple element in
> draft-ietf-simple-presence-04.txt
> (Is it the correct mailing list to use?)


The simple list is the right list. I've changed the recipient line.


> 
> The draft draft-ietf-simple-presence-04.txt shows examples
> of "application/cpim-pidf+xml" body where "name" is an
> attribute of "tuple".
> 
>      
>         
>           
>             open
>                          
> schema="http://www.ietf.org/dtd/im-type-phone.dtd">on-hook
>           
>           sip:user@example.com
>         
>       
> 
> I found that definition in draft-ietf-impp-cpim-pidf-01.txt
> where "id" is a mandatory attribute for tuple.
> 
> 
>               id   %TUPLEID;      #REQUIRED
> 
> 
> The example and defintions does not match!
> Did I choose wrong versions of drafts? Any other
> explanations?


The two docuemtns have been evolving idenpdently, and fall out of sync 
as they evolve. When the pidf spec is stable, we can make sure the 
presence doc formats are all up to date.

Thanks,
Jonathan R.




-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From rmahy@cisco.com  Thu Jan 10 14:39:34 2002
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15274
	for ; Thu, 10 Jan 2002 14:39:34 -0500 (EST)
Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0AJVPF25224;
	Thu, 10 Jan 2002 11:31:25 -0800 (PST)
Date: Thu, 10 Jan 2002 11:31:25 -0800 (PST)
From: Rohan Mahy 
To: "Marshall T. Rose" 
cc: 
Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt
In-Reply-To: <085b01c19964$be7d0c10$0301000a@FATORA>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2118
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: 

Hi Marshall,

I have a few suggestions and questions on your draft.

1) In the security considerations section you use MUST strength for both
DIGEST-MD5 and TLS_RSA_WITH_3DES_EDE_CBC_SHA.  I think requiring TLS and
3DES is too restrictive, especially for small devices or lightweight
implementations.  I propose using MUST strength for authentication
and integrity via DIGEST_MD5, and RECOMMENDED or SHOULD strength for
privacy and "all".

2) Please briefly (one sentence) mention the I: and L: convention before
you use it in the examples.

3a) You mention middleboxes briefly, but I wasn't sure what you are really
recommending when you say it may be needed for  "proxies to transparently
rewrite the transport information "   I assume you mean SIP proxies?
This is *AN* approach, but we won't be able to get to end-to-end integrity
if this is required, hence my next question...

3b) I am assuming that IMSX assumes that the two BEEP entities will
communicate directly without relays.  How would this work with a
couple of BEEP relays involved?  What address would you advertise in SDP?
If this is possible, I think this is very useful for getting around the
middlebox traversal problem.

4) I didn't get a good sense from your examples how to come up with
unique cid: URLs (especially if the originator is behind a NAT).
Do these have to be unique for all users/sessions, per BEEP session, or
per beep request?

5) I think an example or call-flow showing multiplexed bidirectional
messages would be really useful.

6) I'm assuming that the proposed transformation between im: and sip: URLs
is to merely replace the scheme.  Is this correct?

thanks,
-rohan



On Wed, 9 Jan 2002, Marshall T. Rose wrote:

> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-00.txt
>
> if you prefer the html version, go to:
>
>     http://www.beepcore.org/beepcore/docs/profile-imsx.html
>
> enjoy!
>
> /mtr
>
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From mrose+internet.ietf.simple@dbc.mtview.ca.us  Thu Jan 10 19:27:58 2002
Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16155
	for ; Thu, 10 Jan 2002 19:27:58 -0500 (EST)
Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged))
	by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g0B0K8500929;
	Thu, 10 Jan 2002 16:20:08 -0800 (PST)
Message-ID: <011001c19a36$ba29fd30$0301000a@FATORA>
From: "Marshall T. Rose" 
To: "Rohan Mahy" 
Cc: , "Marshall Rose" 
References: 
Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt
Date: Thu, 10 Jan 2002 16:27:17 -0800
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.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Length: 3520
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: 

> 1) In the security considerations section you use MUST strength for both
> DIGEST-MD5 and TLS_RSA_WITH_3DES_EDE_CBC_SHA.  I think requiring TLS and
> 3DES is too restrictive, especially for small devices or lightweight
> implementations.  I propose using MUST strength for authentication
> and integrity via DIGEST_MD5, and RECOMMENDED or SHOULD strength for
> privacy and "all".

the particular wording you see, and the particular technologises list
reflect what the IESG is letting go through these days. in other words,
they've been returning drafts to working groups and individual submissions,
asking for language with these choices.

it is important to appreciate the distinction between what gets implemented
and what gets provisioned. the requirement is that tls be available in
implementations, not that it has to be used by administrators.

implementors are free to sell products with other technologies.
administrators are free to configure or not whatever comes with the
software.

so what all this means is that administrators responsible for people with
small devices won't turn privacy on. that's okay. what's important is that,
two administrators agreeing to use privacy know that there will be at least
one choice available, tls, regardless of what products they're using. they
can then make a reasoned cost-benefit analysis as to what gets provisioned.


> 2) Please briefly (one sentence) mention the I: and L: convention before
> you use it in the examples.

ok.


> 3a) You mention middleboxes briefly, but I wasn't sure what you are really
> recommending when you say it may be needed for  "proxies to transparently
> rewrite the transport information "   I assume you mean SIP proxies?
> This is *AN* approach, but we won't be able to get to end-to-end integrity
> if this is required, hence my next question...

>
> 3b) I am assuming that IMSX assumes that the two BEEP entities will
> communicate directly without relays.  How would this work with a
> couple of BEEP relays involved?  What address would you advertise in SDP?
> If this is possible, I think this is very useful for getting around the
> middlebox traversal problem.

i don't think the text could be any clearer: the IMSX peers have no interest
in the network topology. the SIP infrastructure is responsible for ensuring
end-to-end usability of the transport information. if middleboxes are
involved, then the SIP infrastructure will have to deal with this. the
problem is no different for any other application protocol making use of the
SIP infrastructure.

there is no explicit relaying model. if you want that, this is the wrong
architecture. if you want to solve the middlebox problem, this is the wrong
working group.


> 4) I didn't get a good sense from your examples how to come up with
> unique cid: URLs (especially if the originator is behind a NAT).
> Do these have to be unique for all users/sessions, per BEEP session, or
> per beep request?

i think the email folks solved this problem long ago. generating a unique
url is trivial, particularly, since it is used to refer only to data
contained within the message...


> 5) I think an example or call-flow showing multiplexed bidirectional
> messages would be really useful.

well, there are lots of call-flow diagrams in the sip document, to pick one
and i guess i can copy it...


> 6) I'm assuming that the proposed transformation between im: and sip: URLs
> is to merely replace the scheme.  Is this correct?

that's really for the group to decide...

/mtr



From rmahy@cisco.com  Thu Jan 10 21:09:23 2002
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16474
	for ; Thu, 10 Jan 2002 21:09:23 -0500 (EST)
Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0B28gF23956;
	Thu, 10 Jan 2002 18:08:42 -0800 (PST)
Date: Thu, 10 Jan 2002 18:08:42 -0800 (PST)
From: Rohan Mahy 
To: "Marshall T. Rose" 
cc: , Marshall Rose 
Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt
In-Reply-To: <011001c19a36$ba29fd30$0301000a@FATORA>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 4575
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: 

Hi Marshall,

Thanks for the quick response.  A few more comments inline...

On Thu, 10 Jan 2002, Marshall T. Rose wrote:

> > 1) In the security considerations section you use MUST strength for both
> > DIGEST-MD5 and TLS_RSA_WITH_3DES_EDE_CBC_SHA.  I think requiring TLS and
> > 3DES is too restrictive, especially for small devices or lightweight
> > implementations.  I propose using MUST strength for authentication
> > and integrity via DIGEST_MD5, and RECOMMENDED or SHOULD strength for
> > privacy and "all".
>
> the particular wording you see, and the particular technologises list
> reflect what the IESG is letting go through these days. in other words,
> they've been returning drafts to working groups and individual submissions,
> asking for language with these choices.
>
> it is important to appreciate the distinction between what gets implemented
> and what gets provisioned. the requirement is that tls be available in
> implementations, not that it has to be used by administrators.

the problem is that some lightweight SIP implementations (e.g phones) will
be unable to implement BEEP and TLS and RSA and 3DES.  this is not an
administrator level problem, it is an implementation burden.

if I haven't convinced you, then I will talk to the appropriate AD.  This
shouldn't be your problem.

> implementors are free to sell products with other technologies.
> administrators are free to configure or not whatever comes with the
> software.
>
> so what all this means is that administrators responsible for people with
> small devices won't turn privacy on. that's okay. what's important is that,
> two administrators agreeing to use privacy know that there will be at least
> one choice available, tls, regardless of what products they're using. they
> can then make a reasoned cost-benefit analysis as to what gets provisioned.
>
>
> > 2) Please briefly (one sentence) mention the I: and L: convention before
> > you use it in the examples.
>
> ok.
>
>
> > 3a) You mention middleboxes briefly, but I wasn't sure what you are really
> > recommending when you say it may be needed for  "proxies to transparently
> > rewrite the transport information "   I assume you mean SIP proxies?
> > This is *AN* approach, but we won't be able to get to end-to-end integrity
> > if this is required, hence my next question...
>
> >
> > 3b) I am assuming that IMSX assumes that the two BEEP entities will
> > communicate directly without relays.  How would this work with a
> > couple of BEEP relays involved?  What address would you advertise in SDP?
> > If this is possible, I think this is very useful for getting around the
> > middlebox traversal problem.
>
> i don't think the text could be any clearer: the IMSX peers have no interest
> in the network topology. the SIP infrastructure is responsible for ensuring
> end-to-end usability of the transport information. if middleboxes are
> involved, then the SIP infrastructure will have to deal with this. the
> problem is no different for any other application protocol making use of the
> SIP infrastructure.

How about:

"Note that with the introduction of middleboxes [7], such as firewalls and
network address translators, IMSX peers are responsible for using
transport addresses which are usable end-to-end by their peers, or sending
SIP through proxies or other entities which rewrite these addresses as
appropriate to allow end-to-end communication."   ??

> there is no explicit relaying model. if you want that, this is the wrong
> architecture. if you want to solve the middlebox problem, this is the wrong
> working group.

sorry, I was thinking of APEX.

> > 4) I didn't get a good sense from your examples how to come up with
> > unique cid: URLs (especially if the originator is behind a NAT).
> > Do these have to be unique for all users/sessions, per BEEP session, or
> > per beep request?
>
> i think the email folks solved this problem long ago. generating a unique
> url is trivial, particularly, since it is used to refer only to data
> contained within the message...

ok, you may want to mention that the url is unique only within the
message.

thanks again,
-rohan

>
> > 5) I think an example or call-flow showing multiplexed bidirectional
> > messages would be really useful.
>
> well, there are lots of call-flow diagrams in the sip document, to pick one
> and i guess i can copy it...
>
>
> > 6) I'm assuming that the proposed transformation between im: and sip: URLs
> > is to merely replace the scheme.  Is this correct?
>
> that's really for the group to decide...
>
> /mtr
>
>
>


From petkos@diamond.cs.columbia.edu  Fri Jan 11 13:25:16 2002
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 NAA19395
	for ; Fri, 11 Jan 2002 13:25:16 -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 NAA02201
	for ; Fri, 11 Jan 2002 13:24:41 -0500 (EST)
Received: from diamond.cs.columbia.edu (localhost [127.0.0.1])
	by diamond.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0BIOeAT026081
	for ; Fri, 11 Jan 2002 13:24:40 -0500 (EST)
Received: (from petkos@localhost)
	by diamond.cs.columbia.edu (8.12.1/8.12.1/Submit) id g0BIOeEv026080
	for simple@mailman.dynamicsoft.com; Fri, 11 Jan 2002 13:24:40 -0500 (EST)
From: "Petri K. Koskelainen" 
Message-Id: <200201111824.g0BIOeEv026080@diamond.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Fri, 11 Jan 2002 13:24:40 -0500 (EST)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 598
Subject: [Simple] IMTP Extensions draft available
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: 

Hi,


New IMTP-related draft is now available:
http://www.ietf.org/internet-drafts/draft-koskelainen-imtpext-00.txt

"IMTP extensions for message threading"

Abstract

The IMTP specification defines a session-based IM transport
as well as the message format for it. However, it does not support  
message threads or discussion topics which are useful in 
applications such as multi-party chat. This document defines 
extensions to IMTP which allow applications to utilize threads 
and sub-threads within an IMTP message session. Also, the 
extensions enable message identification.



BR,
--
Petri

From mrose+mtr.netnews@dbc.mtview.ca.us  Fri Jan 11 12:28:03 2002
Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19212
	for ; Fri, 11 Jan 2002 12:28:02 -0500 (EST)
Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged))
	by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g0BHK7504606;
	Fri, 11 Jan 2002 09:20:07 -0800 (PST)
Message-ID: <04c701c19ac5$39ab5890$0301000a@FATORA>
From: "Marshall T. Rose" 
To: "Rohan Mahy" 
Cc: 
References: 
Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt
Date: Fri, 11 Jan 2002 09:27:20 -0800
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.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Length: 1984
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: 

> > it is important to appreciate the distinction between what gets
implemented
> > and what gets provisioned. the requirement is that tls be available in
> > implementations, not that it has to be used by administrators.
>
> the problem is that some lightweight SIP implementations (e.g phones) will
> be unable to implement BEEP and TLS and RSA and 3DES.  this is not an
> administrator level problem, it is an implementation burden.
>
> if I haven't convinced you, then I will talk to the appropriate AD.  This
> shouldn't be your problem.

sure.


> How about:
>
> "Note that with the introduction of middleboxes [7], such as firewalls and
> network address translators, IMSX peers are responsible for using
> transport addresses which are usable end-to-end by their peers, or sending
> SIP through proxies or other entities which rewrite these addresses as
> appropriate to allow end-to-end communication."   ??

i don't think this works because of the "IMSX peers are responsible" part.
this implies some kind of topology-specific behavior on the part of IMSX,
which isn't there. IMSX doesn't know, nor care, about topology. that's
someone else's job... the requirement on the part of IMSX is stated in the
previous paragraph, to wit:

    As with any model based on dynamic rendezvous,
    it is critically important that each application faithfully record the
    appropriate transport information in the corresponding SDP
    announcement.


> > > 4) I didn't get a good sense from your examples how to come up with
> > > unique cid: URLs (especially if the originator is behind a NAT).
> > > Do these have to be unique for all users/sessions, per BEEP session,
or
> > > per beep request?
> >
> > i think the email folks solved this problem long ago. generating a
unique
> > url is trivial, particularly, since it is used to refer only to data
> > contained within the message...
>
> ok, you may want to mention that the url is unique only within the
> message.

ok.

/mtr



From rmahy@cisco.com  Fri Jan 11 15:26:10 2002
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19783
	for ; Fri, 11 Jan 2002 15:26:10 -0500 (EST)
Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0BKPTF14729;
	Fri, 11 Jan 2002 12:25:29 -0800 (PST)
Date: Fri, 11 Jan 2002 12:25:29 -0800 (PST)
From: Rohan Mahy 
To: "Marshall T. Rose" 
cc: 
Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt
In-Reply-To: <04c701c19ac5$39ab5890$0301000a@FATORA>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1674
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: 


On Fri, 11 Jan 2002, Marshall T. Rose wrote:
[snip]
> > How about:
> >
> > "Note that with the introduction of middleboxes [7], such as firewalls and
> > network address translators, IMSX peers are responsible for using
> > transport addresses which are usable end-to-end by their peers, or sending
> > SIP through proxies or other entities which rewrite these addresses as
> > appropriate to allow end-to-end communication."   ??
>
> i don't think this works because of the "IMSX peers are responsible" part.
> this implies some kind of topology-specific behavior on the part of IMSX,
> which isn't there. IMSX doesn't know, nor care, about topology. that's
> someone else's job... the requirement on the part of IMSX is stated in the
> previous paragraph, to wit:
>
>     As with any model based on dynamic rendezvous,
>     it is critically important that each application faithfully record the
>     appropriate transport information in the corresponding SDP
>     announcement.

One of the ways that we are getting SIP intiated media through middleboxes
is to have the SIP UA "lie" about its address.  A SIP UA might use STUN to
get public addresses for RTP and RTCP media, or TURN to establish use of a
media relay.  What I meant by IMSX peer was the host that IMSX runs
on.  An alternate rewording would be "SIP User Agents implementing
IMSX are responsible..."   This is an alternative to the requirement
for a proxy to do rewriting.  Some relevant pointers to this method of
middlebox traversal are below.

draft-rosenberg-midcom-stun-00.txt
draft-rosenberg-midcom-turn-00.txt
draft-rosenberg-sipping-nat-scenarios-00.txt

hope this makes sense.
thanks,
-rohan



From mrose+internet.ietf.simple@dbc.mtview.ca.us  Fri Jan 11 19:17:18 2002
Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20543
	for ; Fri, 11 Jan 2002 19:17:17 -0500 (EST)
Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged))
	by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g0C09M505745;
	Fri, 11 Jan 2002 16:09:22 -0800 (PST)
Message-ID: <066c01c19afe$66498730$0301000a@FATORA>
From: "Marshall T. Rose" 
To: "Rohan Mahy" 
Cc: , "Marshall Rose" 
References: 
Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt
Date: Fri, 11 Jan 2002 16:16:36 -0800
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.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Length: 1337
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: 

> One of the ways that we are getting SIP intiated media through middleboxes
> is to have the SIP UA "lie" about its address.  A SIP UA might use STUN to
> get public addresses for RTP and RTCP media, or TURN to establish use of a
> media relay.  What I meant by IMSX peer was the host that IMSX runs
> on.  An alternate rewording would be "SIP User Agents implementing
> IMSX are responsible..."   This is an alternative to the requirement
> for a proxy to do rewriting.  Some relevant pointers to this method of
> middlebox traversal are below.
>
> draft-rosenberg-midcom-stun-00.txt
> draft-rosenberg-midcom-turn-00.txt
> draft-rosenberg-sipping-nat-scenarios-00.txt
>
> hope this makes sense.

yes, it makes sense, i just question whether it belongs in imsx. how about
this text:

   Note that with the introduction of middleboxes [7], such as firewalls
   and network address translators, it may be necessary to rewrite the
   transport information in order to account for administratively-
   mandated media gateways or address translation.  Accordingly, SIP
   user agents are responsible for either directly rewriting the
   transport information, or, sending the SDP announcement through the
   appropriate intermediaries that will transparently rewrite the
   transport information.  In a phrase, "res ipsa loquitur".

/mtr



From rmahy@cisco.com  Fri Jan 11 19:19:07 2002
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20569
	for ; Fri, 11 Jan 2002 19:19:07 -0500 (EST)
Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0C0IRF11485;
	Fri, 11 Jan 2002 16:18:27 -0800 (PST)
Date: Fri, 11 Jan 2002 16:18:27 -0800 (PST)
From: Rohan Mahy 
To: "Marshall T. Rose" 
cc: , Marshall Rose 
Subject: Re: [Simple] FW: I-D ACTION:draft-mrose-simple-exchange-00.txt
In-Reply-To: <066c01c19afe$66498730$0301000a@FATORA>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1468
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: 


On Fri, 11 Jan 2002, Marshall T. Rose wrote:

>
> > One of the ways that we are getting SIP intiated media through middleboxes
> > is to have the SIP UA "lie" about its address.  A SIP UA might use STUN to
> > get public addresses for RTP and RTCP media, or TURN to establish use of a
> > media relay.  What I meant by IMSX peer was the host that IMSX runs
> > on.  An alternate rewording would be "SIP User Agents implementing
> > IMSX are responsible..."   This is an alternative to the requirement
> > for a proxy to do rewriting.  Some relevant pointers to this method of
> > middlebox traversal are below.
> >
> > draft-rosenberg-midcom-stun-00.txt
> > draft-rosenberg-midcom-turn-00.txt
> > draft-rosenberg-sipping-nat-scenarios-00.txt
> >
> > hope this makes sense.
>
> yes, it makes sense, i just question whether it belongs in imsx. how about
> this text:
>
>    Note that with the introduction of middleboxes [7], such as firewalls
>    and network address translators, it may be necessary to rewrite the
>    transport information in order to account for administratively-
>    mandated media gateways or address translation.  Accordingly, SIP
>    user agents are responsible for either directly rewriting the
>    transport information, or, sending the SDP announcement through the
>    appropriate intermediaries that will transparently rewrite the
>    transport information.  In a phrase, "res ipsa loquitur".
>
> /mtr

sounds good.

thanks,
-rohan


From tanglihua2043@hotmail.com  Tue Jan 22 22:53:07 2002
Received: from hotmail.com (f132.law14.hotmail.com [64.4.21.132])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07801
	for ; Tue, 22 Jan 2002 22:53:06 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 22 Jan 2002 19:52:30 -0800
Received: from 195.212.29.120 by lw14fd.law14.hotmail.msn.com with HTTP;
	Wed, 23 Jan 2002 03:52:29 GMT
X-Originating-IP: [195.212.29.120]
From: "Tang Lihua" 
To: simple@mailman.dynamicsoft.com
Date: Wed, 23 Jan 2002 11:52:29 +0800
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: 
X-OriginalArrivalTime: 23 Jan 2002 03:52:30.0273 (UTC) FILETIME=[617DBB10:01C1A3C1]
Content-Length: 1541
Subject: [Simple] Somes questions about behavior of PS
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: 

Hi,guys

I want to clarify the behaviour of PS. My questions are as follows: 

About Registrar
1. How to upload buddylist or watcherlist to PS? Through registration or 
other way? If a buddylist is stored in PS, should PS automaticly send out 
subscription to each buddy on the list? And it's strange that in this case 
a watcher will receive notifications but no subscription is sent out by the 
watcher itself. Also another problem is that it will burden PS with 
handling all the buddylists or watcherlists. 
2. If a user gets unregistered, remove this user from database or just mark 
it as 'Unregistered'?
How can the PS know an offline presentity is a once registered user? Is 
User Managerment a need? 
 
About Authentication
1. Is the authentication in PS a server-side(as proxy) or a ua-side one(as 
PA) one? If a subscription is sent to an offline presentity, should the PS 
challenge the subscriber?
2. Should the PS maintain access password lists of each presentity for each 
possible watcher? Is there a better way for PS to authorize the watcher?
2. Draft says, 'For pending subscriptions, the state of the presentity 
SHOULD include some kind of textual note that indicates a pending status.' 
Is there any solution to it till now? More, how can the PS notify the 
watcher that a buddy is offline now or a buddy gets online?

Thanks for your comments!

Best regards,

Tang Lihua

_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄ Web µç×ÓÓʼþϵͳ ¡ª¡ª MSN Hotmail¡£
http://www.hotmail.com/cn


From ghoshn@cwc.nus.edu.sg  Thu Jan 24 00:38:46 2002
Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12432
	for ; Thu, 24 Jan 2002 00:38:41 -0500 (EST)
Received: from cwc.nus.edu.sg ([172.16.2.230])
	by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id NAA08505
	for ; Thu, 24 Jan 2002 13:36:37 +0800 (SGT)
Message-ID: <3C4F9F4D.1040101@cwc.nus.edu.sg>
Date: Thu, 24 Jan 2002 13:44:45 +0800
From: Nirmalya Ghosh 
Organization: Centre for Wireless Communications, Singapore
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 425
Subject: [Simple] Call-ID & CSeq changes in MESSAGE requests
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: 

Hi All,
I have been reading through the draft on Sip Extensions for Instant 
Messaging (simple-im-01) and I have a doubt regarding the change of 
Call-ID & CSeq headers. Since MESSAGE requests do not create an implied 
session (implying no call-leg, or call-state), does this mean that the 
Call-leg keeps changing and the CSeq MAY remain the same in subsequent 
MESSAGE requests, or vice versa?

Thanks & Regards,
Nirmalya


From jdrosen@dynamicsoft.com  Thu Jan 24 10:23:50 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14194
	for ; Thu, 24 Jan 2002 10:23:50 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.88])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OFNTGe029372;
	Thu, 24 Jan 2002 10:23:39 -0500 (EST)
Message-ID: <3C5026CB.E1C4F40F@dynamicsoft.com>
Date: Thu, 24 Jan 2002 10:22:51 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Nirmalya Ghosh 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Call-ID & CSeq changes in MESSAGE requests
References: <3C4F9F4D.1040101@cwc.nus.edu.sg>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 982
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: 


Nirmalya Ghosh wrote:
> 
> Hi All,
> I have been reading through the draft on Sip Extensions for Instant
> Messaging (simple-im-01) and I have a doubt regarding the change of
> Call-ID & CSeq headers. Since MESSAGE requests do not create an implied
> session (implying no call-leg, or call-state), does this mean that the
> Call-leg keeps changing and the CSeq MAY remain the same in subsequent
> MESSAGE requests, or vice versa?

Yes, the Call-ID will change in each subsequent message. Furthermore,
since CSeq is defined within the space of a call leg, the value of the
CSeq header in each message are really independent and unrelated.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From montarou@inrs-telecom.uquebec.ca  Tue Jan 29 13:25:51 2002
Received: from ozias.inrs-telecom.uquebec.ca (ozias.inrs-telecom.uquebec.ca [192.26.211.164])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06196
	for ; Tue, 29 Jan 2002 13:25:46 -0500 (EST)
Received: from paloverde.INRS-Telecom.UQuebec.CA (paloverde [192.26.211.111])
	by ozias.inrs-telecom.uquebec.ca (8.11.3/8.11.3) with ESMTP id g0TIP3b01821
	for ; Tue, 29 Jan 2002 13:25:03 -0500 (EST)
Received: from inrs-telecom.uquebec.ca by paloverde.INRS-Telecom.UQuebec.CA (8.9.3+Sun/SMI-SVR4)
	id NAA16834; Tue, 29 Jan 2002 13:25:03 -0500 (EST)
Message-ID: <3C56E8FF.2CCAB19B@inrs-telecom.uquebec.ca>
Date: Tue, 29 Jan 2002 13:25:03 -0500
From: =?iso-8859-1?Q?H=E9l=E8ne?= Montarou 
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: multipart/mixed;
 boundary="------------EA092FC0C53693519E1A26AE"
Content-Length: 8651
Subject: [Simple] Misunderstanding of Presence Service with SIP
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: 

This is a multi-part message in MIME format.
--------------EA092FC0C53693519E1A26AE
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Dear Sir,

 I am studying SIP and the presence service.
 There is some points I misunderstand concerning the model proposed in
 RFC 2778 and the analogy between PUA's addresses and
 presentities'addresses.

 A. Concerning the model :

 So, if I understand well:
 - A principal can manipulate zero or more presentities,
 - A principal interacts with the system via one or several user agents
 so one or several Presence User Agent (PUA),
 - A PUA can not have several presentities due to an addressing problem
 but several PUAs can send their presence information to the same
 presentity.

 Finally, the configuration in the document attached (configuration.ps)
are allowed.

  Is it correct from now?

 - We supposed all the entities are colocalised.
 In the second case, PUAs share the same address so that the presentity
 can be reach via this same address, is not it ??
 In this case, we could say that the address identify uniquely the
 principal.
 In the first case, presentities have different addresses. Only PUAs of
 the Principal can be identify uniquely through presentities. A watcher
 which would like to know the principal presence information (state of
 all devices and services on devices of this principal) has to know the
 PUAs ' presentities addresses, is not it ??
 As an example , PUAs could be different programs/applications.. so
 services on the same computer like email, phone, conference.. etc.. is
 that correct ?   could you give me some more example ?

 -  When PUAs and presentities are delocalised, they can have different
 addresses.
 If we consider both configuration above, how is it possible to identify

 a PUA uniquely for a watcher ? and principal uniquely ?
 What should be the presentity address in particular in the second case
?

 As an example, PUAs could be programs/applications/several devices
 (mobile phone, fixe phone and PC ) with three different addresses. For
 this example, is the second configuration still allowed?

 B.  Concerning the CPIM format:

 - The presence information contained  in a tuple concern a PUA.
 - A list of tuples for the same presentity means that several PUAs send

 information at the same presentity.

 Is it correct ?

 Here the example from the Internet Draft "CPIM Presence Information
Data
 Format":

  
      
         
             
                 OPEN
                 BUSY
                 HOME
              
              im:shingo@mobilecarrier.ne.jp
              Don't Disturb Please!
              2001-10-27T16:49:29Z
         
         
             
             OPEN
             
            mailto:shingo@jp.fujitsu.com

         
         I'll be in Tokyo tomorrow
   

 Could you explain it in terms of Principal, PUA, Presentity, devices,
services and
 addresses ?

 Waiting for your answer, I thank you very much in advance.
 This would help me a lot in my understanding of SIP and presence.

 Regards,

Hélène Montarou.

 ----------------------------------------------
 INRS-Télécommunications
 Place Bonaventure
  900, de la Gauchetière Ouest
 Niveau C, Case Postale 644
 Montréal, QC
 H5A 1C6 Canada

  ----------------------------------------------

--------------EA092FC0C53693519E1A26AE
Content-Type: application/postscript;
 name="configuration.ps"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="configuration.ps"

%!PS-Adobe-2.0 EPSF-2.0
%%Title: configurations.fig
%%Creator: fig2dev Version 3.1 Patchlevel 2
%%CreationDate: Mon Jan 28 13:20:51 2002
%%For: montarou@paloverde (Helene Montarou)
%Magnification: 1.00
%%Orientation: Portrait
%%BoundingBox: 0 0 285 243
%%Pages: 0
%%BeginSetup
%%IncludeFeature: *PageSize A4
%%EndSetup
%%EndComments
/$F2psDict 200 dict def
$F2psDict begin
$F2psDict /mtrx matrix put
/col-1 {0 setgray} bind def
/col0 {0.000 0.000 0.000 srgb} bind def
/col1 {0.000 0.000 1.000 srgb} bind def
/col2 {0.000 1.000 0.000 srgb} bind def
/col3 {0.000 1.000 1.000 srgb} bind def
/col4 {1.000 0.000 0.000 srgb} bind def
/col5 {1.000 0.000 1.000 srgb} bind def
/col6 {1.000 1.000 0.000 srgb} bind def
/col7 {1.000 1.000 1.000 srgb} bind def
/col8 {0.000 0.000 0.560 srgb} bind def
/col9 {0.000 0.000 0.690 srgb} bind def
/col10 {0.000 0.000 0.820 srgb} bind def
/col11 {0.530 0.810 1.000 srgb} bind def
/col12 {0.000 0.560 0.000 srgb} bind def
/col13 {0.000 0.690 0.000 srgb} bind def
/col14 {0.000 0.820 0.000 srgb} bind def
/col15 {0.000 0.560 0.560 srgb} bind def
/col16 {0.000 0.690 0.690 srgb} bind def
/col17 {0.000 0.820 0.820 srgb} bind def
/col18 {0.560 0.000 0.000 srgb} bind def
/col19 {0.690 0.000 0.000 srgb} bind def
/col20 {0.820 0.000 0.000 srgb} bind def
/col21 {0.560 0.000 0.560 srgb} bind def
/col22 {0.690 0.000 0.690 srgb} bind def
/col23 {0.820 0.000 0.820 srgb} bind def
/col24 {0.500 0.190 0.000 srgb} bind def
/col25 {0.630 0.250 0.000 srgb} bind def
/col26 {0.750 0.380 0.000 srgb} bind def
/col27 {1.000 0.500 0.500 srgb} bind def
/col28 {1.000 0.630 0.630 srgb} bind def
/col29 {1.000 0.750 0.750 srgb} bind def
/col30 {1.000 0.880 0.880 srgb} bind def
/col31 {1.000 0.840 0.000 srgb} bind def

end
save
-90.0 290.0 translate
1 -1 scale

/cp {closepath} bind def
/ef {eofill} bind def
/gr {grestore} bind def
/gs {gsave} bind def
/sa {save} bind def
/rs {restore} bind def
/l {lineto} bind def
/m {moveto} bind def
/rm {rmoveto} bind def
/n {newpath} bind def
/s {stroke} bind def
/sh {show} bind def
/slc {setlinecap} bind def
/slj {setlinejoin} bind def
/slw {setlinewidth} bind def
/srgb {setrgbcolor} bind def
/rot {rotate} bind def
/sc {scale} bind def
/sd {setdash} bind def
/ff {findfont} bind def
/sf {setfont} bind def
/scf {scalefont} bind def
/sw {stringwidth} bind def
/tr {translate} bind def
/tnt {dup dup currentrgbcolor
  4 -2 roll dup 1 exch sub 3 -1 roll mul add
  4 -2 roll dup 1 exch sub 3 -1 roll mul add
  4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
  bind def
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
  4 -2 roll mul srgb} bind def
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
/$F2psEnd {$F2psEnteredState restore end} def
%%EndProlog

$F2psBegin
10 setmiterlimit
n 0 842 m 0 0 l 595 0 l 595 842 l cp clip
 0.06000 0.06000 sc
7.500 slw
% Polyline
n 3075 1800 m 3600 1800 l gs col-1 s gr 
% Polyline
n 3075 1725 m 3600 1275 l gs col-1 s gr 
% Polyline
n 3075 1875 m 3600 2325 l gs col-1 s gr 
% Polyline
n 4200 1200 m 4650 1200 l gs col-1 s gr 
% Polyline
n 4200 1800 m 4650 1800 l gs col-1 s gr 
% Polyline
n 4200 2400 m 4650 2400 l gs col-1 s gr 
% Polyline
n 3075 4200 m 3600 4200 l gs col-1 s gr 
% Polyline
n 3059 4294 m 3584 4744 l gs col-1 s gr 
% Polyline
n 3059 4106 m 3584 3656 l gs col-1 s gr 
% Polyline
n 4211 3663 m 4736 4113 l gs col-1 s gr 
% Polyline
n 4200 4200 m 4725 4200 l gs col-1 s gr 
% Polyline
n 4179 4775 m 4704 4325 l gs col-1 s gr 
/Times-Roman ff 180.00 scf sf
1500 900 m
gs 1 -1 sc (1. ) col-1 sh gr
/Times-Roman ff 180.00 scf sf
2100 1875 m
gs 1 -1 sc (Principal \(x\) ) col-1 sh gr
/Times-Roman ff 180.00 scf sf
3750 1800 m
gs 1 -1 sc (PUA) col-1 sh gr
/Times-Roman ff 180.00 scf sf
3750 2400 m
gs 1 -1 sc (PUA) col-1 sh gr
/Times-Roman ff 180.00 scf sf
3750 1275 m
gs 1 -1 sc (PUA) col-1 sh gr
/Times-Roman ff 180.00 scf sf
4800 1200 m
gs 1 -1 sc (Presentity \(@PUA\)) col-1 sh gr
/Times-Roman ff 180.00 scf sf
4800 1800 m
gs 1 -1 sc (Presentity \(@PUA\)) col-1 sh gr
/Times-Roman ff 180.00 scf sf
4800 2400 m
gs 1 -1 sc (Presentity \(@PUA\)) col-1 sh gr
/Times-Roman ff 180.00 scf sf
1500 3300 m
gs 1 -1 sc (.2.) col-1 sh gr
/Times-Roman ff 180.00 scf sf
2100 4200 m
gs 1 -1 sc (Principal \(x\) ) col-1 sh gr
/Times-Roman ff 180.00 scf sf
3750 3675 m
gs 1 -1 sc (PUA) col-1 sh gr
/Times-Roman ff 180.00 scf sf
3750 4275 m
gs 1 -1 sc (PUA) col-1 sh gr
/Times-Roman ff 180.00 scf sf
3750 4800 m
gs 1 -1 sc (PUA) col-1 sh gr
/Times-Roman ff 180.00 scf sf
4875 4200 m
gs 1 -1 sc (Presentity \(@ ?? \)) col-1 sh gr
$F2psEnd
rs

--------------EA092FC0C53693519E1A26AE--


From ndramais@indigosw.com  Fri Feb  1 10:52:46 2002
Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA21678
	for ; Fri, 1 Feb 2002 10:52:45 -0500 (EST)
Received: (qmail 2852 invoked by alias); 1 Feb 2002 15:52:20 -0000
Received: from unknown (HELO indigosw.com) (194.78.202.25)
  by 0 with SMTP; 1 Feb 2002 15:52:20 -0000
Message-ID: <3C5AB9A2.9090002@indigosw.com>
Date: Fri, 01 Feb 2002 16:52:02 +0100
From: Nicolas Dramais 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: SIMPLE list 
CC: "'Rosen, Brian'" ,
        "'Sean Olson (EUS)'" ,
        "'Vencour Marcel'" ,
        Jonathan Rosenberg ,
        Mayerhofer Andreas A 
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1181
Subject: [Simple] Mobility of Buddy List, Again
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: 

Hi all,

I would like to know what the status is now with mobility of buddy 
lists. I'm referring to the thread created on this topic in June 2001.
I agree that draft-rosenberg-impp-buddylist-00.txt addresses one piece 
of the puzzle (even though it has expired now), being the storage and 
retrieval of buddy lists to and from a presence server. However, in 
order to have my presence server doing the dirty work of subscribing to 
each individual entry in my buddy list on my behalf, yet another piece 
is missing : some sort of composite Notify bringing back to the watcher 
presence statuses of all individual entries in my list residing at the 
server.

Is there enough interest on this list to re-activate the above buddylist 
draft as a SIMPLE work item ?
Is there enough interest on this list to define and standardize this 
composite Notify ?

Or is there a consensus that this puzzle is more an implementation matter ?

Thanks,
Nicolas.

-- 
Nicolas DRAMAIS
Indigo Software
"We join the dots"
~~~~~~~~~~~~~~~~~~~~~~
50, rue Wiertz
1050 Brussels
Belgium
Phone: +3222350952
Fax: +3222802676
mailto:ndramais@indigosw.com
~~~~~~~~~~~~~~~~~~~~~~
http://www.indigosw.com







From ghoshn@cwc.nus.edu.sg  Sat Feb  2 22:53:38 2002
Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28149
	for ; Sat, 2 Feb 2002 22:53:35 -0500 (EST)
Received: from cwc.nus.edu.sg ([172.16.3.114])
	by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id LAA28605
	for ; Sun, 3 Feb 2002 11:51:43 +0800 (SGT)
Message-ID: <3C5CB5C4.5070505@cwc.nus.edu.sg>
Date: Sun, 03 Feb 2002 12:00:04 +0800
From: Nirmalya Ghosh 
Organization: Centre for Wireless Communications, Singapore
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1015
Subject: [Simple] How does a Presence Server (acting as a PA) get to know of new users registrations at the proxy/registrar?
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: 

Hi All,
I am just wondering how would a Presence Server (PS) acting as a
Presence Agent (PA) get to know of new users' registrations at the
proxy/registrar?

I am referring to a scenario where the PS relies on partner
proxy/registrars for knowledge of new users registering with them, so
that (in future) it can act as a PA on their behalf of those users.

I thought of a few ways:
[1]   The PS has access to the registration database, which it keeps
monitoring at regular intervals for looking for new users. If a new user
is found, then the PS subscribes to the user (basically asking it for
permission to act as its PA).
[2]   The proxy/registrar sends a MESSAGE to the PS, informing it of
each new user registration.
[3]   Assuming that a user registration cud be considered an event, then
perhaps the PS could have subscribed to the proxy/registrar, which would
send a NOTIFY back to the PS every time a new user registered. (I am not
sure of this last option).

Any suggestions?

Thanks & Regards,
Nirmalya



From ndramais@indigosw.com  Mon Feb  4 05:32:50 2002
Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA00461
	for ; Mon, 4 Feb 2002 05:32:50 -0500 (EST)
Received: (qmail 27541 invoked by alias); 4 Feb 2002 11:40:31 -0000
Received: from unknown (HELO indigosw.com) (194.78.202.25)
  by 0 with SMTP; 4 Feb 2002 11:40:31 -0000
Message-ID: <3C5E6326.2060809@indigosw.com>
Date: Mon, 04 Feb 2002 11:32:06 +0100
From: Nicolas Dramais 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: SIMPLE list 
CC: Torrey Searle ,
        "'Rosen, Brian'" ,
        "'Sean Olson (EUS)'" ,
        "'Vencour Marcel'" ,
        Jonathan Rosenberg ,
        Mayerhofer Andreas A 
Subject: Re: [Simple] Mobility of Buddy List, Again
References:  <3C5AB9A2.9090002@indigosw.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2789
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: 

All,

I hadn't seen that a new draft called 
draft-rosenberg-simple-buddylist-package-00.txt had been created to 
address part of my concern below : to have my presence server, acting as 
a BLSS, ie. do the dirty work of subscribing to each individual entry in 
my buddy list on my behalf. It looks fine.
This new draft also approaches the composite Notify mechanism by 
suggesting either multipart-body Notify or single-body Notify containing 
a list or lists of my buddies' presence data.
I think the draft should go further and specify the preferred way of 
using composite Notifies for interop' concerns.

However, even though I agree the transport mechanism to store, modify 
and retrieve buddy lists onto the server is to be performed with other 
protocols than SIP, SIMPLE should  nevertheless cite the preferred 
solution for doing it; for instance HTTP or SMTP; and thus should stay 
in the scope of SIMPLE. This is to increase interoperability among 
different SIMPLE implementation vendors.
As such, whatever the preferred transport method, a 
transport-independent buddylist xml format is necessary and should be 
agreed upon. Accordingly, as mentioned below, I think it would be a 
great idea to reactivate the standardization and agreement of such a 
format like attempted in draft-rosenberg-impp-buddylist-00.txt.

We suggest choosing for HTTP as transport carrying xml formatted 
buddylist documents for storing, modifying and retrieving buddy lists to 
and from  a presence server.

Reactions welcome.
 
Thanks,

Nicolas.

Nicolas Dramais wrote:

> Hi all,
>
> I would like to know what the status is now with mobility of buddy 
> lists. I'm referring to the thread created on this topic in June 2001.
> I agree that draft-rosenberg-impp-buddylist-00.txt addresses one piece 
> of the puzzle (even though it has expired now), being the storage and 
> retrieval of buddy lists to and from a presence server. However, in 
> order to have my presence server doing the dirty work of subscribing 
> to each individual entry in my buddy list on my behalf, yet another 
> piece is missing : some sort of composite Notify bringing back to the 
> watcher presence statuses of all individual entries in my list 
> residing at the server.
>
> Is there enough interest on this list to re-activate the above 
> buddylist draft as a SIMPLE work item ?
> Is there enough interest on this list to define and standardize this 
> composite Notify ?
>
> Or is there a consensus that this puzzle is more an implementation 
> matter ?
>
> Thanks,
> Nicolas.
>

-- 
Nicolas DRAMAIS 
Indigo Software
"We join the dots"
~~~~~~~~~~~~~~~~~~~~~~
50, rue Wiertz
1050 Brussels
Belgium
Phone: +3222350952
Fax: +3222802676
mailto:ndramais@indigosw.com
~~~~~~~~~~~~~~~~~~~~~~
http://www.indigosw.com





From jdrosen@dynamicsoft.com  Tue Feb  5 17:29:44 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06923
	for ; Tue, 5 Feb 2002 17:29:44 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.41])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g15MTZ6Y014902;
	Tue, 5 Feb 2002 17:29:37 -0500 (EST)
Message-ID: <3C605CA3.5723B3EA@dynamicsoft.com>
Date: Tue, 05 Feb 2002 17:28:51 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Nicolas Dramais 
CC: SIMPLE list ,
        Torrey Searle ,
        "'Rosen, Brian'" ,
        "'Sean Olson (EUS)'" ,
        "'Vencour Marcel'" ,
        Mayerhofer Andreas A 
Subject: Re: [Simple] Mobility of Buddy List, Again
References: <3C5E6326.2060809@indigosw.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5166
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: 


Nicolas Dramais wrote:
> 
> However, even though I agree the transport mechanism to store, modify
> and retrieve buddy lists onto the server is to be performed with other
> protocols than SIP, SIMPLE should  nevertheless cite the preferred
> solution for doing it; for instance HTTP or SMTP; and thus should stay
> in the scope of SIMPLE. This is to increase interoperability among
> different SIMPLE implementation vendors.
> As such, whatever the preferred transport method, a
> transport-independent buddylist xml format is necessary and should be
> agreed upon. Accordingly, as mentioned below, I think it would be a
> great idea to reactivate the standardization and agreement of such a
> format like attempted in draft-rosenberg-impp-buddylist-00.txt.

There is a general issue here about architectures vs. protocols. IETF
has traditionally not specified architectures. It has left that work to
other fora, such as 3gpp, packetcable, and so on, and has tried (without
as much success as they would like) to have these groups feed
requiremetns back to ietf for needed extensions.

The mechanisms for managing the buddy list fit into this category. It is
clear that there are multiple solutions for this, and that in some
cases, no standard is needed (a web page, for example, would allow a
user to edit there buddy list). 

So, IETF could not say "this is the mechanism you use for managing a
buddy list in a presence architecture". It could offer a standard for
such, and other people could specify an architecture that says "use
this". The question that needs to be asked, then, is how should such a
standard look?

We have debated this many times, without much resolution. It really is a
pressing issue, since there needs to be something beyond web pages for
several of these. We actually have several things which all fit into
this general space:

1. management of buddy lists - adding/removing/viewing members
2. management of explicit presence state; telling the PA that I'm
available, or not, or what have you. Also known as "publish".
3. management of authorization policies - telling the PA whether or not
users A or B can subscribe or not. These can be simple (yea/nea) or
arbitrarily complex.

I would argue we should solve these all in the same way, and I think
there is little dispute on that. Now, are these SIP, or something else?
Well, the only way to answer that in general is to look at requirements.
Steve Donovan has published some nice requirements already on this, in:

http://search.ietf.org/internet-drafts/draft-donovan-publish-requirements-01.txt


I happen to be of the personal opinion that SOAP works nicely for this.
They are all pure client/server, all transactional data manipulation or
query operations. They may involve large content (what is my buddy
list?). Furthermore, I can see cases where there might even be more than
one solution. Authorization, for example, is awfully complicated. Itd be
nice to have a really simple yea/nea interface, but more complex ones
that we can evolve over time. Since, with SOAP, one can simply define a
new WIDL for these as needed, its a bit easier.

The main arguments I have heard in SIPs favor are:

1. its already there in the end device,
2. its easier to tie in authentication
3. less UA configuration

Regarding point (1); this is one of those "binary v. text" things which
is nearly impossible to resolve, since it is not a techincal argument
per se. I think many handsets have http in them already. XML will be
there for PIDF. So, I don't know how big an issue it is for real.
Regarding (2), if you are allowing a user to manipulate these things via
a web page, you are already needing to solve the issue of tying in your
authentication DB with a web application. So, I don't see the real issue
per se. Regarding (3), the UA would need to be configured with the soap
server to talk to. If SIP were used, presumably the PUBLISH request, or
whatever it is, would go to the outbound proxy, avoiding the need to
have an additional piece of configuration. This is more of a system
issue, since for some architectures such configuration mechanisms likely
exist (wireless handsets), and in others they dont (PCs), and there
certainly is no standard way to do configuration of end devices at this
time.

SHould there be agreement on this direction (and I know there is not at
this time), the question is whether we would specify the widl here and
then submit the rfc to w3c, or if someone just goes and comes up with
one and registers it. I dont think there is precedent for that at all;
that might argue in favor of a SIP solution since the process is a bit
more known.

ANyway, I would really, really like to resolve this, since these
components are needed for many architectures, and they are the hangup to
a complete solution at this point.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From seancolson@yahoo.com  Tue Feb  5 19:06:09 2002
Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id TAA07244
	for ; Tue, 5 Feb 2002 19:06:08 -0500 (EST)
Message-ID: <20020206000526.76476.qmail@web11608.mail.yahoo.com>
Received: from [12.237.5.37] by web11608.mail.yahoo.com via HTTP; Tue, 05 Feb 2002 16:05:26 PST
Date: Tue, 5 Feb 2002 16:05:26 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] Mobility of Buddy List, Again
To: Jonathan Rosenberg ,
        Nicolas Dramais 
Cc: SIMPLE list ,
        Torrey Searle ,
        "'Rosen, Brian'" ,
        "'Sean Olson \(EUS\)'" ,
        "'Vencour Marcel'" ,
        Mayerhofer Andreas A 
In-Reply-To: <3C605CA3.5723B3EA@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 512
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: 

I also favor a SOAP solution for this problem space.
What is the right way forward from a process point
of view? Is this in the charter for SIMPLE, or 
can this work be safely labelled as out-of-scope?
I'm not sure W3C is the right place for this work
either, but it seems like a better fit than the
IETF.

my two cents,
sean


=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

From adam@dynamicsoft.com  Wed Feb  6 22:05:14 2002
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 WAA12082
	for ; Wed, 6 Feb 2002 22:05:13 -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 g1732b4q024638;
	Wed, 6 Feb 2002 22:02:37 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 6 Feb 2002 22:04:33 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F362FFF7@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
Reply-To: sip@ietf.org
To: "'sip@ietf.org'" 
Cc: "'simple@mailman.dynamicsoft.com'" 
Date: Wed, 6 Feb 2002 22:04:30 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 433
Subject: [Simple] draft-ietf-sip-events-02
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: 

draft-ietf-sip-events-02.txt has been submitted for publication. All known
issues have been resolved, and this draft is ready for working group last
call.

Until it appears in the archives, you may access a copy at:
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-02.txt

Also, a PDF version of the draft, with changebars, may be retrieved
from:
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-02.pdf

/a

From tanglih@cn.ibm.com  Thu Feb  7 03:52:27 2002
Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13182
	for ; Thu, 7 Feb 2002 03:52:26 -0500 (EST)
Received: from d23rh902.au.ibm.com 
        by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g178kY969460
        for ; Thu, 7 Feb 2002 19:46:34 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g178rhO50398
	for ; Thu, 7 Feb 2002 19:53:43 +1100
To: simple@mailman.dynamicsoft.com
Cc: "Hong Cai" , "Wei BJ Lu" 
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Thu, 7 Feb 2002 16:51:51 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 07/02/2002 16:51:53
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 2171
Subject: [Simple] PS = back-to-back PA + registrar?
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: 

Hi all,

It's generally accepted that a PS is a combined PA/Proxy/Registrar. During
our work we find that it's difficult for PS to change the role from proxy
to PA or otherwise, when the presentity changes status from online to
offline or otherwise. (In our understanding, PS acts as a proxy if the
presentity is online and acts as a PA when the presentity goes offline.)

Maybe a back-to-back PA + registrar is a better combination. It can hide
the complexity for PS to handle the subscriptions. Assume once the
presentity comes online, it registers to the PS, with or without the
presence documents or CPL. PS generates a subscription to this registered
presentity (not considering the third party registration) and gets presence
info from the notification created by the presentity. All the presence info
are stored in the backstage database and updated with the notifications.
When a watcher invokes a subscription to the PS, the PS can access to this
database to get current presence info of the specific presentity. It's a
simple model. The PS is an end presentity to any watcher and also an end
watcher for any presentity. It can low down the number of transactions
exsiting in the PS.
Another advantage of this model is that through this way the PS can provide
flexible features to higher application level. For example, all the
presence info are available from the PS.

In this case, it requires the high performance of database management. It
needs to update the presence info according to the notifications from
presentities and it must fire an event to notify the PS to generate a
notification to the watchers. Sometimes the database manager must provide
merging presence info when querying.

A question puzzles me in this condition. If a subscription with buddylist
event package is received, the PS handles it acting as a PA, not a BLSS. Is
it reasonable?

What's your opinion of this model? Any comment is highly anticipated!

Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.

4/F, HaoHai Building, No.7, 5th Street, Shangdi, Beijing 100085
Phone: (8610)62986677-542
Tie line 905-542
Email:  tanglih@cn.ibm.com


From jdrosen@dynamicsoft.com  Mon Feb 11 16:07:37 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02333
	for ; Mon, 11 Feb 2002 16:07:37 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.52])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1BL7d6Y025573;
	Mon, 11 Feb 2002 16:07:39 -0500 (EST)
Message-ID: <3C68326B.4D120C19@dynamicsoft.com>
Date: Mon, 11 Feb 2002 16:06:51 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com, Hong Cai ,
        Wei BJ Lu 
Subject: Re: [Simple] PS = back-to-back PA + registrar?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2457
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: 


Li Hua Tang wrote:
> 
> Hi all,
> 
> It's generally accepted that a PS is a combined PA/Proxy/Registrar.
> During
> our work we find that it's difficult for PS to change the role from
> proxy
> to PA or otherwise, when the presentity changes status from online to
> offline or otherwise. (In our understanding, PS acts as a proxy if the
> presentity is online and acts as a PA when the presentity goes offline.)

It should work. Can you identify specific problems?

> 
> Maybe a back-to-back PA + registrar is a better combination. It can hide
> the complexity for PS to handle the subscriptions. Assume once the
> presentity comes online, it registers to the PS, with or without the
> presence documents or CPL. PS generates a subscription to this
> registered
> presentity (not considering the third party registration) and gets
> presence
> info from the notification created by the presentity. All the presence
> info
> are stored in the backstage database and updated with the notifications.
> When a watcher invokes a subscription to the PS, the PS can access to
> this
> database to get current presence info of the specific presentity. It's a
> simple model. The PS is an end presentity to any watcher and also an end
> watcher for any presentity. It can low down the number of transactions
> exsiting in the PS.
> Another advantage of this model is that through this way the PS can
> provide
> flexible features to higher application level. For example, all the
> presence info are available from the PS.

This is certainly a valid model. It has been discussed on the list, and
is certainly allowed. The specification does not mandate implementation
architectures, it merely provides tools. I don't think there is anything
in the spec that would prevent this from working adequately well. Maybe
just a mention encouraging user agents to support it....

> A question puzzles me in this condition. If a subscription with
> buddylist
> event package is received, the PS handles it acting as a PA, not a BLSS.
> Is
> it reasonable?

A BLSS is a type of PA; its one that handles that particular event
package.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Thu Feb 14 02:37:59 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12786
	for ; Thu, 14 Feb 2002 02:37:59 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.42])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1E7c26Y001019;
	Thu, 14 Feb 2002 02:38:02 -0500 (EST)
Message-ID: <3C6B692B.BB78B6A7@dynamicsoft.com>
Date: Thu, 14 Feb 2002 02:37:15 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tang Lihua 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Somes questions about behavior of PS
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3961
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: 

Sorry for the delay in responding... other IETF activities have kept me
busy. Inline.


Tang Lihua wrote:
> 
> Hi,guys
> 
> I want to clarify the behaviour of PS. My questions are as follows:
> 
> About Registrar
> 1. How to upload buddylist or watcherlist to PS?

There is no specified or mandatory way. Certainly a web page can be
used. There is some demand for a more automated way; this is a common
problem for many data elements that need to be managed. There is a
separate thread on that for the case of managing publication of presence
documents, where SOAP has been proposed.


> If a buddylist is stored in PS, should PS automaticly send
> out
> subscription to each buddy on the list? 

If the subscription is to the buddy list, yes, this is documented in:

http://search.ietf.org/internet-drafts/draft-rosenberg-simple-buddylist-package-00.txt


> And it's strange that in this
> case
> a watcher will receive notifications but no subscription is sent out by
> the
> watcher itself.

Not really strange. See the above draft.

> Also another problem is that it will burden PS with
> handling all the buddylists or watcherlists.

Its not mandatory to provide in a system, of course. A provider can
limit this however its policy dictates.

> 2. If a user gets unregistered, remove this user from database or just
> mark
> it as 'Unregistered'?
> How can the PS know an offline presentity is a once registered user? Is
> User Managerment a need?

Generally, the way a PS constructs a presence document is a matter of
policy, and it is a complex policy issue, involving the user, the
provider, and possibly third party policies. The presence document can
be based on registration status, but usually not solely based on it. 

Registration doesn't affect whether a user is a valid customer of the
service, of course. When you say "remove this user from the DB", that
makes no sense to me, since they are still a valid customer.

> 
> About Authentication
> 1. Is the authentication in PS a server-side(as proxy) or a ua-side
> one(as
> PA) one? 

A PA is a type of SIP UA, and thus uses the user-user authentication. If
the PS is acting as a proxy, it would use proxy-user autehtnication.

Please note that SIMPLE authentication has gotten radically better in
the past month or so as a result of big improvements in overall sip
security mechanisms.

> If a subscription is sent to an offline presentity, should the
> PS
> challenge the subscriber?

Generally, all subscriptions need to be authenticated. 

> 2. Should the PS maintain access password lists of each presentity for
> each
> possible watcher? Is there a better way for PS to authorize the watcher?

SIP provides several ways:

1. password lists provided by the presentity, as you mention. Doesn't
scale well, doesn't allow unknown subscribers. Good for some usages,
though.

2. S/MIME. New for sip, and works well for presence. It assumes client
certs, which is not awfully common, but OK.

3. transitivte trust. The new sips scheme works well here. 


So, we have solutions that run the gamut. This is a hard problem in
general, as its in the area of inter-domain authentication between
entities that may not know each other. 

> 2. Draft says, 'For pending subscriptions, the state of the presentity
> SHOULD include some kind of textual note that indicates a pending
> status.'
> Is there any solution to it till now? 

Solution to what? The status is marked as "pending" or something.


> More, how can the PS notify the
> watcher that a buddy is offline now or a buddy gets online?

A NOTIFY message. That is the point of the presence mechanism.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From adam@dynamicsoft.com  Tue Feb 19 14:28:41 2002
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 OAA06282
	for ; Tue, 19 Feb 2002 14:28:40 -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 g1JJPsQl012840
	for ; Tue, 19 Feb 2002 14:25:54 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 19 Feb 2002 14:27:56 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3630084@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
Reply-To: sip@ietf.org
To: "'simple@mailman.dynamicsoft.com'" 
Date: Tue, 19 Feb 2002 14:27:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 409
Subject: [Simple] draft-ietf-sip-events-03.txt available
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: 

Thanks to everyone who reviewed the SIP Events draft for
WGLC. A new version of the draft taking these comments into
account is now available.

Until it appears in the archives, you can get a copy from:
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-03.txt

And, of course, the unofficial PDF version with changebars:
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-03.pdf

/Adam

From tanglih@cn.ibm.com  Thu Feb 21 04:24:12 2002
Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13068
	for ; Thu, 21 Feb 2002 04:24:11 -0500 (EST)
Received: from d23rh902.au.ibm.com 
        by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g1L9II968572;
        Thu, 21 Feb 2002 20:18:18 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1L9OtR32064;
	Thu, 21 Feb 2002 20:24:56 +1100
Subject: Re: [Simple] PS = back-to-back PA + registrar?
To: Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Thu, 21 Feb 2002 17:23:27 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 21/02/2002 17:23:31
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 4771
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: 

Sorry for my slow response. I just come back from vacation.


                                                                                               
                    Jonathan                                                                   
                    Rosenberg             To:     Li Hua Tang/China/IBM@IBMCN                  
                                 Cai/China/IBM@IBMCN, Wei BJ Lu/China/IBM@IBMCN      
                                          Subject:     Re: [Simple] PS = back-to-back PA +     
                    2002-02-12             registrar?                                          
                    05:06                                                                      
                                                                                               
                                                                                               





>Li Hua Tang wrote:
>
> Hi all,
>
> It's generally accepted that a PS is a combined PA/Proxy/Registrar.
> During
> our work we find that it's difficult for PS to change the role from
> proxy
> to PA or otherwise, when the presentity changes status from online to
> offline or otherwise. (In our understanding, PS acts as a proxy if the
> presentity is online and acts as a PA when the presentity goes offline.)

>It should work. Can you identify specific problems?

Yes, you are right. It can work. According to the latest version of
draft-itef-sip-events-03, we find how the PS can notify the watcher to
generate a new subscription when a presentity change status from offline to
online (using header "Subscription-State" and reason code). A new SUBSCRIBE
request is received, so the PS can change the role from PA to proxy. That's
what once troubled us.

There is still a problem we are not satisfied. In normal conditions, or if
the requests are always record-routing, all is ok. What we are concerned is
what would PS do if the presentity crashes. PS as a proxy (which doesn't
maintain transactions) can't initiate NOTIFY request to the watcher to make
it know that the presentity is now not available. Only when the watcher
sends out refreshing SUBSCRIBE (directly to the presentity, like re-INVITE)
and gets no response (or 481 response if the presentity comes online again
during this period), the watcher can know the change. So the watcher may
generate a new subscription and PS can handle it again. It's a very passive
way.

If a Proxy+PA+Registrar model is taken, a new SUBSCRIBE request is the only
trigger for PS to change role between proxy and PA. The key problem is
whether, when and how the watcher sends this new subscription.
>
> Maybe a back-to-back PA + registrar is a better combination. It can hide
> the complexity for PS to handle the subscriptions. Assume once the
> presentity comes online, it registers to the PS, with or without the
> presence documents or CPL. PS generates a subscription to this
> registered
> presentity (not considering the third party registration) and gets
> presence
> info from the notification created by the presentity. All the presence
> info
> are stored in the backstage database and updated with the notifications.
> When a watcher invokes a subscription to the PS, the PS can access to
> this
> database to get current presence info of the specific presentity. It's a
> simple model. The PS is an end presentity to any watcher and also an end
> watcher for any presentity. It can low down the number of transactions
> exsiting in the PS.
> Another advantage of this model is that through this way the PS can
> provide
> flexible features to higher application level. For example, all the
> presence info are available from the PS.

>This is certainly a valid model. It has been discussed on the list, and
>is certainly allowed. The specification does not mandate implementation
>architectures, it merely provides tools. I don't think there is anything
>in the spec that would prevent this from working adequately well. Maybe
>just a mention encouraging user agents to support it....

> A question puzzles me in this condition. If a subscription with
> buddylist
> event package is received, the PS handles it acting as a PA, not a BLSS.
> Is
> it reasonable?

>A BLSS is a type of PA; its one that handles that particular event
>package.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com





From LAM@zurich.ibm.com  Thu Feb 21 13:15:40 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14731
	for ; Thu, 21 Feb 2002 13:15:39 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA58926
	for ; Thu, 21 Feb 2002 19:14:54 +0100
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1LIGXm31300
	for ; Thu, 21 Feb 2002 19:16:33 +0100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
From: "Lamine Brahimi" 
Date: Thu, 21 Feb 2002 19:15:06 +0100
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.8 |June 18, 2001) at
 21/02/2002 19:14:50
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 1513
Subject: [Simple] Handling unregistration of a Presentity in a presence server
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: 

Dear all,

I'm a Student doing his Diploma Thesis at IBM and I'm writing a presence
server for handling NOTIFY and SUBSCRIBE requests.
The presentity updates its presence info via a REGISTER method to the
presence Server with a description param.
For the moment  the presence server does not act as a registrar. We do not
need it. It only generates notifications of changes to watchers on behalf
of a presentity .
We do not use Proxys.

I have three questions:

1) I think that only one Contact header should be present in the REGISTER
request with the desired description param. Is it OK? Otherwise can you
tell me what is the benefit of having multiple Contact headers.

2) suppose a presentity does not refresh its Registration to the server and
timeout occurs. What should the Presence Server send to the unregistered
presentity's watchers ?
Do we NOTIFY  watchers for example  with an "offline" or whatever
convenient state or it is not worth sending a NOTIFY and in this case send
a 404 (NOT FOUND) or possibly a NOTIFY with Subscription-Expires=0;reason
="presentity does not exist" when receiving
SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity.

3)As a consequence, What is the difference when  we receive a SUBSCRIBE to
a presentity that has unregistered (do we need to keep trace that it has
been registered one time before ?) and a SUBSCRIBE to a presentity the
presence server never heard about. Does the presence server have to send a
404 (NOT FOUND) for both?

Regards,
Lamine.


From pkyzivat@cisco.com  Thu Feb 21 21:05:19 2002
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 VAA16140
	for ; Thu, 21 Feb 2002 21:05:19 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1M24o619663;
	Thu, 21 Feb 2002 21:04:50 -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 AAF61126;
	Thu, 21 Feb 2002 21:07:42 -0500 (EST)
Message-ID: <3C75A5B5.ABD570ED@cisco.com>
Date: Thu, 21 Feb 2002 20:58:13 -0500
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: Lamine Brahimi 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Handling unregistration of a Presentity in a presence 
 server
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3677
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: 

I'm not the expert, but I will offer an opinion. See below.

	Paul

Lamine Brahimi wrote:
> 
> Dear all,
> 
> I'm a Student doing his Diploma Thesis at IBM and I'm writing a presence
> server for handling NOTIFY and SUBSCRIBE requests.

Glad to hear that IBM is sponsoring such useful work.

> The presentity updates its presence info via a REGISTER method to the
> presence Server with a description param.
> For the moment  the presence server does not act as a registrar. We do not
> need it. It only generates notifications of changes to watchers on behalf
> of a presentity .

Using REGISTER but not acting as a registrar seems to be cheating.
You can presumably get away with it for testing, but it would seem
unwise to ship something like that.

I think either you should integrate your presence server with your
registrar, or else you should update your presence info some other way.

> We do not use Proxys.

Really? I suppose this is why you don't need a registrar!
So are your clients required to use SUBSCRIBE to learn where to send?
How do they know where to send the SUBSCRIBE? Normally I would
expect that would find the presence server via a proxy.

If this is really true, then you could claim that your presence
server really is a registrar, but there just aren't any proxies
around to use the results. 
(A bogus argument but impossible to disprove.)

> 
> I have three questions:
> 
> 1) I think that only one Contact header should be present in the REGISTER
> request with the desired description param. Is it OK? Otherwise can you
> tell me what is the benefit of having multiple Contact headers.

The benefit is when you have multiple points at which your address
of record may be reached. E.g. an office phone, home phone, cell phone.

Using REGISTER, it might be unusual for these to be registered
in the same REGISTER message, but it is legal. More likely for this
example would be for each to send separate REGISTER messages.
In that case you are expected to aggregate them when reporting
presence.

It is also permissible to register different kinds of URLs - e.g.
a sip address and a mailto address. Of course the mailto address
might not be of much use to your presence clients.

> 
> 2) suppose a presentity does not refresh its Registration to the server and
> timeout occurs. What should the Presence Server send to the unregistered
> presentity's watchers ?
> Do we NOTIFY  watchers for example  with an "offline" or whatever
> convenient state or it is not worth sending a NOTIFY and in this case send
> a 404 (NOT FOUND) or possibly a NOTIFY with Subscription-Expires=0;reason
> ="presentity does not exist" when receiving
> SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity.

I believe you are expected to send a NOTIFY to subscribers when
the registration expires. You might be able to avoid this by
controlling the expiration time of the subscriptions so that they
never extend beyond the expiration of the registration, but that
doesn't sound like a good idea.

> 
> 3)As a consequence, What is the difference when  we receive a SUBSCRIBE to
> a presentity that has unregistered (do we need to keep trace that it has
> been registered one time before ?) and a SUBSCRIBE to a presentity the
> presence server never heard about. Does the presence server have to send a
> 404 (NOT FOUND) for both?

You shouldn't have to retain state about expired registrations.
There shouldn't be any difference to the subscriber for the two cases.

> 
> Regards,
> Lamine.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From jundery@ubiquity.net  Fri Feb 22 05:11:16 2002
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA17590
	for ; Fri, 22 Feb 2002 05:11:15 -0500 (EST)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 22 Feb 2002 10:10:45 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Handling unregistration of a Presentity in a presence server
Date: Fri, 22 Feb 2002 10:12:51 -0000
Message-ID: <45730E094814E44488F789C1CDED27AEC552B7@GBNEWP0758M.eu.ubiquity.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Handling unregistration of a Presentity in a presence server
Thread-Index: AcG7Rdu25aZWykHXT9ChDWQodxrwRQAQXJlQ
From: "James Undery" 
To: "Paul Kyzivat" , "Lamine Brahimi" 
Cc: 
Content-Length: 3006
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA17590
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: 


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
 
> > Lamine Brahimi wrote:

> > The presentity updates its presence info via a REGISTER 
> method to the
> > presence Server with a description param.
> > For the moment  the presence server does not act as a 
> registrar. We do not
> > need it. It only generates notifications of changes to 
> watchers on behalf
> > of a presentity .
> 
> Using REGISTER but not acting as a registrar seems to be cheating.
> You can presumably get away with it for testing, but it would seem
> unwise to ship something like that.
> 
> I think either you should integrate your presence server with your
> registrar, or else you should update your presence info some 
> other way.

I'd like to interject that using registration info for presence isn't a
good idea, the draft 
http://search.ietf.org/internet-drafts/draft-donovan-publish-requirement
s-01.txt provides the requirements of a better mechanism. 

> > I have three questions:
> > 
> > 1) I think that only one Contact header should be present 
> in the REGISTER
> > request with the desired description param. Is it OK? 
> Otherwise can you
> > tell me what is the benefit of having multiple Contact headers.

What you're doing is a bad idea description params are far more likely
to change than registrations.

> > 
> > 2) suppose a presentity does not refresh its Registration 
> to the server and
> > timeout occurs. What should the Presence Server send to the 
> unregistered
> > presentity's watchers ?
> > Do we NOTIFY  watchers for example  with an "offline" or whatever
> > convenient state or it is not worth sending a NOTIFY and in 
> this case send
> > a 404 (NOT FOUND) or possibly a NOTIFY with 
> Subscription-Expires=0;reason
> > ="presentity does not exist" when receiving
> > SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity.
> 
> I believe you are expected to send a NOTIFY to subscribers when
> the registration expires. You might be able to avoid this by
> controlling the expiration time of the subscriptions so that they
> never extend beyond the expiration of the registration, but that
> doesn't sound like a good idea.

The subscriptions and the registrations are totally unrelated, sending a
NOTIFY with offline status seems the most sensible. (You can't send a
404 to a subscriber inplace of a NOTIFY and I'd contend your confusion
arises from you're abuse of registration.)

> > 
> > 3)As a consequence, What is the difference when  we receive 
> a SUBSCRIBE to
> > a presentity that has unregistered (do we need to keep 
> trace that it has
> > been registered one time before ?) and a SUBSCRIBE to a 
> presentity the
> > presence server never heard about. Does the presence server 
> have to send a
> > 404 (NOT FOUND) for both?
> 
> You shouldn't have to retain state about expired registrations.
> There shouldn't be any difference to the subscriber for the two cases.

Have I mentioned using registrations was a bad idea.

James

From pkyzivat@cisco.com  Fri Feb 22 08:54:53 2002
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 IAA18281
	for ; Fri, 22 Feb 2002 08:54:53 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1MDsP716418;
	Fri, 22 Feb 2002 08:54:25 -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 AAF62372;
	Fri, 22 Feb 2002 08:57:17 -0500 (EST)
Message-ID: <3C764C02.AF2FF2CC@cisco.com>
Date: Fri, 22 Feb 2002 08:47:46 -0500
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: James Undery 
CC: Lamine Brahimi , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Handling unregistration of a Presentity in a presence 
 server
References: <45730E094814E44488F789C1CDED27AEC552B7@GBNEWP0758M.eu.ubiquity.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2875
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: 

Comments below.

	Paul

James Undery wrote:
> 
> I'd like to interject that using registration info for presence isn't a
> good idea, the draft
> http://search.ietf.org/internet-drafts/draft-donovan-publish-requirement
> s-01.txt provides the requirements of a better mechanism.

I partially disagree. 

If I use registration to add, remove, or change contact information,
that ought to affect a presence server. It just doesn't make any sense
for a presence server to be advertising that I am present when in fact I
am unreachable. Also, the callerprefs draft introduces options on the
Contacts in registrations that clearly ought to be interrelated with
presence.

Of course you can place the burden on the UA to update both in a
consistent way, but that is simply asking for trouble. And it isn't
consistent with the semantics of registration, where independent UAs can
register with the same address of record and be merged automatically.
The discussions of merging presence documents went nowhere, so if you
want to permit that, using registration to update presence is better
defined.

That said, if you want to maintain a consistent registration, but want
to update nuances of your presence within the the envelope of that
registration, then some other mechanism might be appropriate.

Another observation - for somebody building something now, a draft of
*requirements* for publishing a presence document isn't very useful.

> What you're doing is a bad idea description params are far more likely
> to change than registrations.

Well, by definition the description param is part of the registration,
so it can't be more likely to change than the registration.

But I suppose your point is that the description of presence state is
more likely to change than is the contact address, so that if all you
want to change is presence state it might be better to use some
mechanism other than Contact parameters to represent it.

But that assumes that you don't need to change registration data at the
same time.

For example, suppose you want to change your presence state when you are
in a call, and suppose your registration initially contains:

   Contact: ;q=1
   Contact: ;q=.5

If all you want to do is say you are busy in a call, just updating a
presence document makes sense. But if you want to remain available for
urgent calls but not others, then (using callerprefs) you would need to
update your registration with:

   Contact: ;q=1;priority=urgent
   Contact: ;q=.5

and then at the end of the call you would need to restore your
registration to the original value. Updating only a presence document
wouldn't have the same effect, because it wouldn't affect calls that
ignore presence.

This just highlights the point that callerprefs and presence haven't
been aligned.

From jundery@ubiquity.net  Fri Feb 22 09:22:53 2002
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA18393
	for ; Fri, 22 Feb 2002 09:22:52 -0500 (EST)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 22 Feb 2002 14:22:23 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Handling unregistration of a Presentity in a presence server
Date: Fri, 22 Feb 2002 14:24:30 -0000
Message-ID: <45730E094814E44488F789C1CDED27AEC552B8@GBNEWP0758M.eu.ubiquity.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Handling unregistration of a Presentity in a presence server
Thread-Index: AcG7qL7nWl3sWD3WSvuGgLAcK9kmMgAADIKw
From: "James Undery" 
To: "Paul Kyzivat" 
Cc: "Lamine Brahimi" , 
Content-Length: 4181
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA18393
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: 

Comments inline

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]

> James Undery wrote:
> > 
> > I'd like to interject that using registration info for 
> presence isn't a
> > good idea, the draft
> > 
> http://search.ietf.org/internet-drafts/draft-donovan-publish-r
> equirement
> > s-01.txt provides the requirements of a better mechanism.
> 
> I partially disagree. 
> 
> If I use registration to add, remove, or change contact information,
> that ought to affect a presence server. It just doesn't make any sense
> for a presence server to be advertising that I am present 
> when in fact I
> am unreachable. Also, the callerprefs draft introduces options on the
> Contacts in registrations that clearly ought to be interrelated with
> presence.

Yes, if all you provide is online/offline info only, registration is
tolerable, however, once you've introduced presence descriptions such as
busy/on the phone/in a meeting then registration is totally
inappropriate. Presence is more dynamic in nature than registration.

> Of course you can place the burden on the UA to update both in a
> consistent way, but that is simply asking for trouble. And it isn't
> consistent with the semantics of registration, where 
> independent UAs can
> register with the same address of record and be merged automatically.
> The discussions of merging presence documents went nowhere, so if you
> want to permit that, using registration to update presence is better
> defined.

I'd definately place the burden on the PA, which is exactly where it is
today in services like MSN (bad example I know), Yahoo, ICQ etc. The
semantics of registration aren't well defined if a location service
returns multiple contacts it's local policy that decided how a proxy
will try to contact them (or even redirect to them).

> That said, if you want to maintain a consistent registration, but want
> to update nuances of your presence within the the envelope of that
> registration, then some other mechanism might be appropriate.
> 
> Another observation - for somebody building something now, a draft of
> *requirements* for publishing a presence document isn't very useful.

Well perhaps looking closer at the requirements and experimenting would
be a better project ;-)

> > What you're doing is a bad idea description params are far 
> more likely
> > to change than registrations.
> 
> Well, by definition the description param is part of the registration,
> so it can't be more likely to change than the registration.
> 
> But I suppose your point is that the description of presence state is
> more likely to change than is the contact address, so that if all you
> want to change is presence state it might be better to use some
> mechanism other than Contact parameters to represent it.
> 
> But that assumes that you don't need to change registration 
> data at the
> same time.
>
> For example, suppose you want to change your presence state 
> when you are
> in a call, and suppose your registration initially contains:
> 
>    Contact: ;q=1
>    Contact: ;q=.5
> 
> If all you want to do is say you are busy in a call, just updating a
> presence document makes sense. But if you want to remain available for
> urgent calls but not others, then (using callerprefs) you 
> would need to
> update your registration with:
> 
>    Contact: ;q=1;priority=urgent
>    Contact: ;q=.5
> 
> and then at the end of the call you would need to restore your
> registration to the original value. Updating only a presence document
> wouldn't have the same effect, because it wouldn't affect calls that
> ignore presence.

This is exactly why this is a really bad idea. And the reason for using
480 or 486 responses. Just because you can get the same effect in SIP
from multiple mechanisms doesn't mean they are all equally good.

> This just highlights the point that callerprefs and presence haven't
> been aligned.

Well callerprefs are hints and presence is about hints so I guess the
two are related, unfortunately for the original poster this whole area
is pretty much undefined.

James

From LAM@zurich.ibm.com  Fri Feb 22 11:45:15 2002
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18835
	for ; Fri, 22 Feb 2002 11:45:14 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA130470
	for ; Fri, 22 Feb 2002 17:44:29 +0100
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1MGkHR49792
	for ; Fri, 22 Feb 2002 17:46:17 +0100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
From: "Lamine Brahimi" 
Date: Fri, 22 Feb 2002 17:44:21 +0100
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.8 |June 18, 2001) at
 22/02/2002 17:44:25
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 157
Subject: [Simple] Response to Unsubscription
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: 

Dear all,

What response: NOTIFY, 200 OK or both do we have to send when receiving an
unsubscription ?
It is not clear in the latest draft
Thanks,
Lamine.



From pkyzivat@cisco.com  Fri Feb 22 12:57:06 2002
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 MAA19101
	for ; Fri, 22 Feb 2002 12:57:06 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1MHuaM05601;
	Fri, 22 Feb 2002 12:56:36 -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 AAF64830;
	Fri, 22 Feb 2002 12:59:26 -0500 (EST)
Message-ID: <3C7684C2.658739CA@cisco.com>
Date: Fri, 22 Feb 2002 12:49:54 -0500
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: Lamine Brahimi 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Response to Unsubscription
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 692
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: 

I thought it was clear. There is no special UNSUBSCRIBE - it is simply a
variant of SUBSCRIBE, so the responses must be consistent with that.
Like any request, it must receive a response, so you must send a 200 OK.
Then, because it is a SUBSCRIBE, you must also send a NOTIFY. Then the
subscription is gone, so you are done.

	Paul

Lamine Brahimi wrote:
> 
> Dear all,
> 
> What response: NOTIFY, 200 OK or both do we have to send when receiving an
> unsubscription ?
> It is not clear in the latest draft
> Thanks,
> Lamine.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From bpenfield@acmepacket.com  Fri Feb 22 13:07:29 2002
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19161
	for ; Fri, 22 Feb 2002 13:07:29 -0500 (EST)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id A8AF8DEA0134; Fri, 22 Feb 2002 13:06:39 -0500
Message-ID: <002901c1bbca$c0cc7fe0$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: , "Lamine Brahimi" 
References: 
Subject: Re: [Simple] Response to Unsubscription
Date: Fri, 22 Feb 2002 13:00:03 -0500
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
Content-Length: 1041
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: 

draft-ietf-sip-events-03.txt section 4.1.4.3 states:

     Unsubscribing is handled in the same way as refreshing of a
     subscription, with the "Expires" header set to "0". Note that a
     successful unsubscription will also trigger a final NOTIFY
     message.

The notifier sends a 200 OK (successful) response to the SUBSCRIBE and sends
the final NOTIFY.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: "Lamine Brahimi" 
To: 
Sent: Friday, February 22, 2002 11:44 AM
Subject: [Simple] Response to Unsubscription


> Dear all,
>
> What response: NOTIFY, 200 OK or both do we have to send when receiving an
> unsubscription ?
> It is not clear in the latest draft
> Thanks,
> Lamine.
>
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From LAM@zurich.ibm.com  Sun Feb 24 12:16:22 2002
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27563
	for ; Sun, 24 Feb 2002 12:16:21 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA117290
	for ; Sun, 24 Feb 2002 18:15:35 +0100
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1OHG0P08506
	for ; Sun, 24 Feb 2002 18:16:00 +0100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
From: "Lamine Brahimi" 
Date: Sun, 24 Feb 2002 18:14:15 +0100
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.8 |June 18, 2001) at
 24/02/2002 18:14:15
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 1174
Subject: [Simple] Howt to deal with Notifications when having multiple PUAs for a presentity
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: 

Dear all,
Thanks for previous advices.
I have a specific question:

I allow my presentity to have several PUAs thus several presence-Info (one
per PUA identified by a Contact-address in the Contact-Header  in the
REGISTER msg etc ...).
 It is the presence server (colocated with the registrar)  that aggregates
all presence-Info of a presentity and NOTIFY the watchers.
 What should the presence server do if a presentity PUA (identified by a
contact-address) is not updated and thus expires ????
Can we consider that as an update of presence Info?
Should I notify all the watchers with all the the remaining PUAs
presence-Info only?
Should I notify all the watchers with all the PUAs and a status "NOT FOUND"
(see rfc 2778) for the one which has expired?
Should I do nothing and wait for a "true" presence-Info change to notify
watchers ?

Or, in order to avoid that, can we consider a REGISTER-refresh to update
ALL the presentity Contact-addresses (even they are not all
present in ther Contact header) and symetrically  the same thing for an
unregistration?
It does not follow exactly the spec but it avoids a lot of complexity?

Thanks for the help/
Regards,
Lamine.



From AVSHALOM@il.ibm.com  Sun Feb 24 15:05:44 2002
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28085;
	Sun, 24 Feb 2002 15:05:43 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id VAA137518;
	Sun, 24 Feb 2002 21:04:58 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1OK5NP90484;
	Sun, 24 Feb 2002 21:05:23 +0100
To: "Lamine Brahimi" 
Cc: simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
MIME-Version: 1.0
Subject: Re: [Simple] Howt to deal with Notifications when having multiple PUAs for
 a presentity
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Sun, 24 Feb 2002 22:05:26 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
 24/02/2002 22:05:32,
	Serialize complete at 24/02/2002 22:05:32
Content-Type: multipart/alternative; boundary="=_alternative 006E31F642256B6A_="
Content-Length: 5004
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: 

This is a multipart message in MIME format.
--=_alternative 006E31F642256B6A_=
Content-Type: text/plain; charset="us-ascii"

I would say that if the registration of a PUA expires you should consider 
it as an update to the presence info.
Think of the case where each PUA is representing a mobile device and one 
of the mobile devices was shut down.

Avshalom Houri
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com






Lamine Brahimi/Zurich/IBM@IBMCH
Sent by: simple-admin@mailman.dynamicsoft.com
24/02/2002 19:14

 
        To:        simple@mailman.dynamicsoft.com
        cc: 
        Subject:        [Simple] Howt to deal with Notifications when having multiple PUAs for a 
presentity

 

Dear all,
Thanks for previous advices.
I have a specific question:

I allow my presentity to have several PUAs thus several presence-Info (one
per PUA identified by a Contact-address in the Contact-Header  in the
REGISTER msg etc ...).
 It is the presence server (colocated with the registrar)  that aggregates
all presence-Info of a presentity and NOTIFY the watchers.
 What should the presence server do if a presentity PUA (identified by a
contact-address) is not updated and thus expires ????
Can we consider that as an update of presence Info?
Should I notify all the watchers with all the the remaining PUAs
presence-Info only?
Should I notify all the watchers with all the PUAs and a status "NOT 
FOUND"
(see rfc 2778) for the one which has expired?
Should I do nothing and wait for a "true" presence-Info change to notify
watchers ?

Or, in order to avoid that, can we consider a REGISTER-refresh to update
ALL the presentity Contact-addresses (even they are not all
present in ther Contact header) and symetrically  the same thing for an
unregistration?
It does not follow exactly the spec but it avoids a lot of complexity?

Thanks for the help/
Regards,
Lamine.


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



--=_alternative 006E31F642256B6A_=
Content-Type: text/html; charset="us-ascii"



I would say that if the registration of a PUA expires you should consider it as an update to the presence info.

Think of the case where each PUA is representing a mobile device and one of the mobile devices was shut down.



Avshalom Houri

Lotus Sametime, IBM Software Group

avshalom@il.ibm.com















Lamine Brahimi/Zurich/IBM@IBMCH

Sent by: simple-admin@mailman.dynamicsoft.com

24/02/2002 19:14



        

        To:        simple@mailman.dynamicsoft.com

        cc:        

        Subject:        [Simple] Howt to deal with Notifications when having multiple PUAs for a presentity



       




Dear all,

Thanks for previous advices.

I have a specific question:



I allow my presentity to have several PUAs thus several presence-Info (one

per PUA identified by a Contact-address in the Contact-Header  in the

REGISTER msg etc ...).

 It is the presence server (colocated with the registrar)  that aggregates

all presence-Info of a presentity and NOTIFY the watchers.

 What should the presence server do if a presentity PUA (identified by a

contact-address) is not updated and thus expires ????

Can we consider that as an update of presence Info?

Should I notify all the watchers with all the the remaining PUAs

presence-Info only?

Should I notify all the watchers with all the PUAs and a status "NOT FOUND"

(see rfc 2778) for the one which has expired?

Should I do nothing and wait for a "true" presence-Info change to notify

watchers ?



Or, in order to avoid that, can we consider a REGISTER-refresh to update

ALL the presentity Contact-addresses (even they are not all

present in ther Contact header) and symetrically  the same thing for an

unregistration?

It does not follow exactly the spec but it avoids a lot of complexity?



Thanks for the help/

Regards,

Lamine.





_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple






--=_alternative 006E31F642256B6A_=--

From tanglih@cn.ibm.com  Sun Feb 24 21:57:36 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29420
	for ; Sun, 24 Feb 2002 21:57:23 -0500 (EST)
Received: from d23rh901.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g1P2qMN46498
        for ; Mon, 25 Feb 2002 13:52:22 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1P2vKi109544
	for ; Mon, 25 Feb 2002 13:57:20 +1100
Subject: Re: [Simple] Handling unregistration of a Presentity in a presence  server
To: "Lamine Brahimi" , simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Mon, 25 Feb 2002 10:56:35 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 25/02/2002 10:56:39
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 6288
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: 

Please see my comments below.


Best regards,

Tang Lihua
Research Member, IBM China Research Lab.
Email:  tanglih@cn.ibm.com


                                                                                                          
                    Paul Kyzivat                                                                          
                                 To:     Lamine Brahimi/Zurich/IBM@IBMCH              
                    Sent by:                         cc:     simple@mailman.dynamicsoft.com               
                    simple-admin@mailman.dynam       Subject:     Re: [Simple] Handling unregistration of 
                    icsoft.com                        a Presentity in a presence  server                  
                                                                                                          
                                                                                                          
                    2002-02-22 09:58                                                                      
                                                                                                          
                                                                                                          



I'm not the expert, but I will offer an opinion. See below.

           Paul

Lamine Brahimi wrote:
>
> Dear all,
>
> I'm a Student doing his Diploma Thesis at IBM and I'm writing a presence
> server for handling NOTIFY and SUBSCRIBE requests.

>Glad to hear that IBM is sponsoring such useful work.

> The presentity updates its presence info via a REGISTER method to the
> presence Server with a description param.
> For the moment  the presence server does not act as a registrar. We do
not
> need it. It only generates notifications of changes to watchers on behalf
> of a presentity .

>Using REGISTER but not acting as a registrar seems to be cheating.
>You can presumably get away with it for testing, but it would seem
>unwise to ship something like that.

I quite agree this. Registrar is an important components of PS.

>I think either you should integrate your presence server with your
>registrar, or else you should update your presence info some other way.

>> We do not use Proxys.

>Really? I suppose this is why you don't need a registrar!
>So are your clients required to use SUBSCRIBE to learn where to send?
>How do they know where to send the SUBSCRIBE? Normally I would
>expect that would find the presence server via a proxy.

>If this is really true, then you could claim that your presence
>server really is a registrar, but there just aren't any proxies
>around to use the results.
>(A bogus argument but impossible to disprove.)

>
> I have three questions:
>
> 1) I think that only one Contact header should be present in the REGISTER
> request with the desired description param. Is it OK? Otherwise can you
> tell me what is the benefit of having multiple Contact headers.

>The benefit is when you have multiple points at which your address
>of record may be reached. E.g. an office phone, home phone, cell phone.

>Using REGISTER, it might be unusual for these to be registered
>in the same REGISTER message, but it is legal. More likely for this
>example would be for each to send separate REGISTER messages.
>In that case you are expected to aggregate them when reporting
>presence.

>It is also permissible to register different kinds of URLs - e.g.
>a sip address and a mailto address. Of course the mailto address
>might not be of much use to your presence clients.

>
> 2) suppose a presentity does not refresh its Registration to the server
and
> timeout occurs. What should the Presence Server send to the unregistered
> presentity's watchers ?
> Do we NOTIFY  watchers for example  with an "offline" or whatever
> convenient state or it is not worth sending a NOTIFY and in this case
send
> a 404 (NOT FOUND) or possibly a NOTIFY with Subscription-Expires=0;reason
> ="presentity does not exist" when receiving
> SUBSCRIPTION/SUBSCRIPTION-refresh for that unregistered presentity.

Brahimi, I guess you still use an old version of sip-events draft. In the
latest one
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-03.txt, the
header "Subscription-Expires"  has been changed to "Subscription-State" and
the reason code is totally different. And I think you'd better use the
defined reason code to describe the status.

>I believe you are expected to send a NOTIFY to subscribers when
>the registration expires. You might be able to avoid this by
>controlling the expiration time of the subscriptions so that they
>never extend beyond the expiration of the registration, but that
>doesn't sound like a good idea.

>
> 3)As a consequence, What is the difference when  we receive a SUBSCRIBE
to
> a presentity that has unregistered (do we need to keep trace that it has
> been registered one time before ?) and a SUBSCRIBE to a presentity the
> presence server never heard about. Does the presence server have to send
a
> 404 (NOT FOUND) for both?

It's different. You know REGISTER and SUBSCRIBE requests are quite
different. A valid user is the one who can access to Presence Sevice. Even
if this valid user has unregistered, the PS must handle the subscription to
it. So if a SUBSCRIBE request is received to a invalid presentity (the PS
never hears about), 404 Not Found can be sent back. If the SUBSCRIBE
request is to a valid presentity but now it's not available, the PS must
handle it and send back NOTIFY acting as a PA. This NOTIFY requst has such
a header "Subscription-State: terminated;reason=deactivated", or
"Subscription-State: terminated;reason=probation;retry-after=100". It's
your preference to choose an impementation way.

>You shouldn't have to retain state about expired registrations.
>There shouldn't be any difference to the subscriber for the two cases.

>
> Regards,
> Lamine.
>
> _______________________________________________
> 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 AVSHALOM@il.ibm.com  Mon Feb 25 05:43:02 2002
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00499
	for ; Mon, 25 Feb 2002 05:43:02 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA152460
	for ; Mon, 25 Feb 2002 11:42:14 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1PAi4J48588
	for ; Mon, 25 Feb 2002 11:44:05 +0100
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Mon, 25 Feb 2002 12:30:16 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at
 25/02/2002 12:44:05,
	Serialize complete at 25/02/2002 12:44:05
Content-Type: multipart/alternative; boundary="=_alternative 0039878342256B6B_="
Content-Length: 2514
Subject: [Simple] Session of MESSAGES
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: 

This is a multipart message in MIME format.
--=_alternative 0039878342256B6B_=
Content-Type: text/plain; charset="us-ascii"

From the minutes of the SIMPLE meeting in the last IETF:

draft-rosenberg-simple-im-transport:

* Weakly expressed support. Moderately strong hum against
  proceeding with this proposal.
  - concerns over keeping IMTP and SIP syncronized
 
* Alternate proposal solicited - if none appears before
  early January, work will proceed with IMTP

* Split opinions on whether a proposal must be held to 
  mankin-im-session-guide

Until today there was not much discussion in the group regarding this 
issue. There was one submission of an alternative suggestion:
draft-mrose-simple-exchange-01.txt (IMSX). This suggestion had had very 
minimal discussion in the list.

I think that we should start discussing the following:
* Should a proposal must be held to mankin-im-session-guide
* The different alternatives on the table

Thanks
Avshalom Houri
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com

--=_alternative 0039878342256B6B_=
Content-Type: text/html; charset="us-ascii"



From the minutes of the SIMPLE meeting in the last IETF:



draft-rosenberg-simple-im-transport:



* Weakly expressed support. Moderately strong hum against

  proceeding with this proposal.

  - concerns over keeping IMTP and SIP syncronized

  

* Alternate proposal solicited - if none appears before

  early January, work will proceed with IMTP



* Split opinions on whether a proposal must be held to 

  mankin-im-session-guide



Until today there was not much discussion in the group regarding this issue. There was one submission of an alternative suggestion:

draft-mrose-simple-exchange-01.txt (IMSX). This suggestion had had very minimal discussion in the list.



I think that we should start discussing the following:

* Should a proposal must be held to mankin-im-session-guide

* The different alternatives on the table



Thanks

Avshalom Houri

Lotus Sametime, IBM Software Group

avshalom@il.ibm.com


--=_alternative 0039878342256B6B_=--

From LAM@zurich.ibm.com  Mon Feb 25 09:50:19 2002
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01253
	for ; Mon, 25 Feb 2002 09:50:18 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id PAA166158
	for ; Mon, 25 Feb 2002 15:49:30 +0100
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1PEpMJ78828
	for ; Mon, 25 Feb 2002 15:51:22 +0100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
From: "Lamine Brahimi" 
Date: Mon, 25 Feb 2002 15:49:26 +0100
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.8 |June 18, 2001) at
 25/02/2002 15:49:28
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 1309
Subject: [Simple] On SIP-Specific event Notification new Draft
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: 

Dear all,

Thanks for reporting me the new draft for SIP-Specific event Notification.

     If an initial SUBSCRIBE request is not sent on a pre-existing
     dialog, the subscriber will wait for a response to the SUBSCRIBE
     request or a matching NOTIFY.
     Responses are matched to such SUBSCRIBE requests if they contain
     the same the same "Call-ID", the same "From" header field, the
     same "To" header field, excluding the "tag", and the same "CSeq".
     Rules for the comparison of these headers are described in SIP
     [1]. If a 200-class response matches such a SUBSCRIBE request,
     it creates a new subscription and a new dialog (unless they have
     already been created by a matching NOTIFY request; see below).
          ........

So far, so good ....
However,

    If an initial SUBSCRIBE is sent on a pre-existing dialog, a
     matching 200-class response or successful NOTIFY request merely
     creates a new subscription associated with that dialog.
    Multiple subscriptions can be associated with a single dialog.

How an initial SUBSCRIBE can be sent on a pre-existing dialog otherwise
than sending to the same presentity
several times the SAME SUSBCRIBE ? As a consequence what is the benefit of
having multiple Subscriptions
in the same dialog ???

Thanks,
Lamine.


From tsearle@indigosw.com  Mon Feb 25 05:04:34 2002
Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA00368
	for ; Mon, 25 Feb 2002 05:04:34 -0500 (EST)
Received: (qmail 14635 invoked by alias); 25 Feb 2002 10:03:49 -0000
Received: from unknown (HELO indigosw.com) (194.78.202.25)
  by 0 with SMTP; 25 Feb 2002 10:03:49 -0000
Message-ID: <3C7A0C4E.8070000@indigosw.com>
Date: Mon, 25 Feb 2002 11:05:02 +0100
From: Torrey Searle 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020206
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 482
Subject: [Simple] Expires: 0 in a 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: 

Should Expires: 0 be treated as a special case?  Generally 
unscubscription is treated by the draft as a regular subscription 
update.  However, it seems that in the current draft, treating 
Unscription as regular re-subscription can cause a problem of "423 
Interval too brief" to be generated.

I think that an Expiration time of 0 should be given special meaning and 
explicitly be exempt from the subscription length checks.

Torrey Searle
Indigo Software
tsearle@indigosw.com


From jdrosen@dynamicsoft.com  Mon Feb 25 14:14:37 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02124
	for ; Mon, 25 Feb 2002 14:14:37 -0500 (EST)
Received: from dynamicsoft.com ([63.110.3.234])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1PJEb6Y016920;
	Mon, 25 Feb 2002 14:14:40 -0500 (EST)
Message-ID: <3C7A8CE9.70D795E8@dynamicsoft.com>
Date: Mon, 25 Feb 2002 14:13:45 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Torrey Searle 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Expires: 0 in a SUBSCRIBE
References: <3C7A0C4E.8070000@indigosw.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1125
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: 


Torrey Searle wrote:
> 
> Should Expires: 0 be treated as a special case?  Generally
> unscubscription is treated by the draft as a regular subscription
> update.  However, it seems that in the current draft, treating
> Unscription as regular re-subscription can cause a problem of "423
> Interval too brief" to be generated.

It shouldn't. This is clear in bis, at least:

The registrar MAY shorten the expiration interval. If and only if the
expiration interval is greater than 1722
zero AND smaller than one hour AND less than a registrar-configured
minimum, the registrar MAY 1723
reject the registration with a response of 423 (Registration Too Brief).
1724

sip-events seems to have lost this detail when the 423 text was
integrated into the document. That needs to be fixed.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From tanglih@cn.ibm.com  Tue Feb 26 04:15:12 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04768
	for ; Tue, 26 Feb 2002 04:14:57 -0500 (EST)
Received: from d23rh901.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g1Q991N300688
        for ; Tue, 26 Feb 2002 20:09:01 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1Q9Dun43062
	for ; Tue, 26 Feb 2002 20:13:56 +1100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Tue, 26 Feb 2002 17:13:13 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 26/02/2002 17:13:16
MIME-Version: 1.0
Content-type: text/plain; charset=gb2312
Content-Length: 1168
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id EAA04768
Subject: [Simple] Handling Expires:0 are different in two drafts, why?
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: 

Hi all,

I am puzzled by how to handle a SUBSCRIBE request with an "Expires" of 0.

In the draft draft-ietf-sip-events-03 it's said,
     Note that the NOTIFY messages triggered by SUBSCRIBE messages with
    ¡°Expires¡± headers of 0 will contain a ¡°Subscription-State¡± value
     of ¡°terminated¡±,and a ¡°reason¡± parameter of ¡°timeout¡±.
In this condition, the subscription is terminated and reason=timeout may
cause
a new subscription.

But considering a SUBSCRIBE request for Event:presence.winfo, it's said in
the
draft draft-rosenberg-impp-watcherinfo-00,
     notifications triggered as a result of a fetch operation (a
     SUBSCRIBE with Expires of 0) SHOULD result in the full state of all
     watchers (of course, only those watchers that have been authorized to
     be divulged to the subscriber) to be present in the NOTIFY.
In this condition, what would the value of ¡°Subscription-State¡± be? I think
the subscription is still active here.

What do you think about these two cases?

Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  tanglih@cn.ibm.com

From tony@att.com  Tue Feb 26 17:32:42 2002
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 RAA07183
	for ; Tue, 26 Feb 2002 17:32:42 -0500 (EST)
Received: from maillennium.att.com ([135.25.114.99])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g1QMVqZ19471
	for ; Tue, 26 Feb 2002 17:31:53 -0500 (EST)
Received: from att.com (tony-ob.mt.att.com[135.91.110.214])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020226223151gw100k1vfae>
          (Authid: tony);
          Tue, 26 Feb 2002 22:31:51 +0000
Message-ID: <3C7C0CCC.D6EBC1BC@att.com>
Date: Tue, 26 Feb 2002 17:31:40 -0500
From: Tony Hansen 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SIMPLE list 
References: <20020206000526.76476.qmail@web11608.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 6706
Subject: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again)
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: 

Here are some ideas on how this could play out within the IETF.

One of the documents being put out in the SIP WG is SIP Call Flow
Examples. It shows how the SIP protocol should be used in an IP
Telephony service.

Another effort in the IETF is the Voice Profile for Internet Messaging
(VPIM) working group. That group has been figuring out how to do voice
messaging (for voice mailboxes) using existing protocols, such as SMTP
and IMAP. Where the existing protocols were lacking, they also worked on
filling in the gaps, either within the VPIM WG or in conjunction with
other working groups (e.g., imap-ext). Note: the VPIM WG was originally
formed due to input from an external organization, the EMA, but the work
has all been done here in the IETF.

The problem we're facing here in SIMPLE seems to be in the same
category, and the solution may be similar. It appears that what is
required is a profile for an instant messaging service saying how it
should pull together the different piece parts to form a coherent whole.

I'm convinced we can solve this problem. Getting feedback from the
industry is absolutely useful in the process, but I think the work needs
to happen here, in the IETF. And I'm willing to work on it.

Comments? Should something like this go on the SIMPLE agenda for
Minneapolis?

	Tony Hansen
	tony@att.com

Sean Olson wrote:
> 
> I also favor a SOAP solution for this problem space.
> What is the right way forward from a process point
> of view? Is this in the charter for SIMPLE, or
> can this work be safely labelled as out-of-scope?
> I'm not sure W3C is the right place for this work
> either, but it seems like a better fit than the
> IETF.

Jonathan Rosenberg wrote:
> 
> Nicolas Dramais wrote:
> >
> > However, even though I agree the transport mechanism to store, modify
> > and retrieve buddy lists onto the server is to be performed with other
> > protocols than SIP, SIMPLE should  nevertheless cite the preferred
> > solution for doing it; for instance HTTP or SMTP; and thus should stay
> > in the scope of SIMPLE. This is to increase interoperability among
> > different SIMPLE implementation vendors.
> > As such, whatever the preferred transport method, a
> > transport-independent buddylist xml format is necessary and should be
> > agreed upon. Accordingly, as mentioned below, I think it would be a
> > great idea to reactivate the standardization and agreement of such a
> > format like attempted in draft-rosenberg-impp-buddylist-00.txt.
> 
> There is a general issue here about architectures vs. protocols. IETF
> has traditionally not specified architectures. It has left that work to
> other fora, such as 3gpp, packetcable, and so on, and has tried (without
> as much success as they would like) to have these groups feed
> requiremetns back to ietf for needed extensions.
> 
> The mechanisms for managing the buddy list fit into this category. It is
> clear that there are multiple solutions for this, and that in some
> cases, no standard is needed (a web page, for example, would allow a
> user to edit there buddy list).
> 
> So, IETF could not say "this is the mechanism you use for managing a
> buddy list in a presence architecture". It could offer a standard for
> such, and other people could specify an architecture that says "use
> this". The question that needs to be asked, then, is how should such a
> standard look?
> 
> We have debated this many times, without much resolution. It really is a
> pressing issue, since there needs to be something beyond web pages for
> several of these. We actually have several things which all fit into
> this general space:
> 
> 1. management of buddy lists - adding/removing/viewing members
> 2. management of explicit presence state; telling the PA that I'm
> available, or not, or what have you. Also known as "publish".
> 3. management of authorization policies - telling the PA whether or not
> users A or B can subscribe or not. These can be simple (yea/nea) or
> arbitrarily complex.
> 
> I would argue we should solve these all in the same way, and I think
> there is little dispute on that. Now, are these SIP, or something else?
> Well, the only way to answer that in general is to look at requirements.
> Steve Donovan has published some nice requirements already on this, in:
> 
> http://search.ietf.org/internet-drafts/draft-donovan-publish-requirements-01.txt
> 
> I happen to be of the personal opinion that SOAP works nicely for this.
> They are all pure client/server, all transactional data manipulation or
> query operations. They may involve large content (what is my buddy
> list?). Furthermore, I can see cases where there might even be more than
> one solution. Authorization, for example, is awfully complicated. Itd be
> nice to have a really simple yea/nea interface, but more complex ones
> that we can evolve over time. Since, with SOAP, one can simply define a
> new WIDL for these as needed, its a bit easier.
> 
> The main arguments I have heard in SIPs favor are:
> 
> 1. its already there in the end device,
> 2. its easier to tie in authentication
> 3. less UA configuration
> 
> Regarding point (1); this is one of those "binary v. text" things which
> is nearly impossible to resolve, since it is not a techincal argument
> per se. I think many handsets have http in them already. XML will be
> there for PIDF. So, I don't know how big an issue it is for real.
> Regarding (2), if you are allowing a user to manipulate these things via
> a web page, you are already needing to solve the issue of tying in your
> authentication DB with a web application. So, I don't see the real issue
> per se. Regarding (3), the UA would need to be configured with the soap
> server to talk to. If SIP were used, presumably the PUBLISH request, or
> whatever it is, would go to the outbound proxy, avoiding the need to
> have an additional piece of configuration. This is more of a system
> issue, since for some architectures such configuration mechanisms likely
> exist (wireless handsets), and in others they dont (PCs), and there
> certainly is no standard way to do configuration of end devices at this
> time.
> 
> SHould there be agreement on this direction (and I know there is not at
> this time), the question is whether we would specify the widl here and
> then submit the rfc to w3c, or if someone just goes and comes up with
> one and registers it. I dont think there is precedent for that at all;
> that might argue in favor of a SIP solution since the process is a bit
> more known.
> 
> ANyway, I would really, really like to resolve this, since these
> components are needed for many architectures, and they are the hangup to
> a complete solution at this point.

From ndramais@indigosw.com  Wed Feb 27 05:41:26 2002
Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA09393
	for ; Wed, 27 Feb 2002 05:41:25 -0500 (EST)
Received: (qmail 18489 invoked by alias); 27 Feb 2002 10:40:38 -0000
Received: from unknown (HELO indigosw.com) (194.78.202.25)
  by 0 with SMTP; 27 Feb 2002 10:40:38 -0000
Message-ID: <3C7CB7A4.9010908@indigosw.com>
Date: Wed, 27 Feb 2002 11:40:36 +0100
From: Nicolas Dramais 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Tony Hansen 
CC: SIMPLE list 
Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again)
References: <20020206000526.76476.qmail@web11608.mail.yahoo.com> <3C7C0CCC.D6EBC1BC@att.com>
Content-Type: multipart/alternative;
 boundary="------------040108000904090405090007"
Content-Length: 18398
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: 

--------------040108000904090405090007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

  Hi Tony,

please see my comments below.

Nicolas.

Tony Hansen wrote:

>Here are some ideas on how this could play out within the IETF.
>
>One of the documents being put out in the SIP WG is SIP Call Flow
>Examples. It shows how the SIP protocol should be used in an IP
>Telephony service.
>
Indeed, why not do the same kind of "informational" Call Flow Examples 
document for showing how SIMPLE should be used in deploying a SIP for 
Presence service (showing the use of SOAP transported by SIP or HTTP for 
buddy list mobility and list management, presence state and 
authorization management) ?

>
>
>Another effort in the IETF is the Voice Profile for Internet Messaging
>(VPIM) working group. That group has been figuring out how to do voice
>messaging (for voice mailboxes) using existing protocols, such as SMTP
>and IMAP. Where the existing protocols were lacking, they also worked on
>filling in the gaps, either within the VPIM WG or in conjunction with
>other working groups (e.g., imap-ext). Note: the VPIM WG was originally
>formed due to input from an external organization, the EMA, but the work
>has all been done here in the IETF.
>
>The problem we're facing here in SIMPLE seems to be in the same
>category, and the solution may be similar. It appears that what is
>required is a profile for an instant messaging service saying how it
>should pull together the different piece parts to form a coherent whole.
>
Well, I guess like many other people on this list, we believe that SIP 
for Presence can be applied to a much broader scope of applications than 
just for an IM service.
Hence, we want to separate very much Presence from IM.
So I' d rather name it Presence service instead of IM service.

>
>
>I'm convinced we can solve this problem. Getting feedback from the
>industry is absolutely useful in the process, but I think the work needs
>to happen here, in the IETF. And I'm willing to work on it.
>
As mentioned below, we too want to insure a minimum of Presence service 
interoperability among different SIMPLE implementation vendors; 
especially for mobility of buddy lists and for the management issues 
Jonathan pointed out below.
We are also willing to contribute to it, being on the IETF list or the W3C.

Regards,
Nicolas.

>
>
>Comments? Should something like this go on the SIMPLE agenda for
>Minneapolis?
>
>	Tony Hansen
>	tony@att.com
>
>Sean Olson wrote:
>
>>I also favor a SOAP solution for this problem space.
>>What is the right way forward from a process point
>>of view? Is this in the charter for SIMPLE, or
>>can this work be safely labelled as out-of-scope?
>>I'm not sure W3C is the right place for this work
>>either, but it seems like a better fit than the
>>IETF.
>>
>
>Jonathan Rosenberg wrote:
>
>>Nicolas Dramais wrote:
>>
>>>However, even though I agree the transport mechanism to store, modify
>>>and retrieve buddy lists onto the server is to be performed with other
>>>protocols than SIP, SIMPLE should  nevertheless cite the preferred
>>>solution for doing it; for instance HTTP or SMTP; and thus should stay
>>>in the scope of SIMPLE. This is to increase interoperability among
>>>different SIMPLE implementation vendors.
>>>As such, whatever the preferred transport method, a
>>>transport-independent buddylist xml format is necessary and should be
>>>agreed upon. Accordingly, as mentioned below, I think it would be a
>>>great idea to reactivate the standardization and agreement of such a
>>>format like attempted in draft-rosenberg-impp-buddylist-00.txt.
>>>
>>There is a general issue here about architectures vs. protocols. IETF
>>has traditionally not specified architectures. It has left that work to
>>other fora, such as 3gpp, packetcable, and so on, and has tried (without
>>as much success as they would like) to have these groups feed
>>requiremetns back to ietf for needed extensions.
>>
>>The mechanisms for managing the buddy list fit into this category. It is
>>clear that there are multiple solutions for this, and that in some
>>cases, no standard is needed (a web page, for example, would allow a
>>user to edit there buddy list).
>>
>>So, IETF could not say "this is the mechanism you use for managing a
>>buddy list in a presence architecture". It could offer a standard for
>>such, and other people could specify an architecture that says "use
>>this". The question that needs to be asked, then, is how should such a
>>standard look?
>>
>>We have debated this many times, without much re
>>solution. It really is a
>>pressing issue, since there needs to be something beyond web pages for
>>several of these. We actually have several things which all fit into
>>this general space:
>>
>>1. management of buddy lists - adding/removing/viewing members
>>2. management of explicit presence state; telling the PA that I'm
>>available, or not, or what have you. Also known as "publish".
>>3. management of authorization policies - telling the PA whether or not
>>users A or B can subscribe or not. These can be simple (yea/nea) or
>>arbitrarily complex.
>>
>>I would argue we should solve these all in the same way, and I think
>>there is little dispute on that. Now, are these SIP, or something else?
>>Well, the only way to answer that in general is to look at requirements.
>>Steve Donovan has published some nice requirements already on this, in:
>>
>>http://search.ietf.org/internet-drafts/draft-donovan-publish-requirements-01.txt
>>
>>I happen to be of the personal opinion that SOAP works nicely for this.
>>They are all pure client/server, all transactional data manipulation or
>>query operations. They may involve large content (what is my buddy
>>list?). Furthermore, I can see cases where there might even be more than
>>one solution. Authorization, for example, is awfully complicated. Itd be
>>nice to have a really simple yea/nea interface, but more complex ones
>>that we can evolve over time. Since, with SOAP, one can simply define a
>>new WIDL for these as needed, its a bit easier.
>>
>>The main arguments I have heard in SIPs favor are:
>>
>>1. its already there in the end device,
>>2. its easier to tie in authentication
>>3. less UA configuration
>>
>>Regarding point (1); this is one of those "binary v. text" things which
>>is nearly impossible to resolve, since it is not a techincal argu
>>ment
>>per se. I think many handsets have http in them already. XML will be
>>there for PIDF. So, I don't know how big an issue it is for real.
>>Regarding (2), if you are allowing a user to manipulate these things via
>>a web page, you are already needing to solve the issue of tying in your
>>authentication DB with a web application. So, I don't see the real issue
>>per se. Regarding (3), the UA would need to be configured with the soap
>>server to talk to. If SIP were used, presumably the PUBLISH request, or
>>whatever it is, would go to the outbound proxy, avoiding the need to
>>have an additional piece of configuration. This is more of a system
>>issue, since for some architectures such configuration mechanisms likely
>>exist (wireless handsets), and in others they dont (PCs), and there
>>certainly is no standard way to do configuration of end devices at this
>>time.
>>
>>SHould there be agreement on this direction (and I know there is not at
>>this time),
>> the question is whether we would specify the widl here and
>>then submit the rfc to w3c, or if someone just goes and comes up with
>>one and registers it. I dont think there is precedent for that at all;
>>that might argue in favor of a SIP solution since the process is a bit
>>more known.
>>
>>ANyway, I would really, really like to resolve this, since these
>>components are needed for many architectures, and they are the hangup to
>>a complete solution at this point.
>>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>

-- 
Nicolas DRAMAIS
Indigo Software
~~~~~~~~~~~~~~~~~~~~~~
50, rue Wiertz
1050 Brussels
Belgium
Phone: +3222350952
Fax: +3222802676
mailto:ndramais@indigosw.com
~~~~~~~~~~~~~~~~~~~~~~
http://www.indigosw.com




--------------040108000904090405090007
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit






   Hi Tony,



 please see my comments below.



 Nicolas.



 Tony Hansen wrote:



  
Here are some ideas on how this could play out within the IETF.

One of the documents being put out in the SIP WG is SIP Call Flow
Examples. It shows how the SIP protocol should be used in an IP
Telephony service.

  

 Indeed, why not do the same kind of "informational" Call Flow Examples document 
for showing how SIMPLE should be used in deploying a SIP for Presence service 
(showing the use of SOAP transported by SIP or HTTP for buddy list mobility 
and list management, presence state and authorization management) ?

  

    


Another effort in the IETF is the Voice Profile for Internet Messaging
(VPIM) working group. That group has been figuring out how to do voice
messaging (for voice mailboxes) using existing protocols, such as SMTP
and IMAP. Where the existing protocols were lacking, they also worked on
filling in the gaps, either within the VPIM WG or in conjunction with
other working groups (e.g., imap-ext). Note: the VPIM WG was originally
formed due to input from an external organization, the EMA, but the work
has all been done here in the IETF.

The problem we're facing here in SIMPLE seems to be in the same
category, and the solution may be similar. It appears that what is
required is a profile for an instant messaging service saying how it
should pull together the different piece parts to form a coherent whole.

    

 Well, I guess like many other people on this list, we believe that SIP for 
Presence can be applied to a much broader scope of applications than just 
for an IM service.

 Hence, we want to separate very much Presence from IM.

 So I' d rather name it Presence service instead of IM service.

    

      


I'm convinced we can solve this problem. Getting feedback from the
industry is absolutely useful in the process, but I think the work needs
to happen here, in the IETF. And I'm willing to work on it.

      

 As mentioned below, we too want to insure a minimum of Presence service
interoperability among different SIMPLE implementation vendors; especially
for mobility of buddy lists and for the management issues Jonathan pointed
out below.

 We are also willing to contribute to it, being on the IETF list or the W3C.

      

 Regards,

 Nicolas. 

      

        


Comments? Should something like this go on the SIMPLE agenda for
Minneapolis?

	Tony Hansen
	tony@att.com

Sean Olson wrote:

        

          
I also favor a SOAP solution for this problem space.
What is the right way forward from a process point
of view? Is this in the charter for SIMPLE, or
can this work be safely labelled as out-of-scope?
I'm not sure W3C is the right place for this work
either, but it seems like a better fit than the
IETF.

          

          

Jonathan Rosenberg wrote:

          

            
Nicolas Dramais wrote:

            

              
However, even though I agree the transport mechanism to store, modify
and retrieve buddy lists onto the server is to be performed with other
protocols than SIP, SIMPLE should  nevertheless cite the preferred
solution for doing it; for instance HTTP or SMTP; and thus should stay
in the scope of SIMPLE. This is to increase interoperability among
different SIMPLE implementation vendors.
As such, whatever the preferred transport method, a
transport-independent buddylist xml format is necessary and should be
agreed upon. Accordingly, as mentioned below, I think it would be a
great idea to reactivate the standardization and agreement of such a
format like attempted in draft-rosenberg-impp-buddylist-00.txt.

              

              
There is a general issue here about architectures vs. protocols. IETF
has traditionally not specified architectures. It has left that work to
other fora, such as 3gpp, packetcable, and so on, and has tried (without
as much success as they would like) to have these groups feed
requiremetns back to ietf for needed extensions.

The mechanisms for managing the buddy list fit into this category. It is
clear that there are multiple solutions for this, and that in some
cases, no standard is needed (a web page, for example, would allow a
user to edit there buddy list).

So, IETF could not say "this is the mechanism you use for managing a
buddy list in a presence architecture". It could offer a standard for
such, and other people could specify an architecture that says "use
this". The question that needs to be asked, then, is how should such a
standard look?

We have debated this many times, without much re

solution. It really is a
pressing issue, since there needs to be something beyond web pages for
several of these. We actually have several things which all fit into
this general space:

1. management of buddy lists - adding/removing/viewing members
2. management of explicit presence state; telling the PA that I'm
available, or not, or what have you. Also known as "publish".
3. management of authorization policies - telling the PA whether or not
users A or B can subscribe or not. These can be simple (yea/nea) or
arbitrarily complex.

I would argue we should solve these all in the same way, and I think
there is little dispute on that. Now, are these SIP, or something else?
Well, the only way to answer that in general is to look at requirements.
Steve Donovan has published some nice requirements already on this, in:

http://search.ietf.org/internet-drafts/draft-donovan-publish-requirements-01.txt

I happen to be of the personal opinion that SOAP works nicely for this.
They are all pure client/server, all transactional data manipulation or
query operations. They may involve large content (what is my buddy
list?). Furthermore, I can see cases where there might even be more than
one solution. Authorization, for example, is awfully complicated. Itd be
nice to have a really simple yea/nea interface, but more complex ones
that we can evolve over time. Since, with SOAP, one can simply define a
new WIDL for these as needed, its a bit easier.

The main arguments I have heard in SIPs favor are:

1. its already there in the end device,
2. its easier to tie in authentication
3. less UA configuration

Regarding point (1); this is one of those "binary v. text" things which
is nearly impossible to resolve, since it is not a techinc
al argu
ment
per se. I think many handsets have http in them already. XML will be
there for PIDF. So, I don't know how big an issue it is for real.
Regarding (2), if you are allowing a user to manipulate these things via
a web page, you are already needing to solve the issue of tying in your
authentication DB with a web application. So, I don't see the real issue
per se. Regarding (3), the UA would need to be configured with the soap
server to talk to. If SIP were used, presumably the PUBLISH request, or
whatever it is, would go to the outbound proxy, avoiding the need to
have an additional piece of configuration. This is more of a system
issue, since for some architectures such configuration mechanisms likely
exist (wireless handsets), and in others they dont (PCs), and there
certainly is no standard way to do configuration of end devices at this
time.

SHould there be agreement on this direction (and I know there is not at
thi
s time),
 the question is whether we would specify the widl here and
then submit the rfc to w3c, or if someone just goes and comes up with
one and registers it. I dont think there is precedent for that at all;
that might argue in favor of a SIP solution since the process is a bit
more known.

ANyway, I would really, really like to resolve this, since these
components are needed for many architectures, and they are the hangup to
a complete solution at this point.

              

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



              

              

              
-- 
Nicolas DRAMAIS
Indigo Software
~~~~~~~~~~~~~~~~~~~~~~
50, rue Wiertz
1050 Brussels
Belgium
Phone: +3222350952
Fax: +3222802676
mailto:ndramais@indigosw.com
~~~~~~~~~~~~~~~~~~~~~~
http://www.indigosw.com



              

              

              

              
              

--------------040108000904090405090007--


From nsyracus@cnri.reston.va.us  Wed Feb 27 07:27:51 2002
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 HAA09739
	for ; Wed, 27 Feb 2002 07:27:50 -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 HAA18728;
	Wed, 27 Feb 2002 07:26:59 -0500 (EST)
Message-Id: <200202271226.HAA18728@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
Date: Wed, 27 Feb 2002 07:26:58 -0500
Content-Length: 2838
Subject: [Simple] I-D ACTION:draft-ietf-simple-cpim-mapping-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: CPIM Mapping of SIMPLE Presence and Instant Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-simple-cpim-mapping-00.txt
	Pages		: 12
	Date		: 26-Feb-02
	
The SIMPLE work group has defined a SIP events package for
distribution of presence information. It has also proposed a MESSAGE
extension for the transport of instant messages. This document
describes how those mechanisms map to the abstract CPIM service, in
order to interoperate with other CPIM compliant presence and instant
messaging services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-cpim-mapping-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-cpim-mapping-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-cpim-mapping-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:	<20020226131227.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-cpim-mapping-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-cpim-mapping-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020226131227.I-D@ietf.org>

--OtherAccess--

--NextPart--



From adam@dynamicsoft.com  Wed Feb 27 13:08:36 2002
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 NAA10828
	for ; Wed, 27 Feb 2002 13:08: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 g1RI5iZq021368;
	Wed, 27 Feb 2002 13:05:44 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Feb 2002 13:07:50 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300B2@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
Reply-To: sip@ietf.org
To: "'sip@ietf.org'" 
Cc: "'simple@mailman.dynamicsoft.com'" 
Date: Wed, 27 Feb 2002 13:07:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 603
Subject: [Simple] New Version: draft-ietf-sip-events-04 complete
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: 

FYI: a new version of the SIP Events draft is available. Until
it appears in the archives, a copy is available from the locations
listed below. WGLC has already concluded; this announcement is for
information purposes only. I am not soliciting comments from the
working group at this time.

Official version:
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.txt

Unofficial PDF version w/changebars:
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.pdf

Changes from -03 are nominal, and are documented at:
http://pages.sbcglobal.net/roaches/ietf/event-changes.html

/a 

From jdrosen@dynamicsoft.com  Wed Feb 27 16:13:26 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11439
	for ; Wed, 27 Feb 2002 16:13:26 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.53])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1RLDS6Y019245;
	Wed, 27 Feb 2002 16:13:28 -0500 (EST)
Message-ID: <3C7D227E.3E8288A6@dynamicsoft.com>
Date: Wed, 27 Feb 2002 13:16:30 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Handling Expires:0 are different in two drafts, why?
References: 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 1861
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: 


Li Hua Tang wrote:
> 
> Hi all,
> 
> I am puzzled by how to handle a SUBSCRIBE request with an "Expires" of
> 0.

There is no special casing. Its a SUBSCRIBE that just happens to expire
real soon.

> 
> In the draft draft-ietf-sip-events-03 it's said,
>      Note that the NOTIFY messages triggered by SUBSCRIBE messages with
>     ¡°Expires¡± headers of 0 will contain a ¡°Subscription-State¡± value
>      of ¡°terminated¡±,and a ¡°reason¡± parameter of ¡°timeout¡±.
> In this condition, the subscription is terminated and reason=timeout may
> cause
> a new subscription.
> 
> But considering a SUBSCRIBE request for Event:presence.winfo, it's said
> in
> the
> draft draft-rosenberg-impp-watcherinfo-00,
>      notifications triggered as a result of a fetch operation (a
>      SUBSCRIBE with Expires of 0) SHOULD result in the full state of all
>      watchers (of course, only those watchers that have been authorized
> to
>      be divulged to the subscriber) to be present in the NOTIFY.
> In this condition, what would the value of ¡°Subscription-State¡± be? I
> think
> the subscription is still active here.

A fetch does not create a subscription; at least, not one that lives for
more than an infinitesimal period of time. Effectively, the fetch
creates an instantaneously expiring subscription, causing a NOTIFY to be
sent. That NOTIFY has the current state, along with the
Subscription-State header, with a value terminated and reason of
timeout. Thus, the two statements above are not contradictory.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com



From jdrosen@dynamicsoft.com  Wed Feb 27 16:13:30 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11444
	for ; Wed, 27 Feb 2002 16:13:30 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.53])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1RLDX6Y019248;
	Wed, 27 Feb 2002 16:13:33 -0500 (EST)
Message-ID: <3C7D243D.84C492B4@dynamicsoft.com>
Date: Wed, 27 Feb 2002 13:23:57 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Avshalom Houri 
CC: Lamine Brahimi , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Howt to deal with Notifications when having multiplePUAs 
 for a presentity
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2232
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: 


Avshalom Houri wrote:
> 
> I would say that if the registration of a PUA expires you should
> consider it as an update to the presence info.
> Think of the case where each PUA is representing a mobile device and one
> of the mobile devices was shut down.

Correct. Some more details inline.

Lamine writes: 
> 
> Dear all,
> Thanks for previous advices.
> I have a specific question:
> 
> I allow my presentity to have several PUAs thus several presence-Info
> (one
> per PUA identified by a Contact-address in the Contact-Header  in the
> REGISTER msg etc ...).
> It is the presence server (colocated with the registrar)  that
> aggregates
> all presence-Info of a presentity and NOTIFY the watchers.
> What should the presence server do if a presentity PUA (identified by a
> contact-address) is not updated and thus expires ????
> Can we consider that as an update of presence Info?

Definitely. The role of the PA is to take the sources of presence it
knows about, and generate a total presence document for the presentity
based on those sources. That includes, but by no means is limited to,
registrations.

> Should I notify all the watchers with all the the remaining PUAs
> presence-Info only?

That probably makes the most sense.

> Should I notify all the watchers with all the PUAs and a status "NOT
> FOUND"
> (see rfc 2778) for the one which has expired?

Probably the updated presence document would omit the contact address
for the PUA whose registration has expired.

> Should I do nothing and wait for a "true" presence-Info change to notify
> watchers ?
> 
> Or, in order to avoid that, can we consider a REGISTER-refresh to update
> ALL the presentity Contact-addresses (even they are not all
> present in ther Contact header)

No, because thats not what the REGISTER means. THe spec doesn't prevent
this, but the presence document you generate would not be accurate.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com



From jdrosen@dynamicsoft.com  Wed Feb 27 16:13:35 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11449
	for ; Wed, 27 Feb 2002 16:13:35 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.53])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1RLDb6Y019251;
	Wed, 27 Feb 2002 16:13:38 -0500 (EST)
Message-ID: <3C7D2986.74356922@dynamicsoft.com>
Date: Wed, 27 Feb 2002 13:46:30 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] PS = back-to-back PA + registrar?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2368
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: 

inline.

Li Hua Tang wrote:
> 

> > It's generally accepted that a PS is a combined PA/Proxy/Registrar.
> > During
> > our work we find that it's difficult for PS to change the role from
> > proxy
> > to PA or otherwise, when the presentity changes status from online to
> > offline or otherwise. (In our understanding, PS acts as a proxy if the
> > presentity is online and acts as a PA when the presentity goes
> offline.)
> 
> >It should work. Can you identify specific problems?
> 
> Yes, you are right. It can work. According to the latest version of
> draft-itef-sip-events-03, we find how the PS can notify the watcher to
> generate a new subscription when a presentity change status from offline
> to
> online (using header "Subscription-State" and reason code). A new
> SUBSCRIBE
> request is received, so the PS can change the role from PA to proxy.
> That's
> what once troubled us.
> 
> There is still a problem we are not satisfied. In normal conditions, or
> if
> the requests are always record-routing, all is ok. What we are concerned
> is
> what would PS do if the presentity crashes. PS as a proxy (which doesn't
> maintain transactions) can't initiate NOTIFY request to the watcher to
> make
> it know that the presentity is now not available. Only when the watcher
> sends out refreshing SUBSCRIBE (directly to the presentity, like
> re-INVITE)
> and gets no response (or 481 response if the presentity comes online
> again
> during this period), the watcher can know the change. So the watcher may
> generate a new subscription and PS can handle it again. It's a very
> passive
> way.

Correct. This is an inherent limitation of the end-system based
notification model. There will be a delay, equal to the refresh interval
of SUBSCRIBE, to detect the failure of a PA. If a network server is used
(and made reliable itself, through state replication or whatever means
are needed), the watcher can be notified of the change as quickly as the
PA can know. That depends on the subscription refresh interval.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From MChiou@Santera.com  Wed Feb 27 15:12:21 2002
Received: from excalibur.santera.com (mail.santera.com [4.22.157.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA11229
	for ; Wed, 27 Feb 2002 15:12:21 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 27 Feb 2002 14:11:31 -0600
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] New Version: draft-ietf-sip-events-04 complete
thread-index: AcG/vB/RCq4nW0+fRsO/G7zKqWqvaQACplJA
From: "Chiou, Mark" 
To: 
Cc: 
Content-Length: 380
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA11229
Subject: [Simple] RE: [Sip] draft-ietf-sip-events-04; Questions
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: 

Hi Adam,

I have the following questions regarding to 7.4 new Method:

1. Why the Contact header is mandatory for SUBSCRIBER and NOTIFY? If the Contact is not applicable to these methods, then "-" should be applied to R, 1xx, 2xx, 3xx, and 485.
2. I don't think 3xx is applicable to these two methods, such that contact 3xx should have "-" instead of "o".


Regards,


Mark Chiou

From MChiou@Santera.com  Wed Feb 27 15:18:52 2002
Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA11263
	for ; Wed, 27 Feb 2002 15:18:52 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 27 Feb 2002 14:18:01 -0600
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sip] New Version: draft-ietf-sip-events-04 complete
thread-index: AcG/vB/RCq4nW0+fRsO/G7zKqWqvaQADu9oA
From: "Chiou, Mark" 
To: 
Content-Length: 213
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA11263
Subject: [Simple] Question regarding SIP-Specific Event Notification
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: 

Hi Adam,

Could you explain why the immediately NOTIFY request is required when Notifier receives a SUBSCRIBER request? For my opinion, the 200 OK response for the SUBSCRIBER request is sufficient.

Thanks,

Mark

From tanglih@cn.ibm.com  Wed Feb 27 22:30:51 2002
Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12745
	for ; Wed, 27 Feb 2002 22:30:50 -0500 (EST)
Received: from d23rh901.au.ibm.com 
        by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g1S3P0x130924
        for ; Thu, 28 Feb 2002 14:25:00 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1S3Unw71188
	for ; Thu, 28 Feb 2002 14:30:49 +1100
Subject: Re: [Simple] New Version: draft-ietf-sip-events-04 complete
To: 
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Thu, 28 Feb 2002 11:30:08 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 28/02/2002 11:30:12
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 2329
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: 

Adam,

I noticed one new reason code noresource is added. Could you please give a
scenario where it can be used?


Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  tanglih@cn.ibm.com


                                                                                                          
                    Adam Roach                                                                            
                               To:     "'sip@ietf.org'"               
                    Sent by:                         cc:     "'simple@mailman.dynamicsoft.com'"           
                    simple-admin@mailman.dynam                            
                    icsoft.com                       Subject:     [Simple] New Version:                   
                                                      draft-ietf-sip-events-04 complete                   
                                                                                                          
                    2002-02-28 02:07                                                                      
                    Please respond to sip                                                                 
                                                                                                          
                                                                                                          



FYI: a new version of the SIP Events draft is available. Until
it appears in the archives, a copy is available from the locations
listed below. WGLC has already concluded; this announcement is for
information purposes only. I am not soliciting comments from the
working group at this time.

Official version:
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.txt

Unofficial PDF version w/changebars:
http://pages.sbcglobal.net/roaches/ietf/draft-ietf-sip-events-04.pdf

Changes from -03 are nominal, and are documented at:
http://pages.sbcglobal.net/roaches/ietf/event-changes.html

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





From LAM@zurich.ibm.com  Thu Feb 28 04:08:44 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13772
	for ; Thu, 28 Feb 2002 04:08:44 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id KAA62826
	for ; Thu, 28 Feb 2002 10:07:53 +0100
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g1S99h726926
	for ; Thu, 28 Feb 2002 10:09:44 +0100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
From: "Lamine Brahimi" 
Date: Thu, 28 Feb 2002 10:07:43 +0100
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.8 |June 18, 2001) at
 28/02/2002 10:07:47
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 118
Subject: [Simple] Watcher with Multiple PUAs
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: 

Dear all,

I wonder where to send Notifications if Watcher has Multiple PUAs (or
contact-adresses)?
Regards,
Lamine.


From jdrosen@dynamicsoft.com  Thu Feb 28 08:45:11 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14691
	for ; Thu, 28 Feb 2002 08:45:11 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.53])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1SDjD6Y020086;
	Thu, 28 Feb 2002 08:45:16 -0500 (EST)
Message-ID: <3C7E342E.733788F1@dynamicsoft.com>
Date: Thu, 28 Feb 2002 08:44:14 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lamine Brahimi 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Watcher with Multiple PUAs
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 712
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: 

SUBSCRIBE can carry but a single Contact address.

-Jonathan R.

Lamine Brahimi wrote:
> 
> Dear all,
> 
> I wonder where to send Notifications if Watcher has Multiple PUAs (or
> contact-adresses)?
> Regards,
> Lamine.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Thu Feb 28 09:32:43 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14880
	for ; Thu, 28 Feb 2002 09:32:43 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.53])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1SEWm6Y020113;
	Thu, 28 Feb 2002 09:32:48 -0500 (EST)
Message-ID: <3C7E3F5B.405E3DCC@dynamicsoft.com>
Date: Thu, 28 Feb 2002 09:31:55 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] New Version: draft-ietf-sip-events-04 complete
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 674
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: 


Li Hua Tang wrote:
> 
> Adam,
> 
> I noticed one new reason code noresource is added. Could you please give a
> scenario where it can be used?

It was discussed at length on the sip list. Its not useful for presence,
but is useful for other resources, such as call state, where the
subscription terminates on the end of the call.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From nsyracus@cnri.reston.va.us  Thu Feb 28 07:06:01 2002
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 HAA14377
	for ; Thu, 28 Feb 2002 07:06:00 -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 HAA17538;
	Thu, 28 Feb 2002 07:05:12 -0500 (EST)
Message-Id: <200202281205.HAA17538@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
Date: Thu, 28 Feb 2002 07:05:11 -0500
Content-Length: 2841
Subject: [Simple] I-D ACTION:draft-rosenberg-simple-components-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: A Component Model for SIMPLE
	Author(s)	: J. Rosenberg
	Filename	: draft-rosenberg-simple-components-00.txt
	Pages		: 
	Date		: 27-Feb-02
	
The SIMPLE working group has developed a core set of specifications
for messaging and presence functionality. However, those protocols
alone are not sufficient to build a complete IM and presence
application.  In this document, we advocate a componentized model,
whereby the other pieces of the system are very loosely coupled, and
easily swapped out for others, in order to allow innovation and
differentiation. We also propose some simple solutions for several of
them to allow for interop.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-components-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-rosenberg-simple-components-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-rosenberg-simple-components-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:	<20020227124628.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-rosenberg-simple-components-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rosenberg-simple-components-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020227124628.I-D@ietf.org>

--OtherAccess--

--NextPart--



From adam@dynamicsoft.com  Thu Feb 28 11:33:09 2002
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 LAA15305
	for ; Thu, 28 Feb 2002 11:33:09 -0500 (EST)
Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g1SGU9Zq029508;
	Thu, 28 Feb 2002 11:30:10 -0500 (EST)
Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <14NNGK5V>; Thu, 28 Feb 2002 11:32:15 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300B6@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Chiou, Mark'" , sip@ietf.org
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] RE: [Sip] draft-ietf-sip-events-04; Questions
Date: Thu, 28 Feb 2002 11:32:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 799
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: 

> -----Original Message-----
> From: Chiou, Mark [mailto:MChiou@Santera.com]
> 
> 1. Why the Contact header is mandatory for SUBSCRIBER and 
> NOTIFY? If the Contact is not applicable to these methods, 
> then "-" should be applied to R, 1xx, 2xx, 3xx, and 485.

Contact headers form an important part of the route. This
behavior mirrors that of the bis draft.

> 2. I don't think 3xx is applicable to these two methods, such 
> that contact 3xx should have "-" instead of "o".

3xx responses are applicable to all methods, and there's nothing
that an extension can do about it. Redirect servers will always
redirect unknown methods.

I could also argue that 3xx responses can be quite useful
for SUBSCRIBE, with some fairly compelling examples, but
the above fact makes it a rather moot point.

/a

From petkos@cs.columbia.edu  Thu Feb 28 12:25:16 2002
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 MAA15533
	for ; Thu, 28 Feb 2002 12:25:16 -0500 (EST)
Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA06575
	for ; Thu, 28 Feb 2002 12:24:19 -0500 (EST)
Received: (from petkos@localhost)
	by dynasty.cs.columbia.edu (8.9.3/8.9.3) id MAA04612
	for simple@mailman.dynamicsoft.com; Thu, 28 Feb 2002 12:24:18 -0500 (EST)
From: "Petri K. Koskelainen" 
Message-Id: <200202281724.MAA04612@dynasty.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Thu, 28 Feb 2002 12:24:18 -0500 (EST)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2215
Subject: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
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: 

Hi,

The draft proposes that In-Reply-To header should
be used for message threading in paging mode,
and the draft also states that in message session 
mode threading is already provided.

I don't fully agree here. It works for two-party messaging
but not well in group messaging scenarios.

Problem 1: Message session supports only one discussion thread 
per session.
This does not well reflect real-life scenarios. 
For example, there may be a group chat session with 20 people. 
It is very likely that they have different
conversation topics going-on at the same time although they 
are in the same group. It is also likely that smaller sub-threads
emerge and it would be nice if these can be somehow shown
in the user interface similarly to current network news UIs.
For example, if there are several questions asked in the group
and users respond with "yes!" or "no" in the message body it is 
quite difficult to know to which question they were intended.
User Interface could show them nicely if there were header support 
for it.


Problem 2: Group messaging server creates new Call-IDs for each call-leg.
In-Reply-To has also problems in group IM paging mode
since the server creates new Call-IDs for each 
participant. One call-id is valid only between one user and the server.
The server has to remember all previous Call-IDs so
it can change Call-IDs in In-Reply-To accordingly when somebody 
is responding to group message. 
It must have the history and know that a message it sent to Bob 
a day ago with Call-ID=X is in fact the same message than 
message sent to Alice with Call-ID=Y. This becames quite complicated.

 
Problem 3: Lack of global and common ID for each group message.
Now it is difficult to reference a specific group instant message
afterwards so that everybody understands it. Only the server
has the knowledge (if it keeps the history). The recipients
don't know that group IM sent to me with Call-ID=X is the same than
group IM sent to Alice with Call-ID=Y. In some cases it would
be useful to have the information available in the message.


These problems can be solved if new header (Message-ID)
is defined and References header is used (like in NNTP messages).


BR,
--
Petri

From dean.willis@softarmor.com  Thu Feb 28 13:14:35 2002
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 NAA15703
	for ; Thu, 28 Feb 2002 13:14:34 -0500 (EST)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g1SID8B12843;
	Thu, 28 Feb 2002 12:13:08 -0600
Message-ID: <014301c1c083$7fa086c0$bc036e3f@TXDWILLIS2>
From: "Dean Willis" 
To: "Petri K. Koskelainen" ,
        
References: <200202281724.MAA04612@dynasty.cs.columbia.edu>
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Date: Thu, 28 Feb 2002 12:12:35 -0600
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
Content-Length: 713
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: 

Petri, talking abouta thread that decomposes int subordinate threads, wrote:
> These problems can be solved if new header (Message-ID)
> is defined and References header is used (like in NNTP messages).

I'm reminded of the tumbler approach that Ted Nelson developed in the Xanadu
framework for providing infinitely subscopable addressing.

Essentially, a subscope of any address could could be declared by suffixing
a "." and a subscope identifier to the existing address. Although tumblers
used numeric addressing ostensibly derived from byte counts within static
documents, a similar mechanism was later used for describing heirarchy in
usenet groups, such as "rec.humor.funny.standards.messaging".

--
Dean


From tanglih@cn.ibm.com  Thu Feb 28 20:33:12 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17021
	for ; Thu, 28 Feb 2002 20:33:10 -0500 (EST)
Received: from d23rh901.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g211SBn328726
        for ; Fri, 1 Mar 2002 12:28:11 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g211X5S92052
	for ; Fri, 1 Mar 2002 12:33:07 +1100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Fri, 1 Mar 2002 09:32:24 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 01/03/2002 09:32:31
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 238
Subject: [Simple] Is there any sip draft for presence status?
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: 

Hi all,

I wonder if there is some sip draft to define user presence status, such as
available/do-not-disturb/away/offline/invisible etc. I think we need a
standard
to describe it.


Best regards,

Tang Lihua
Email:  tanglih@cn.ibm.com


From jdrosen@dynamicsoft.com  Thu Feb 28 21:28:47 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17214
	for ; Thu, 28 Feb 2002 21:28:47 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.62])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g212So6Y020964;
	Thu, 28 Feb 2002 21:28:51 -0500 (EST)
Message-ID: <3C7EE72C.116DAF19@dynamicsoft.com>
Date: Thu, 28 Feb 2002 21:27:56 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Is there any sip draft for presence status?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 924
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: 

See:
http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-01.txt

which is the mandatory presence document format for SIMPLE.

-Jonathan R.

Li Hua Tang wrote:
> 
> Hi all,
> 
> I wonder if there is some sip draft to define user presence status, such
> as
> available/do-not-disturb/away/offline/invisible etc. I think we need a
> standard
> to describe it.
> 
> Best regards,
> 
> Tang Lihua
> Email:  tanglih@cn.ibm.com
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From tanglih@cn.ibm.com  Thu Feb 28 22:12:30 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA17370
	for ; Thu, 28 Feb 2002 22:12:18 -0500 (EST)
Received: from d23rh901.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g2137Jn278806;
        Fri, 1 Mar 2002 14:07:19 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh901.au.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g213CES44116;
	Fri, 1 Mar 2002 14:12:14 +1100
To: Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Fri, 1 Mar 2002 11:11:34 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 01/03/2002 11:11:39
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 695
Subject: [Simple] draft-rosenberg-simple-components-00.txt (Realtime Authorization)
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: 

Jonathan,

Thanks for your indication to user presence status. I find related
definition in RFC2778.

One more question about realtime authorization.

If the presentity has subscribed for winfo event, the PS can send the
pending wacther status to the presentity to ask for authorization. But if
the presentity didn't do so at early time, how can the PS notify it of a
waiting authorization? I read the draft about QAUTH, but it seems a too old
draft and I don't know whether it's still valid (or adopted by other
vendors) now?


Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  tanglih@cn.ibm.com


From jdrosen@dynamicsoft.com  Fri Mar  1 01:49:05 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18058
	for ; Fri, 1 Mar 2002 01:49:05 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.62])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g216nE6Y021194
	for ; Fri, 1 Mar 2002 01:49:14 -0500 (EST)
Message-ID: <3C7F2433.851EE7B5@dynamicsoft.com>
Date: Fri, 01 Mar 2002 01:48:19 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; 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
Content-Length: 1304
Subject: [Simple] updated presence spec
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: 

Folks,

I've just submitted an update to the main presence spec. Until it
appears in the archives, you can grab a copy at:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-05.txt

The changes since -04 are:

  * alignment with sip-events-04
  * alignment with bis-09
  * removal of 3/4 examples, remaining example doesn't show PIDF any
more (we kept getting out of sync)
  * additional words on security, mentioning the new SIPS and S/MIME
capabilities for SIP
  * removal of text redundant with sip-events and bis
  * added a recommendation that PUA implement this package, to allow for
a PA to obtain user presence by subscribing to the various PUA
  * added formal IANA registration of the presence package
  * broke references into normative and informative
  * added 2119 terminology section

This document had already completed working group last call, and was
merely parked behind sip-events. Now that those are done, we can move
forward.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From oran@cisco.com  Fri Mar  1 10:01:29 2002
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22468
	for ; Fri, 1 Mar 2002 10:01:28 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g21F0QZ21467
	for ; Fri, 1 Mar 2002 07:00:36 -0800 (PST)
Received: from oranlt ([161.44.238.50])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ACD60520;
	Fri, 1 Mar 2002 07:00:34 -0800 (PST)
From: "David R. Oran" 
To: 
Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Date: Fri, 1 Mar 2002 10:00:27 -0500
Organization: Cisco Systems
Message-ID: <041201c1c131$d33db740$32ee2ca1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <200202281724.MAA04612@dynasty.cs.columbia.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 4297
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: 

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com 
> [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of 
> Petri K. Koskelainen
> Sent: Thursday, February 28, 2002 12:24 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Re: 
> draft-rosenberg-simple-components-00.txt (threading)
> 
> 
> 
> Hi,
> 
> The draft proposes that In-Reply-To header should
> be used for message threading in paging mode,
> and the draft also states that in message session 
> mode threading is already provided.
> 
> I don't fully agree here. It works for two-party messaging
> but not well in group messaging scenarios.
>
> Problem 1: Message session supports only one discussion thread 
> per session.
> This does not well reflect real-life scenarios. 
> For example, there may be a group chat session with 20 people. 
> It is very likely that they have different
> conversation topics going-on at the same time although they 
> are in the same group. It is also likely that smaller 
> sub-threads emerge and it would be nice if these can be 
> somehow shown in the user interface similarly to current 
> network news UIs. For example, if there are several questions 
> asked in the group and users respond with "yes!" or "no" in 
> the message body it is 
> quite difficult to know to which question they were intended. 
> User Interface could show them nicely if there were header support 
> for it.
>
Actually, I think there are two related, but not identical problems to
be solved here. One is the logical grouping of messages by thread/topic,
for which In-reply-to: is helpful but not completely adequate. The
second is constructing a causal order of the messages in a multi-party
chat session. In-reply-to can in fact be used for this, as long as each
message is in fact tagged with the message-id of the message that
provoked it (some UI support is of course needed to identify this).
However, this usage would conflict with the classical threading usage we
see in newsgroups.

I think the threading/topic stuff would best be solved with adding a
hierarchical structure to the Subject: (or In-reply-to) header, or a new
header, such as "context:"  and some conventions thereto, as was
suggested. However, that leaves the problem of how to establish the
causal order if the In-reply-to header is used. For that, I believe a
new header would be called for.

I frankly find a causal order more useful than a threading feature, but
that may just be me...
 
> 
> Problem 2: Group messaging server creates new Call-IDs for 
> each call-leg. In-Reply-To has also problems in group IM 
> paging mode since the server creates new Call-IDs for each 
> participant. One call-id is valid only between one user and 
> the server. The server has to remember all previous Call-IDs 
> so it can change Call-IDs in In-Reply-To accordingly when somebody 
> is responding to group message. 
> It must have the history and know that a message it sent to Bob 
> a day ago with Call-ID=X is in fact the same message than 
> message sent to Alice with Call-ID=Y. This becomes quite complicated.
>
This would argue for "in-reply-to" (and whatever we use for causal
order) having a global scope as opposed to a dialog/call scope, right.
If we did this and tied the context to the URI of the group chat and not
the dialog, this problem would go away, right?

>  
> Problem 3: Lack of global and common ID for each group 
> message. Now it is difficult to reference a specific group 
> instant message afterwards so that everybody understands it. 
> Only the server has the knowledge (if it keeps the history). 
> The recipients don't know that group IM sent to me with 
> Call-ID=X is the same than group IM sent to Alice with 
> Call-ID=Y. In some cases it would be useful to have the 
> information available in the message.
> 
> 
> These problems can be solved if new header (Message-ID)
> is defined and References header is used (like in NNTP messages).
>
This would work, I think, and if my proposal for causal orders used this
as the referent we could get a long way toward a nice system model.
 
> 
> BR,
> --
> Petri
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com 
> http://mailman.dynamicsoft.com/mailman/listinf> o/simple
> 


From jdrosen@dynamicsoft.com  Sat Mar  2 14:40:14 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27594
	for ; Sat, 2 Mar 2002 14:40:14 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.30])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g22JeK6Y023500
	for ; Sat, 2 Mar 2002 14:40:20 -0500 (EST)
Message-ID: <3C812A6D.BA894505@dynamicsoft.com>
Date: Sat, 02 Mar 2002 14:39:25 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; 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
Content-Length: 984
Subject: [Simple] watcherinfo format draft
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: 

I submitted an update to the watcher info XML specification. This update
basically reflects comments during last call, along with alignment with
sip-events-04. Until it appears, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-simple-winfo-format-01.txt

Changes since -00:

* Changed first-subscribed to refer to the time the subscribe was
first received for this subscription, rather than the first EVER
across subscriptions.

* Removed notify-address element

* Added expiration parameter.

* Removed most-recently-subscribed as per IETF 52 agreement.

* Alignment with sip-events-04

* Generalized to any package, not just presence

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From tanglih@cn.ibm.com  Mon Mar  4 02:50:41 2002
Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04056
	for ; Mon, 4 Mar 2002 02:50:39 -0500 (EST)
Received: from d23rh902.au.ibm.com 
        by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g247iox127394
        for ; Mon, 4 Mar 2002 17:44:50 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g247p5D51006
	for ; Mon, 4 Mar 2002 18:51:06 +1100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Mon, 4 Mar 2002 15:49:57 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 04/03/2002 15:50:00
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 577
Subject: [Simple] watcher info problem in PA/Proxy/Registrar model
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: 

Hi,all

Using a PA/Proxy/Registrar model, I find it's difficult for PS to handle
Event:presence.winfo subscription.

If a Event:presence subscription is proxying (when PS acts as a proxy), PS
can't get to know the watcher status anymore. That means if a presentity
wants to learn who have subscribed to its presence by sending a
Event:presence.winfo subscription, PS can only return watcher info about
which status is pending or waiting. So I doubt the PA/Proxy/Registrar model
again. Is there any good solution to this?


Best regards,

Tang Lihua
Email:  tanglih@cn.ibm.com


From tsearle@indigosw.com  Mon Mar  4 06:39:58 2002
Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id GAA00662
	for ; Mon, 4 Mar 2002 06:39:57 -0500 (EST)
Received: (qmail 10160 invoked by alias); 4 Mar 2002 11:39:09 -0000
Received: from unknown (HELO indigosw.com) (194.78.202.25)
  by 0 with SMTP; 4 Mar 2002 11:39:09 -0000
Message-ID: <3C835CDC.1070309@indigosw.com>
Date: Mon, 04 Mar 2002 12:39:08 +0100
From: Torrey Searle 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 204
Subject: [Simple] Re: is there any draft for presence Status
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: 

In the CPIM draft, it says that the values for the status-type:im will 
be defined in a later document.  Does this document exist, and if so 
where?  

Torrey Searle
Indigo Software
tsearle@indigosw.com


From aseyedeb@npd.hcltech.com  Mon Mar  4 07:09:55 2002
Received: from mailnpd.hcltech.com ([203.197.145.76])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id HAA00774
	for ; Mon, 4 Mar 2002 07:09:53 -0500 (EST)
Received: from npd.hcltech.com ([192.168.100.97])
	by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g24BxNm29886;
	Mon, 4 Mar 2002 17:29:24 +0530
Message-ID: <3C836322.C5B06E1D@npd.hcltech.com>
Date: Mon, 04 Mar 2002 17:35:54 +0530
From: Abdul Rahman Kadir 
Organization: HCL Technologies
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 790
Subject: [Simple] Pls give some info in PS operation ?
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: 

Hi

Can some one help me understanding the foll. in Presence server
operation?



1. Can the SUBSCRIBE request received at the Presence Server be
   REJECTED immediatelty after authentication process is over if    
   there is no access permission for the subscriber or due to any 
   other reason ?.
   
   or SUBSCRIBE request MUST always come to PENDING State before
   getting REJECTED ? - that is, Presence Server will move to pending
   state as no access  permission given for subscriber at present
   (presentity not alive) and will try get it authorized .
   And so after some time slot,it decides to REJECT since subscriber
   not authorized so far.

2. Will there be any access-list present for the subscriber in the
   PS while the presentity is off-line.


thanks
Abdul Rahman

From bcampbell@dynamicsoft.com  Mon Mar  4 19:29:38 2002
Received: from pteam.dfw.dynamicsoft.com (pteam.dfw.dynamicsoft.com [63.110.3.12])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03221
	for ; Mon, 4 Mar 2002 19:29:38 -0500 (EST)
Received: from txbcampbell (pteam.dfw.dynamicsoft.com [63.110.3.12])
	by pteam.dfw.dynamicsoft.com (8.9.3/8.9.3) with SMTP id TAA10807;
	Mon, 4 Mar 2002 19:37:47 -0600
From: "Ben Campbell" 
To: "Abdul Rahman Kadir" ,
        
Subject: RE: [Simple] Pls give some info in PS operation ?
Date: Mon, 4 Mar 2002 18:27:54 -0600
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)
Importance: Normal
In-Reply-To: <3C836322.C5B06E1D@npd.hcltech.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 1610
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: 


> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Abdul Rahman
> Kadir
> Sent: Monday, March 04, 2002 6:06 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Pls give some info in PS operation ?
>
>
> Hi
>
> Can some one help me understanding the foll. in Presence server
> operation?
>
>
>
> 1. Can the SUBSCRIBE request received at the Presence Server be
>    REJECTED immediatelty after authentication process is over if
>    there is no access permission for the subscriber or due to any
>    other reason ?.
>
>    or SUBSCRIBE request MUST always come to PENDING State before
>    getting REJECTED ? - that is, Presence Server will move to pending
>    state as no access  permission given for subscriber at present
>    (presentity not alive) and will try get it authorized .
>    And so after some time slot,it decides to REJECT since subscriber
>    not authorized so far.
>

If the PS can make an immediate decision on the matter, then there is no
need for a pending state. It can just reject the subscription with an
appropriate 400 or 600 class response.


> 2. Will there be any access-list present for the subscriber in the
>    PS while the presentity is off-line.

This depends entirely on the application design and local policy. It is
certainly possible to build a presence service where that is true.


>
>
> thanks
> Abdul Rahman
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From luw@cn.ibm.com  Mon Mar  4 19:56:11 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03325
	for ; Mon, 4 Mar 2002 19:56:10 -0500 (EST)
Received: from d23rh902.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g250pAn215312
        for ; Tue, 5 Mar 2002 10:51:10 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g250ucH86054
	for ; Tue, 5 Mar 2002 11:56:38 +1100
Subject: Re: [Simple] Pls give some info in PS operation ?
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Wei BJ Lu" 
Date: Tue, 5 Mar 2002 08:56:40 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 05/03/2002 08:55:33
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 3129
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: 

See my comments below, starting from ">>>"
------------------------------
Dr. LU Wei
Staff Research Member
Infrastructure Technology
IBM China Research Lab

Phone:   (8610)62986677-549
Tie-line: 905-549
Fax:     (8610)82899634
Email:    luw@cn.ibm.com


                                                                                                                               
                    Abdul Rahman Kadir                                                                                         
                           To:     simple@mailman.dynamicsoft.com                                    
                    Sent by:                         cc:                                                                       
                    simple-admin@mailman.dynam       Subject:     [Simple] Pls give some info in PS operation ?                
                    icsoft.com                                                                                                 
                                                                                                                               
                                                                                                                               
                    2002-03-04 20:05                                                                                           
                    Please respond to Abdul                                                                                    
                    Rahman Kadir                                                                                               
                                                                                                                               
                                                                                                                               



Hi

Can some one help me understanding the foll. in Presence server
operation?



1. Can the SUBSCRIBE request received at the Presence Server be
   REJECTED immediatelty after authentication process is over if
   there is no access permission for the subscriber or due to any
   other reason ?.

   or SUBSCRIBE request MUST always come to PENDING State before
   getting REJECTED ? - that is, Presence Server will move to pending
   state as no access  permission given for subscriber at present
   (presentity not alive) and will try get it authorized .
   And so after some time slot,it decides to REJECT since subscriber
   not authorized so far.

>>>The latter one. If the Presence Server cannot find a policy to
authorize the incoming subscription, it should move to pending state
and wait for the presentity to define a policy for the new watcher.

2. Will there be any access-list present for the subscriber in the
   PS while the presentity is off-line.

>>> Yes. Even if the presentity goes offline, its access list


thanks
Abdul Rahman
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple





From adam@dynamicsoft.com  Mon Mar  4 20:01:35 2002
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 UAA03365
	for ; Mon, 4 Mar 2002 20:01: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 g250weT8007508;
	Mon, 4 Mar 2002 19:58:40 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 4 Mar 2002 20:00:47 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36300E6@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Chiou, Mark'" , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Question regarding SIP-Specific Event Notification
Date: Mon, 4 Mar 2002 20:00:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 684
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: 

Read the section in the draft about forking.

/a

> -----Original Message-----
> From: Chiou, Mark [mailto:MChiou@Santera.com]
> Sent: Wednesday, February 27, 2002 2:18 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Question regarding SIP-Specific Event Notification
> 
> 
> Hi Adam,
> 
> Could you explain why the immediately NOTIFY request is 
> required when Notifier receives a SUBSCRIBER request? For my 
> opinion, the 200 OK response for the SUBSCRIBER request is sufficient.
> 
> Thanks,
> 
> Mark
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jdrosen@dynamicsoft.com  Mon Mar  4 20:20:09 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03447
	for ; Mon, 4 Mar 2002 20:20:09 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.87])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g251KE6Y025479;
	Mon, 4 Mar 2002 20:20:17 -0500 (EST)
Message-ID: <3C841D16.8E0D792A@dynamicsoft.com>
Date: Mon, 04 Mar 2002 20:19:18 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Torrey Searle 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: is there any draft for presence Status
References: <3C835CDC.1070309@indigosw.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 837
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: 

Nope, doesn't exist AFAIK. Please go ahead and write one - its
loooooonnnnnnnggggg overdue.

-Jonathan R.

Torrey Searle wrote:
> 
> In the CPIM draft, it says that the values for the status-type:im will
> be defined in a later document.  Does this document exist, and if so
> where?
> 
> Torrey Searle
> Indigo Software
> tsearle@indigosw.com
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Mon Mar  4 20:21:34 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03454
	for ; Mon, 4 Mar 2002 20:21:33 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.87])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g251LW6Y025482;
	Mon, 4 Mar 2002 20:21:35 -0500 (EST)
Message-ID: <3C841D64.C98CF677@dynamicsoft.com>
Date: Mon, 04 Mar 2002 20:20:36 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1214
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: 


Li Hua Tang wrote:
> 
> Hi,all
> 
> Using a PA/Proxy/Registrar model, I find it's difficult for PS to handle
> Event:presence.winfo subscription.
> 
> If a Event:presence subscription is proxying (when PS acts as a proxy),
> PS
> can't get to know the watcher status anymore.

Right.

> That means if a presentity
> wants to learn who have subscribed to its presence by sending a
> Event:presence.winfo subscription, PS can only return watcher info about
> which status is pending or waiting. So I doubt the PA/Proxy/Registrar
> model
> again. Is there any good solution to this?

The PS wouldn't terminate the subscriptions for watcher information; it
would proxy them, just as it did the original presence information. The
server that handles the subscriptions for some package foo needs to
handle foo.winfo. This is much clearer in the next rev of the
specification.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From tanglih@cn.ibm.com  Mon Mar  4 20:52:11 2002
Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03607
	for ; Mon, 4 Mar 2002 20:52:09 -0500 (EST)
Received: from d23rh902.au.ibm.com 
        by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g251kKx104862;
        Tue, 5 Mar 2002 11:46:20 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g251qWH10716;
	Tue, 5 Mar 2002 12:52:33 +1100
Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model
To: Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Tue, 5 Mar 2002 09:51:25 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 05/03/2002 09:51:30
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 1489
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: 

Jonathan Rosenberg wrote:

>The PS wouldn't terminate the subscriptions for watcher information; it
>would proxy them, just as it did the original presence information. The
>server that handles the subscriptions for some package foo needs to
>handle foo.winfo. This is much clearer in the next rev of the
>specification.

Then who can terminate the subscriptions for watcher information? Let us
detail two cases. These two cases have been described in
draft-ietf-simple-winfo-format-01.

One is a user, A, subscribes to the presence of another user, B. A would
like to find out about the status of their subscription. If no PS, the
subscriptions for watcher information is sent directly to B and it's easy
to do handle it. If there is a PS existing between A and B, my first
question is what will the To header be in SUBSCRIBE request? If it's a
registered SIP address and the request may be forked, another question
comes out. There is no clear definition in winfo-package-00 about how to
handle this forked SUBSCRIBE requests. If the request is proxying and not
forked, B will terminate this subscription.

The other case is a user B, wishes to learn the set of people who have
subscribed to B's presence. What is the To header of this SUBSCRIBE
request? More, if the PS can't terminate this subscription, are they the
set of watchers who return their watcher information to B independently?
It's difficult to understand this way.

Best regards,

Tang Lihua
Email:  tanglih@cn.ibm.com


From jdrosen@dynamicsoft.com  Mon Mar  4 20:57:55 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03647
	for ; Mon, 4 Mar 2002 20:57:55 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.87])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g251vw6Y025534;
	Mon, 4 Mar 2002 20:57:59 -0500 (EST)
Message-ID: <3C8425EC.586661D2@dynamicsoft.com>
Date: Mon, 04 Mar 2002 20:57:00 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2634
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: 


Li Hua Tang wrote:
> 
> Jonathan Rosenberg wrote:
> 
> >The PS wouldn't terminate the subscriptions for watcher information; it
> >would proxy them, just as it did the original presence information. The
> >server that handles the subscriptions for some package foo needs to
> >handle foo.winfo. This is much clearer in the next rev of the
> >specification.
> 
> Then who can terminate the subscriptions for watcher information?

Whatever element is terminating the presence subscriptions.

> Let us
> detail two cases. These two cases have been described in
> draft-ietf-simple-winfo-format-01.
> 
> One is a user, A, subscribes to the presence of another user, B. A would
> like to find out about the status of their subscription. If no PS, the
> subscriptions for watcher information is sent directly to B and it's
> easy
> to do handle it. If there is a PS existing between A and B, my first
> question is what will the To header be in SUBSCRIBE request?

Same as it was for the SUBSCRIBE for presence state.

> If it's a
> registered SIP address and the request may be forked, another question
> comes out. There is no clear definition in winfo-package-00 about how to
> handle this forked SUBSCRIBE requests. If the request is proxying and
> not
> forked, B will terminate this subscription.

winfo-package-01 talks about this case. It recommends that the
watcherinfo subscription be sent on the same dialog as the presence
subscription. THis guarantees that the same server handling presence, is
also handling watcherinfo.


> 
> The other case is a user B, wishes to learn the set of people who have
> subscribed to B's presence. What is the To header of this SUBSCRIBE
> request?

Same as it was for the presence subscription.

> More, if the PS can't terminate this subscription, are they the
> set of watchers who return their watcher information to B independently?
> It's difficult to understand this way.

There are two solutions for this case. Both are docuented in -01. In the
first case, the PS will fork the watcherinfo subscription, and the
result is that multiple subscriptions are installed. In the second case,
the PS can direct the watcherinfo subscription to a server that the
network has explicitly designated as the winfo server, and it knows
about all watchers. 

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From tanglih@cn.ibm.com  Tue Mar  5 02:27:38 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04629
	for ; Tue, 5 Mar 2002 02:27:20 -0500 (EST)
Received: from d23rh902.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g257Lrn310940;
        Tue, 5 Mar 2002 17:21:54 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g257RJH47720;
	Tue, 5 Mar 2002 18:27:20 +1100
To: Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Tue, 5 Mar 2002 15:26:12 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 05/03/2002 15:26:17
MIME-Version: 1.0
Content-type: text/plain; charset=gb2312
Content-Length: 348
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id CAA04629
Subject: [Simple] id attribute of winfo format?
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: 

Jonathan£¬

I go to see the winfo-package-01 (at
http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-01.txt) and
it mentions an id attribute of winfo format. But I can't find this
attribute in the latest winfo-format-01. Do I misunderstand somthing or a
new version is coming soon?


Best regards,

Tang Lihua
Email:  tanglih@cn.ibm.com

From tanglih@cn.ibm.com  Tue Mar  5 02:50:39 2002
Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.COM [202.135.136.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04730
	for ; Tue, 5 Mar 2002 02:50:34 -0500 (EST)
Received: from d23rh901.au.ibm.com 
        by ausmtp02.au.ibm.com (IBM AP 2.0) with ESMTP id g257ikx65068;
        Tue, 5 Mar 2002 17:44:46 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh901.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g257oQ532636;
	Tue, 5 Mar 2002 18:50:27 +1100
Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model
To: Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Tue, 5 Mar 2002 15:49:54 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 05/03/2002 15:49:56
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 1666
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: 

Jonathan Rosenberg wrote:
>It recommends that the
>watcherinfo subscription be sent on the same dialog as the presence
>subscription. THis guarantees that the same server handling presence, is
>also handling watcherinfo.
Why the same dialog? It's possible that no presence subscription hasn't
been sent before a winfo subscription. And a SUBSCRIBE request for winfo
will definitely create a new dialog since it has a new callID.

>> More, if the PS can't terminate this subscription, are they the
>> set of watchers who return their watcher information to B independently?
>> It's difficult to understand this way.

>There are two solutions for this case. Both are docuented in -01. In the
>first case, the PS will fork the watcherinfo subscription, and the
>result is that multiple subscriptions are installed. In the second case,
>the PS can direct the watcherinfo subscription to a server that the
>network has explicitly designated as the winfo server, and it knows
>about all watchers.

I'm much confused. What you have said seems selfcontradicting. Since PS
will handle the presence subscription, in your opinion, the PS should be
the same server to handle the winfo subscription. Return to my original
question. If the PS uses PA/Proxy/Registrar model, it can't act as the
winfo server at the same time. Due to the recursion, it's reasonable to
colocate presence sever and winfo server. But if the SUBSCRIBE request is
proxying, the server will lose control of presence status.

One more point I am not very clear about winfo-package-01. Should a
notification of winfo subscription return immediately?

Best regards,
Tang Lihua
Email:  tanglih@cn.ibm.com




From jdrosen@dynamicsoft.com  Tue Mar  5 03:08:20 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04805
	for ; Tue, 5 Mar 2002 03:08:19 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.67])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2588J6Y025722;
	Tue, 5 Mar 2002 03:08:20 -0500 (EST)
Message-ID: <3C847CBB.6423FBF4@dynamicsoft.com>
Date: Tue, 05 Mar 2002 03:07:23 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
References: 
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 902
Subject: [Simple] Re: id attribute of winfo format?
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: 


Li Hua Tang wrote:
> 
> Jonathan£¬
> 
> I go to see the winfo-package-01 (at
> http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-01.txt)
> and
> it mentions an id attribute of winfo format. But I can't find this
> attribute in the latest winfo-format-01. Do I misunderstand somthing or
> a
> new version is coming soon?

It will be in the -02 version. I got overzealous and submitted the
format document before revving the package document. While doing the
package document, I realized I needed this change to the format
document. My apologies.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Tue Mar  5 03:12:58 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04843
	for ; Tue, 5 Mar 2002 03:12:57 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.67])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g258D36Y025725;
	Tue, 5 Mar 2002 03:13:03 -0500 (EST)
Message-ID: <3C847DD7.1EE1E7EE@dynamicsoft.com>
Date: Tue, 05 Mar 2002 03:12:07 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3002
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: 


Li Hua Tang wrote:
> 
> Jonathan Rosenberg wrote:
> >It recommends that the
> >watcherinfo subscription be sent on the same dialog as the presence
> >subscription. THis guarantees that the same server handling presence,
> is
> >also handling watcherinfo.
>
> Why the same dialog? 

So that it gets to the same server handling the presence subscription.

> It's possible that no presence subscription hasn't
> been sent before a winfo subscription.

That is not the case we are discussing. IN this case, a user wants to
track the status of his own subscription to some other resource. By
definition, this is a watcherinfo subscription associated with some
other existing subscription.


> And a SUBSCRIBE request for winfo
> will definitely create a new dialog since it has a new callID.

Not in this case. The meaning of sending the subscription on the same
dialog is to reuse the call-id, to, from.


> 
> >> More, if the PS can't terminate this subscription, are they the
> >> set of watchers who return their watcher information to B
> independently?
> >> It's difficult to understand this way.
> 
> >There are two solutions for this case. Both are docuented in -01. In
> the
> >first case, the PS will fork the watcherinfo subscription, and the
> >result is that multiple subscriptions are installed. In the second
> case,
> >the PS can direct the watcherinfo subscription to a server that the
> >network has explicitly designated as the winfo server, and it knows
> >about all watchers.
> 
> I'm much confused. What you have said seems selfcontradicting. Since PS
> will handle the presence subscription, in your opinion, the PS should be
> the same server to handle the winfo subscription. 

Whatever handles the presence subscription, handles the watcherinfo
subscriptions.


> Return to my original
> question. If the PS uses PA/Proxy/Registrar model, it can't act as the
> winfo server at the same time.

Now to me, you are saying contradicting things. Either the PS is a PA,
or it is a proxy. If its a PA, it terminates the watcherinfo
subscriptions. If its a proxy, it proxies the watcherinfo subscriptions.


> Due to the recursion, it's reasonable to
> colocate presence sever and winfo server. But if the SUBSCRIBE request
> is
> proxying, the server will lose control of presence status.

Whatever handles the presence subscription, handles the watcherinfo
subscriptions.

> 
> One more point I am not very clear about winfo-package-01. Should a
> notification of winfo subscription return immediately?

What does "return immediately" mean? It generates an immediate NOTIFY,
if that is what you mean. That is true for all sip event packages.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From tanglih@cn.ibm.com  Tue Mar  5 07:32:07 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05729
	for ; Tue, 5 Mar 2002 07:32:05 -0500 (EST)
Received: from d23rh901.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g258wWn12948;
        Tue, 5 Mar 2002 18:58:32 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh901.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2593P564160;
	Tue, 5 Mar 2002 20:03:26 +1100
Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model
To: Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Tue, 5 Mar 2002 17:02:52 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 05/03/2002 17:02:56
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 1677
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: 


Jonathan Rosenberg wrote:

> > It's possible that no presence subscription hasn't
> > been sent before a winfo subscription.

> That is not the case we are discussing. IN this case, a user wants to
> rack the status of his own subscription to some other resource. By
> definition, this is a watcherinfo subscription associated with some
> other existing subscription.

> > And a SUBSCRIBE request for winfo
> > will definitely create a new dialog since it has a new callID.

> Not in this case. The meaning of sending the subscription on the same
> dialog is to reuse the call-id, to, from.

I can't agree with you. In order to do realtime authorization (or say, in
oder to be notified as soon as being subscribed), the presentity can send
winfo subscription to the PS first even if there is no presence
subscription to it. It's independent on whether a watcher has subscribed or
will subscribe to the resource of this presentity. It's not associated with
an exsiting subscription.

And it can be guaranteed that all the winfo subscriptions to one resource
have the same callid since they may be generated by any watcher or the
presentity itself.

> Now to me, you are saying contradicting things. Either the PS is a PA,
> or it is a proxy. If its a PA, it terminates the watcherinfo
> subscriptions. If its a proxy, it proxies the watcherinfo subscriptions.

Either the PS is a PA, or it is a proxy. Do you mean the PS can't be a
combination of PA/Proxy/Registrar? Or do you mean the PS can't change the
role between PA and Proxy when handling subscriptions whenever the
presentity changes status (available or not)?

Best regards,

Tang Lihua
Email:  tanglih@cn.ibm.com




From nsyracus@cnri.reston.va.us  Tue Mar  5 06:33:03 2002
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 GAA05532
	for ; Tue, 5 Mar 2002 06:33:02 -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 GAA24297;
	Tue, 5 Mar 2002 06:32:12 -0500 (EST)
Message-Id: <200203051132.GAA24297@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
Date: Tue, 05 Mar 2002 06:32:12 -0500
Content-Length: 3007
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-05.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: SIP Extensions for Presence
	Author(s)	: J. Rosenberg et al.
	Filename	: draft-ietf-simple-presence-05.txt
	Pages		: 27
	Date		: 04-Mar-02
	
This document proposes an extension to SIP for subscriptions and
notifications of user presence. User presence is defined as the
willingness and ability of a user to communicate with other users on
the network. Historically, presence has been limited to 'on-line' and
'off-line' indicators; the notion of presence here is broader.
Subscriptions and notifications of user presence are supported by
defining an event package within the general SIP event notification
framework. This protocol is also compliant with the Common Presence
and Instant Messaging (CPIM) framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-presence-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-presence-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020304141759.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020304141759.I-D@ietf.org>

--OtherAccess--

--NextPart--



From LAM@zurich.ibm.com  Wed Mar  6 05:08:24 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09771
	for ; Wed, 6 Mar 2002 05:08:24 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id LAA88668
	for ; Wed, 6 Mar 2002 11:07:29 +0100
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g26A9TX92728
	for ; Wed, 6 Mar 2002 11:09:29 +0100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
From: "Lamine Brahimi" 
Date: Wed, 6 Mar 2002 11:07:13 +0100
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.9a |January 7, 2002) at
 06/03/2002 11:07:27
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 1161
Subject: [Simple] about Cseq  sequence numbers
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: 

Dear all,

Suppose a watcher subscribes to a presentity presence info with
an initial SUBSCRIBE msg  with a Cseq value of 1.
the watcher receives the corresponding NOTIFY  with a Cseq value of 1 (the
same).
Then the presentity updates several times its presence info and the watcher
receives several NOTIFY with incremented Cseq values. (ie if the presence
info changed twice
the last NOTIFY has a Cseq value of 3, right ?).
Then when the watcher wants to refresh its subscription I do that:
it sends a SUBSCRIBE with a CSeq value of 2 and a matching Dialog To tag.
 It receives its corresponding NOTIFY with a CSeq value of 2.
So my (little) problem is that I have two transactions which have the same
Cseq number of 2 in the same dialog :
the latest NOTIFY and the first one notifying an update in Presentity
presence info.
Is it correct like that ?
A possible solution to avoid that is to set the Cseq value of the
refreshing SUBSCRIBE to a value one
higher than the latest NOTIFY received in that dialog (in our case 4, if
presence info changed twice before the refresh)
and not the latest SUBSCRIBE sent.

Does someone knows what to do ?
Thanks,
Lamine.


From hisham.khartabil@nokia.com  Wed Mar  6 05:56:05 2002
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 FAA09960
	for ; Wed, 6 Mar 2002 05:55:55 -0500 (EST)
From: hisham.khartabil@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 g26AssZ05940
	for ; Wed, 6 Mar 2002 12:54:54 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 6 Mar 2002 12:54:42 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 6 Mar 2002 12:54:44 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] about Cseq  sequence numbers
Date: Wed, 6 Mar 2002 12:54:43 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77790BA@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] about Cseq  sequence numbers
Thread-Index: AcHE92FXAo8wUHyBS7+pdks+fbH4fwABXWLQ
To: , 
X-OriginalArrivalTime: 06 Mar 2002 10:54:44.0052 (UTC) FILETIME=[52F32140:01C1C4FD]
Content-Length: 1879
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA09960
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: 

The SUBSCRIBE CSeq and NOTIFY CSeq are independent.

Your Subscription refresh carried a Cseq of 2. The NOTIFY following that should carry a Cseq of 5. When receiving a NOTIFY, all you do is update the Dialog state with the new remote Cseq.

Regards,
Hisham

> -----Original Message-----
> From: ext Lamine Brahimi [mailto:LAM@zurich.ibm.com]
> Sent: Wednesday, March 06, 2002 12:07 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] about Cseq sequence numbers
> 
> 
> 
> Dear all,
> 
> Suppose a watcher subscribes to a presentity presence info with
> an initial SUBSCRIBE msg  with a Cseq value of 1.
> the watcher receives the corresponding NOTIFY  with a Cseq 
> value of 1 (the
> same).
> Then the presentity updates several times its presence info 
> and the watcher
> receives several NOTIFY with incremented Cseq values. (ie if 
> the presence
> info changed twice
> the last NOTIFY has a Cseq value of 3, right ?).
> Then when the watcher wants to refresh its subscription I do that:
> it sends a SUBSCRIBE with a CSeq value of 2 and a matching 
> Dialog To tag.
>  It receives its corresponding NOTIFY with a CSeq value of 2.
> So my (little) problem is that I have two transactions which 
> have the same
> Cseq number of 2 in the same dialog :
> the latest NOTIFY and the first one notifying an update in Presentity
> presence info.
> Is it correct like that ?
> A possible solution to avoid that is to set the Cseq value of the
> refreshing SUBSCRIBE to a value one
> higher than the latest NOTIFY received in that dialog (in our 
> case 4, if
> presence info changed twice before the refresh)
> and not the latest SUBSCRIBE sent.
> 
> Does someone knows what to do ?
> Thanks,
> Lamine.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From bcampbell@dynamicsoft.com  Wed Mar  6 11:20:09 2002
Received: from pteam.dfw.dynamicsoft.com (pteam.dfw.dynamicsoft.com [63.110.3.12])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10934
	for ; Wed, 6 Mar 2002 11:20:08 -0500 (EST)
Received: from txbcampbell (pteam.dfw.dynamicsoft.com [63.110.3.12])
	by pteam.dfw.dynamicsoft.com (8.9.3/8.9.3) with SMTP id LAA27050;
	Wed, 6 Mar 2002 11:28:09 -0600
From: "Ben Campbell" 
To: "Lamine Brahimi" , 
Subject: RE: [Simple] about Cseq  sequence numbers
Date: Wed, 6 Mar 2002 10:18:09 -0600
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
In-Reply-To: 
Importance: Normal
Content-Length: 2276
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: 

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Lamine Brahimi
> Sent: Wednesday, March 06, 2002 4:07 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] about Cseq sequence numbers
>
>
>
> Dear all,
>
> Suppose a watcher subscribes to a presentity presence info with
> an initial SUBSCRIBE msg  with a Cseq value of 1.
> the watcher receives the corresponding NOTIFY  with a Cseq value of 1 (the
> same).
> Then the presentity updates several times its presence info and
> the watcher
> receives several NOTIFY with incremented Cseq values. (ie if the presence
> info changed twice
> the last NOTIFY has a Cseq value of 3, right ?).
> Then when the watcher wants to refresh its subscription I do that:
> it sends a SUBSCRIBE with a CSeq value of 2 and a matching Dialog To tag.
>  It receives its corresponding NOTIFY with a CSeq value of 2.
> So my (little) problem is that I have two transactions which have the same
> Cseq number of 2 in the same dialog :
> the latest NOTIFY and the first one notifying an update in Presentity
> presence info.

No. Each endpoint has its own separate CSeq state for requests--that is,
each endpoint has its own numbering sequence for requests. In your example,
the NOTIFY after the re-subscribe would have a CSeq of 4 (the next in
sequence of all the NOTIFYs). The NOTIFY does not share the CSeq of the
INVITE. (Note that NOTIFY is a request, not a response.) In your example, it
is only coincidence that the initial SUBSCRIBE and NOTIFY had the same CSeq.
(In the real world, CSeqs should rarely start with 1, and each side would
probably choose a different initial CSeq.)




> Is it correct like that ?
> A possible solution to avoid that is to set the Cseq value of the
> refreshing SUBSCRIBE to a value one
> higher than the latest NOTIFY received in that dialog (in our case 4, if
> presence info changed twice before the refresh)
> and not the latest SUBSCRIBE sent.

No, that is incorrect behavior.  See above.


>
> Does someone knows what to do ?
> Thanks,
> Lamine.
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From nsyracus@cnri.reston.va.us  Wed Mar  6 13:43:28 2002
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 NAA11425
	for ; Wed, 6 Mar 2002 13:43:27 -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 NAA26289;
	Wed, 6 Mar 2002 13:42:36 -0500 (EST)
Message-Id: <200203061842.NAA26289@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 06 Mar 2002 13:42:36 -0500
Content-Length: 2484
Subject: [Simple] I-D ACTION:draft-ietf-sip-message-01.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: SIP Extensions for Instant Messaging
	Author(s)	: J. Rosenberg et al.
	Filename	: draft-ietf-sip-message-01.txt
	Pages		: 22
	Date		: 05-Mar-02
	
This document defines a SIP extension (a single new method) that
supports Instant Messaging (IM).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-message-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-message-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020305135345.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-message-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-message-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020305135345.I-D@ietf.org>

--OtherAccess--

--NextPart--



From jdrosen@dynamicsoft.com  Thu Mar  7 15:55:51 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16303
	for ; Thu, 7 Mar 2002 15:55:50 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g27Ktt6Y028625;
	Thu, 7 Mar 2002 15:55:55 -0500 (EST)
Message-ID: <3C87D3A0.AE0A55CA@dynamicsoft.com>
Date: Thu, 07 Mar 2002 15:54:56 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] watcher info problem in PA/Proxy/Registrar model
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3448
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: 


Li Hua Tang wrote:
> 
> Jonathan Rosenberg wrote:
> 
> > > It's possible that no presence subscription hasn't
> > > been sent before a winfo subscription.
> 
> > That is not the case we are discussing. IN this case, a user wants to
> > rack the status of his own subscription to some other resource. By
> > definition, this is a watcherinfo subscription associated with some
> > other existing subscription.
> 
> > > And a SUBSCRIBE request for winfo
> > > will definitely create a new dialog since it has a new callID.
> 
> > Not in this case. The meaning of sending the subscription on the same
> > dialog is to reuse the call-id, to, from.
> 
> I can't agree with you. In order to do realtime authorization (or say,
> in
> oder to be notified as soon as being subscribed), the presentity can
> send
> winfo subscription to the PS first even if there is no presence
> subscription to it. It's independent on whether a watcher has subscribed
> or
> will subscribe to the resource of this presentity. It's not associated
> with
> an exsiting subscription.

That is correct, but that is not the case I am talking about here. I
think we are talking past each other.

There are TWO separate uses of a watcher info subscription. One, is a
subscription by the watcher themself, and the other, is from the
presentity. Pictorially:

     Please view in a fixed-width font such as Courier.



           (1) sub winfo            (2) sub winfo
       +-------------------+    +---------------------+
       |                   |    |                     |
       |                   V    V                     |
  +--------+             +--------+              +----+---+
  |presence|             |        |              |        |
  | watcher|------------>|  PA    |<------------ |presentity
  |        | sub presence|        |  publish pres|        |
  |        |             |        |              |        |
  +--------+             +--------+              +--------+

Case (1) is the presence subscriber being the watcherinfo subscriber.
Case (2) is the presentity being the watcherinfo subscriber.

In case (1), the winfo subscription, by definition, follows a presence
subscription. It can therefore go on the same dialog. In case (2), the
winfo subscription happens independently, and needs to go to all PA
which are publishing presence for that presentity.

> > Now to me, you are saying contradicting things. Either the PS is a PA,
> > or it is a proxy. If its a PA, it terminates the watcherinfo
> > subscriptions. If its a proxy, it proxies the watcherinfo
> subscriptions.
> 
> Either the PS is a PA, or it is a proxy. Do you mean the PS can't be a
> combination of PA/Proxy/Registrar? Or do you mean the PS can't change
> the
> role between PA and Proxy when handling subscriptions whenever the
> presentity changes status (available or not)?

No. I am saying that if a PS is a proxy for a presence subscription, it
has to be a proxy for a watcherinfo subscription for the same user. If a
PS is a PA for a presence subscription, it has to be a PA for a
watcherinfo subscription for the same user.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Fri Mar  8 00:21:32 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17792
	for ; Fri, 8 Mar 2002 00:21:31 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g285KV6Y029017;
	Fri, 8 Mar 2002 00:20:32 -0500 (EST)
Message-ID: <3C8849E5.5066603F@dynamicsoft.com>
Date: Fri, 08 Mar 2002 00:19:33 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1030
Subject: [Simple] Re: draft-rosenberg-simple-components-00.txt (Realtime Authorization)
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: 


Li Hua Tang wrote:
> 
> Jonathan,
> 
> Thanks for your indication to user presence status. I find related
> definition in RFC2778.
> 
> One more question about realtime authorization.
> 
> If the presentity has subscribed for winfo event, the PS can send the
> pending wacther status to the presentity to ask for authorization. But
> if
> the presentity didn't do so at early time, how can the PS notify it of a
> waiting authorization?

If the presentity wants to find out about waiting or pending
subscriptions, it needs to subscribe to, or fetch, watcherinfo. If the
presentity doesn't subscribe or fetch the watcherinfo, it won't know,
and there is no way for the server to tell it.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Fri Mar  8 01:27:55 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18007
	for ; Fri, 8 Mar 2002 01:27:55 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g286RW6Y029063;
	Fri, 8 Mar 2002 01:27:34 -0500 (EST)
Message-ID: <3C885999.CC029951@dynamicsoft.com>
Date: Fri, 08 Mar 2002 01:26:33 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Petri K. Koskelainen" 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
References: <200202281724.MAA04612@dynasty.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3625
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: 


"Petri K. Koskelainen" wrote:
> 
> Hi,
> 
> The draft proposes that In-Reply-To header should
> be used for message threading in paging mode,
> and the draft also states that in message session
> mode threading is already provided.
> 
> I don't fully agree here. It works for two-party messaging
> but not well in group messaging scenarios.

It is good that we are finally having some discussion on this.
Do note that draft-ietf-sip-message does actually talk about 
In-Reply-To as the threading mechanism...

> 
> Problem 1: Message session supports only one discussion thread
> per session.
> This does not well reflect real-life scenarios.
> For example, there may be a group chat session with 20 people.
> It is very likely that they have different
> conversation topics going-on at the same time although they
> are in the same group. It is also likely that smaller sub-threads
> emerge and it would be nice if these can be somehow shown
> in the user interface similarly to current network news UIs.
> For example, if there are several questions asked in the group
> and users respond with "yes!" or "no" in the message body it is
> quite difficult to know to which question they were intended.
> User Interface could show them nicely if there were header support
> for it.

I'll buy that this would be handy, although not super critical. 
If MESSAGE were used for messaging within the session model,
wouldn't In-Reply-To be sufficient for it?

> 
> Problem 2: Group messaging server creates new Call-IDs for each call-leg.
> In-Reply-To has also problems in group IM paging mode
> since the server creates new Call-IDs for each
> participant. One call-id is valid only between one user and the server.
> The server has to remember all previous Call-IDs so
> it can change Call-IDs in In-Reply-To accordingly when somebody
> is responding to group message.
> It must have the history and know that a message it sent to Bob
> a day ago with Call-ID=X is in fact the same message than
> message sent to Alice with Call-ID=Y. This becames quite complicated.

No doubt.

A discussion we REALLY need to have, is whether we think that the paging
model even makes sense for multiparty. I am really not convinced. It
seems that multiparty paging model is really more like email, and that
is not what IM is supposed to be. If group IM is supposed to be real
time, It just works so much better in the session model. So many
problems (like this one above) just evaporate.

Can anyone suggest a reason why the paging model is preferrable for
group chat? Simplicity is one, but that simplicity might be elusive as
you try to fill in all the missing pieces.

> 
> 
> Problem 3: Lack of global and common ID for each group message.
> Now it is difficult to reference a specific group instant message
> afterwards so that everybody understands it. Only the server
> has the knowledge (if it keeps the history). The recipients
> don't know that group IM sent to me with Call-ID=X is the same than
> group IM sent to Alice with Call-ID=Y. In some cases it would
> be useful to have the information available in the message.

Agree that a unique message ID is needed. For session model, if MESSAGE
is used, it is NOT clear to me that Call-ID would have to change for
each leg of the conference.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Fri Mar  8 01:34:32 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18053
	for ; Fri, 8 Mar 2002 01:34:32 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g286Yc6Y029067;
	Fri, 8 Mar 2002 01:34:38 -0500 (EST)
Message-ID: <3C885B44.4D8F4D6B@dynamicsoft.com>
Date: Fri, 08 Mar 2002 01:33:40 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "David R. Oran" 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
References: <041201c1c131$d33db740$32ee2ca1@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2927
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: 


"David R. Oran" wrote:
> 

> > Problem 1: Message session supports only one discussion thread
> > per session.
> > This does not well reflect real-life scenarios.
> > For example, there may be a group chat session with 20 people.
> > It is very likely that they have different
> > conversation topics going-on at the same time although they
> > are in the same group. It is also likely that smaller
> > sub-threads emerge and it would be nice if these can be
> > somehow shown in the user interface similarly to current
> > network news UIs. For example, if there are several questions
> > asked in the group and users respond with "yes!" or "no" in
> > the message body it is
> > quite difficult to know to which question they were intended.
> > User Interface could show them nicely if there were header support
> > for it.
> >
> Actually, I think there are two related, but not identical problems to
> be solved here. One is the logical grouping of messages by thread/topic,
> for which In-reply-to: is helpful but not completely adequate. The
> second is constructing a causal order of the messages in a multi-party
> chat session.

Good observation. I think you are right.

 In-reply-to can in fact be used for this, as long as each
> message is in fact tagged with the message-id of the message that
> provoked it (some UI support is of course needed to identify this).
> However, this usage would conflict with the classical threading usage we
> see in newsgroups.

In-Reply-To can play either role, depending on what you think should go
in there. If, when you respond to a message, you place into In-Reply-To,
the value of In-Reply-To from the message you are responding to, you get
threading. You change threads by basically deleting In-Reply-To when you
create a new thread. If you place into In-Reply-To, the Call-ID of the
message you are responding to, you get causal order. Its not clear which
is a "more correct" usage of In-Reply-To. If I had to guess, its
probably the latter usage, which would get you causal order.

> 
> I think the threading/topic stuff would best be solved with adding a
> hierarchical structure to the Subject: (or In-reply-to) header, or a new
> header, such as "context:"  and some conventions thereto, as was
> suggested. However, that leaves the problem of how to establish the
> causal order if the In-reply-to header is used. For that, I believe a
> new header would be called for.

Why is a new header needed for causal order if you use In-Reply-To?

Theading may very well better be handled by Subject. I hadn't thought
about that....

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Fri Mar  8 01:53:20 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18142
	for ; Fri, 8 Mar 2002 01:53:20 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g286rT6Y029083;
	Fri, 8 Mar 2002 01:53:29 -0500 (EST)
Message-ID: <3C885FAF.A82A3222@dynamicsoft.com>
Date: Fri, 08 Mar 2002 01:52:31 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tony Hansen 
CC: SIMPLE list 
Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again)
References: <20020206000526.76476.qmail@web11608.mail.yahoo.com> <3C7C0CCC.D6EBC1BC@att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2795
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: 


Tony Hansen wrote:
> 
> Here are some ideas on how this could play out within the IETF.
> 
> One of the documents being put out in the SIP WG is SIP Call Flow
> Examples. It shows how the SIP protocol should be used in an IP
> Telephony service.
> 
> Another effort in the IETF is the Voice Profile for Internet Messaging
> (VPIM) working group. That group has been figuring out how to do voice
> messaging (for voice mailboxes) using existing protocols, such as SMTP
> and IMAP. Where the existing protocols were lacking, they also worked on
> filling in the gaps, either within the VPIM WG or in conjunction with
> other working groups (e.g., imap-ext). Note: the VPIM WG was originally
> formed due to input from an external organization, the EMA, but the work
> has all been done here in the IETF.
> 
> The problem we're facing here in SIMPLE seems to be in the same
> category, and the solution may be similar. It appears that what is
> required is a profile for an instant messaging service saying how it
> should pull together the different piece parts to form a coherent whole.

Well, there are two parts.

Part one, is to specify the pieces, and to make sure they are all there.
Part two, is to specify an architecture that puts them together as a
whole.

Part one is definitely an IETF activity. We really have most of the
pieces, and the few that remain, are easy. I have written an I-D on this
subject, which discusess the pieces needed for a consumer IM/buddy-list
application:

http://www.ietf.org/internet-drafts/draft-rosenberg-simple-components-00.txt

I'd really like to get group input on whether there is
interest/agreement on which aspects of my proposed plan.

The second piece, part two, is to specify an architecture that pulls it
all together. If such a thing were done here, it would need to be
informational to say the least. There is precendent for publication of
informational architecture docs generated by other bodies (the DCS
architecture). I think SOMEONE needs to put this together, that is for
certain. If no one else is stepping up to the plate, I'd prefer IETF to
nobody, thats for sure.

> 
> I'm convinced we can solve this problem. Getting feedback from the
> industry is absolutely useful in the process, but I think the work needs
> to happen here, in the IETF. And I'm willing to work on it.
> 
> Comments? Should something like this go on the SIMPLE agenda for
> Minneapolis?

I'd like to discuss it, yes.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From vektor@fdd.com  Fri Mar  8 02:08:26 2002
Received: from fdd.com (dsl081-147-080.chi1.dsl.speakeasy.net [64.81.147.80])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18212
	for ; Fri, 8 Mar 2002 02:08:26 -0500 (EST)
Received: (from vektor@localhost)
	by fdd.com (8.11.3/8.10.1) id g2877Wt30719;
	Fri, 8 Mar 2002 01:07:32 -0600 (CST)
Date: Fri, 8 Mar 2002 01:07:31 -0600
From: Billy Biggs 
To: Jonathan Rosenberg 
Cc: "Petri K. Koskelainen" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Message-ID: <20020308010731.A17757@dumbterm.net>
References: <200202281724.MAA04612@dynasty.cs.columbia.edu> <3C885999.CC029951@dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3C885999.CC029951@dynamicsoft.com>; from jdrosen@dynamicsoft.com on Fri, Mar 08, 2002 at 01:26:33AM -0500
Content-Length: 1562
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: 

Jonathan Rosenberg (jdrosen@dynamicsoft.com):

> A discussion we REALLY need to have, is whether we think that the
> paging model even makes sense for multiparty. I am really not
> convinced. It seems that multiparty paging model is really more like
> email, and that is not what IM is supposed to be. If group IM is
> supposed to be real time, It just works so much better in the session
> model. So many problems (like this one above) just evaporate.
> 
> Can anyone suggest a reason why the paging model is preferrable for
> group chat? Simplicity is one, but that simplicity might be elusive as
> you try to fill in all the missing pieces.

  The session model for group messaging implies the existance of a
centralized server, otherwise it becomes unmanageable (all the
complexities of distributed state in a full mesh).  If all messaging is
done through paging, it seems like you could build an end-to-end
conference on the fly with transparent migration from point-to-point and
multi-recipient messages.

  I believe that the simplicity remains only if you allow membership
inconsistencies, like email.  Each group member retains their own
membership state which may or may not match the other recipients, and
while optional membership add/drop requests may be sent by members, each
client is ultimately free to make their own decisions as to who they
send messages to.  This allows for 'bcc' functionality as well.

  However, if messages are not autonomous and themselves contain state,
this would break the model.

-- 
Billy Biggs
billy@billybiggs.com

From tsearle@indigosw.com  Fri Mar  8 06:34:40 2002
Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id GAA19029
	for ; Fri, 8 Mar 2002 06:34:39 -0500 (EST)
Received: (qmail 23171 invoked by alias); 8 Mar 2002 11:33:50 -0000
Received: from unknown (HELO indigosw.com) (194.78.202.25)
  by 0 with SMTP; 8 Mar 2002 11:33:50 -0000
Message-ID: <3C88A1A5.8020102@indigosw.com>
Date: Fri, 08 Mar 2002 12:33:57 +0100
From: Torrey Searle 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 683
Subject: [Simple] Date header and offline messages
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: 

in 9.5 it seems to allow for a store and forward mechanism with sip 
messaging.
Am I correct in assuming that the Date header a forwared delayed request 
must have an updated date header to avoid being blocked by the replay 
prevention described in 11.3?

If the date header is updated on the forward, can there be an 
"Originally-Sent" header?  In the case when a message stored on the 
server because the final destination was offline.  Informing the user of 
the time the message originally was sent can be informative.  IM 
services such as Yahoo also have timestamps to indicate when an offline 
message was originally sent.

Torrey Searle
Indigo Software
tsearle@indigosw.com


From nsyracus@cnri.reston.va.us  Fri Mar  8 07:01:10 2002
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 HAA19133
	for ; Fri, 8 Mar 2002 07:01:10 -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 HAA00150;
	Fri, 8 Mar 2002 07:00:19 -0500 (EST)
Message-Id: <200203081200.HAA00150@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
Date: Fri, 08 Mar 2002 07:00:19 -0500
Content-Length: 2970
Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-package-01.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: A SIP Event Sub-Package for Watcher Information
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-winfo-package-01.txt
	Pages		: 17
	Date		: 07-Mar-02
	
This document defines the watcher information sub-package for the SIP
event infrastructure. Watcher information refers to the set of users
subcribed to a particular resource within a particular event package.
This set changes dynamically as users subscribe, unsubscribe, are
approved, or are rejected. A subscriber can subscribe to this
information, and therefore learn about changes to it. This event
package is a sub-package because it can be applied to any event
package, including itself.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-winfo-package-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-winfo-package-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020307120938.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-winfo-package-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-winfo-package-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020307120938.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Fri Mar  8 07:01:15 2002
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 HAA19138
	for ; Fri, 8 Mar 2002 07:01:14 -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 HAA00180;
	Fri, 8 Mar 2002 07:00:24 -0500 (EST)
Message-Id: <200203081200.HAA00180@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
Date: Fri, 08 Mar 2002 07:00:24 -0500
Content-Length: 2754
Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-format-01.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: An XML Based Format for Watcher Information
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-winfo-format-01.txt
	Pages		: 10
	Date		: 07-Mar-02
	
Watchers are defined as entities that request (i.e., subscribe to)
information about a resource. There is fairly complex state
associated with these subscriptions. The union of the state for all
subscriptions to a particular resource is called the watcher
information for that resource.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-winfo-format-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-winfo-format-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020307120951.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-winfo-format-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-winfo-format-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020307120951.I-D@ietf.org>

--OtherAccess--

--NextPart--



From tsearle@antihe.ro  Fri Mar  8 09:28:18 2002
Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA19638
	for ; Fri, 8 Mar 2002 09:28:18 -0500 (EST)
Received: (qmail 26352 invoked by alias); 8 Mar 2002 14:27:29 -0000
Received: from unknown (HELO antihe.ro) (194.78.202.25)
  by 0 with SMTP; 8 Mar 2002 14:27:29 -0000
Message-ID: <3C88CA59.5070306@antihe.ro>
Date: Fri, 08 Mar 2002 15:27:37 +0100
From: Torrey Searle 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
References: <200203081203.HAA19210@mailman.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1150
Subject: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
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: 

On reason that makes group discussions via e-mail easy and quick to 
start up is the ability to "reply to all" in response to the e-mail, in 
the case of page mode of IM a person reciving an IM does not know who 
the other recipents of the message are, rendering it difficult for 
everybody to determine the proper members of the conversation.  Listing 
the members in a Contact header is not allowed because no dialog is created.

Perhaps a "Respond-To" header can be added to a message in order to 
suggest to the recipient which addresses should a response to the given 
message be sent to.

Torrey Searle
Indigo Software

>  I believe that the simplicity remains only if you allow membership
>inconsistencies, like email.  Each group member retains their own
>membership state which may or may not match the other recipients, and
>while optional membership add/drop requests may be sent by members, each
>client is ultimately free to make their own decisions as to who they
>send messages to.  This allows for 'bcc' functionality as well.
>
>  However, if messages are not autonomous and themselves contain state,
>this would break the model.
>


From oran@cisco.com  Fri Mar  8 10:35:17 2002
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19862
	for ; Fri, 8 Mar 2002 10:35:17 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g28FYO317051;
	Fri, 8 Mar 2002 07:34:24 -0800 (PST)
Received: from oranlt ([161.44.238.50])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ACF17050;
	Fri, 8 Mar 2002 07:34:38 -0800 (PST)
From: "David R. Oran" 
To: "'Jonathan Rosenberg'" 
Cc: 
Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Date: Fri, 8 Mar 2002 10:34:17 -0500
Organization: Cisco Systems
Message-ID: <003801c1c6b6$b693c690$32ee2ca1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <3C885B44.4D8F4D6B@dynamicsoft.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 4803
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: 

Clarifying a couple of points for Jonathan:

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
> Sent: Friday, March 08, 2002 1:34 AM
> To: David R. Oran
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Re: 
> draft-rosenberg-simple-components-00.txt (threading)
> 
> 
> 
> 
> "David R. Oran" wrote:
> > 
> 
> > > Problem 1: Message session supports only one discussion 
> thread per 
> > > session. This does not well reflect real-life scenarios.
> > > For example, there may be a group chat session with 20 people.
> > > It is very likely that they have different
> > > conversation topics going-on at the same time although they
> > > are in the same group. It is also likely that smaller
> > > sub-threads emerge and it would be nice if these can be
> > > somehow shown in the user interface similarly to current
> > > network news UIs. For example, if there are several questions
> > > asked in the group and users respond with "yes!" or "no" in
> > > the message body it is
> > > quite difficult to know to which question they were intended.
> > > User Interface could show them nicely if there were header support
> > > for it.
> > >
> > Actually, I think there are two related, but not identical 
> problems to 
> > be solved here. One is the logical grouping of messages by 
> > thread/topic, for which In-reply-to: is helpful but not completely 
> > adequate. The second is constructing a causal order of the 
> messages in 
> > a multi-party chat session.
> 
> Good observation. I think you are right.
> 
>  In-reply-to can in fact be used for this, as long as each
> > message is in fact tagged with the message-id of the message that 
> > provoked it (some UI support is of course needed to identify this). 
> > However, this usage would conflict with the classical 
> threading usage 
> > we see in newsgroups.
> 
> In-Reply-To can play either role, depending on what you think 
> should go in there. If, when you respond to a message, you 
> place into In-Reply-To, the value of In-Reply-To from the 
> message you are responding to, you get threading. 
Yup. 

> You change 
> threads by basically deleting In-Reply-To when you create a 
> new thread. 
Well, news systems allow you to have "hierarchical" threading, which
would not be easy/possible unless you either have some hierarchy in
In-Reply-To: and/or a way to explicitly start a sub-thread, perhaps by
using Subject: in a clever way as you allude to below. The mixing of
this not-quite-right causal ordering results in annoying structures like
the cascading-thread with each message indented further. Such threads
are very hard to follow which is why both threading and causal ordering
is needed.

> If you place into In-Reply-To, the Call-ID of the 
> message you are responding to, you get causal order. 
Yes, either the Call-ID itself or some other global identifier. I
suppose Call-ID can be used without usage confusion, but I haven't
thought about it long enough to be sure.

> Its not 
> clear which is a "more correct" usage of In-Reply-To. If I 
> had to guess, its probably the latter usage, which would get 
> you causal order.
> 
I'm inclined to agree. Again though, I'd need to ponder a bit more to
see if this is indeed the way to go.

> > 
> > I think the threading/topic stuff would best be solved with 
> adding a 
> > hierarchical structure to the Subject: (or In-reply-to) 
> header, or a 
> > new header, such as "context:"  and some conventions 
> thereto, as was 
> > suggested. However, that leaves the problem of how to establish the 
> > causal order if the In-reply-to header is used. For that, I 
> believe a 
> > new header would be called for.
> 
> Why is a new header needed for causal order if you use In-Reply-To?
>
Sorry, my ruminations were sloppy. I meant that if you used In-Reply-To:
for threading you'd need a new header for establishing causal order.
 
> Threading may very well better be handled by Subject. I hadn't 
> thought about that....
>
Definitely worth considering. Given the general history and sloppiness
around Subject:, it might be better to have an explicit "Threading:"
header than try to figure out what to put in subject, which today simply
does "approximate pattern match using the natural intelligence engine".
There are also the issues around the (inconsistent) conventions for
manipulating Subject: headers with things like "Re:" "Fwd:" etc.

Dave.

> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 


From pkyzivat@cisco.com  Fri Mar  8 11:50:42 2002
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 LAA20124
	for ; Fri, 8 Mar 2002 11:50:42 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g28GoCJ06710;
	Fri, 8 Mar 2002 11:50:12 -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 AAG44475;
	Fri, 8 Mar 2002 11:53:05 -0500 (EST)
Message-ID: <3C88EBAF.A823F391@cisco.com>
Date: Fri, 08 Mar 2002 11:49:51 -0500
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] I-D ACTION:draft-ietf-simple-winfo-format-01.txt
References: <200203081200.HAA00180@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 956
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: 

I have a question about:

        duration: The amount of time, in seconds, that the subscription
             was in the previous state before transitioning to the state
             described in the status parameter.

I can see how this can be useful when receiving a notification containing only changes. But it is less useful when doing a fetch, or when receiving the initial notification
following a subscription. In those cases there is no way to know how long the subscription has been in the current state.

One solution would be to provide two values. But I think it is sufficient to provide only the duration in the current state. This is clearly the value needed when you have
no prior information about the subscription. If you have a prior value, then the total time in the prior state, if desired, can be computed using the prior duration value,
the time the last notification was sent, and the time the current notification was sent.

	Paul

From petkos@cs.columbia.edu  Fri Mar  8 11:56:52 2002
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 LAA20166
	for ; Fri, 8 Mar 2002 11:56:52 -0500 (EST)
Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA28304;
	Fri, 8 Mar 2002 11:56:04 -0500 (EST)
Received: (from petkos@localhost)
	by dynasty.cs.columbia.edu (8.9.3/8.9.3) id LAA27135;
	Fri, 8 Mar 2002 11:56:04 -0500 (EST)
From: "Petri K. Koskelainen" 
Message-Id: <200203081656.LAA27135@dynasty.cs.columbia.edu>
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
To: jdrosen@dynamicsoft.com (Jonathan Rosenberg)
Date: Fri, 8 Mar 2002 11:56:04 -0500 (EST)
Cc: petkos@cs.columbia.edu (Petri K. Koskelainen),
        simple@mailman.dynamicsoft.com
In-Reply-To: <3C885999.CC029951@dynamicsoft.com> from "Jonathan Rosenberg" at Mar 08, 2002 01:26:33 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 860
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: 

> A discussion we REALLY need to have, is whether we think that the paging
> model even makes sense for multiparty. I am really not convinced. It
> seems that multiparty paging model is really more like email, and that
> is not what IM is supposed to be. If group IM is supposed to be real
> time, It just works so much better in the session model. So many
> problems (like this one above) just evaporate.
> 
> Can anyone suggest a reason why the paging model is preferrable for
> group chat? Simplicity is one, but that simplicity might be elusive as
> you try to fill in all the missing pieces.

There are one-shot scenarios which require realtime delivery
to a group. It is quite heavy operation to set up a session,
send one IM, and then close the session. 
Example usage might be an urgent realtime announcement to a 
pre-defined group.

 
BR,
--
Petri


From seancolson@yahoo.com  Fri Mar  8 12:57:45 2002
Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA20403
	for ; Fri, 8 Mar 2002 12:57:44 -0500 (EST)
Message-ID: <20020308175649.73567.qmail@web11607.mail.yahoo.com>
Received: from [131.107.3.70] by web11607.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 09:56:49 PST
Date: Fri, 8 Mar 2002 09:56:49 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
To: "Petri K. Koskelainen" ,
        Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
In-Reply-To: <200203081656.LAA27135@dynasty.cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1645
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: 

Group chat is of course a better fit for the
session model. One-time delivery of messages to
a group is a better fit for paging as Petri points
out. How common is this? I can think of a TON of
applications that fit this scenario. What features
of group messaging can't be implemented in a paging
mode?

/sean

--- "Petri K. Koskelainen" 
wrote:
> 
> > A discussion we REALLY need to have, is whether we
> think that the paging
> > model even makes sense for multiparty. I am really
> not convinced. It
> > seems that multiparty paging model is really more
> like email, and that
> > is not what IM is supposed to be. If group IM is
> supposed to be real
> > time, It just works so much better in the session
> model. So many
> > problems (like this one above) just evaporate.
> > 
> > Can anyone suggest a reason why the paging model
> is preferrable for
> > group chat? Simplicity is one, but that simplicity
> might be elusive as
> > you try to fill in all the missing pieces.
> 
> There are one-shot scenarios which require realtime
> delivery
> to a group. It is quite heavy operation to set up a
> session,
> send one IM, and then close the session. 
> Example usage might be an urgent realtime
> announcement to a 
> pre-defined group.
> 
>  
> BR,
> --
> Petri
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple


=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

From pkyzivat@cisco.com  Fri Mar  8 16:36:23 2002
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 QAA21109
	for ; Fri, 8 Mar 2002 16:36:22 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g28LZqd11484;
	Fri, 8 Mar 2002 16:35:52 -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 AAG46817;
	Fri, 8 Mar 2002 16:38:44 -0500 (EST)
Message-ID: <3C892EA2.A90EA0AC@cisco.com>
Date: Fri, 08 Mar 2002 16:35:30 -0500
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: Sean Olson 
CC: "Petri K. Koskelainen" ,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
References: <20020308175649.73567.qmail@web11607.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 411
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: 

Sean Olson wrote:
> 
> Group chat is of course a better fit for the
> session model. One-time delivery of messages to
> a group is a better fit for paging as Petri points
> out. How common is this? I can think of a TON of
> applications that fit this scenario. What features
> of group messaging can't be implemented in a paging
> mode?

- combining different media in the same group/conference
- floor control

From seancolson@yahoo.com  Fri Mar  8 17:24:07 2002
Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA21284
	for ; Fri, 8 Mar 2002 17:24:06 -0500 (EST)
Message-ID: <20020308222318.46835.qmail@web11608.mail.yahoo.com>
Received: from [131.107.3.92] by web11608.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 14:23:18 PST
Date: Fri, 8 Mar 2002 14:23:18 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
To: Paul Kyzivat 
Cc: "Petri K. Koskelainen" ,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3C892EA2.A90EA0AC@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 920
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: 

--- Paul Kyzivat  wrote:
> Sean Olson wrote:
> > 
> > Group chat is of course a better fit for the
> > session model. One-time delivery of messages to
> > a group is a better fit for paging as Petri points
> > out. How common is this? I can think of a TON of
> > applications that fit this scenario. What features
> > of group messaging can't be implemented in a
> paging
> > mode?
> 
> - combining different media in the same
> group/conference

I don't see this limitation. What about entity
headers?


> - floor control
This is a bit odd for IM

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


=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

From pkyzivat@cisco.com  Fri Mar  8 17:40:57 2002
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 RAA21358
	for ; Fri, 8 Mar 2002 17:40:57 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g28MeQV18241;
	Fri, 8 Mar 2002 17:40: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 AAG47321;
	Fri, 8 Mar 2002 17:43:20 -0500 (EST)
Message-ID: <3C893DC6.FF2E0214@cisco.com>
Date: Fri, 08 Mar 2002 17:40:06 -0500
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: Sean Olson 
CC: "Petri K. Koskelainen" ,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
References: <20020308222318.46835.qmail@web11608.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1214
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: 


Sean Olson wrote:
> 
> --- Paul Kyzivat  wrote:
> > Sean Olson wrote:
> > >
> > > Group chat is of course a better fit for the
> > > session model. One-time delivery of messages to
> > > a group is a better fit for paging as Petri points
> > > out. How common is this? I can think of a TON of
> > > applications that fit this scenario. What features
> > > of group messaging can't be implemented in a
> > paging
> > > mode?
> >
> > - combining different media in the same
> > group/conference
> 
> I don't see this limitation. What about entity
> headers?

I don't understand what you mean.

What I meant is that session oriented messaging is needed if you want to have a conference that includes messaging as well as other media, like voice or video. That way
they are associated with one another via a common INVITE, with multiple m= lines in the SDP.

If you use page mode messaging, you have to invent an entirely new mechanism to tie it to the session for the other media.

> 
> > - floor control
> This is a bit odd for IM

Perhaps so if it is text mode IM. But suppose you are using this for some other purpose, like gaming, or pushing URLs that are to be rendered in a window.

	Paul

From seancolson@yahoo.com  Fri Mar  8 18:28:39 2002
Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA21519
	for ; Fri, 8 Mar 2002 18:28:38 -0500 (EST)
Message-ID: <20020308232749.63992.qmail@web11601.mail.yahoo.com>
Received: from [131.107.3.83] by web11601.mail.yahoo.com via HTTP; Fri, 08 Mar 2002 15:27:49 PST
Date: Fri, 8 Mar 2002 15:27:49 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
To: Paul Kyzivat 
Cc: "Petri K. Koskelainen" ,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3C893DC6.FF2E0214@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 2069
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: 

 
> I don't understand what you mean.

I was referring to mixing media within an IM 
"session" -- not the problem you were referring to :)

> What I meant is that session oriented messaging is
> needed if you want to have a conference that
> includes messaging as well as other media, like
> voice or video. That way
> they are associated with one another via a common
> INVITE, with multiple m= lines in the SDP.

Absolutely. And for a group conference that makes
a lot of sense. For ad-hoc groups which are
essentially a collection of point-to-point
connections, there may not be a need or occassion
to use a INVITE-based session. An example is a
IM sidebar to a regular group conference. You don't
want to re-negotiate (via INVITE) the overall
conference, but instead what to exchange a few simple
IMs among an ad-hoc group. 

[I'm not against the session model for multiparty IM.
If the WG would prefer to focus only on session model
for multiparty scenarios, that's fine. But I expect
this will only mean people will go off and implement
their own paging model for multiparty IM. It's just
too intuitive to pass up.]


> 
> If you use page mode messaging, you have to invent
> an entirely new mechanism to tie it to the session
> for the other media.

In-Reply-To would not work?

> > 
> > > - floor control
> > This is a bit odd for IM
> 
> Perhaps so if it is text mode IM. But suppose you
> are using this for some other purpose, like gaming,
> or pushing URLs that are to be rendered in a window.

Floor control would be useful here if the group
accepts a moderator/floor notion of control. Chaotic
as it may seem, there may be good reason to not have
floor control in a multiparty IM environment. The
social dynamics seem to argue for it for one. Note
that I am not including "group chat" or chatroom 
scenarios. I am talking more about ad-hoc scenarios.

> 	Paul

/sean

=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

From dean.willis@softarmor.com  Sat Mar  9 16:44:17 2002
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 QAA25512
	for ; Sat, 9 Mar 2002 16:44:16 -0500 (EST)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g29Lgll04584;
	Sat, 9 Mar 2002 15:42:47 -0600
Message-ID: <009501c1c7b3$4f356fa0$133fed0c@C1893415A>
From: "Dean Willis" 
To: "Jonathan Rosenberg" ,
        "Petri K. Koskelainen" 
Cc: 
References: <200202281724.MAA04612@dynasty.cs.columbia.edu> <3C885999.CC029951@dynamicsoft.com>
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Date: Sat, 9 Mar 2002 15:42:27 -0600
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
Content-Length: 1423
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: 

Jonathan asked:
> A discussion we REALLY need to have, is whether we think that the paging
> model even makes sense for multiparty. I am really not convinced. It
> seems that multiparty paging model is really more like email, and that
> is not what IM is supposed to be. If group IM is supposed to be real
> time, It just works so much better in the session model. So many
> problems (like this one above) just evaporate.
>
> Can anyone suggest a reason why the paging model is preferrable for
> group chat? Simplicity is one, but that simplicity might be elusive as
> you try to fill in all the missing pieces.

Well, if some of your participants are coming and going, you have an open
question about whether store-and-forward delivery to those paticipants is
appropriate.

If we do store-and-forward, then it really IS like fast email, and I would
posit that the paging model makes excellent sense. If on the other hand the
model is a "chat room" where unless you are in the room, you never see the
message, then a session model makes more sense.

So I suggest that we may wish to consider distinguishing these two models
from a requirements analysis perspective.

I believe if we follow this to a logical conclusion that we'll end up with
two very different implementations serving the different modalities, and a
couple of logical "transition points" where messaging sequence move from one
mode to the other.

--
Dean


From pkyzivat@cisco.com  Mon Mar 11 09:00:27 2002
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 JAA01096
	for ; Mon, 11 Mar 2002 09:00:27 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2BDxu424924;
	Mon, 11 Mar 2002 08:59:56 -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 AAG51874;
	Mon, 11 Mar 2002 09:02:49 -0500 (EST)
Message-ID: <3C8CB847.D9C0FA9B@cisco.com>
Date: Mon, 11 Mar 2002 08:59:35 -0500
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: Sean Olson 
CC: "Petri K. Koskelainen" ,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
References: <20020308232749.63992.qmail@web11601.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2587
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: 

I am not opposed to page-mode conferences.
I was simply responding to your message that implied
(I thought) that page-mode might be sufficient, without
session-mode.

The other problem with page-mode conferences is of course
the issue of sending them over the SIP signalling channel.
There is the general objection to doing this for fear of
saturating the channel.

	Paul

Sean Olson wrote:
> 
> 
> > I don't understand what you mean.
> 
> I was referring to mixing media within an IM
> "session" -- not the problem you were referring to :)
> 
> > What I meant is that session oriented messaging is
> > needed if you want to have a conference that
> > includes messaging as well as other media, like
> > voice or video. That way
> > they are associated with one another via a common
> > INVITE, with multiple m= lines in the SDP.
> 
> Absolutely. And for a group conference that makes
> a lot of sense. For ad-hoc groups which are
> essentially a collection of point-to-point
> connections, there may not be a need or occassion
> to use a INVITE-based session. An example is a
> IM sidebar to a regular group conference. You don't
> want to re-negotiate (via INVITE) the overall
> conference, but instead what to exchange a few simple
> IMs among an ad-hoc group.
> 
> [I'm not against the session model for multiparty IM.
> If the WG would prefer to focus only on session model
> for multiparty scenarios, that's fine. But I expect
> this will only mean people will go off and implement
> their own paging model for multiparty IM. It's just
> too intuitive to pass up.]
> 
> >
> > If you use page mode messaging, you have to invent
> > an entirely new mechanism to tie it to the session
> > for the other media.
> 
> In-Reply-To would not work?
> 
> > >
> > > > - floor control
> > > This is a bit odd for IM
> >
> > Perhaps so if it is text mode IM. But suppose you
> > are using this for some other purpose, like gaming,
> > or pushing URLs that are to be rendered in a window.
> 
> Floor control would be useful here if the group
> accepts a moderator/floor notion of control. Chaotic
> as it may seem, there may be good reason to not have
> floor control in a multiparty IM environment. The
> social dynamics seem to argue for it for one. Note
> that I am not including "group chat" or chatroom
> scenarios. I am talking more about ad-hoc scenarios.
> 
> >       Paul
> 
> /sean
> 
> =====
> Sean Olson 
> 
> __________________________________________________
> Do You Yahoo!?
> Try FREE Yahoo! Mail - the world's greatest free email!
> http://mail.yahoo.com/

From dean.willis@softarmor.com  Mon Mar 11 14:42:14 2002
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 OAA02165
	for ; Mon, 11 Mar 2002 14:42:13 -0500 (EST)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2BJeOl26223;
	Mon, 11 Mar 2002 13:40:24 -0600
From: "Dean Willis" 
To: "'Paul Kyzivat'" ,
        "'Sean Olson'" 
Cc: "'Petri K. Koskelainen'" ,
        "'Jonathan Rosenberg'" ,
        
Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Date: Mon, 11 Mar 2002 13:40:22 -0600
Message-ID: <000401c1c934$960a62f0$bb036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <3C8CB847.D9C0FA9B@cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 2099
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: 

Paul wrote:
> The other problem with page-mode conferences is of course
> the issue of sending them over the SIP signalling channel. 
> There is the general objection to doing this for fear of 
> saturating the channel.

Of course, meeting the European (and probably elsewhere) regulatory
requirements for privacy is going to require running EVERYTHING over the
signaling chanel or through an intermediary "anonymizer" box anyhow, so
I fail to see this as a real issue. One simply has to design one's
signaling network appropriately. One also has to design the business
model in such a way that the costs can be accounted for and offset by
revenue . . .

I keep seeing this "Oh no, they're asking us to actually carry TRAFFIC
on our network!" response from mobile operators that are still stuck in
GSM circuit mindsets. What they fail to realize is that it is the
value-added service (such as privacy management) built into that
carriage that provides the value-add which distinguishes the service
operator from a commodity bit-pipe provider.

At the "most protective" end of the spectrum (I get this from people in
Germany building wireless systems), the communication between two users
cannot be allowed to reveal the actual IP address of any user, nor can
it reveal anything about the geographic location or business
relationships (who's your carrier?) of any user. The ONLY piece of
information that can be revealed is the "identity" of a user as
indicated by a network "address of record", and then only to the extent
thet the user has specifically requested dislcosure of that mechanism
AND a contractual relationship between operators provides for the
controlled release of only that information. This means that each
service operator has to operate a bidirectional anonymization service.
For short sequences of messages, the SIP proxy network (with a few
"hiding" tweaks) seems to be an efficient mechanism for doing this,
certainly more efficient than allocating two session-level anonymizer
boxes and using INVITE session signaling semantics to instantiate a
protected session.

--
Dean


From pkyzivat@cisco.com  Mon Mar 11 15:14:01 2002
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 PAA02288
	for ; Mon, 11 Mar 2002 15:14:01 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2BKDUf21110;
	Mon, 11 Mar 2002 15:13:30 -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 AAG55424;
	Mon, 11 Mar 2002 15:16:24 -0500 (EST)
Message-ID: <3C8D0FD5.3098EA25@cisco.com>
Date: Mon, 11 Mar 2002 15:13:09 -0500
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: Dean Willis 
CC: "'Sean Olson'" ,
        "'Petri K. Koskelainen'" ,
        "'Jonathan Rosenberg'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
References: <000401c1c934$960a62f0$bb036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2228
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: 

Dean Willis wrote:
> 
> At the "most protective" end of the spectrum (I get this from people in
> Germany building wireless systems), the communication between two users
> cannot be allowed to reveal the actual IP address of any user, nor can
> it reveal anything about the geographic location or business
> relationships (who's your carrier?) of any user. The ONLY piece of
> information that can be revealed is the "identity" of a user as
> indicated by a network "address of record", and then only to the extent
> thet the user has specifically requested dislcosure of that mechanism
> AND a contractual relationship between operators provides for the
> controlled release of only that information. 

Ugh!

Seems nasty to require such by default. Providing that level of anonymity is costly. Ought not to be mandated. While I may want it, I often don't need it.

Nevertheless, this seems to be largely irrelevant to the subject at hand.

> Of course, meeting the European (and probably elsewhere) regulatory
> requirements for privacy is going to require running EVERYTHING over the
> signaling chanel or through an intermediary "anonymizer" box anyhow, so
> I fail to see this as a real issue. One simply has to design one's
> signaling network appropriately. One also has to design the business
> model in such a way that the costs can be accounted for and offset by
> revenue . . .
> 
> I keep seeing this "Oh no, they're asking us to actually carry TRAFFIC
> on our network!" response from mobile operators that are still stuck in
> GSM circuit mindsets. What they fail to realize is that it is the
> value-added service (such as privacy management) built into that
> carriage that provides the value-add which distinguishes the service
> operator from a commodity bit-pipe provider.

My impression is that the force behind keeping IM off of the SIP signalling channel is IETF rather than regulatory agencies or mobile operators. I thought it had to do with
UDP not be flow controlled.

The proposals to use a SIP-like protocol over TCP or TLS resolves that problem. And if it transits a proxy then it can handle the anonymization as well. But I believe doing
those things will require session oriented messaging.

	Paul

From dean.willis@softarmor.com  Mon Mar 11 17:19:57 2002
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 RAA02721
	for ; Mon, 11 Mar 2002 17:19:56 -0500 (EST)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2BMIDl27114;
	Mon, 11 Mar 2002 16:18:13 -0600
From: "Dean Willis" 
To: "'Paul Kyzivat'" 
Cc: "'Sean Olson'" ,
        "'Petri K. Koskelainen'" ,
        "'Jonathan Rosenberg'" ,
        
Date: Mon, 11 Mar 2002 16:18:11 -0600
Message-ID: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <3C8D0FD5.3098EA25@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 6792
Subject: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading)
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: 

Paul said:
> My impression is that the force behind keeping IM off of the 
> SIP signalling channel is IETF rather than regulatory 
> agencies or mobile operators. I thought it had to do with UDP 
> not be flow controlled.
> 
> The proposals to use a SIP-like protocol over TCP or TLS 
> resolves that problem. And if it transits a proxy then it can 
> handle the anonymization as well. But I believe doing those 
> things will require session oriented messaging.

Well, there are serveral forces toward keeping user messages off of the
"signaling" path.

1) We've justified use of questionable flow control techniques for SIP
by calling it "signaling", which implies a requirement for low-latency
transmission using relative short messages delivered in an independently
atomic fashion (no head-of-line blocking).  Since this is somehow
different than "bulk data", i.e. emails, etc. it is "sort of" ok,
although SCTP is seen as the direction-of-choice for compliance with
proper Internet architecture. The odd thing is that "pager" mode
messages have exactly the same sort of requirements.

2) Some people have a "purity of model" approach and are offended by
mixing information with meta-information. That is, the putting of any
information into SIP besides that needed for the negotiation of sessions
external to SIP offends them. Of course, they also find the REGISTER
message, the INFO message, user-supplied bodies that are not SDP, and
other such mechanisms offensive in the same way. They may be right, but
SIP already mixes user and session-description information.

3) Some operators are concerned about a re-occurrence of the fundamental
signaling problem with SMS. As currently implemented, wireless
short-message-service transits user datagrams over SS7 links which also
transport the signaling for circuit-switced call establishement and
teardown. SS7 links are also very expensive and have to be highly
protected. As a result, these scarce resources get overloaded and
congest, and there's not efficient way to do prioritization between SMS
and other signaling over those links. Newer research in SMS has sought a
means to allocate transport outside of the primary SS7 path for moving
message bodies.

Some people see an an analog between the SS7 network and the role of SIP
proxies as signaling elements. Since the SIP proxies get mixed up in the
transference of SIP messages, they are seen as roughly similar to the
STPs and SMSCs in the SS7 network.

Warning: Philosophical Rant Follows

The key issue is buried deep in the underlying business model. In the
Internet world, you pay the same for the bits used to signal a
multimedia session as for the bits used by the multimedia session
itself. In the PSTN, the carriers pay for the signaling used to set up
the multimedia session. In other words, there is NO signaling, as
signaling is used in the PSTN sense, on the Internet -- just application
traffic. There might be messaging applications, routing applications,
management applications, or multimedia applications, but they're just
all applications as far as the underlying network in concerned. In the
PSTN, signaling actually traverses a separate, specialized network,
driven by its own economic laws.

In the Internet world view, if an application generates profits and
adding more servers allows it to generate more profit, then the
application gets more servers. But in the PSTN model, signaling is COST
and never actually generates profit -- it merely allows the
establishment of sessions or the delivery of messages, and it is the
sessions or messages which generate the profit. Signaling is just a cost
of doing business, and there's no good way to pass it directly on to the
consumer or even charge it back to the application, so it always gets
shorted. Given the fundamental laws of economics, the shortage of a
useful resource increases its value, so signaling traffic becomes much
more highly-protected and the efficiency of the signaling paramount.
Running on its separate, tightly-controlled and carefully managed
network, PSTN signaling takes on an almost religious significance. It's
DIFFERENT from user or application data, and SPECIAL. I seem to remember
from my days in PSTN design that it took "two years and two million
dollars" to get clearance to connect to the core SS7 network. Of course,
this mean that no new applications git built, but it's the model the
phone-types understand.

But there's really a deep fundamental difference between PSTN and
Internet models. In a pure SIP network, we expect Internet-like
end-to-end routability at layer 3. Once I know your contact information,
I can send messages directly to you. This doesn't really exist in SS7.
SIP proxies provide "layer 4 routing" functions like STPs, but only if
needed by the endpoints. However, circuit-switched mindsets are leading
to the development of SS7-like networks using SIP and IP, where the
end-to-end- path at layer 3 is established ONLY if authorized by
higher-layer (SIP) traffic which has transited the "trunking points" of
operator proxies operating from within "walled gardens". In other words,
they're insisting on reinventing the entire SS7 problem, and shouldn't
be at all surprised when the issues that were so constraining in the SS7
world strike again. 

One of the issues that comes out is that PSTN types don't know how to
charge for signaling -- they only know how to charge for the RESULTS of
signaling. Therefore, it is important to them to tightly control the
sorts of signaling that a user can do, because if a user does some kind
of signaling that does something besides set up a session that they know
how to charge for, that user is "stealing resources". As a consequence,
PSTN-logic requires that the operator UNDERSTAND all signaling, and
anything that isn't understood signaling needs to be relegated to
transport controlled-by-signaling or just plain blocked.

I'm continually approached by phone operators who start out by saying
something like "We'll never implement the SIP MESSAGE method. Since it
goes over our proxy network with user-supplied data, we have no way to
charge for it and it allows users to steal network resources." I respond
with something like "Well, the charging model of 3GPP/3GPP2 allows us to
write a charging record indicating who sent the message, who received
it, and how big it was. Given that, you should be able to charge for
each one of these messages at whatever rate the business will bear." The
first response is something like "We can't do that, this is the
SIGNALING network. What if we run out of capacity?" Then they stop and
think about it. Sometimes, virtual dollar signs ($^$) light up in their
eyes. Other times they wander off mumbling at/about me. But it's clearly
an alien philosophy.

--
Dean


From pkyzivat@cisco.com  Mon Mar 11 17:44:28 2002
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 RAA02819
	for ; Mon, 11 Mar 2002 17:44:28 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2BMhvM10772;
	Mon, 11 Mar 2002 17:43: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 AAG56797;
	Mon, 11 Mar 2002 17:46:51 -0500 (EST)
Message-ID: <3C8D3318.965F0CF2@cisco.com>
Date: Mon, 11 Mar 2002 17:43:36 -0500
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: Dean Willis 
CC: "'Sean Olson'" ,
        "'Petri K. Koskelainen'" ,
        "'Jonathan Rosenberg'" ,
        simple@mailman.dynamicsoft.com
References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 7860
Subject: [Simple] Re: Messages: Signaling, Data, or Theft (Was something to do wit message
 threading)
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: 

Dean,

Thank you for the informative "Philosophical Rant". What you say makes a lot of sense to me. But in the end I don't much care, as long as the people who do care settle
their differences so we can decide on *something*.

My need is for session oriented IM, in the sense that it can be negotiated as one of possibly many media in a call, that may or may not be conferenced. What channel it gets
transmitted over is not important to me as long as it works and has reasonable latency. I have no objection to the presence of page mode IM as well, and have some uses in
mind for it too. I also have no objection to page mode and session mode IM using the same paths, if all the flow control issues can be resolved.

To me the main problem is having some closure on how session mode IM is specified in SDP.

	Paul

Dean Willis wrote:
> 
> Paul said:
> > My impression is that the force behind keeping IM off of the
> > SIP signalling channel is IETF rather than regulatory
> > agencies or mobile operators. I thought it had to do with UDP
> > not be flow controlled.
> >
> > The proposals to use a SIP-like protocol over TCP or TLS
> > resolves that problem. And if it transits a proxy then it can
> > handle the anonymization as well. But I believe doing those
> > things will require session oriented messaging.
> 
> Well, there are serveral forces toward keeping user messages off of the
> "signaling" path.
> 
> 1) We've justified use of questionable flow control techniques for SIP
> by calling it "signaling", which implies a requirement for low-latency
> transmission using relative short messages delivered in an independently
> atomic fashion (no head-of-line blocking).  Since this is somehow
> different than "bulk data", i.e. emails, etc. it is "sort of" ok,
> although SCTP is seen as the direction-of-choice for compliance with
> proper Internet architecture. The odd thing is that "pager" mode
> messages have exactly the same sort of requirements.
> 
> 2) Some people have a "purity of model" approach and are offended by
> mixing information with meta-information. That is, the putting of any
> information into SIP besides that needed for the negotiation of sessions
> external to SIP offends them. Of course, they also find the REGISTER
> message, the INFO message, user-supplied bodies that are not SDP, and
> other such mechanisms offensive in the same way. They may be right, but
> SIP already mixes user and session-description information.
> 
> 3) Some operators are concerned about a re-occurrence of the fundamental
> signaling problem with SMS. As currently implemented, wireless
> short-message-service transits user datagrams over SS7 links which also
> transport the signaling for circuit-switced call establishement and
> teardown. SS7 links are also very expensive and have to be highly
> protected. As a result, these scarce resources get overloaded and
> congest, and there's not efficient way to do prioritization between SMS
> and other signaling over those links. Newer research in SMS has sought a
> means to allocate transport outside of the primary SS7 path for moving
> message bodies.
> 
> Some people see an an analog between the SS7 network and the role of SIP
> proxies as signaling elements. Since the SIP proxies get mixed up in the
> transference of SIP messages, they are seen as roughly similar to the
> STPs and SMSCs in the SS7 network.
> 
> Warning: Philosophical Rant Follows
> 
> The key issue is buried deep in the underlying business model. In the
> Internet world, you pay the same for the bits used to signal a
> multimedia session as for the bits used by the multimedia session
> itself. In the PSTN, the carriers pay for the signaling used to set up
> the multimedia session. In other words, there is NO signaling, as
> signaling is used in the PSTN sense, on the Internet -- just application
> traffic. There might be messaging applications, routing applications,
> management applications, or multimedia applications, but they're just
> all applications as far as the underlying network in concerned. In the
> PSTN, signaling actually traverses a separate, specialized network,
> driven by its own economic laws.
> 
> In the Internet world view, if an application generates profits and
> adding more servers allows it to generate more profit, then the
> application gets more servers. But in the PSTN model, signaling is COST
> and never actually generates profit -- it merely allows the
> establishment of sessions or the delivery of messages, and it is the
> sessions or messages which generate the profit. Signaling is just a cost
> of doing business, and there's no good way to pass it directly on to the
> consumer or even charge it back to the application, so it always gets
> shorted. Given the fundamental laws of economics, the shortage of a
> useful resource increases its value, so signaling traffic becomes much
> more highly-protected and the efficiency of the signaling paramount.
> Running on its separate, tightly-controlled and carefully managed
> network, PSTN signaling takes on an almost religious significance. It's
> DIFFERENT from user or application data, and SPECIAL. I seem to remember
> from my days in PSTN design that it took "two years and two million
> dollars" to get clearance to connect to the core SS7 network. Of course,
> this mean that no new applications git built, but it's the model the
> phone-types understand.
> 
> But there's really a deep fundamental difference between PSTN and
> Internet models. In a pure SIP network, we expect Internet-like
> end-to-end routability at layer 3. Once I know your contact information,
> I can send messages directly to you. This doesn't really exist in SS7.
> SIP proxies provide "layer 4 routing" functions like STPs, but only if
> needed by the endpoints. However, circuit-switched mindsets are leading
> to the development of SS7-like networks using SIP and IP, where the
> end-to-end- path at layer 3 is established ONLY if authorized by
> higher-layer (SIP) traffic which has transited the "trunking points" of
> operator proxies operating from within "walled gardens". In other words,
> they're insisting on reinventing the entire SS7 problem, and shouldn't
> be at all surprised when the issues that were so constraining in the SS7
> world strike again.
> 
> One of the issues that comes out is that PSTN types don't know how to
> charge for signaling -- they only know how to charge for the RESULTS of
> signaling. Therefore, it is important to them to tightly control the
> sorts of signaling that a user can do, because if a user does some kind
> of signaling that does something besides set up a session that they know
> how to charge for, that user is "stealing resources". As a consequence,
> PSTN-logic requires that the operator UNDERSTAND all signaling, and
> anything that isn't understood signaling needs to be relegated to
> transport controlled-by-signaling or just plain blocked.
> 
> I'm continually approached by phone operators who start out by saying
> something like "We'll never implement the SIP MESSAGE method. Since it
> goes over our proxy network with user-supplied data, we have no way to
> charge for it and it allows users to steal network resources." I respond
> with something like "Well, the charging model of 3GPP/3GPP2 allows us to
> write a charging record indicating who sent the message, who received
> it, and how big it was. Given that, you should be able to charge for
> each one of these messages at whatever rate the business will bear." The
> first response is something like "We can't do that, this is the
> SIGNALING network. What if we run out of capacity?" Then they stop and
> think about it. Sometimes, virtual dollar signs ($^$) light up in their
> eyes. Other times they wander off mumbling at/about me. But it's clearly
> an alien philosophy.
> 
> --
> Dean

From Vasilis.Polychronidis@Openwave.com  Mon Mar 11 23:29:08 2002
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 XAA03897
	for ; Mon, 11 Mar 2002 23:29:07 -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 <20020312042817.VZVZ7425.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Mon, 11 Mar 2002 22:28:17 -0600
Received: from Openwave.com ([206.35.147.89]) by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP
          id <20020312042816.CHDQ939.oe-ismta2.bizmailsrvcs.net@Openwave.com>;
          Mon, 11 Mar 2002 22:28:16 -0600
Message-ID: <3C8D83DE.929A3FDD@Openwave.com>
Date: Mon, 11 Mar 2002 20:28:14 -0800
From: Vasilis Polychronidis 
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis 
CC: "'Paul Kyzivat'" ,
        "'Sean Olson'" ,
        "'Petri K. Koskelainen'" ,
        "'Jonathan Rosenberg'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do 
 wit message threading)
References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2>
Content-Type: multipart/alternative;
 boundary="------------CF7EAF9D3135AFEED988043F"
Content-Length: 17264
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: 

--------------CF7EAF9D3135AFEED988043F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear Dean,
I would have agreed with your thinking if:
1. buying a SIP proxy costs as much as to buy a HTTP proxy
2. messaging traffic had the same Quality of Service (QOS) requirements and
signaling (setting up IP calls).
Since none of the above statements are true I do not agree with your
thinking.

For example in order to guarantee that you get 0.1% blocking on IP call
signaling you will have to over provision
your SIP proxies in order to handle the additional messaging traffic.
However since the messaging traffic does not
require the same QOS as signaling you will be wasting a lot of capacity.
In other words your cost for transporting messaging data will be the same as
the signaling one.

Another example: Since SIP proxies and especially CSCFs (3GPP term for
specialized SIP proxies) costs more than
plain HTTP proxies (for the conferencing case) or IP routers (for the end to
end case) then IM service providers will
have to incur all this extra cost for doing IM via SIP proxies.

There are no philosophical differences here just basic engineering and
economics.

-Vasilis

Dean Willis wrote:

> Paul said:
> > My impression is that the force behind keeping IM off of the
> > SIP signalling channel is IETF rather than regulatory
> > agencies or mobile operators. I thought it had to do with UDP
> > not be flow controlled.
> >
> > The proposals to use a SIP-like protocol over TCP or TLS
> > resolves that problem. And if it transits a proxy then it can
> > handle the anonymization as well. But I believe doing those
> > things will require session oriented messaging.
>
> Well, there are serveral forces toward keeping user messages off of the
> "signaling" path.
>
> 1) We've justified use of questionable flow control techniques for SIP
> by calling it "signaling", which implies a requirement for low-latency
> transmission using relative short messages delivered in an independently
> atomic fashion (no head-of-line blocking).  Since this is somehow
> different than "bulk data", i.e. emails, etc. it is "sort of" ok,
> although SCTP is seen as the direction-of-choice for compliance with
> proper Internet architecture. The odd thing is that "pager" mode
> messages have exactly the same sort of requirements.
>
> 2) Some people have a "purity of model" approach and are offended by
> mixing information with meta-information. That is, the putting of any
> information into SIP besides that needed for the negotiation of sessions
> external to SIP offends them. Of course, they also find the REGISTER
> message, the INFO message, user-supplied bodies that are not SDP, and
> other such mechanisms offensive in the same way. They may be right, but
> SIP already mixes user and session-description information.
>
> 3) Some operators are concerned about a re-occurrence of the fundamental
> signaling problem with SMS. As currently implemented, wireless
> short-message-service transits user datagrams over SS7 links which also
> transport the signaling for circuit-switced call establishement and
> teardown. SS7 links are also very expensive and have to be highly
> protected. As a result, these scarce resources get overloaded and
> congest, and there's not efficient way to do prioritization between SMS
> and other signaling over those links. Newer research in SMS has sought a
> means to allocate transport outside of the primary SS7 path for moving
> message bodies.
>
> Some people see an an analog between the SS7 network and the role of SIP
> proxies as signaling elements. Since the SIP proxies get mixed up in the
> transference of SIP messages, they are seen as roughly similar to the
> STPs and SMSCs in the SS7 network.
>
> Warning: Philosophical Rant Follows
>
> The key issue is buried deep in the underlying business model. In the
> Internet world, you pay the same for the bits used to signal a
> multimedia session as for the bits used by the multimedia session
> itself. In the PSTN, the carriers pay for the signaling used to set up
> the multimedia session. In other words, there is NO signaling, as
> signaling is used in the PSTN sense, on the Internet -- just application
> traffic. There might be messaging applications, routing applications,
> management applications, or multimedia applications, but they're just
> all applications as far as the underlying network in concerned. In the
> PSTN, signaling actually traverses a separate, specialized network,
> driven by its own economic laws.
>
> In the Internet world view, if an application generates profits and
> adding more servers allows it to generate more profit, then the
> application gets more servers. But in the PSTN model, signaling is COST
> and never actually generates profit -- it merely allows the
> establishment of sessions or the delivery of messages, and it is the
> sessions or messages which generate the profit. Signaling is just a cost
> of doing business, and there's no good way to pass it directly on to the
> consumer or even charge it back to the application, so it always gets
> shorted. Given the fundamental laws of economics, the shortage of a
> useful resource increases its value, so signaling traffic becomes much
> more highly-protected and the efficiency of the signaling paramount.
> Running on its separate, tightly-controlled and carefully managed
> network, PSTN signaling takes on an almost religious significance. It's
> DIFFERENT from user or application data, and SPECIAL. I seem to remember
> from my days in PSTN design that it took "two years and two million
> dollars" to get clearance to connect to the core SS7 network. Of course,
> this mean that no new applications git built, but it's the model the
> phone-types understand.
>
> But there's really a deep fundamental difference between PSTN and
> Internet models. In a pure SIP network, we expect Internet-like
> end-to-end routability at layer 3. Once I know your contact information,
> I can send messages directly to you. This doesn't really exist in SS7.
> SIP proxies provide "layer 4 routing" functions like STPs, but only if
> needed by the endpoints. However, circuit-switched mindsets are leading
> to the development of SS7-like networks using SIP and IP, where the
> end-to-end- path at layer 3 is established ONLY if authorized by
> higher-layer (SIP) traffic which has transited the "trunking points" of
> operator proxies operating from within "walled gardens". In other words,
> they're insisting on reinventing the entire SS7 problem, and shouldn't
> be at all surprised when the issues that were so constraining in the SS7
> world strike again.
>
> One of the issues that comes out is that PSTN types don't know how to
> charge for signaling -- they only know how to charge for the RESULTS of
> signaling. Therefore, it is important to them to tightly control the
> sorts of signaling that a user can do, because if a user does some kind
> of signaling that does something besides set up a session that they know
> how to charge for, that user is "stealing resources". As a consequence,
> PSTN-logic requires that the operator UNDERSTAND all signaling, and
> anything that isn't understood signaling needs to be relegated to
> transport controlled-by-signaling or just plain blocked.
>
> I'm continually approached by phone operators who start out by saying
> something like "We'll never implement the SIP MESSAGE method. Since it
> goes over our proxy network with user-supplied data, we have no way to
> charge for it and it allows users to steal network resources." I respond
> with something like "Well, the charging model of 3GPP/3GPP2 allows us to
> write a charging record indicating who sent the message, who received
> it, and how big it was. Given that, you should be able to charge for
> each one of these messages at whatever rate the business will bear." The
> first response is something like "We can't do that, this is the
> SIGNALING network. What if we run out of capacity?" Then they stop and
> think about it. Sometimes, virtual dollar signs ($^$) light up in their
> eyes. Other times they wander off mumbling at/about me. But it's clearly
> an alien philosophy.
>
> --
> Dean
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

--------------CF7EAF9D3135AFEED988043F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Dear Dean,

I would have agreed with your thinking if:

1. buying a SIP proxy costs as much as to buy a HTTP proxy

2. messaging traffic had the same Quality of Service (QOS) requirements
and signaling (setting up IP calls).

Since none of the above statements are true I do not agree with your
thinking.

For example in order to guarantee that you get 0.1% blocking on IP call
signaling you will have to over provision

your SIP proxies in order to handle the additional messaging traffic.
However since the messaging traffic does not

require the same QOS as signaling you will be wasting a lot of capacity.

In other words your cost for transporting messaging data will be the
same as the signaling one.

Another example: Since SIP proxies and especially CSCFs (3GPP term for
specialized SIP proxies) costs more than

plain HTTP proxies (for the conferencing case) or IP routers (for the
end to end case) then IM service providers will

have to incur all this extra cost for doing IM via SIP proxies.

There are no philosophical differences here just basic engineering and
economics.

-Vasilis

Dean Willis wrote:

Paul said:

> My impression is that the force behind keeping IM off of the

> SIP signalling channel is IETF rather than regulatory

> agencies or mobile operators. I thought it had to do with UDP

> not be flow controlled.

>

> The proposals to use a SIP-like protocol over TCP or TLS

> resolves that problem. And if it transits a proxy then it can

> handle the anonymization as well. But I believe doing those

> things will require session oriented messaging.

Well, there are serveral forces toward keeping user messages off of
the

"signaling" path.

1) We've justified use of questionable flow control techniques for SIP

by calling it "signaling", which implies a requirement for low-latency

transmission using relative short messages delivered in an independently

atomic fashion (no head-of-line blocking).  Since this is somehow

different than "bulk data", i.e. emails, etc. it is "sort of" ok,

although SCTP is seen as the direction-of-choice for compliance with

proper Internet architecture. The odd thing is that "pager" mode

messages have exactly the same sort of requirements.

2) Some people have a "purity of model" approach and are offended by

mixing information with meta-information. That is, the putting of any

information into SIP besides that needed for the negotiation of sessions

external to SIP offends them. Of course, they also find the REGISTER

message, the INFO message, user-supplied bodies that are not SDP, and

other such mechanisms offensive in the same way. They may be right,
but

SIP already mixes user and session-description information.

3) Some operators are concerned about a re-occurrence of the fundamental

signaling problem with SMS. As currently implemented, wireless

short-message-service transits user datagrams over SS7 links which
also

transport the signaling for circuit-switced call establishement and

teardown. SS7 links are also very expensive and have to be highly

protected. As a result, these scarce resources get overloaded and

congest, and there's not efficient way to do prioritization between
SMS

and other signaling over those links. Newer research in SMS has sought
a

means to allocate transport outside of the primary SS7 path for moving

message bodies.

Some people see an an analog between the SS7 network and the role of
SIP

proxies as signaling elements. Since the SIP proxies get mixed up in
the

transference of SIP messages, they are seen as roughly similar to the

STPs and SMSCs in the SS7 network.

Warning: Philosophical Rant Follows

The key issue is buried deep in the underlying business model. In the

Internet world, you pay the same for the bits used to signal a

multimedia session as for the bits used by the multimedia session

itself. In the PSTN, the carriers pay for the signaling used to set
up

the multimedia session. In other words, there is NO signaling, as

signaling is used in the PSTN sense, on the Internet -- just application

traffic. There might be messaging applications, routing applications,

management applications, or multimedia applications, but they're just

all applications as far as the underlying network in concerned. In
the

PSTN, signaling actually traverses a separate, specialized network,

driven by its own economic laws.

In the Internet world view, if an application generates profits and

adding more servers allows it to generate more profit, then the

application gets more servers. But in the PSTN model, signaling is
COST

and never actually generates profit -- it merely allows the

establishment of sessions or the delivery of messages, and it is the

sessions or messages which generate the profit. Signaling is just a
cost

of doing business, and there's no good way to pass it directly on to
the

consumer or even charge it back to the application, so it always gets

shorted. Given the fundamental laws of economics, the shortage of a

useful resource increases its value, so signaling traffic becomes much

more highly-protected and the efficiency of the signaling paramount.

Running on its separate, tightly-controlled and carefully managed

network, PSTN signaling takes on an almost religious significance.
It's

DIFFERENT from user or application data, and SPECIAL. I seem to remember

from my days in PSTN design that it took "two years and two million

dollars" to get clearance to connect to the core SS7 network. Of course,

this mean that no new applications git built, but it's the model the

phone-types understand.

But there's really a deep fundamental difference between PSTN and

Internet models. In a pure SIP network, we expect Internet-like

end-to-end routability at layer 3. Once I know your contact information,

I can send messages directly to you. This doesn't really exist in SS7.

SIP proxies provide "layer 4 routing" functions like STPs, but only
if

needed by the endpoints. However, circuit-switched mindsets are leading

to the development of SS7-like networks using SIP and IP, where the

end-to-end- path at layer 3 is established ONLY if authorized by

higher-layer (SIP) traffic which has transited the "trunking points"
of

operator proxies operating from within "walled gardens". In other words,

they're insisting on reinventing the entire SS7 problem, and shouldn't

be at all surprised when the issues that were so constraining in the
SS7

world strike again.

One of the issues that comes out is that PSTN types don't know how to

charge for signaling -- they only know how to charge for the RESULTS
of

signaling. Therefore, it is important to them to tightly control the

sorts of signaling that a user can do, because if a user does some
kind

of signaling that does something besides set up a session that they
know

how to charge for, that user is "stealing resources". As a consequence,

PSTN-logic requires that the operator UNDERSTAND all signaling, and

anything that isn't understood signaling needs to be relegated to

transport controlled-by-signaling or just plain blocked.

I'm continually approached by phone operators who start out by saying

something like "We'll never implement the SIP MESSAGE method. Since
it

goes over our proxy network with user-supplied data, we have no way
to

charge for it and it allows users to steal network resources." I respond

with something like "Well, the charging model of 3GPP/3GPP2 allows
us to

write a charging record indicating who sent the message, who received

it, and how big it was. Given that, you should be able to charge for

each one of these messages at whatever rate the business will bear."
The

first response is something like "We can't do that, this is the

SIGNALING network. What if we run out of capacity?" Then they stop
and

think about it. Sometimes, virtual dollar signs ($^$) light up in their

eyes. Other times they wander off mumbling at/about me. But it's clearly

an alien philosophy.

--

Dean

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple



--------------CF7EAF9D3135AFEED988043F--




From dean.willis@softarmor.com  Tue Mar 12 01:12:11 2002
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 BAA04269
	for ; Tue, 12 Mar 2002 01:12:10 -0500 (EST)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2C6ANl29473;
	Tue, 12 Mar 2002 00:10:24 -0600
Message-ID: <002701c1c98c$9725dd10$133fed0c@C1893415A>
From: "Dean Willis" 
To: "Vasilis Polychronidis" 
Cc: "'Paul Kyzivat'" ,
        "'Sean Olson'" ,
        "'Petri K. Koskelainen'" ,
        "'Jonathan Rosenberg'" ,
        
References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> <3C8D83DE.929A3FDD@Openwave.com>
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do  wit message threading)
Date: Tue, 12 Mar 2002 00:10:20 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0024_01C1C95A.4BDD52C0"
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
Content-Length: 21882
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0024_01C1C95A.4BDD52C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hey, it's not MY fault that 3GPP made their proxies too complicated and =
therefore expensive.

Do you have a better answer for meeting the European privacy =
requirements?

--
Dean
  ----- Original Message -----=20
  From: Vasilis Polychronidis=20
  To: Dean Willis=20
  Cc: 'Paul Kyzivat' ; 'Sean Olson' ; 'Petri K. Koskelainen' ; 'Jonathan =
Rosenberg' ; simple@mailman.dynamicsoft.com=20
  Sent: Monday, March 11, 2002 10:28 PM
  Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was =
something to do wit message threading)


  Dear Dean,=20
  I would have agreed with your thinking if:=20
  1. buying a SIP proxy costs as much as to buy a HTTP proxy=20
  2. messaging traffic had the same Quality of Service (QOS) =
requirements and signaling (setting up IP calls).=20
  Since none of the above statements are true I do not agree with your =
thinking.=20
  For example in order to guarantee that you get 0.1% blocking on IP =
call signaling you will have to over provision=20
  your SIP proxies in order to handle the additional messaging traffic. =
However since the messaging traffic does not=20
  require the same QOS as signaling you will be wasting a lot of =
capacity.=20
  In other words your cost for transporting messaging data will be the =
same as the signaling one.=20

  Another example: Since SIP proxies and especially CSCFs (3GPP term for =
specialized SIP proxies) costs more than=20
  plain HTTP proxies (for the conferencing case) or IP routers (for the =
end to end case) then IM service providers will=20
  have to incur all this extra cost for doing IM via SIP proxies.=20

  There are no philosophical differences here just basic engineering and =
economics.=20

  -Vasilis=20

  Dean Willis wrote:=20

    Paul said:=20
    > My impression is that the force behind keeping IM off of the=20
    > SIP signalling channel is IETF rather than regulatory=20
    > agencies or mobile operators. I thought it had to do with UDP=20
    > not be flow controlled.=20
    >=20
    > The proposals to use a SIP-like protocol over TCP or TLS=20
    > resolves that problem. And if it transits a proxy then it can=20
    > handle the anonymization as well. But I believe doing those=20
    > things will require session oriented messaging.=20
    Well, there are serveral forces toward keeping user messages off of =
the=20
    "signaling" path.=20

    1) We've justified use of questionable flow control techniques for =
SIP=20
    by calling it "signaling", which implies a requirement for =
low-latency=20
    transmission using relative short messages delivered in an =
independently=20
    atomic fashion (no head-of-line blocking).  Since this is somehow=20
    different than "bulk data", i.e. emails, etc. it is "sort of" ok,=20
    although SCTP is seen as the direction-of-choice for compliance with =

    proper Internet architecture. The odd thing is that "pager" mode=20
    messages have exactly the same sort of requirements.=20

    2) Some people have a "purity of model" approach and are offended by =

    mixing information with meta-information. That is, the putting of =
any=20
    information into SIP besides that needed for the negotiation of =
sessions=20
    external to SIP offends them. Of course, they also find the REGISTER =

    message, the INFO message, user-supplied bodies that are not SDP, =
and=20
    other such mechanisms offensive in the same way. They may be right, =
but=20
    SIP already mixes user and session-description information.=20

    3) Some operators are concerned about a re-occurrence of the =
fundamental=20
    signaling problem with SMS. As currently implemented, wireless=20
    short-message-service transits user datagrams over SS7 links which =
also=20
    transport the signaling for circuit-switced call establishement and=20
    teardown. SS7 links are also very expensive and have to be highly=20
    protected. As a result, these scarce resources get overloaded and=20
    congest, and there's not efficient way to do prioritization between =
SMS=20
    and other signaling over those links. Newer research in SMS has =
sought a=20
    means to allocate transport outside of the primary SS7 path for =
moving=20
    message bodies.=20

    Some people see an an analog between the SS7 network and the role of =
SIP=20
    proxies as signaling elements. Since the SIP proxies get mixed up in =
the=20
    transference of SIP messages, they are seen as roughly similar to =
the=20
    STPs and SMSCs in the SS7 network.=20

    Warning: Philosophical Rant Follows=20

    The key issue is buried deep in the underlying business model. In =
the=20
    Internet world, you pay the same for the bits used to signal a=20
    multimedia session as for the bits used by the multimedia session=20
    itself. In the PSTN, the carriers pay for the signaling used to set =
up=20
    the multimedia session. In other words, there is NO signaling, as=20
    signaling is used in the PSTN sense, on the Internet -- just =
application=20
    traffic. There might be messaging applications, routing =
applications,=20
    management applications, or multimedia applications, but they're =
just=20
    all applications as far as the underlying network in concerned. In =
the=20
    PSTN, signaling actually traverses a separate, specialized network,=20
    driven by its own economic laws.=20

    In the Internet world view, if an application generates profits and=20
    adding more servers allows it to generate more profit, then the=20
    application gets more servers. But in the PSTN model, signaling is =
COST=20
    and never actually generates profit -- it merely allows the=20
    establishment of sessions or the delivery of messages, and it is the =

    sessions or messages which generate the profit. Signaling is just a =
cost=20
    of doing business, and there's no good way to pass it directly on to =
the=20
    consumer or even charge it back to the application, so it always =
gets=20
    shorted. Given the fundamental laws of economics, the shortage of a=20
    useful resource increases its value, so signaling traffic becomes =
much=20
    more highly-protected and the efficiency of the signaling paramount. =

    Running on its separate, tightly-controlled and carefully managed=20
    network, PSTN signaling takes on an almost religious significance. =
It's=20
    DIFFERENT from user or application data, and SPECIAL. I seem to =
remember=20
    from my days in PSTN design that it took "two years and two million=20
    dollars" to get clearance to connect to the core SS7 network. Of =
course,=20
    this mean that no new applications git built, but it's the model the =

    phone-types understand.=20

    But there's really a deep fundamental difference between PSTN and=20
    Internet models. In a pure SIP network, we expect Internet-like=20
    end-to-end routability at layer 3. Once I know your contact =
information,=20
    I can send messages directly to you. This doesn't really exist in =
SS7.=20
    SIP proxies provide "layer 4 routing" functions like STPs, but only =
if=20
    needed by the endpoints. However, circuit-switched mindsets are =
leading=20
    to the development of SS7-like networks using SIP and IP, where the=20
    end-to-end- path at layer 3 is established ONLY if authorized by=20
    higher-layer (SIP) traffic which has transited the "trunking points" =
of=20
    operator proxies operating from within "walled gardens". In other =
words,=20
    they're insisting on reinventing the entire SS7 problem, and =
shouldn't=20
    be at all surprised when the issues that were so constraining in the =
SS7=20
    world strike again.=20

    One of the issues that comes out is that PSTN types don't know how =
to=20
    charge for signaling -- they only know how to charge for the RESULTS =
of=20
    signaling. Therefore, it is important to them to tightly control the =

    sorts of signaling that a user can do, because if a user does some =
kind=20
    of signaling that does something besides set up a session that they =
know=20
    how to charge for, that user is "stealing resources". As a =
consequence,=20
    PSTN-logic requires that the operator UNDERSTAND all signaling, and=20
    anything that isn't understood signaling needs to be relegated to=20
    transport controlled-by-signaling or just plain blocked.=20

    I'm continually approached by phone operators who start out by =
saying=20
    something like "We'll never implement the SIP MESSAGE method. Since =
it=20
    goes over our proxy network with user-supplied data, we have no way =
to=20
    charge for it and it allows users to steal network resources." I =
respond=20
    with something like "Well, the charging model of 3GPP/3GPP2 allows =
us to=20
    write a charging record indicating who sent the message, who =
received=20
    it, and how big it was. Given that, you should be able to charge for =

    each one of these messages at whatever rate the business will bear." =
The=20
    first response is something like "We can't do that, this is the=20
    SIGNALING network. What if we run out of capacity?" Then they stop =
and=20
    think about it. Sometimes, virtual dollar signs ($^$) light up in =
their=20
    eyes. Other times they wander off mumbling at/about me. But it's =
clearly=20
    an alien philosophy.=20

    --=20
    Dean=20

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


------=_NextPart_000_0024_01C1C95A.4BDD52C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hey, it's not MY fault that 3GPP made =
their proxies=20
too complicated and therefore expensive.


 


Do you have a better answer for meeting =
the=20
European privacy requirements?


 


--
Dean



  
----- Original Message ----- 

  From:=20
  Vasilis =
Polychronidis=20
  
  
  
Cc: 'Paul Kyzivat' ; 'Sean Olson'=20
  ; 'Petri=20
  K. Koskelainen' ; 'Jonathan Rosenberg' ; simple@mailman.dynamicsoft=
.com=20
  

  
Sent: Monday, March 11, 2002 =
10:28=20
  PM

  
Subject: Re: [Simple] Messages: =

  Signaling, Data, or Theft (Was something to do wit message =
threading)

  

Dear Dean, 
I =
would have=20
  agreed with your thinking if: 
1. buying a SIP proxy costs as much =
as to=20
  buy a HTTP proxy 
2. messaging traffic had the same Quality of =
Service=20
  (QOS) requirements and signaling (setting up IP calls). 
Since none =
of the=20
  above statements are true I do not agree with your thinking.=20
  
For example in order to guarantee that you get 0.1% blocking on IP =
call=20
  signaling you will have to over provision 
your SIP proxies in =
order to=20
  handle the additional messaging traffic. However since the messaging =
traffic=20
  does not 
require the same QOS as signaling you will be wasting a =
lot of=20
  capacity. 
In other words your cost for transporting messaging data =
will be=20
  the same as the signaling one.=20
  
Another example: Since SIP proxies and especially CSCFs (3GPP term =
for=20
  specialized SIP proxies) costs more than 
plain HTTP proxies =
(for=20
  the conferencing case) or IP routers (for the end to end case) then IM =
service=20
  providers will 
have to incur all this extra cost for doing IM via =
SIP=20
  proxies.=20
  
There are no philosophical differences here just basic engineering =
and=20
  economics.=20
  
-Vasilis=20
  
Dean Willis wrote:=20
  
Paul said: 
> My impression is that =
the force=20
    behind keeping IM off of the 
> SIP signalling channel is IETF =
rather=20
    than regulatory 
> agencies or mobile operators. I thought it =
had to=20
    do with UDP 
> not be flow controlled. 
> 
> The =
proposals=20
    to use a SIP-like protocol over TCP or TLS 
> resolves that =
problem.=20
    And if it transits a proxy then it can 
> handle the =
anonymization as=20
    well. But I believe doing those 
> things will require session =

    oriented messaging.=20
    
Well, there are serveral forces toward keeping user messages off =
of the=20
    
"signaling" path.=20
    
1) We've justified use of questionable flow control techniques =
for SIP=20
    
by calling it "signaling", which implies a requirement for =
low-latency=20
    
transmission using relative short messages delivered in an =
independently=20
    
atomic fashion (no head-of-line blocking).  Since this is =
somehow=20
    
different than "bulk data", i.e. emails, etc. it is "sort of" =
ok,=20
    
although SCTP is seen as the direction-of-choice for compliance =
with=20
    
proper Internet architecture. The odd thing is that "pager" mode =

    
messages have exactly the same sort of requirements.=20
    
2) Some people have a "purity of model" approach and are offended =
by=20
    
mixing information with meta-information. That is, the putting =
of any=20
    
information into SIP besides that needed for the negotiation of =
sessions=20
    
external to SIP offends them. Of course, they also find the =
REGISTER=20
    
message, the INFO message, user-supplied bodies that are not =
SDP, and=20
    
other such mechanisms offensive in the same way. They may be =
right, but=20
    
SIP already mixes user and session-description information.=20
    
3) Some operators are concerned about a re-occurrence of the =
fundamental=20
    
signaling problem with SMS. As currently implemented, wireless=20
    
short-message-service transits user datagrams over SS7 links =
which also=20
    
transport the signaling for circuit-switced call establishement =
and=20
    
teardown. SS7 links are also very expensive and have to be =
highly=20
    
protected. As a result, these scarce resources get overloaded =
and=20
    
congest, and there's not efficient way to do prioritization =
between SMS=20
    
and other signaling over those links. Newer research in SMS has =
sought a=20
    
means to allocate transport outside of the primary SS7 path for =
moving=20
    
message bodies.=20
    
Some people see an an analog between the SS7 network and the role =
of SIP=20
    
proxies as signaling elements. Since the SIP proxies get mixed =
up in the=20
    
transference of SIP messages, they are seen as roughly similar =
to the=20
    
STPs and SMSCs in the SS7 network.=20
    
Warning: Philosophical Rant Follows=20
    
The key issue is buried deep in the underlying business model. In =
the=20
    
Internet world, you pay the same for the bits used to signal a=20
    
multimedia session as for the bits used by the multimedia =
session=20
    
itself. In the PSTN, the carriers pay for the signaling used to =
set up=20
    
the multimedia session. In other words, there is NO signaling, =
as=20
    
signaling is used in the PSTN sense, on the Internet -- just =
application=20
    
traffic. There might be messaging applications, routing =
applications,=20
    
management applications, or multimedia applications, but they're =
just=20
    
all applications as far as the underlying network in concerned. =
In the=20
    
PSTN, signaling actually traverses a separate, specialized =
network,=20
    
driven by its own economic laws.=20
    
In the Internet world view, if an application generates profits =
and=20
    
adding more servers allows it to generate more profit, then the=20
    
application gets more servers. But in the PSTN model, signaling =
is COST=20
    
and never actually generates profit -- it merely allows the=20
    
establishment of sessions or the delivery of messages, and it is =
the=20
    
sessions or messages which generate the profit. Signaling is =
just a cost=20
    
of doing business, and there's no good way to pass it directly =
on to the=20
    
consumer or even charge it back to the application, so it always =
gets=20
    
shorted. Given the fundamental laws of economics, the shortage =
of a=20
    
useful resource increases its value, so signaling traffic =
becomes much=20
    
more highly-protected and the efficiency of the signaling =
paramount.=20
    
Running on its separate, tightly-controlled and carefully =
managed=20
    
network, PSTN signaling takes on an almost religious =
significance. It's=20
    
DIFFERENT from user or application data, and SPECIAL. I seem to =
remember=20
    
from my days in PSTN design that it took "two years and two =
million=20
    
dollars" to get clearance to connect to the core SS7 network. Of =
course,=20
    
this mean that no new applications git built, but it's the model =
the=20
    
phone-types understand.=20
    
But there's really a deep fundamental difference between PSTN and =

    
Internet models. In a pure SIP network, we expect Internet-like=20
    
end-to-end routability at layer 3. Once I know your contact =
information,=20
    
I can send messages directly to you. This doesn't really exist =
in SS7.=20
    
SIP proxies provide "layer 4 routing" functions like STPs, but =
only if=20
    
needed by the endpoints. However, circuit-switched mindsets are =
leading=20
    
to the development of SS7-like networks using SIP and IP, where =
the=20
    
end-to-end- path at layer 3 is established ONLY if authorized by =

    
higher-layer (SIP) traffic which has transited the "trunking =
points" of=20
    
operator proxies operating from within "walled gardens". In =
other words,=20
    
they're insisting on reinventing the entire SS7 problem, and =
shouldn't=20
    
be at all surprised when the issues that were so constraining in =
the SS7=20
    
world strike again.=20
    
One of the issues that comes out is that PSTN types don't know =
how to=20
    
charge for signaling -- they only know how to charge for the =
RESULTS of=20
    
signaling. Therefore, it is important to them to tightly control =
the=20
    
sorts of signaling that a user can do, because if a user does =
some kind=20
    
of signaling that does something besides set up a session that =
they know=20
    
how to charge for, that user is "stealing resources". As a =
consequence,=20
    
PSTN-logic requires that the operator UNDERSTAND all signaling, =
and=20
    
anything that isn't understood signaling needs to be relegated =
to=20
    
transport controlled-by-signaling or just plain blocked.=20
    
I'm continually approached by phone operators who start out by =
saying=20
    
something like "We'll never implement the SIP MESSAGE method. =
Since it=20
    
goes over our proxy network with user-supplied data, we have no =
way to=20
    
charge for it and it allows users to steal network resources." I =
respond=20
    
with something like "Well, the charging model of 3GPP/3GPP2 =
allows us to=20
    
write a charging record indicating who sent the message, who =
received=20
    
it, and how big it was. Given that, you should be able to charge =
for=20
    
each one of these messages at whatever rate the business will =
bear." The=20
    
first response is something like "We can't do that, this is the=20
    
SIGNALING network. What if we run out of capacity?" Then they =
stop and=20
    
think about it. Sometimes, virtual dollar signs ($^$) light up =
in their=20
    
eyes. Other times they wander off mumbling at/about me. But it's =
clearly=20
    
an alien philosophy.=20
    
-- 
Dean=20
    
_______________________________________________ 
simple =
mailing list=20
    
simple@mailman.dynamicsoft.com 
http://ma=
ilman.dynamicsoft.com/mailman/listinfo/simple


------=_NextPart_000_0024_01C1C95A.4BDD52C0--


From Markus.Isomaki@nokia.com  Tue Mar 12 15:38:44 2002
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 PAA06976
	for ; Tue, 12 Mar 2002 15:38:43 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2CKbD319269
	for ; Tue, 12 Mar 2002 22:37:13 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 12 Mar 2002 22:37:51 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 12 Mar 2002 22:37:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again)
Date: Tue, 12 Mar 2002 22:37:51 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again)
Thread-Index: AcHGbgf5fPKVe+7GTEq1R2Cd8URVAwDlD5Mg
To: , 
Cc: 
X-OriginalArrivalTime: 12 Mar 2002 20:37:51.0747 (UTC) FILETIME=[C7B83530:01C1CA05]
Content-Length: 5046
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA06976
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: 

Hi,

Just to inform you that 3GPP is stepping into this territory too (believe it or not). Their presence architecture is basically starting to look SIMPLE-based, but some requirements, such as presence publishing or managing presence ACLs, is beyond the scope of current SIMPLE specs. 3GPP will also shortly start work on the evolution of messaging and something called group management.

So, now is certainly the time for the IETF to charter these kind of things if a unified solution for the _Internet_ is wanted. Otherwise e.g. wireless domain may diverge into some solution of their own. I think this is something for the IESG to consider when evaluating the possible rechartering proposals. However, if IETF will go forward, 3GPP's role might be to write a requirements (maybe this time with real requirements, distinct from solutions :-) draft from 3G wireless point of view, and then apply the results in their architecture. Obviously timing is important, I'm not sure if the IETF could realistically be expected to finish these kind of things in 12 months etc. So, there might be again guys on the mic telling that 3GPP needs this and this draft by this and this date for Release X...

Note that standardizing something like provisioning or data manipulation interface may not make sense in the PC-centric world, where web-browser interfaces are OK. However, in 2*2 inch handset screen with numerical keyboard it may not be feasible to leave it that open. And 400+ million handsets a year can't be wrong :-)

So, I vote for discussion in Minneapolis, preferably leading to a rechartering proposal with a quick decision schedule. I'm also willing to work on this, and I know a couple of other guys who would be too.

Regards,
	Markus  

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 08 March, 2002 8:53
> To: Tony Hansen
> Cc: SIMPLE list
> Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy
> List, Again)
> 
> 
> 
> 
> Tony Hansen wrote:
> > 
> > Here are some ideas on how this could play out within the IETF.
> > 
> > One of the documents being put out in the SIP WG is SIP Call Flow
> > Examples. It shows how the SIP protocol should be used in an IP
> > Telephony service.
> > 
> > Another effort in the IETF is the Voice Profile for 
> Internet Messaging
> > (VPIM) working group. That group has been figuring out how 
> to do voice
> > messaging (for voice mailboxes) using existing protocols, 
> such as SMTP
> > and IMAP. Where the existing protocols were lacking, they 
> also worked on
> > filling in the gaps, either within the VPIM WG or in 
> conjunction with
> > other working groups (e.g., imap-ext). Note: the VPIM WG 
> was originally
> > formed due to input from an external organization, the EMA, 
> but the work
> > has all been done here in the IETF.
> > 
> > The problem we're facing here in SIMPLE seems to be in the same
> > category, and the solution may be similar. It appears that what is
> > required is a profile for an instant messaging service saying how it
> > should pull together the different piece parts to form a 
> coherent whole.
> 
> Well, there are two parts.
> 
> Part one, is to specify the pieces, and to make sure they are 
> all there.
> Part two, is to specify an architecture that puts them together as a
> whole.
> 
> Part one is definitely an IETF activity. We really have most of the
> pieces, and the few that remain, are easy. I have written an 
> I-D on this
> subject, which discusess the pieces needed for a consumer 
> IM/buddy-list
> application:
> 
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-components-00.txt

I'd really like to get group input on whether there is
interest/agreement on which aspects of my proposed plan.

The second piece, part two, is to specify an architecture that pulls it
all together. If such a thing were done here, it would need to be
informational to say the least. There is precendent for publication of
informational architecture docs generated by other bodies (the DCS
architecture). I think SOMEONE needs to put this together, that is for
certain. If no one else is stepping up to the plate, I'd prefer IETF to
nobody, thats for sure.

> 
> I'm convinced we can solve this problem. Getting feedback from the
> industry is absolutely useful in the process, but I think the work needs
> to happen here, in the IETF. And I'm willing to work on it.
> 
> Comments? Should something like this go on the SIMPLE agenda for
> Minneapolis?

I'd like to discuss it, yes.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

From dean.willis@softarmor.com  Tue Mar 12 17:31:33 2002
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 RAA07388
	for ; Tue, 12 Mar 2002 17:31:31 -0500 (EST)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2CMU7U02899;
	Tue, 12 Mar 2002 16:30:07 -0600
From: "Dean Willis" 
To: "'Dean Willis'" ,
        "'Paul Kyzivat'" 
Cc: 
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit message threading)
Date: Tue, 12 Mar 2002 16:29:58 -0600
Message-ID: <000001c1ca15$71a9ec50$bb036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 1977
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: 

> Warning: Philosophical Rant Follows
> 
> The key issue is buried deep in the underlying business 
> model. In the Internet world, you pay the same for the bits 
> used to signal a multimedia session as for the bits used by 
> the multimedia session itself. In the PSTN, the carriers pay 
> for the signaling used to set up the multimedia session. In 
> other words, there is NO signaling, as signaling is used in 
> the PSTN sense, on the Internet -- just application traffic. 
> There might be messaging applications, routing applications, 
> management applications, or multimedia applications, but 
> they're just all applications as far as the underlying 
> network in concerned. In the PSTN, signaling actually 
> traverses a separate, specialized network, driven by its own 
> economic laws.
> 

Reference remaining rant elsewhere.

Here's an example.

-----------
From last year's Next Steps in Signaling BOF:

6.5 James Kempf
   Radio access networks - air is expensive.  Optimize by using less
   bandwidth and more (for example) CPU cycles. Whatever the signaling
   protocol is, it must be very efficient for mobility. Providers pay
   big $$ for the airwaves, they don't want  to use it for signaling,
   but for user data.  Best: do the signaling through the backbone, and
   not over the air if possible.  The signaling must be efficient for
   mobility to minimize signaling while moving from area to area.
   Mobility signalling should be directly coupled to the traffic.
-------------

See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt

Clearly from the provider perspective, user data and signaling are two
different things. Therein lies the debate. For if a user were to do
something that "looks like" signaling, they would intrude on the
territory of the operator.

The problem here: is Messaging the same as signaling? Is Presence the
same as signaling? Is anything we do with SIP really "signaling" or is
it user data?

--
Dean


From mhammer@cisco.com  Wed Mar 13 10:41:36 2002
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 KAA10535
	for ; Wed, 13 Mar 2002 10:41:36 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DFf4D04816;
	Wed, 13 Mar 2002 10:41:04 -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 AAR72113;
	Wed, 13 Mar 2002 10:35:36 -0500 (EST)
Message-Id: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 13 Mar 2002 10:40:40 -0500
To: "Dean Willis" 
From: Michael Hammer 
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was
  something to do wit message threading)
Cc: "'Dean Willis'" ,
        "'Paul Kyzivat'" ,
        
In-Reply-To: <000001c1ca15$71a9ec50$bb036e3f@TXDWILLIS2>
References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Content-Length: 4099
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: 


Dean,



There are some things users care about and will pay for, and other things
they won't.  For connection oriented services, they consider the
"air time" when they have full cut-through to when they get
disconnected to be the value.  In connectionless services, they care
about data packets getting through, not overhead signaling packets.



You seem to be suggesting that the customer pay for the time they spend
waiting for the signaling to complete the call.  Or, you expect them
to pay for signaling as well as data-bearing messages.  This is
analogous to making customers pay for packaging, when all they want is
the handful of tablets in the little bottle inside the big box.



Near where I live there is an ice-skating rink that charges by the
hour.  Most people won't put up including in that hour the time
taken to fill out forms and select skates.  Nor would they pay for
time where they are standing in line for that process.  Not standing
in line, getting to the rink sooner, and skating a full hour have
value.



This is not just the service provider perspective, but the customer
perspective.



It's OK to get philosophical, just keep it real. :)



Mike





At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:




> Warning: Philosophical Rant Follows

> 

> The key issue is buried deep in the underlying business 

> model. In the Internet world, you pay the same for the bits 

> used to signal a multimedia session as for the bits used by 

> the multimedia session itself. In the PSTN, the carriers pay 

> for the signaling used to set up the multimedia session. In 

> other words, there is NO signaling, as signaling is used in 

> the PSTN sense, on the Internet -- just application traffic. 

> There might be messaging applications, routing applications, 

> management applications, or multimedia applications, but 

> they're just all applications as far as the underlying 

> network in concerned. In the PSTN, signaling actually 

> traverses a separate, specialized network, driven by its own 

> economic laws.

> 



Reference remaining rant elsewhere.



Here's an example.



-----------

 From last year's Next Steps in Signaling BOF:



6.5 James Kempf

   Radio access networks - air is expensive.  Optimize by
using less

   bandwidth and more (for example) CPU cycles. Whatever the
signaling

   protocol is, it must be very efficient for mobility.
Providers pay

   big $$ for the airwaves, they don't want  to use it for
signaling,

   but for user data.  Best: do the signaling through the
backbone, and

   not over the air if possible.  The signaling must be
efficient for

   mobility to minimize signaling while moving from area to
area.

   Mobility signalling should be directly coupled to the
traffic.

-------------



See
http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt



Clearly from the provider perspective, user data and signaling are
two

different things. Therein lies the debate. For if a user were to do

something that "looks like" signaling, they would intrude on
the

territory of the operator.



The problem here: is Messaging the same as signaling? Is Presence
the

same as signaling? Is anything we do with SIP really
"signaling" or is

it user data?



--

Dean



_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple




From dgboyer@avaya.com  Wed Mar 13 10:58:53 2002
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10616
	for ; Wed, 13 Mar 2002 10:58:53 -0500 (EST)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2DFuXI22686
	for ; Wed, 13 Mar 2002 10:56:33 -0500 (EST)
Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g2DFuX622676
	for ; Wed, 13 Mar 2002 10:56:33 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Date: Wed, 13 Mar 2002 10:58:37 -0500
Message-ID: <8CA1128D59AD27429985B397118CEDDF78FEB7@nj7460avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Thread-Index: AcHGyu9Rpl8M1KvNTA+ZYSDNHhAELgD3KRIw
From: "Boyer, David G (Dave)" 
To: "Sean Olson" ,
        "Petri K. Koskelainen" ,
        "Jonathan Rosenberg" 
Cc: 
Content-Length: 2636
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA10616
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: 

We consistently use group "persistent" chat where I work.
When a user arrives after a discussion has begun he/she
can see what has been said.  If you use the one-shoot
pager model this will not be possible.  
This is useful for many reasons - a CRM example is a 
supervisor might need to join in a chat that has been
going on between an agent and a customer.  He/she will
need to see what has been said.

Dave Boyer

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Friday, March 08, 2002 12:57 PM
> To: Petri K. Koskelainen; Jonathan Rosenberg
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt
> (threading)
> 
> 
> Group chat is of course a better fit for the
> session model. One-time delivery of messages to
> a group is a better fit for paging as Petri points
> out. How common is this? I can think of a TON of
> applications that fit this scenario. What features
> of group messaging can't be implemented in a paging
> mode?
> 
> /sean
> 
> --- "Petri K. Koskelainen" 
> wrote:
> > 
> > > A discussion we REALLY need to have, is whether we
> > think that the paging
> > > model even makes sense for multiparty. I am really
> > not convinced. It
> > > seems that multiparty paging model is really more
> > like email, and that
> > > is not what IM is supposed to be. If group IM is
> > supposed to be real
> > > time, It just works so much better in the session
> > model. So many
> > > problems (like this one above) just evaporate.
> > > 
> > > Can anyone suggest a reason why the paging model
> > is preferrable for
> > > group chat? Simplicity is one, but that simplicity
> > might be elusive as
> > > you try to fill in all the missing pieces.
> > 
> > There are one-shot scenarios which require realtime
> > delivery
> > to a group. It is quite heavy operation to set up a
> > session,
> > send one IM, and then close the session. 
> > Example usage might be an urgent realtime
> > announcement to a 
> > pre-defined group.
> > 
> >  
> > BR,
> > --
> > Petri
> > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 
> =====
> Sean Olson 
> 
> __________________________________________________
> Do You Yahoo!?
> Try FREE Yahoo! Mail - the world's greatest free email!
> http://mail.yahoo.com/
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From duncan.mills@vf.vodafone.co.uk  Wed Mar 13 11:14:19 2002
Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10699
	for ; Wed, 13 Mar 2002 11:14:16 -0500 (EST)
From: duncan.mills@vf.vodafone.co.uk
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id QAA16425; Wed, 13 Mar 2002 16:13:16 GMT
Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67])
	by mailguard1 (4.6.1.91) with ESMTP id 
	for ; Wed, 13 Mar 2002 17:11:23 +0100
Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone
 (Content Technologies SMTPRS 2.0.15) with ESMTP id ;
 Wed, 13 Mar 2002 16:10:51 +0000
Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Mar 2002 16:10:50 -0000
Message-Id: 
To: mhammer@cisco.com, dean.willis@softarmor.com
Cc: dean.willis@softarmor.com, pkyzivat@cisco.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something t
	o do wit message threading)
Date: Wed, 13 Mar 2002 16:10:44 -0000
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.109)
Content-Type: text/plain;	charset="iso-8859-1"
Content-Length: 5253
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: 

Michael,
 
The signalling (packaging in your analogy) costs the operator x.  The
operator cannot realistically charge the customer for the signalling
(packaging), as the customer is unaware of and gets no value from most of
it.  So the operator is x out of pocket.
 
The operator can charge the customer for the services (the tablets).  The
services (tablets) cost y.
 
Most operators will charge y+x for services and keep the signalling 'free'
for the users.
 
Of course, this is more likely to be x + y + p, where p=profit ;-)
 
Ultimately, the signalling costs operators (especially across the radio
interface) and that cost should be kept at a minimum.
 
We have to be careful with things like instant messaging.  If I were able to
initiate a voice call towards you with some display text that appears on
your terminal as "Duncan is calling and wants to know if you still want to
meet him for a drink tonight," you could simply ignore the call.  So I have
passed a message to you that cost me nothing.  You then initiate a voice
call towards me.  This appears on my terminal as "Michael is calling and
yes, I'll meet you in the local bar at 8p.m."  I don't answer.  You have
replied to me free of charge.
 
Both of those call set-ups have cost the operator dearly, and he can't
really charge for it...
 
Regards,
 
Duncan
 
 

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: 13 March 2002 15:41
To: Dean Willis
Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to
do wit message threading)


Dean,

There are some things users care about and will pay for, and other things
they won't.  For connection oriented services, they consider the "air time"
when they have full cut-through to when they get disconnected to be the
value.  In connectionless services, they care about data packets getting
through, not overhead signaling packets.

You seem to be suggesting that the customer pay for the time they spend
waiting for the signaling to complete the call.  Or, you expect them to pay
for signaling as well as data-bearing messages.  This is analogous to making
customers pay for packaging, when all they want is the handful of tablets in
the little bottle inside the big box.

Near where I live there is an ice-skating rink that charges by the hour.
Most people won't put up including in that hour the time taken to fill out
forms and select skates.  Nor would they pay for time where they are
standing in line for that process.  Not standing in line, getting to the
rink sooner, and skating a full hour have value.

This is not just the service provider perspective, but the customer
perspective.

It's OK to get philosophical, just keep it real. :)

Mike


At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:



> Warning: Philosophical Rant Follows
> 
> The key issue is buried deep in the underlying business 
> model. In the Internet world, you pay the same for the bits 
> used to signal a multimedia session as for the bits used by 
> the multimedia session itself. In the PSTN, the carriers pay 
> for the signaling used to set up the multimedia session. In 
> other words, there is NO signaling, as signaling is used in 
> the PSTN sense, on the Internet -- just application traffic. 
> There might be messaging applications, routing applications, 
> management applications, or multimedia applications, but 
> they're just all applications as far as the underlying 
> network in concerned. In the PSTN, signaling actually 
> traverses a separate, specialized network, driven by its own 
> economic laws.
> 

Reference remaining rant elsewhere.

Here's an example.

-----------
From last year's Next Steps in Signaling BOF:

6.5 James Kempf
   Radio access networks - air is expensive.  Optimize by using less
   bandwidth and more (for example) CPU cycles. Whatever the signaling
   protocol is, it must be very efficient for mobility. Providers pay
   big $$ for the airwaves, they don't want  to use it for signaling,
   but for user data.  Best: do the signaling through the backbone, and
   not over the air if possible.  The signaling must be efficient for
   mobility to minimize signaling while moving from area to area.
   Mobility signalling should be directly coupled to the traffic.
-------------

See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
 

Clearly from the provider perspective, user data and signaling are two
different things. Therein lies the debate. For if a user were to do
something that "looks like" signaling, they would intrude on the
territory of the operator.

The problem here: is Messaging the same as signaling? Is Presence the
same as signaling? Is anything we do with SIP really "signaling" or is
it user data?

--
Dean

_______________________________________________
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 dean.willis@softarmor.com  Wed Mar 13 12:08:24 2002
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 MAA10917
	for ; Wed, 13 Mar 2002 12:08:23 -0500 (EST)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2DH7QU09309;
	Wed, 13 Mar 2002 11:07:26 -0600
Message-ID: <014e01c1cab1$8ce4c6b0$133fed0c@C1893415A>
From: "Dean Willis" 
To: "Boyer, David G \(Dave\)" ,
        "Sean Olson" ,
        "Petri K. Koskelainen" ,
        "Jonathan Rosenberg" 
Cc: 
References: <8CA1128D59AD27429985B397118CEDDF78FEB7@nj7460avexu1.global.avaya.com>
Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Date: Wed, 13 Mar 2002 11:07:25 -0600
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
Content-Length: 649
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: 

> We consistently use group "persistent" chat where I work.
> When a user arrives after a discussion has begun he/she
> can see what has been said.  If you use the one-shoot
> pager model this will not be possible.
> This is useful for many reasons - a CRM example is a
> supervisor might need to join in a chat that has been
> going on between an agent and a customer.  He/she will
> need to see what has been said.

That seems to me to be a function of the application server hosting the chat
and independent of the message transport used, although it does raise
interesting questions for both transport models we've commonly discussed.

--
Dean


From dean.willis@softarmor.com  Wed Mar 13 12:20:23 2002
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 MAA10980
	for ; Wed, 13 Mar 2002 12:20:23 -0500 (EST)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2DHIvU09377;
	Wed, 13 Mar 2002 11:18:57 -0600
Message-ID: <015501c1cab3$28ccc630$133fed0c@C1893415A>
From: "Dean Willis" 
To: "Michael Hammer" 
Cc: 
References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2> <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was  something to do wit message threading)
Date: Wed, 13 Mar 2002 11:18:57 -0600
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
Content-Length: 1984
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: 

----- Original Message -----
From: Michael Hammer
...
There are some things users care about and will pay for, and other
things they won't.  For connection oriented services, they consider the
"air time" when they have full cut-through to when they get disconnected
to be the value.  In connectionless services, they care about data
packets getting through, not overhead signaling packets.

You seem to be suggesting that the customer pay for the time they spend
waiting for the signaling to complete the call.  Or, you expect them to
pay for signaling as well as data-bearing messages.  This is analogous
to making customers pay for packaging, when all they want is the handful
of tablets in the little bottle inside the big box.
--------------------------

No. Actually, I think time-based services, especially in a messaging
context, are a silly idea.

This is the Internet. People CHOOSE what applications they are going to
run. One of the reasons they choose A over B might be that A is more
efficient in the way it signals.

In your model, people are still paying for the packaging (it's ALWAYS
wrapped up in the cost of the product) but since you're hiding it from
them and mandating the format, they have no incentive and no mechanism
to encourage efficiency.

Here's an example. I read my mail frequently over GSM circuit-switched
data at 9600 bps. This is expensive. So I use SSH with compression,
which beefs up the security immensely and generally saves me about 25%.
Now, what part of that traffic was signaling, and what part application?
I'd say only the GSM control traffic that set up the call was
"signaling" and everything I sent over the circuit, i.e. all my IP data,
was application.How is this different from what we're talking about with
SIMPLE?

The INTERNET is not a circuit switched phone network, and it's not so
simple as phone people assume to differentiate signaling from
application data.

But this has gotten rather far afield for this list.

--
Dean


From seancolson@yahoo.com  Wed Mar 13 12:34:57 2002
Received: from web11601.mail.yahoo.com (web11601.mail.yahoo.com [216.136.172.53])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA11054
	for ; Wed, 13 Mar 2002 12:34:56 -0500 (EST)
Message-ID: <20020313173406.68306.qmail@web11601.mail.yahoo.com>
Received: from [131.107.3.86] by web11601.mail.yahoo.com via HTTP; Wed, 13 Mar 2002 09:34:06 PST
Date: Wed, 13 Mar 2002 09:34:06 -0800 (PST)
From: Sean Olson 
Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
To: "Boyer, David G \(Dave\)" ,
        "Petri K. Koskelainen" ,
        Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
In-Reply-To: <8CA1128D59AD27429985B397118CEDDF78FEB7@nj7460avexu1.global.avaya.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1187
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: 

There is no reason this cannot be achieved with the
paging model. In fact neither model directly provides 
support for what you are talking about -- and neither
prevents building what you want. I can see the 
usefulness of this feature, but I expect you will
need/want a separate channel to look at the history
of a chat "session". If nothing else, you would
want to be able to separate past messages from
live chat without mistakenly discarding a "past" 
message as being out of context.

/sean

--- "Boyer, David G (Dave)"  wrote:
> We consistently use group "persistent" chat where I
> work.
> When a user arrives after a discussion has begun
> he/she
> can see what has been said.  If you use the
> one-shoot
> pager model this will not be possible.  
> This is useful for many reasons - a CRM example is a
> 
> supervisor might need to join in a chat that has
> been
> going on between an agent and a customer.  He/she
> will
> need to see what has been said.
> 
> Dave Boyer

=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

From mhammer@cisco.com  Wed Mar 13 14:06:30 2002
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 OAA11355
	for ; Wed, 13 Mar 2002 14:06:29 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DJ5vJ02580;
	Wed, 13 Mar 2002 14:05:57 -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 AAR74509;
	Wed, 13 Mar 2002 14:00:29 -0500 (EST)
Message-Id: <4.3.2.7.2.20020313135918.00b65b48@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 13 Mar 2002 14:05:35 -0500
To: "Dean Willis" 
From: Michael Hammer 
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was 
  something to do wit message threading)
Cc: 
In-Reply-To: <015501c1cab3$28ccc630$133fed0c@C1893415A>
References: <004701c1c94a$a1e50bf0$bb036e3f@TXDWILLIS2>
 <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Content-Length: 3200
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: 


Dean,



Agree with the general sentiment of your reply.  But, inherent in
your previous emails was the idea that the service provider could somehow
get revenue from the IMs intermingled with the session setup messages to
cover the cost of over-provisioning the proxies to cover peak IM storms,
yet keep signaling message delay low.



This lead to the thought that you must charge per message for both IM
(data) and for SIP messages (signaling).  All I was questioning was
whether the user will see the value in paying for the signaling, that for
the most part is invisible to him, and perhaps beyond his control to
account for.  I see that as problematic.



Simply redesigning to make something that once was network internal to be
user-provided does not mean the user will appreciate why he pays
more.



Mike







At 11:18 AM 3/13/2002 -0600, Dean Willis wrote:


----- Original Message -----

From: Michael Hammer

...

There are some things users care about and will pay for, and other

things they won't.  For connection oriented services, they consider
the

"air time" when they have full cut-through to when they get
disconnected

to be the value.  In connectionless services, they care about
data

packets getting through, not overhead signaling packets.



You seem to be suggesting that the customer pay for the time they
spend

waiting for the signaling to complete the call.  Or, you expect them
to

pay for signaling as well as data-bearing messages.  This is
analogous

to making customers pay for packaging, when all they want is the
handful

of tablets in the little bottle inside the big box.

--------------------------



No. Actually, I think time-based services, especially in a 
messaging

context, are a silly idea.



This is the Internet. People CHOOSE what applications they are going
to

run. One of the reasons they choose A over B might be that A is 
more

efficient in the way it signals.



In your model, people are still paying for the packaging (it's
ALWAYS

wrapped up in the cost of the product) but since you're hiding it
from

them and mandating the format, they have no incentive and no
mechanism

to encourage efficiency.



Here's an example. I read my mail frequently over GSM
circuit-switched

data at 9600 bps. This is expensive. So I use SSH with compression,

which beefs up the security immensely and generally saves me about
25%.

Now, what part of that traffic was signaling, and what part
application?

I'd say only the GSM control traffic that set up the call was

"signaling" and everything I sent over the circuit, i.e. all my
IP data,

was application.How is this different from what we're talking about
with

SIMPLE?



The INTERNET is not a circuit switched phone network, and it's not
so

simple as phone people assume to differentiate signaling from

application data.



But this has gotten rather far afield for this list.



--

Dean



From bcampbell@dynamicsoft.com  Wed Mar 13 15:49:48 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11709
	for ; Wed, 13 Mar 2002 15:49:47 -0500 (EST)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2DKmW207339;
	Wed, 13 Mar 2002 14:48:32 -0600 (CST)
From: "Ben Campbell" 
To: "Michael Hammer" ,
        "Dean Willis" 
Cc: "'Dean Willis'" ,
        "'Paul Kyzivat'" ,
        
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was  something to do wit message threading)
Date: Wed, 13 Mar 2002 14:47:15 -0600
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: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
Content-Length: 4560
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: 

You example only works when you apply a billing model (per minute billing)
to a medium (IP applications) where it doesn't make sense. Indeed, I think
the per-minute model is not so much expected by users--it is just the
carriers don't know how to bill any other way.

If you applied a more IP Centric billing model (charge per byte), then you
can easily charge for signal and user data the same way. My GPRS service
provider charges for GPRS data in exactly this manner--if I run a SIMPLE
service across it, they just see bytes. A signal byte and a user byte are
indistinguishable.

My personal nightmare is hearing that carriers want to charge X per byte,
except for bytes that were in SIP messages.


-----Original Message-----
From: simple-admin@mailman.dynamicsoft.com
[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer
Sent: Wednesday, March 13, 2002 9:41 AM
To: Dean Willis
Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to
do wit message threading)


Dean,

There are some things users care about and will pay for, and other things
they won't.  For connection oriented services, they consider the "air time"
when they have full cut-through to when they get disconnected to be the
value.  In connectionless services, they care about data packets getting
through, not overhead signaling packets.

You seem to be suggesting that the customer pay for the time they spend
waiting for the signaling to complete the call.  Or, you expect them to pay
for signaling as well as data-bearing messages.  This is analogous to making
customers pay for packaging, when all they want is the handful of tablets in
the little bottle inside the big box.

Near where I live there is an ice-skating rink that charges by the hour.
Most people won't put up including in that hour the time taken to fill out
forms and select skates.  Nor would they pay for time where they are
standing in line for that process.  Not standing in line, getting to the
rink sooner, and skating a full hour have value.

This is not just the service provider perspective, but the customer
perspective.

It's OK to get philosophical, just keep it real. :)

Mike


At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:


> Warning: Philosophical Rant Follows
>
> The key issue is buried deep in the underlying business
> model. In the Internet world, you pay the same for the bits
> used to signal a multimedia session as for the bits used by
> the multimedia session itself. In the PSTN, the carriers pay
> for the signaling used to set up the multimedia session. In
> other words, there is NO signaling, as signaling is used in
> the PSTN sense, on the Internet -- just application traffic.
> There might be messaging applications, routing applications,
> management applications, or multimedia applications, but
> they're just all applications as far as the underlying
> network in concerned. In the PSTN, signaling actually
> traverses a separate, specialized network, driven by its own
> economic laws.
>

Reference remaining rant elsewhere.

Here's an example.

-----------
From last year's Next Steps in Signaling BOF:

6.5 James Kempf
   Radio access networks - air is expensive.  Optimize by using less
   bandwidth and more (for example) CPU cycles. Whatever the signaling
   protocol is, it must be very efficient for mobility. Providers pay
   big $$ for the airwaves, they don't want  to use it for signaling,
   but for user data.  Best: do the signaling through the backbone, and
   not over the air if possible.  The signaling must be efficient for
   mobility to minimize signaling while moving from area to area.
   Mobility signalling should be directly coupled to the traffic.
-------------

See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt

Clearly from the provider perspective, user data and signaling are two
different things. Therein lies the debate. For if a user were to do
something that "looks like" signaling, they would intrude on the
territory of the operator.

The problem here: is Messaging the same as signaling? Is Presence the
same as signaling? Is anything we do with SIP really "signaling" or is
it user data?

--
Dean

_______________________________________________
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 bcampbell@dynamicsoft.com  Wed Mar 13 16:01:08 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11770
	for ; Wed, 13 Mar 2002 16:01:03 -0500 (EST)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2DKxh208292;
	Wed, 13 Mar 2002 14:59:43 -0600 (CST)
From: "Ben Campbell" 
To: "Dean Willis" ,
        "Jonathan Rosenberg" ,
        "Petri K. Koskelainen" 
Cc: 
Subject: RE: [Simple] Re: draft-rosenberg-simple-components-00.txt (threading)
Date: Wed, 13 Mar 2002 14:58:26 -0600
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: <009501c1c7b3$4f356fa0$133fed0c@C1893415A>
Content-Length: 2495
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: 

I think think I agree with Dean in that it is not so much the _group_ aspect
as the _chat_ aspect that indicates the use of a session. There are
perfectly good page mode applications for groups.

It is the _conference_ aspects that make sessions interesting--things like
knowing who is participating at any time, association with other media
streams, etc.

If all I want to do is send a quick, short message to multiple people, I
rather hope I do not have to set up a session to do it.

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Dean Willis
> Sent: Saturday, March 09, 2002 3:42 PM
> To: Jonathan Rosenberg; Petri K. Koskelainen
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Re: draft-rosenberg-simple-components-00.txt
> (threading)
>
>
> Jonathan asked:
> > A discussion we REALLY need to have, is whether we think that the paging
> > model even makes sense for multiparty. I am really not convinced. It
> > seems that multiparty paging model is really more like email, and that
> > is not what IM is supposed to be. If group IM is supposed to be real
> > time, It just works so much better in the session model. So many
> > problems (like this one above) just evaporate.
> >
> > Can anyone suggest a reason why the paging model is preferrable for
> > group chat? Simplicity is one, but that simplicity might be elusive as
> > you try to fill in all the missing pieces.
>
> Well, if some of your participants are coming and going, you have an open
> question about whether store-and-forward delivery to those paticipants is
> appropriate.
>
> If we do store-and-forward, then it really IS like fast email, and I would
> posit that the paging model makes excellent sense. If on the
> other hand the
> model is a "chat room" where unless you are in the room, you never see the
> message, then a session model makes more sense.
>
> So I suggest that we may wish to consider distinguishing these two models
> from a requirements analysis perspective.
>
> I believe if we follow this to a logical conclusion that we'll end up with
> two very different implementations serving the different modalities, and a
> couple of logical "transition points" where messaging sequence
> move from one
> mode to the other.
>
> --
> Dean
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From mhammer@cisco.com  Wed Mar 13 17:43:24 2002
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 RAA12155
	for ; Wed, 13 Mar 2002 17:43:24 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DMgqo02044;
	Wed, 13 Mar 2002 17:42:52 -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 AAR77007;
	Wed, 13 Mar 2002 17:37:23 -0500 (EST)
Message-Id: <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 13 Mar 2002 17:42:28 -0500
To: "Ben Campbell" 
From: Michael Hammer 
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was 
  something to do wit message threading)
Cc: "Dean Willis" ,
        "'Dean Willis'" ,
        "'Paul Kyzivat'" ,
        
In-Reply-To: 
References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 6023
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: 

Ben,

When you consider RTP over IP, which fits your "IP application" definition, 
whether you charge per packet or realize that statistically X packets and Y 
minutes is "six of one, half a dozen of the other" then there are some 
models where per minute works out to be the same value.

How do you reconcile volume charging with the two things that I noticed 
about my two services:  ISP:  Bills me a flat monthly fee for data 
service.  Mobile phone:  Bills me flat monthly fee for phone service, with 
per minute charges above an agreed on number of "free" minutes.  It didn't 
used to be like that.  Seems you are suggesting a trend-reversal or at 
least an exception to the rule.

The earlier models of charging per data connection minute or per minute of 
call did not encourage usage and therefore generate enough revenue.  Per 
byte charges can generate revenue, but only if it doesn't discourage use.

Will the per-byte prices be low enough to encourage use, yet still cover 
the cost of over-provisioning the network to keep setup delay low?  Will 
connection-less IM users pay a premium to make sure that 
connection-oriented RTP-flow users don't experience setup delays?  Tell me, 
who pays for excess capacity?  This could be a competitive discriminator.

Mike


At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
>You example only works when you apply a billing model (per minute billing)
>to a medium (IP applications) where it doesn't make sense. Indeed, I think
>the per-minute model is not so much expected by users--it is just the
>carriers don't know how to bill any other way.
>
>If you applied a more IP Centric billing model (charge per byte), then you
>can easily charge for signal and user data the same way. My GPRS service
>provider charges for GPRS data in exactly this manner--if I run a SIMPLE
>service across it, they just see bytes. A signal byte and a user byte are
>indistinguishable.
>
>My personal nightmare is hearing that carriers want to charge X per byte,
>except for bytes that were in SIP messages.
>
>
>-----Original Message-----
>From: simple-admin@mailman.dynamicsoft.com
>[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer
>Sent: Wednesday, March 13, 2002 9:41 AM
>To: Dean Willis
>Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
>Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to
>do wit message threading)
>
>
>Dean,
>
>There are some things users care about and will pay for, and other things
>they won't.  For connection oriented services, they consider the "air time"
>when they have full cut-through to when they get disconnected to be the
>value.  In connectionless services, they care about data packets getting
>through, not overhead signaling packets.
>
>You seem to be suggesting that the customer pay for the time they spend
>waiting for the signaling to complete the call.  Or, you expect them to pay
>for signaling as well as data-bearing messages.  This is analogous to making
>customers pay for packaging, when all they want is the handful of tablets in
>the little bottle inside the big box.
>
>Near where I live there is an ice-skating rink that charges by the hour.
>Most people won't put up including in that hour the time taken to fill out
>forms and select skates.  Nor would they pay for time where they are
>standing in line for that process.  Not standing in line, getting to the
>rink sooner, and skating a full hour have value.
>
>This is not just the service provider perspective, but the customer
>perspective.
>
>It's OK to get philosophical, just keep it real. :)
>
>Mike
>
>
>At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
>
>
> > Warning: Philosophical Rant Follows
> >
> > The key issue is buried deep in the underlying business
> > model. In the Internet world, you pay the same for the bits
> > used to signal a multimedia session as for the bits used by
> > the multimedia session itself. In the PSTN, the carriers pay
> > for the signaling used to set up the multimedia session. In
> > other words, there is NO signaling, as signaling is used in
> > the PSTN sense, on the Internet -- just application traffic.
> > There might be messaging applications, routing applications,
> > management applications, or multimedia applications, but
> > they're just all applications as far as the underlying
> > network in concerned. In the PSTN, signaling actually
> > traverses a separate, specialized network, driven by its own
> > economic laws.
> >
>
>Reference remaining rant elsewhere.
>
>Here's an example.
>
>-----------
> From last year's Next Steps in Signaling BOF:
>
>6.5 James Kempf
>    Radio access networks - air is expensive.  Optimize by using less
>    bandwidth and more (for example) CPU cycles. Whatever the signaling
>    protocol is, it must be very efficient for mobility. Providers pay
>    big $$ for the airwaves, they don't want  to use it for signaling,
>    but for user data.  Best: do the signaling through the backbone, and
>    not over the air if possible.  The signaling must be efficient for
>    mobility to minimize signaling while moving from area to area.
>    Mobility signalling should be directly coupled to the traffic.
>-------------
>
>See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
>
>Clearly from the provider perspective, user data and signaling are two
>different things. Therein lies the debate. For if a user were to do
>something that "looks like" signaling, they would intrude on the
>territory of the operator.
>
>The problem here: is Messaging the same as signaling? Is Presence the
>same as signaling? Is anything we do with SIP really "signaling" or is
>it user data?
>
>--
>Dean
>
>_______________________________________________
>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 bcampbell@dynamicsoft.com  Wed Mar 13 18:06:24 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12254
	for ; Wed, 13 Mar 2002 18:06:23 -0500 (EST)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2DN5M218984;
	Wed, 13 Mar 2002 17:05:23 -0600 (CST)
From: "Ben Campbell" 
To: "Michael Hammer" 
Cc: "Dean Willis" ,
        "'Dean Willis'" ,
        "'Paul Kyzivat'" ,
        
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was   something to do wit message threading)
Date: Wed, 13 Mar 2002 17:04:06 -0600
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com>
Content-Length: 8453
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: 


> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Wednesday, March 13, 2002 4:42 PM
> To: Ben Campbell
> Cc: Dean Willis; 'Dean Willis'; 'Paul Kyzivat';
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something
> to do wit message threading)
>
>
> Ben,
>
> When you consider RTP over IP, which fits your "IP application"
> definition,
> whether you charge per packet or realize that statistically X
> packets and Y
> minutes is "six of one, half a dozen of the other" then there are some
> models where per minute works out to be the same value.

But this only works for rtp type applications, and I fully expect to run
other IP applications as well. You very quickly fall into the twilight zone
of cross-layer usage counting, where you charge per minute for RTP traffic,
but per byte for others.
>
> How do you reconcile volume charging with the two things that I noticed
> about my two services:  ISP:  Bills me a flat monthly fee for data
> service.  Mobile phone:  Bills me flat monthly fee for phone
> service, with
> per minute charges above an agreed on number of "free" minutes.
> It didn't
> used to be like that.  Seems you are suggesting a trend-reversal or at
> least an exception to the rule.

Yes, it is a trend reversal. Your ISP charges you flat rate because that is
what the market pretty much requires. But, if you have a residential level
of service, they probably also have policies that let them harrass you if,
in their sole opinion, you are using to many bytes in your so-called
unlimited flat rate service--creating a whole new class of double-speak
about limited unlimited service. A per-byte usage, where the per byte cost
for the average user added up to the same as the flat rate price would do
much to rationalize these plans. (And of course, flat rate plans are a bit
of a red-herring in this discussion--if you aren't billing for bytes
_or_minutes_ then who cares if they are user data or signal data?)

As for the mobile phone, they are charging per-minute for holding up
wireless network resources. I am glad to see that the GPRS carriers in the
US are _not_ trying to shoehorn per-minute billing for GPRS data. (Their
per-byte charges are rediculously high, but that is another problem)

>
> The earlier models of charging per data connection minute or per
> minute of
> call did not encourage usage and therefore generate enough revenue.  Per
> byte charges can generate revenue, but only if it doesn't discourage use.
>
> Will the per-byte prices be low enough to encourage use, yet still cover
> the cost of over-provisioning the network to keep setup delay low?  Will
> connection-less IM users pay a premium to make sure that
> connection-oriented RTP-flow users don't experience setup delays?
>  Tell me,
> who pays for excess capacity?  This could be a competitive discriminator.

These are all business model issues that are equally true in flat-rate and
per-minute models. I assert that an IP carrier that can figure out how to
price and market a per-byte service will have a significant competitive
advantage over an IP carrier that tries to perserve a legacy per-minute
model--even if the average revenue per subscriber is identical. This is due
to simpler network accounting and management if for no other reason.

Figuring out how to price and market it such a service is business magic,
not engineering magic.

>
> Mike
>
>
> At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
> >You example only works when you apply a billing model (per
> minute billing)
> >to a medium (IP applications) where it doesn't make sense.
> Indeed, I think
> >the per-minute model is not so much expected by users--it is just the
> >carriers don't know how to bill any other way.
> >
> >If you applied a more IP Centric billing model (charge per
> byte), then you
> >can easily charge for signal and user data the same way. My GPRS service
> >provider charges for GPRS data in exactly this manner--if I run a SIMPLE
> >service across it, they just see bytes. A signal byte and a user byte are
> >indistinguishable.
> >
> >My personal nightmare is hearing that carriers want to charge X per byte,
> >except for bytes that were in SIP messages.
> >
> >
> >-----Original Message-----
> >From: simple-admin@mailman.dynamicsoft.com
> >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer
> >Sent: Wednesday, March 13, 2002 9:41 AM
> >To: Dean Willis
> >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
> >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was
> something to
> >do wit message threading)
> >
> >
> >Dean,
> >
> >There are some things users care about and will pay for, and other things
> >they won't.  For connection oriented services, they consider the
> "air time"
> >when they have full cut-through to when they get disconnected to be the
> >value.  In connectionless services, they care about data packets getting
> >through, not overhead signaling packets.
> >
> >You seem to be suggesting that the customer pay for the time they spend
> >waiting for the signaling to complete the call.  Or, you expect
> them to pay
> >for signaling as well as data-bearing messages.  This is
> analogous to making
> >customers pay for packaging, when all they want is the handful
> of tablets in
> >the little bottle inside the big box.
> >
> >Near where I live there is an ice-skating rink that charges by the hour.
> >Most people won't put up including in that hour the time taken
> to fill out
> >forms and select skates.  Nor would they pay for time where they are
> >standing in line for that process.  Not standing in line, getting to the
> >rink sooner, and skating a full hour have value.
> >
> >This is not just the service provider perspective, but the customer
> >perspective.
> >
> >It's OK to get philosophical, just keep it real. :)
> >
> >Mike
> >
> >
> >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
> >
> >
> > > Warning: Philosophical Rant Follows
> > >
> > > The key issue is buried deep in the underlying business
> > > model. In the Internet world, you pay the same for the bits
> > > used to signal a multimedia session as for the bits used by
> > > the multimedia session itself. In the PSTN, the carriers pay
> > > for the signaling used to set up the multimedia session. In
> > > other words, there is NO signaling, as signaling is used in
> > > the PSTN sense, on the Internet -- just application traffic.
> > > There might be messaging applications, routing applications,
> > > management applications, or multimedia applications, but
> > > they're just all applications as far as the underlying
> > > network in concerned. In the PSTN, signaling actually
> > > traverses a separate, specialized network, driven by its own
> > > economic laws.
> > >
> >
> >Reference remaining rant elsewhere.
> >
> >Here's an example.
> >
> >-----------
> > From last year's Next Steps in Signaling BOF:
> >
> >6.5 James Kempf
> >    Radio access networks - air is expensive.  Optimize by using less
> >    bandwidth and more (for example) CPU cycles. Whatever the signaling
> >    protocol is, it must be very efficient for mobility. Providers pay
> >    big $$ for the airwaves, they don't want  to use it for signaling,
> >    but for user data.  Best: do the signaling through the backbone, and
> >    not over the air if possible.  The signaling must be efficient for
> >    mobility to minimize signaling while moving from area to area.
> >    Mobility signalling should be directly coupled to the traffic.
> >-------------
> >
> >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> >
> >Clearly from the provider perspective, user data and signaling are two
> >different things. Therein lies the debate. For if a user were to do
> >something that "looks like" signaling, they would intrude on the
> >territory of the operator.
> >
> >The problem here: is Messaging the same as signaling? Is Presence the
> >same as signaling? Is anything we do with SIP really "signaling" or is
> >it user data?
> >
> >--
> >Dean
> >
> >_______________________________________________
> >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 pkyzivat@cisco.com  Wed Mar 13 18:10:28 2002
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 SAA12311
	for ; Wed, 13 Mar 2002 18:10:28 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DN9uJ04667;
	Wed, 13 Mar 2002 18:09:56 -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 AAG72673;
	Wed, 13 Mar 2002 18:12:49 -0500 (EST)
Message-ID: <3C8FDC2F.939FBDE2@cisco.com>
Date: Wed, 13 Mar 2002 18:09:35 -0500
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: Michael Hammer 
CC: Ben Campbell ,
        Dean Willis ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do 
 wit message threading)
References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 7772
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: 

While it is nice to get something for nothing, in the long term somebody has to pay for the infrastructure that provides the bandwidth. Personally, I would not mind paying
for usage based on a fair metric. Charging per byte makes sense, while charging for elapsed time does not. Charging for guaranteed bandwidth over some time period might
make sense, but more likely it would make sense to charge more per byte for higher priority bytes.

What would be really unfair would be to use the same channel, with the same bandwidth guarantees and charge one price for IM bytes and a different price for voice bytes.

If you are charging by the byte, people have an incentive to balance better quality against the cost of the extra bytes needed to deliver that quality.

Charged by the byte, IM won't be free, but may seem to be because it uses vastly fewer bytes than even a short voice message, and can get by with with lower priority
service as well.

As long as signalling bytes used for call setup travel the same network as the voice bytes, and are billed at the same rate, it is unlikely that callers would notice much
effect on their bills because the quantities are so much smaller than for voice content. The most noticable factor might be due to roundoff - an unsuccessful call might be
charged at $0.01 rather than being free. 

The excess capacity required to provide good service can hopefully be recovered in the surcharge for priority service.

	Paul

Michael Hammer wrote:
> 
> Ben,
> 
> When you consider RTP over IP, which fits your "IP application" definition,
> whether you charge per packet or realize that statistically X packets and Y
> minutes is "six of one, half a dozen of the other" then there are some
> models where per minute works out to be the same value.
> 
> How do you reconcile volume charging with the two things that I noticed
> about my two services:  ISP:  Bills me a flat monthly fee for data
> service.  Mobile phone:  Bills me flat monthly fee for phone service, with
> per minute charges above an agreed on number of "free" minutes.  It didn't
> used to be like that.  Seems you are suggesting a trend-reversal or at
> least an exception to the rule.
> 
> The earlier models of charging per data connection minute or per minute of
> call did not encourage usage and therefore generate enough revenue.  Per
> byte charges can generate revenue, but only if it doesn't discourage use.
> 
> Will the per-byte prices be low enough to encourage use, yet still cover
> the cost of over-provisioning the network to keep setup delay low?  Will
> connection-less IM users pay a premium to make sure that
> connection-oriented RTP-flow users don't experience setup delays?  Tell me,
> who pays for excess capacity?  This could be a competitive discriminator.
> 
> Mike
> 
> At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
> >You example only works when you apply a billing model (per minute billing)
> >to a medium (IP applications) where it doesn't make sense. Indeed, I think
> >the per-minute model is not so much expected by users--it is just the
> >carriers don't know how to bill any other way.
> >
> >If you applied a more IP Centric billing model (charge per byte), then you
> >can easily charge for signal and user data the same way. My GPRS service
> >provider charges for GPRS data in exactly this manner--if I run a SIMPLE
> >service across it, they just see bytes. A signal byte and a user byte are
> >indistinguishable.
> >
> >My personal nightmare is hearing that carriers want to charge X per byte,
> >except for bytes that were in SIP messages.
> >
> >
> >-----Original Message-----
> >From: simple-admin@mailman.dynamicsoft.com
> >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer
> >Sent: Wednesday, March 13, 2002 9:41 AM
> >To: Dean Willis
> >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
> >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to
> >do wit message threading)
> >
> >
> >Dean,
> >
> >There are some things users care about and will pay for, and other things
> >they won't.  For connection oriented services, they consider the "air time"
> >when they have full cut-through to when they get disconnected to be the
> >value.  In connectionless services, they care about data packets getting
> >through, not overhead signaling packets.
> >
> >You seem to be suggesting that the customer pay for the time they spend
> >waiting for the signaling to complete the call.  Or, you expect them to pay
> >for signaling as well as data-bearing messages.  This is analogous to making
> >customers pay for packaging, when all they want is the handful of tablets in
> >the little bottle inside the big box.
> >
> >Near where I live there is an ice-skating rink that charges by the hour.
> >Most people won't put up including in that hour the time taken to fill out
> >forms and select skates.  Nor would they pay for time where they are
> >standing in line for that process.  Not standing in line, getting to the
> >rink sooner, and skating a full hour have value.
> >
> >This is not just the service provider perspective, but the customer
> >perspective.
> >
> >It's OK to get philosophical, just keep it real. :)
> >
> >Mike
> >
> >
> >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
> >
> >
> > > Warning: Philosophical Rant Follows
> > >
> > > The key issue is buried deep in the underlying business
> > > model. In the Internet world, you pay the same for the bits
> > > used to signal a multimedia session as for the bits used by
> > > the multimedia session itself. In the PSTN, the carriers pay
> > > for the signaling used to set up the multimedia session. In
> > > other words, there is NO signaling, as signaling is used in
> > > the PSTN sense, on the Internet -- just application traffic.
> > > There might be messaging applications, routing applications,
> > > management applications, or multimedia applications, but
> > > they're just all applications as far as the underlying
> > > network in concerned. In the PSTN, signaling actually
> > > traverses a separate, specialized network, driven by its own
> > > economic laws.
> > >
> >
> >Reference remaining rant elsewhere.
> >
> >Here's an example.
> >
> >-----------
> > From last year's Next Steps in Signaling BOF:
> >
> >6.5 James Kempf
> >    Radio access networks - air is expensive.  Optimize by using less
> >    bandwidth and more (for example) CPU cycles. Whatever the signaling
> >    protocol is, it must be very efficient for mobility. Providers pay
> >    big $$ for the airwaves, they don't want  to use it for signaling,
> >    but for user data.  Best: do the signaling through the backbone, and
> >    not over the air if possible.  The signaling must be efficient for
> >    mobility to minimize signaling while moving from area to area.
> >    Mobility signalling should be directly coupled to the traffic.
> >-------------
> >
> >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> >
> >Clearly from the provider perspective, user data and signaling are two
> >different things. Therein lies the debate. For if a user were to do
> >something that "looks like" signaling, they would intrude on the
> >territory of the operator.
> >
> >The problem here: is Messaging the same as signaling? Is Presence the
> >same as signaling? Is anything we do with SIP really "signaling" or is
> >it user data?
> >
> >--
> >Dean
> >
> >_______________________________________________
> >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 pkyzivat@cisco.com  Wed Mar 13 18:21:20 2002
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 SAA12393
	for ; Wed, 13 Mar 2002 18:21:20 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DNKmZ05538;
	Wed, 13 Mar 2002 18:20:49 -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 AAG72735;
	Wed, 13 Mar 2002 18:23:42 -0500 (EST)
Message-ID: <3C8FDEBC.884C4FE7@cisco.com>
Date: Wed, 13 Mar 2002 18:20:28 -0500
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: Ben Campbell 
CC: Michael Hammer ,
        Dean Willis ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was   something to do 
 wit message threading)
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1353
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: 

Ben Campbell wrote:
> 
> These are all business model issues that are equally true in flat-rate and
> per-minute models. I assert that an IP carrier that can figure out how to
> price and market a per-byte service will have a significant competitive
> advantage over an IP carrier that tries to perserve a legacy per-minute
> model--even if the average revenue per subscriber is identical. This is due
> to simpler network accounting and management if for no other reason.
> 
> Figuring out how to price and market it such a service is business magic,
> not engineering magic.

To me the attractiveness of this model is that it is a fairer model - more consistent with resources consumed.

The trick is that this has to be perceived as fair by the people purchasing the service. I can be comfortable with per-byte billing once I figure out how much a typical
phone call will cost me. But my mother will probably never perceive per-byte billing as fair because she will never understand what it means.

I can imagine two pricing models coexisting. Some people might simply have per-byte network access charges, and be free to run voice, data, whatever over them using
equipment of their choice. Others might contract for by-the-minute or flat-rate phone service, with the service provider providing the network access and the devices that
use it.

	Paul

From mhammer@cisco.com  Wed Mar 13 19:04:57 2002
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 TAA12551
	for ; Wed, 13 Mar 2002 19:04:57 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2E04PY08322;
	Wed, 13 Mar 2002 19:04:25 -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 AAR77666;
	Wed, 13 Mar 2002 18:58:57 -0500 (EST)
Message-Id: <4.3.2.7.2.20020313190133.03dc97b8@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 13 Mar 2002 19:04:02 -0500
To: Paul Kyzivat 
From: Michael Hammer 
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was
  something to do  wit message threading)
Cc: Ben Campbell ,
        Dean Willis ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3C8FDC2F.939FBDE2@cisco.com>
References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
 <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 8360
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: 

Paul,

As long as signaling gets priority over IM and doing session setup doesn't 
turn into a world wide wait, I can go along with running the packets over 
the same infrastructure.

Mike


At 06:09 PM 3/13/2002 -0500, Paul Kyzivat wrote:
>While it is nice to get something for nothing, in the long term somebody 
>has to pay for the infrastructure that provides the bandwidth. Personally, 
>I would not mind paying
>for usage based on a fair metric. Charging per byte makes sense, while 
>charging for elapsed time does not. Charging for guaranteed bandwidth over 
>some time period might
>make sense, but more likely it would make sense to charge more per byte 
>for higher priority bytes.
>
>What would be really unfair would be to use the same channel, with the 
>same bandwidth guarantees and charge one price for IM bytes and a 
>different price for voice bytes.
>
>If you are charging by the byte, people have an incentive to balance 
>better quality against the cost of the extra bytes needed to deliver that 
>quality.
>
>Charged by the byte, IM won't be free, but may seem to be because it uses 
>vastly fewer bytes than even a short voice message, and can get by with 
>with lower priority
>service as well.
>
>As long as signalling bytes used for call setup travel the same network as 
>the voice bytes, and are billed at the same rate, it is unlikely that 
>callers would notice much
>effect on their bills because the quantities are so much smaller than for 
>voice content. The most noticable factor might be due to roundoff - an 
>unsuccessful call might be
>charged at $0.01 rather than being free.
>
>The excess capacity required to provide good service can hopefully be 
>recovered in the surcharge for priority service.
>
>         Paul
>
>Michael Hammer wrote:
> >
> > Ben,
> >
> > When you consider RTP over IP, which fits your "IP application" definition,
> > whether you charge per packet or realize that statistically X packets and Y
> > minutes is "six of one, half a dozen of the other" then there are some
> > models where per minute works out to be the same value.
> >
> > How do you reconcile volume charging with the two things that I noticed
> > about my two services:  ISP:  Bills me a flat monthly fee for data
> > service.  Mobile phone:  Bills me flat monthly fee for phone service, with
> > per minute charges above an agreed on number of "free" minutes.  It didn't
> > used to be like that.  Seems you are suggesting a trend-reversal or at
> > least an exception to the rule.
> >
> > The earlier models of charging per data connection minute or per minute of
> > call did not encourage usage and therefore generate enough revenue.  Per
> > byte charges can generate revenue, but only if it doesn't discourage use.
> >
> > Will the per-byte prices be low enough to encourage use, yet still cover
> > the cost of over-provisioning the network to keep setup delay low?  Will
> > connection-less IM users pay a premium to make sure that
> > connection-oriented RTP-flow users don't experience setup delays?  Tell me,
> > who pays for excess capacity?  This could be a competitive discriminator.
> >
> > Mike
> >
> > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
> > >You example only works when you apply a billing model (per minute billing)
> > >to a medium (IP applications) where it doesn't make sense. Indeed, I think
> > >the per-minute model is not so much expected by users--it is just the
> > >carriers don't know how to bill any other way.
> > >
> > >If you applied a more IP Centric billing model (charge per byte), then you
> > >can easily charge for signal and user data the same way. My GPRS service
> > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE
> > >service across it, they just see bytes. A signal byte and a user byte are
> > >indistinguishable.
> > >
> > >My personal nightmare is hearing that carriers want to charge X per byte,
> > >except for bytes that were in SIP messages.
> > >
> > >
> > >-----Original Message-----
> > >From: simple-admin@mailman.dynamicsoft.com
> > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer
> > >Sent: Wednesday, March 13, 2002 9:41 AM
> > >To: Dean Willis
> > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
> > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was 
> something to
> > >do wit message threading)
> > >
> > >
> > >Dean,
> > >
> > >There are some things users care about and will pay for, and other things
> > >they won't.  For connection oriented services, they consider the "air 
> time"
> > >when they have full cut-through to when they get disconnected to be the
> > >value.  In connectionless services, they care about data packets getting
> > >through, not overhead signaling packets.
> > >
> > >You seem to be suggesting that the customer pay for the time they spend
> > >waiting for the signaling to complete the call.  Or, you expect them 
> to pay
> > >for signaling as well as data-bearing messages.  This is analogous to 
> making
> > >customers pay for packaging, when all they want is the handful of 
> tablets in
> > >the little bottle inside the big box.
> > >
> > >Near where I live there is an ice-skating rink that charges by the hour.
> > >Most people won't put up including in that hour the time taken to fill out
> > >forms and select skates.  Nor would they pay for time where they are
> > >standing in line for that process.  Not standing in line, getting to the
> > >rink sooner, and skating a full hour have value.
> > >
> > >This is not just the service provider perspective, but the customer
> > >perspective.
> > >
> > >It's OK to get philosophical, just keep it real. :)
> > >
> > >Mike
> > >
> > >
> > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
> > >
> > >
> > > > Warning: Philosophical Rant Follows
> > > >
> > > > The key issue is buried deep in the underlying business
> > > > model. In the Internet world, you pay the same for the bits
> > > > used to signal a multimedia session as for the bits used by
> > > > the multimedia session itself. In the PSTN, the carriers pay
> > > > for the signaling used to set up the multimedia session. In
> > > > other words, there is NO signaling, as signaling is used in
> > > > the PSTN sense, on the Internet -- just application traffic.
> > > > There might be messaging applications, routing applications,
> > > > management applications, or multimedia applications, but
> > > > they're just all applications as far as the underlying
> > > > network in concerned. In the PSTN, signaling actually
> > > > traverses a separate, specialized network, driven by its own
> > > > economic laws.
> > > >
> > >
> > >Reference remaining rant elsewhere.
> > >
> > >Here's an example.
> > >
> > >-----------
> > > From last year's Next Steps in Signaling BOF:
> > >
> > >6.5 James Kempf
> > >    Radio access networks - air is expensive.  Optimize by using less
> > >    bandwidth and more (for example) CPU cycles. Whatever the signaling
> > >    protocol is, it must be very efficient for mobility. Providers pay
> > >    big $$ for the airwaves, they don't want  to use it for signaling,
> > >    but for user data.  Best: do the signaling through the backbone, and
> > >    not over the air if possible.  The signaling must be efficient for
> > >    mobility to minimize signaling while moving from area to area.
> > >    Mobility signalling should be directly coupled to the traffic.
> > >-------------
> > >
> > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> > >
> > >Clearly from the provider perspective, user data and signaling are two
> > >different things. Therein lies the debate. For if a user were to do
> > >something that "looks like" signaling, they would intrude on the
> > >territory of the operator.
> > >
> > >The problem here: is Messaging the same as signaling? Is Presence the
> > >same as signaling? Is anything we do with SIP really "signaling" or is
> > >it user data?
> > >
> > >--
> > >Dean
> > >
> > >_______________________________________________
> > >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 hgs@cs.columbia.edu  Wed Mar 13 19:16:46 2002
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 TAA12614
	for ; Wed, 13 Mar 2002 19:16:46 -0500 (EST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA20976;
	Wed, 13 Mar 2002 19:15:51 -0500 (EST)
Received: from cs.columbia.edu (dyn-wireless-244-121.dyn.columbia.edu [160.39.244.121])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2E0FoNB007135
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Wed, 13 Mar 2002 19:15:50 -0500 (EST)
Message-ID: <3C8FEBA1.8054E72B@cs.columbia.edu>
Date: Wed, 13 Mar 2002 19:15:29 -0500
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Michael Hammer ,
        Ben Campbell ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was something to do 
 wit message threading)
References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com> <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> <3C8FDC2F.939FBDE2@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 8709
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: 

Talking about charging: cost-per-byte has very little relationship to
real costs. After all, the incremental cost of sending a byte in a
network that is not fully loaded is very close to zero, wireless or
otherwise, since almost all the costs are fixed costs. From a provider
perspective, you want to charge according to willingness to pay, not
cost. There is a reason airlines don't charge per hour flight time or
per mile flown.


Paul Kyzivat wrote:
> 
> While it is nice to get something for nothing, in the long term somebody has to pay for the infrastructure that provides the bandwidth. Personally, I would not mind paying
> for usage based on a fair metric. Charging per byte makes sense, while charging for elapsed time does not. Charging for guaranteed bandwidth over some time period might
> make sense, but more likely it would make sense to charge more per byte for higher priority bytes.
> 
> What would be really unfair would be to use the same channel, with the same bandwidth guarantees and charge one price for IM bytes and a different price for voice bytes.
> 
> If you are charging by the byte, people have an incentive to balance better quality against the cost of the extra bytes needed to deliver that quality.
> 
> Charged by the byte, IM won't be free, but may seem to be because it uses vastly fewer bytes than even a short voice message, and can get by with with lower priority
> service as well.
> 
> As long as signalling bytes used for call setup travel the same network as the voice bytes, and are billed at the same rate, it is unlikely that callers would notice much
> effect on their bills because the quantities are so much smaller than for voice content. The most noticable factor might be due to roundoff - an unsuccessful call might be
> charged at $0.01 rather than being free.
> 
> The excess capacity required to provide good service can hopefully be recovered in the surcharge for priority service.
> 
>         Paul
> 
> Michael Hammer wrote:
> >
> > Ben,
> >
> > When you consider RTP over IP, which fits your "IP application" definition,
> > whether you charge per packet or realize that statistically X packets and Y
> > minutes is "six of one, half a dozen of the other" then there are some
> > models where per minute works out to be the same value.
> >
> > How do you reconcile volume charging with the two things that I noticed
> > about my two services:  ISP:  Bills me a flat monthly fee for data
> > service.  Mobile phone:  Bills me flat monthly fee for phone service, with
> > per minute charges above an agreed on number of "free" minutes.  It didn't
> > used to be like that.  Seems you are suggesting a trend-reversal or at
> > least an exception to the rule.
> >
> > The earlier models of charging per data connection minute or per minute of
> > call did not encourage usage and therefore generate enough revenue.  Per
> > byte charges can generate revenue, but only if it doesn't discourage use.
> >
> > Will the per-byte prices be low enough to encourage use, yet still cover
> > the cost of over-provisioning the network to keep setup delay low?  Will
> > connection-less IM users pay a premium to make sure that
> > connection-oriented RTP-flow users don't experience setup delays?  Tell me,
> > who pays for excess capacity?  This could be a competitive discriminator.
> >
> > Mike
> >
> > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
> > >You example only works when you apply a billing model (per minute billing)
> > >to a medium (IP applications) where it doesn't make sense. Indeed, I think
> > >the per-minute model is not so much expected by users--it is just the
> > >carriers don't know how to bill any other way.
> > >
> > >If you applied a more IP Centric billing model (charge per byte), then you
> > >can easily charge for signal and user data the same way. My GPRS service
> > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE
> > >service across it, they just see bytes. A signal byte and a user byte are
> > >indistinguishable.
> > >
> > >My personal nightmare is hearing that carriers want to charge X per byte,
> > >except for bytes that were in SIP messages.
> > >
> > >
> > >-----Original Message-----
> > >From: simple-admin@mailman.dynamicsoft.com
> > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer
> > >Sent: Wednesday, March 13, 2002 9:41 AM
> > >To: Dean Willis
> > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
> > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to
> > >do wit message threading)
> > >
> > >
> > >Dean,
> > >
> > >There are some things users care about and will pay for, and other things
> > >they won't.  For connection oriented services, they consider the "air time"
> > >when they have full cut-through to when they get disconnected to be the
> > >value.  In connectionless services, they care about data packets getting
> > >through, not overhead signaling packets.
> > >
> > >You seem to be suggesting that the customer pay for the time they spend
> > >waiting for the signaling to complete the call.  Or, you expect them to pay
> > >for signaling as well as data-bearing messages.  This is analogous to making
> > >customers pay for packaging, when all they want is the handful of tablets in
> > >the little bottle inside the big box.
> > >
> > >Near where I live there is an ice-skating rink that charges by the hour.
> > >Most people won't put up including in that hour the time taken to fill out
> > >forms and select skates.  Nor would they pay for time where they are
> > >standing in line for that process.  Not standing in line, getting to the
> > >rink sooner, and skating a full hour have value.
> > >
> > >This is not just the service provider perspective, but the customer
> > >perspective.
> > >
> > >It's OK to get philosophical, just keep it real. :)
> > >
> > >Mike
> > >
> > >
> > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
> > >
> > >
> > > > Warning: Philosophical Rant Follows
> > > >
> > > > The key issue is buried deep in the underlying business
> > > > model. In the Internet world, you pay the same for the bits
> > > > used to signal a multimedia session as for the bits used by
> > > > the multimedia session itself. In the PSTN, the carriers pay
> > > > for the signaling used to set up the multimedia session. In
> > > > other words, there is NO signaling, as signaling is used in
> > > > the PSTN sense, on the Internet -- just application traffic.
> > > > There might be messaging applications, routing applications,
> > > > management applications, or multimedia applications, but
> > > > they're just all applications as far as the underlying
> > > > network in concerned. In the PSTN, signaling actually
> > > > traverses a separate, specialized network, driven by its own
> > > > economic laws.
> > > >
> > >
> > >Reference remaining rant elsewhere.
> > >
> > >Here's an example.
> > >
> > >-----------
> > > From last year's Next Steps in Signaling BOF:
> > >
> > >6.5 James Kempf
> > >    Radio access networks - air is expensive.  Optimize by using less
> > >    bandwidth and more (for example) CPU cycles. Whatever the signaling
> > >    protocol is, it must be very efficient for mobility. Providers pay
> > >    big $$ for the airwaves, they don't want  to use it for signaling,
> > >    but for user data.  Best: do the signaling through the backbone, and
> > >    not over the air if possible.  The signaling must be efficient for
> > >    mobility to minimize signaling while moving from area to area.
> > >    Mobility signalling should be directly coupled to the traffic.
> > >-------------
> > >
> > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> > >
> > >Clearly from the provider perspective, user data and signaling are two
> > >different things. Therein lies the debate. For if a user were to do
> > >something that "looks like" signaling, they would intrude on the
> > >territory of the operator.
> > >
> > >The problem here: is Messaging the same as signaling? Is Presence the
> > >same as signaling? Is anything we do with SIP really "signaling" or is
> > >it user data?
> > >
> > >--
> > >Dean
> > >
> > >_______________________________________________
> > >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 sardana@obsoft.com  Thu Mar 14 00:46:00 2002
Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA13703
	for ; Thu, 14 Mar 2002 00:45:59 -0500 (EST)
Received: from obsoft.com (localhost.localdomain [127.0.0.1])
	by obsoft.com (8.11.6/8.11.6) with ESMTP id g2E5o3t22067;
	Wed, 13 Mar 2002 21:50:04 -0800
Message-ID: <3C903A0B.A7701E0A@obsoft.com>
Date: Wed, 13 Mar 2002 21:50:03 -0800
From: Bobby Sardana 
Organization: ObjectSoftware, Inc
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Hammer 
CC: Paul Kyzivat ,
        Ben Campbell ,
        Dean Willis ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomething to do  
 wit message threading)
References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
	 <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com> <4.3.2.7.2.20020313190133.03dc97b8@cia.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 9154
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: 

So does this imply that every SIP message that transpires the network will need
introspection to check if it has an embedded mime type? I am sure this will be an
issue with regards to signalling performance.

regards,

Bobby Sardana.
sardana@obsoft.com

Michael Hammer wrote:

> Paul,
>
> As long as signaling gets priority over IM and doing session setup doesn't
> turn into a world wide wait, I can go along with running the packets over
> the same infrastructure.
>
> Mike
>
> At 06:09 PM 3/13/2002 -0500, Paul Kyzivat wrote:
> >While it is nice to get something for nothing, in the long term somebody
> >has to pay for the infrastructure that provides the bandwidth. Personally,
> >I would not mind paying
> >for usage based on a fair metric. Charging per byte makes sense, while
> >charging for elapsed time does not. Charging for guaranteed bandwidth over
> >some time period might
> >make sense, but more likely it would make sense to charge more per byte
> >for higher priority bytes.
> >
> >What would be really unfair would be to use the same channel, with the
> >same bandwidth guarantees and charge one price for IM bytes and a
> >different price for voice bytes.
> >
> >If you are charging by the byte, people have an incentive to balance
> >better quality against the cost of the extra bytes needed to deliver that
> >quality.
> >
> >Charged by the byte, IM won't be free, but may seem to be because it uses
> >vastly fewer bytes than even a short voice message, and can get by with
> >with lower priority
> >service as well.
> >
> >As long as signalling bytes used for call setup travel the same network as
> >the voice bytes, and are billed at the same rate, it is unlikely that
> >callers would notice much
> >effect on their bills because the quantities are so much smaller than for
> >voice content. The most noticable factor might be due to roundoff - an
> >unsuccessful call might be
> >charged at $0.01 rather than being free.
> >
> >The excess capacity required to provide good service can hopefully be
> >recovered in the surcharge for priority service.
> >
> >         Paul
> >
> >Michael Hammer wrote:
> > >
> > > Ben,
> > >
> > > When you consider RTP over IP, which fits your "IP application" definition,
> > > whether you charge per packet or realize that statistically X packets and Y
> > > minutes is "six of one, half a dozen of the other" then there are some
> > > models where per minute works out to be the same value.
> > >
> > > How do you reconcile volume charging with the two things that I noticed
> > > about my two services:  ISP:  Bills me a flat monthly fee for data
> > > service.  Mobile phone:  Bills me flat monthly fee for phone service, with
> > > per minute charges above an agreed on number of "free" minutes.  It didn't
> > > used to be like that.  Seems you are suggesting a trend-reversal or at
> > > least an exception to the rule.
> > >
> > > The earlier models of charging per data connection minute or per minute of
> > > call did not encourage usage and therefore generate enough revenue.  Per
> > > byte charges can generate revenue, but only if it doesn't discourage use.
> > >
> > > Will the per-byte prices be low enough to encourage use, yet still cover
> > > the cost of over-provisioning the network to keep setup delay low?  Will
> > > connection-less IM users pay a premium to make sure that
> > > connection-oriented RTP-flow users don't experience setup delays?  Tell me,
> > > who pays for excess capacity?  This could be a competitive discriminator.
> > >
> > > Mike
> > >
> > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
> > > >You example only works when you apply a billing model (per minute billing)
> > > >to a medium (IP applications) where it doesn't make sense. Indeed, I think
> > > >the per-minute model is not so much expected by users--it is just the
> > > >carriers don't know how to bill any other way.
> > > >
> > > >If you applied a more IP Centric billing model (charge per byte), then you
> > > >can easily charge for signal and user data the same way. My GPRS service
> > > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE
> > > >service across it, they just see bytes. A signal byte and a user byte are
> > > >indistinguishable.
> > > >
> > > >My personal nightmare is hearing that carriers want to charge X per byte,
> > > >except for bytes that were in SIP messages.
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: simple-admin@mailman.dynamicsoft.com
> > > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer
> > > >Sent: Wednesday, March 13, 2002 9:41 AM
> > > >To: Dean Willis
> > > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
> > > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was
> > something to
> > > >do wit message threading)
> > > >
> > > >
> > > >Dean,
> > > >
> > > >There are some things users care about and will pay for, and other things
> > > >they won't.  For connection oriented services, they consider the "air
> > time"
> > > >when they have full cut-through to when they get disconnected to be the
> > > >value.  In connectionless services, they care about data packets getting
> > > >through, not overhead signaling packets.
> > > >
> > > >You seem to be suggesting that the customer pay for the time they spend
> > > >waiting for the signaling to complete the call.  Or, you expect them
> > to pay
> > > >for signaling as well as data-bearing messages.  This is analogous to
> > making
> > > >customers pay for packaging, when all they want is the handful of
> > tablets in
> > > >the little bottle inside the big box.
> > > >
> > > >Near where I live there is an ice-skating rink that charges by the hour.
> > > >Most people won't put up including in that hour the time taken to fill out
> > > >forms and select skates.  Nor would they pay for time where they are
> > > >standing in line for that process.  Not standing in line, getting to the
> > > >rink sooner, and skating a full hour have value.
> > > >
> > > >This is not just the service provider perspective, but the customer
> > > >perspective.
> > > >
> > > >It's OK to get philosophical, just keep it real. :)
> > > >
> > > >Mike
> > > >
> > > >
> > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
> > > >
> > > >
> > > > > Warning: Philosophical Rant Follows
> > > > >
> > > > > The key issue is buried deep in the underlying business
> > > > > model. In the Internet world, you pay the same for the bits
> > > > > used to signal a multimedia session as for the bits used by
> > > > > the multimedia session itself. In the PSTN, the carriers pay
> > > > > for the signaling used to set up the multimedia session. In
> > > > > other words, there is NO signaling, as signaling is used in
> > > > > the PSTN sense, on the Internet -- just application traffic.
> > > > > There might be messaging applications, routing applications,
> > > > > management applications, or multimedia applications, but
> > > > > they're just all applications as far as the underlying
> > > > > network in concerned. In the PSTN, signaling actually
> > > > > traverses a separate, specialized network, driven by its own
> > > > > economic laws.
> > > > >
> > > >
> > > >Reference remaining rant elsewhere.
> > > >
> > > >Here's an example.
> > > >
> > > >-----------
> > > > From last year's Next Steps in Signaling BOF:
> > > >
> > > >6.5 James Kempf
> > > >    Radio access networks - air is expensive.  Optimize by using less
> > > >    bandwidth and more (for example) CPU cycles. Whatever the signaling
> > > >    protocol is, it must be very efficient for mobility. Providers pay
> > > >    big $$ for the airwaves, they don't want  to use it for signaling,
> > > >    but for user data.  Best: do the signaling through the backbone, and
> > > >    not over the air if possible.  The signaling must be efficient for
> > > >    mobility to minimize signaling while moving from area to area.
> > > >    Mobility signalling should be directly coupled to the traffic.
> > > >-------------
> > > >
> > > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> > > >
> > > >Clearly from the provider perspective, user data and signaling are two
> > > >different things. Therein lies the debate. For if a user were to do
> > > >something that "looks like" signaling, they would intrude on the
> > > >territory of the operator.
> > > >
> > > >The problem here: is Messaging the same as signaling? Is Presence the
> > > >same as signaling? Is anything we do with SIP really "signaling" or is
> > > >it user data?
> > > >
> > > >--
> > > >Dean
> > > >
> > > >_______________________________________________
> > > >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 mhammer@cisco.com  Thu Mar 14 10:04:11 2002
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 KAA15405
	for ; Thu, 14 Mar 2002 10:04:11 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2EF3ek27197;
	Thu, 14 Mar 2002 10:03:40 -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 AAR81315;
	Thu, 14 Mar 2002 09:58:13 -0500 (EST)
Message-Id: <4.3.2.7.2.20020314100137.047802a0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 14 Mar 2002 10:03:18 -0500
To: Henning Schulzrinne 
From: Michael Hammer 
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Was
  something to do  wit message threading)
Cc: Paul Kyzivat ,
        Ben Campbell ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3C8FEBA1.8054E72B@cs.columbia.edu>
References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
 <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com>
 <3C8FDC2F.939FBDE2@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 9471
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: 

Henning,

Yes, but someone has to pay the debt schedule.  Over what period are you 
amortizing the fixed cost of the network?  15 years like telephone 
switches?  The balance sheet still has to make sense, even if the revenue 
and costs are not directly coupled.

Mike


At 07:15 PM 3/13/2002 -0500, Henning Schulzrinne wrote:
>Talking about charging: cost-per-byte has very little relationship to
>real costs. After all, the incremental cost of sending a byte in a
>network that is not fully loaded is very close to zero, wireless or
>otherwise, since almost all the costs are fixed costs. From a provider
>perspective, you want to charge according to willingness to pay, not
>cost. There is a reason airlines don't charge per hour flight time or
>per mile flown.
>
>
>Paul Kyzivat wrote:
> >
> > While it is nice to get something for nothing, in the long term 
> somebody has to pay for the infrastructure that provides the bandwidth. 
> Personally, I would not mind paying
> > for usage based on a fair metric. Charging per byte makes sense, while 
> charging for elapsed time does not. Charging for guaranteed bandwidth 
> over some time period might
> > make sense, but more likely it would make sense to charge more per byte 
> for higher priority bytes.
> >
> > What would be really unfair would be to use the same channel, with the 
> same bandwidth guarantees and charge one price for IM bytes and a 
> different price for voice bytes.
> >
> > If you are charging by the byte, people have an incentive to balance 
> better quality against the cost of the extra bytes needed to deliver that 
> quality.
> >
> > Charged by the byte, IM won't be free, but may seem to be because it 
> uses vastly fewer bytes than even a short voice message, and can get by 
> with with lower priority
> > service as well.
> >
> > As long as signalling bytes used for call setup travel the same network 
> as the voice bytes, and are billed at the same rate, it is unlikely that 
> callers would notice much
> > effect on their bills because the quantities are so much smaller than 
> for voice content. The most noticable factor might be due to roundoff - 
> an unsuccessful call might be
> > charged at $0.01 rather than being free.
> >
> > The excess capacity required to provide good service can hopefully be 
> recovered in the surcharge for priority service.
> >
> >         Paul
> >
> > Michael Hammer wrote:
> > >
> > > Ben,
> > >
> > > When you consider RTP over IP, which fits your "IP application" 
> definition,
> > > whether you charge per packet or realize that statistically X packets 
> and Y
> > > minutes is "six of one, half a dozen of the other" then there are some
> > > models where per minute works out to be the same value.
> > >
> > > How do you reconcile volume charging with the two things that I noticed
> > > about my two services:  ISP:  Bills me a flat monthly fee for data
> > > service.  Mobile phone:  Bills me flat monthly fee for phone service, 
> with
> > > per minute charges above an agreed on number of "free" minutes.  It 
> didn't
> > > used to be like that.  Seems you are suggesting a trend-reversal or at
> > > least an exception to the rule.
> > >
> > > The earlier models of charging per data connection minute or per 
> minute of
> > > call did not encourage usage and therefore generate enough revenue.  Per
> > > byte charges can generate revenue, but only if it doesn't discourage use.
> > >
> > > Will the per-byte prices be low enough to encourage use, yet still cover
> > > the cost of over-provisioning the network to keep setup delay low?  Will
> > > connection-less IM users pay a premium to make sure that
> > > connection-oriented RTP-flow users don't experience setup 
> delays?  Tell me,
> > > who pays for excess capacity?  This could be a competitive discriminator.
> > >
> > > Mike
> > >
> > > At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
> > > >You example only works when you apply a billing model (per minute 
> billing)
> > > >to a medium (IP applications) where it doesn't make sense. Indeed, I 
> think
> > > >the per-minute model is not so much expected by users--it is just the
> > > >carriers don't know how to bill any other way.
> > > >
> > > >If you applied a more IP Centric billing model (charge per byte), 
> then you
> > > >can easily charge for signal and user data the same way. My GPRS service
> > > >provider charges for GPRS data in exactly this manner--if I run a SIMPLE
> > > >service across it, they just see bytes. A signal byte and a user 
> byte are
> > > >indistinguishable.
> > > >
> > > >My personal nightmare is hearing that carriers want to charge X per 
> byte,
> > > >except for bytes that were in SIP messages.
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: simple-admin@mailman.dynamicsoft.com
> > > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael Hammer
> > > >Sent: Wednesday, March 13, 2002 9:41 AM
> > > >To: Dean Willis
> > > >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
> > > >Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was 
> something to
> > > >do wit message threading)
> > > >
> > > >
> > > >Dean,
> > > >
> > > >There are some things users care about and will pay for, and other 
> things
> > > >they won't.  For connection oriented services, they consider the 
> "air time"
> > > >when they have full cut-through to when they get disconnected to be the
> > > >value.  In connectionless services, they care about data packets getting
> > > >through, not overhead signaling packets.
> > > >
> > > >You seem to be suggesting that the customer pay for the time they spend
> > > >waiting for the signaling to complete the call.  Or, you expect them 
> to pay
> > > >for signaling as well as data-bearing messages.  This is analogous 
> to making
> > > >customers pay for packaging, when all they want is the handful of 
> tablets in
> > > >the little bottle inside the big box.
> > > >
> > > >Near where I live there is an ice-skating rink that charges by the hour.
> > > >Most people won't put up including in that hour the time taken to 
> fill out
> > > >forms and select skates.  Nor would they pay for time where they are
> > > >standing in line for that process.  Not standing in line, getting to the
> > > >rink sooner, and skating a full hour have value.
> > > >
> > > >This is not just the service provider perspective, but the customer
> > > >perspective.
> > > >
> > > >It's OK to get philosophical, just keep it real. :)
> > > >
> > > >Mike
> > > >
> > > >
> > > >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
> > > >
> > > >
> > > > > Warning: Philosophical Rant Follows
> > > > >
> > > > > The key issue is buried deep in the underlying business
> > > > > model. In the Internet world, you pay the same for the bits
> > > > > used to signal a multimedia session as for the bits used by
> > > > > the multimedia session itself. In the PSTN, the carriers pay
> > > > > for the signaling used to set up the multimedia session. In
> > > > > other words, there is NO signaling, as signaling is used in
> > > > > the PSTN sense, on the Internet -- just application traffic.
> > > > > There might be messaging applications, routing applications,
> > > > > management applications, or multimedia applications, but
> > > > > they're just all applications as far as the underlying
> > > > > network in concerned. In the PSTN, signaling actually
> > > > > traverses a separate, specialized network, driven by its own
> > > > > economic laws.
> > > > >
> > > >
> > > >Reference remaining rant elsewhere.
> > > >
> > > >Here's an example.
> > > >
> > > >-----------
> > > > From last year's Next Steps in Signaling BOF:
> > > >
> > > >6.5 James Kempf
> > > >    Radio access networks - air is expensive.  Optimize by using less
> > > >    bandwidth and more (for example) CPU cycles. Whatever the signaling
> > > >    protocol is, it must be very efficient for mobility. Providers pay
> > > >    big $$ for the airwaves, they don't want  to use it for signaling,
> > > >    but for user data.  Best: do the signaling through the backbone, and
> > > >    not over the air if possible.  The signaling must be efficient for
> > > >    mobility to minimize signaling while moving from area to area.
> > > >    Mobility signalling should be directly coupled to the traffic.
> > > >-------------
> > > >
> > > >See http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> > > >
> > > >Clearly from the provider perspective, user data and signaling are two
> > > >different things. Therein lies the debate. For if a user were to do
> > > >something that "looks like" signaling, they would intrude on the
> > > >territory of the operator.
> > > >
> > > >The problem here: is Messaging the same as signaling? Is Presence the
> > > >same as signaling? Is anything we do with SIP really "signaling" or is
> > > >it user data?
> > > >
> > > >--
> > > >Dean
> > > >
> > > >_______________________________________________
> > > >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 hgs@cs.columbia.edu  Thu Mar 14 10:13:21 2002
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 KAA15458
	for ; Thu, 14 Mar 2002 10:13:21 -0500 (EST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA06840;
	Thu, 14 Mar 2002 10:12:28 -0500 (EST)
Received: from cs.columbia.edu (pool-138-89-38-45.mad.east.verizon.net [138.89.38.45])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2EFCQNB007644
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Thu, 14 Mar 2002 10:12:27 -0500 (EST)
Message-ID: <3C90BFAD.DCEEA9F6@cs.columbia.edu>
Date: Thu, 14 Mar 2002 10:20:13 -0500
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Hammer 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomething to do  
 wit message threading)
References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
	 <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com>
	 <3C8FDC2F.939FBDE2@cisco.com> <4.3.2.7.2.20020314100137.047802a0@cia.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1279
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: 

Certainly - just like for airplanes. In both network and airline cases,
you care about getting the most money from your customers. Basic
economics tells you that you want to differentiate charging not just by
volume, but by willingness to pay. If number of bytes used is a
first-order approximation to willingness to pay, it may not be a bad
thing. However, note all the weekend/evening plans that were (are?)
popular for wireless to separate the business vs. consumer spending
willingness, or the various business vs. consumer plans for DSL. An
'empty' byte on a wireless network has the same properties as an empty
seat on an airplane - the owner of that byte or seat is going to do
anything to sell it before it leaves base, as long as they can keep
their existing customers that paid more from grabbing the better deal.

(This has strayed far beyond SIMPLE; if you're interested in the
analysis of this for QOS, I can point you to some papers we have written
on this topic.)

Michael Hammer wrote:
> 
> Henning,
> 
> Yes, but someone has to pay the debt schedule.  Over what period are you
> amortizing the fixed cost of the network?  15 years like telephone
> switches?  The balance sheet still has to make sense, even if the revenue
> and costs are not directly coupled.
>

From oran@cisco.com  Thu Mar 14 10:25:58 2002
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15519
	for ; Thu, 14 Mar 2002 10:25:58 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2EFP0325997;
	Thu, 14 Mar 2002 07:25:00 -0800 (PST)
Received: from oranlt ([161.44.238.50])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ACH90962;
	Thu, 14 Mar 2002 07:25:08 -0800 (PST)
From: "David R. Oran" 
To: "'Michael Hammer'" ,
        "'Ben Campbell'" 
Cc: "'Dean Willis'" ,
        "'Dean Willis'" ,
        "'Paul Kyzivat'" ,
        
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was   something to do wit message threading)
Date: Thu, 14 Mar 2002 10:24:10 -0500
Organization: Cisco Systems
Message-ID: <035701c1cb6c$4f992e70$32ee2ca1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 8233
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: 

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com 
> [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of 
> Michael Hammer
> Sent: Wednesday, March 13, 2002 5:42 PM
> To: Ben Campbell
> Cc: Dean Willis; 'Dean Willis'; 'Paul Kyzivat'; 
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Messages: Signaling, Data, or Theft 
> (Was something to do wit message threading)
> 
> 
> Ben,
> 
> When you consider RTP over IP, which fits your "IP 
> application" definition, 
> whether you charge per packet or realize that statistically X 
> packets and Y 
> minutes is "six of one, half a dozen of the other" then there 
> are some 
> models where per minute works out to be the same value.
>
Huh? What if I adaptively change my packetization perdiod based on
changes in loss patterns an end-to-end delay? If you do that you have to
count both bytes and packets and once you've done that minutes are
irrelevant (unless you want to gouge the user for silence periods). The
only time minutes might be relevant is if you want to charge for
*reserved resources*. If you do that, then you have the converse
situation - the only thing relevant to billing is the time the requested
resources are reserved, and bytes and packets don't matter.

The trap, as others have pointed out is to try to charge based on the
color of the bits, as opposed to what (if anything) the network does
with the bits.
 
> How do you reconcile volume charging with the two things that 
> I noticed 
> about my two services:  ISP:  Bills me a flat monthly fee for data 
> service.  Mobile phone:  Bills me flat monthly fee for phone 
> service, with 
> per minute charges above an agreed on number of "free" 
> minutes.  It didn't 
> used to be like that.  Seems you are suggesting a 
> trend-reversal or at 
> least an exception to the rule.
> 
> The earlier models of charging per data connection minute or 
> per minute of 
> call did not encourage usage and therefore generate enough 
> revenue.  Per 
> byte charges can generate revenue, but only if it doesn't 
> discourage use.
> 
> Will the per-byte prices be low enough to encourage use, yet 
> still cover 
> the cost of over-provisioning the network to keep setup delay 
> low?  Will 
> connection-less IM users pay a premium to make sure that 
> connection-oriented RTP-flow users don't experience setup 
> delays?  Tell me, 
> who pays for excess capacity?  This could be a competitive 
> discriminator.
> 
All of this completely confounds *accounting* with *billing*. If you
don't account for anything other than the existence of a subscription,
then all you can do is flat-rate bill. If you count something, you can
certainly bill for it, but you don't HAVE to, and the discussion is no
longer technical but marketing, sales, and macro-economics.

As a side note, accounting (but not billing!) falls out of nearly any
QoS capability, since you need to count things in order to police and
shape traffic.

Dave.
> Mike
> 
> 
> At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
> >You example only works when you apply a billing model (per minute 
> >billing) to a medium (IP applications) where it doesn't make sense. 
> >Indeed, I think the per-minute model is not so much expected by 
> >users--it is just the carriers don't know how to bill any other way.
> >
> >If you applied a more IP Centric billing model (charge per 
> byte), then 
> >you can easily charge for signal and user data the same way. My GPRS 
> >service provider charges for GPRS data in exactly this 
> manner--if I run 
> >a SIMPLE service across it, they just see bytes. A signal byte and a 
> >user byte are indistinguishable.
> >
> >My personal nightmare is hearing that carriers want to charge X per 
> >byte, except for bytes that were in SIP messages.
> >
> >
> >-----Original Message-----
> >From: simple-admin@mailman.dynamicsoft.com
> >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael 
> >Hammer
> >Sent: Wednesday, March 13, 2002 9:41 AM
> >To: Dean Willis
> >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
> >Subject: RE: [Simple] Messages: Signaling, Data, or Theft 
> (Was something to
> >do wit message threading)
> >
> >
> >Dean,
> >
> >There are some things users care about and will pay for, and other 
> >things they won't.  For connection oriented services, they 
> consider the 
> >"air time" when they have full cut-through to when they get 
> >disconnected to be the value.  In connectionless services, they care 
> >about data packets getting through, not overhead signaling packets.
> >
> >You seem to be suggesting that the customer pay for the time 
> they spend 
> >waiting for the signaling to complete the call.  Or, you 
> expect them to 
> >pay for signaling as well as data-bearing messages.  This is 
> analogous 
> >to making customers pay for packaging, when all they want is the 
> >handful of tablets in the little bottle inside the big box.
> >
> >Near where I live there is an ice-skating rink that charges by the 
> >hour. Most people won't put up including in that hour the 
> time taken to 
> >fill out forms and select skates.  Nor would they pay for time where 
> >they are standing in line for that process.  Not standing in line, 
> >getting to the rink sooner, and skating a full hour have value.
> >
> >This is not just the service provider perspective, but the customer 
> >perspective.
> >
> >It's OK to get philosophical, just keep it real. :)
> >
> >Mike
> >
> >
> >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
> >
> >
> > > Warning: Philosophical Rant Follows
> > >
> > > The key issue is buried deep in the underlying business model. In 
> > > the Internet world, you pay the same for the bits used to 
> signal a 
> > > multimedia session as for the bits used by the multimedia session 
> > > itself. In the PSTN, the carriers pay for the signaling 
> used to set 
> > > up the multimedia session. In other words, there is NO 
> signaling, as 
> > > signaling is used in the PSTN sense, on the Internet -- just 
> > > application traffic. There might be messaging 
> applications, routing 
> > > applications, management applications, or multimedia 
> applications, 
> > > but they're just all applications as far as the underlying
> > > network in concerned. In the PSTN, signaling actually
> > > traverses a separate, specialized network, driven by its own
> > > economic laws.
> > >
> >
> >Reference remaining rant elsewhere.
> >
> >Here's an example.
> >
> >-----------
> > From last year's Next Steps in Signaling BOF:
> >
> >6.5 James Kempf
> >    Radio access networks - air is expensive.  Optimize by using less
> >    bandwidth and more (for example) CPU cycles. Whatever 
> the signaling
> >    protocol is, it must be very efficient for mobility. 
> Providers pay
> >    big $$ for the airwaves, they don't want  to use it for 
> signaling,
> >    but for user data.  Best: do the signaling through the 
> backbone, and
> >    not over the air if possible.  The signaling must be 
> efficient for
> >    mobility to minimize signaling while moving from area to area.
> >    Mobility signalling should be directly coupled to the traffic.
> >-------------
> >
> >See 
> >http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> >
> >Clearly from the provider perspective, user data and 
> signaling are two 
> >different things. Therein lies the debate. For if a user were to do 
> >something that "looks like" signaling, they would intrude on the 
> >territory of the operator.
> >
> >The problem here: is Messaging the same as signaling? Is 
> Presence the 
> >same as signaling? Is anything we do with SIP really 
> "signaling" or is 
> >it user data?
> >
> >--
> >Dean
> >
> >_______________________________________________
> >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/listinf> o/simple
> 


From mhammer@cisco.com  Thu Mar 14 10:52:00 2002
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 KAA15653
	for ; Thu, 14 Mar 2002 10:52:00 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2EFpSL04694;
	Thu, 14 Mar 2002 10:51:28 -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 AAR82005;
	Thu, 14 Mar 2002 10:46:00 -0500 (EST)
Message-Id: <4.3.2.7.2.20020314103901.00b95e28@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 14 Mar 2002 10:51:05 -0500
To: Henning Schulzrinne 
From: Michael Hammer 
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomething
  to do   wit message threading)
Cc: simple@mailman.dynamicsoft.com
In-Reply-To: <3C90BFAD.DCEEA9F6@cs.columbia.edu>
References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
 <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com>
 <3C8FDC2F.939FBDE2@cisco.com>
 <4.3.2.7.2.20020314100137.047802a0@cia.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 1932
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: 

Henning,

Dave is right once you get beyond accounting for the traffic, billing is 
more an arbitrary business issue.

Back to what I perceive as the main technical question though:  Will 
session setup (signaling) packets get priority (within proxy processing) 
over IM packets such that session setup time is not impacted?  Or will 
users re-initiate after a second or two exacerbating the traffic load?  Or 
as some have suggested, does SIP traffic get segregated and travel over 
different proxies?  Does the protocol element exist to discriminate so?

Mike


At 10:20 AM 3/14/2002 -0500, Henning Schulzrinne wrote:
>Certainly - just like for airplanes. In both network and airline cases,
>you care about getting the most money from your customers. Basic
>economics tells you that you want to differentiate charging not just by
>volume, but by willingness to pay. If number of bytes used is a
>first-order approximation to willingness to pay, it may not be a bad
>thing. However, note all the weekend/evening plans that were (are?)
>popular for wireless to separate the business vs. consumer spending
>willingness, or the various business vs. consumer plans for DSL. An
>'empty' byte on a wireless network has the same properties as an empty
>seat on an airplane - the owner of that byte or seat is going to do
>anything to sell it before it leaves base, as long as they can keep
>their existing customers that paid more from grabbing the better deal.
>
>(This has strayed far beyond SIMPLE; if you're interested in the
>analysis of this for QOS, I can point you to some papers we have written
>on this topic.)
>
>Michael Hammer wrote:
> >
> > Henning,
> >
> > Yes, but someone has to pay the debt schedule.  Over what period are you
> > amortizing the fixed cost of the network?  15 years like telephone
> > switches?  The balance sheet still has to make sense, even if the revenue
> > and costs are not directly coupled.
> >


From hgs@cs.columbia.edu  Thu Mar 14 10:58:56 2002
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 KAA15696
	for ; Thu, 14 Mar 2002 10:58:56 -0500 (EST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA12057;
	Thu, 14 Mar 2002 10:57:30 -0500 (EST)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2EFvUNB010060
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Thu, 14 Mar 2002 10:57:30 -0500 (EST)
Message-ID: <3C90C856.CF763DA7@cs.columbia.edu>
Date: Thu, 14 Mar 2002 10:57:10 -0500
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Hammer 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do   
 wit message threading)
References: <4.3.2.7.2.20020313103045.00b2f4c0@cia.cisco.com>
	 <4.3.2.7.2.20020313171429.03e979b8@cia.cisco.com>
	 <3C8FDC2F.939FBDE2@cisco.com>
	 <4.3.2.7.2.20020314100137.047802a0@cia.cisco.com> <4.3.2.7.2.20020314103901.00b95e28@cia.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 843
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: 

There are a number of techniques, e.g., I vaguely remember work
published recently related to web servers from folks at IBM, that allow
prioritization for different classes of requests. Thus, I just don't see
this as a protocol issue.

Michael Hammer wrote:
> 
> Henning,
> 
> Dave is right once you get beyond accounting for the traffic, billing is
> more an arbitrary business issue.
> 
> Back to what I perceive as the main technical question though:  Will
> session setup (signaling) packets get priority (within proxy processing)
> over IM packets such that session setup time is not impacted?  Or will
> users re-initiate after a second or two exacerbating the traffic load?  Or
> as some have suggested, does SIP traffic get segregated and travel over
> different proxies?  Does the protocol element exist to discriminate so?
> 
> Mike

From Markus.Isomaki@nokia.com  Thu Mar 14 14:44:22 2002
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 OAA16482
	for ; Thu, 14 Mar 2002 14:44:20 -0500 (EST)
From: Markus.Isomaki@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 g2EJheZ14323
	for ; Thu, 14 Mar 2002 21:43:40 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 14 Mar 2002 21:43:28 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 14 Mar 2002 21:43:28 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do   wit message threading)
Date: Thu, 14 Mar 2002 21:43:28 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do   wit message threading)
Thread-Index: AcHLcSnzUqPC4J2NTq+lvbtgh9OWuAAHcWgA
To: , 
Cc: 
X-OriginalArrivalTime: 14 Mar 2002 19:43:28.0587 (UTC) FILETIME=[838D01B0:01C1CB90]
Content-Length: 2225
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA16482
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: 

Hi,

Scheduling within proxies is one thing. Also important is how the IP packets carrying SIP are handled over low-capacity links. For example in wireless access, session setup maybe treated differently from regular traffic in order to meet the call setup times. On the other hand large MESSAGEs etc. could be treated as best-effort. DiffServ codepoints might be used to do the thing, but this requires the last hop proxy to set them based on some logic. Probably this is nothing to do with SIP protocol, though. 

Also a question: what if there is a single TCP connection between UA and proxy. Proxy starts to transmit a large MESSAGE toward UA. In the meanwhile an INVITE for a voice call arrives at the proxy to be delivered to the same UA. Is it possible to interleave it between the TCP segments carrying MESSAGE, or does MESSAGE block the transport?

Markus

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: 14 March, 2002 17:57
> To: Michael Hammer
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Messages: Signaling, Data, or Theft
> (Wassomethingto do wit message threading)
> 
> 
> There are a number of techniques, e.g., I vaguely remember work
> published recently related to web servers from folks at IBM, 
> that allow
> prioritization for different classes of requests. Thus, I 
> just don't see
> this as a protocol issue.
> 
> Michael Hammer wrote:
> > 
> > Henning,
> > 
> > Dave is right once you get beyond accounting for the 
> traffic, billing is
> > more an arbitrary business issue.
> > 
> > Back to what I perceive as the main technical question though:  Will
> > session setup (signaling) packets get priority (within 
> proxy processing)
> > over IM packets such that session setup time is not 
> impacted?  Or will
> > users re-initiate after a second or two exacerbating the 
> traffic load?  Or
> > as some have suggested, does SIP traffic get segregated and 
> travel over
> > different proxies?  Does the protocol element exist to 
> discriminate so?
> > 
> > Mike
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From Tom_Gray@Mitel.COM  Thu Mar 14 15:18:53 2002
Received: from Mitel.COM ([216.191.234.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16611
	for ; Thu, 14 Mar 2002 15:18:48 -0500 (EST)
From: Tom_Gray@Mitel.COM
Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id PAA19602;
	Thu, 14 Mar 2002 15:17:28 -0500 (EST)
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Was something to do wit
 message threading)
To: "David R. Oran" 
Cc: "'Michael Hammer'" ,
        "'Ben Campbell'" ,
        "'Dean Willis'" ,
        "'Paul Kyzivat'" ,
        
Date: Thu, 14 Mar 2002 15:17:27 -0500
Message-ID: 
X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.7 |March 21, 2001) at 03/14/2002
 03:17:27 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 8927
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: 

 For a survey and references consult

http://www.comsoc.org/livepubs/surveys/public/2q00issue/pdf/DaSilva.pdf






"David R. Oran" @mailman.dynamicsoft.com on 03/14/2002
10:24:10 AM

Sent by:  simple-admin@mailman.dynamicsoft.com


To:   "'Michael Hammer'" , "'Ben Campbell'"
      
cc:   "'Dean Willis'" , "'Dean Willis'"
      , "'Paul Kyzivat'" ,
      

Subject:  RE: [Simple] Messages: Signaling, Data, or Theft (Was   something
      to do wit message threading)


> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of
> Michael Hammer
> Sent: Wednesday, March 13, 2002 5:42 PM
> To: Ben Campbell
> Cc: Dean Willis; 'Dean Willis'; 'Paul Kyzivat';
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Messages: Signaling, Data, or Theft
> (Was something to do wit message threading)
>
>
> Ben,
>
> When you consider RTP over IP, which fits your "IP
> application" definition,
> whether you charge per packet or realize that statistically X
> packets and Y
> minutes is "six of one, half a dozen of the other" then there
> are some
> models where per minute works out to be the same value.
>
Huh? What if I adaptively change my packetization perdiod based on
changes in loss patterns an end-to-end delay? If you do that you have to
count both bytes and packets and once you've done that minutes are
irrelevant (unless you want to gouge the user for silence periods). The
only time minutes might be relevant is if you want to charge for
*reserved resources*. If you do that, then you have the converse
situation - the only thing relevant to billing is the time the requested
resources are reserved, and bytes and packets don't matter.

The trap, as others have pointed out is to try to charge based on the
color of the bits, as opposed to what (if anything) the network does
with the bits.

> How do you reconcile volume charging with the two things that
> I noticed
> about my two services:  ISP:  Bills me a flat monthly fee for data
> service.  Mobile phone:  Bills me flat monthly fee for phone
> service, with
> per minute charges above an agreed on number of "free"
> minutes.  It didn't
> used to be like that.  Seems you are suggesting a
> trend-reversal or at
> least an exception to the rule.
>
> The earlier models of charging per data connection minute or
> per minute of
> call did not encourage usage and therefore generate enough
> revenue.  Per
> byte charges can generate revenue, but only if it doesn't
> discourage use.
>
> Will the per-byte prices be low enough to encourage use, yet
> still cover
> the cost of over-provisioning the network to keep setup delay
> low?  Will
> connection-less IM users pay a premium to make sure that
> connection-oriented RTP-flow users don't experience setup
> delays?  Tell me,
> who pays for excess capacity?  This could be a competitive
> discriminator.
>
All of this completely confounds *accounting* with *billing*. If you
don't account for anything other than the existence of a subscription,
then all you can do is flat-rate bill. If you count something, you can
certainly bill for it, but you don't HAVE to, and the discussion is no
longer technical but marketing, sales, and macro-economics.

As a side note, accounting (but not billing!) falls out of nearly any
QoS capability, since you need to count things in order to police and
shape traffic.

Dave.
> Mike
>
>
> At 02:47 PM 3/13/2002 -0600, Ben Campbell wrote:
> >You example only works when you apply a billing model (per minute
> >billing) to a medium (IP applications) where it doesn't make sense.
> >Indeed, I think the per-minute model is not so much expected by
> >users--it is just the carriers don't know how to bill any other way.
> >
> >If you applied a more IP Centric billing model (charge per
> byte), then
> >you can easily charge for signal and user data the same way. My GPRS
> >service provider charges for GPRS data in exactly this
> manner--if I run
> >a SIMPLE service across it, they just see bytes. A signal byte and a
> >user byte are indistinguishable.
> >
> >My personal nightmare is hearing that carriers want to charge X per
> >byte, except for bytes that were in SIP messages.
> >
> >
> >-----Original Message-----
> >From: simple-admin@mailman.dynamicsoft.com
> >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Michael
> >Hammer
> >Sent: Wednesday, March 13, 2002 9:41 AM
> >To: Dean Willis
> >Cc: 'Dean Willis'; 'Paul Kyzivat'; simple@mailman.dynamicsoft.com
> >Subject: RE: [Simple] Messages: Signaling, Data, or Theft
> (Was something to
> >do wit message threading)
> >
> >
> >Dean,
> >
> >There are some things users care about and will pay for, and other
> >things they won't.  For connection oriented services, they
> consider the
> >"air time" when they have full cut-through to when they get
> >disconnected to be the value.  In connectionless services, they care
> >about data packets getting through, not overhead signaling packets.
> >
> >You seem to be suggesting that the customer pay for the time
> they spend
> >waiting for the signaling to complete the call.  Or, you
> expect them to
> >pay for signaling as well as data-bearing messages.  This is
> analogous
> >to making customers pay for packaging, when all they want is the
> >handful of tablets in the little bottle inside the big box.
> >
> >Near where I live there is an ice-skating rink that charges by the
> >hour. Most people won't put up including in that hour the
> time taken to
> >fill out forms and select skates.  Nor would they pay for time where
> >they are standing in line for that process.  Not standing in line,
> >getting to the rink sooner, and skating a full hour have value.
> >
> >This is not just the service provider perspective, but the customer
> >perspective.
> >
> >It's OK to get philosophical, just keep it real. :)
> >
> >Mike
> >
> >
> >At 04:29 PM 3/12/2002 -0600, Dean Willis wrote:
> >
> >
> > > Warning: Philosophical Rant Follows
> > >
> > > The key issue is buried deep in the underlying business model. In
> > > the Internet world, you pay the same for the bits used to
> signal a
> > > multimedia session as for the bits used by the multimedia session
> > > itself. In the PSTN, the carriers pay for the signaling
> used to set
> > > up the multimedia session. In other words, there is NO
> signaling, as
> > > signaling is used in the PSTN sense, on the Internet -- just
> > > application traffic. There might be messaging
> applications, routing
> > > applications, management applications, or multimedia
> applications,
> > > but they're just all applications as far as the underlying
> > > network in concerned. In the PSTN, signaling actually
> > > traverses a separate, specialized network, driven by its own
> > > economic laws.
> > >
> >
> >Reference remaining rant elsewhere.
> >
> >Here's an example.
> >
> >-----------
> > From last year's Next Steps in Signaling BOF:
> >
> >6.5 James Kempf
> >    Radio access networks - air is expensive.  Optimize by using less
> >    bandwidth and more (for example) CPU cycles. Whatever
> the signaling
> >    protocol is, it must be very efficient for mobility.
> Providers pay
> >    big $$ for the airwaves, they don't want  to use it for
> signaling,
> >    but for user data.  Best: do the signaling through the
> backbone, and
> >    not over the air if possible.  The signaling must be
> efficient for
> >    mobility to minimize signaling while moving from area to area.
> >    Mobility signalling should be directly coupled to the traffic.
> >-------------
> >
> >See
> >http://search.ietf.org/internet-drafts/draft-bradner-nsis-bof-00.txt
> >
> >Clearly from the provider perspective, user data and
> signaling are two
> >different things. Therein lies the debate. For if a user were to do
> >something that "looks like" signaling, they would intrude on the
> >territory of the operator.
> >
> >The problem here: is Messaging the same as signaling? Is
> Presence the
> >same as signaling? Is anything we do with SIP really
> "signaling" or is
> >it user data?
> >
> >--
> >Dean
> >
> >_______________________________________________
> >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/listinf> o/simple
>

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




From dean.willis@softarmor.com  Thu Mar 14 16:45:27 2002
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 QAA16894
	for ; Thu, 14 Mar 2002 16:45:26 -0500 (EST)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2ELiXU28121;
	Thu, 14 Mar 2002 15:44:33 -0600
From: "Dean Willis" 
To: 
Cc: 
Subject: Message Interveleaving: was RE: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do   wit message threading)
Date: Thu, 14 Mar 2002 15:44:19 -0600
Message-ID: <00e701c1cba1$6610ba30$bb036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-reply-to: 
Content-Length: 977
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: 

> Also a question: what if there is a single TCP connection 
> between UA and proxy. Proxy starts to transmit a large 
> MESSAGE toward UA. In the meanwhile an INVITE for a voice 
> call arrives at the proxy to be delivered to the same UA. Is 
> it possible to interleave it between the TCP segments 
> carrying MESSAGE, or does MESSAGE block the transport?

That is transport dependent -- does your transport protocol provide for
subpacketization and interleaving?

There was a big push to provide this with PPP back when people thought
they were going to be doing voice over IP over dialup, and we found that
every large TCP packet blew the RTP jitter buffer due to serialization
delay. Somebody who's brain works better than mine can probably produce
a reference for the PPP variation, which I think was never widely
deployed.

One could hope that the wireless transport people provide something like
that. I have the sneaking suspicion they didn't, at least yet.

--
Dean


From bcampbell@dynamicsoft.com  Thu Mar 14 17:09:51 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16995
	for ; Thu, 14 Mar 2002 17:09:50 -0500 (EST)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2EM8K232452;
	Thu, 14 Mar 2002 16:08:22 -0600 (CST)
From: "Ben Campbell" 
To: , , 
Cc: 
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do   wit message threading)
Date: Thu, 14 Mar 2002 16:06:59 -0600
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
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 704
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: 

> Also a question: what if there is a single TCP connection between
> UA and proxy. Proxy starts to transmit a large MESSAGE toward UA.
> In the meanwhile an INVITE for a voice call arrives at the proxy
> to be delivered to the same UA. Is it possible to interleave it
> between the TCP segments carrying MESSAGE, or does MESSAGE block
> the transport?
>

That could be a problem in some scenarios. I think the real answer, though,
is to limit the MESSAGE requests to some reasonable size. We have had talk
about standardizing methods to send large data by reference--I think any
real application that sends messages containing much bigger than an average
text IM will eventually need to go that route.


From pkyzivat@cisco.com  Thu Mar 14 18:21:58 2002
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 SAA17235
	for ; Thu, 14 Mar 2002 18:21:58 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2ENLPP07720;
	Thu, 14 Mar 2002 18:21: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 AAG80013;
	Thu, 14 Mar 2002 18:24:18 -0500 (EST)
Message-ID: <3C91305F.51007A32@cisco.com>
Date: Thu, 14 Mar 2002 18:21:03 -0500
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: Ben Campbell 
CC: Markus.Isomaki@nokia.com, hgs@cs.columbia.edu, mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do   
 wit message threading)
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 953
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: 


Ben Campbell wrote:
> 
> > Also a question: what if there is a single TCP connection between
> > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA.
> > In the meanwhile an INVITE for a voice call arrives at the proxy
> > to be delivered to the same UA. Is it possible to interleave it
> > between the TCP segments carrying MESSAGE, or does MESSAGE block
> > the transport?
> >
> 
> That could be a problem in some scenarios. I think the real answer, though,
> is to limit the MESSAGE requests to some reasonable size. We have had talk
> about standardizing methods to send large data by reference--I think any
> real application that sends messages containing much bigger than an average
> text IM will eventually need to go that route.

This is probably reasonable for page mode IM, but less reasonable for session mode. Once you have gone to the trouble to establish a session, it should be ok to send bigger
messages over it.

	Paul

From sriramp@nortelnetworks.com  Thu Mar 14 18:49:11 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17345
	for ; Thu, 14 Mar 2002 18:49:11 -0500 (EST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2ENmJh06809
	for ; Thu, 14 Mar 2002 17:48:20 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 14 Mar 2002 17:48:21 -0600
Message-ID: 
From: "Sriram Parameswar"
To: simple@mailman.dynamicsoft.com
Date: Thu, 14 Mar 2002 17:48:20 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1CBB2.B896C3B0"
Content-Length: 5475
Subject: [Simple] IMTP vs. IMXP
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: 

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_01C1CBB2.B896C3B0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi:

Taking a look at the IMTP versus IMXP issue - I have evaluated them as
follows:
IMTP
-----
1. Is a subset of SIP - however what is the actual use of the 'To' header in
IMTP? The From header has its uses - example chat rooms.
2. In the NAT/FW traversal discussion - when are the 'REGISTER' bindings
with the IMTP relay freed? Typically we would expect the receipt of a BYE to
free the bindings - what if we do not get that BYE? How do we handle
extended/persistent sessions?
3. On the issue of re-negotiating the media (i.e. send a jpeg file in the
IMTP bearer) - it should be made clear that a re-INVITE is necessary.
4. IMTP is basically forcing the routing decision up several layers (upto
the Application Layer) and this "routing" would be much more efficient at
lower layers.

IMXP (IM Simple Exchange)
-----
1. Though BEEP is considered lightweight, it seems like overkill in that the
negotiation and security seem redundant with what can be done with SIP.
2.BEEP does not currently support threading, but this could possibly be done
using the message exchange identifier/content ID. However something along
the lines of draft-koskelainen-imtpext-00.txt may need to be added.
3. I am not sure that the NAT/Firewall traversal issue has been solved -
especially keeping the NAT bindings open for an extended session.

Both the I-D's do not take up the issue of rendering Instant Messagig
content - a feature that is available in existing IM systems. 

Are there other alternatives that we have not considered? CPIM with an XHTML
payload over TCP could be a starting point. It solves rendering of Instant
Messages - on UA's and the interoperability issue too. We could also
consider using CC/PP to ensure that payloads are formatted correctly as per
the recepients terminal characteristics.

Thanks,

Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com

------_=_NextPart_001_01C1CBB2.B896C3B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






IMTP vs. IMXP




Hi:




Taking a look at the IMTP versus IMXP issue - I have =
evaluated them as follows:

IMTP

-----

1. Is a subset of SIP - however what is the actual =
use of the 'To' header in IMTP? The From header has its uses - example =
chat rooms.



2. In the NAT/FW traversal discussion - when are the =
'REGISTER' bindings with the IMTP relay freed? Typically we would =
expect the receipt of a BYE to free the bindings - what if we do not =
get that BYE? How do we handle extended/persistent sessions?



3. On the issue of re-negotiating the media (i.e. =
send a jpeg file in the IMTP bearer) - it should be made clear that a =
re-INVITE is necessary.



4. IMTP is basically forcing the routing decision up =
several layers (upto the Application Layer) and this =
"routing" would be much more efficient at lower =
layers.



IMXP (IM Simple Exchange)

-----

1. Though BEEP is considered lightweight, it seems =
like overkill in that the negotiation and security seem redundant with =
what can be done with SIP.



2.BEEP does not currently support threading, but this =
could possibly be done using the message exchange identifier/content =
ID. However something along the lines of =
draft-koskelainen-imtpext-00.txt may need to be added.



3. I am not sure that the NAT/Firewall traversal =
issue has been solved - especially keeping the NAT bindings open for an =
extended session.



Both the I-D's do not take up the issue of rendering =
Instant Messagig content - a feature that is available in existing IM =
systems. 



Are there other alternatives that we have not =
considered? CPIM with an XHTML payload over TCP could be a starting =
point. It solves rendering of Instant Messages - on UA's and the =
interoperability issue too. We could also consider using CC/PP to =
ensure that payloads are formatted correctly as per the recepients =
terminal characteristics.



Thanks,




Sriram

__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-684-3986

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com





------_=_NextPart_001_01C1CBB2.B896C3B0--

From Marcelo.HeilFranca@icn.siemens.de  Fri Mar 15 05:35:40 2002
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19328
	for ; Fri, 15 Mar 2002 05:35:40 -0500 (EST)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA10488;
	Fri, 15 Mar 2002 11:34:43 +0100 (MET)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA07191;
	Fri, 15 Mar 2002 11:34:28 +0100 (MET)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Fri, 15 Mar 2002 11:34:41 +0100
Message-ID: <5B4D0C5BA65ECA46969C1419122317E60EDEA4@mchh161e>
From: Heil Franca Marcelo  ICM N PG U ID A 2
	 
To: "'Paul Kyzivat'" ,
        Ben Campbell
	 
Cc: Markus.Isomaki@nokia.com, hgs@cs.columbia.edu, mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto 
	do    wit message threading)
Date: Fri, 15 Mar 2002 11:34:51 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1742
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: 

Comments below:

> 
> 
> 
> 
> Ben Campbell wrote:
> > 
> > > Also a question: what if there is a single TCP connection between
> > > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA.
> > > In the meanwhile an INVITE for a voice call arrives at the proxy
> > > to be delivered to the same UA. Is it possible to interleave it
> > > between the TCP segments carrying MESSAGE, or does MESSAGE block
> > > the transport?
> > >
> > 
> > That could be a problem in some scenarios. I think the real 
> answer, though,
> > is to limit the MESSAGE requests to some reasonable size. 
> We have had talk
> > about standardizing methods to send large data by 
> reference--I think any
> > real application that sends messages containing much bigger 
> than an average
> > text IM will eventually need to go that route.
> 
> This is probably reasonable for page mode IM, but less 
> reasonable for session mode. Once you have gone to the 
> trouble to establish a session, it should be ok to send bigger
> messages over it.
> 
> 	Paul

I support limiting the size of MESSAGE requests for page mode IM.
Otherwise, network components (e. g. proxies) which are not really concerned
with IM contents would be unnecessarily burdened. For example, intermediate
proxies having to process, route and forward large MESSAGEs (with sizes in
the order of megabytes) arriving frequently would quickly run out of memory
resources. 
Session mode IMs should be expected to be transferred end-to-end using an
appropriate transport protocol, so that intermediate proxies should not be
in the path and therefore not  directly involved in the IM transfer. Session
mode seems, therefore, much more appropriate for tranferring large IMs than
page mode.
Marcelo

From dean.willis@softarmor.com  Fri Mar 15 10:53:45 2002
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 KAA20281
	for ; Fri, 15 Mar 2002 10:53:45 -0500 (EST)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2FFqpe00800;
	Fri, 15 Mar 2002 09:52:52 -0600
From: "Dean Willis" 
To: "'Heil Franca Marcelo  ICM N PG U ID A 2'" 
Cc: 
Date: Fri, 15 Mar 2002 09:52:36 -0600
Message-ID: <017301c1cc39$6e03ceb0$bb036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <5B4D0C5BA65ECA46969C1419122317E60EDEA4@mchh161e>
Content-Length: 2826
Subject: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft)
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: 

Marcelo wrote:
> I support limiting the size of MESSAGE requests for page mode 
> IM. Otherwise, network components (e. g. proxies) which are 
> not really concerned with IM contents would be unnecessarily 
> burdened. For example, intermediate proxies having to 
> process, route and forward large MESSAGEs (with sizes in the 
> order of megabytes) arriving frequently would quickly run out 
> of memory resources. 

The genral approach that I believe has been agreed on is that MESSAGES
should not exceed a size slightly smaller than a reasonable path MTU
because there MAY bea a UDP link somewhere in between, and fragmenting
over a UDP link increases the probability of a fragment loss (not to
mention posing interesting issues for congestion management). Beyond
this point, reducing them in size doesn't significantly affect the proxy
performance, because the proxy load is driven by the forwarding logic
and signaling state machines and not the I/O of the message body.

> Session mode IMs should be expected to be transferred 
> end-to-end using an appropriate transport protocol, so that 
> intermediate proxies should not be in the path and therefore 
> not  directly involved in the IM transfer. Session mode 
> seems, therefore, much more appropriate for tranferring large 
> IMs than page mode. Marcelo 

Page mode IMs don't necessarily transit the intermediate proxies. If the
contact address of the destination is known, and the network topology
has not been deliberately designed to prevent it, one can send the
MESSAGE directly to the far end. Let's not let the fact that some people
have deliberately obfuscated their networks with "required" proxies make
us forget about the intended end-to-end nature of the Internet.

The general idea of a proxy is as a "location service" aid -- if you
don't know how to get directly to somoeone (or can't, due to topology),
you can ask a proxy to help. In fact, one could use pager-mode MESSAGES
over a persistent end-to-end TCP or TCP/TLS session, and get all the
benefits of congestion control, retransmission, in-order delivery, and
reassembly.

This is most interesting because the intended nature of the "sips:" URI
mechanism is that every link be TLS (which implies TCP or SCTP). So the
use of sips: on MESSAGE requests most all of the UDP-related issues,
esepcially when used directly with a sips: contact.

Combine this with the use of redirection (302) messages instead of
"proxying", and one can get e2e sessions (which transport pager-mode
MESSAGES as well as other SIP) in a very nice end-to-end fashion. And
there's probably something that could be done to optimize the flow by
allowing intermediate proxies that absolutely MUST stay on the path to
"cache" 302 responses and recurse on them to provide automatic MESSAGE
path optimization.

--
Dean

--
Dean


From Thomas.Nagel@materna.de  Fri Mar 15 11:02:40 2002
Received: from smtp01ffm.de.uu.net (smtp01ffm.de.uu.net [192.76.144.150])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20362
	for ; Fri, 15 Mar 2002 11:02:40 -0500 (EST)
Received: from penelope.materna.de (penelope.materna.de [193.96.115.65])
	by smtp01ffm.de.uu.net (5.5.5/5.5.5) with ESMTP id RAA15639;
	Fri, 15 Mar 2002 17:02:23 +0100 (MET)
Received: from ganymed (ganymed.materna.de [139.2.34.141])
	by penelope.materna.de (Postfix) with ESMTP
	id 8C44B67F7; Fri, 15 Mar 2002 17:01:45 +0100 (MET)
Received: from thurn.materna.de (actually localhost) by ganymed
          with Internet with ESMTP; Fri, 15 Mar 2002 17:01:36 +0100
Received: by thurn.materna.de with Internet Mail Service (5.5.2653.19)
	id ; Fri, 15 Mar 2002 17:01:14 +0100
Message-ID: <73B855B4F72FD411A1CF009027B113C40199F739@taxis.materna.de>
From: "Nagel, Thomas" 
To: "'Dean Willis'" 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: AW: [Simple] Message Sizes (was Messages: Signaling, Data, or The
	ft)
Date: Fri, 15 Mar 2002 17:01:14 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1616
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA20362
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: 

Hi Dean, 


> -----Ursprüngliche Nachricht-----
> Von: Dean Willis [mailto:dean.willis@softarmor.com]
> Gesendet: Freitag, 15. März 2002 16:53
> An: 'Heil Franca Marcelo ICM N PG U ID A 2'
> Cc: simple@mailman.dynamicsoft.com
> Betreff: [Simple] Message Sizes (was Messages: Signaling, Data, or
> Theft)
> 
> 
> Marcelo wrote:
> > I support limiting the size of MESSAGE requests for page mode 
> > IM. Otherwise, network components (e. g. proxies) which are 
> > not really concerned with IM contents would be unnecessarily 
> > burdened. For example, intermediate proxies having to 
> > process, route and forward large MESSAGEs (with sizes in the 
> > order of megabytes) arriving frequently would quickly run out 
> > of memory resources. 
> 
> The genral approach that I believe has been agreed on is that MESSAGES
> should not exceed a size slightly smaller than a reasonable path MTU
> because there MAY bea a UDP link somewhere in between, and fragmenting
> over a UDP link increases the probability of a fragment loss (not to
> mention posing interesting issues for congestion management). Beyond
> this point, reducing them in size doesn't significantly 
> affect the proxy
> performance, because the proxy load is driven by the forwarding logic
> and signaling state machines and not the I/O of the message body.
> 

Question: Doesn't this (again) raise the (afaik. in IPv4 un-solvable) 
PATH MRU discovery problem?

Thomas


> --
> Dean
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From bcampbell@dynamicsoft.com  Fri Mar 15 11:32:28 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20481
	for ; Fri, 15 Mar 2002 11:32:27 -0500 (EST)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2FGVL216353;
	Fri, 15 Mar 2002 10:31:21 -0600 (CST)
From: "Ben Campbell" 
To: "Dean Willis" ,
        "'Heil Franca Marcelo  ICM N PG U ID A 2'" 
Cc: 
Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft)
Date: Fri, 15 Mar 2002 10:28:56 -0600
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
In-Reply-To: <017301c1cc39$6e03ceb0$bb036e3f@TXDWILLIS2>
Importance: Normal
Content-Length: 2009
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: 

> Page mode IMs don't necessarily transit the intermediate proxies. If the
> contact address of the destination is known, and the network topology
> has not been deliberately designed to prevent it, one can send the
> MESSAGE directly to the far end. Let's not let the fact that some people
> have deliberately obfuscated their networks with "required" proxies make
> us forget about the intended end-to-end nature of the Internet.
>
> The general idea of a proxy is as a "location service" aid -- if you
> don't know how to get directly to somoeone (or can't, due to topology),
> you can ask a proxy to help. In fact, one could use pager-mode MESSAGES
> over a persistent end-to-end TCP or TCP/TLS session, and get all the
> benefits of congestion control, retransmission, in-order delivery, and
> reassembly.
>
> This is most interesting because the intended nature of the "sips:" URI
> mechanism is that every link be TLS (which implies TCP or SCTP). So the
> use of sips: on MESSAGE requests most all of the UDP-related issues,
> esepcially when used directly with a sips: contact.
>
> Combine this with the use of redirection (302) messages instead of
> "proxying", and one can get e2e sessions (which transport pager-mode
> MESSAGES as well as other SIP) in a very nice end-to-end fashion. And
> there's probably something that could be done to optimize the flow by
> allowing intermediate proxies that absolutely MUST stay on the path to
> "cache" 302 responses and recurse on them to provide automatic MESSAGE
> path optimization.
>

Keep in mind though, that MESSAGE does not initiate a dialog. The affect
here is that, in the absense of something like a "Moved Permantly"
redirection, Each subsequent MESSAGE request to a given address of record
will follow a similar path--that is, there is no real way _not_ to record
route.

That of course does not prevent the _initial_ route to end up e2e, with the
use of redirect servers as you mention. But each subsequent message must
also get redirected.


From dean.willis@softarmor.com  Fri Mar 15 12:19:02 2002
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 MAA20680
	for ; Fri, 15 Mar 2002 12:19:01 -0500 (EST)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2FHI0e01454;
	Fri, 15 Mar 2002 11:18:00 -0600
From: "Dean Willis" 
To: "'Ben Campbell'" ,
        "'Heil Franca Marcelo  ICM N PG U ID A 2'" 
Cc: 
Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft)
Date: Fri, 15 Mar 2002 11:17:44 -0600
Message-ID: <040a01c1cc45$52a417e0$bb036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: 
Content-Length: 2570
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: 

Ben points out:
> Keep in mind though, that MESSAGE does not initiate a dialog. 
> The affect here is that, in the absense of something like a 
> "Moved Permantly" redirection, Each subsequent MESSAGE 
> request to a given address of record will follow a similar 
> path--that is, there is no real way _not_ to record route.
> 
> That of course does not prevent the _initial_ route to end up 
> e2e, with the use of redirect servers as you mention. But 
> each subsequent message must also get redirected.

That's what I mean by "caching" redirections.

Say we have:

UA1--->P1--->LS
        |
        |
        UA2

Where the normal flow is something like:

UA1->INVITE target@lS->P1
P1->INVITE target@ls->LS
LS->302 target@UA2 -> P1
P1 -> INVITE target@ls -> UA2

Or

UA1->MESSAGE target@lS->P1
P1->MESSAGE target@ls->LS
LS->302 target@UA2 -> P1
P1 -> MESSAGE target@ls -> UA2

Now, the normal model is that for each subsequent INVITE or MESSAGE to
go through the same process.

But what if P1 "remembers" that it has been recently redirected for this
request URI, and just keeps on using it, like:

UA1->INVITE target@lS->P1
P1 -> INVITE target@ls -> UA2

Or

UA1->MESSAGE target@lS->P1
P1 -> MESSAGE target@ls -> UA2
 
Certainly, this raises some questions:

1) How long to "remember" -- it's not permanent, but it's longer than 1
message . . .

2) What happens if we keep sending to the redirected contact "too long"
and the user has already moved somewhere else?

3) the caching operation is clearly proxy stateful

4) we could implement this sort of 302 caching in a UA too

A couple of possibilities spring to mind.

1) We could add something like a duration indicator to the 302 response,
much like the TTL on DNS lookups. Or we could contrive to do something
at the DNS level, although this really doesn't give us the message-type
specific behavior potentially provided by the LS in this example. Or we
could rely on a "bounce" from question 2 to let us know that the
situation has changed and we need to reconsider the route.

2) If the contact that P1 is redirecting too stops responding (timeout
or ICMP response) then P1 knows to flush the cache. This begs the
question of what happens if the redirection policy at LS changes --
using this model, we'd continue talking to the original redirection
contact until some other mechanism causes a transition, which might be
acceptable.

3) Yes, all 302-recursions are at least transaction satteful at the
proxy. 

4) Actually, any point that does a 302-recursion could implement this
sort of approach.

--
Dean


From dean.willis@softarmor.com  Fri Mar 15 12:23:27 2002
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 MAA20733
	for ; Fri, 15 Mar 2002 12:23:27 -0500 (EST)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2FHMae01490;
	Fri, 15 Mar 2002 11:22:37 -0600
From: "Dean Willis" 
To: "'Nagel, Thomas'" 
Cc: 
Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft)
Date: Fri, 15 Mar 2002 11:22:21 -0600
Message-ID: <040b01c1cc45$f756b8b0$bb036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <73B855B4F72FD411A1CF009027B113C40199F739@taxis.materna.de>
Content-Length: 550
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: 

> Question: Doesn't this (again) raise the (afaik. in IPv4 un-solvable) 
> PATH MRU discovery problem?
> 
> Thomas

Yes. Actually, we could use a similar approach to TCP path MTU discovery
(implemented from BSD 4.4 Tahoe on, I believe). Any proxy sending SIP
messages UDP would set DF, and if the message is rejected by a router
(indicated by returned ICMP response saying fragementation required, DF
set), either kick the message back towards the source with a "message
size exceeded" SIP response or switch to a more reasonable protocol.

--
Dean


From bcampbell@dynamicsoft.com  Fri Mar 15 14:01:40 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21055
	for ; Fri, 15 Mar 2002 14:01:39 -0500 (EST)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2FJ0e229939;
	Fri, 15 Mar 2002 13:00:40 -0600 (CST)
From: "Ben Campbell" 
To: "Dean Willis" ,
        "'Heil Franca Marcelo  ICM N PG U ID A 2'" 
Cc: 
Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft)
Date: Fri, 15 Mar 2002 12:58:14 -0600
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <040a01c1cc45$52a417e0$bb036e3f@TXDWILLIS2>
Content-Length: 1104
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: 

> 1) We could add something like a duration indicator to the 302 response,
> much like the TTL on DNS lookups. Or we could contrive to do something
> at the DNS level, although this really doesn't give us the message-type
> specific behavior potentially provided by the LS in this example. Or we
> could rely on a "bounce" from question 2 to let us know that the
> situation has changed and we need to reconsider the route.

Actually, the current SIP spec officially supports the use of the Expires
header in 302 responses for this purpose.

>
> 2) If the contact that P1 is redirecting too stops responding (timeout
> or ICMP response) then P1 knows to flush the cache. This begs the
> question of what happens if the redirection policy at LS changes --
> using this model, we'd continue talking to the original redirection
> contact until some other mechanism causes a transition, which might be
> acceptable.
>
> 3) Yes, all 302-recursions are at least transaction satteful at the
> proxy.
>
> 4) Actually, any point that does a 302-recursion could implement this
> sort of approach.
>
> --
> Dean
>


From dwillis@dynamicsoft.com  Fri Mar 15 14:17:22 2002
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 OAA21147
	for ; Fri, 15 Mar 2002 14:17:21 -0500 (EST)
Received: from there (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g2FJFhe02317;
	Fri, 15 Mar 2002 13:15:43 -0600
Message-Id: <200203151915.g2FJFhe02317@bdsl.66.12.12.130.gte.net>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Dean Willis 
To: "Ben Campbell" , ,
        , 
Subject: Re: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do   wit message threading)
Date: Fri, 15 Mar 2002 13:15:41 -0600
X-Mailer: KMail [version 1.3.2]
Cc: 
References: 
In-Reply-To: 
Organization: dynamicsoft Inc.
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Length: 1159
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: 

Actually, if you do the math, you find that something like 64 bytes is 
the largest message size whose serialization delay doesn't break RTP at 
9600 bps. That makes it a sub-IP interrleaving problem.

--
Dean


On Thursday 14 March 2002 04:06 pm, Ben Campbell wrote:
> > Also a question: what if there is a single TCP connection between
> > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA.
> > In the meanwhile an INVITE for a voice call arrives at the proxy
> > to be delivered to the same UA. Is it possible to interleave it
> > between the TCP segments carrying MESSAGE, or does MESSAGE block
> > the transport?
>
> That could be a problem in some scenarios. I think the real answer,
> though, is to limit the MESSAGE requests to some reasonable size. We
> have had talk about standardizing methods to send large data by
> reference--I think any real application that sends messages
> containing much bigger than an average text IM will eventually need
> to go that route.
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From dean.willis@softarmor.com  Fri Mar 15 17:34:20 2002
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 RAA21803
	for ; Fri, 15 Mar 2002 17:34:19 -0500 (EST)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g2FMXKe03638;
	Fri, 15 Mar 2002 16:33:20 -0600
From: "Dean Willis" 
To: "'Ben Campbell'" ,
        "'Heil Franca Marcelo  ICM N PG U ID A 2'" 
Cc: 
Subject: RE: [Simple] Message Sizes (was Messages: Signaling, Data, or Theft)
Date: Fri, 15 Mar 2002 16:33:03 -0600
Message-ID: <045f01c1cc71$5f4c2100$bb036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: 
Content-Length: 1204
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: 

> > 1) We could add something like a duration indicator to the 302 
> > response, much like the TTL on DNS lookups. Or we could 
> contrive to do 
> > something at the DNS level, although this really doesn't 
> give us the 
> > message-type specific behavior potentially provided by the 
> LS in this 
> > example. Or we could rely on a "bounce" from question 2 to 
> let us know 
> > that the situation has changed and we need to reconsider the route.
> 
> Actually, the current SIP spec officially supports the use of 
> the Expires header in 302 responses for this purpose.

Ahah. 

So: By combining this with proxy-recursion on 302 responses, we have a
way to optimally target MESSAGES (and other traffic) to a particular end
point in such a way that proxies that MUS Tbe on the path are retained,
and those that don't have to be aren't.

All it takes are two rules:

1) A "proxy" node that does not want to stay in the loop 302 redirects
to the next hop, rather than proxying

2) A "proxy" node which proxies recurses on 301/302 responses and MAY
record-route if it wants to be in-the loop for all messages in a
resulting dialog

Actually, I think this solves a whole lot of things . . . 

--
Dean


From tanglih@cn.ibm.com  Sun Mar 17 22:15:14 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01270
	for ; Sun, 17 Mar 2002 22:13:14 -0500 (EST)
Received: from d23rh902.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g2I37ln330376
        for ; Mon, 18 Mar 2002 13:07:47 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2I3D2675346
	for ; Mon, 18 Mar 2002 14:13:03 +1100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Mon, 18 Mar 2002 10:35:47 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 18/03/2002 11:12:21
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 790
Subject: [Simple] We need a clear description of 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: 

Hi, all

We need a clear description of Presence, not just described as
online/offline/away... What is standardized in draft-ietf-impp-cpim-pidf-01
is not sufficient.

Presence is defined in RFC2778 as the communication state of a user. In
fact, it's a broad concept. The presence information can include following
aspects:
1. online/offline/away status,
2. user willingness: do not disturb/willing to chat,
3. available communication device status: open/close,
4. geography location,
5. presence history is also very useful
and more.

How can we descibe all this information in a unified way?

Your comments are welcome.


Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  tanglih@cn.ibm.com


From pkyzivat@cisco.com  Mon Mar 18 20:16:37 2002
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 UAA03197
	for ; Mon, 18 Mar 2002 20:16:37 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2J1G5k01593;
	Mon, 18 Mar 2002 20:16:06 -0500 (EST)
Received: from cisco.com (rtp-vpn1-482.cisco.com [10.82.225.226])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAG96826;
	Mon, 18 Mar 2002 20:18:56 -0500 (EST)
Message-ID: <3C96913C.F810071D@cisco.com>
Date: Mon, 18 Mar 2002 20:15:40 -0500
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: Li Hua Tang 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] We need a clear description of Presence
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2292
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: 

Comments below.

	Paul

Li Hua Tang wrote:
> 
> Hi, all
> 
> We need a clear description of Presence, not just described as
> online/offline/away... What is standardized in draft-ietf-impp-cpim-pidf-01
> is not sufficient.
> 
> Presence is defined in RFC2778 as the communication state of a user. In
> fact, it's a broad concept. The presence information can include following
> aspects:
> 1. online/offline/away status,
> 2. user willingness: do not disturb/willing to chat,
> 3. available communication device status: open/close,
> 4. geography location,
> 5. presence history is also very useful
> and more.
> 
> How can we descibe all this information in a unified way?

It hasn't been discussed much, but there is considerable overlap between
presence and callerprefs. Callerprefs provides a way to qualify the
Contact addresses registered for an address-of-record. For instance,
the media, classes of calls, and priorities that are acceptable. Also
q-values permit prioritizing among alternative contact addresses, so that
for instance voicemail can be ranked higher than direct connection for
some types of calls.

This hasn't been integrated into the default presence document, but
it ought to be. The presence document as currently defined has the
contact addresses and the q-values, but not the other qualifying information.

This added information can be used to describe many, but not all,of the 
things mentioned above. For instance, suppose you have a device capable of 
both voice and chat. Normally you might register as:

	REGISTER ...
	...
	Contact: sip:your@device;media="audio/*,message/*"

If you receive a voice call, and want to indicate unavailability for voice, 
but continued availability to chat, you might reregister:

	REGISTER ...
	...
	Contact: sip:your@device;media="message/*"

They you would update this again at completion of your call when
you are again willing to receive voice.

Given a suitable linkage between the registrar and presence server,
then these changes ought to be reported as presence changes.

This isn't a complete solution to the issues you describe. It can be
viewed as extra capability that reduces the problem, or it may be
considered as making the problem larger. I think it is essential that
presence and callerprefs be harmonized.

From jdrosen@dynamicsoft.com  Tue Mar 19 00:15:12 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03915
	for ; Tue, 19 Mar 2002 00:15:11 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.86])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2J5EuTE010176;
	Tue, 19 Mar 2002 00:14:56 -0500 (EST)
Message-ID: <3C96C912.6D26FF18@dynamicsoft.com>
Date: Tue, 19 Mar 2002 00:13:54 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Li Hua Tang , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] We need a clear description of Presence
References: <3C96913C.F810071D@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2047
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: 


Paul Kyzivat wrote:
> 

> If you receive a voice call, and want to indicate unavailability for
> voice,
> but continued availability to chat, you might reregister:
> 
>         REGISTER ...
>         ...
>         Contact: sip:your@device;media="message/*"
> 
> They you would update this again at completion of your call when
> you are again willing to receive voice.
> 
> Given a suitable linkage between the registrar and presence server,
> then these changes ought to be reported as presence changes.
> 
> This isn't a complete solution to the issues you describe. It can be
> viewed as extra capability that reduces the problem, or it may be
> considered as making the problem larger. I think it is essential that
> presence and callerprefs be harmonized.

I think you want the presence document to be able to support the
expressiveness which caller preferences has. However, I don't think you
want a user to explicitly set their presence by registrations. Rather,
the presence server would compose their registrations (including caller
prefs data), with their uploaded presence docs (which provide explicit
presence indications), to generate a final composed presence document.

Using caller prefs for the UA to explicitly set presence is bad, since
it depends on the UA knowing the policy of the presence server in its
construction of the presence doc. By being explicit, i..e, "set my
presence to available", that problem is avoided.

That said, I think much work is needed to build upon PIDF and add status
values and other parameters needed for a more expressive system. At the
very least, we need some statuses for IM. I would really like to see
such a work item picked up by SIMPLE.

Thanks,
Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From Markus.Isomaki@nokia.com  Tue Mar 19 00:15:38 2002
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 AAA03920
	for ; Tue, 19 Mar 2002 00:15:36 -0500 (EST)
From: Markus.Isomaki@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 g2J5EtZ02581
	for ; Tue, 19 Mar 2002 07:14:55 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 19 Mar 2002 07:14:43 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 19 Mar 2002 07:14:43 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do   wit message threading)
Date: Tue, 19 Mar 2002 07:14:42 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Messages: Signaling, Data, or Theft (Wassomethingto do   wit message threading)
Thread-Index: AcHMVdK21bg/IsS/TGyKXdCK+61JgQCdLkpQ
To: , ,
        , 
Cc: 
X-OriginalArrivalTime: 19 Mar 2002 05:14:43.0129 (UTC) FILETIME=[FA6C1290:01C1CF04]
Content-Length: 3149
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id AAA03920
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: 

Hi,

Right. And fortunately there are some sub-IP mechanisms in place to separate RTP and SIP and even do L2 fragmentation so that a large SIP IP-packet won't block RTP. Mid-call signaling was also one of the reasons to start developing SigComp.

What I'm more worried is the prioritization of SIP vs. SIP, i.e. handling of call setup signaling compared to messaging or presence or whatever SIP will be used next for. That logic needs to reside in the application layer, as for e.g. DiffServ classifiers all SIP looks the same. 

The list of reasons is this:
- SIP call setup budget with manyfolks and resource reservation over low-capacity wireless will be tight even with SigComp. It must be possible to separate this traffic from other SIP traffic, e.g. messages.
- This is especially true when thinking about emergency services. 
- Some operators want to separate call setup traffic from other traffic also for charging reasons (no volume-based charging for "signaling"). This is done by having counters on SIP traffic. It must be possible to separate SIP call setup signaling from other SIP traffic for this reason as well.

I'm not sure if there is anything to standardize for SIP though. In the simplest case this could be seen as a policy issue for SIP UAs and proxies, so that they would mark different SIP packets differently (for example with different DS codepoints). These just need to be configured right in proxies and routers. So this may be an additional(?) requirement to SIP device configuration. But maybe someone has a clearer view.

Markus



   


> -----Original Message-----
> From: ext Dean Willis [mailto:dwillis@dynamicsoft.com]
> Sent: 15 March, 2002 21:16
> To: Ben Campbell; Isomaki Markus (NRC/Helsinki); hgs@cs.columbia.edu;
> mhammer@cisco.com
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Messages: Signaling, Data, or Theft
> (Wassomethingto do wit message threading)
> 
> 
> 
> Actually, if you do the math, you find that something like 64 
> bytes is 
> the largest message size whose serialization delay doesn't 
> break RTP at 
> 9600 bps. That makes it a sub-IP interrleaving problem.
> 
> --
> Dean
> 
> 
> On Thursday 14 March 2002 04:06 pm, Ben Campbell wrote:
> > > Also a question: what if there is a single TCP connection between
> > > UA and proxy. Proxy starts to transmit a large MESSAGE toward UA.
> > > In the meanwhile an INVITE for a voice call arrives at the proxy
> > > to be delivered to the same UA. Is it possible to interleave it
> > > between the TCP segments carrying MESSAGE, or does MESSAGE block
> > > the transport?
> >
> > That could be a problem in some scenarios. I think the real answer,
> > though, is to limit the MESSAGE requests to some reasonable size. We
> > have had talk about standardizing methods to send large data by
> > reference--I think any real application that sends messages
> > containing much bigger than an average text IM will eventually need
> > to go that route.
> >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From dgboyer@avaya.com  Tue Mar 19 09:32:44 2002
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05647
	for ; Tue, 19 Mar 2002 09:32:44 -0500 (EST)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16767
	for ; Tue, 19 Mar 2002 09:30:18 -0500 (EST)
Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16753
	for ; Tue, 19 Mar 2002 09:30:18 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] We need a clear description of Presence
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 19 Mar 2002 09:32:26 -0500
Message-ID: <8CA1128D59AD27429985B397118CEDDF78FEFE@nj7460avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] We need a clear description of Presence
Thread-Index: AcHPBXOcIZ/EK3gJRkKf+NiYpeKsYAATKgWw
From: "Boyer, David G (Dave)" 
To: "Jonathan Rosenberg" ,
        "Paul Kyzivat" 
Cc: "Li Hua Tang" , 
Content-Length: 2245
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA05647
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: 


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, March 19, 2002 12:14 AM
> To: Paul Kyzivat
> Cc: Li Hua Tang; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] We need a clear description of Presence
> 
> 
> 
> 
> Paul Kyzivat wrote:
> > 
> 
> > If you receive a voice call, and want to indicate unavailability for
> > voice,
> > but continued availability to chat, you might reregister:
> > 
> >         REGISTER ...
> >         ...
> >         Contact: sip:your@device;media="message/*"
> > 
> > They you would update this again at completion of your call when
> > you are again willing to receive voice.
> > 
> > Given a suitable linkage between the registrar and presence server,
> > then these changes ought to be reported as presence changes.

Presence changes should also be reportable by non-communicative devices -
video motion detection/face recognition, blue-tooth node registration,
etc.  Desiring presence information about someone does not necessarily imply
the desire to communicate with that person.
> > 
...
> 
> Using caller prefs for the UA to explicitly set presence is bad, since
> it depends on the UA knowing the policy of the presence server in its
> construction of the presence doc. By being explicit, i..e, "set my
> presence to available", that problem is avoided.

Shouldn't availability be expressible on a per user basis, not just
globally?
> 
> That said, I think much work is needed to build upon PIDF and 
> add status
> values and other parameters needed for a more expressive 
> system. At the
> very least, we need some statuses for IM. I would really like to see
> such a work item picked up by SIMPLE.
> 
> Thanks,
> Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From pkyzivat@cisco.com  Tue Mar 19 11:18:15 2002
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 LAA06006
	for ; Tue, 19 Mar 2002 11:18:14 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2JGHgs28216;
	Tue, 19 Mar 2002 11:17:42 -0500 (EST)
Received: from cisco.com (rtp-vpn2-576.cisco.com [10.82.242.64])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH00185;
	Tue, 19 Mar 2002 11:20:32 -0500 (EST)
Message-ID: <3C97648B.D46001EB@cisco.com>
Date: Tue, 19 Mar 2002 11:17:15 -0500
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: Li Hua Tang , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] We need a clear description of Presence
References: <3C96913C.F810071D@cisco.com> <3C96C912.6D26FF18@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1725
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: 

Jonathan Rosenberg wrote:
> 
> I think you want the presence document to be able to support the
> expressiveness which caller preferences has. However, I don't think you
> want a user to explicitly set their presence by registrations. Rather,
> the presence server would compose their registrations (including caller
> prefs data), with their uploaded presence docs (which provide explicit
> presence indications), to generate a final composed presence document.
> 
> Using caller prefs for the UA to explicitly set presence is bad, since
> it depends on the UA knowing the policy of the presence server in its
> construction of the presence doc. By being explicit, i..e, "set my
> presence to available", that problem is avoided.

Since there is no standard for uploading a presence document,
a UA *always* has to know the policy the presence server uses to
construct or acquire the presence document. Knowing that the presence
server will construct the document in a way consistent with the registration
is no worse than knowing that it gets it by ftp upload to a particular
file, or by payload in a REGISTER message.

Use of callerprefs requires registration. Requiring that the UA also
format and upload a presence document each time simply adds to the
burden on both it and the servers - at least in the case that presence
server and registrar are colocated. It also can result in divergence
of the two states, through error or negligence.

> 
> That said, I think much work is needed to build upon PIDF and add status
> values and other parameters needed for a more expressive system. At the
> very least, we need some statuses for IM. I would really like to see
> such a work item picked up by SIMPLE.

agreed.

	Paul

From pkyzivat@cisco.com  Tue Mar 19 11:37:38 2002
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 LAA06103
	for ; Tue, 19 Mar 2002 11:37:38 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2JGb6700981;
	Tue, 19 Mar 2002 11:37:06 -0500 (EST)
Received: from cisco.com (rtp-vpn2-576.cisco.com [10.82.242.64])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAH00388;
	Tue, 19 Mar 2002 11:39:57 -0500 (EST)
Message-ID: <3C976918.D9B16082@cisco.com>
Date: Tue, 19 Mar 2002 11:36:40 -0500
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: "Boyer, David G (Dave)" 
CC: Jonathan Rosenberg ,
        Li Hua Tang , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] We need a clear description of Presence
References: <8CA1128D59AD27429985B397118CEDDF78FEFE@nj7460avexu1.global.avaya.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2401
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: 

comments below.

	Paul

"Boyer, David G (Dave)" wrote:
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Tuesday, March 19, 2002 12:14 AM
> > To: Paul Kyzivat
> > Cc: Li Hua Tang; simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] We need a clear description of Presence
> >
> >
> >
> >
> > Paul Kyzivat wrote:
> > >
> >
> > > If you receive a voice call, and want to indicate unavailability for
> > > voice,
> > > but continued availability to chat, you might reregister:
> > >
> > >         REGISTER ...
> > >         ...
> > >         Contact: sip:your@device;media="message/*"
> > >
> > > They you would update this again at completion of your call when
> > > you are again willing to receive voice.
> > >
> > > Given a suitable linkage between the registrar and presence server,
> > > then these changes ought to be reported as presence changes.
> 
> Presence changes should also be reportable by non-communicative devices -
> video motion detection/face recognition, blue-tooth node registration,
> etc.  Desiring presence information about someone does not necessarily imply
> the desire to communicate with that person.

I don't understand your point. Devices must be communicative in some way
to report presence. Are you saying that some devices that don't do sip
may want to update presence?

I am not suggesting that registration must be the *only* way of doing so.

But I am suggesting that a *subset* of the presence information is in
1:1 correspondence to registration information, and that *one way*
for that information to get into the presence document is via the registrar.

I realize this is controversial, but I believe that it is *best* for
the presence server to get that portion of the presence document content
from the registrar. This is analogous to expecting a proxy server and
registrar to communicate via an unspecified location service.

> > Using caller prefs for the UA to explicitly set presence is bad, since
> > it depends on the UA knowing the policy of the presence server in its
> > construction of the presence doc. By being explicit, i..e, "set my
> > presence to available", that problem is avoided.
> 
> Shouldn't availability be expressible on a per user basis, not just
> globally?

Again I don't understand your point. ("Not just globally?" ???)
                                           ****

From dgboyer@avaya.com  Tue Mar 19 11:44:58 2002
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06157
	for ; Tue, 19 Mar 2002 11:44:57 -0500 (EST)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18078
	for ; Tue, 19 Mar 2002 11:42:32 -0500 (EST)
Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18065
	for ; Tue, 19 Mar 2002 11:42:32 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] We need a clear description of Presence
Date: Tue, 19 Mar 2002 11:44:40 -0500
Message-ID: <8CA1128D59AD27429985B397118CEDDF391249@nj7460avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] We need a clear description of Presence
Thread-Index: AcHPZF4bEdI3Jp4UQtWUvaiJddf4/wAAApgA
From: "Boyer, David G (Dave)" 
To: "Paul Kyzivat" 
Cc: "Jonathan Rosenberg" ,
        "Li Hua Tang" , 
Content-Length: 3773
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA06157
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: 


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, March 19, 2002 11:37 AM
> To: Boyer, David G (Dave)
> Cc: Jonathan Rosenberg; Li Hua Tang; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] We need a clear description of Presence
> 
> 
> comments below.
> 
> 	Paul
> 
> "Boyer, David G (Dave)" wrote:
> > 
> > > -----Original Message-----
> > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > > Sent: Tuesday, March 19, 2002 12:14 AM
> > > To: Paul Kyzivat
> > > Cc: Li Hua Tang; simple@mailman.dynamicsoft.com
> > > Subject: Re: [Simple] We need a clear description of Presence
> > >
> > >
> > >
> > >
> > > Paul Kyzivat wrote:
> > > >
> > >
> > > > If you receive a voice call, and want to indicate 
> unavailability for
> > > > voice,
> > > > but continued availability to chat, you might reregister:
> > > >
> > > >         REGISTER ...
> > > >         ...
> > > >         Contact: sip:your@device;media="message/*"
> > > >
> > > > They you would update this again at completion of your call when
> > > > you are again willing to receive voice.
> > > >
> > > > Given a suitable linkage between the registrar and 
> presence server,
> > > > then these changes ought to be reported as presence changes.
> > 
> > Presence changes should also be reportable by 
> non-communicative devices -
> > video motion detection/face recognition, blue-tooth node 
> registration,
> > etc.  Desiring presence information about someone does not 
> necessarily imply
> > the desire to communicate with that person.
> 
> I don't understand your point. Devices must be communicative 
> in some way
> to report presence. Are you saying that some devices that don't do sip
> may want to update presence?

Definitly - biometric devices are not capable of communications
but can indicate very accurate presence information, surveillance
cameras can be used to uniquely identify individuals, etc.  This
presence information should also be recorded in a Presence server.
Perhaps this is out side the scope of SIP, but it is not outside
the scope of a presence service.
> 
> I am not suggesting that registration must be the *only* way 
> of doing so.
> 
> But I am suggesting that a *subset* of the presence information is in
> 1:1 correspondence to registration information, and that *one way*
> for that information to get into the presence document is via 
> the registrar.
> 
> I realize this is controversial, but I believe that it is *best* for
> the presence server to get that portion of the presence 
> document content
> from the registrar. This is analogous to expecting a proxy server and
> registrar to communicate via an unspecified location service.

This is fine for SIP devices.  Perhaps the answer is that the other
devices need to communicate to the Presence server via a different means,
although it seems that using the SIP registration method would make sense
for these non-standard devices.
> 
> > > Using caller prefs for the UA to explicitly set presence 
> is bad, since
> > > it depends on the UA knowing the policy of the presence 
> server in its
> > > construction of the presence doc. By being explicit, i..e, "set my
> > > presence to available", that problem is avoided.
> > 
> > Shouldn't availability be expressible on a per user basis, not just
> > globally?
> 
> Again I don't understand your point. ("Not just globally?" ???)
>                                            ****
The way Johnathan worded setting availability above sounded to me that 
availability is something you toggle on and off.  Availability can be
more complex than that.  I am available to Johnathan through IM only,
I am available to Paul via cell-phone and IM, etc.  Perhaps I misunderstood
Johnathans comment.

Dave

From zmolek@avaya.com  Tue Mar 19 12:08:56 2002
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06294
	for ; Tue, 19 Mar 2002 12:08:55 -0500 (EST)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16395
	for ; Tue, 19 Mar 2002 12:06:31 -0500 (EST)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16380
	for ; Tue, 19 Mar 2002 12:06:31 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] We need a clear description of Presence
Date: Tue, 19 Mar 2002 10:08:42 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] We need a clear description of Presence
Thread-Index: AcHPZF4bEdI3Jp4UQtWUvaiJddf4/wAAApgAAACgHQA=
From: "Zmolek, Andrew (Andrew)" 
To: "Boyer, David G (Dave)" ,
        "Paul Kyzivat" 
Cc: "Jonathan Rosenberg" ,
        "Li Hua Tang" , 
Content-Length: 2195
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA06294
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: 

Comments inline...

>> I don't understand your point. Devices must be communicative 
>> in some way to report presence. Are you saying that some 
>> devices that don't do sip may want to update presence?
>
> Definitly - biometric devices are not capable of communications
> but can indicate very accurate presence information, 
> surveillance cameras can be used to uniquely identify 
> individuals, etc.  This presence information should also be 
> recorded in a Presence server. Perhaps this is out side the 
> scope of SIP, but it is not outside the scope of a presence 
> service.

This is a key point. Primary sensors are connected to analysis systems, which probably don't provide presence. But those systems create intelligence that is useful and a potential feed into a presence system. This notion of multiple feeds from analysis system makes the notion of presence via a single document seem overly constrained, as there are probably going to be many feeds to the presence service. 

Plus, exposure of availability is a different matter (and isn't likely to be the complete "document" of information known to the presence service and could be a complete lie for my local telemarketer, for instance)

>> I am not suggesting that registration must be the *only* way 
>> of doing so.
>> 
>> But I am suggesting that a *subset* of the presence information is in
>> 1:1 correspondence to registration information, and that *one way*
>> for that information to get into the presence document is via 
>> the registrar.
>> 
>> I realize this is controversial, but I believe that it is *best* for
>> the presence server to get that portion of the presence 
>> document content from the registrar. This is analogous to expecting 
>> a proxy server and registrar to communicate via an unspecified 
>> location service.

Again, there are going to be lots of feeds from lots of sources. Registrars will form a key part of the resulting data, but there isn't any point in constraining the notion of presence by excluding other valid feeds.

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            zmolek@avaya.com 
              +1 720 444 4001 




From jdrosen@dynamicsoft.com  Tue Mar 19 21:43:27 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08195
	for ; Tue, 19 Mar 2002 21:43:27 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.147])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2K2hVTE011439;
	Tue, 19 Mar 2002 21:43:31 -0500 (EST)
Message-ID: <3C97F70D.C43EDE93@dynamicsoft.com>
Date: Tue, 19 Mar 2002 21:42:21 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Boyer, David G (Dave)" 
CC: Paul Kyzivat , Li Hua Tang ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] We need a clear description of Presence
References: <8CA1128D59AD27429985B397118CEDDF391249@nj7460avexu1.global.avaya.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2285
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: 


"Boyer, David G (Dave)" wrote:
> 

> > I don't understand your point. Devices must be communicative
> > in some way
> > to report presence. Are you saying that some devices that don't do sip
> > may want to update presence?
> 
> Definitly - biometric devices are not capable of communications
> but can indicate very accurate presence information, surveillance
> cameras can be used to uniquely identify individuals, etc.  This
> presence information should also be recorded in a Presence server.
> Perhaps this is out side the scope of SIP, but it is not outside
> the scope of a presence service.

It is within the scope of a SIP based presence system to report presence
that includes that kind of information. It is fundamental to the model
we have been advocating that a presence document is a composition of
data sources from potentially disparate devices. In this case, it is
very unlikely that the presence data arrives to the server via SIP, but
it doesn't have to in order to be distributed by a SIP based presence
server. 

> > > Shouldn't availability be expressible on a per user basis, not just
> > > globally?
> >
> > Again I don't understand your point. ("Not just globally?" ???)
> >                                            ****
> The way Johnathan worded setting availability above sounded to me that
> availability is something you toggle on and off.  Availability can be
> more complex than that.  I am available to Johnathan through IM only,
> I am available to Paul via cell-phone and IM, etc.  Perhaps I
> misunderstood
> Johnathans comment.

I wasn't saying it was global. I was merely saying that a user should be
allowed to explicitly ask the server to set particular aspects of a
presence document, and the way it does this is by publishing such a
document to the server. Whether the presence server uses the values it
provides is a matter of local policy, but at least the server knows the
intent of the user.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Tue Mar 19 21:45:16 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08221
	for ; Tue, 19 Mar 2002 21:45:16 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.147])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2K2jETE011442;
	Tue, 19 Mar 2002 21:45:14 -0500 (EST)
Message-ID: <3C97F779.22A9247D@dynamicsoft.com>
Date: Tue, 19 Mar 2002 21:44:09 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: "Boyer, David G (Dave)" ,
        Li Hua Tang , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] We need a clear description of Presence
References: <3C976918.D9B16082@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1190
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: 


Paul Kyzivat wrote:
> 

> But I am suggesting that a *subset* of the presence information is in
> 1:1 correspondence to registration information, and that *one way*
> for that information to get into the presence document is via the
> registrar.
> 
> I realize this is controversial, but I believe that it is *best* for
> the presence server to get that portion of the presence document content
> from the registrar. This is analogous to expecting a proxy server and
> registrar to communicate via an unspecified location service.

I don't want to ever dictate policy on how a PA composes a presence
document. Its that simple. All we can do is provide ways for a user to
explicitly indicate what they want. How the PA collects that information
and generates a composite presence document MUST be permitted to be
entirely a matter of local policy.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From tony@att.com  Tue Mar 19 23:48:15 2002
Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08652
	for ; Tue, 19 Mar 2002 23:48:15 -0500 (EST)
Received: from maillennium.att.com ([135.25.114.99])
	by almso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g2K4lK901548
	for ; Tue, 19 Mar 2002 23:47:21 -0500 (EST)
Received: from att.com ([135.210.75.30])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020320044719gw1001rqp9e>
          (Authid: tony);
          Wed, 20 Mar 2002 04:47:19 +0000
Message-ID: <3C981275.F3228127@att.com>
Date: Tue, 19 Mar 2002 23:39:17 -0500
From: Tony Hansen 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: SIMPLE list 
Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again)
References: <20020206000526.76476.qmail@web11608.mail.yahoo.com> <3C7C0CCC.D6EBC1BC@att.com> <3C885FAF.A82A3222@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3447
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: 

Discussion on the components document is scheduled for the last 45
minutes of the SIMPLE slot. While we can probably get some things agreed
on during that time, there are probably a number of issues that won't
be. Since face to face is so much higher bandwidth than email, are
people interested in continuing a discussion of the components document
and IM/P service profiles either over dinner on Wednesday after SIMPLE,
over lunch on Thursday, or over dinner on Thursday?

	Tony Hansen
	tony@att.com

Jonathan Rosenberg wrote:
> 
> Tony Hansen wrote:
> >
> > Here are some ideas on how this could play out within the IETF.
> >
> > One of the documents being put out in the SIP WG is SIP Call Flow
> > Examples. It shows how the SIP protocol should be used in an IP
> > Telephony service.
> >
> > Another effort in the IETF is the Voice Profile for Internet Messaging
> > (VPIM) working group. That group has been figuring out how to do voice
> > messaging (for voice mailboxes) using existing protocols, such as SMTP
> > and IMAP. Where the existing protocols were lacking, they also worked on
> > filling in the gaps, either within the VPIM WG or in conjunction with
> > other working groups (e.g., imap-ext). Note: the VPIM WG was originally
> > formed due to input from an external organization, the EMA, but the work
> > has all been done here in the IETF.
> >
> > The problem we're facing here in SIMPLE seems to be in the same
> > category, and the solution may be similar. It appears that what is
> > required is a profile for an instant messaging service saying how it
> > should pull together the different piece parts to form a coherent whole.
> 
> Well, there are two parts.
> 
> Part one, is to specify the pieces, and to make sure they are all there.
> Part two, is to specify an architecture that puts them together as a
> whole.
> 
> Part one is definitely an IETF activity. We really have most of the
> pieces, and the few that remain, are easy. I have written an I-D on this
> subject, which discusess the pieces needed for a consumer IM/buddy-list
> application:
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-components-00.txt
> 
> I'd really like to get group input on whether there is
> interest/agreement on which aspects of my proposed plan.
> 
> The second piece, part two, is to specify an architecture that pulls it
> all together. If such a thing were done here, it would need to be
> informational to say the least. There is precendent for publication of
> informational architecture docs generated by other bodies (the DCS
> architecture). I think SOMEONE needs to put this together, that is for
> certain. If no one else is stepping up to the plate, I'd prefer IETF to
> nobody, thats for sure.
> 
> >
> > I'm convinced we can solve this problem. Getting feedback from the
> > industry is absolutely useful in the process, but I think the work needs
> > to happen here, in the IETF. And I'm willing to work on it.
> >
> > Comments? Should something like this go on the SIMPLE agenda for
> > Minneapolis?
> 
> I'd like to discuss it, yes.
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Wed Mar 20 00:35:29 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08827
	for ; Wed, 20 Mar 2002 00:35:29 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.114])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2K5ZdTE011516;
	Wed, 20 Mar 2002 00:35:39 -0500 (EST)
Message-ID: <3C981F6D.9EB2863C@dynamicsoft.com>
Date: Wed, 20 Mar 2002 00:34:37 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-winfo-format-01.txt
References: <3C88EBAF.A823F391@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1696
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: 


Paul Kyzivat wrote:
> 
> I have a question about:
> 
>         duration: The amount of time, in seconds, that the subscription
>              was in the previous state before transitioning to the state
>              described in the status parameter.
> 
> I can see how this can be useful when receiving a notification
> containing only changes. But it is less useful when doing a fetch, or
> when receiving the initial notification
> following a subscription. 

Agreed.

> In those cases there is no way to know how
> long the subscription has been in the current state.

Good point.

> 
> One solution would be to provide two values. But I think it is
> sufficient to provide only the duration in the current state. This is
> clearly the value needed when you have
> no prior information about the subscription. If you have a prior value,
> then the total time in the prior state, if desired, can be computed
> using the prior duration value,
> the time the last notification was sent, and the time the current
> notification was sent.

Seems reasonable. Of course, now the opposite problem occurs.
Notifications sent on state changes will always have a duration of zero,
providing meaningless information. So, either the fetch and
subscribe-triggered notifies have useless durations, or the
event-triggered notifications have useless durations....

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Wed Mar 20 01:39:26 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09056
	for ; Wed, 20 Mar 2002 01:39:26 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.114])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2K6dZTE011539;
	Wed, 20 Mar 2002 01:39:36 -0500 (EST)
Message-ID: <3C982E67.E7FC1F9A@dynamicsoft.com>
Date: Wed, 20 Mar 2002 01:38:31 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Torrey Searle 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Date header and offline messages
References: <3C88A1A5.8020102@indigosw.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 940
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: 


Torrey Searle wrote:
> 
> in 9.5 it seems to allow for a store and forward mechanism with sip
> messaging.
> Am I correct in assuming that the Date header a forwared delayed request
> 
> must have an updated date header to avoid being blocked by the replay
> prevention described in 11.3?

Good point.

I would prefer that the date header NOT be updated (as this would
invalidate the signature). Rather, the text in the message draft add
some words that indicate that a late IM may not indicate an attack, and
then give some guidelines about what it would mean, and when its OK, and
when its not.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From seancolson@yahoo.com  Wed Mar 20 09:34:17 2002
Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA10518
	for ; Wed, 20 Mar 2002 09:34:16 -0500 (EST)
Message-ID: <20020320143323.41489.qmail@web11603.mail.yahoo.com>
Received: from [166.63.189.85] by web11603.mail.yahoo.com via HTTP; Wed, 20 Mar 2002 06:33:23 PST
Date: Wed, 20 Mar 2002 06:33:23 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] IM Service Profile? (was Re: Mobility of Buddy List, Again)
To: Tony Hansen , SIMPLE list 
In-Reply-To: <3C981275.F3228127@att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 848
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: 

This sounds like a good thing. How about Wednesday 
evening over dinner before the plenary?

/sean

--- Tony Hansen  wrote:
> Discussion on the components document is scheduled
> for the last 45
> minutes of the SIMPLE slot. While we can probably
> get some things agreed
> on during that time, there are probably a number of
> issues that won't
> be. Since face to face is so much higher bandwidth
> than email, are
> people interested in continuing a discussion of the
> components document
> and IM/P service profiles either over dinner on
> Wednesday after SIMPLE,
> over lunch on Thursday, or over dinner on Thursday?
> 
> 	Tony Hansen
> 	tony@att.com

=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

From bcampbell@dynamicsoft.com  Wed Mar 20 10:19:19 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10687
	for ; Wed, 20 Mar 2002 10:19:18 -0500 (EST)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g2KFI2d54591;
	Wed, 20 Mar 2002 09:18:02 -0600 (CST)
From: "Ben Campbell" 
To: "Paul Kyzivat" ,
        "Boyer, David G \(Dave\)" 
Cc: "Jonathan Rosenberg" ,
        "Li Hua Tang" , 
Subject: RE: [Simple] We need a clear description of Presence
Date: Wed, 20 Mar 2002 09:18:02 -0600
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
In-Reply-To: <3C976918.D9B16082@cisco.com>
Importance: Normal
Content-Length: 1070
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: 


> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Paul Kyzivat
> Sent: Tuesday, March 19, 2002 10:37 AM
> To: Boyer, David G (Dave)
> Cc: Jonathan Rosenberg; Li Hua Tang; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] We need a clear description of Presence
> But I am suggesting that a *subset* of the presence information is in
> 1:1 correspondence to registration information, and that *one way*
> for that information to get into the presence document is via the
> registrar.
>
> I realize this is controversial, but I believe that it is *best* for
> the presence server to get that portion of the presence document content
> from the registrar. This is analogous to expecting a proxy server and
> registrar to communicate via an unspecified location service.
>

That is a perfectly acceptable and useful presence service to build with
SIMPLE. But SIMPLE must not mandate that particular service. I can envision
SIMPLE related services with no registrar involved at all.


From Markus.Isomaki@nokia.com  Fri Mar 22 00:56:34 2002
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 AAA17719
	for ; Fri, 22 Mar 2002 00:56:33 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2M5trt29175
	for ; Fri, 22 Mar 2002 07:55:53 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 22 Mar 2002 07:55:40 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 22 Mar 2002 07:55:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 22 Mar 2002 07:55:39 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] We need a clear description of Presence
Thread-Index: AcHQJ5QHlPfqDQopQ36JiPExrAY8hgBPESjg
To: 
Cc: 
X-OriginalArrivalTime: 22 Mar 2002 05:55:40.0200 (UTC) FILETIME=[32309A80:01C1D166]
Content-Length: 1440
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id AAA17719
Subject: [Simple] Requirements to SIMPLE components continuation
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: 

Hi,

It seems that work based on the proposals in the SIMPLE components draft is getting started within SIMPLE and SIPPING.

In addition to those mentioned in the draft and presentation, I would like to propose the following requirements:

- Private messages in a multiparty centralized conference with messaging sessions. This means that if a number of participants are in a conference/chat via a centralized server it should be possible to send a private (i.e. only shown to the selected recipient, not the whole conference) message between two participants. It must be possible to correlate it somehow on the ongoing conference, so that it can be shown correctly on recipient's chat window, meaning that a completely separate one-shot message is not the right solution.

- Showing different presence information to different Watchers. This means that e.g. for some Watchers the status of IMs is just "closed", while for others something more accurate could be shown. So, basically the presence doc. is formed based on who is asking for it, and there must be a way for the presentity to control this.

- Presence subscription filtering. This means that a Watcher should be able to presence to the changes in certain _part_ of the presence info. If other parts change, NOTIFYs are not generated.

Do these seem like reasonable requirements? Are there already solutions for these, or should they be included in the starting work?

Markus  

From Gryphon@startcorp.com  Sun Mar 24 18:45:57 2002
Received: from a-start.start.syd ([203.111.107.186])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29634
	for ; Sun, 24 Mar 2002 18:45:55 -0500 (EST)
content-class: urn:content-classes:message
Subject: RE: [Simple] Requirements to SIMPLE components continuation
Date: Mon, 25 Mar 2002 10:44:40 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <0EB17E926D035949A09C0F4CD5E9D77302F234@a-start.start.syd>
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] We need a clear description of Presence
Thread-Index: AcHQJ5QHlPfqDQopQ36JiPExrAY8hgBPESjgAIoWxDA=
From: "Stephen Gryphon" 
To: 
Content-Length: 2237
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA29634
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: 

> -----Original Message-----
> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> - Private messages in a multiparty centralized conference 
> with messaging sessions. This means that if a number of 
> participants are in a conference/chat via a centralized 
> server it should be possible to send a private (i.e. only 
> shown to the selected recipient, not the whole conference) 
> message between two participants. It must be possible to 
> correlate it somehow on the ongoing conference, so that it 
> can be shown correctly on recipient's chat window, meaning 
> that a completely separate one-shot message is not the right solution.

The central conferencing model we are basing our work on is similar to a mailing list, where when a message is posted the Request-URI and the To field are both the conference/address, with the From address as the speaker. This is then delivered to the conference server.

The conference server then distributes the MESSAGE to all participants, setting the Request-URI to the correct value for each recipient (but keeping the To field as the conference name). [NB. It is not unusual for the To and Request-URI to not match, e.g. when proxying.]

We are also assuming that threading is based on the Call-ID (or the In-Reply-To) field.

This means that (a) A MESSAGE could be sent directly to the recipients address, or (b) A MESSAGE could be sent to the conference Request-URI, but with the To field as the indended individual recipient (this lets the conference server know to only forward to that participant).

In both cases the Call-ID should be set appropriately (this also lets the conference server know which conference the private message is part of). It is the Call-ID (or In-Reply-To) that determines the threading and should be used by the UI to display the message in context (as per the Components draft).

In short:
- The UI should correlate the conference based on the Call-ID.
- Separate one-shot should then be displayed correctly, if it can get through and passes all security checks.
- For a complete record the MESSAGE can still go via the conference server by using an appropriate Request-URI (and Call-ID), with the intended To field.

Hope this helps.

- Sly

From petkos@diamond.cs.columbia.edu  Sun Mar 24 19:51:59 2002
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 TAA29869
	for ; Sun, 24 Mar 2002 19:51:59 -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 TAA00754
	for ; Sun, 24 Mar 2002 19:51:05 -0500 (EST)
Received: from diamond.cs.columbia.edu (localhost [127.0.0.1])
	by diamond.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2P0p5AT024570
	for ; Sun, 24 Mar 2002 19:51:05 -0500 (EST)
Received: (from petkos@localhost)
	by diamond.cs.columbia.edu (8.12.1/8.12.1/Submit) id g2P0p46V024568
	for simple@mailman.dynamicsoft.com; Sun, 24 Mar 2002 19:51:04 -0500 (EST)
From: "Petri K. Koskelainen" 
Message-Id: <200203250051.g2P0p46V024568@diamond.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Sun, 24 Mar 2002 19:51:04 -0500 (EST)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 367
Subject: [Simple] Requirements to SIMPLE components continuation
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: 

Hi,

Since each member in a conference has a different call-id for
SIP signaling (with the server), how can you send one-shot MESSAGE 
directly to recipient and use call-id information to indicate
that this refers to existing conference?

The sender does not know about call-id's between server 
and recipient, and there isn't any conference wide call-id.



Petri


From Gryphon@startcorp.com  Sun Mar 24 23:52:35 2002
Received: from a-start.start.syd ([203.111.107.186])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00625
	for ; Sun, 24 Mar 2002 23:52:34 -0500 (EST)
content-class: urn:content-classes:message
Subject: RE: [Simple] Requirements to SIMPLE components continuation
Date: Mon, 25 Mar 2002 15:51:20 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <0EB17E926D035949A09C0F4CD5E9D77302F235@a-start.start.syd>
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Requirements to SIMPLE components continuation
Thread-Index: AcHTlzbFamhe2qkASoeK+IOkvEn1aAAGSSaA
From: "Stephen Gryphon" 
To: 
Content-Length: 2287
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id XAA00625
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: 

> -----Original Message-----
> From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu]
> Since each member in a conference has a different call-id for
> SIP signaling (with the server), how can you send one-shot MESSAGE 
> directly to recipient and use call-id information to indicate
> that this refers to existing conference?
> The sender does not know about call-id's between server 
> and recipient, and there isn't any conference wide call-id.

I don't think one-shot MESSAGE's are a good idea, but, depend on the implementation assumptions, it may work anyway. 

Using the conference server for passing the private MESSAGE (in-session) makes a lot more sense.

Assuming the setup is per a MESSAGE session, with the signalling channels only setting up the conference session. Clients will then have a separate media channel for content MESSAGE's, which could share a common call-id. 

One-shot MESSAGE may work if the sender uses this common session Call-ID, and the recipient just threads all with the same Call-ID (irrespective of other headers). [I still don't like it though.]

==

Not sure what others think, the  assumptions of a common Call-ID for the conference session makes good sense to me. In particular, when the conference server receives a MESSAGE the only thing it needs to change when broadcasting is the Request-URI.

Whilst the message delivered to conference participants may then seem a little strange (e.g. it is neither To them, nor From anyone they are in direct contact with), this is not much different from when you are receiving from a proxy.

It also makes the processing by the conference server very quick (rewriting To, From, and Call-ID for each outgoing connection would be extra work). 

Keeping the From address also allows the UI to display the author of each message (this was a problem with draft-khartabil-sip-conferencing-00, there was no way for the recipient to identify, and hence display, the author of a message).

In fact, if you embed the conference identifier in the conference Request-URI, then you could actually stream incoming messages straight to outbound pipes, if you wanted a particularly fast conference server.

I have some samples of the message flow, if anyone is interested.

==

Can anyone see any problems?


- Sly

From pkyzivat@cisco.com  Mon Mar 25 14:22:47 2002
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 OAA02092
	for ; Mon, 25 Mar 2002 14:22:47 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2PJM4I25542;
	Mon, 25 Mar 2002 14:22: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 AAH34728;
	Mon, 25 Mar 2002 14:24:53 -0500 (EST)
Message-ID: <3C9F78C1.B4FC31C1@cisco.com>
Date: Mon, 25 Mar 2002 14:21:37 -0500
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: Markus.Isomaki@nokia.com
CC: simple@mailman.dynamicsoft.com, jdrosen@dynamicsoft.com
Subject: Re: [Simple] Requirements to SIMPLE components continuation
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2740
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: 


Markus.Isomaki@nokia.com wrote:
> 
> Hi,
> 
> It seems that work based on the proposals in the SIMPLE components draft is getting started within SIMPLE and SIPPING.
> 
> In addition to those mentioned in the draft and presentation, I would like to propose the following requirements:
> 
> - Private messages in a multiparty centralized conference with messaging sessions. This means that if a number of participants are in a conference/chat via a centralized server it should be possible to send a private (i.e. only shown to the selected recipient, not the whole conference) message between two participants. It must be possible to correlate it somehow on the ongoing conference, so that it can be shown correctly on recipient's chat window, meaning that a completely separate one-shot message is not the right solution.

I question this. Why should private side messages involve the conference as a whole at all? This seems to violate the notion of the conference. And, why would I trust that
a message delivered through a conference server will only been seen by my intended recipient? My willingness to trust this will probably vary depending upon how the
conference is implemented. (For instance if the moderator of the conference is not my intended recipient.)

I would prefer that the side conversations be entirely independent the shared conferencing components - via page-mode MESSAGE exchanges, or via a separate MESSAGE session.

(This doesn't prohibit the GUI tying these together, based on In-Reply-To headers or the like.)

> 
> - Showing different presence information to different Watchers. This means that e.g. for some Watchers the status of IMs is just "closed", while for others something more accurate could be shown. So, basically the presence doc. is formed based on who is asking for it, and there must be a way for the presentity to control this.

This may be probematic because of scaling problems. If a separate view has to be computed for every watcher then it may not be possible to use use presence servers to
distribute presence state to the masses.

However, it might make sense to access-control the various presence attributes, so that only certain people are permitted to see detailed information while a larger set of
people may see more general information. This would fit in well with filtering - requests for too much detail might fail for some users, where they would succeed when using
a suitable filter. (Or else, the required filter could be automatically applied to avoid refusing the request.)

> 
> - Presence subscription filtering. This means that a Watcher should be able to presence to the changes in certain _part_ of the presence info. If other parts change, NOTIFYs are not generated.

From Markus.Isomaki@nokia.com  Mon Mar 25 16:18:29 2002
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 QAA02495
	for ; Mon, 25 Mar 2002 16:18:27 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2PLHjs08446
	for ; Mon, 25 Mar 2002 23:17:45 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 25 Mar 2002 23:17:30 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 25 Mar 2002 23:17:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Requirements to SIMPLE components continuation
Date: Mon, 25 Mar 2002 23:17:30 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Requirements to SIMPLE components continuation
Thread-Index: AcHUMlRzjirprzDoQOGmkNHwjjiVLgADc1gA
To: 
Cc: , 
X-OriginalArrivalTime: 25 Mar 2002 21:17:30.0676 (UTC) FILETIME=[790AB740:01C1D442]
Content-Length: 4835
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id QAA02495
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: 

Paul Kyzivat wrote:
>
> I would prefer that the side conversations be entirely 
> independent the shared conferencing components - via 
> page-mode MESSAGE exchanges, or via a separate MESSAGE session.
> 
> (This doesn't prohibit the GUI tying these together, based on 
> In-Reply-To headers or the like.)

I guess the requirement itself is still fine. It should be possible for the recipient to show the "private" message in the right context, like in the same window where the chat conference is ongoing (as in Netmeeting). If a separate page-mode MESSAGE with In-Reply-To etc. is able to do this, it is probably OK. 

> However, it might make sense to access-control the various 
> presence attributes, so that only certain people are 
> permitted to see detailed information while a larger set of
> people may see more general information. This would fit in 
> well with filtering - requests for too much detail might fail 
> for some users, where they would succeed when using
> a suitable filter. (Or else, the required filter could be 
> automatically applied to avoid refusing the request.)

Yes, I think this should be possible. There should be at least two levels, e.g. "public" (everyone) and "private" (my buddies or co-workers etc.). Even this might be too complicated for most users to set, but for some it could be useful. 

I think the filtering and other access rules should be such, that also the access to geographical location info could be controlled by them (as part of presence or as a separate event package?), if at all possible. GEOPRIV probably has some quite strict privacy requirements related to that.

Markus 

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: 25 March, 2002 21:22
> To: Isomaki Markus (NRC/Helsinki)
> Cc: simple@mailman.dynamicsoft.com; jdrosen@dynamicsoft.com
> Subject: Re: [Simple] Requirements to SIMPLE components continuation
> 
> 
> 
> 
> Markus.Isomaki@nokia.com wrote:
> > 
> > Hi,
> > 
> > It seems that work based on the proposals in the SIMPLE 
> components draft is getting started within SIMPLE and SIPPING.
> > 
> > In addition to those mentioned in the draft and 
> presentation, I would like to propose the following requirements:
> > 
> > - Private messages in a multiparty centralized conference 
> with messaging sessions. This means that if a number of 
> participants are in a conference/chat via a centralized 
> server it should be possible to send a private (i.e. only 
> shown to the selected recipient, not the whole conference) 
> message between two participants. It must be possible to 
> correlate it somehow on the ongoing conference, so that it 
> can be shown correctly on recipient's chat window, meaning 
> that a completely separate one-shot message is not the right solution.
> 
> I question this. Why should private side messages involve the 
> conference as a whole at all? This seems to violate the 
> notion of the conference. And, why would I trust that
> a message delivered through a conference server will only 
> been seen by my intended recipient? My willingness to trust 
> this will probably vary depending upon how the
> conference is implemented. (For instance if the moderator of 
> the conference is not my intended recipient.)
> 
> I would prefer that the side conversations be entirely 
> independent the shared conferencing components - via 
> page-mode MESSAGE exchanges, or via a separate MESSAGE session.
> 
> (This doesn't prohibit the GUI tying these together, based on 
> In-Reply-To headers or the like.)
> 
> > 
> > - Showing different presence information to different 
> Watchers. This means that e.g. for some Watchers the status 
> of IMs is just "closed", while for others something more 
> accurate could be shown. So, basically the presence doc. is 
> formed based on who is asking for it, and there must be a way 
> for the presentity to control this.
> 
> This may be probematic because of scaling problems. If a 
> separate view has to be computed for every watcher then it 
> may not be possible to use use presence servers to
> distribute presence state to the masses.
> 
> However, it might make sense to access-control the various 
> presence attributes, so that only certain people are 
> permitted to see detailed information while a larger set of
> people may see more general information. This would fit in 
> well with filtering - requests for too much detail might fail 
> for some users, where they would succeed when using
> a suitable filter. (Or else, the required filter could be 
> automatically applied to avoid refusing the request.)
> 
> > 
> > - Presence subscription filtering. This means that a 
> Watcher should be able to presence to the changes in certain 
> _part_ of the presence info. If other parts change, NOTIFYs 
> are not generated.
> 

From mikko.lonnfors@nokia.com  Tue Mar 26 08:57:18 2002
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 IAA05518
	for ; Tue, 26 Mar 2002 08:57:17 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2QDtcG06396
	for ; Tue, 26 Mar 2002 15:55:38 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Tue, 26 Mar 2002 15:56:19 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 26 Mar 2002 15:56:19 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 26 Mar 2002 15:56:16 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF104059@esebe004.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: question about winfo-package
Thread-Index: AcHUzf/zHlqJTITTTGiQ+ENINbIhPQ==
To: 
X-OriginalArrivalTime: 26 Mar 2002 13:56:19.0232 (UTC) FILETIME=[013EAA00:01C1D4CE]
Content-Length: 1000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA05518
Subject: [Simple] question about winfo-package
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: 

Hi,

One question about winfo-package. Lets say that winfo is applied to presence event-package
and that user A has subscribed his winfo. Now user B performs FETCH (SUBSCRIBE with expires: 0)
on user A's presence information. 

User B is authorized to subscribe A's presence:

First server send winfo NOTIFY to user A

  
     
       
     
   

then PS sends presence document to user B and immediately after that an other NOTIFY to user A with

  
     
       
     
   

Should user A receive these two NOTIFY message or can FETCH request be considered expired when it arrives
so that only the second winfo NOTIFY would be needed? 

regards
- Mikko

From tanglih@cn.ibm.com  Tue Mar 26 20:30:00 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07625;
	Tue, 26 Mar 2002 20:29:53 -0500 (EST)
Received: from d23rh902.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g2R1OG3450438;
        Wed, 27 Mar 2002 12:24:16 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2R1TW608284;
	Wed, 27 Mar 2002 12:29:32 +1100
Subject: Re: [Simple] question about winfo-package
To: mikko.lonnfors@nokia.com
Cc: simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Wed, 27 Mar 2002 09:29:02 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 27/03/2002 09:29:06
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 3493
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: 

Mikko,

My opinion about your question is as follows:

The motivating application for winfo package is presence authorization. If
User B is authorized to subscribe A's presence, as you said, generally
speaking the PS doesn't need to notify A of the B's subscription status for
authorization.

If the PS needs to notify A of this FETCH subscription, you may use the
'expiration' attribute of winfo foramt. Like this:
  
     
       
     
   
In this case, A should understanding that a FETCH subscription is
requested.
How about this way to solute your problem?

Will you attend the coming 10th SIPIT? I think We can discuss about this
question and more about SIMPLE face-to-face at that time.

Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  tanglih@cn.ibm.com


                                                                                                          
                    mikko.lonnfors@nokia.com                                                              
                    Sent by:                         To:                  
                    simple-admin@mailman.dynam       cc:                                                  
                    icsoft.com                       Subject:     [Simple] question about winfo-package   
                                                                                                          
                                                                                                          
                    2002-03-26 21:56                                                                      
                    Please respond to                                                                     
                    mikko.lonnfors                                                                        
                                                                                                          
                                                                                                          



Hi,

One question about winfo-package. Lets say that winfo is applied to
presence event-package
and that user A has subscribed his winfo. Now user B performs FETCH
(SUBSCRIBE with expires: 0)
on user A's presence information.

User B is authorized to subscribe A's presence:

First server send winfo NOTIFY to user A

  
     
       
     
   

then PS sends presence document to user B and immediately after that an
other NOTIFY to user A with

  
     
       
     
   

Should user A receive these two NOTIFY message or can FETCH request be
considered expired when it arrives
so that only the second winfo NOTIFY would be needed?

regards
- Mikko
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple





From mikko.lonnfors@nokia.com  Wed Mar 27 02:35:37 2002
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 CAA08754;
	Wed, 27 Mar 2002 02:35:36 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2R7Yss08419;
	Wed, 27 Mar 2002 09:34:54 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 27 Mar 2002 09:34:40 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 27 Mar 2002 09:34:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] question about winfo-package
Date: Wed, 27 Mar 2002 09:34:39 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF10405B@esebe004.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] question about winfo-package
Thread-Index: AcHVLthgpsZYzozJT+Gs4L7860OWhgALIFgw
To: 
Cc: , 
X-OriginalArrivalTime: 27 Mar 2002 07:34:40.0136 (UTC) FILETIME=[DABBA880:01C1D561]
Content-Length: 5658
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id CAA08754
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: 

Hi,

Some comments inline

-----Original Message-----
From: ext Li Hua Tang [mailto:tanglih@cn.ibm.com]
Sent: 27 March, 2002 03:29
To: Lonnfors Mikko (NRC/Helsinki)
Cc: simple@mailman.dynamicsoft.com; simple-admin@mailman.dynamicsoft.com
Subject: Re: [Simple] question about winfo-package



Mikko,

My opinion about your question is as follows:

The motivating application for winfo package is presence authorization. If
User B is authorized to subscribe A's presence, as you said, generally
speaking the PS doesn't need to notify A of the B's subscription status for
authorization.

I would still say that winfo is designed to enable presentity to get lists of watchers interested in their presence status.
This should happen regardless of the watcher's authorization status. Presence authorization may be the main motivation
to enable this functionality but not the only one.

If the PS needs to notify A of this FETCH subscription, you may use the
'expiration' attribute of winfo foramt. Like this:
  
     
       
     
   
In this case, A should understanding that a FETCH subscription is
requested.
How about this way to solute your problem?

I think there are some problems with this approach. I think that winfo  is designed to
signal changes in watchers subscription status i.e. signal the state to which a watcher has moved from previous state. 
In this case, as you said,  A should be able to understand that

    
       

means FETCH. This would mean special casing expiration="0". Otherwise, continuing this we could send

    
       

Now, should A be able to understand that B's subscription expires in 200 and after that time automatically do something
(for example delete B's entry from GUI)? But now if B refreshes his subscription A needs to get new winfo NOTIFY with new 
expiration timer despite that there has been no change in B's subscription status. 

We could take an other example. Let's say that B performs FETCH but has no authorization. Should A now get

   
       

I would say that sending 

   
       

would make more sense.

Any comments?

Will you attend the coming 10th SIPIT? I think We can discuss about this
question and more about SIMPLE face-to-face at that time.

I will probably not be able attend this one.

regards
- Mikko


Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  tanglih@cn.ibm.com


                                                                                                          
                    mikko.lonnfors@nokia.com                                                              
                    Sent by:                         To:                  
                    simple-admin@mailman.dynam       cc:                                                  
                    icsoft.com                       Subject:     [Simple] question about winfo-package   
                                                                                                          
                                                                                                          
                    2002-03-26 21:56                                                                      
                    Please respond to                                                                     
                    mikko.lonnfors                                                                        
                                                                                                          
                                                                                                          



Hi,

One question about winfo-package. Lets say that winfo is applied to
presence event-package
and that user A has subscribed his winfo. Now user B performs FETCH
(SUBSCRIBE with expires: 0)
on user A's presence information.

User B is authorized to subscribe A's presence:

First server send winfo NOTIFY to user A

  
     
       
     
   

then PS sends presence document to user B and immediately after that an
other NOTIFY to user A with

  
     
       
     
   

Should user A receive these two NOTIFY message or can FETCH request be
considered expired when it arrives
so that only the second winfo NOTIFY would be needed?

regards
- Mikko
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple





From mikko.lonnfors@nokia.com  Wed Mar 27 06:20:11 2002
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 GAA09453;
	Wed, 27 Mar 2002 06:20:10 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RBJUs06485;
	Wed, 27 Mar 2002 13:19:30 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 27 Mar 2002 13:19:16 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 27 Mar 2002 13:19:15 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] question about winfo-package (resend with revision marks)
Date: Wed, 27 Mar 2002 13:19:15 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0DCAED@esebe004.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] question about winfo-package
Thread-Index: AcHVLthgpsZYzozJT+Gs4L7860OWhgALIFgwAAldreA=
To: 
Cc: , 
X-OriginalArrivalTime: 27 Mar 2002 11:19:15.0697 (UTC) FILETIME=[3ACB1610:01C1D581]
Content-Length: 5930
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA09453
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: 

Sorry for resending this. Original main didn't have any revision marks.

Some comments inline inside .

-----Original Message-----
From: ext Li Hua Tang [mailto:tanglih@cn.ibm.com]
Sent: 27 March, 2002 03:29
To: Lonnfors Mikko (NRC/Helsinki)
Cc: simple@mailman.dynamicsoft.com; simple-admin@mailman.dynamicsoft.com
Subject: Re: [Simple] question about winfo-package



Mikko,

My opinion about your question is as follows:

The motivating application for winfo package is presence authorization. If
User B is authorized to subscribe A's presence, as you said, generally
speaking the PS doesn't need to notify A of the B's subscription status for
authorization.


I would still say that winfo is designed to enable presentity to get lists of watchers interested in their presence status.
This should happen regardless of the watcher's authorization status. Presence authorization may be the main motivation
to enable this functionality but not the only one.


If the PS needs to notify A of this FETCH subscription, you may use the
'expiration' attribute of winfo foramt. Like this:
  
     
       
     
   
In this case, A should understanding that a FETCH subscription is
requested.
How about this way to solute your problem?


I think there are some problems with this approach. I think that winfo  is designed to
signal changes in watchers subscription status i.e. signal the state to which a watcher has moved from previous state. 
In this case, as you said,  A should be able to understand that

    
       

means FETCH. This would mean special casing expiration="0". Otherwise, continuing this we could send

    
       

Now, should A be able to understand that B's subscription expires in 200 and after that time automatically do something
(for example delete B's entry from GUI)? But now if B refreshes his subscription A needs to get new winfo NOTIFY with new 
expiration timer despite that there has been no change in B's subscription status. 

We could take an other example. Let's say that B performs FETCH but has no authorization. Should A now get

   
       

I would say that sending 

   
       

would make more sense.

Any comments?


Will you attend the coming 10th SIPIT? I think We can discuss about this
question and more about SIMPLE face-to-face at that time.


I will probably not be able attend this one.

regards
- Mikko


Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  tanglih@cn.ibm.com


                                                                                                          
                    mikko.lonnfors@nokia.com                                                              
                    Sent by:                         To:                  
                    simple-admin@mailman.dynam       cc:                                                  
                    icsoft.com                       Subject:     [Simple] question about winfo-package   
                                                                                                          
                                                                                                          
                    2002-03-26 21:56                                                                      
                    Please respond to                                                                     
                    mikko.lonnfors                                                                        
                                                                                                          
                                                                                                          



Hi,

One question about winfo-package. Lets say that winfo is applied to
presence event-package
and that user A has subscribed his winfo. Now user B performs FETCH
(SUBSCRIBE with expires: 0)
on user A's presence information.

User B is authorized to subscribe A's presence:

First server send winfo NOTIFY to user A

  
     
       
     
   

then PS sends presence document to user B and immediately after that an
other NOTIFY to user A with

  
     
       
     
   

Should user A receive these two NOTIFY message or can FETCH request be
considered expired when it arrives
so that only the second winfo NOTIFY would be needed?

regards
- Mikko
_______________________________________________
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 aki.niemi@nokia.com  Wed Mar 27 10:13:10 2002
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 KAA10184
	for ; Wed, 27 Mar 2002 10:13:09 -0500 (EST)
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2RFCSs03557
	for ; Wed, 27 Mar 2002 17:12:28 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 27 Mar 2002 17:12:14 +0200
Received: from nokia.com ([172.21.148.60]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 27 Mar 2002 17:12:13 +0200
Message-ID: <3CA1E13D.6090602@nokia.com>
Date: Wed, 27 Mar 2002 17:11:57 +0200
From: "Niemi Aki (NET/Espoo)" 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020212
X-Accept-Language: en-us
MIME-Version: 1.0
To: ext Jonathan Rosenberg 
CC: simple@mailman.dynamicsoft.com
References: <3C96913C.F810071D@cisco.com> <3C96C912.6D26FF18@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Mar 2002 15:12:13.0849 (UTC) FILETIME=[C66BD090:01C1D5A1]
Content-Length: 585
Subject: [Simple] IM Session 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: 

Hi All,

Based on the discussions at the SIMPLE session at the IETF53 meeting, do 
we now have consensus that the approaches we're studying for the message 
transport inside an IM session are in fact:

	- SIP MESSAGE (with a specific "feature set")
	- IMSX (draft-mrose-simple-exchange-01.txt)

At least this was my impression from the presentations/discussions there.

I assume this means that IMTP as such is not considered any more, but an 
updated version of draft-ietf-simple-im-session-00.txt that addresses 
the issues Jonathan presented, may instead be expected?

Cheers,
Aki


From jdrosen@dynamicsoft.com  Wed Mar 27 12:47:48 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10712
	for ; Wed, 27 Mar 2002 12:47:48 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2RHlwTE016810;
	Wed, 27 Mar 2002 12:47:59 -0500 (EST)
Message-ID: <3CA2058A.A14C43CD@dynamicsoft.com>
Date: Wed, 27 Mar 2002 12:46:50 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema 
CC: "Niemi Aki (NET/Espoo)" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM Session Transport
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2247
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: 


Christian Huitema wrote:
> 
> > Based on the discussions at the SIMPLE session at the IETF53 meeting,
> do
> > we now have consensus that the approaches we're studying for the
> message
> > transport inside an IM session are in fact:
> >
> >       - SIP MESSAGE (with a specific "feature set")
> >       - IMSX (draft-mrose-simple-exchange-01.txt)
> >
> > At least this was my impression from the presentations/discussions
> there.
> >
> > I assume this means that IMTP as such is not considered any more, but
> an
> > updated version of draft-ietf-simple-im-session-00.txt that addresses
> > the issues Jonathan presented, may instead be expected?
> 
> That is definitely not my impression. I left the meeting feeling that
> the rough consensus was to use IMTP as the base solution, with the
> possibility of negotiating other transports in SDP as an option (e.g.
> IMSX). However, Jonathan promised to update the IMTP draft.

I think the difference between what Aki and you are saying is merely
pedantic. The basic idea behind my presentation was that, with the new
loose routing capabilities of bis, we would no longer need a separate
protocol for IM transport. We could use regular SIP, with the MESSAGE
method, in a particular usage scenario (pre-loaded routes with all tcp
transport, for example). Thus, there would no longer be IMTP as a
separate protocol, merely a draft on the usage of the MESSAGE method in
this modality. Indeed, I would argue that such a usage description
belongs in draft-ietf-simple-im-session.

My impression was that there was good consensus on this approach, but we
would need to have a concrete proposal to look at. I believe the chairs
allocated 4 weeks for the total time to write and submit the draft, and
compare it with IMSX. I also recall that there was general agreement
that other IM transport could always be negotiated as per the general
SIP/SDP capability.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From petkos@diamond.cs.columbia.edu  Wed Mar 27 14:03:01 2002
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 OAA10989
	for ; Wed, 27 Mar 2002 14:03:00 -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 OAA01543
	for ; Wed, 27 Mar 2002 14:02:06 -0500 (EST)
Received: from diamond.cs.columbia.edu (localhost [127.0.0.1])
	by diamond.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g2RJ26AT027532
	for ; Wed, 27 Mar 2002 14:02:06 -0500 (EST)
Received: (from petkos@localhost)
	by diamond.cs.columbia.edu (8.12.1/8.12.1/Submit) id g2RJ22Tj027530
	for simple@mailman.dynamicsoft.com; Wed, 27 Mar 2002 14:02:02 -0500 (EST)
From: "Petri K. Koskelainen" 
Message-Id: <200203271902.g2RJ22Tj027530@diamond.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Wed, 27 Mar 2002 14:02:02 -0500 (EST)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 870
Subject: [Simple] Requirements to SIMPLE components continuation
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: 

Stephen wrote:

> Assuming the setup is per a MESSAGE session, with the signalling 
> channels only setting up the conference session. Clients will 
> then have a separate media channel for 
> content MESSAGE's, which could share a common call-id.

Do you mean that all MESSAGEs in a conference session share same call-id?

This can be done, but then you cannot do message identification.
It is impossible to refer to a specific MESSAGE anymore,
and I think this is required. (Referring to a conference discussion 
based on call-id is useful, but you may also want to refer to 
a specific IM inside a conference, especially when replying).

New header (message-id) would solve that problem.
It might make sense to create also References header.
This would allow that In-Reply-To always refers to a session,
while References refers to a specific MESSAGE.


BR,
--
Petri

From sriramp@nortelnetworks.com  Wed Mar 27 17:19:34 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11651
	for ; Wed, 27 Mar 2002 17:19:34 -0500 (EST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2RMIab28448
	for ; Wed, 27 Mar 2002 16:18:36 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Mar 2002 16:18:38 -0600
Message-ID: 
From: "Sriram Parameswar"
To: simple@mailman.dynamicsoft.com
Date: Wed, 27 Mar 2002 16:18:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1D5DD.5798E090"
Content-Length: 3129
Subject: [Simple] (no subject)
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: 

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_01C1D5DD.5798E090
Content-Type: text/plain;
	charset="iso-8859-1"


Jonathan wrote:
<>
I think the difference between what Aki and you are saying is merely
pedantic. The basic idea behind my presentation was that, with the new loose
routing capabilities of bis, we would no longer need a separate protocol for
IM transport. We could use regular SIP, with the MESSAGE method, in a
particular usage scenario (pre-loaded routes with all tcp transport, for
example). Thus, there would no longer be IMTP as a separate protocol, merely
a draft on the usage of the MESSAGE method in this modality. Indeed, I would
argue that such a usage description belongs in draft-ietf-simple-im-session.

<>

Jonathan,

"Just a question for clarification" using 3GPP-speak. When you say we will
use loose routing and full blown SIP (as opposed to a limited header set
defined in IMTP), are you implying that the MESSAGE will now follow the
exact same route as the signaling? Also are the other SIP headers applicable
to MESSAGE now going to be allowed in IM sessions?

Thanks,

Sriram



------_=_NextPart_001_01C1D5DD.5798E090
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable













Jonathan wrote:

<<quote>>

I think the difference between what =
Aki and you are saying is merely pedantic. The basic idea behind my =
presentation was that, with the new loose routing capabilities of bis, =
we would no longer need a separate protocol for IM transport. We could =
use regular SIP, with the MESSAGE method, in a particular usage =
scenario (pre-loaded routes with all tcp transport, for example). Thus, =
there would no longer be IMTP as a separate protocol, merely a draft on =
the usage of the MESSAGE method in this modality. Indeed, I would argue =
that such a usage description belongs in draft-ietf-simple-im-session. =




<<endquote>>




Jonathan,




"Just a question for =
clarification" using 3GPP-speak. When you say we will use loose =
routing and full blown SIP (as opposed to a limited header set defined =
in IMTP), are you implying that the MESSAGE will now follow the exact =
same route as the signaling? Also are the other SIP headers applicable =
to MESSAGE now going to be allowed in IM sessions?



Thanks,




Sriram







------_=_NextPart_001_01C1D5DD.5798E090--

From HUITEMA@windows.microsoft.com  Wed Mar 27 11:25:28 2002
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 LAA10431
	for ; Wed, 27 Mar 2002 11:25:28 -0500 (EST)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 27 Mar 2002 08:24:32 -0800
Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Mar 2002 08:24:33 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 27 Mar 2002 08:24:31 -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.4905);
	 Wed, 27 Mar 2002 08:24:24 -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);
	 Wed, 27 Mar 2002 08:21:17 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] IM Session Transport
Date: Wed, 27 Mar 2002 08:21:17 -0800
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] IM Session Transport
thread-index: AcHVpQRz/l8A+1j2QKup7fCwakKfIAABo3wQ
From: "Christian Huitema" 
To: "Niemi Aki (NET/Espoo)" ,
        "ext Jonathan Rosenberg" 
Cc: 
X-OriginalArrivalTime: 27 Mar 2002 16:21:17.0780 (UTC) FILETIME=[6C658140:01C1D5AB]
Content-Length: 872
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA10431
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: 

> Based on the discussions at the SIMPLE session at the IETF53 meeting,
do
> we now have consensus that the approaches we're studying for the
message
> transport inside an IM session are in fact:
> 
> 	- SIP MESSAGE (with a specific "feature set")
> 	- IMSX (draft-mrose-simple-exchange-01.txt)
> 
> At least this was my impression from the presentations/discussions
there.
> 
> I assume this means that IMTP as such is not considered any more, but
an
> updated version of draft-ietf-simple-im-session-00.txt that addresses
> the issues Jonathan presented, may instead be expected?

That is definitely not my impression. I left the meeting feeling that
the rough consensus was to use IMTP as the base solution, with the
possibility of negotiating other transports in SDP as an option (e.g.
IMSX). However, Jonathan promised to update the IMTP draft.

-- Christian Huitema

From pkyzivat@cisco.com  Wed Mar 27 18:56:18 2002
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 SAA12002
	for ; Wed, 27 Mar 2002 18:56:17 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2RNtgi15030;
	Wed, 27 Mar 2002 18:55: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 AAH48830;
	Wed, 27 Mar 2002 18:58:36 -0500 (EST)
Message-ID: <3CA25BE7.53DE97BA@cisco.com>
Date: Wed, 27 Mar 2002 18:55:19 -0500
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: Christian Huitema 
CC: "Niemi Aki (NET/Espoo)" ,
        ext Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM Session Transport
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1363
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: 

My impression is consistent with what Jonathon posted - namely that IMTP should go away, to be replaced with a restricted profile of SIP. I thought there was general
agreement of the room on that, though I don't recall if there was a humm.

	Paul

Christian Huitema wrote:
> 
> > Based on the discussions at the SIMPLE session at the IETF53 meeting,
> do
> > we now have consensus that the approaches we're studying for the
> message
> > transport inside an IM session are in fact:
> >
> >       - SIP MESSAGE (with a specific "feature set")
> >       - IMSX (draft-mrose-simple-exchange-01.txt)
> >
> > At least this was my impression from the presentations/discussions
> there.
> >
> > I assume this means that IMTP as such is not considered any more, but
> an
> > updated version of draft-ietf-simple-im-session-00.txt that addresses
> > the issues Jonathan presented, may instead be expected?
> 
> That is definitely not my impression. I left the meeting feeling that
> the rough consensus was to use IMTP as the base solution, with the
> possibility of negotiating other transports in SDP as an option (e.g.
> IMSX). However, Jonathan promised to update the IMTP draft.
> 
> -- Christian Huitema
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From tony@att.com  Wed Mar 27 22:17:29 2002
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12624
	for ; Wed, 27 Mar 2002 22:17:29 -0500 (EST)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g2S3GY105105
	for ; Wed, 27 Mar 2002 21:16:34 -0600 (CST)
Received: from att.com ([135.210.112.72])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020328031634gw1001rp9pe>
          (Authid: tony);
          Thu, 28 Mar 2002 03:16:34 +0000
Message-ID: <3CA28B04.F5F647FA@att.com>
Date: Wed, 27 Mar 2002 22:16:20 -0500
From: Tony Hansen 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] IM Session Transport
References:  <3CA25BE7.53DE97BA@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1660
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: 

My notes say:

	IMTP was to be replaced by a profile of SIP

	after 4 weeks, both the IMTP replacement and IMSX would then be
	compared on their advantages and disadvantages

Yes, it was noted that more than one session mechanism could be defined.
But that was not used as a justification to make a decision for either
mechanism that day.

	Tony Hansen
	tony@att.com

Paul Kyzivat wrote:
> 
> My impression is consistent with what Jonathon posted - namely that
> IMTP should go away, to be replaced with a restricted profile of SIP.
> I thought there was general
> agreement of the room on that, though I don't recall if there was a humm.
> 
>         Paul
> 
> Christian Huitema wrote:
> >
> > > Based on the discussions at the SIMPLE session at the IETF53 meeting,
> > do
> > > we now have consensus that the approaches we're studying for the
> > message
> > > transport inside an IM session are in fact:
> > >
> > >       - SIP MESSAGE (with a specific "feature set")
> > >       - IMSX (draft-mrose-simple-exchange-01.txt)
> > >
> > > At least this was my impression from the presentations/discussions
> > there.
> > >
> > > I assume this means that IMTP as such is not considered any more, but
> > an
> > > updated version of draft-ietf-simple-im-session-00.txt that addresses
> > > the issues Jonathan presented, may instead be expected?
> >
> > That is definitely not my impression. I left the meeting feeling that
> > the rough consensus was to use IMTP as the base solution, with the
> > possibility of negotiating other transports in SDP as an option (e.g.
> > IMSX). However, Jonathan promised to update the IMTP draft.
> >
> > -- Christian Huitema

From sriramp@nortelnetworks.com  Thu Mar 28 10:12:51 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14833
	for ; Thu, 28 Mar 2002 10:12:51 -0500 (EST)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2SFBsk16348;
	Thu, 28 Mar 2002 09:11:54 -0600 (CST)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Mar 2002 09:11:59 -0600
Message-ID: 
From: "Sriram Parameswar"
To: "'simple@mailman.dynamicsoft.com'" 
Cc: "'jdrosen@dynamicsoft.com'" 
Date: Thu, 28 Mar 2002 09:11:57 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1D66A.E6E2DF70"
Content-Length: 3333
Subject: [Simple] IM Session Transport **Resend with subject**
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: 

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_01C1D66A.E6E2DF70
Content-Type: text/plain;
	charset="iso-8859-1"

*** Resend with  proper Subject***

> Jonathan wrote:
> <>
> I think the difference between what Aki and you are saying is merely
> pedantic. The basic idea behind my presentation was that, with the new
> loose routing capabilities of bis, we would no longer need a separate
> protocol for IM transport. We could use regular SIP, with the MESSAGE
> method, in a particular usage scenario (pre-loaded routes with all tcp
> transport, for example). Thus, there would no longer be IMTP as a separate
> protocol, merely a draft on the usage of the MESSAGE method in this
> modality. Indeed, I would argue that such a usage description belongs in
> draft-ietf-simple-im-session. 
> <>
> 
> Jonathan,
> 
> "Just a question for clarification" using 3GPP-speak. When you say we will
> use loose routing and full blown SIP (as opposed to a limited header set
> defined in IMTP), are you implying that the MESSAGE will now follow the
> exact same route as the signaling? Also are the other SIP headers
> applicable to MESSAGE now going to be allowed in IM sessions?
> 
> Thanks,
> 
> Sriram
> 
> 

------_=_NextPart_001_01C1D66A.E6E2DF70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






 IM Session Transport **Resend with subject**




*** Resend with  proper Subject***




Jonathan wrote:

<<quote>>

I think the difference between what =
Aki and you are saying is merely pedantic. The basic idea behind my =
presentation was that, with the new loose routing capabilities of bis, =
we would no longer need a separate protocol for IM transport. We could =
use regular SIP, with the MESSAGE method, in a particular usage =
scenario (pre-loaded routes with all tcp transport, for example). Thus, =
there would no longer be IMTP as a separate protocol, merely a draft on =
the usage of the MESSAGE method in this modality. Indeed, I would argue =
that such a usage description belongs in draft-ietf-simple-im-session. =




<<endquote>>




Jonathan,




"Just a question for =
clarification" using 3GPP-speak. When you say we will use loose =
routing and full blown SIP (as opposed to a limited header set defined =
in IMTP), are you implying that the MESSAGE will now follow the exact =
same route as the signaling? Also are the other SIP headers applicable =
to MESSAGE now going to be allowed in IM sessions?



Thanks,




Sriram







------_=_NextPart_001_01C1D66A.E6E2DF70--

From jdrosen@dynamicsoft.com  Thu Mar 28 17:28:40 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16229
	for ; Thu, 28 Mar 2002 17:28:40 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.79])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g2SMSnTE019322;
	Thu, 28 Mar 2002 17:28:49 -0500 (EST)
Message-ID: <3CA398DB.1D7D3CAB@dynamicsoft.com>
Date: Thu, 28 Mar 2002 17:27:39 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sriram Parameswar 
CC: "'simple@mailman.dynamicsoft.com'" 
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1697
Subject: [Simple] Re: IM Session Transport **Resend with subject**
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: 


Sriram Parameswar wrote:
> 
> *** Resend with  proper Subject***
> 
> Jonathan wrote:
> <>
> I think the difference between what Aki and you are saying is merely
> pedantic. The basic idea behind my presentation was that, with the new
> loose routing capabilities of bis, we would no longer need a separate
> protocol for IM transport. We could use regular SIP, with the MESSAGE
> method, in a particular usage scenario (pre-loaded routes with all tcp
> transport, for example). Thus, there would no longer be IMTP as a
> separate protocol, merely a draft on the usage of the MESSAGE method in
> this modality. Indeed, I would argue that such a usage description
> belongs in draft-ietf-simple-im-session.
> 
> <>
> 
> Jonathan,
> 
> "Just a question for clarification" using 3GPP-speak. When you say we
> will use loose routing and full blown SIP (as opposed to a limited
> header set defined in IMTP), are you implying that the MESSAGE will now
> follow the exact same route as the signaling? 

No. It can follow a different route.

> Also are the other SIP
> headers applicable to MESSAGE now going to be allowed in IM sessions?

Well, I would think that pretty much everything allowed in page mode
should also work for the session usage. In addition, since a context is
established, things like CSeq can be used to establish order.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Mon Apr  1 01:13:38 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00642
	for ; Mon, 1 Apr 2002 01:13:38 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.23])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g316DfTE022292;
	Mon, 1 Apr 2002 01:13:41 -0500 (EST)
Message-ID: <3CA7FA4F.4709C99@dynamicsoft.com>
Date: Mon, 01 Apr 2002 01:12:31 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mikko.lonnfors@nokia.com
CC: tanglih@cn.ibm.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] question about winfo-package (resend with revision marks)
References: <0C1353ABB1DEB74DB067ADFF749C4EEF0DCAED@esebe004.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3242
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: 


mikko.lonnfors@nokia.com wrote:
> 
> My opinion about your question is as follows:
> 
> The motivating application for winfo package is presence authorization.
> If
> User B is authorized to subscribe A's presence, as you said, generally
> speaking the PS doesn't need to notify A of the B's subscription status
> for
> authorization.
> 
> 
> I would still say that winfo is designed to enable presentity to get
> lists of watchers interested in their presence status.
> This should happen regardless of the watcher's authorization status.
> Presence authorization may be the main motivation
> to enable this functionality but not the only one.
> 

Yes. However, the decision about when to send NOTIFY for winfo is a
server decision; it can decide to not send two notifications in the case
of a fetch.


> 
> If the PS needs to notify A of this FETCH subscription, you may use the
> 'expiration' attribute of winfo foramt. Like this:
>   
>      
>                            event="subscribe" expiration="0"/>
>      
>    
> In this case, A should understanding that a FETCH subscription is
> requested.
> How about this way to solute your problem?
> 
> 
> I think there are some problems with this approach. I think that winfo
> is designed to
> signal changes in watchers subscription status i.e. signal the state to
> which a watcher has moved from previous state.
> In this case, as you said,  A should be able to understand that
> 
>     
>                            event="subscribe" expiration="0"/>
> 
> means FETCH. This would mean special casing expiration="0".

It only needs to be special cased if you are trying to explicitly
identify fetch requests. I see no reason to do that. The above
notification stands, by itself, as something reasonable. However, if you
want to send a single notification, you are probably better off sending
the one on the transition to terminated due to timeout.



> We could take an other example. Let's say that B performs FETCH but has
> no authorization. Should A now get
> 
>    
>                            event="subscribe" expiration="0"/>
> 
> I would say that sending
> 
>    
>                            event="subscribe"/>
> 
> would make more sense.

I agree that the second one makes more sense. The first is valid, of
course, but if you want to send just one notification, the latter is
more useful. Again, the decision about which state change notifications
to send is a matter of local policy.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From rsparks@dynamicsoft.com  Wed Apr  3 10:45:51 2002
Received: from crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12933
	for ; Wed, 3 Apr 2002 10:45:50 -0500 (EST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g33FmjA22926
	for ; Wed, 3 Apr 2002 09:48:45 -0600
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Date: 03 Apr 2002 09:43:48 -0600
Message-Id: <1017848628.1774.70.camel@dhcp222.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 10734
Subject: [Simple] Draft minutes from IETF53 meeting
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: 

Thanks to James Undery for taking the notes.

Please provide comments/corrections by Apr-8.

RjS
---------------------------------------------
SIMPLE 53rd IETF Salon C Mar-20-2002 15:30

Summary:

* The presence and watcher-info drafts are ready for nits review.
  Nits review will occur by Apr 5 and will proceed to WGLC.

* CPIM mapping effort is on track for June milestone

* Message session
  - Jonathan will provide a proposal for message sessions using
    normal SIP instead of IMTP, using loose routing to solve
    our earlier transport issues
  - Analysis of this proposal and IMXP for satisfying transport
    constraints and CPIM conformity will be provided within 4 weeks 
    (by Apr-22-2002).

* There is general agreement to work on providing solutions for the
  gaps identified in the simple-components draft. Some of the work
  would be done in SIMPLE, some in SIP/SIPPING, and some in a few
  other fora. The work to be done in SIMPLE will be identified and
  a proposed charter reflecting it will be submitted shortly.
    
Detailed Minutes (provided by James Undery)

Agenda Bash
+ No issues

Current deliverables
Apr 02 Presence to be submitted
Apr 02 watcher info to IESG
May 02 CPIM mapping to IESG
Jun 02 IM sessions to draft

SIMPLE issues - Jonathon Rosenberg
==================================

Jonathon presented the latest changes and upcoming work for a number of the 
drafts he is authoring.

Presence
- Alignment with new SIP and sip-events upcoming RFCs
- Removal of 3/4 of examples, removal of example PIDF content from remaining 
  examples
- Additional security, usage of SMIME and sips
- Recommended PUA implement this package, so network can subscribe
- Handle generally applicable issues such as IANA considerations and split 
  references into normative and non-normative categories.

winfo-format
- First-Subscribed will now indicate when the current state machine was first 
  created rather than the first subscription ever
- Removed notify address
- Added expiration params
- Removed most recent subscribed
- id and version attributes will be added after the blackout
Open issue: duration meaningless in fetch operation; Jonathon said to ignore it,
speakers from the floor agreed.

winfo-package
- Forking issue need to get subscriptions on all machines handling 
  subscriptions. Two methods were discussed forking or use existing dialog. 
  Which method to use depends on whether you are the presentity or not. i.e. A 
  pure watcher should use an existing dialog.
- IANA considerations
- State agent text will be rewritten

The proposed schedule for progressing these items was
Arrange nits reviews
Updated drafts by Apr 5 for WGLC
Submit to IESG

CPIM mapping draft open issues - Ben Campbell
=============================================

Ben commented there has been no discussion of this draft on lists. Ben then ran
through his list of open issues.

- How the URI is handled at the CPIM gateway. Two methods have been suggested
  - Direct scheme substitution
  - Leave as a gateway local mapping
  - Ben proposed taking the local policy approach. There was no objection.

- Update the draft to take account of changes in the latest SIP spec. e.g. 
  transaction IDs and dialog.

Christian Huitema observed that CPIM was designed to allow SMIME to cover the 
body, we should check we don't need to change the body at the gateway.

Ben agreed it was reasonable to meet charter deadline of May 02 provided the
work didn't have to account for message sessions (due June 02).

Message sessions
================

IMSX - Marshall Rose
--------------------

Marshall ran through a brief presentation of how IMSX and beep would work.
The steps involved were establish a TCP connection, tune BEEP session and then
exchange messages. Examples of the SDP involved were given showing privacy 
being tuned. 

At this point Christian noted the problems opening the TCP connection from a 
SDP negotiation; Rohan Mahy noted this is being worked on by mmusic in the 
comedia draft.

Marshall explained the tuning process negotiates authentication integrity 
privacy of the connection and how the initial message can be piggybacked with 
opening a IMSX channel. The simplicity of the scheme was then covered, i.e. 
it deals with no addressing, routing,middlebox, message formats or rendering. 
All these issues are handled by other protocols.

Cullen Jennings questioned if lack of middlebox issues was true. The answer 
from various people was this was a SIP/SDP/Midcom issue with the session setup.

Ben asked how large is a beep implementation? Marshall estimated that 20 
screens would cover the simplest implementation and more feature equated to 
more code. 

Jonathon noted SIP offers a lot of the negotiation feature making large 
portions of the BEEP/IMSX setup redundant. To which Marshall replied Beep
stays out of signaling and noted media protocols might want security
negotiation indirectly too.

Christian said attributes should be negotiated in the SDP to remove a level of 
indirection and that TLS handles negotiation of encryption integrity.

Henning Schulzrinne  commented multiple negotiations allows multiple new 
failures.
   
Question from the floor is binary data in beep transported as binary or base 
64 encoded, the reply was BEEP sends as binary.

A discussion of UDP and TCP transversing middleboxes followed, the consensus 
was this is a non-issue as it's the same for both proposals.

IMTP - Jonathon Rosenberg
-------------------------

Jonathon ran through the changes to the SIP spec that have greatly aided and
simplified this work. The main change to benefit IMTP was loose routing that
removed the need to make IMTP a subset of SIP ( by removing UDP, forking and 
redirection). The requirement now being loose routing can only use TCP hops.
Other changes relating to when a proxy can change the Request URI (i.e. only 
when it owns the domain in the Request URI) means using a FQDN or IP of host 
ensures no forking or redirection.

Henning asked if this would interference with normal signaling traffic. 
Jonathon replied that the element handling IMTP wouldn't necessarily be a 
signaling entity.

Henning also inquired if it is possible to open multiple TCP connections to 
handle messages. Jonathon replied yes, however because it's SHOULD to reuse
connection this would requires special code for this instance.

A speaker noted that IMTP was routed at application level yet should act like 
media. Jonathon drew attention to the problems of creating a bespoke protocol 
and how it'd probably be similar to IMTP anyway.

Christian noted we could stream CPIM over TCP as a minimum, however, we might 
need a proxy for logging etc. So IMTP is probably minimal for what we want.

Bob Penfield observed using Record-Routes seems overkill. Jonathon responded 
by saying it was likely that the loose route would be obtained separately 
routes in the signaling.

The chairs commented we have two concrete proposals neither absolutely flawed, 
we have the options pick one, pick both or chuck the problem. After a lengthy 
discussion on the two alternatives it was decided that both options would verify 
they conform to CPIM sanity checks and report this back within 4 weeks. Once 
this information was in the WG would be in a better position to pick one or 
proceed with both.

Andrew Zmolek added that picking one option now doesn't shut the door on the 
other, SIP can still use it later.

Alison Mankin noted that the proposals should also tidy loose ends as they 
checked for CPIM conformity.

Page vs Session modes and groups - Jonathon Rosenberg
=====================================================

Jonathon ran through talk showing groups existed in both modes, and 
characterised with mode was appropriate. Counter examples were discussed, and
Jonathon agreed group messaging covered a spectrum of modes and potentially 
mode transition would be useful.

Open issues were then covered including threading and ordering of group 
messages, group addressing and maximum message size for page mode (Bis 
will automatically use TCP for big messages)

Christian noted for security and page mode we want to use SMIME which could be
large due to the certificates. Jonathon replied session mode could use a 
session key rather than certs. Christian also noted this could be a bigger SIP
issue.

Jonathon finished with the biggest open issue, how much effort should we put 
in to adding group mode that is how to use the existing modes one, both or 
neither. Jonathon recommended for groups mode use session. Henning replied we 
don't need to make the decision, there are cases for both, we should give 
advice not make a choice. Dave Oran questioned this asking why would you 
need group in both, one reason for page mode is latency for the initial 
message, otherwise use session.

SIMPLE components - Jonathon Rosenberg
======================================

Jonathon gave a presentation of the network components that would be required
for a functional "buddy list" application, and suggested we ensure the tools 
were available to build this.

Jonathon identified a list of what's missing which included; data manipulation,
status notification (i.e. is typing notification), message storing, group 
conferencing, content sharing, threading, publication and glue for above. His
proposal was SIMPLE adopt "buddy list" application, adopt a "is typing" 
solution, adopt development of IM statuses for PIDF, finish message sessions 
(including threading), adopt data manipulation (i.e. list allow or deny), 
a presence publication document and an architecture document to put it all
together.

Henning commented that we have started group mode and threading. Jonathon
noted this is just for SIMPLE, the homeless items are message store (VPIM ?),
content vault manipulation (Webdav ?), conferencing floor control 
(needs a BOF ?) and profiles, user and group discovery (whois++). Lots of 
people agree this is needed, someone noted this homeless stuff needs to go 
somewhere. Sean Olsen asked if we can expand the charter to encompass this 
or pass it out to other WGs. Henning noted another conferencing adhoc had
occurred and were going to produce requirements within 3 weeks.

It was agreed to hold an adhoc meeting to continue this discussion

Markus commented this stuff is needed by 3GPP who will be looking at it 
after release 5. Someone else observed AOL has trademarked buddylist,
Jonathon agreed to change the name he used.

A hum on adopting the work and discussing what it means was held with 
strong consensus for continuing this work.

Keith Drage requested we don't set priorities until input from external groups 
has had a chance to come in.




From rsparks@dynamicsoft.com  Wed Apr  3 11:37:00 2002
Received: from crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13114
	for ; Wed, 3 Apr 2002 11:36:59 -0500 (EST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g33GdtA23069
	for ; Wed, 3 Apr 2002 10:39:55 -0600
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Date: 03 Apr 2002 10:34:42 -0600
Message-Id: <1017851682.1774.101.camel@dhcp222.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 14999
Subject: [Simple] notes from the SIMPLE components adhoc at IETF53
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: 

Thanks to Mary Barnes for taking these notes:
-------------------------------------------------
   
SIMPLE WG adhoc meeting 

Meeting was led by Jonathan Rosenberg with SIMPLE (Robert Sparks) and SIPPING (Rohan Mahy) WG chairs moderating the discussion for the items affecting their WGs.

Notetaker: Mary Barnes

Attendees:
Avshalom Houri avshalom@il.ibm.com
Sriram Parameswar sriramp@nortelnetworks.com
Sean Olson seancolson@yahoo.com
Tony Hansen tony@att.com
Andy Zmolek zmolek@avaya.com
Cullen Jennings fluffy@cisco.com
Robert Sparks rsparks@dynamicsoft.com
Jonathan Rosenberg jdrosen@dynamicsoft.com
Mary Barnes mbarnes@nortelnetworks.com
Adam Roach adam@dynamicsoft.com
Ben Campbell bcampbell@dynamicsoft.com
Mikko Lannfors mikko.lonnfors@nokia.com
Markus Isomaki markus.isomaki@nokia.com
Kristian Kiss kristian.kiss@nokia.com
Mark beckmann mark.beckmann@siemens.com
Georg mayer georg.mayer@icn.siemens.de
Paul Kyzivat pkyzivat@cisco.com
Wolfgang Beck beckw@t-systems.com
Mark Day markday@cisco.com
Hirogasu Sugano sugano.h@jp.fujitsu.com
Keith Drage drage@lucent.com
Dean Willis dean.willis@softarmor.com
James Undery james@ubiquity.com
Rohan Mahy rohan@cisco.com
Jon Peterson jon.Peterson@neustar.biz
Miguel Garcia Miguel.Garcia@ericsson.com
Sonia Garapaty sonia.garapaty@nortelnetworks.com
Jayshree bharatia jayshree@nortelnetworks.com
Pekka pessi pekka.pessi@nokia.com
Miguel A. Garcia Miguel.A.Garcia@ericsson.com



The purpose of the meeting was to work through the list of new work items that had been discussed during the main SIMPLE WG session on Wednesday (1530-1730) including a list  of 7 work items for SIMPLE WG, several work items proposed for SIPPING WG and 4 work items whose "home" needed to be determined. 

SIMPLE Work items:   
o Adopt a buddylist package as a work item
o Fairly well scoped. Package or Template package?
o Subscribe to list rather than members.
o Nothing to do with list manipulation. 
 
o Adopt development of a solution for is-typing:
o What is it?
* Is this related to key events in SIPPING 
* Presence data field format, BUT there's a correlation issue. 
*  Needs to be scoped to IM.  IN the middle of message, it's another stream.
* Dialog associated? 

Discussion: 
* It's a session associated with presence
* Mark: getting semantics confused with transport.
* Ben: disagree that it's presence since it's associated with a conversation. Could do that with "brainless" filtering.
* Rohan: It shouldn't be keypress thing.
* Adam: Frequency with which they occur, even if it's presence Sub/Not would not be appropriate.
* Mark: At higher aspect, it's presence. 
* Jon P: We should have concept of presence towards an individual.  So, discounting this because it's a session. 
* Dean: It's "scoped" presence.
* Ben: Is this just for sessions? Or is it for paging in general? 
* Tony: Getting into solving the problem, thus discussion out of scope.
* Jonathan: trying to see if there is acknowledgement to tackle this one.
* Robert: Agreement that there is a requirement to solve this one.
* Rohan: list possibilities and work offline.
* Sean: Would like to scope it as availability and not just UI indication. 
* Keith: Only need to go into details if you think it might impact another WG. 
* Jonathan: If it can't be done with Sub/not, then there's a problem.
* Andrew: Plenty of examples where it is not a good idea for sub/not, but in general might want something else...hierarchy that does use sub/not.
* Avshalom: It's more of a type of session, must be coordinated.
* Ben: Objection to presence isn't an objection to sub/not.

Conclusion (as stated by Dean): agreement on "is preparing". Agreement that this is a session scoped activity. 


o Adopt development of a set of IM statuses for PIDF
o PIDF is supposed to be extensible.
o If you want a semantic, need to broaden set.

Discussion: 
* Sriram: 3GPP went crazy with this.  Agreed OPEN/CLOSE because it was the only 2 for which they could get agreement.
* Ben: same question came up in IMPP, so there may be a Q wrt WG.
* Jonathan: thinks it's okay to have this in SIMPLE since it's actively working.
* Miguel: Related to status of user at a particular time: Auth pending. 
* Jonathan: Yahoo for a while used such a state.  Not unreasonable.  It's complicated due to the scope of these things. Could be potentially unbound.  Doesn't mean you should do nothing.  Do we want a list of values that meet capabilities of existing deployed systems?  Do you need something more wireless specific. 
* Rohan: Time domain of "how closed are you?" granularity would be useful.
* Tony: These are all substates of open and closed.
* Adam: Defining beyond open/closed if you don't have specific semantics is problematic.  Need specific semantics for substates.  Leave reasons freeform.
* Ben: Agrees with Adam.  Perhaps a note - useful for a human.  Minimalist as possible for automata, otherwise infinite possibilities.
* Paul K: subordinate status is peered to contact.  But, status may apply to only one contact.
* Cullen: It's not open/closed; it's probabilistic. There will be lots of uncertainty.
* Jonathan: given that English phrase is not important; What are the semantics? 
* Mark: don't see this as a SIMPLE problem.  This is a home versus office status defining activity.  Not clear that you would manage to get consensus within SIMPLE on any given set of profiles.  Want a framework. 
* Rohan: Disagreeing with Ben's previous comment.  English phrases are useful.  These will need to be localized.  Need to be able to apply semantic meaning. 
* Ben: Addressing Mark's comment. Think we're in danger of trying to do way too much.  This should be left to service. Define minimal set for interop; more than we have now. 
* Sriram: Even if you set busy, you are closed.  Think Open/closed are only 2 interoperable cases.  Then have English phrases for others.
* Dean: 2 ways. 1. Semantic web model. 2. Leave it completely open. What is availability is presence which is dynamically updated. Really need basic minimum set with extension mechanism.
* Mark: Already did some of this in another draft (??) Open/ close were roots of XML trees.  Other messaging systems elaborate those.
* Jon P: Want to be able to build a real system.  Obligation should be to build states to go beyond IM service. John would like telephony services.  Suggests scope is IM at this time; thinks this should be beyond OPEN and Closed. 
* Avashalm:  Need a schema that can be "negotiated" between different systems.
* Sean: Haven't heard anything yet that don't boil down to Open and closed.  For interop, that's it. 
* Jonathan: Textual stuff works great until you realize consumer of presence may be automata (onhook/offhook versus open/closed).  Are there a  set of things for semantic understanding?
* Andrew: Automatic sensing.  Don't want to preclude giving different answers based on policy.  
* Ben: Process comment... aren't converging. 
* Jonathan: Is this a work item?   
* Rohan: Onhook/offhook - like tree idea.  
* Jon P: Want things like offline and idle - beyond open/close.
* Tony: Need some way of specifying substates.  Why are we doing this?  Filling in gaps so that folks building services know how to to this. Need to document ...
* Miguel: What are the requirements for this aspect?  Need to standardize semantic of substates.  Don't think this is the problem. Systems today solve this problem. Need to write down requirements. 
* James U: need a method to group open and closed.  Phone may be offhook, but message window may be open.  Presence in messaging appl needs to accurately reflect the combined states. 
* Adam: was arguing for a discrete number of states. 
* Jonathan: Is there a deliverable here?
* Mark: arguing against using Note to convey semantics.  Right question is that you need to trust that you're going to get from IMPP the capability for statuses, how are you going to use the toolkit?

Jonathan restating objective:
* Deliver an IM and presence system which is consumer grade buddylist app which mirrors existing systems.

Discussion:
* Sriram: at the beginning was trying to not combine IM and presence.
* Jonathan: trying to determine what to do when. 

An attempt by Robert to summarize "Agreement": have in existence a set which is bigger than open and closed.  

Discussion:
* Robert: do we want to build this set in SIMPLE or in IETF? 
* General consensus: want to do this in SIMPLE. 
* Robert: As Mark has suggested, they've tried to do this repeatedly. 
* Dean: get list from wireless village that they've submitted to 3G standards
* Adam: they're not semantically separate. 

An attempt by Jonathan to summarize work item: List, semantically oriented, limit to existing solutions.  Propose group to look at what's out there. 

Conclusion: Avashalom volunteered to take on this task.  Look at existing work in this area.  Mark can provide background info. 

o Finish message sessions (solving threading)
   Too fine grained to discuss now. 

o Adopt a work item to develop the needed data manipulations for buddylist, allow/deny
1. Model for block list, allow list: data schema and object manipulation. 
2. Harder part is the protocol: SOAP, ACAP, ..? 

Discussion: 
* Jonathan: difficulty would also be in authorization, authentication and other such security things. 
* Ben: is data exchange a part of this problem? 
* Jonathan: Yes, it falls out from this problem. 
* Sriram: had previously suggested the web.
* Jonathan: most general.  Simple components document says that.  Architecture doc could talk about this.  Markus would point out the inability for this to work in that environment. Need at a minimum a yes/no to approve a buddy. 
* Tony: the scope of what you can manipulate. Define the minimum set. 
* Cullen: must be defined at an API level that could be used by automata.
* Markus: is this generic group management?  Or is this specific to buddylists? 
* Robert: Need to decide this scope.  In this context, general is way too broad. 
* Jonathan: Everything as a group is another wireless village initiative.

Robert summarizing problem: We have learning to do about data models. Proposing to define a data model for buddylists, authorization lists (for presence and IM), accept/deny.  The issue of how you go about sending the data state in the network relates to the publish problem.  Is there anything we can do in SIMPLE to accelerate that problem. 

Discussion:
* Jonathan: the publish is listed as a simple work item.
* Rohan: didn't get what happened.  Thought the conclusion was for Ben to lead the effort on how to use http to bind...
* Ben: access control and authorization for data manipulation
* Sriram: trying to hook for foo with SIMPLE.  
* Jonathan: want unified view and not solve just one problem.

Robert again summarizing the problem: Able to express buddylists and authorization states and manipulation.  

Discussion:
* Jonathan: collect the results of this and solicit volunteers.
* Robert: buddylists and authorization should be do able.  Data manipulation is another issue. 

Conclusion: Ben will start working on this and Robert will work with Rohan on where this work belongs. 


o Presence document publication
o This was included as part of the previous work item. 
             
o Architecture doc (informational)
o Call flows, etc. 
o Big, long document

Discussion: 
* Adam: is this going to go through the process?
* Jonathan: apparently, this has been done before. Should do this here in SIMPLE.  Document should describe how to build a consumer grade appl. 
* Tony: BCP?
* Jonathan: implies more from standard's process, etc. 

Conclusion: consensus to work on that document. 

Proposed new work with SIPPING: 

1 and 2: Straight-forward - agreed 
3. Message confirmation package.   When you're going to something like a GW, want to propagate those backward.  This is similar to REFER use of NOTIFY.  

Discussion:
* Rohan: Message creates a dialog with implicit NOTIFY. 
* Adam: Are you proposing that whenever we send a message, we create a subscription? 
* Ben: The difference between this and REFER is the time scope.  There could be days for SMS. 
* Jonathan: for mobiles, do you have to re-subscribe when you power back on. 
* Robert: attempting to use sub/not , high probability of state drop.
* Rohan: define a new message type: confirmation body.
* Ben: also implies the need to signal for confirmation. 
* Jon P: per SMTP
* Rohan: or SIPFRAG

Conclusion: this would then be a SIMPLE WG item to develop the message. 

4. URI list - content and direction

Jonathan describing problem: Removal of feature in SIP EVENTS, where you could have a URI list. Used MIME type text-URI and this is experimental.  Could not have a reference in a normative RFC. With MIME registrations, it's extremely difficult to get timely resolution ... There is a bigger problem, in that this would be more useful for other messages. Problem: What is scope, lifetime, etc?   Thus, it was pulled out. BUT is a valid SIPPING work item.  

Discussion:
* Sean: lifetime issues are appl specific, thus solving this in a general manner might be problematic. 
* Rohan: How do you use content indirection for sub/not.
* Andrew: they did this for VPIM.  
* Ben: Process: URL only issue?  NOT dealing with how it gets there, etc. 
* Robert: mechanism in notify got killed because of mime type.  REFER put a URL in a header.  
* Adam: trying to point to things that would otherwise be in the body.
* Ben: things may operate on the body without headers
Conclusion:
* Sean and Adam: will write requirements

Continued discussion:
* Dean: Proxy turns stuff into URI list, then it belongs in a header and NOT in a body.
* Andrew: VPIM wants to do this.  Put in body and then extract to header. 

Homeless
o Message store 
o VPIM?
Jonathan overview: Notification of messages that you missed, message histories and store. 
Discussion: 
o Sounds like IMAP and mail.
o Jonathan: that's the proposal. 
o Rohan: to get to data, would need request history. 
Conclusion: Mary to talk to Glenn Parsons and determine if this is it. Rohan to talk to Glenn about coordinating this work between WGs. 

o Content vault 
o Webdav?

Problem description: Want to be able to put contact in, define access list, how you authenticate, lifetime issues and letting others fetch.

Discussion: 
o Cullen: Is "IT" one blob?  
o Jonathan: IT's a blob. 

o Jonathan: Motivated by filesharing appl.  "File transfer"

Conclusion: Sean/Sriram  will talk to someone in webdav and come up with requirements. 

o Floor control, conference policy
o Agreement in BoF to write requirements document. 
o Part of SIPPING right now. 

o Profiles, user and group discovery
Whois++
o Jonathan: find a group for whatever.  How do you do this across distributed domains?  Would work from a webpage in one domain.  
o Mark: IRTF problem.
o Tony: areas like that, provide a URI that points to where to do it.  
Conclusion: Need a liaison and make sure the right things are there. Who:??





From hgs@cs.columbia.edu  Wed Apr  3 22:51:53 2002
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 WAA14982
	for ; Wed, 3 Apr 2002 22:51:53 -0500 (EST)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA09419;
	Wed, 3 Apr 2002 22:50:55 -0500 (EST)
Received: from cs.columbia.edu (pool-138-89-41-36.mad.east.verizon.net [138.89.41.36])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g343omPm003003
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Wed, 3 Apr 2002 22:50:54 -0500 (EST)
Message-ID: <3CABCD9B.5E7EC028@cs.columbia.edu>
Date: Wed, 03 Apr 2002 22:50:51 -0500
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Sparks 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <1017851682.1774.101.camel@dhcp222.dfw.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2316
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: 

A general remark: where possible, I believe it would be helpful to
abstract from the specific event type and see if the operation also
applies to other SIP events. This seems likely to further increase the
leverage that the general SIP event mechanism, as opposed to a specific
presence mechanism, offers. In particular, I believe that conferencing
might later be able to make good use of these generalizations.

> 
> SIMPLE Work items:
> o Adopt a buddylist package as a work item
> o Fairly well scoped. Package or Template package?
> o Subscribe to list rather than members.
> o Nothing to do with list manipulation.

For example, buddy lists are, abstracted, just a list of events and SIP
URIs that I subscribe to. It should be treated as such. 

> * Jonathan: Textual stuff works great until you realize consumer of presence may be automata (onhook/offhook versus open/closed).  Are there a  set of things for semantic understanding?

Comment: The important thing is a unique name (plus maybe an English
phrase) so that I can program behavior. It's not terribly important that
there is a legal definition as to what state of mind and body each word
entails. For example, it's sufficient if within a community of interest
"ttsio" state means "talking to student in office".

Also, priorities are a good example: "Urgent" doesn't have a distinct
meaning ("the building's on fire" vs. "I need this a week from now"),
but it's still useful.

> o Adopt a work item to develop the needed data manipulations for buddylist, allow/deny
> 1. Model for block list, allow list: data schema and object manipulation.
> 2. Harder part is the protocol: SOAP, ACAP, ..?

Again, this is likely a general event/subscription problem, not
specifically a presence problem. ACAP is a configuration retrieval
protocol with very limited deployment, not an RPC mechanism.

Again, conference management ("Dear moderator: User X wants to join
conference. Yes/no?") has a similar problem, as discussed in one of the
meetings.

> o Profiles, user and group discovery
> Whois++
> o Jonathan: find a group for whatever.  How do you do this across distributed domains?  Would work from a webpage in one domain.

This could be considered a service-location problem. As long as you know
the domain, "remote" SLP would work quite nicely for that.

From nsyracus@cnri.reston.va.us  Thu Apr  4 07:03:22 2002
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 HAA16329
	for ; Thu, 4 Apr 2002 07:03:22 -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 HAA10739;
	Thu, 4 Apr 2002 07:02:23 -0500 (EST)
Message-Id: <200204041202.HAA10739@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
Date: Thu, 04 Apr 2002 07:02:23 -0500
Content-Length: 3096
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-06.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: Session Initiation Protocol (SIP) Extensions for 
                          Presence
	Author(s)	: J. Rosenberg et al.
	Filename	: draft-ietf-simple-presence-06.txt
	Pages		: 26
	Date		: 03-Apr-02
	
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications of user presence. User
presence is defined as the willingness and ability of a user to
communicate with other users on the network. Historically, presence
has been limited to 'on-line' and 'off-line' indicators; the notion
of presence here is broader. Subscriptions and notifications of user
presence are supported by defining an event package within the
general SIP event notification framework. This protocol is also
compliant with the Common Presence and Instant Messaging (CPIM)
framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-presence-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-presence-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020403130515.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020403130515.I-D@ietf.org>

--OtherAccess--

--NextPart--



From rsparks@dynamicsoft.com  Thu Apr  4 18:36:52 2002
Received: from crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18175
	for ; Thu, 4 Apr 2002 18:36:51 -0500 (EST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g34NdkA28409
	for ; Thu, 4 Apr 2002 17:39:46 -0600
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Date: 04 Apr 2002 17:35:50 -0600
Message-Id: <1017963350.1228.6.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Length: 3169
Subject: [Simple] WGLC: draft-ietf-simple-presence-06.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: 

This is a SIMPLE working group last call for comments on the
presence draft announced below. 

This draft has been through a last call before, but was
touched afterwards to align with the changes in sip-events
and the new RFC. As such, this call for comments is short.

Please post any comments you have on this draft to the list
before April 11.

Thanks,

RjS

-----Forwarded Message-----

> From: Internet-Drafts@ietf.org
> Cc: simple@mailman.dynamicsoft.com
> Subject: I-D ACTION:draft-ietf-simple-presence-06.txt
> Date: 04 Apr 2002 07:02:23 -0500
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.
> 
> 	Title		: Session Initiation Protocol (SIP) Extensions for 
>                           Presence
> 	Author(s)	: J. Rosenberg et al.
> 	Filename	: draft-ietf-simple-presence-06.txt
> 	Pages		: 26
> 	Date		: 03-Apr-02
> 	
> This document describes the usage of the Session Initiation Protocol
> (SIP) for subscriptions and notifications of user presence. User
> presence is defined as the willingness and ability of a user to
> communicate with other users on the network. Historically, presence
> has been limited to 'on-line' and 'off-line' indicators; the notion
> of presence here is broader. Subscriptions and notifications of user
> presence are supported by defining an event package within the
> general SIP event notification framework. This protocol is also
> compliant with the Common Presence and Instant Messaging (CPIM)
> framework.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-06.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-simple-presence-06.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-simple-presence-06.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 



From jdrosen@dynamicsoft.com  Thu Apr  4 21:06:26 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18600
	for ; Thu, 4 Apr 2002 21:06:26 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3526eTE028991;
	Thu, 4 Apr 2002 21:06:40 -0500 (EST)
Message-ID: <3CAD0668.554BC8EB@dynamicsoft.com>
Date: Thu, 04 Apr 2002 21:05:28 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Sparks 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] WGLC: draft-ietf-simple-presence-06.txt
References: <1017963350.1228.6.camel@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 4071
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: 

Note that the changes from -05 to -06 are entirely cosmetic, based on
nits reviews on the -05 version.

-Jonathan R.

Robert Sparks wrote:
> 
> This is a SIMPLE working group last call for comments on the
> presence draft announced below.
> 
> This draft has been through a last call before, but was
> touched afterwards to align with the changes in sip-events
> and the new RFC. As such, this call for comments is short.
> 
> Please post any comments you have on this draft to the list
> before April 11.
> 
> Thanks,
> 
> RjS
> 
> -----Forwarded Message-----
> 
> > From: Internet-Drafts@ietf.org
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: I-D ACTION:draft-ietf-simple-presence-06.txt
> > Date: 04 Apr 2002 07:02:23 -0500
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the SIP for Instant Messaging and
> Presence Leveraging Extensions Working Group of the IETF.
> >
> >       Title           : Session Initiation Protocol (SIP) Extensions
> for
> >                           Presence
> >       Author(s)       : J. Rosenberg et al.
> >       Filename        : draft-ietf-simple-presence-06.txt
> >       Pages           : 26
> >       Date            : 03-Apr-02
> >
> > This document describes the usage of the Session Initiation Protocol
> > (SIP) for subscriptions and notifications of user presence. User
> > presence is defined as the willingness and ability of a user to
> > communicate with other users on the network. Historically, presence
> > has been limited to 'on-line' and 'off-line' indicators; the notion
> > of presence here is broader. Subscriptions and notifications of user
> > presence are supported by defining an event package within the
> > general SIP event notification framework. This protocol is also
> > compliant with the Common Presence and Instant Messaging (CPIM)
> > framework.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-06.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the
> message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >       "get draft-ietf-simple-presence-06.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >       mailserv@ietf.org.
> > In the body type:
> >       "FILE /internet-drafts/draft-ietf-simple-presence-06.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> >       MIME-encoded form by using the "mpack" utility.  To use this
> >       feature, insert the command "ENCODING mime" before the "FILE"
> >       command.  To decode the response(s), you will need "munpack" or
> >       a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> >       exhibit different behavior, especially when dealing with
> >       "multipart" MIME messages (i.e. documents which have been split
> >       up into multiple messages), so check your local documentation on
> >       how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Fri Apr  5 14:05:07 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21361
	for ; Fri, 5 Apr 2002 14:05:07 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g35J4nTE029575;
	Fri, 5 Apr 2002 14:04:49 -0500 (EST)
Message-ID: <3CADF509.7CF561D@dynamicsoft.com>
Date: Fri, 05 Apr 2002 14:03:37 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
CC: Robert Sparks , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <3CABCD9B.5E7EC028@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3768
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: 


Henning Schulzrinne wrote:
> 
> A general remark: where possible, I believe it would be helpful to
> abstract from the specific event type and see if the operation also
> applies to other SIP events. This seems likely to further increase the
> leverage that the general SIP event mechanism, as opposed to a specific
> presence mechanism, offers. In particular, I believe that conferencing
> might later be able to make good use of these generalizations.
> 
> >
> > SIMPLE Work items:
> > o Adopt a buddylist package as a work item
> > o Fairly well scoped. Package or Template package?
> > o Subscribe to list rather than members.
> > o Nothing to do with list manipulation.
> 
> For example, buddy lists are, abstracted, just a list of events and SIP
> URIs that I subscribe to. It should be treated as such.

I agree. THis was one of the discussion points, in fact, as to whether
to make it a template package. Its template packate format would be a
"collection" template, for example:

presence.collection
conference.collection

The fact that its more general doesn't rule out simple doing it, though.
AFter all, watcherinfo is the same - it evolved into a template so
others could use it.


> 
> > * Jonathan: Textual stuff works great until you realize consumer of
> presence may be automata (onhook/offhook versus open/closed).  Are there
> a  set of things for semantic understanding?
> 
> Comment: The important thing is a unique name (plus maybe an English
> phrase) so that I can program behavior. It's not terribly important that
> there is a legal definition as to what state of mind and body each word
> entails. For example, it's sufficient if within a community of interest
> "ttsio" state means "talking to student in office".
> 
> Also, priorities are a good example: "Urgent" doesn't have a distinct
> meaning ("the building's on fire" vs. "I need this a week from now"),
> but it's still useful.

Sure. The main point is that somewhere, there needs to be a list of
names, with reasonably defined meanings associated with them...

> 
> > o Adopt a work item to develop the needed data manipulations for
> buddylist, allow/deny
> > 1. Model for block list, allow list: data schema and object
> manipulation.
> > 2. Harder part is the protocol: SOAP, ACAP, ..?
> 
> Again, this is likely a general event/subscription problem, not
> specifically a presence problem. ACAP is a configuration retrieval
> protocol with very limited deployment, not an RPC mechanism.

I'm not sure if you are arguing that ACAP is a better fit, if SOAP is a
better fit, or if netiher are the right fit, since this is another event
problem. 

The problem has an event component, but there is more than that. I need
to be able to manipulate lists stored on a server - adding entries,
removing entries, getting the list of entries. I also need to be
notified if that list is changed outside of my client/handset - for
example, modified by customer support, or from a web page. 


> > o Profiles, user and group discovery
> > Whois++
> > o Jonathan: find a group for whatever.  How do you do this across
> distributed domains?  Would work from a webpage in one domain.
> 
> This could be considered a service-location problem. As long as you know
> the domain, "remote" SLP would work quite nicely for that.

I think we agreed to steer clear of this problem for now, actually. I
believe it is far more complex than service discovery. 

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From hgs@bart.cs.columbia.edu  Fri Apr  5 14:27:20 2002
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 OAA21442
	for ; Fri, 5 Apr 2002 14:27:20 -0500 (EST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA09781;
	Fri, 5 Apr 2002 14:26:18 -0500 (EST)
Received: from bart.cs.columbia.edu (localhost [127.0.0.1])
	by bart.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g35JQHDS023006;
	Fri, 5 Apr 2002 14:26:17 -0500 (EST)
Received: from localhost (hgs@localhost)
	by bart.cs.columbia.edu (8.12.1/8.12.1/Submit) with ESMTP id g35JQGlr023003;
	Fri, 5 Apr 2002 14:26:17 -0500 (EST)
Date: Fri, 5 Apr 2002 14:26:16 -0500 (EST)
From: "Henning G. Schulzrinne" 
To: Jonathan Rosenberg 
cc: Robert Sparks , 
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
In-Reply-To: <3CADF509.7CF561D@dynamicsoft.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2963
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: 

> >
> > Comment: The important thing is a unique name (plus maybe an English
> > phrase) so that I can program behavior. It's not terribly important that
> > there is a legal definition as to what state of mind and body each word
> > entails. For example, it's sufficient if within a community of interest
> > "ttsio" state means "talking to student in office".
> >
> > Also, priorities are a good example: "Urgent" doesn't have a distinct
> > meaning ("the building's on fire" vs. "I need this a week from now"),
> > but it's still useful.
>
> Sure. The main point is that somewhere, there needs to be a list of
> names, with reasonably defined meanings associated with them...

While I think a registration mechanism is helpful, I don't even think it's
strictly necessary. It's more important that UAs make it easy to add new
word/description pairs that are meaningful to me. Thus, there's no large
need to worry about restricting the set. If I want to add "tired" or
"drunk" as states of presence, this doesn't seem to do much harm. (At
least in some colleges, those are probably the two most common states...)
One
minor issue is the ability to represent new states via some kind of icon;
that would argue against being too generous in adding hundreds of presence
states each month.

>
> I'm not sure if you are arguing that ACAP is a better fit, if SOAP is a
> better fit, or if netiher are the right fit, since this is another event
> problem.

I'm arguing that ACAP is probably not the right fit. SOAP can do anything
so it's never the wrong fit :-)

>
> The problem has an event component, but there is more than that. I need
> to be able to manipulate lists stored on a server - adding entries,
> removing entries, getting the list of entries. I also need to be
> notified if that list is changed outside of my client/handset - for
> example, modified by customer support, or from a web page.
>
>

Speaking from conf-control experience, we found that a combination of
events (SIP) and object manipulation (SOAP methods) works well. The SOAP
component deals with request-response things, SIP events with asynchronous
events that the client can't anticipate.

> > > o Profiles, user and group discovery
> > > Whois++
> > > o Jonathan: find a group for whatever.  How do you do this across
> > distributed domains?  Would work from a webpage in one domain.
> >
> > This could be considered a service-location problem. As long as you know
> > the domain, "remote" SLP would work quite nicely for that.
>
> I think we agreed to steer clear of this problem for now, actually. I
> believe it is far more complex than service discovery.

In its full generality, I agree. For more circumscribed problems ("find
groups related to cooking that are open to minors and are moderated on
provider BPM.COM"), this is manageable and similar enough. I believe even
the limited functionality would be helpful. Again, it would be similar
between conferences and IM groups.


From pkyzivat@cisco.com  Fri Apr  5 18:12:19 2002
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 SAA22087
	for ; Fri, 5 Apr 2002 18:12:19 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g35NBe505785;
	Fri, 5 Apr 2002 18:11:40 -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 AAH98014;
	Fri, 5 Apr 2002 18:14:34 -0500 (EST)
Message-ID: <3CAE2F14.A335A079@cisco.com>
Date: Fri, 05 Apr 2002 18:11:16 -0500
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: "Henning G. Schulzrinne" 
CC: Jonathan Rosenberg ,
        Robert Sparks ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5726
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: 

I suspect that we are trying to load too much significance onto a single status value - trying to make it convey everything nuance of availability into one value.

There are a couple of problems with this:
- as Henning noted, there is an expectation that the status value can be represented as an icon. The more values there are the harder it is to do.

- the syntax already supports multiple value elements in status. As soon as there is more than one, mapping to a single icon is a problem that must be dealt with.

Another issue is that this is being approached assuming that the sip/simple community has no vested interest in any particular way of characterizing status. But this isn't
true - we have callerprefs, which provide a way of characterizing availability of contacts. These have not (yet) been integrated with presence, but they ought to be.

Callerprefs provide a number of dimensions on which to classify a contact (tuple). These could be mapped directly to status values. Or they could be mapped to some new
elements within a tuple. They are a bit more complex than the what is currently defined by urn:ietf:params:cpim-presence:status-type:basic. There are a number of preference
parameter types (class, duplex, feature, language, media, mobility, methods, priority), and each in turn has an enumerated set of possible values. (There is also a
"description" parameter, but it probably should be mapped to , and a q-value that is already represented as the priority attribute of .)

These preference parameters are a bit different than the existing and proposed values. The existing and proposed values generally indicate what state the presentity is in /
what it is doing and leave it up to the watcher to how that relates to its willingness to accept a call. The callerprefs parameters more explicitly state what sorts of
calls should be accepted, without any other explicit indication of current state.

This difference has implications for the UI, but serves more-or-less the same purpose of helping the caller decide whether to attempt a call.

It is important to align these mechanisms, because it provides linkage to registration. If I use registration w/callerprefs to control how/if forking proxies decide to send
calls to me, the information that is learned via presence ought to be consistent. So there ought to be some well defined relationship between the states of the two
mechanisms.

	Paul

"Henning G. Schulzrinne" wrote:
> 
> > >
> > > Comment: The important thing is a unique name (plus maybe an English
> > > phrase) so that I can program behavior. It's not terribly important that
> > > there is a legal definition as to what state of mind and body each word
> > > entails. For example, it's sufficient if within a community of interest
> > > "ttsio" state means "talking to student in office".
> > >
> > > Also, priorities are a good example: "Urgent" doesn't have a distinct
> > > meaning ("the building's on fire" vs. "I need this a week from now"),
> > > but it's still useful.
> >
> > Sure. The main point is that somewhere, there needs to be a list of
> > names, with reasonably defined meanings associated with them...
> 
> While I think a registration mechanism is helpful, I don't even think it's
> strictly necessary. It's more important that UAs make it easy to add new
> word/description pairs that are meaningful to me. Thus, there's no large
> need to worry about restricting the set. If I want to add "tired" or
> "drunk" as states of presence, this doesn't seem to do much harm. (At
> least in some colleges, those are probably the two most common states...)
> One
> minor issue is the ability to represent new states via some kind of icon;
> that would argue against being too generous in adding hundreds of presence
> states each month.
> 
> >
> > I'm not sure if you are arguing that ACAP is a better fit, if SOAP is a
> > better fit, or if netiher are the right fit, since this is another event
> > problem.
> 
> I'm arguing that ACAP is probably not the right fit. SOAP can do anything
> so it's never the wrong fit :-)
> 
> >
> > The problem has an event component, but there is more than that. I need
> > to be able to manipulate lists stored on a server - adding entries,
> > removing entries, getting the list of entries. I also need to be
> > notified if that list is changed outside of my client/handset - for
> > example, modified by customer support, or from a web page.
> >
> >
> 
> Speaking from conf-control experience, we found that a combination of
> events (SIP) and object manipulation (SOAP methods) works well. The SOAP
> component deals with request-response things, SIP events with asynchronous
> events that the client can't anticipate.
> 
> > > > o Profiles, user and group discovery
> > > > Whois++
> > > > o Jonathan: find a group for whatever.  How do you do this across
> > > distributed domains?  Would work from a webpage in one domain.
> > >
> > > This could be considered a service-location problem. As long as you know
> > > the domain, "remote" SLP would work quite nicely for that.
> >
> > I think we agreed to steer clear of this problem for now, actually. I
> > believe it is far more complex than service discovery.
> 
> In its full generality, I agree. For more circumscribed problems ("find
> groups related to cooking that are open to minors and are moderated on
> provider BPM.COM"), this is manageable and similar enough. I believe even
> the limited functionality would be helpful. Again, it would be similar
> between conferences and IM groups.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From seancolson@yahoo.com  Fri Apr  5 20:35:06 2002
Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id UAA22477
	for ; Fri, 5 Apr 2002 20:35:06 -0500 (EST)
Message-ID: <20020406013410.1461.qmail@web11608.mail.yahoo.com>
Received: from [131.107.3.70] by web11608.mail.yahoo.com via HTTP; Fri, 05 Apr 2002 17:34:10 PST
Date: Fri, 5 Apr 2002 17:34:10 -0800 (PST)
From: Sean Olson 
To: sipping@ietf.org, simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 455
Subject: [Simple] draft-olson-sipping-content-indirect-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: 

FYI. I've put together a draft of requirements
for a mechanism to allow content indirection
(an indirect reference to content that would normally
be carried directly in the SIP payload)

http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.txt

/sean


=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

From pkyzivat@cisco.com  Mon Apr  8 10:11:34 2002
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 KAA01128
	for ; Mon, 8 Apr 2002 10:11:34 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g38EARDX019488;
	Mon, 8 Apr 2002 10:10:28 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI02609;
	Mon, 8 Apr 2002 10:13:22 -0400 (EDT)
Message-ID: <3CB1A4BC.8DB70998@cisco.com>
Date: Mon, 08 Apr 2002 10:10:04 -0400
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: Sean Olson 
CC: sipping@ietf.org, simple@mailman.dynamicsoft.com
References: <20020406013410.1461.qmail@web11608.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1126
Subject: [Simple] Re: [Sipping] draft-olson-sipping-content-indirect-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: 

Sean - comment below.

	Paul

Sean Olson wrote:
> 
> FYI. I've put together a draft of requirements
> for a mechanism to allow content indirection
> (an indirect reference to content that would normally
> be carried directly in the SIP payload)
> 
> http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.txt

What is the purpose of REQ-2? 

Since this proposal is about content indirection, it seems like the purpose of the content should be unchanged whether it is indirected or not. Whatever mechanism there is
out to apply equally whether the content is direct or indirect. The Content-Disposition header already serves this purpose.

Perhaps you are trying to say that it should be possible to use several URLs as an alternative to several parts in a multipart-MIME body, and that you want an ability
equivalent to specifying a separate Content-Disposition header for each. That seems reasonable.

But if you are suggesting a need for more forms of disposition than are currently covered by Content-Disposition, then I think that should be handled in a way independent
of content indirection.

	Paul

From sriramp@nortelnetworks.com  Mon Apr  8 10:54:59 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01286
	for ; Mon, 8 Apr 2002 10:54:58 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g38ErID25199;
	Mon, 8 Apr 2002 09:53:18 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2JXVK3GP>; Mon, 8 Apr 2002 09:50:42 -0500
Message-ID: 
From: "Sriram Parameswar"
To: "'Paul Kyzivat'" , Sean Olson 
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Re: [Sipping] draft-olson-sipping-content-indirect-0
	0.txt
Date: Mon, 8 Apr 2002 09:50:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1DF0C.C00A0BD0"
Content-Length: 6709
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: 

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_01C1DF0C.C00A0BD0
Content-Type: text/plain;
	charset="iso-8859-1"

Sean:

Couple of additional comments/requirements:

** Access-Control - control over access to the content either by
authorization mechanisms or others. 
** Access-Control mechanism - this is probably extreme but we could probably
add an access-control mechanism. This should allow for a method of
access-control modification i.e. I gave you permission to see a particular
content - then want to revoke this privilege.

Thanks,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Monday, April 08, 2002 9:10 AM
To: Sean Olson
Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
Subject: [Simple] Re: [Sipping]
draft-olson-sipping-content-indirect-00.txt


Sean - comment below.

	Paul

Sean Olson wrote:
> 
> FYI. I've put together a draft of requirements
> for a mechanism to allow content indirection
> (an indirect reference to content that would normally
> be carried directly in the SIP payload)
> 
>
http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.
txt

What is the purpose of REQ-2? 

Since this proposal is about content indirection, it seems like the purpose
of the content should be unchanged whether it is indirected or not. Whatever
mechanism there is
out to apply equally whether the content is direct or indirect. The
Content-Disposition header already serves this purpose.

Perhaps you are trying to say that it should be possible to use several URLs
as an alternative to several parts in a multipart-MIME body, and that you
want an ability
equivalent to specifying a separate Content-Disposition header for each.
That seems reasonable.

But if you are suggesting a need for more forms of disposition than are
currently covered by Content-Disposition, then I think that should be
handled in a way independent
of content indirection.

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

------_=_NextPart_001_01C1DF0C.C00A0BD0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Re: [Sipping] =
draft-olson-sipping-content-indirect-00.txt




Sean:




Couple of additional comments/requirements:




** Access-Control - control over access to the =
content either by authorization mechanisms or others. 

** Access-Control mechanism - this is probably =
extreme but we could probably add an access-control mechanism. This =
should allow for a method of access-control modification i.e. I gave =
you permission to see a particular content - then want to revoke this =
privilege.



Thanks,




Sriram




__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-684-3986

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com






-----Original Message-----

From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=


Sent: Monday, April 08, 2002 9:10 AM

To: Sean Olson

Cc: sipping@ietf.org; =
simple@mailman.dynamicsoft.com

Subject: [Simple] Re: [Sipping]

draft-olson-sipping-content-indirect-00.txt






Sean - comment below.




        Paul




Sean Olson wrote:

> 

> FYI. I've put together a draft of =
requirements

> for a mechanism to allow content =
indirection

> (an indirect reference to content that would =
normally

> be carried directly in the SIP payload)

> 

> http://www.ietf.org/internet-drafts/draft-olson-sippin=
g-content-indirect-00.txt




What is the purpose of REQ-2? 




Since this proposal is about content indirection, it =
seems like the purpose of the content should be unchanged whether it is =
indirected or not. Whatever mechanism there is



out to apply equally whether the content is direct or =
indirect. The Content-Disposition header already serves this =
purpose.



Perhaps you are trying to say that it should be =
possible to use several URLs as an alternative to several parts in a =
multipart-MIME body, and that you want an ability



equivalent to specifying a separate =
Content-Disposition header for each. That seems reasonable.




But if you are suggesting a need for more forms of =
disposition than are currently covered by Content-Disposition, then I =
think that should be handled in a way independent



of content indirection.




        Paul

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple=






------_=_NextPart_001_01C1DF0C.C00A0BD0--

From seancolson@yahoo.com  Mon Apr  8 12:43:05 2002
Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA01655
	for ; Mon, 8 Apr 2002 12:43:05 -0400 (EDT)
Message-ID: <20020408164205.88765.qmail@web11602.mail.yahoo.com>
Received: from [207.46.137.8] by web11602.mail.yahoo.com via HTTP; Mon, 08 Apr 2002 09:42:05 PDT
Date: Mon, 8 Apr 2002 09:42:05 -0700 (PDT)
From: Sean Olson 
To: Paul Kyzivat 
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
In-Reply-To: <3CB1A4BC.8DB70998@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 896
Subject: [Simple] Re: [Sipping] draft-olson-sipping-content-indirect-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: 

> 
> Perhaps you are trying to say that it should be
> possible to use several URLs as an alternative to
> several parts in a multipart-MIME body, and that you
> want an ability
> equivalent to specifying a separate
> Content-Disposition header for each. That seems
> reasonable.

Exactly. I will make this explicit.

> 
> But if you are suggesting a need for more forms of
> disposition than are currently covered by
> Content-Disposition, then I think that should be
> handled in a way independent
> of content indirection.

I think Content-Disposition could be easily
extended to accommodate what I have in mind.
I will leave those details to a draft that 
proposes an implementation of these requirements.

> 
> 	Paul

Thanks for the comments.
/sean



__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

From seancolson@yahoo.com  Mon Apr  8 13:05:46 2002
Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01757
	for ; Mon, 8 Apr 2002 13:05:46 -0400 (EDT)
Message-ID: <20020408170447.29119.qmail@web11607.mail.yahoo.com>
Received: from [207.46.137.9] by web11607.mail.yahoo.com via HTTP; Mon, 08 Apr 2002 10:04:47 PDT
Date: Mon, 8 Apr 2002 10:04:47 -0700 (PDT)
From: Sean Olson 
Subject: RE: [Simple] Re: [Sipping] draft-olson-sipping-content-indirect-0 0.txt
To: Sriram Parameswar ,
        "'Paul Kyzivat'" 
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 2864
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: 

This starts to spill over into the content vault
area. I'm preparing a separate draft for this.
There is obviously a lot of overlap here. I 
should be able to post the new draft in about a
week. Let me know if this doesn't cover your 
concerns.

Thanks,
Sean

--- Sriram Parameswar 
wrote:
> Sean:
> 
> Couple of additional comments/requirements:
> 
> ** Access-Control - control over access to the
> content either by
> authorization mechanisms or others. 
> ** Access-Control mechanism - this is probably
> extreme but we could probably
> add an access-control mechanism. This should allow
> for a method of
> access-control modification i.e. I gave you
> permission to see a particular
> content - then want to revoke this privilege.
> 
> Thanks,
> 
> Sriram
> 
> __________________________________________
> Sriram Parameswar              Phone: 972-685-8540
> Interactive Multimedia Server (IMS) Fax:
> 972-684-3986
> Nortel Networks, Richardson USA  Email:
> sriramp@nortelnetworks.com
> 
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, April 08, 2002 9:10 AM
> To: Sean Olson
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: [Simple] Re: [Sipping]
> draft-olson-sipping-content-indirect-00.txt
> 
> 
> Sean - comment below.
> 
> 	Paul
> 
> Sean Olson wrote:
> > 
> > FYI. I've put together a draft of requirements
> > for a mechanism to allow content indirection
> > (an indirect reference to content that would
> normally
> > be carried directly in the SIP payload)
> > 
> >
>
http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.
> txt
> 
> What is the purpose of REQ-2? 
> 
> Since this proposal is about content indirection, it
> seems like the purpose
> of the content should be unchanged whether it is
> indirected or not. Whatever
> mechanism there is
> out to apply equally whether the content is direct
> or indirect. The
> Content-Disposition header already serves this
> purpose.
> 
> Perhaps you are trying to say that it should be
> possible to use several URLs
> as an alternative to several parts in a
> multipart-MIME body, and that you
> want an ability
> equivalent to specifying a separate
> Content-Disposition header for each.
> That seems reasonable.
> 
> But if you are suggesting a need for more forms of
> disposition than are
> currently covered by Content-Disposition, then I
> think that should be
> handled in a way independent
> of content indirection.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 


=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

From jdrosen@dynamicsoft.com  Tue Apr  9 03:33:37 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04042
	for ; Tue, 9 Apr 2002 03:33:37 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.115])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g397X9o6002206;
	Tue, 9 Apr 2002 03:33:10 -0400 (EDT)
Message-ID: <3CB24E53.47BCABDF@dynamicsoft.com>
Date: Mon, 08 Apr 2002 22:13:39 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Henning G. Schulzrinne" 
CC: Robert Sparks , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2675
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: 


"Henning G. Schulzrinne" wrote:
> 

> > > Also, priorities are a good example: "Urgent" doesn't have a
> distinct
> > > meaning ("the building's on fire" vs. "I need this a week from
> now"),
> > > but it's still useful.
> >
> > Sure. The main point is that somewhere, there needs to be a list of
> > names, with reasonably defined meanings associated with them...
> 
> While I think a registration mechanism is helpful, I don't even think
> it's
> strictly necessary. It's more important that UAs make it easy to add new
> word/description pairs that are meaningful to me. Thus, there's no large
> need to worry about restricting the set. If I want to add "tired" or
> "drunk" as states of presence, this doesn't seem to do much harm. (At
> least in some colleges, those are probably the two most common
> states...)
> One
> minor issue is the ability to represent new states via some kind of
> icon;
> that would argue against being too generous in adding hundreds of
> presence
> states each month.

Without a registration mechanism, and a reasonably well defined meaning
known to all, how could you select the appropriate icon for a status
(assuming you don't send the icon itself)?

This is really symptomatic of the general problem. Without standardized
meanings for a bunch of values, there is no way for an automata to do
processing of presence data. Such processing might include display of an
icon, but there are other things:

  * automatically try to ring the cell phone instead of the desk phone
when someones status is "in a meeting", as opposed to "busy" where the
call would go to voicemail instead.

  * block phone calls when the status is "sleeping" but allow IM

and so on.


> > I think we agreed to steer clear of this problem for now, actually. I
> > believe it is far more complex than service discovery.
> 
> In its full generality, I agree. For more circumscribed problems ("find
> groups related to cooking that are open to minors and are moderated on
> provider BPM.COM"), this is manageable and similar enough. I believe
> even
> the limited functionality would be helpful. Again, it would be similar
> between conferences and IM groups.

When you know the domain where teh group is hosted, its easy, yes. The
whole trick is when you DONT know, and it is that problem which I wish
to steer clear of.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com



From mikko.lonnfors@nokia.com  Tue Apr  9 03:37:59 2002
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 DAA04079
	for ; Tue, 9 Apr 2002 03:37:58 -0400 (EDT)
From: mikko.lonnfors@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g397bH513326
	for ; Tue, 9 Apr 2002 10:37:17 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 9 Apr 2002 10:37:00 +0300
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 9 Apr 2002 10:36:59 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] question about winfo-package (resend with revision marks)
Date: Tue, 9 Apr 2002 10:36:59 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF104067@esebe004.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] question about winfo-package (resend with revision marks)
Thread-Index: AcHZRECmLKeXD7SsTnuU7OZCmRT3oQGUk19A
To: 
Cc: 
X-OriginalArrivalTime: 09 Apr 2002 07:36:59.0954 (UTC) FILETIME=[5570F120:01C1DF99]
Content-Length: 4590
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA04079
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: 

Hi,

Thanks for the answer. I have one more question about draft-ietf-simple-winfo-package-01.
Chapter 4.7.1 The Subscription State Machine (after figure 1) 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."

Is this to say that the package on which winfo is applied to should not generate
any NOTIFY messages to subscriber? This sound a bit weird because SIP events says that NOTIFY
should be send immediately after 200-class response. (I am here assuming SUB-202 request/response
if there is no authorization policy is set)

So in short how should the quoted sentence be interpreted?

regards
- Mikko

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 01 April, 2002 09:13
> To: Lonnfors Mikko (NRC/Helsinki)
> Cc: tanglih@cn.ibm.com; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] question about winfo-package (resend 
> with revision
> marks)
> 
> 
> 
> 
> mikko.lonnfors@nokia.com wrote:
> > 
> > My opinion about your question is as follows:
> > 
> > The motivating application for winfo package is presence 
> authorization.
> > If
> > User B is authorized to subscribe A's presence, as you 
> said, generally
> > speaking the PS doesn't need to notify A of the B's 
> subscription status
> > for
> > authorization.
> > 
> > 
> > I would still say that winfo is designed to enable presentity to get
> > lists of watchers interested in their presence status.
> > This should happen regardless of the watcher's authorization status.
> > Presence authorization may be the main motivation
> > to enable this functionality but not the only one.
> > 
> 
> Yes. However, the decision about when to send NOTIFY for winfo is a
> server decision; it can decide to not send two notifications 
> in the case
> of a fetch.
> 
> 
> > 
> > If the PS needs to notify A of this FETCH subscription, you 
> may use the
> > 'expiration' attribute of winfo foramt. Like this:
> >   
> >      
> >         >                    event="subscribe" expiration="0"/>
> >      
> >    
> > In this case, A should understanding that a FETCH subscription is
> > requested.
> > How about this way to solute your problem?
> > 
> > 
> > I think there are some problems with this approach. I think 
> that winfo
> > is designed to
> > signal changes in watchers subscription status i.e. signal 
> the state to
> > which a watcher has moved from previous state.
> > In this case, as you said,  A should be able to understand that
> > 
> >     
> >         >                    event="subscribe" expiration="0"/>
> > 
> > means FETCH. This would mean special casing expiration="0".
> 
> It only needs to be special cased if you are trying to explicitly
> identify fetch requests. I see no reason to do that. The above
> notification stands, by itself, as something reasonable. 
> However, if you
> want to send a single notification, you are probably better 
> off sending
> the one on the transition to terminated due to timeout.
> 
> 
> 
> > We could take an other example. Let's say that B performs 
> FETCH but has
> > no authorization. Should A now get
> > 
> >    
> >         >                    event="subscribe" expiration="0"/>
> > 
> > I would say that sending
> > 
> >    
> >         >                    event="subscribe"/>
> > 
> > would make more sense.
> 
> I agree that the second one makes more sense. The first is valid, of
> course, but if you want to send just one notification, the latter is
> more useful. Again, the decision about which state change 
> notifications
> to send is a matter of local policy.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 

From hgs@cs.columbia.edu  Tue Apr  9 09:25:29 2002
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 JAA05037
	for ; Tue, 9 Apr 2002 09:25:28 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA07867;
	Tue, 9 Apr 2002 09:24:29 -0400 (EDT)
Received: from cs.columbia.edu (pool-138-89-41-200.mad.east.verizon.net [138.89.41.200])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g39DORPm018603
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 9 Apr 2002 09:24:28 -0400 (EDT)
Message-ID: <3CB2EB6F.BF507ECE@cs.columbia.edu>
Date: Tue, 09 Apr 2002 09:23:59 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: Robert Sparks , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References:  <3CB24E53.47BCABDF@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2870
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: 

> > One
> > minor issue is the ability to represent new states via some kind of
> > icon;
> > that would argue against being too generous in adding hundreds of
> > presence
> > states each month.
> 
> Without a registration mechanism, and a reasonably well defined meaning
> known to all, how could you select the appropriate icon for a status
> (assuming you don't send the icon itself)?
> 
> This is really symptomatic of the general problem. Without standardized
> meanings for a bunch of values, there is no way for an automata to do
> processing of presence data. Such processing might include display of an
> icon, but there are other things:
> 
>   * automatically try to ring the cell phone instead of the desk phone
> when someones status is "in a meeting", as opposed to "busy" where the
> call would go to voicemail instead.
> 
>   * block phone calls when the status is "sleeping" but allow IM

However, that type of processing is best done at the callee. Thus, this
only needs to be a local convention between the callee and his proxy
server. It doesn't matter in that case whether I call the state
"dozing", "sleeping", "zzzz" or "napping". I may well have many
different local states that influence call routing, as in "meeting with
boss", "meeting with customer", "meeting with salescritter" (please
interrupt at any time, the sooner, the better), etc. In most of these
cases, I don't want to make this information visible to watchers, yet
still have it be useful for call routing, as part of a CPL or cgi
script, say.

> 
> and so on.

There's a range of utility here, I believe:

(1) private labels (no registration) - can't do icons except by explicit
table in the UA, would need to manually program behavior on a
case-by-case basis, based on token match (com.dynamicsoft.sleeping);
still useful for closed user communities

(2) central registration, but fairly open - can do icons (and other
pre-programmed behavior) as long as list doesn't change too often; fall
back to displaying "other" icon and text string for entities that don't
recognize the state;

(3) limited base set that everybody should understand - icons,
exhaustive case match, useful across general Internet community, etc.

I agree that (3) is important, but I think we'll have an easier time
agreeing on (3) if we don't preclude (2) and (1).


> When you know the domain where teh group is hosted, its easy, yes. The
> whole trick is when you DONT know, and it is that problem which I wish
> to steer clear of.

No disagreement; in many cases, I suspect that we can approximate the
latter by meta-sites, just like Yahoo or OpenDirectory provide listings
for many "external" web sites. I would just point my search tool at
best-discussion-groups.com, which in turn finds groups. Same mechanism
as per-domain, but still avoids the "one root" or "global unstructured
search" problem.

From seancolson@yahoo.com  Tue Apr  9 13:08:13 2002
Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA05647
	for ; Tue, 9 Apr 2002 13:08:12 -0400 (EDT)
Message-ID: <20020409170715.94629.qmail@web11608.mail.yahoo.com>
Received: from [207.46.137.9] by web11608.mail.yahoo.com via HTTP; Tue, 09 Apr 2002 10:07:15 PDT
Date: Tue, 9 Apr 2002 10:07:15 -0700 (PDT)
From: Sean Olson 
To: "Beck01, Wolfgang" , sipping@ietf.org,
        simple@mailman.dynamicsoft.com
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1260
Subject: [Simple] RE: [Sipping] draft-olson-sipping-content-indirect-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: 

I absolutely appreciate your concern. Simply
put, any system must have an appropriately defined
security mechanism in place for any packets it
receives. Ignoring Content-Disposition: for now,
what dangers do you perceive for handling an INVITE,
or a SUBSCRIBE, or a REFER, or ... ? This is
roughly equivalent to the problem of handling CPL 
upload. How do you trust the CPL you receive to
know it is safe to execute? Assuming there is
an answer to that question, can you apply that
answer to an "execute" disposition?

I would like to solicit other people's comments
on this topic. If there is sufficient pushback,
I'll remove this item.

Thanks!
/sean

--- "Beck01, Wolfgang"  wrote:
> Sean,
> 
> disposition "execute" in REQ-2 is very dangerous. A
> popular E-mail program
> used to have a similar function enabled by default,
> which resulted
> in a worldwide breakdown of many mail servers. Even
> "render" might be dangerous, if
> the document uses some language like PostScript or
> Word macros.
> 
> 
> --
> Wolfgang Beck
> T-Systems Nova GmbH 
> 
> 


=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

From BeckW@t-systems.com  Tue Apr  9 09:22:07 2002
Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05011
	for ; Tue, 9 Apr 2002 09:22:06 -0400 (EDT)
Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 9 Apr 2002 15:19:23 +0200
Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19)
	id <2Q8W76AN>; Tue, 9 Apr 2002 15:20:30 +0200
Message-Id: 
From: "Beck01, Wolfgang" 
To: seancolson@yahoo.com, sipping@ietf.org, simple@mailman.dynamicsoft.com
Date: Tue, 9 Apr 2002 15:20:29 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Length: 339
Subject: [Simple] RE: [Sipping] draft-olson-sipping-content-indirect-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: 

Sean,

disposition "execute" in REQ-2 is very dangerous. A popular E-mail program
used to have a similar function enabled by default, which resulted
in a worldwide breakdown of many mail servers. Even "render" might be dangerous, if
the document uses some language like PostScript or Word macros.


--
Wolfgang Beck
T-Systems Nova GmbH 



From pkyzivat@cisco.com  Tue Apr  9 15:57:44 2002
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 PAA06211
	for ; Tue, 9 Apr 2002 15:57:44 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g39JuXR9015767;
	Tue, 9 Apr 2002 15:56:33 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI13115;
	Tue, 9 Apr 2002 15:59:28 -0400 (EDT)
Message-ID: <3CB34759.E8512A1C@cisco.com>
Date: Tue, 09 Apr 2002 15:56:10 -0400
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: Henning Schulzrinne 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References:  <3CAE2F14.A335A079@cisco.com> <3CAF1D6C.90444446@cs.columbia.edu> <3CB1D49A.C9BA1BC2@cisco.com> <3CB232B8.C4D665B6@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 6779
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: 

Henning,

I am somewhat concerned about the usage model if we attempt to preserve both kinds of status information - what I am doing & what I am willing to do. I don't think it is
reasonable to expect a user to manually set both, nor do I see how one can be derived from the other.

These are distinct mechanisms (callerprefs & presence) that have evolved in different environments (voice & im) and that are trying to expand into each other's niche. They
each have something to contribute, but they have gratuitous differences that get in the way of coexistence or union.

For both mechanisms, some aspects of management can be handled automatically, but not all:

In the case of IM, there has often been an expectation that you manually log on when you are present and log off when you are not, and that this implicitly provides one
mechanism for updating presence. After that, and other nuances (e.g. away from desk) are handled by explicit user interaction. The status values are simple, so they are
easy to manage manually (e.g. by picking from a menu.) 

In the case of callerprefs, while the mechanism has been under development for some time, there is little practical usage experience. The environment in which it is
intended to operate is somewhat different - typically a phone remains connected and accessible whether there is a user attending it or not. Also, the notation for
expressing callerprefs is not so simple - it isn't easily mapped to a simple UI. Simple use of callerprefs will probably be static configuration.

However, I have in mind more active use of callerprefs - picking up the phone may change my availability. Exactly how it changes it should be a configurable option. I may
choose to be unavailable for voice calls whenever I am on a voice call. Or, I may be willing to participate in up to 2 voice calls at a time. My UA could be configured to
update my registration to honor my preferences in this regard.

Other aspects of my callerprefs can't be so easily inferred. If I only want to take personal calls and calls from my bookie when I am on vacation, then I need a UI that
lets me express that kind of logic. 

The trick is - do I have one UI or two? 

Worst case - when I am getting set to go on vacation, I use one UI to update my callerprefs, requesting only personal calls plus calls from my bookie. (This is what I am
*willing* to do.) Then, with a different UI I update my presence, to status "On Vacation".

Slightly better - I use one UI, but set two distinct attributes as above.

Better yet - I use one UI, and select one menu item that causes both attributes to be set.

Further comments below.

	Paul

Henning Schulzrinne wrote:
> 
> Paul Kyzivat wrote:
> >
> > Henning,
> >
> > I'm not sure that this will simplify the task, but it might focus it.
> >
> > A first step is to decide whether callerprefs should be mapped to  elements of  or if they should be mapped to attributes of  in the way that the
> > q-value is already mapped to a  attribute of .
> 
> Interesting idea - making it a Contact parameter would remove the need
> for a presence document, to a large extent.

Yes! If you agree that there is a substantial overlap in functionality between callerprefs and presence, then it becomes a lot more appealing to simply update your
callerprefs via REGISTER and not bother updating a presence document separately.

> I suspect we need both, with the same mapping, so that
> Accept/Reject-Contact doesn't need to know whether you registered via
> document or Contact parameter.

Not sure I follow. Are you suggesting that uploading a presence document might cause a re-registration if the contact information in the presence document is in conflict
with the current registration?

I am a bit concerned about that. There is a well defined mechanism for updating contact information in a registration piecemeal from different endpoints. But there is no
similar mechanism for presence documents.

I would rather change presence so that I can upload the part of the presence document that doesn't come from registration, and say that the rest should come from the
registrar/location service.

> > Also, I think there needs to be a discussion of whether we ought to be describing what the presentity is doing, or what it is willing to do, or both. If both, are they
> > dealt with in the same value space, or they separate but equal? While these seem to be different, I am concerned that nobody will be interested in managing them separately
> > - doing so would be cumbersome in a UI. Unfortunately, I don't think there is a well defined mapping between what I am doing and what I am willing to do. Saying what I am
> > willing to do seems more useful to a caller than saying what I am doing.
> 
> I like this distinction.

If we can agree that these are two dimensions to presence status, and that both are relevant, it *might* simplify the problem of defining standard values, by factoring it.

OTOH, it will complicate the problem of mapping to other presence systems that only have one dimension.

> What I'm willing to be doing is pretty simple, for call setup - I'm
> either willing to talk or not. The only real distinction might be the
> media - "willing to text chat" (since I'm in a meeting), "willing to do
> video". We already have the ability to express this in caller
> preferences.

I agree we have the ability to do it, but don't agree that it is simple. The nuances are straightforward syntactically, but not simply represented in a UI. (They don't map
to alternative variants of a single icon.)

"I'm willing to text chat in english or french about business; but I'm only willing to take urgent voice calls,and only in english"

> Expressing my state (what I'm doing) seems most useful to let the other
> side gauge whether their attempt at communication is likely to be
> well-received. Noting "sleeping" or "in a meeting" tells the caller that
> the call better be really important or I'm likely to be rather short
> with them. Similarly, "in a car" might be helpful to know for the caller
> - discussing a deep subject while trying to avoid rear-ending the car in
> front of me is not such a good idea.
> 
> Maybe it would be helpful to have a list of examples in each category.
> 
> So far, I can think of two categories: reflecting general surroundings
> ("car", "home", "office", "public transport" [i.e., don't assume
> privacy]) [caller preferences already has "personal" and "business"] and
> reflecting my degree of distraction or interruptibility ("in meeting",
> "watching TV", "on another call", "thinking", ...). The latter category
> seems to have no end.
> 
> Did I catch what you were trying to say?

I think we are on somewhat the same wavelength.

From hgs@cs.columbia.edu  Tue Apr  9 19:03:51 2002
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 TAA06746
	for ; Tue, 9 Apr 2002 19:03:51 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA00933;
	Tue, 9 Apr 2002 19:02:46 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g39N2jPm021562
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 9 Apr 2002 19:02:45 -0400 (EDT)
Message-ID: <3CB372A7.F7363C5D@cs.columbia.edu>
Date: Tue, 09 Apr 2002 19:00:55 -0400
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: simple@mailman.dynamicsoft.com
References:  <3CAE2F14.A335A079@cisco.com> <3CAF1D6C.90444446@cs.columbia.edu> <3CB1D49A.C9BA1BC2@cisco.com> <3CB232B8.C4D665B6@cs.columbia.edu> <3CB34759.E8512A1C@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5279
Subject: [Simple] State labels (Was: notes from the SIMPLE components adhoc at IETF53)
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: 

> I am somewhat concerned about the usage model if we attempt to preserve both kinds of status information - what I am doing & what I am willing to do. I don't think it is
> reasonable to expect a user to manually set both, nor do I see how one can be derived from the other.

I agree - they are largely orthogonal.

> In the case of IM, there has often been an expectation that you manually log on when you are present and log off when you are not, and that this implicitly provides one
> mechanism for updating presence. After that, and other nuances (e.g. away from desk) are handled by explicit user interaction. The status values are simple, so they are
> easy to manage manually (e.g. by picking from a menu.)

While this is true today, I can well imagine more sophisticated
mechanisms, e.g., by referring to the user's appointment book or
biometric sensors (for "sleeping", "talking", "not in good mood",
"legally drunk"). Others, like "in phone call", are hard to derive for
separate IM/voice systems, but trivial for integrated systems.

> 
> In the case of callerprefs, while the mechanism has been under development for some time, there is little practical usage experience. The environment in which it is
> intended to operate is somewhat different - typically a phone remains connected and accessible whether there is a user attending it or not. Also, the notation for
> expressing callerprefs is not so simple - it isn't easily mapped to a simple UI. Simple use of callerprefs will probably be static configuration.

Most of the parameters are pretty static and often tied to the device
properties ("mobile"), so there isn't as much need for a UI.

> 
> However, I have in mind more active use of callerprefs - picking up the phone may change my availability. Exactly how it changes it should be a configurable option. I may
> choose to be unavailable for voice calls whenever I am on a voice call. Or, I may be willing to participate in up to 2 voice calls at a time. My UA could be configured to
> update my registration to honor my preferences in this regard.

Agreed.

> 
> Other aspects of my callerprefs can't be so easily inferred. If I only want to take personal calls and calls from my bookie when I am on vacation, then I need a UI that
> lets me express that kind of logic.
> 
> The trick is - do I have one UI or two?



> 
> Worst case - when I am getting set to go on vacation, I use one UI to update my callerprefs, requesting only personal calls plus calls from my bookie. (This is what I am
> *willing* to do.) Then, with a different UI I update my presence, to status "On Vacation".

Wait a second - caller preferences don't influence what I'm willing to
accept directly, except in an oblique way. To indicate "only calls from
bookie" would be a CPL thingie, not a caller preferences thing.


> 
> Slightly better - I use one UI, but set two distinct attributes as above.
> 
> Better yet - I use one UI, and select one menu item that causes both attributes to be set.
> 
> Further comments below.
> 


> Yes! If you agree that there is a substantial overlap in functionality between callerprefs and presence, then it becomes a lot more appealing to simply update your
> callerprefs via REGISTER and not bother updating a presence document separately.

I suspect that we have slightly different notions of what caller
preferences does. The REGISTER side in caller preferences describes
properties of various Contact's, which are then matched by corresponding
Accept-Contact etc. in the INVITE.

> 
> > I suspect we need both, with the same mapping, so that
> > Accept/Reject-Contact doesn't need to know whether you registered via
> > document or Contact parameter.
> 
> Not sure I follow. Are you suggesting that uploading a presence document might cause a re-registration if the contact information in the presence document is in conflict
> with the current registration?

I don't understand. If the presence state is somehow reflected in the
variables "visible" during caller preferences handling, this doesn't
have to be a re-registration. Logically, the Accept-/Reject-Contact
processing doesn't really care where the parameters came from, REGISTER,
manual configuration or some other mechanism.

> 
> I am a bit concerned about that. There is a well defined mechanism for updating contact information in a registration piecemeal from different endpoints. But there is no
> similar mechanism for presence documents.
> 
> I would rather change presence so that I can upload the part of the presence document that doesn't come from registration, and say that the rest should come from the
> registrar/location service.
> 
> 

> I agree we have the ability to do it, but don't agree that it is simple. The nuances are straightforward syntactically, but not simply represented in a UI. (They don't map
> to alternative variants of a single icon.)
> 
> "I'm willing to text chat in english or french about business; but I'm only willing to take urgent voice calls,and only in english"

That's a UI issue. I suspect that much of that information is fairly
constant, with a few parameters changing dynamically. As long as the
parameters are orthogonal, you could have

    Language        Purpose
(1) [x] English     Business
OR
(2) [x] French

etc.

From sardana@obsoft.com  Tue Apr  9 21:53:21 2002
Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07270
	for ; Tue, 9 Apr 2002 21:53:20 -0400 (EDT)
Received: from obsoft.com (localhost.localdomain [127.0.0.1])
	by obsoft.com (8.11.6/8.11.6) with ESMTP id g3A1v4t14429;
	Tue, 9 Apr 2002 18:57:04 -0700
Message-ID: <3CB39BF0.4A4435C8@obsoft.com>
Date: Tue, 09 Apr 2002 18:57:04 -0700
From: Bobby Sardana 
Organization: ObjectSoftware, Inc
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Beck01, Wolfgang" 
CC: seancolson@yahoo.com, sipping@ietf.org, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] RE: [Sipping] draft-olson-sipping-content-indirect-00.txt
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 885
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: 

I am sure that the appropriate UAC will implement a "security sandbox" for both the
"execute" and "render" feature set. A properly designed UAC will also allow such
features to be manually disabled.

Personally, I like the "execute" feature as it allows new services to be deployed on
the UAC.

regards,

Bobby Sardana.
sardana@obsoft.com

"Beck01, Wolfgang" wrote:

> Sean,
>
> disposition "execute" in REQ-2 is very dangerous. A popular E-mail program
> used to have a similar function enabled by default, which resulted
> in a worldwide breakdown of many mail servers. Even "render" might be dangerous, if
> the document uses some language like PostScript or Word macros.
>
> --
> Wolfgang Beck
> T-Systems Nova GmbH
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple


From hisham.khartabil@nokia.com  Wed Apr 10 03:00:41 2002
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 DAA08120
	for ; Wed, 10 Apr 2002 03:00:40 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3A70fJ22877
	for ; Wed, 10 Apr 2002 10:00:41 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 10 Apr 2002 09:59:38 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 10 Apr 2002 09:59:40 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 10 Apr 2002 09:59:39 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] question about winfo-package (resend with revision marks)
Date: Wed, 10 Apr 2002 09:59:38 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB777910E@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] question about winfo-package (resend with revision marks)
Thread-Index: AcHZRECmLKeXD7SsTnuU7OZCmRT3oQGUk19AADGUEyA=
To: , 
Cc: 
X-OriginalArrivalTime: 10 Apr 2002 06:59:39.0910 (UTC) FILETIME=[48AF1A60:01C1E05D]
Content-Length: 5423
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA08120
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: 

The first NOTIFY is sent of course, but there will be no NOTIFYs sent when a change to winfo occurs.

Regards,
Hisham

> -----Original Message-----
> From: Lonnfors Mikko (NRC/Helsinki) 
> Sent: Tuesday, April 09, 2002 10:37 AM
> To: jdrosen@dynamicsoft.com
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] question about winfo-package (resend 
> with revision
> marks)
> 
> 
> Hi,
> 
> Thanks for the answer. I have one more question about 
> draft-ietf-simple-winfo-package-01.
> Chapter 4.7.1 The Subscription State Machine (after figure 1) 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."
> 
> Is this to say that the package on which winfo is applied to 
> should not generate
> any NOTIFY messages to subscriber? This sound a bit weird 
> because SIP events says that NOTIFY
> should be send immediately after 200-class response. (I am 
> here assuming SUB-202 request/response
> if there is no authorization policy is set)
> 
> So in short how should the quoted sentence be interpreted?
> 
> regards
> - Mikko
> 
> > -----Original Message-----
> > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: 01 April, 2002 09:13
> > To: Lonnfors Mikko (NRC/Helsinki)
> > Cc: tanglih@cn.ibm.com; simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] question about winfo-package (resend 
> > with revision
> > marks)
> > 
> > 
> > 
> > 
> > mikko.lonnfors@nokia.com wrote:
> > > 
> > > My opinion about your question is as follows:
> > > 
> > > The motivating application for winfo package is presence 
> > authorization.
> > > If
> > > User B is authorized to subscribe A's presence, as you 
> > said, generally
> > > speaking the PS doesn't need to notify A of the B's 
> > subscription status
> > > for
> > > authorization.
> > > 
> > > 
> > > I would still say that winfo is designed to enable 
> presentity to get
> > > lists of watchers interested in their presence status.
> > > This should happen regardless of the watcher's 
> authorization status.
> > > Presence authorization may be the main motivation
> > > to enable this functionality but not the only one.
> > > 
> > 
> > Yes. However, the decision about when to send NOTIFY for winfo is a
> > server decision; it can decide to not send two notifications 
> > in the case
> > of a fetch.
> > 
> > 
> > > 
> > > If the PS needs to notify A of this FETCH subscription, you 
> > may use the
> > > 'expiration' attribute of winfo foramt. Like this:
> > >   
> > >      
> > >         > >                    event="subscribe" expiration="0"/>
> > >      
> > >    
> > > In this case, A should understanding that a FETCH subscription is
> > > requested.
> > > How about this way to solute your problem?
> > > 
> > > 
> > > I think there are some problems with this approach. I think 
> > that winfo
> > > is designed to
> > > signal changes in watchers subscription status i.e. signal 
> > the state to
> > > which a watcher has moved from previous state.
> > > In this case, as you said,  A should be able to understand that
> > > 
> > >     
> > >         > >                    event="subscribe" expiration="0"/>
> > > 
> > > means FETCH. This would mean special casing expiration="0".
> > 
> > It only needs to be special cased if you are trying to explicitly
> > identify fetch requests. I see no reason to do that. The above
> > notification stands, by itself, as something reasonable. 
> > However, if you
> > want to send a single notification, you are probably better 
> > off sending
> > the one on the transition to terminated due to timeout.
> > 
> > 
> > 
> > > We could take an other example. Let's say that B performs 
> > FETCH but has
> > > no authorization. Should A now get
> > > 
> > >    
> > >         > >                    event="subscribe" expiration="0"/>
> > > 
> > > I would say that sending
> > > 
> > >    
> > >         > >                    event="subscribe"/>
> > > 
> > > would make more sense.
> > 
> > I agree that the second one makes more sense. The first is valid, of
> > course, but if you want to send just one notification, the latter is
> > more useful. Again, the decision about which state change 
> > notifications
> > to send is a matter of local policy.
> > 
> > -Jonathan R.
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > Chief Scientist                         First Floor
> > dynamicsoft                             East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> > http://www.jdrosen.net                  PH:  (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jorge@teltier.com  Wed Apr 10 13:06:14 2002
Received: from teltier.com (teltier.com [161.58.154.42])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09719
	for ; Wed, 10 Apr 2002 13:06:14 -0400 (EDT)
Received: from GUERNICA (fwuser@[65.202.44.138]) by teltier.com (8.11.6) id g3AH5AH28977; Wed, 10 Apr 2002 13:05:10 -0400 (EDT)
Reply-To: 
From: "Jorge Lobo" 
To: , 
Cc: 
Date: Wed, 10 Apr 2002 12:59:07 -0400
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: <200204101600.MAA09548@mailman.dynamicsoft.com>
Content-Length: 1583
Subject: [Simple] RE: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
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: 

Paul and Henning,

I have been following your discussion on call preferences and
presence and I would like to offer an alternative view.

I have been working with PAM, the presence and availability
management standards being adopted by Parley and 3GPP,
(http://www.PAMForum.org).

In PAM there is a separation between "presence" and "availability".
Presence, as mention by Henning, in the IM world is set by the
user, but in many cases can be and will be automatically detected.
The presence of your cellular phone in the network is detected 
automatically.

What availability offers is a layer over presence where the subscriber
describes preferences on how to expose presence. Preference rules to
compute availability can be as simple as opt-in or out to publication of
presence as in current IM systems to extremely to extremely sophisticated
rules where the user can decide how to expose the information based on 
who is requesting the information, the time of the request, 
the location of the requester and the user, etc. - the bookie example is
one this more complicated examples.

In the case of PAM there is a minimal set of controls that a presence
server should provide as an implementation of availability, but it is
left open to the different implementations how sophisticated the
computation of availability can be.

A similar approach here may solve many of your problems.

Regards,

Jorge.

------------------------
Jorge Lobo, Ph.D.
Principal Architect
Teltier Technologies
60 Walnut Avenue, #300
Clark, NJ 07066
mailto:jorge@teltier.com
------------------------



From pkyzivat@cisco.com  Wed Apr 10 18:49:44 2002
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 SAA10706
	for ; Wed, 10 Apr 2002 18:49:44 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3AMmZYe009044;
	Wed, 10 Apr 2002 18:48:36 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI21980;
	Wed, 10 Apr 2002 18:51:29 -0400 (EDT)
Message-ID: <3CB4C12B.5292F18E@cisco.com>
Date: Wed, 10 Apr 2002 18:48:11 -0400
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: Henning Schulzrinne 
CC: simple@mailman.dynamicsoft.com
References:  <3CAE2F14.A335A079@cisco.com> <3CAF1D6C.90444446@cs.columbia.edu> <3CB1D49A.C9BA1BC2@cisco.com> <3CB232B8.C4D665B6@cs.columbia.edu> <3CB34759.E8512A1C@cisco.com> <3CB372A7.F7363C5D@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3308
Subject: [Simple] Re: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
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: 

Henning - comments below.

	Paul

Henning Schulzrinne wrote:
> 
> > Worst case - when I am getting set to go on vacation, I use one UI to update my callerprefs, requesting only personal calls plus calls from my bookie. (This is what I am
> > *willing* to do.) Then, with a different UI I update my presence, to status "On Vacation".
> 
> Wait a second - caller preferences don't influence what I'm willing to
> accept directly, except in an oblique way. To indicate "only calls from
> bookie" would be a CPL thingie, not a caller preferences thing.

You are right. I can't do that in any obvious way with callerprefs.
I can however do the personal call thing:

	Contact: "cell phone";class="personal"
	Contact: ;class="business"

> I suspect that we have slightly different notions of what caller
> preferences does. The REGISTER side in caller preferences describes
> properties of various Contact's, which are then matched by corresponding
> Accept-Contact etc. in the INVITE.

The register side describes properties of the contact - properties
that I am willing to admit to (willing to do.) (I do English & Spanish, I do business at
this contact, personal stuff at that one, etc.)

It isn't super rich in expressiveness, but it isn't all the impoverished either. 

> > > I suspect we need both, with the same mapping, so that
> > > Accept/Reject-Contact doesn't need to know whether you registered via
> > > document or Contact parameter.
> >
> > Not sure I follow. Are you suggesting that uploading a presence document might cause a re-registration if the contact information in the presence document is in conflict
> > with the current registration?
> 
> I don't understand. If the presence state is somehow reflected in the
> variables "visible" during caller preferences handling, this doesn't
> have to be a re-registration. Logically, the Accept-/Reject-Contact
> processing doesn't really care where the parameters came from, REGISTER,
> manual configuration or some other mechanism.

I think we must till be talking past one another.

You seem to be saying that the Accept-/Reject-Contact processing, which occurs in a proxy, typically using contact info from a location service, might have got its contact
info from the uploading of a presence document. 

Now either this means that the uploading of the presence document revised the location service, or else proxies that are privy to presence information might work
differently than those that only have access to the location service.

And, if uploading the presence document revises the location service, then there must be some rule for how presence document uploads and registrations are merged into the
location service.

If some proxies use the presence information in addition to location service information to evaluate callerprefs, then again there must be rules for how the two information
sources are merged.

========

Something just occurred to me: 

Perhaps callerprefs in a presence subscription could be used as a filter on presence information. So for example I could subscribe to your presence for class="business",
or for media="voice".

This might work reasonably well - then a smaller set of actual presence states would be useful - even just offline/pending/open/closed.

	Paul

From pkyzivat@cisco.com  Wed Apr 10 19:13:59 2002
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 TAA10835
	for ; Wed, 10 Apr 2002 19:13:59 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3ANCpfM010098;
	Wed, 10 Apr 2002 19:12:51 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI22059;
	Wed, 10 Apr 2002 19:15:45 -0400 (EDT)
Message-ID: <3CB4C6DB.A0A7C7D1@cisco.com>
Date: Wed, 10 Apr 2002 19:12:27 -0400
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: jorge@teltier.com
CC: hgs@cs.columbia.edu, simple@mailman.dynamicsoft.com
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1883
Subject: [Simple] Re: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
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: 

Jorge,

I just took a quick look at the PAM specification.

While it would take a much longer look to fully understand the mappings, I agree that there does seem to be some commonality here.

	Paul

Jorge Lobo wrote:
> 
> Paul and Henning,
> 
> I have been following your discussion on call preferences and
> presence and I would like to offer an alternative view.
> 
> I have been working with PAM, the presence and availability
> management standards being adopted by Parley and 3GPP,
> (http://www.PAMForum.org).
> 
> In PAM there is a separation between "presence" and "availability".
> Presence, as mention by Henning, in the IM world is set by the
> user, but in many cases can be and will be automatically detected.
> The presence of your cellular phone in the network is detected
> automatically.
> 
> What availability offers is a layer over presence where the subscriber
> describes preferences on how to expose presence. Preference rules to
> compute availability can be as simple as opt-in or out to publication of
> presence as in current IM systems to extremely to extremely sophisticated
> rules where the user can decide how to expose the information based on
> who is requesting the information, the time of the request,
> the location of the requester and the user, etc. - the bookie example is
> one this more complicated examples.
> 
> In the case of PAM there is a minimal set of controls that a presence
> server should provide as an implementation of availability, but it is
> left open to the different implementations how sophisticated the
> computation of availability can be.
> 
> A similar approach here may solve many of your problems.
> 
> Regards,
> 
> Jorge.
> 
> ------------------------
> Jorge Lobo, Ph.D.
> Principal Architect
> Teltier Technologies
> 60 Walnut Avenue, #300
> Clark, NJ 07066
> mailto:jorge@teltier.com
> ------------------------

From jorge@teltier.com  Wed Apr 10 20:00:54 2002
Received: from teltier.com (teltier.com [161.58.154.42])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11032
	for ; Wed, 10 Apr 2002 20:00:54 -0400 (EDT)
Received: from GUERNICA (fwuser@[65.202.44.138]) by teltier.com (8.11.6) id g3ANxqj15152; Wed, 10 Apr 2002 19:59:52 -0400 (EDT)
Reply-To: 
From: "Jorge Lobo" 
To: "Paul Kyzivat" 
Cc: , 
Date: Wed, 10 Apr 2002 19:53:46 -0400
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)
Importance: Normal
In-Reply-To: <3CB4C6DB.A0A7C7D1@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 3182
Subject: [Simple] RE: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
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: 

A quick mapping from some of the concepts of PAM to SIMPLE.

PAM is based on Identities, and Identities have Agents
associated with them.  Agents are electronic representations
of (software or hardware) devices. Agents are the producers
of "raw" presence, and the presence of an Identity is derived
from the devices the Identity owns.

Identities  ---> Presentities
Agents      ---> Presence User Agent

Some applications may have direct access to presence but most
applications will be allowed only access to availability.

The basic API calls from PAM relevant to SIMPLE are

set and get presence

set and get preferences

get availability

One more thing.  There is a special class of presence data associated
with agents in PAM called capabilities - given that the capabilities of
an agent (Presence User Agent) can vary with time. For example, a capability
can be J2ME-cable, an attribute of the capability can be
communicationAddress
which can be a dynamic IP address assigned to the agent for communication.

Best,

Jorge.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Wednesday, April 10, 2002 7:12 PM
To: jorge@teltier.com
Cc: hgs@cs.columbia.edu; simple@mailman.dynamicsoft.com
Subject: Re: State labels (Was: notes from the SIMPLE components adhoc
at IETF53)


Jorge,

I just took a quick look at the PAM specification.

While it would take a much longer look to fully understand the mappings, I
agree that there does seem to be some commonality here.

	Paul

Jorge Lobo wrote:
>
> Paul and Henning,
>
> I have been following your discussion on call preferences and
> presence and I would like to offer an alternative view.
>
> I have been working with PAM, the presence and availability
> management standards being adopted by Parley and 3GPP,
> (http://www.PAMForum.org).
>
> In PAM there is a separation between "presence" and "availability".
> Presence, as mention by Henning, in the IM world is set by the
> user, but in many cases can be and will be automatically detected.
> The presence of your cellular phone in the network is detected
> automatically.
>
> What availability offers is a layer over presence where the subscriber
> describes preferences on how to expose presence. Preference rules to
> compute availability can be as simple as opt-in or out to publication of
> presence as in current IM systems to extremely to extremely sophisticated
> rules where the user can decide how to expose the information based on
> who is requesting the information, the time of the request,
> the location of the requester and the user, etc. - the bookie example is
> one this more complicated examples.
>
> In the case of PAM there is a minimal set of controls that a presence
> server should provide as an implementation of availability, but it is
> left open to the different implementations how sophisticated the
> computation of availability can be.
>
> A similar approach here may solve many of your problems.
>
> Regards,
>
> Jorge.
>
> ------------------------
> Jorge Lobo, Ph.D.
> Principal Architect
> Teltier Technologies
> 60 Walnut Avenue, #300
> Clark, NJ 07066
> mailto:jorge@teltier.com
> ------------------------


From tanglih@cn.ibm.com  Wed Apr 10 22:28:55 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11485
	for ; Wed, 10 Apr 2002 22:28:21 -0400 (EDT)
Received: from d23rh902.au.ibm.com 
        by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id g3B2MK363670;
        Thu, 11 Apr 2002 12:22:20 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.185.50.18])
	by d23rh902.au.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g3B1lIA15152;
	Thu, 11 Apr 2002 11:47:18 +1000
Subject: Re: [Simple] RE: State labels (Was: notes from the SIMPLE components adhoc
 at IETF53)
To: 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Thu, 11 Apr 2002 09:47:15 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.8 |June 18, 2001) at
 11/04/2002 09:47:18
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 5044
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: 

Jorge,

Tell the truth I am little confused by the concepts you mentioned,
presence, availability and capability in PAM world. Could you please give
me a scenario in the real world?

And how to control the different access to presence and availability? Has
authorization and authentication been considered in PAM?


Best regards,

Tang Lihua



                                                                                                          
                    "Jorge Lobo"                                                                          
                                  To:     "Paul Kyzivat"           
                    Sent by:                         cc:     ,                       
                    simple-admin@mailman.dynam                            
                    icsoft.com                       Subject:     [Simple] RE: State labels (Was: notes   
                                                      from the SIMPLE components adhoc at IETF53)         
                                                                                                          
                    2002-04-11 07:53                                                                      
                    Please respond to jorge                                                               
                                                                                                          
                                                                                                          




A quick mapping from some of the concepts of PAM to SIMPLE.

PAM is based on Identities, and Identities have Agents
associated with them.  Agents are electronic representations
                 --------
               >>Indentities here?
of (software or hardware) devices. Agents are the producers
of "raw" presence, and the presence of an Identity is derived
from the devices the Identity owns.

Identities  ---> Presentities
Agents      ---> Presence User Agent

Some applications may have direct access to presence but most
applications will be allowed only access to availability.

The basic API calls from PAM relevant to SIMPLE are

set and get presence

set and get preferences

get availability

One more thing.  There is a special class of presence data associated
with agents in PAM called capabilities - given that the capabilities of
an agent (Presence User Agent) can vary with time. For example, a
capability
can be J2ME-cable, an attribute of the capability can be
communicationAddress
which can be a dynamic IP address assigned to the agent for communication.

Best,

Jorge.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Wednesday, April 10, 2002 7:12 PM
To: jorge@teltier.com
Cc: hgs@cs.columbia.edu; simple@mailman.dynamicsoft.com
Subject: Re: State labels (Was: notes from the SIMPLE components adhoc
at IETF53)


Jorge,

I just took a quick look at the PAM specification.

While it would take a much longer look to fully understand the mappings, I
agree that there does seem to be some commonality here.

           Paul

Jorge Lobo wrote:
>
> Paul and Henning,
>
> I have been following your discussion on call preferences and
> presence and I would like to offer an alternative view.
>
> I have been working with PAM, the presence and availability
> management standards being adopted by Parley and 3GPP,
> (http://www.PAMForum.org).
>
> In PAM there is a separation between "presence" and "availability".
> Presence, as mention by Henning, in the IM world is set by the
> user, but in many cases can be and will be automatically detected.
> The presence of your cellular phone in the network is detected
> automatically.
>
> What availability offers is a layer over presence where the subscriber
> describes preferences on how to expose presence. Preference rules to
> compute availability can be as simple as opt-in or out to publication of
> presence as in current IM systems to extremely to extremely sophisticated
> rules where the user can decide how to expose the information based on
> who is requesting the information, the time of the request,
> the location of the requester and the user, etc. - the bookie example is
> one this more complicated examples.
>
> In the case of PAM there is a minimal set of controls that a presence
> server should provide as an implementation of availability, but it is
> left open to the different implementations how sophisticated the
> computation of availability can be.
>
> A similar approach here may solve many of your problems.
>
> Regards,
>
> Jorge.
>
> ------------------------
> Jorge Lobo, Ph.D.
> Principal Architect
> Teltier Technologies
> 60 Walnut Avenue, #300
> Clark, NJ 07066
> mailto:jorge@teltier.com
> ------------------------

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





From mark.beckmann@sal.siemens.de  Wed Apr 10 22:44:38 2002
Received: from david.siemens.de (david.siemens.de [192.35.17.14])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11613
	for ; Wed, 10 Apr 2002 22:44:38 -0400 (EDT)
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by david.siemens.de (8.11.6/8.11.6) with ESMTP id g3B2hdd19151
	for ; Thu, 11 Apr 2002 04:43:39 +0200 (MET DST)
Received: from hvrz00da.hvr.siemens.de (hvrz00da.hvr.siemens.de [129.103.192.197])
	by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g3B2hdn09655
	for ; Thu, 11 Apr 2002 04:43:39 +0200 (MEST)
Received: by hvrz00da.hvr.siemens.de with Internet Mail Service (5.5.2653.19)
	id <2QC93XLM>; Thu, 11 Apr 2002 04:43:39 +0200
Message-ID: 
From: BECKMANN MARK 
To: simple@mailman.dynamicsoft.com
Date: Thu, 11 Apr 2002 04:43:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1421
Subject: [Simple] Presence data format extension
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: 

Hello,

this may be rather a question to the impp WG, but hopefully someone on this
list can also help me, so that I dont have to subscribe to yet another
list;). 

I would like to know if my understanding is correct that basically each
implementor is free to develop his/her own presence data format extension in
particular additional value types and that the extensions are then just
identified by a unique xmlns without having to register the new status value
types and/or create a new RFC to describe those extensions.

Now, if my understanding is correct I wonder whether it is necessary to
define any status values beyond a very limited set at all. The schema
attribute allows each recipient of presence data to find out about the data
format. The limited set of specified status values would allow
interoperability without having to check the data format or semantic
description. For any status information beyond that, interoperability is
achieved by providing information about the data format in the schema
attribute. Of course it is then still open how a user will find out about
the meaning of the status values. Couldn't an additional link pointing to
the semantic description of the extensions solve this problem? 

Thanks,

Mark

Mark Beckmann			Siemens AG

ICM MP PO8 SA 82
P.O.Box 100702			phone: +49 (5341) 906 1814
D-38228 Salzgitter   		fax:   +49 (5341) 906 2010

mailto: Mark.Beckmann@siemens.com



From sriramp@nortelnetworks.com  Thu Apr 11 15:58:45 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14647
	for ; Thu, 11 Apr 2002 15:58:44 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3BJvh415774
	for ; Thu, 11 Apr 2002 14:57:43 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <2JXVMV39>; Thu, 11 Apr 2002 14:57:49 -0500
Message-ID: 
From: "Sriram Parameswar"
To: simple@mailman.dynamicsoft.com
Date: Thu, 11 Apr 2002 14:57:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1E193.2489FE70"
Content-Length: 3684
Subject: [Simple] draft-ietf-simple-presence-06 WGLC comments
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: 

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_01C1E193.2489FE70
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,

The draft looks good. My comments/questions are as follows:
*	Section 4 - "In fact, behavior of the presence agent for handing a
SUBSCRIBE with Expires of zero is no different than for any other expiration
value; all SUBSCRIBE requests result in a triggered NOTIFY with the current
presentity and subscription state". My question is on a presence 'fetch' -
what happens if a SUBSCRIBE is not authorized so the first NOTIFY contains
either 'bogus' presence information or no body - if an automaton then
performs an authorization (using some mechanism) and sends another NOTIFY
with actual presence information - is this valid? Either way (valid or not
valid) it would be good to have a line of clarification on how Presence
fetches in the un-authorized case are handled.
*	RFC 2119 key words (MUST, SHOULD etc.) lack a space after them in
sections - 7.2, 9.2, 9.5.

Thanks,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


------_=_NextPart_001_01C1E193.2489FE70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






draft-ietf-simple-presence-06 WGLC comments




Hi All,




The draft looks good. My =
comments/questions are as follows:


  • Section 4 - "In fact, behavior of the presence agent for =
handing a SUBSCRIBE with Expires of zero is no different than for any =
other expiration value; all SUBSCRIBE requests result in a triggered =
NOTIFY with the current presentity and subscription =
state". My question is on a =
presence 'fetch' - what happens if a SUBSCRIBE is not authorized so the =
first NOTIFY contains either 'bogus' presence information or no body - =
if an automaton then performs an authorization (using some mechanism) =
and sends another NOTIFY with actual presence information - is this =
valid? Either way (valid or not valid) it would be good to have a line =
of clarification on how Presence fetches in the un-authorized case are =
handled.
    • 

  • RFC 2119 key words (MUST, SHOULD =
etc.) lack a space after them in sections - 7.2, 9.2, 9.5.
    • 

    



Thanks,




Sriram




__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: =
972-685-8540

Interactive Multimedia Server (IMS) =
Fax: 972-684-3986

Nortel Networks, Richardson =
USA  Email: =
sriramp@nortelnetworks.com





------_=_NextPart_001_01C1E193.2489FE70--

From jorge@teltier.com  Thu Apr 11 18:12:20 2002
Received: from teltier.com (teltier.com [161.58.154.42])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15090
	for ; Thu, 11 Apr 2002 18:12:20 -0400 (EDT)
Received: from GUERNICA (fwuser@[65.202.44.138]) by teltier.com (8.11.6) id g3BMArf29294; Thu, 11 Apr 2002 18:10:53 -0400 (EDT)
Reply-To: 
From: "Jorge Lobo" 
To: "Li Hua Tang" 
Cc: 
Subject: RE: [Simple] RE: State labels (Was: notes from the SIMPLE components adhoc at IETF53)
Date: Thu, 11 Apr 2002 18:04:48 -0400
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)
In-Reply-To: 
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 5089
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: 

Dear Tang Lihua,

authentication is done in a different place through a framework. PAM, as
specified by the PAMForum, has a simple authentication framework, but
inside Parley and 3GPP, the framework works across all the services
provided by them. Usually after authenticating with the framework a
token is returned to the requester and it is used in every API call.
The framework is also used to discover services such as PAM.  Other
services are call control, billing, etc.

Jorge.
-----Original Message-----
From: Li Hua Tang [mailto:tanglih@cn.ibm.com]
Sent: Wednesday, April 10, 2002 9:47 PM
To: jorge@teltier.com
Cc: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] RE: State labels (Was: notes from the SIMPLE
components adhoc at IETF53)



Jorge,

Tell the truth I am little confused by the concepts you mentioned,
presence, availability and capability in PAM world. Could you please give
me a scenario in the real world?

And how to control the different access to presence and availability? Has
authorization and authentication been considered in PAM?


Best regards,

Tang Lihua




                    "Jorge Lobo"
                                  To:     "Paul Kyzivat"

                    Sent by:                         cc:
,
                    simple-admin@mailman.dynam

                    icsoft.com                       Subject:     [Simple]
RE: State labels (Was: notes
                                                      from the SIMPLE
components adhoc at IETF53)

                    2002-04-11 07:53
                    Please respond to jorge






A quick mapping from some of the concepts of PAM to SIMPLE.

PAM is based on Identities, and Identities have Agents
associated with them.  Agents are electronic representations
                 --------
               >>Indentities here?
of (software or hardware) devices. Agents are the producers
of "raw" presence, and the presence of an Identity is derived
from the devices the Identity owns.

Identities  ---> Presentities
Agents      ---> Presence User Agent

Some applications may have direct access to presence but most
applications will be allowed only access to availability.

The basic API calls from PAM relevant to SIMPLE are

set and get presence

set and get preferences

get availability

One more thing.  There is a special class of presence data associated
with agents in PAM called capabilities - given that the capabilities of
an agent (Presence User Agent) can vary with time. For example, a
capability
can be J2ME-cable, an attribute of the capability can be
communicationAddress
which can be a dynamic IP address assigned to the agent for communication.

Best,

Jorge.

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Wednesday, April 10, 2002 7:12 PM
To: jorge@teltier.com
Cc: hgs@cs.columbia.edu; simple@mailman.dynamicsoft.com
Subject: Re: State labels (Was: notes from the SIMPLE components adhoc
at IETF53)


Jorge,

I just took a quick look at the PAM specification.

While it would take a much longer look to fully understand the mappings, I
agree that there does seem to be some commonality here.

           Paul

Jorge Lobo wrote:
>
> Paul and Henning,
>
> I have been following your discussion on call preferences and
> presence and I would like to offer an alternative view.
>
> I have been working with PAM, the presence and availability
> management standards being adopted by Parley and 3GPP,
> (http://www.PAMForum.org).
>
> In PAM there is a separation between "presence" and "availability".
> Presence, as mention by Henning, in the IM world is set by the
> user, but in many cases can be and will be automatically detected.
> The presence of your cellular phone in the network is detected
> automatically.
>
> What availability offers is a layer over presence where the subscriber
> describes preferences on how to expose presence. Preference rules to
> compute availability can be as simple as opt-in or out to publication of
> presence as in current IM systems to extremely to extremely sophisticated
> rules where the user can decide how to expose the information based on
> who is requesting the information, the time of the request,
> the location of the requester and the user, etc. - the bookie example is
> one this more complicated examples.
>
> In the case of PAM there is a minimal set of controls that a presence
> server should provide as an implementation of availability, but it is
> left open to the different implementations how sophisticated the
> computation of availability can be.
>
> A similar approach here may solve many of your problems.
>
> Regards,
>
> Jorge.
>
> ------------------------
> Jorge Lobo, Ph.D.
> Principal Architect
> Teltier Technologies
> 60 Walnut Avenue, #300
> Clark, NJ 07066
> mailto:jorge@teltier.com
> ------------------------

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






From hisham.khartabil@nokia.com  Fri Apr 12 06:17:35 2002
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 GAA16981
	for ; Fri, 12 Apr 2002 06:17:29 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3CAGj514549
	for ; Fri, 12 Apr 2002 13:16:45 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 12 Apr 2002 13:16:28 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 12 Apr 2002 13:16:28 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 12 Apr 2002 13:16:28 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 12 Apr 2002 13:16:27 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB777912D@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on presence-06
Thread-Index: AcHiCxtmToYAyeNoTr+N6u5Zk0ydkw==
To: , 
X-OriginalArrivalTime: 12 Apr 2002 10:16:28.0290 (UTC) FILETIME=[1BDA6620:01C1E20B]
Content-Length: 2865
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA16981
Subject: [Simple] Comments on presence-06
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: 

I hope this is not too late.


3. Definitions

In a normal interpretation on client and server, a client requests and a server responds. They perform opposite tasks.

This leads to the confusion in understanding definitions of Presence Client and Presence Server. In this specification, they do the same thing and that is to respond to SUBSCRIBE requests and generate NOTIFY requests.

I understand that they share the common name of Presence Agent, but calling them Presence Client and Server does not make sense to me. My suggestion would be to keep Presence Server as is and change Presence Client to something like Presence Edge Server (or something similar to highlight the fact that it is the end point).

Presence Client definition is not used in the description through out the document. Section 6.11 hardly uses it when talking about migrations.

4. Overview of Operation

Third paragraph states 

  "If authorization could not be obtained at this
   time, the subscription is considered "pending", and a 202 response is
   returned. "

then

  "As the state of the presentity changes, the PA
   generates NOTIFYs for all subscribers with authorized subscriptions.
   The state of the subscription itself is carried in the Subscription-
   State header of the NOTIFY, and would typically indicate whether the
   subscription is active or pending."

Now, if NOTIFYs are generated, as a result of a change in state of presentity, to authorised subscribers only, why would you ever send an state update NOTIFY with subscription-state of pending. If the last sentence was not talking about NOTIFY updates, it should be split from the sentence above it.


5. Usage of Presence URLs
If the protocol-independent form is used in the R-URI, how do you know where the next hop is? do you still apply procedures in sip-srv draft on the pres url?


6.3
"The body of a SUBSCRIBE request MAY contain a body" should say "A SUBSCRIBE request MAY contain a body"

6.6.2
Third paragraph

  "For pending subscriptions, the
   state of the presentity SHOULD include some kind of textual note that
   indicates a pending status."

Why is that necessary to merit a SHOULD? It sounds like redundant info to me. Subscription-state header carries that info already.

6.11
- "On occasion" should be "On occasions".

- paragraph 4 states 
  "However, just because a PUA indicates it can accept
   subscriptions, does not mean a PA should migrate the subscriptions
   there."

Why not? I thought this was the dynamic means defining the condition of the migration to take place in this package.


9.5 and 9.6.1 is full of missed spaces. eg. "SUBSCRIBEand"


13.
Reference 3 should be "Common Presence and Instant Messaging (CPIM)"



General comment:
- Fetch of presence info is not mentioned at all in the document. Is the intentional?


That's all I have.

Regards,
Hisham Khartabil

From bateman@acm.org  Fri Apr 12 07:11:45 2002
Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17190
	for ; Fri, 12 Apr 2002 07:11:44 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 16vyx2-0007dG-00; Fri, 12 Apr 2002 12:10:44 +0100
Received: from modem-3747.porcupine.dialup.pol.co.uk ([217.134.206.163] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 16vyx1-0005If-00; Fri, 12 Apr 2002 12:10:43 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'BECKMANN MARK'" ,
        
Subject: RE: [Simple] Presence data format extension
Date: Fri, 12 Apr 2002 12:09:22 +0100
Organization: VisionTech Limited
Message-ID: <000601c1e212$86102be0$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: 
Importance: Normal
Content-Length: 2712
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: 

On 11 April 2002 03:43, BECKMANN MARK wrote:
> Hello,
> 
> this may be rather a question to the impp WG, but hopefully someone on
this
> list can also help me, so that I dont have to subscribe to yet another
> list;). 
> 
> I would like to know if my understanding is correct that basically
each
> implementor is free to develop his/her own presence data format
extension in
> particular additional value types and that the extensions are then
just
> identified by a unique xmlns without having to register the new status
value
> types and/or create a new RFC to describe those extensions.

Well, yes, anyone can create a new extension to the presence data format
using xmlns and abiding by the extensibility mechanism described in the
draft. As far as status values are concerned, we're just working up a
more refined solution to that in the published draft (in fact, we'd
welcome comments from anyone on the recent discussion - you can get to
the mailing list archives from http://www.imppwg.org/), but you can
provide different status value ranges too.

> Now, if my understanding is correct I wonder whether it is necessary
to
> define any status values beyond a very limited set at all. The schema
> attribute allows each recipient of presence data to find out about the
data
> format. The limited set of specified status values would allow
> interoperability without having to check the data format or semantic
> description. For any status information beyond that, interoperability
is
> achieved by providing information about the data format in the schema
> attribute. Of course it is then still open how a user will find out
about
> the meaning of the status values. Couldn't an additional link pointing
to
> the semantic description of the extensions solve this problem? 

In terms of interop, I fully expect there to be standard extensions
published. In fact, while we only deal with the RFC 2778 terms OPEN and
CLOSED directly, I think a set of standard IM status values is essential
including the usual things like "busy" and "away". We didn't want to
hold up the already tortuously slow process of producing the IMPP
presence draft by trying to get agreement on this, which is why it will
be an extension. It will be important for different user agents which
might use different protocols on opposite sides of a CPIM gateway to
have agreed on the meaning of the status values.

I've seen it mentioned that this might be a possible work item for this
group. I expect the discussion would be a bit of a religious debate
including things like "do we need busy and do-not-disturb, are these the
same thing, and if they are, which do we use" but it will have to be
done in the end.

Regards,

Adrian.



From AVSHALOM@il.ibm.com  Sun Apr 14 10:58:52 2002
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25216
	for ; Sun, 14 Apr 2002 10:58:51 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id QAA38662
	for ; Sun, 14 Apr 2002 16:57:49 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3EEvnU32486
	for ; Sun, 14 Apr 2002 16:57:49 +0200
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Sun, 14 Apr 2002 17:57:42 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 14/04/2002 17:57:48,
	Serialize complete at 14/04/2002 17:57:48
Content-Type: multipart/alternative; boundary="=_alternative 00522F2AC2256B9B_="
Content-Length: 13201
Subject: [Simple] Status summary
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: 

This is a multipart message in MIME format.
--=_alternative 00522F2AC2256B9B_=
Content-Type: text/plain; charset="us-ascii"

In the SIMPLE components adhoc meeting at IETF53, I have volunteered to 
summarize the various statuses used in various systems. The summary is 
below.

While going over the various statuses it occurred to me that we need a 
more 
precise definition of what we mean when we say status. The various status 
values 
in the various systems can be divided into:

* Mood - Happy, Sad etc.

* Hint - I am on the phone therefore I will probably not be able to 
respond 
  immediately. The way that the my client will display the message to me 
e.g.
  in Away mode some clients will display the message in a different way 
from
  the way they do in normal online mode. 

* Availability - Am I open or close to communication. The availability can 
be 
  simple just open or close or quite complex - I am open to communication 
  depending on who is calling and in which location am I.

While moods and hints can be localized to vendors and clients, it seems 
that 
availability is the part of the status that mostly needs standardization.

The summary:
===========

# AOL - No explicit status - only idle indication by sensing mouse and 
keyboard activity.

# MSN - Open and close statuses + hints
        * Online (OPEN)
        * Busy (CLOSED)
        * Be Right Back (OPEN)
        * Away (OPEN)
        * On the Phone (CLOSED)
        * Out to Lunch (OPEN)
        * Appear Offline (Lurking, CLOSED)

# YAHOO - Open and close + hints for open.
        * Offline (CLOSED)
        * Available (OPEN) 
        * Busy with various messages (configurable) e.g. Be Right Back, Busy 
          etc. (OPEN) 
        * Invisible (Lurking can be done only in login time) 

# ICQ - Open and close statuses. Open statuses are accompanied by hints. 
For 
  example if I am in DND, I will still get messages but the messages will 
not be 
  displayed on my screen.
        Simple Mode
                * Available
                * Away (OPEN, Messages are shown on the screen)
                * Offline
        Advanced Mode
                * Available
                * Free for chat
                * Away
                * N/A (Extended Away)
                * Occupied (Urgent messages)
                * DND (Do Not Disturb)
                * Privacy (Invisible) - Lurking
                * Offline

# Louts Sametime - Open and close + strong DND. Strong DND means that I am 
not 
  able to send a message to a person that is in DND mode
        * Active (OPEN)
        * DND (Online but closed)
        * Away (OPEN, an hint)

# Wireless Village - As defined by the spec status is composed from 
several 
  attributes as: availability, preferred contacts etc. Following is a 
complete 
  list. 
        * User availability
                - AVAILABLE
                - NOT_AVAILABLE
                - DISCREET (selectively available. Likd DND or busy in other systems)
         
        * Preferred Contacts (preferred contact method of the user + address of 
          contact)
                - CALL
                - SMS
                - MMS (Multi Media SMS)
                - IM
                - EMAIL
        * Preferred Language
        * Status Text (free text describing the status)
        * Status Mood (e.g. HAPPY, SAD, etc.)
        * Alias (alias name for the user)
        * Status Content - MMS content or URL to the MMS content that the user 
          has selected as personal status information.
        * Contact Info - Contact information (vCard)

# PAM Forum - As described in a previous message Jorge Lobo" 
  . PAM forum has separate layers of presence 
information and 
  availability. Availability can be computed by a very simple methods or 
by very 
  complex conditions as if the message is from X try to get me on any 
available 
  device that I am on if not, leave a message on my desktop.

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com

--=_alternative 00522F2AC2256B9B_=
Content-Type: text/html; charset="us-ascii"



In the SIMPLE components adhoc meeting at IETF53, I have volunteered to 

summarize the various statuses used in various systems. The summary is below.



While going over the various statuses it occurred to me that we need a more 

precise definition of what we mean when we say status. The various status values 

in the various systems can be divided into:



* Mood - Happy, Sad etc.



* Hint - I am on the phone therefore I will probably not be able to respond 

  immediately. The way that the my client will display the message to me e.g.

  in Away mode some clients will display the message in a different way from

  the way they do in normal online mode. 



* Availability - Am I open or close to communication. The availability can be 

  simple just open or close or quite complex - I am open to communication 

  depending on who is calling and in which location am I.



While moods and hints can be localized to vendors and clients, it seems that 

availability is the part of the status that mostly needs standardization.



The summary:

===========



# AOL - No explicit status - only idle indication by sensing mouse and keyboard activity.



# MSN - Open and close statuses + hints

        * Online (OPEN)

        * Busy (CLOSED)

        * Be Right Back (OPEN)

        * Away (OPEN)

        * On the Phone (CLOSED)

        * Out to Lunch (OPEN)

        * Appear Offline (Lurking, CLOSED)



# YAHOO - Open and close + hints for open.

        * Offline (CLOSED)

        * Available (OPEN)        

        * Busy with various messages (configurable) e.g. Be Right Back, Busy 

          etc. (OPEN)        

        * Invisible (Lurking can be done only in login time) 



# ICQ - Open and close statuses. Open statuses are accompanied by hints. For 

  example if I am in DND, I will still get messages but the messages will not be 

  displayed on my screen.

        Simple Mode

                * Available

                * Away (OPEN, Messages are shown on the screen)

                * Offline

        Advanced Mode

                * Available

                * Free for chat

                * Away

                * N/A (Extended Away)

                * Occupied (Urgent messages)

                * DND (Do Not Disturb)

                * Privacy (Invisible) - Lurking

                * Offline



# Louts Sametime - Open and close + strong DND. Strong DND means that I am not 

  able to send a message to a person that is in DND mode

        * Active (OPEN)

        * DND (Online but closed)

        * Away (OPEN, an hint)



# Wireless Village - As defined by the spec status is composed from several 

  attributes as: availability, preferred contacts etc. Following is a complete 

  list.  

        * User availability

                - AVAILABLE

                - NOT_AVAILABLE

                - DISCREET (selectively available. Likd DND or busy in other systems)

                

        * Preferred Contacts (preferred contact method of the user + address of 

          contact)

                - CALL

                - SMS

                - MMS (Multi Media SMS)

                - IM

                - EMAIL

        * Preferred Language

        * Status Text (free text describing the status)

        * Status Mood (e.g. HAPPY, SAD, etc.)

        * Alias (alias name for the user)

        * Status Content - MMS content or URL to the MMS content that the user 

          has selected as personal status information.

        * Contact Info - Contact information (vCard)



# PAM Forum - As described in a previous message Jorge Lobo" 

  <jorge@teltier.com>. PAM forum has separate layers of presence information and 

  availability. Availability can be computed by a very simple methods or by very 

  complex conditions as if the message is from X try to get me on any available 

  device that I am on if not, leave a message on my desktop.



Avshalom Houri

Presence and Instant Messaging Architect

Lotus Sametime, IBM Software Group

avshalom@il.ibm.com


--=_alternative 00522F2AC2256B9B_=--

From bcampbell@dynamicsoft.com  Sun Apr 14 14:37:55 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25888
	for ; Sun, 14 Apr 2002 14:37:54 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3EIaeX62727;
	Sun, 14 Apr 2002 13:36:41 -0500 (CDT)
From: "Ben Campbell" 
To: "Avshalom Houri" , 
Subject: RE: [Simple] Status summary
Date: Sun, 14 Apr 2002 13:36:21 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001F_01C1E3B9.5D33B810"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: 
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 15963
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_001F_01C1E3B9.5D33B810
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I cannot speak for the other systems, but Yahoo Messenger allows you to
select open or closed when you create a user configurable message. Also, you
can  become invisible (i.e. lurk) at any time, not just at login.
  -----Original Message-----
  From: simple-admin@mailman.dynamicsoft.com
[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Avshalom Houri
  Sent: Sunday, April 14, 2002 9:58 AM
  To: simple@mailman.dynamicsoft.com
  Subject: [Simple] Status summary



  In the SIMPLE components adhoc meeting at IETF53, I have volunteered to
  summarize the various statuses used in various systems. The summary is
below.

  While going over the various statuses it occurred to me that we need a
more
  precise definition of what we mean when we say status. The various status
values
  in the various systems can be divided into:

  * Mood - Happy, Sad etc.

  * Hint - I am on the phone therefore I will probably not be able to
respond
    immediately. The way that the my client will display the message to me
e.g.
    in Away mode some clients will display the message in a different way
from
    the way they do in normal online mode.

  * Availability - Am I open or close to communication. The availability can
be
    simple just open or close or quite complex - I am open to communication
    depending on who is calling and in which location am I.

  While moods and hints can be localized to vendors and clients, it seems
that
  availability is the part of the status that mostly needs standardization.

  The summary:
  ===========

  # AOL - No explicit status - only idle indication by sensing mouse and
keyboard activity.

  # MSN - Open and close statuses + hints
          * Online (OPEN)
          * Busy (CLOSED)
          * Be Right Back (OPEN)
          * Away (OPEN)
          * On the Phone (CLOSED)
          * Out to Lunch (OPEN)
          * Appear Offline (Lurking, CLOSED)

  # YAHOO - Open and close + hints for open.
          * Offline (CLOSED)
          * Available (OPEN)
          * Busy with various messages (configurable) e.g. Be Right Back,
Busy
            etc. (OPEN)
          * Invisible (Lurking can be done only in login time)

  # ICQ - Open and close statuses. Open statuses are accompanied by hints.
For
    example if I am in DND, I will still get messages but the messages will
not be
    displayed on my screen.
          Simple Mode
                  * Available
                  * Away (OPEN, Messages are shown on the screen)
                  * Offline
          Advanced Mode
                  * Available
                  * Free for chat
                  * Away
                  * N/A (Extended Away)
                  * Occupied (Urgent messages)
                  * DND (Do Not Disturb)
                  * Privacy (Invisible) - Lurking
                  * Offline

  # Louts Sametime - Open and close + strong DND. Strong DND means that I am
not
    able to send a message to a person that is in DND mode
          * Active (OPEN)
          * DND (Online but closed)
          * Away (OPEN, an hint)

  # Wireless Village - As defined by the spec status is composed from
several
    attributes as: availability, preferred contacts etc. Following is a
complete
    list.
          * User availability
                  - AVAILABLE
                  - NOT_AVAILABLE
                  - DISCREET (selectively available. Likd DND or busy in
other systems)

          * Preferred Contacts (preferred contact method of the user +
address of
            contact)
                  - CALL
                  - SMS
                  - MMS (Multi Media SMS)
                  - IM
                  - EMAIL
          * Preferred Language
          * Status Text (free text describing the status)
          * Status Mood (e.g. HAPPY, SAD, etc.)
          * Alias (alias name for the user)
          * Status Content - MMS content or URL to the MMS content that the
user
            has selected as personal status information.
          * Contact Info - Contact information (vCard)

  # PAM Forum - As described in a previous message Jorge Lobo"
    . PAM forum has separate layers of presence
information and
    availability. Availability can be computed by a very simple methods or
by very
    complex conditions as if the message is from X try to get me on any
available
    device that I am on if not, leave a message on my desktop.

  Avshalom Houri
  Presence and Instant Messaging Architect
  Lotus Sametime, IBM Software Group
  avshalom@il.ibm.com


------=_NextPart_000_001F_01C1E3B9.5D33B810
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







I=20
cannot speak for the other systems, but Yahoo Messenger allows you to =
select=20
open or closed when you create a user configurable message. Also, you =
can =20
become invisible (i.e. lurk) at any time, not just at =
login.


  
-----Original Message-----
From:=20
  simple-admin@mailman.dynamicsoft.com=20
  [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of =
Avshalom=20
  Houri
Sent: Sunday, April 14, 2002 9:58 AM
To:=20
  simple@mailman.dynamicsoft.com
Subject: [Simple] Status=20
  summary


In =
the SIMPLE=20
  components adhoc meeting at IETF53, I have volunteered to =

summarize the various statuses used in =
various systems.=20
  The summary is below. 

While going=20
  over the various statuses it occurred to me that we need a more=20
  
precise definition of what =
we mean=20
  when we say status. The various status values 
in the various systems can be divided into: =


* Mood - Happy, Sad etc. =


* Hint - I am on the phone therefore I will =
probably=20
  not be able to respond 
 =20
  immediately. The way that the my client will display the message to me =

  e.g. 
  in Away mode =
some clients=20
  will display the message in a different way from 
  the way they do in normal online =
mode.=20
  

* Availability - Am I =
open or=20
  close to communication. The availability can be 
  simple just open or close or quite =
complex - I=20
  am open to communication 
 =20
  depending on who is calling and in which location am I. =


While moods and hints can be localized to =
vendors and=20
  clients, it seems that 
availability is=20
  the part of the status that mostly needs standardization. =


The summary: 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 

# AOL - No=20
  explicit status - only idle indication by sensing mouse and keyboard=20
  activity. 

# MSN - Open =
and close=20
  statuses + hints 
  =
   =20
    * Online (OPEN) 
   =20
      * Busy (CLOSED) 
 =20
        * Be Right Back (OPEN) 
        * Away (OPEN) 
        * On the Phone=20
  (CLOSED) 
    =
    *=20
  Out to Lunch (OPEN) 
  =
 =20
      * Appear Offline (Lurking, CLOSED) 

# YAHOO - Open and close + hints for =
open.=20
  
        * =
Offline=20
  (CLOSED) 
    =
    *=20
  Available (OPEN)         
        * Busy with various messages =
(configurable)=20
  e.g. Be Right Back, Busy 
   =20
        etc. (OPEN)         =

        * Invisible =
(Lurking can be=20
  done only in login time) 

# ICQ -=20
  Open and close statuses. Open statuses are accompanied by hints. For=20
  
  example if I am in =
DND, I will=20
  still get messages but the messages will not be 
  displayed on my screen. =

        Simple =
Mode=20
  
        =
   =20
      * Available 
 =20
                * Away (OPEN, =
Messages are=20
  shown on the screen) 
   =20
              * Offline 
        Advanced =
Mode=20
  
        =
   =20
      * Available 
 =20
                * Free for =
chat=20
  
        =
   =20
      * Away 
   =20
              * N/A (Extended Away) =

  
        =
   =20
      * Occupied (Urgent messages) 
                * DND =
(Do Not=20
  Disturb) 
    =
   =20
          * Privacy (Invisible) - Lurking =

            =
   =20
  * Offline 

# Louts =
Sametime - Open=20
  and close + strong DND. Strong DND means that I am not =

  able to send a message to a person =
that is in=20
  DND mode 
    =
    *=20
  Active (OPEN) 
  =
   =20
    * DND (Online but closed) 
        * Away (OPEN, an hint) =


# Wireless Village - As defined by the spec =
status is=20
  composed from several 
 =20
  attributes as: availability, preferred contacts etc. Following is a =
complete=20
  
  list.   =

        * User =
availability=20
  
        =
   =20
      - AVAILABLE 
 =20
                - =
NOT_AVAILABLE=20
  
        =
   =20
      - DISCREET (selectively available. Likd DND or busy in =
other=20
  systems) 
    =
   =20
          
 =20
        * Preferred Contacts (preferred contact method of =
the=20
  user + address of 
  =
   =20
      contact) 
   =20
              - CALL 
            =
   =20
  - SMS 
      =
 =20
          - MMS (Multi Media SMS) 
            =
   =20
  - IM 
      =
 =20
          - EMAIL 
        * Preferred Language =

        * Status Text =
(free text=20
  describing the status) 
   =20
      * Status Mood (e.g. HAPPY, SAD, etc.) 
        * Alias (alias =
name for the=20
  user) 
      =
  *=20
  Status Content - MMS content or URL to the MMS content that the user=20
  
      =
    has=20
  selected as personal status information. 
        * Contact Info - Contact =
information=20
  (vCard) 

# PAM Forum - =
As described=20
  in a previous message Jorge Lobo" 
  <jorge@teltier.com>. PAM forum has separate =
layers of=20
  presence information and 
 =20
  availability. Availability can be computed by a very simple methods or =
by very=20
  
  complex conditions =
as if the=20
  message is from X try to get me on any available 
  device that I am on if not, leave a =
message on=20
  my desktop. 

Avshalom =
Houri=20
  
Presence and Instant Messaging=20
  Architect 
Lotus Sametime, =
IBM Software=20
  Group 
avshalom@il.ibm.com=20



------=_NextPart_000_001F_01C1E3B9.5D33B810--


From tony@att.com  Sun Apr 14 16:53:35 2002
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26338
	for ; Sun, 14 Apr 2002 16:53:34 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g3EKqX505957
	for ; Sun, 14 Apr 2002 15:52:33 -0500 (CDT)
Received: from att.com ([135.210.96.171])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020414205233gw100opi5be>
          (Authid: tony);
          Sun, 14 Apr 2002 20:52:33 +0000
Message-ID: <3CB9EA79.9080603@att.com>
Date: Sun, 14 Apr 2002 16:45:45 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com, impp@iastate.edu
CC: Avshalom Houri 
Subject: Re: [Simple] Status summary
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 5434
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: 

AT&T's IM Anywhere provides:

     OPEN with hints:
	Available
	Away
	Be right back
	Do not disturb
	On the phone
	you can also create your own custom messages

     CLOSED
	Offline (invisible, lurking)

Any of the states (including Offline) can be chosen at any time.

	Tony Hansen
	tony@att.com

Ben Campbell wrote:

> I cannot speak for the other systems, but Yahoo Messenger allows you to 
> select open or closed when you create a user configurable message. Also, 
> you can  become invisible (i.e. lurk) at any time, not just at login.
> 
>     -----Original Message-----
>     From: simple-admin@mailman.dynamicsoft.com
>     [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Avshalom Houri
>     Sent: Sunday, April 14, 2002 9:58 AM
>     To: simple@mailman.dynamicsoft.com
>     Subject: [Simple] Status summary
> 
> 
>     In the SIMPLE components adhoc meeting at IETF53, I have volunteered to
>     summarize the various statuses used in various systems. The summary
>     is below.
> 
>     While going over the various statuses it occurred to me that we need
>     a more
>     precise definition of what we mean when we say status. The various
>     status values
>     in the various systems can be divided into:
> 
>     * Mood - Happy, Sad etc.
> 
>     * Hint - I am on the phone therefore I will probably not be able to
>     respond
>       immediately. The way that the my client will display the message
>     to me e.g.
>       in Away mode some clients will display the message in a different
>     way from
>       the way they do in normal online mode.
> 
>     * Availability - Am I open or close to communication. The
>     availability can be
>       simple just open or close or quite complex - I am open to
>     communication
>       depending on who is calling and in which location am I.
> 
>     While moods and hints can be localized to vendors and clients, it
>     seems that
>     availability is the part of the status that mostly needs
>     standardization.
> 
>     The summary:
>     ===========
> 
>     # AOL - No explicit status - only idle indication by sensing mouse
>     and keyboard activity.
> 
>     # MSN - Open and close statuses + hints
>             * Online (OPEN)
>             * Busy (CLOSED)
>             * Be Right Back (OPEN)
>             * Away (OPEN)
>             * On the Phone (CLOSED)
>             * Out to Lunch (OPEN)
>             * Appear Offline (Lurking, CLOSED)
> 
>     # YAHOO - Open and close + hints for open.
>             * Offline (CLOSED)
>             * Available (OPEN)        
>             * Busy with various messages (configurable) e.g. Be Right
>     Back, Busy
>               etc. (OPEN)        
>             * Invisible (Lurking can be done only in login time)
> 
>     # ICQ - Open and close statuses. Open statuses are accompanied by
>     hints. For
>       example if I am in DND, I will still get messages but the messages
>     will not be
>       displayed on my screen.
>             Simple Mode
>                     * Available
>                     * Away (OPEN, Messages are shown on the screen)
>                     * Offline
>             Advanced Mode
>                     * Available
>                     * Free for chat
>                     * Away
>                     * N/A (Extended Away)
>                     * Occupied (Urgent messages)
>                     * DND (Do Not Disturb)
>                     * Privacy (Invisible) - Lurking
>                     * Offline
> 
>     # Louts Sametime - Open and close + strong DND. Strong DND means
>     that I am not
>       able to send a message to a person that is in DND mode
>             * Active (OPEN)
>             * DND (Online but closed)
>             * Away (OPEN, an hint)
> 
>     # Wireless Village - As defined by the spec status is composed from
>     several
>       attributes as: availability, preferred contacts etc. Following is
>     a complete
>       list.  
>             * User availability
>                     - AVAILABLE
>                     - NOT_AVAILABLE
>                     - DISCREET (selectively available. Likd DND or busy
>     in other systems)
>                    
>             * Preferred Contacts (preferred contact method of the user +
>     address of
>               contact)
>                     - CALL
>                     - SMS
>                     - MMS (Multi Media SMS)
>                     - IM
>                     - EMAIL
>             * Preferred Language
>             * Status Text (free text describing the status)
>             * Status Mood (e.g. HAPPY, SAD, etc.)
>             * Alias (alias name for the user)
>             * Status Content - MMS content or URL to the MMS content
>     that the user
>               has selected as personal status information.
>             * Contact Info - Contact information (vCard)
> 
>     # PAM Forum - As described in a previous message Jorge Lobo"
>       . PAM forum has separate layers of presence
>     information and
>       availability. Availability can be computed by a very simple
>     methods or by very
>       complex conditions as if the message is from X try to get me on
>     any available
>       device that I am on if not, leave a message on my desktop.
> 
>     Avshalom Houri
>     Presence and Instant Messaging Architect
>     Lotus Sametime, IBM Software Group
>     avshalom@il.ibm.com
> 



From nsyracus@cnri.reston.va.us  Mon Apr 15 07:30:57 2002
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 HAA00733
	for ; Mon, 15 Apr 2002 07:30:57 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13143;
	Mon, 15 Apr 2002 07:29:55 -0400 (EDT)
Message-Id: <200204151129.HAA13143@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 15 Apr 2002 07:29:54 -0400
Content-Length: 3316
Subject: [Simple] I-D ACTION:draft-ietf-sip-message-02.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg et al.
	Filename	: draft-ietf-sip-message-02.txt
	Pages		: 19
	Date		: 12-Apr-02
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-message-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-message-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020412140710.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-message-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-message-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020412140710.I-D@ietf.org>

--OtherAccess--

--NextPart--



From stpeter@jabber.org  Mon Apr 15 13:38:20 2002
Received: from lor.jeremie.com (lor.jeremie.com [208.245.212.28])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01779
	for ; Mon, 15 Apr 2002 13:38:19 -0400 (EDT)
Received: from localhost (stpeter@localhost)
	by lor.jeremie.com (8.9.3/8.9.3) with ESMTP id MAA05522;
	Mon, 15 Apr 2002 12:37:17 -0500
Date: Mon, 15 Apr 2002 12:37:17 -0500 (CDT)
From: Peter Saint-Andre 
X-Sender: stpeter@lor.jeremie.com
To: Tony Hansen 
cc: simple@mailman.dynamicsoft.com, impp@iastate.edu,
        Avshalom Houri 
Subject: Re: [Simple] Status summary
In-Reply-To: <3CB9EA79.9080603@att.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1136
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: 

FWIW, we provide the following statuses (stati?) in Jabber:

1. Unavailable (maps to CLOSED)

2. Available (maps to OPEN) with sub-statuses:
   - away
   - extended away
   - do not disturb
   - free/desiring to chat

3. Invisible

Any status can be extended with a natural-language description of the
status.

More information at
http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence

Peter

--
Peter Saint-Andre
email+jabber: stpeter@jabber.org
weblog: http://www.saint-andre.com/blog/

On Sun, 14 Apr 2002, Tony Hansen wrote:

> AT&T's IM Anywhere provides:
> 
>      OPEN with hints:
> 	Available
> 	Away
> 	Be right back
> 	Do not disturb
> 	On the phone
> 	you can also create your own custom messages
> 
>      CLOSED
> 	Offline (invisible, lurking)
> 
> Any of the states (including Offline) can be chosen at any time.
> 
> 	Tony Hansen
> 	tony@att.com
> 
> Ben Campbell wrote:
> 
> > I cannot speak for the other systems, but Yahoo Messenger allows you to 
> > select open or closed when you create a user configurable message. Also, 
> > you can  become invisible (i.e. lurk) at any time, not just at login.


From seancolson@yahoo.com  Mon Apr 15 13:55:29 2002
Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01858
	for ; Mon, 15 Apr 2002 13:55:29 -0400 (EDT)
Message-ID: <20020415175425.36353.qmail@web11604.mail.yahoo.com>
Received: from [131.107.3.78] by web11604.mail.yahoo.com via HTTP; Mon, 15 Apr 2002 10:54:25 PDT
Date: Mon, 15 Apr 2002 10:54:25 -0700 (PDT)
From: Sean Olson 
Subject: Re: [Simple] Status summary
To: simple@mailman.dynamicsoft.com, impp@iastate.edu,
        Avshalom Houri 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 396
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: 

There seems to be a common thread here where
we can map communication status (presence) to
one of three states:

   open,
   closed,
   undisclosed (invisible)

Is there a fourth type of state I am missing?

/sean



=====
Sean Olson 

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

From dgboyer@avaya.com  Mon Apr 15 14:03:47 2002
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01912
	for ; Mon, 15 Apr 2002 14:03:47 -0400 (EDT)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06062
	for ; Mon, 15 Apr 2002 14:01:10 -0400 (EDT)
Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06048
	for ; Mon, 15 Apr 2002 14:01:09 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Status summary
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 15 Apr 2002 14:03:22 -0400
Message-ID: <8CA1128D59AD27429985B397118CEDDFC44198@nj7460avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Status summary
Thread-Index: AcHkpue64sgDy5gJQD2+nRb7YR12JAAAR7mw
From: "Boyer, David G (Dave)" 
To: "Sean Olson" , ,
        , "Avshalom Houri" 
Content-Length: 1074
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA01912
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: 

I am curious about something.  How would you catagorize present
but on the phone?  You may not be available for a SIP audio session, but
you would be available for an IM.  Different presence states for diff
communication channels?

Dave

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Monday, April 15, 2002 1:54 PM
> To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> Subject: Re: [Simple] Status summary
> 
> 
> There seems to be a common thread here where
> we can map communication status (presence) to
> one of three states:
> 
>    open,
>    closed,
>    undisclosed (invisible)
> 
> Is there a fourth type of state I am missing?
> 
> /sean
> 
> 
> 
> =====
> Sean Olson 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From bcampbell@dynamicsoft.com  Mon Apr 15 14:42:32 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02045
	for ; Mon, 15 Apr 2002 14:42:32 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3FIfSX65280;
	Mon, 15 Apr 2002 13:41:28 -0500 (CDT)
From: "Ben Campbell" 
To: "Sean Olson" , ,
        , "Avshalom Houri" 
Subject: RE: [Simple] Status summary
Date: Mon, 15 Apr 2002 13:41:07 -0500
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)
In-Reply-To: <20020415175425.36353.qmail@web11604.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 1140
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: 

There may be some concept of Open, but unavailable, at least if you look at
the way Yahoo handles offline, vs. online but setting some unavailable
status. See the off-list conversation between Avshalom and myself that I am
forwarding separately.

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Sean Olson
> Sent: Monday, April 15, 2002 12:54 PM
> To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> Subject: Re: [Simple] Status summary
>
>
> There seems to be a common thread here where
> we can map communication status (presence) to
> one of three states:
>
>    open,
>    closed,
>    undisclosed (invisible)
>
> Is there a fourth type of state I am missing?
>
> /sean
>
>
>
> =====
> Sean Olson 
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple


From bcampbell@dynamicsoft.com  Mon Apr 15 14:45:12 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02079
	for ; Mon, 15 Apr 2002 14:45:10 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3FIi8X65501
	for ; Mon, 15 Apr 2002 13:44:08 -0500 (CDT)
From: "Ben Campbell" 
To: "Simple" 
Subject: FW: [Simple] Status summary
Date: Mon, 15 Apr 2002 13:43:47 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0083_01C1E483.9134CD50"
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
Content-Length: 23737
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0083_01C1E483.9134CD50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The following is a conversation between Avshalom and myself that we took off
list by accident. We both agreed to forward it back to the list.
  -----Original Message-----
  From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
  Sent: Monday, April 15, 2002 10:15 AM
  To: Avshalom Houri
  Subject: RE: [Simple] Status summary


  Agreed--but in the Yahoo environment, the sender can not tell for sure if
the message gets delivered immediately or gets store-and-forwarded. So from
the sender's perspective, the two situations are the same. On the other
hand, the _network_ treats the two differently.

  This is very different than, say, Windows Messenger, which if the
recipient appears to be offline, dumps you into an email editor instead of
the IM conversation client.
    -----Original Message-----
    From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
    Sent: Monday, April 15, 2002 10:11 AM
    To: Ben Campbell
    Subject: RE: [Simple] Status summary



    I think that even if the system is able to deliver the message somehow
using offline messages it is not different from email and the state should
be regarded as closed.  I am not sure about this distinction in a wireless
systems where IM might be translated to an SMS that will be seen by the user
after a considerable period of time.

    Avshalom Houri
    Presence and Instant Messaging Architect
    Lotus Sametime, IBM Software Group
    avshalom@il.ibm.com




         "Ben Campbell" 
          15/04/2002 16:25
          Please respond to "Ben Campbell"


                  To:        Avshalom Houri/Haifa/IBM@IBMIL
                  cc:
                  Subject:        RE: [Simple] Status summary




    I guess it depends on your definition of "closed." From the sender's
    perspective, it is never more than a hint.

    On yahoo, others can send you a message at any time, without regard to
    whether you are open or closed. If you appear to be closed, they will
get a
    warning that you may not get the message immediately.

    If you are truly offline at the time, the message gets stored until you
    login next time. If you are logged in, it will get delivered to you,
    regardless of your status at the time.

    Now, with some experimentation, I find that a watcher's UI treats really
    being closed differently from online but unavailable. The first is
grayed
    out or not displayed (depending on your display mode), the second is
bolded,
    but shows an icon indicating you are unavailable.

    This seems to indicate a difference between open/closed as determined by
    login, and availability as determined by a user assertion. But the only
    difference from a watchers perspective is the user interface
presentation.

    > -----Original Message-----
    > From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
    > Sent: Monday, April 15, 2002 5:25 AM
    > To: bcampbell@dynamicsoft.com
    > Subject: RE: [Simple] Status summary
    >
    >
    >
    > I Yahoo when you create your configurable satus message, you can mark
the
    > status
    > as busy but it is only an hint and other users can still send you a
    > message.
    >
    > Avshalom Houri
    > Presence and Instant Messaging Architect
    > Lotus Sametime, IBM Software Group
    > avshalom@il.ibm.com
    >
    >
    >
    >
    >   "Ben Campbell"
    >             To:        Avshalom
    >                                Houri/Haifa/IBM@IBMIL,
    >                                
    >   14/04/2002 21:36                     cc:
    >   Please respond to "Ben               Subject:        RE: [Simple]
    >   Campbell"                    Status summary
    >
    >
    >
    >
    >
    >
    >
    > I cannot speak for the other systems, but Yahoo Messenger allows you
to
    > select open or closed when you create a user configurable message.
Also,
    > you can  become invisible (i.e. lurk) at any time, not just at login.
    > -----Original Message-----
    > From: simple-admin@mailman.dynamicsoft.com
    > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Avshalom
Houri
    > Sent: Sunday, April 14, 2002 9:58 AM
    > To: simple@mailman.dynamicsoft.com
    > Subject: [Simple] Status summary
    >
    >
    > In the SIMPLE components adhoc meeting at IETF53, I have volunteered
to
    > summarize the various statuses used in various systems. The summary is
    > below.
    >
    > While going over the various statuses it occurred to me that we
    > need a more
    >
    > precise definition of what we mean when we say status. The various
status
    > values
    > in the various systems can be divided into:
    >
    > * Mood - Happy, Sad etc.
    >
    > * Hint - I am on the phone therefore I will probably not be able
    > to respond
    >
    >  immediately. The way that the my client will display the message to
me
    > e.g.
    >  in Away mode some clients will display the message in a
    > different way from
    >
    >  the way they do in normal online mode.
    >
    > * Availability - Am I open or close to communication. The availability
can
    > be
    >  simple just open or close or quite complex - I am open to
communication
    >  depending on who is calling and in which location am I.
    >
    > While moods and hints can be localized to vendors and clients, it
seems
    > that
    > availability is the part of the status that mostly needs
standardization.
    >
    > The summary:
    > ===========
    >
    > # AOL - No explicit status - only idle indication by sensing mouse and
    > keyboard activity.
    >
    > # MSN - Open and close statuses + hints
    >        * Online (OPEN)
    >        * Busy (CLOSED)
    >        * Be Right Back (OPEN)
    >         * Away (OPEN)
    >        * On the Phone (CLOSED)
    >        * Out to Lunch (OPEN)
    >        * Appear Offline (Lurking, CLOSED)
    >
    > # YAHOO - Open and close + hints for open.
    >        * Offline (CLOSED)
    >        * Available (OPEN)
    >        * Busy with various messages (configurable) e.g. Be Right
    > Back, Busy
    >
    >          etc. (OPEN)
    >        * Invisible (Lurking can be done only in login time)
    >
    > # ICQ - Open and close statuses. Open statuses are accompanied by
hints.
    > For
    >  example if I am in DND, I will still get messages but the messages
will
    > not be
    >  displayed on my screen.
    >        Simple Mode
    >                * Available
    >                * Away (OPEN, Messages are shown on the screen)
    >                * Offline
    >        Advanced Mode
    >                * Available
    >                * Free for chat
    >                * Away
    >                * N/A (Extended Away)
    >                * Occupied (Urgent messages)
    >                * DND (Do Not Disturb)
    >                * Privacy (Invisible) - Lurking
    >                * Offline
    >
    > # Louts Sametime - Open and close + strong DND. Strong DND means that
I am
    > not
    >  able to send a message to a person that is in DND mode
    >        * Active (OPEN)
    >        * DND (Online but closed)
    >        * Away (OPEN, an hint)
    >
    > # Wireless Village - As defined by the spec status is composed
    > from several
    >
    >  attributes as: availability, preferred contacts etc. Following is a
    > complete
    >  list.
    >        * User availability
    >                - AVAILABLE
    >                - NOT_AVAILABLE
    >                - DISCREET (selectively available. Likd DND or
    > busy in other
    > systems)
    >
    >        * Preferred Contacts (preferred contact method of the user
    > + address
    > of
    >          contact)
    >                - CALL
    >                - SMS
    >                - MMS (Multi Media SMS)
    >                - IM
    >                - EMAIL
    >        * Preferred Language
    >        * Status Text (free text describing the status)
    >        * Status Mood (e.g. HAPPY, SAD, etc.)
    >        * Alias (alias name for the user)
    >        * Status Content - MMS content or URL to the MMS content that
the
    > user
    >          has selected as personal status information.
    >        * Contact Info - Contact information (vCard)
    >
    > # PAM Forum - As described in a previous message Jorge Lobo"
    >  . PAM forum has separate layers of presence
    > information
    > and
    >  availability. Availability can be computed by a very simple methods
or by
    > very
    >  complex conditions as if the message is from X try to get me on any
    > available
    >  device that I am on if not, leave a message on my desktop.
    >
    > Avshalom Houri
    > Presence and Instant Messaging Architect
    > Lotus Sametime, IBM Software Group
    > avshalom@il.ibm.com





------=_NextPart_000_0083_01C1E483.9134CD50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







The=20
following is a conversation between Avshalom and myself that we took off =
list by=20
accident. We both agreed to forward it back to the =
list.



  
-----Original Message-----
From: Ben Campbell=20
  [mailto:bcampbell@dynamicsoft.com]
Sent: Monday, April 15, =
2002=20
  10:15 AM
To: Avshalom Houri
Subject: RE: [Simple] =
Status=20
  summary


  
Agreed--but in the Yahoo environment, the sender can not tell =
for sure=20
  if the message gets delivered immediately or gets store-and-forwarded. =
So from=20
  the sender's perspective, the two situations are the same. On the =
other hand,=20
  the _network_ treats the two differently.

  
 

  
This=20
  is very different than, say, Windows Messenger, which if the recipient =
appears=20
  to be offline, dumps you into an email editor instead of the IM =
conversation=20
  client.

  
    
-----Original Message-----
From: Avshalom Houri=20
    [mailto:AVSHALOM@il.ibm.com]
Sent: Monday, April 15, 2002 =
10:11=20
    AM
To: Ben Campbell
Subject: RE: [Simple] Status =

    summary


I =
think that=20
    even if the system is able to deliver the message somehow using =
offline=20
    messages it is not different from email and the state should be =
regarded as=20
    closed.  I am not sure about this distinction in a wireless =
systems=20
    where IM might be translated to an SMS that will be seen by the user =
after a=20
    considerable period of time. 

Avshalom Houri
Presence and Instant Messaging =
Architect
Lotus=20
    Sametime, IBM Software=20
    Group
avshalom@il.ibm.com





    

      
      

        
        "Ben Campbell"=20
          <bcampbell@dynamicsoft.com>=20
          
15/04/2002 16:25 =

Please respond to "Ben =
Campbell"=20


        		       =20
          
    =
   =20
          To:        Avshalom =
Houri/Haifa/IBM@IBMIL=20
          
      =
  cc:=20
                  
        Subject:     =
 =20
           RE: [Simple] Status summary 

     =20
     


I guess it depends on your definition of "closed." From the =

    sender's
perspective, it is never more than a hint.

On =
yahoo,=20
    others can send you a message at any time, without regard =
to
whether you=20
    are open or closed. If you appear to be closed, they will get =
a
warning=20
    that you may not get the message immediately.

If you are =
truly=20
    offline at the time, the message gets stored until you
login next =
time.=20
    If you are logged in, it will get delivered to you,
regardless of =
your=20
    status at the time.

Now, with some experimentation, I find =
that a=20
    watcher's UI treats really
being closed differently from online =
but=20
    unavailable. The first is grayed
out or not displayed (depending =
on your=20
    display mode), the second is bolded,
but shows an icon indicating =
you are=20
    unavailable.

This seems to indicate a difference between =
open/closed=20
    as determined by
login, and availability as determined by a user=20
    assertion. But the only
difference from a watchers perspective is =
the=20
    user interface presentation.

> -----Original =
Message-----
>=20
    From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
> Sent: =
Monday,=20
    April 15, 2002 5:25 AM
> To: bcampbell@dynamicsoft.com
> =

    Subject: RE: [Simple] Status summary
>
>
>
> =
I Yahoo=20
    when you create your configurable satus message, you can mark =
the
>=20
    status
> as busy but it is only an hint and other users can =
still send=20
    you a
> message.
>
> Avshalom Houri
> =
Presence and=20
    Instant Messaging Architect
> Lotus Sametime, IBM Software=20
    Group
> =
avshalom@il.ibm.com
>
>
>
>
>=20
      "Ben Campbell"
>   =
<bcampbell@dynamicsoft.com>=20
             To:      =20
     Avshalom
>             =
 =20
                   =20
     Houri/Haifa/IBM@IBMIL,
>         =
 =20
                      =
 =20
     <simple@mailman.dynamicsoft.com>
>   =
14/04/2002 21:36=20
                      =
 =20
    cc:
>   Please respond to "Ben       =
   =20
        Subject:        RE: =
[Simple]
>=20
      Campbell"               =
 =20
       Status=20
    =
summary
>
>
>
>
>
>
>
> =
I=20
    cannot speak for the other systems, but Yahoo Messenger allows you=20
    to
> select open or closed when you create a user configurable =

    message. Also,
> you can  become invisible (i.e. lurk) at =
any=20
    time, not just at login.
> -----Original Message-----
> =
From:=20
    simple-admin@mailman.dynamicsoft.com
>=20
    [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Avshalom=20
    Houri
> Sent: Sunday, April 14, 2002 9:58 AM
> To:=20
    simple@mailman.dynamicsoft.com
> Subject: [Simple] Status=20
    summary
>
>
> In the SIMPLE components adhoc =
meeting at=20
    IETF53, I have volunteered to
> summarize the various statuses =
used in=20
    various systems. The summary is
> below.
>
> While =
going=20
    over the various statuses it occurred to me that we
> need a=20
    more
>
> precise definition of what we mean when we say =
status.=20
    The various status 
>=20
    values
> in the various systems can be divided =
into:
>
> *=20
    Mood - Happy, Sad etc.
>
> * Hint - I am on the phone =
therefore=20
    I will probably not be able
> to respond
>
>=20
     immediately. The way that the my client will display the =
message to=20
    me
> e.g.
>  in Away mode some clients will display =
the=20
    message in a
> different way from
>
>  the =
way they=20
    do in normal online mode.
>
> * Availability - Am I open =
or=20
    close to communication. The availability can
> be
> =
 simple=20
    just open or close or quite complex - I am open to =
communication
>=20
     depending on who is calling and in which location am=20
    I.
>
> While moods and hints can be localized to vendors =
and=20
    clients, it seems
> that
> availability is the part of =
the=20
    status that mostly needs standardization.
>
> The=20
    summary:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> # =
AOL - No explicit status -=20
    only idle indication by sensing mouse and
> keyboard=20
    activity.
>
> # MSN - Open and close statuses + =
hints
>=20
           * Online (OPEN)
>     =
 =20
     * Busy (CLOSED)
>        * Be Right =
Back=20
    (OPEN)
>         * Away (OPEN)
> =
 =20
         * On the Phone (CLOSED)
>     =
 =20
     * Out to Lunch (OPEN)
>        * =
Appear=20
    Offline (Lurking, CLOSED)
>
> # YAHOO - Open and close + =
hints=20
    for open.
>        * Offline =
(CLOSED)
>=20
           * Available (OPEN)
>     =
 =20
     * Busy with various messages (configurable) e.g. Be =
Right
>=20
    Back, Busy
>
>          etc.=20
    (OPEN)
>        * Invisible (Lurking can =
be done=20
    only in login time)
>
> # ICQ - Open and close statuses. =
Open=20
    statuses are accompanied by hints.
> For
>  example =
if I am=20
    in DND, I will still get messages but the messages will
> not=20
    be
>  displayed on my screen.
>     =
 =20
     Simple Mode
>             =
 =20
     * Available
>             =
 =20
     * Away (OPEN, Messages are shown on the screen)
>   =
 =20
               * Offline
>   =
 =20
       Advanced Mode
>         =
   =20
       * Available
>           =
 =20
       * Free for chat
>         =
 =20
         * Away
>         =
   =20
       * N/A (Extended Away)
>       =
 =20
           * Occupied (Urgent messages)
> =
 =20
                 * DND (Do Not=20
    Disturb)
>               =
 *=20
    Privacy (Invisible) - Lurking
>         =
 =20
         * Offline
>
> # Louts Sametime - =
Open and=20
    close + strong DND. Strong DND means that I am
> not
>=20
     able to send a message to a person that is in DND mode
> =
 =20
         * Active (OPEN)
>       =
 * DND=20
    (Online but closed)
>        * Away (OPEN, =
an=20
    hint)
>
> # Wireless Village - As defined by the spec =
status is=20
    composed
> from several
>
>  attributes as:=20
    availability, preferred contacts etc. Following is a
>=20
    complete
>  list.
>        * =
User=20
    availability
>             =
 =20
     - AVAILABLE
>             =
 =20
     - NOT_AVAILABLE
>           =
 =20
       - DISCREET (selectively available. Likd DND or
> =
busy in=20
    other
> systems)
>
>        *=20
    Preferred Contacts (preferred contact method of the user
> +=20
    address
> of
>        =20
     contact)
>             =
 =20
     - CALL
>             =
 =20
     - SMS
>               =
 -=20
    MMS (Multi Media SMS)
>           =
 =20
       - IM
>             =
 =20
     - EMAIL
>        * Preferred=20
    Language
>        * Status Text (free text =

    describing the status)
>        * Status =
Mood=20
    (e.g. HAPPY, SAD, etc.)
>        * Alias =
(alias=20
    name for the user)
>        * Status =
Content - MMS=20
    content or URL to the MMS content that the
> user
> =
 =20
           has selected as personal status=20
    information.
>        * Contact Info - =
Contact=20
    information (vCard)
>
> # PAM Forum - As described in a =
previous=20
    message Jorge Lobo"
>  <jorge@teltier.com>. PAM =
forum has=20
    separate layers of presence
> information
> and
>=20
     availability. Availability can be computed by a very simple =
methods or=20
    by
> very
>  complex conditions as if the message =
is from X=20
    try to get me on any
> available
>  device that I =
am on if=20
    not, leave a message on my desktop.
>
> Avshalom =
Houri
>=20
    Presence and Instant Messaging Architect
> Lotus Sametime, IBM =

    Software Group
>=20
avshalom@il.ibm.com





------=_NextPart_000_0083_01C1E483.9134CD50--


From stpeter@jabber.org  Mon Apr 15 15:36:27 2002
Received: from lor.jeremie.com (lor.jeremie.com [208.245.212.28])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02291
	for ; Mon, 15 Apr 2002 15:36:26 -0400 (EDT)
Received: from localhost (stpeter@localhost)
	by lor.jeremie.com (8.9.3/8.9.3) with ESMTP id OAA07715;
	Mon, 15 Apr 2002 14:35:20 -0500
Date: Mon, 15 Apr 2002 14:35:12 -0500 (CDT)
From: Peter Saint-Andre 
X-Sender: stpeter@lor.jeremie.com
To: "Boyer, David G (Dave)" 
cc: Sean Olson , simple@mailman.dynamicsoft.com,
        impp@iastate.edu, Avshalom Houri 
Subject: RE: [Simple] Status summary
In-Reply-To: <8CA1128D59AD27429985B397118CEDDFC44198@nj7460avexu1.global.avaya.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1763
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: 

In Jabber we handle this with the concept of a "resource" -- one Jabber
Entity (normally user@host) can possess multiple resources associated with
different connection types or locations (e.g., user@host/cellphone and
user@host/desktop), there is no limit on the number of simultaneous
connected resources that may be associated with a Jabber Entity, and each
resource can have a distinct presence status.

Peter

--
Peter Saint-Andre
email+jabber: stpeter@jabber.org

On Mon, 15 Apr 2002, Boyer, David G (Dave) wrote:

> I am curious about something.  How would you catagorize present
> but on the phone?  You may not be available for a SIP audio session, but
> you would be available for an IM.  Different presence states for diff
> communication channels?
> 
> Dave
> 
> > -----Original Message-----
> > From: Sean Olson [mailto:seancolson@yahoo.com]
> > Sent: Monday, April 15, 2002 1:54 PM
> > To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> > Subject: Re: [Simple] Status summary
> > 
> > 
> > There seems to be a common thread here where
> > we can map communication status (presence) to
> > one of three states:
> > 
> >    open,
> >    closed,
> >    undisclosed (invisible)
> > 
> > Is there a fourth type of state I am missing?
> > 
> > /sean
> > 
> > 
> > 
> > =====
> > Sean Olson 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Tax Center - online filing with TurboTax
> > http://taxes.yahoo.com/
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 
> 
> 
>   [reminder: meta-impp@iastate.edu for non-technical discussions, please]
> 


From Juberti@aol.com  Mon Apr 15 15:38:20 2002
Received: from imo-r05.mx.aol.com (imo-r05.mx.aol.com [152.163.225.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02321
	for ; Mon, 15 Apr 2002 15:38:20 -0400 (EDT)
Received: from Juberti@aol.com
	by imo-r05.mx.aol.com (mail_out_v32.5.) id u.a6.24918124 (15876);
	Mon, 15 Apr 2002 15:37:14 -0400 (EDT)
Received: from  pcsn602343 ([10.2.115.71]) by air-id07.mx.aol.com (v84.14) with ESMTP id MAILINID73-0415153714; Mon, 15 Apr 2002 15:37:14 -0400
From: "Justin Uberti" 
To: , 
Cc: "Avshalom Houri" 
Subject: RE: [Simple] Status summary
Date: Mon, 15 Apr 2002 15:37:14 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CB9EA79.9080603@att.com>
Importance: Normal
Content-Length: 3732
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: 

AOL has open and closed statuses and hints.

* Online (OPEN)
* Offline (CLOSED)
* Away with various configurable messages (CLOSED)
* Idle (OPEN)

Justin Uberti
America Online

> >     The summary:
> >     ===========
> >
> >     # AOL - No explicit status - only idle indication by sensing mouse
> >     and keyboard activity.
> >
> >     # MSN - Open and close statuses + hints
> >             * Online (OPEN)
> >             * Busy (CLOSED)
> >             * Be Right Back (OPEN)
> >             * Away (OPEN)
> >             * On the Phone (CLOSED)
> >             * Out to Lunch (OPEN)
> >             * Appear Offline (Lurking, CLOSED)
> >
> >     # YAHOO - Open and close + hints for open.
> >             * Offline (CLOSED)
> >             * Available (OPEN)
> >             * Busy with various messages (configurable) e.g. Be Right
> >     Back, Busy
> >               etc. (OPEN)
> >             * Invisible (Lurking can be done only in login time)
> >
> >     # ICQ - Open and close statuses. Open statuses are accompanied by
> >     hints. For
> >       example if I am in DND, I will still get messages but the messages
> >     will not be
> >       displayed on my screen.
> >             Simple Mode
> >                     * Available
> >                     * Away (OPEN, Messages are shown on the screen)
> >                     * Offline
> >             Advanced Mode
> >                     * Available
> >                     * Free for chat
> >                     * Away
> >                     * N/A (Extended Away)
> >                     * Occupied (Urgent messages)
> >                     * DND (Do Not Disturb)
> >                     * Privacy (Invisible) - Lurking
> >                     * Offline
> >
> >     # Louts Sametime - Open and close + strong DND. Strong DND means
> >     that I am not
> >       able to send a message to a person that is in DND mode
> >             * Active (OPEN)
> >             * DND (Online but closed)
> >             * Away (OPEN, an hint)
> >
> >     # Wireless Village - As defined by the spec status is composed from
> >     several
> >       attributes as: availability, preferred contacts etc. Following is
> >     a complete
> >       list.
> >             * User availability
> >                     - AVAILABLE
> >                     - NOT_AVAILABLE
> >                     - DISCREET (selectively available. Likd DND or busy
> >     in other systems)
> >
> >             * Preferred Contacts (preferred contact method of the user +
> >     address of
> >               contact)
> >                     - CALL
> >                     - SMS
> >                     - MMS (Multi Media SMS)
> >                     - IM
> >                     - EMAIL
> >             * Preferred Language
> >             * Status Text (free text describing the status)
> >             * Status Mood (e.g. HAPPY, SAD, etc.)
> >             * Alias (alias name for the user)
> >             * Status Content - MMS content or URL to the MMS content
> >     that the user
> >               has selected as personal status information.
> >             * Contact Info - Contact information (vCard)
> >
> >     # PAM Forum - As described in a previous message Jorge Lobo"
> >       . PAM forum has separate layers of presence
> >     information and
> >       availability. Availability can be computed by a very simple
> >     methods or by very
> >       complex conditions as if the message is from X try to get me on
> >     any available
> >       device that I am on if not, leave a message on my desktop.
> >
> >     Avshalom Houri
> >     Presence and Instant Messaging Architect
> >     Lotus Sametime, IBM Software Group
> >     avshalom@il.ibm.com
> >


From jdrosen@dynamicsoft.com  Mon Apr 15 16:29:24 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02507
	for ; Mon, 15 Apr 2002 16:29:24 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.83])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3FKTdo6010375;
	Mon, 15 Apr 2002 16:29:39 -0400 (EDT)
Message-ID: <3CBB37E7.25E75EC6@dynamicsoft.com>
Date: Mon, 15 Apr 2002 16:28:23 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: mikko.lonnfors@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] question about winfo-package (resend with revision marks)
References: <2038BCC78B1AD641891A0D1AE133DBB777910E@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 6073
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: 


hisham.khartabil@nokia.com wrote:
> 
> The first NOTIFY is sent of course, but there will be no NOTIFYs sent
> when a change to winfo occurs.

Right. I'll clarify that.

Thanks,
Jonathan R.

> > -----Original Message-----
> > From: Lonnfors Mikko (NRC/Helsinki)
> > Sent: Tuesday, April 09, 2002 10:37 AM
> > To: jdrosen@dynamicsoft.com
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] question about winfo-package (resend
> > with revision
> > marks)
> >
> >
> > Hi,
> >
> > Thanks for the answer. I have one more question about
> > draft-ietf-simple-winfo-package-01.
> > Chapter 4.7.1 The Subscription State Machine (after figure 1) 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."
> >
> > Is this to say that the package on which winfo is applied to
> > should not generate
> > any NOTIFY messages to subscriber? This sound a bit weird
> > because SIP events says that NOTIFY
> > should be send immediately after 200-class response. (I am
> > here assuming SUB-202 request/response
> > if there is no authorization policy is set)
> >
> > So in short how should the quoted sentence be interpreted?
> >
> > regards
> > - Mikko
> >
> > > -----Original Message-----
> > > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > > Sent: 01 April, 2002 09:13
> > > To: Lonnfors Mikko (NRC/Helsinki)
> > > Cc: tanglih@cn.ibm.com; simple@mailman.dynamicsoft.com
> > > Subject: Re: [Simple] question about winfo-package (resend
> > > with revision
> > > marks)
> > >
> > >
> > >
> > >
> > > mikko.lonnfors@nokia.com wrote:
> > > >
> > > > My opinion about your question is as follows:
> > > >
> > > > The motivating application for winfo package is presence
> > > authorization.
> > > > If
> > > > User B is authorized to subscribe A's presence, as you
> > > said, generally
> > > > speaking the PS doesn't need to notify A of the B's
> > > subscription status
> > > > for
> > > > authorization.
> > > >
> > > > 
> > > > I would still say that winfo is designed to enable
> > presentity to get
> > > > lists of watchers interested in their presence status.
> > > > This should happen regardless of the watcher's
> > authorization status.
> > > > Presence authorization may be the main motivation
> > > > to enable this functionality but not the only one.
> > > > 
> > >
> > > Yes. However, the decision about when to send NOTIFY for winfo is a
> > > server decision; it can decide to not send two notifications
> > > in the case
> > > of a fetch.
> > >
> > >
> > > >
> > > > If the PS needs to notify A of this FETCH subscription, you
> > > may use the
> > > > 'expiration' attribute of winfo foramt. Like this:
> > > >   
> > > >      
> > > >         > > >                    event="subscribe" expiration="0"/>
> > > >      
> > > >    
> > > > In this case, A should understanding that a FETCH subscription is
> > > > requested.
> > > > How about this way to solute your problem?
> > > >
> > > > 
> > > > I think there are some problems with this approach. I think
> > > that winfo
> > > > is designed to
> > > > signal changes in watchers subscription status i.e. signal
> > > the state to
> > > > which a watcher has moved from previous state.
> > > > In this case, as you said,  A should be able to understand that
> > > >
> > > >     
> > > >         > > >                    event="subscribe" expiration="0"/>
> > > >
> > > > means FETCH. This would mean special casing expiration="0".
> > >
> > > It only needs to be special cased if you are trying to explicitly
> > > identify fetch requests. I see no reason to do that. The above
> > > notification stands, by itself, as something reasonable.
> > > However, if you
> > > want to send a single notification, you are probably better
> > > off sending
> > > the one on the transition to terminated due to timeout.
> > >
> > >
> > >
> > > > We could take an other example. Let's say that B performs
> > > FETCH but has
> > > > no authorization. Should A now get
> > > >
> > > >    
> > > >         > > >                    event="subscribe" expiration="0"/>
> > > >
> > > > I would say that sending
> > > >
> > > >    
> > > >         > > >                    event="subscribe"/>
> > > >
> > > > would make more sense.
> > >
> > > I agree that the second one makes more sense. The first is valid, of
> > > course, but if you want to send just one notification, the latter is
> > > more useful. Again, the decision about which state change
> > > notifications
> > > to send is a matter of local policy.
> > >
> > > -Jonathan R.
> > >
> > > --
> > > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > > Chief Scientist                         First Floor
> > > dynamicsoft                             East Hanover, NJ 07936
> > > jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> > > http://www.jdrosen.net                  PH:  (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From hgs@cs.columbia.edu  Mon Apr 15 17:28:19 2002
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 RAA02691
	for ; Mon, 15 Apr 2002 17:28:18 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA27458;
	Mon, 15 Apr 2002 17:27:16 -0400 (EDT)
Received: from cs.columbia.edu (slip-32-102-22-11.md.us.prserv.net [32.102.22.11])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g3FLRBPm029753
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 15 Apr 2002 17:27:13 -0400 (EDT)
Message-ID: <3CBB4583.94152842@cs.columbia.edu>
Date: Mon, 15 Apr 2002 17:26:27 -0400
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Saint-Andre 
CC: Tony Hansen , simple@mailman.dynamicsoft.com,
        impp@iastate.edu, Avshalom Houri 
Subject: Re: [Simple] Status summary
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 667
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: 

I'm curious: Windows Messenger, supposedly using SIP and IMPP presence,
has a bunch of status indications, similar to the ones mentioned on the
list (lunch, do not disturb, etc.). How are they encoded?

Peter Saint-Andre wrote:
> 
> FWIW, we provide the following statuses (stati?) in Jabber:
> 
> 1. Unavailable (maps to CLOSED)
> 
> 2. Available (maps to OPEN) with sub-statuses:
>    - away
>    - extended away
>    - do not disturb
>    - free/desiring to chat
> 
> 3. Invisible
> 
> Any status can be extended with a natural-language description of the
> status.
> 
> More information at
> http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence

From jdrosen@dynamicsoft.com  Mon Apr 15 17:37:58 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02750
	for ; Mon, 15 Apr 2002 17:37:58 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.83])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3FLcFo6010845
	for ; Mon, 15 Apr 2002 17:38:15 -0400 (EDT)
Message-ID: <3CBB47FA.86E3D26E@dynamicsoft.com>
Date: Mon, 15 Apr 2002 17:36:58 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; 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
Content-Length: 1533
Subject: [Simple] changes to winfo format
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: 

Folks,

In an attempt to make our XML usage in draft-ietf-simple-winfo-format
more consistent with "proper" XML usage (See
http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-00.txt),
I propose the following changes to the watcherinfo format draft:


1. The resource element be named to watchers, and the uri attribute be
renamed to resource. The reason is so that the element name (watchers)
actually identifies what it is that the element contains. Right now, the
name of the element is resource, but its value is not the resource, its
the watchers.

2. The value of the watcher element be the URI, rather than the optional
human readable name of the watcher. The URI is really the value of this
element, not the human readable form.

3. We add an xml:lang attribute to the watcher element, allowing for
declaration of the language for the human readable name of the watcher.

4. We explicitly disallow the usage of the XML declaration, and
explicitly mandate UTF-8 encoding.

5. We use a schema instead of a DTD.

6. We explicitly disallow XML processing instructions.

7. We explicitly say that any unrecognized elements or attributes are
ignored.


Comments?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From AVSHALOM@il.ibm.com  Tue Apr 16 06:40:34 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04795
	for ; Tue, 16 Apr 2002 06:40:33 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id MAA43016;
	Tue, 16 Apr 2002 12:38:58 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GAcup80066;
	Tue, 16 Apr 2002 12:38:56 +0200
To: Henning Schulzrinne 
Cc: impp@iastate.edu, simple@mailman.dynamicsoft.com,
        Peter Saint-Andre , Tony Hansen 
MIME-Version: 1.0
Subject: Re: [Simple] Status summary
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Tue, 16 Apr 2002 13:38:57 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 16/04/2002 13:38:57,
	Serialize complete at 16/04/2002 13:38:57
Content-Type: multipart/alternative; boundary="=_alternative 003A7FA4C2256B9D_="
Content-Length: 3949
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: 

This is a multipart message in MIME format.
--=_alternative 003A7FA4C2256B9D_=
Content-Type: text/plain; charset="us-ascii"

I was checking the Windows messenger version 4.6. As far as I know:
        * This version is based on the MSN protocol and not SIP.
        * The SIP client is not publically available yet.

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com






Henning Schulzrinne 
16/04/2002 00:26
Please respond to Henning Schulzrinne

 
        To:        Peter Saint-Andre 
        cc:        Tony Hansen , simple@mailman.dynamicsoft.com, 
impp@iastate.edu, Avshalom Houri/Haifa/IBM@IBMIL
        Subject:        Re: [Simple] Status summary

 

I'm curious: Windows Messenger, supposedly using SIP and IMPP presence,
has a bunch of status indications, similar to the ones mentioned on the
list (lunch, do not disturb, etc.). How are they encoded?

Peter Saint-Andre wrote:
> 
> FWIW, we provide the following statuses (stati?) in Jabber:
> 
> 1. Unavailable (maps to CLOSED)
> 
> 2. Available (maps to OPEN) with sub-statuses:
>    - away
>    - extended away
>    - do not disturb
>    - free/desiring to chat
> 
> 3. Invisible
> 
> Any status can be extended with a natural-language description of the
> status.
> 
> More information at
> http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence



--=_alternative 003A7FA4C2256B9D_=
Content-Type: text/html; charset="us-ascii"



I was checking the Windows messenger version 4.6. As far as I know:

        * This version is based on the MSN protocol and not SIP.

        * The SIP client is not publically available yet.



Avshalom Houri

Presence and Instant Messaging Architect

Lotus Sametime, IBM Software Group

avshalom@il.ibm.com















Henning Schulzrinne <hgs@cs.columbia.edu>

16/04/2002 00:26

Please respond to Henning Schulzrinne



        

        To:        Peter Saint-Andre <stpeter@jabber.org>

        cc:        Tony Hansen <tony@att.com>, simple@mailman.dynamicsoft.com, impp@iastate.edu, Avshalom Houri/Haifa/IBM@IBMIL

        Subject:        Re: [Simple] Status summary



       




I'm curious: Windows Messenger, supposedly using SIP and IMPP presence,

has a bunch of status indications, similar to the ones mentioned on the

list (lunch, do not disturb, etc.). How are they encoded?



Peter Saint-Andre wrote:

> 

> FWIW, we provide the following statuses (stati?) in Jabber:

> 

> 1. Unavailable (maps to CLOSED)

> 

> 2. Available (maps to OPEN) with sub-statuses:

>    - away

>    - extended away

>    - do not disturb

>    - free/desiring to chat

> 

> 3. Invisible

> 

> Any status can be extended with a natural-language description of the

> status.

> 

> More information at

> http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence






--=_alternative 003A7FA4C2256B9D_=--

From AVSHALOM@il.ibm.com  Tue Apr 16 06:57:51 2002
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04867
	for ; Tue, 16 Apr 2002 06:57:50 -0400 (EDT)
Received: from d12relay02.de.ibm.com ([9.165.215.23])
	by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id MAA171852;
	Tue, 16 Apr 2002 12:53:42 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GAr1p101594;
	Tue, 16 Apr 2002 12:53:07 +0200
To: "Christian Huitema" 
Cc: impp@iastate.edu, owner-impp@iastate.edu,
        "Sean Olson" , simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Subject: RE: [Simple] Status summary
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Tue, 16 Apr 2002 13:53:03 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 16/04/2002 13:53:07,
	Serialize complete at 16/04/2002 13:53:07
Content-Type: multipart/alternative; boundary="=_alternative 003BCA26C2256B9D_="
Content-Length: 6764
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: 

This is a multipart message in MIME format.
--=_alternative 003BCA26C2256B9D_=
Content-Type: text/plain; charset="us-ascii"

I agree with Christian. We would lose the meaning of being invisible (or 
actually lurking) if the status will be invisible.

It seems that there are open and close statuses where I think we need to 
get a 
clear definition of those.

It seems that:
* OPEN - The message will be received by the user agent no matter if the 
  user himself/herself is near the terminal. This include away and other 
  hints as idle.

* CLOSED - The message will not be received by the user agent.

As started to discuss with Ben Campbell, it seems that in parallel we need 
to 
decide what is the meaning of other means of conveying the message to the 
user
* If the system implements offline messages will that regarded as open or 
  closed?

* What about SMS, normal phone call, email etc.?

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com






"Christian Huitema" 
Sent by: owner-impp@iastate.edu
16/04/2002 04:24
Please respond to "Christian Huitema"

 
        To:        "Sean Olson" , , 
, Avshalom Houri/Haifa/IBM@IBMIL
        cc: 
        Subject:        RE: [Simple] Status summary

 

Undisclosed is not a state. When someone is "invisible", they appear
"off line" (closed) to third parties. You definitely don't want a code
point that would say "X is online but would like to appear offline".

-- Christian Huitema

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Monday, April 15, 2002 10:54 AM
> To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> Subject: Re: [Simple] Status summary
> 
> There seems to be a common thread here where
> we can map communication status (presence) to
> one of three states:
> 
>    open,
>    closed,
>    undisclosed (invisible)
> 
> Is there a fourth type of state I am missing?
> 
> /sean
> 
> 
> 
> =====
> Sean Olson 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple



  [reminder: meta-impp@iastate.edu for non-technical discussions, please]




--=_alternative 003BCA26C2256B9D_=
Content-Type: text/html; charset="us-ascii"



I agree with Christian. We would lose the meaning of being invisible (or 

actually lurking) if the status will be invisible.



It seems that there are open and close statuses where I think we need to get a 

clear definition of those.



It seems that:

* OPEN - The message will be received by the user agent no matter if the 

  user himself/herself is near the terminal. This include away and other 

  hints as idle.



* CLOSED - The message will not be received by the user agent.



As started to discuss with Ben Campbell, it seems that in parallel we need to 

decide what is the meaning of other means of conveying the message to the user

* If the system implements offline messages will that regarded as open or 

  closed?



* What about SMS, normal phone call, email etc.?



Avshalom Houri

Presence and Instant Messaging Architect

Lotus Sametime, IBM Software Group

avshalom@il.ibm.com















"Christian Huitema" <huitema@windows.microsoft.com>

Sent by: owner-impp@iastate.edu

16/04/2002 04:24

Please respond to "Christian Huitema"



        

        To:        "Sean Olson" <seancolson@yahoo.com>, <simple@mailman.dynamicsoft.com>, <impp@iastate.edu>, Avshalom Houri/Haifa/IBM@IBMIL

        cc:        

        Subject:        RE: [Simple] Status summary



       




Undisclosed is not a state. When someone is "invisible", they appear

"off line" (closed) to third parties. You definitely don't want a code

point that would say "X is online but would like to appear offline".



-- Christian Huitema



> -----Original Message-----

> From: Sean Olson [mailto:seancolson@yahoo.com]

> Sent: Monday, April 15, 2002 10:54 AM

> To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri

> Subject: Re: [Simple] Status summary

> 

> There seems to be a common thread here where

> we can map communication status (presence) to

> one of three states:

> 

>    open,

>    closed,

>    undisclosed (invisible)

> 

> Is there a fourth type of state I am missing?

> 

> /sean

> 

> 

> 

> =====

> Sean Olson <seancolson@yahoo.com>

> 

> __________________________________________________

> Do You Yahoo!?

> Yahoo! Tax Center - online filing with TurboTax

> http://taxes.yahoo.com/

> _______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple







  [reminder: meta-impp@iastate.edu for non-technical discussions, please]








--=_alternative 003BCA26C2256B9D_=--

From HUITEMA@windows.microsoft.com  Mon Apr 15 21:29:40 2002
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03364
	for ; Mon, 15 Apr 2002 21:29:39 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 15 Apr 2002 18:28:36 -0700
Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Apr 2002 18:28:37 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 15 Apr 2002 18:28:37 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 15 Apr 2002 18:28:32 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0);
	 Mon, 15 Apr 2002 18:24:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] Status summary
Date: Mon, 15 Apr 2002 18:24:56 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Status summary
Thread-Index: AcHkpkaGBNWB4oCgSyCXHPelz0sCrQAP2jqg
From: "Christian Huitema" 
To: "Sean Olson" , ,
        , "Avshalom Houri" 
X-OriginalArrivalTime: 16 Apr 2002 01:24:57.0319 (UTC) FILETIME=[85016770:01C1E4E5]
Content-Length: 1063
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id VAA03364
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: 

Undisclosed is not a state. When someone is "invisible", they appear
"off line" (closed) to third parties. You definitely don't want a code
point that would say "X is online but would like to appear offline".

-- Christian Huitema

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Monday, April 15, 2002 10:54 AM
> To: simple@mailman.dynamicsoft.com; impp@iastate.edu; Avshalom Houri
> Subject: Re: [Simple] Status summary
> 
> There seems to be a common thread here where
> we can map communication status (presence) to
> one of three states:
> 
>    open,
>    closed,
>    undisclosed (invisible)
> 
> Is there a fourth type of state I am missing?
> 
> /sean
> 
> 
> 
> =====
> Sean Olson 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Tax Center - online filing with TurboTax
> http://taxes.yahoo.com/
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From tkarlo@net2phone.com  Tue Apr 16 09:29:00 2002
Received: from imail01.net2phone.com (imail01.net2phone.com [66.33.145.25])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05302
	for ; Tue, 16 Apr 2002 09:29:00 -0400 (EDT)
Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1])
	by imail01.net2phone.com (8.12.2/8.12.2) with ESMTP id g3GDPPuc026439;
	Tue, 16 Apr 2002 09:25:25 -0400 (EDT)
Received: by mailsvr with Internet Mail Service (5.5.2653.19)
	id <2FHSMLZB>; Tue, 16 Apr 2002 09:26:27 -0400
Message-ID: 
From: Tom  Karlo 
To: "'Avshalom Houri'" ,
        Henning Schulzrinne
	 
Cc: impp@iastate.edu, simple@mailman.dynamicsoft.com,
        Peter Saint-Andre
	 , Tony Hansen 
Subject: RE: [Simple] Status summary
Date: Tue, 16 Apr 2002 09:23:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1E549.D475FC80"
Content-Length: 12608
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: 

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_01C1E549.D475FC80
Content-Type: text/plain

Actually, the latest Windows Messenger has been SIP-based for a while now (6
months?) My company is one of the carriers providing support. You might have
to check the XP messenger, although I do believe 4.6 would be the right one.
If you get the version where when making a phone call, you're given a list
of services to choose from, then that's the SIP one. The old one only
allowed you to use the Net2Phone protocol.
 
Tom Karlo
Net2Phone
 
-----Original Message-----
From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] 
Sent: Tuesday, April 16, 2002 6:39 AM
To: Henning Schulzrinne
Cc: impp@iastate.edu; simple@mailman.dynamicsoft.com; Peter Saint-Andre;
Tony Hansen
Subject: Re: [Simple] Status summary
 

I was checking the Windows messenger version 4.6. As far as I know: 
        * This version is based on the MSN protocol and not SIP. 
        * The SIP client is not publically available yet. 

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com





 
Henning Schulzrinne  
16/04/2002 00:26 
Please respond to Henning Schulzrinne 
        
        To:        Peter Saint-Andre  
        cc:        Tony Hansen ,
simple@mailman.dynamicsoft.com, impp@iastate.edu, Avshalom
Houri/Haifa/IBM@IBMIL 
        Subject:        Re: [Simple] Status summary 

       


I'm curious: Windows Messenger, supposedly using SIP and IMPP presence,
has a bunch of status indications, similar to the ones mentioned on the
list (lunch, do not disturb, etc.). How are they encoded?

Peter Saint-Andre wrote:
> 
> FWIW, we provide the following statuses (stati?) in Jabber:
> 
> 1. Unavailable (maps to CLOSED)
> 
> 2. Available (maps to OPEN) with sub-statuses:
>    - away
>    - extended away
>    - do not disturb
>    - free/desiring to chat
> 
> 3. Invisible
> 
> Any status can be extended with a natural-language description of the
> status.
> 
> More information at
> http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence



------_=_NextPart_001_01C1E549.D475FC80
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
























Actually, the latest Windows =
Messenger has
been SIP-based for a while now (6 months?) My company is one of the =
carriers
providing support. You might have to check the XP messenger, although I =
do believe
4.6 would be the right one. If you get the version where when making a =
phone
call, you’re given a list of services to choose from, then =
that’s
the SIP one. The old one only allowed you to use the Net2Phone =
protocol.



 
=



Tom =
Karlo



Net2Phone<=
/p>


 
=



-----Original =
Message-----

From: Avshalom Houri
[mailto:AVSHALOM@il.ibm.com] 

Sent: Tuesday, April 16, =
2002 6:39
AM

To: Henning =
Schulzrinne

Cc: impp@iastate.edu;
simple@mailman.dynamicsoft.com; Peter Saint-Andre; Tony Hansen

Subject: Re: [Simple] =
Status
summary



 





I was checking the Windows messenger version =
4.6. As
far as I know: 

 
      * This version is based on the MSN protocol and =
not SIP.


 
      * The SIP client is not publically available =
yet.




Avshalom
Houri

Presence and Instant Messaging Architect

Lotus Sametime, IBM Software Group

avshalom@il.ibm.com












 

  
  
 

  		
  
  
Henning Schulzrinne
  <hgs@cs.columbia.edu> 

  
16/04/2002 00:26 

  Please
  respond to Henning Schulzrinne 

  		
  
  
        

   
        To:        Peter Saint-Andre
  <stpeter@jabber.org> 

   
        cc:        Tony Hansen
  <tony@att.com>, simple@mailman.dynamicsoft.com, =
impp@iastate.edu, Avshalom
  Houri/Haifa/IBM@IBMIL 

   
        Subject:        Re: [Simple] =
Status
  summary 

  

   
       

  		
 









I'm curious: Windows Messenger, supposedly =
using SIP
and IMPP presence,

has a bunch of status indications, similar to the ones mentioned on =
the

list (lunch, do not disturb, etc.). How are they encoded?



Peter Saint-Andre wrote:

> 

> FWIW, we provide the following statuses (stati?) in Jabber:

> 

> 1. Unavailable (maps to CLOSED)

> 

> 2. Available (maps to OPEN) with sub-statuses:

>    - away

>    - extended away

>    - do not disturb

>    - free/desiring to chat

> 

> 3. Invisible

> 

> Any status can be extended with a natural-language description of =
the

> status.

> 

> More information at

> =
http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence












------_=_NextPart_001_01C1E549.D475FC80--

From AVSHALOM@il.ibm.com  Tue Apr 16 15:05:04 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06281;
	Tue, 16 Apr 2002 15:05:03 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id VAA12580;
	Tue, 16 Apr 2002 21:03:28 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GJ3Np179242;
	Tue, 16 Apr 2002 21:03:23 +0200
To: Tom Karlo 
Cc: Henning Schulzrinne , impp@iastate.edu,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Peter Saint-Andre , Tony Hansen 
MIME-Version: 1.0
Subject: RE: [Simple] Status summary
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Tue, 16 Apr 2002 22:03:20 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 16/04/2002 22:03:27,
	Serialize complete at 16/04/2002 22:03:27
Content-Type: multipart/alternative; boundary="=_alternative 0068ACD3C2256B9D_="
Content-Length: 11756
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: 

This is a multipart message in MIME format.
--=_alternative 0068ACD3C2256B9D_=
Content-Type: text/plain; charset="Windows-1255"
Content-Transfer-Encoding: base64

V2hhdCBpcyBzaXAgYmFzZWQgaW4gdGhlIFhQIFdpbmRvd3MgbWVzc2VuZ2VyIGlzIGluIHRoZSBW
T0lQIHBhcnQuIFRoZSBQSU0gDQpwYXJ0IGlzIHN0aWxsIHVzaW5nIHRoZSBNU04gcHJvdG9jb2wg
KFZFUiAxMTkpIGFzIGNhbiBiZSBzZWVuIGlmIHlvdSBsb29rIA0KYXQgdGhlIHBhY2tldHMgaXQg
c2VuZHMuDQoNCkF2c2hhbG9tIEhvdXJpDQpQcmVzZW5jZSBhbmQgSW5zdGFudCBNZXNzYWdpbmcg
QXJjaGl0ZWN0DQpMb3R1cyBTYW1ldGltZSwgSUJNIFNvZnR3YXJlIEdyb3VwDQphdnNoYWxvbUBp
bC5pYm0uY29tDQoNCg0KDQoNCg0KDQpUb20gIEthcmxvIDx0a2FybG9AbmV0MnBob25lLmNvbT4N
ClNlbnQgYnk6IHNpbXBsZS1hZG1pbkBtYWlsbWFuLmR5bmFtaWNzb2Z0LmNvbQ0KMTYvMDQvMjAw
MiAxNjoyMw0KUGxlYXNlIHJlc3BvbmQgdG8gVG9tICBLYXJsbw0KDQogDQogICAgICAgIFRvOiAg
ICAgICAgQXZzaGFsb20gSG91cmkvSGFpZmEvSUJNQElCTUlMLCBIZW5uaW5nIFNjaHVsenJpbm5l
IDxoZ3NAY3MuY29sdW1iaWEuZWR1Pg0KICAgICAgICBjYzogICAgICAgIGltcHBAaWFzdGF0ZS5l
ZHUsIHNpbXBsZUBtYWlsbWFuLmR5bmFtaWNzb2Z0LmNvbSwgUGV0ZXIgU2FpbnQtQW5kcmUgDQo8
c3RwZXRlckBqYWJiZXIub3JnPiwgVG9ueSBIYW5zZW4gPHRvbnlAYXR0LmNvbT4NCiAgICAgICAg
U3ViamVjdDogICAgICAgIFJFOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeQ0KDQogDQoNCkFjdHVh
bGx5LCB0aGUgbGF0ZXN0IFdpbmRvd3MgTWVzc2VuZ2VyIGhhcyBiZWVuIFNJUC1iYXNlZCBmb3Ig
YSB3aGlsZSBub3cgDQooNiBtb250aHM/KSBNeSBjb21wYW55IGlzIG9uZSBvZiB0aGUgY2Fycmll
cnMgcHJvdmlkaW5nIHN1cHBvcnQuIFlvdSBtaWdodCANCmhhdmUgdG8gY2hlY2sgdGhlIFhQIG1l
c3NlbmdlciwgYWx0aG91Z2ggSSBkbyBiZWxpZXZlIDQuNiB3b3VsZCBiZSB0aGUgDQpyaWdodCBv
bmUuIElmIHlvdSBnZXQgdGhlIHZlcnNpb24gd2hlcmUgd2hlbiBtYWtpbmcgYSBwaG9uZSBjYWxs
LCB5b3WScmUgDQpnaXZlbiBhIGxpc3Qgb2Ygc2VydmljZXMgdG8gY2hvb3NlIGZyb20sIHRoZW4g
dGhhdJJzIHRoZSBTSVAgb25lLiBUaGUgb2xkIA0Kb25lIG9ubHkgYWxsb3dlZCB5b3UgdG8gdXNl
IHRoZSBOZXQyUGhvbmUgcHJvdG9jb2wuDQogDQpUb20gS2FybG8NCk5ldDJQaG9uZQ0KIA0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEF2c2hhbG9tIEhvdXJpIFttYWlsdG86QVZT
SEFMT01AaWwuaWJtLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAxNiwgMjAwMiA2OjM5IEFN
DQpUbzogSGVubmluZyBTY2h1bHpyaW5uZQ0KQ2M6IGltcHBAaWFzdGF0ZS5lZHU7IHNpbXBsZUBt
YWlsbWFuLmR5bmFtaWNzb2Z0LmNvbTsgUGV0ZXIgU2FpbnQtQW5kcmU7IFRvbnkgDQpIYW5zZW4N
ClN1YmplY3Q6IFJlOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeQ0KIA0KDQpJIHdhcyBjaGVja2lu
ZyB0aGUgV2luZG93cyBtZXNzZW5nZXIgdmVyc2lvbiA0LjYuIEFzIGZhciBhcyBJIGtub3c6IA0K
ICAgICAgICAqIFRoaXMgdmVyc2lvbiBpcyBiYXNlZCBvbiB0aGUgTVNOIHByb3RvY29sIGFuZCBu
b3QgU0lQLiANCiAgICAgICAgKiBUaGUgU0lQIGNsaWVudCBpcyBub3QgcHVibGljYWxseSBhdmFp
bGFibGUgeWV0LiANCg0KQXZzaGFsb20gSG91cmkNClByZXNlbmNlIGFuZCBJbnN0YW50IE1lc3Nh
Z2luZyBBcmNoaXRlY3QNCkxvdHVzIFNhbWV0aW1lLCBJQk0gU29mdHdhcmUgR3JvdXANCmF2c2hh
bG9tQGlsLmlibS5jb20NCg0KDQoNCg0KIA0KSGVubmluZyBTY2h1bHpyaW5uZSA8aGdzQGNzLmNv
bHVtYmlhLmVkdT4gDQoxNi8wNC8yMDAyIDAwOjI2IA0KUGxlYXNlIHJlc3BvbmQgdG8gSGVubmlu
ZyBTY2h1bHpyaW5uZSANCiAgICAgICAgDQogICAgICAgIFRvOiAgICAgICAgUGV0ZXIgU2FpbnQt
QW5kcmUgPHN0cGV0ZXJAamFiYmVyLm9yZz4gDQogICAgICAgIGNjOiAgICAgICAgVG9ueSBIYW5z
ZW4gPHRvbnlAYXR0LmNvbT4sIA0Kc2ltcGxlQG1haWxtYW4uZHluYW1pY3NvZnQuY29tLCBpbXBw
QGlhc3RhdGUuZWR1LCBBdnNoYWxvbSANCkhvdXJpL0hhaWZhL0lCTUBJQk1JTCANCiAgICAgICAg
U3ViamVjdDogICAgICAgIFJlOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeSANCg0KIA0KDQoNCkkn
bSBjdXJpb3VzOiBXaW5kb3dzIE1lc3Nlbmdlciwgc3VwcG9zZWRseSB1c2luZyBTSVAgYW5kIElN
UFAgcHJlc2VuY2UsDQpoYXMgYSBidW5jaCBvZiBzdGF0dXMgaW5kaWNhdGlvbnMsIHNpbWlsYXIg
dG8gdGhlIG9uZXMgbWVudGlvbmVkIG9uIHRoZQ0KbGlzdCAobHVuY2gsIGRvIG5vdCBkaXN0dXJi
LCBldGMuKS4gSG93IGFyZSB0aGV5IGVuY29kZWQ/DQoNClBldGVyIFNhaW50LUFuZHJlIHdyb3Rl
Og0KPiANCj4gRldJVywgd2UgcHJvdmlkZSB0aGUgZm9sbG93aW5nIHN0YXR1c2VzIChzdGF0aT8p
IGluIEphYmJlcjoNCj4gDQo+IDEuIFVuYXZhaWxhYmxlIChtYXBzIHRvIENMT1NFRCkNCj4gDQo+
IDIuIEF2YWlsYWJsZSAobWFwcyB0byBPUEVOKSB3aXRoIHN1Yi1zdGF0dXNlczoNCj4gICAgLSBh
d2F5DQo+ICAgIC0gZXh0ZW5kZWQgYXdheQ0KPiAgICAtIGRvIG5vdCBkaXN0dXJiDQo+ICAgIC0g
ZnJlZS9kZXNpcmluZyB0byBjaGF0DQo+IA0KPiAzLiBJbnZpc2libGUNCj4gDQo+IEFueSBzdGF0
dXMgY2FuIGJlIGV4dGVuZGVkIHdpdGggYSBuYXR1cmFsLWxhbmd1YWdlIGRlc2NyaXB0aW9uIG9m
IHRoZQ0KPiBzdGF0dXMuDQo+IA0KPiBNb3JlIGluZm9ybWF0aW9uIGF0DQo+IGh0dHA6Ly93d3cu
amFiYmVyLm9yZy9pZXRmL2RyYWZ0LW1pbGxlci1qYWJiZXItMDAuaHRtbCNjb21tb24tcHJlc2Vu
Y2UNCg0KDQoNCg==
--=_alternative 0068ACD3C2256B9D_=
Content-Type: text/html; charset="Windows-1255"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoYXQgaXMgc2lwIGJhc2VkIGlu
IHRoZSBYUCBXaW5kb3dzIG1lc3NlbmdlciBpcyBpbiB0aGUgVk9JUCBwYXJ0LiBUaGUgUElNIHBh
cnQgaXMgc3RpbGwgdXNpbmcgdGhlIE1TTiBwcm90b2NvbCAoVkVSIDExOSkgYXMgY2FuIGJlIHNl
ZW4gaWYgeW91IGxvb2sgYXQgdGhlIHBhY2tldHMgaXQgc2VuZHMuPC9mb250Pg0KPGJyPg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BdnNoYWxvbSBIb3VyaTxicj4NClByZXNl
bmNlIGFuZCBJbnN0YW50IE1lc3NhZ2luZyBBcmNoaXRlY3Q8YnI+DQpMb3R1cyBTYW1ldGltZSwg
SUJNIFNvZnR3YXJlIEdyb3VwPGJyPg0KYXZzaGFsb21AaWwuaWJtLmNvbTxicj4NCjxicj4NCjwv
Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10
b3A+DQo8dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlRvbSAmbmJz
cDtLYXJsbyAmbHQ7dGthcmxvQG5ldDJwaG9uZS5jb20mZ3Q7PC9iPjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U2VudCBieTogc2ltcGxlLWFkbWluQG1haWxtYW4u
ZHluYW1pY3NvZnQuY29tPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi
PjE2LzA0LzIwMDIgMTY6MjM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy
aWYiPlBsZWFzZSByZXNwb25kIHRvIFRvbSAmbmJzcDtLYXJsbzwvZm9udD4NCjxicj4NCjx0ZD48
Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBUbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXZzaGFsb20gSG91cmkv
SGFpZmEvSUJNQElCTUlMLCBIZW5uaW5nIFNjaHVsenJpbm5lICZsdDtoZ3NAY3MuY29sdW1iaWEu
ZWR1Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNjOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbXBw
QGlhc3RhdGUuZWR1LCBzaW1wbGVAbWFpbG1hbi5keW5hbWljc29mdC5jb20sIFBldGVyIFNhaW50
LUFuZHJlICZsdDtzdHBldGVyQGphYmJlci5vcmcmZ3Q7LCBUb255IEhhbnNlbiAmbHQ7dG9ueUBh
dHQuY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YmplY3Q6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwO1JFOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz
aXplPTEgZmFjZT0iQXJpYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48L3Rh
YmxlPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5B
Y3R1YWxseSwgdGhlIGxhdGVzdCBXaW5kb3dzIE1lc3NlbmdlciBoYXMgYmVlbiBTSVAtYmFzZWQg
Zm9yIGEgd2hpbGUgbm93ICg2IG1vbnRocz8pIE15IGNvbXBhbnkgaXMgb25lIG9mIHRoZSBjYXJy
aWVycyBwcm92aWRpbmcgc3VwcG9ydC4gWW91IG1pZ2h0IGhhdmUgdG8gY2hlY2sgdGhlIFhQIG1l
c3NlbmdlciwgYWx0aG91Z2ggSSBkbyBiZWxpZXZlIDQuNiB3b3VsZCBiZSB0aGUgcmlnaHQgb25l
LiBJZiB5b3UgZ2V0IHRoZSB2ZXJzaW9uIHdoZXJlIHdoZW4gbWFraW5nIGEgcGhvbmUgY2FsbCwg
eW91knJlIGdpdmVuIGEgbGlzdCBvZiBzZXJ2aWNlcyB0byBjaG9vc2UgZnJvbSwgdGhlbiB0aGF0
knMgdGhlIFNJUCBvbmUuIFRoZSBvbGQgb25lIG9ubHkgYWxsb3dlZCB5b3UgdG8gdXNlIHRoZSBO
ZXQyUGhvbmUgcHJvdG9jb2wuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAg
ZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgw
IGZhY2U9IkFyaWFsIj5Ub20gS2FybG88L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9IzAw
MDA4MCBmYWNlPSJBcmlhbCI+TmV0MlBob25lPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9y
PSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9MiBmYWNl
PSJUYWhvbWEiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGI+PGJyPg0KRnJvbTo8L2I+IEF2
c2hhbG9tIEhvdXJpIFttYWlsdG86QVZTSEFMT01AaWwuaWJtLmNvbV0gPGI+PGJyPg0KU2VudDo8
L2I+IFR1ZXNkYXksIEFwcmlsIDE2LCAyMDAyIDY6MzkgQU08Yj48YnI+DQpUbzo8L2I+IEhlbm5p
bmcgU2NodWx6cmlubmU8Yj48YnI+DQpDYzo8L2I+IGltcHBAaWFzdGF0ZS5lZHU7IHNpbXBsZUBt
YWlsbWFuLmR5bmFtaWNzb2Z0LmNvbTsgUGV0ZXIgU2FpbnQtQW5kcmU7IFRvbnkgSGFuc2VuPGI+
PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbU2ltcGxlXSBTdGF0dXMgc3VtbWFyeTwvZm9udD4NCjxw
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxwPjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJIHdhcyBjaGVja2luZyB0aGUgV2lu
ZG93cyBtZXNzZW5nZXIgdmVyc2lvbiA0LjYuIEFzIGZhciBhcyBJIGtub3c6PC9mb250Pjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsqIFRoaXMgdmVy
c2lvbiBpcyBiYXNlZCBvbiB0aGUgTVNOIHByb3RvY29sIGFuZCBub3QgU0lQLjwvZm9udD48Zm9u
dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNl
PSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KiBUaGUgU0lQ
IGNsaWVudCBpcyBub3QgcHVibGljYWxseSBhdmFpbGFibGUgeWV0LjwvZm9udD48Zm9udCBzaXpl
PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl
PSJzYW5zLXNlcmlmIj48YnI+DQpBdnNoYWxvbSBIb3VyaTxicj4NClByZXNlbmNlIGFuZCBJbnN0
YW50IE1lc3NhZ2luZyBBcmNoaXRlY3Q8YnI+DQpMb3R1cyBTYW1ldGltZSwgSUJNIFNvZnR3YXJl
IEdyb3VwPGJyPg0KYXZzaGFsb21AaWwuaWJtLmNvbTxicj4NCjwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3
aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MSU+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHRkIHdpZHRoPTI4JT48Zm9udCBz
aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SGVubmluZyBTY2h1bHpyaW5uZSAmbHQ7aGdzQGNz
LmNvbHVtYmlhLmVkdSZndDs8L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MTYvMDQv
MjAwMiAwMDoyNjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9m
b250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpQbGVhc2UgcmVzcG9uZCB0
byBIZW5uaW5nIFNjaHVsenJpbm5lPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPiA8L2ZvbnQ+DQo8dGQgd2lkdGg9NzAlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RvOiAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDtQZXRlciBTYWludC1BbmRyZSAmbHQ7c3RwZXRlckBqYWJiZXIub3Jn
Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxm
b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7Y2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RvbnkgSGFuc2VuICZsdDt0b255
QGF0dC5jb20mZ3Q7LCBzaW1wbGVAbWFpbG1hbi5keW5hbWljc29mdC5jb20sIGltcHBAaWFzdGF0
ZS5lZHUsIEF2c2hhbG9tIEhvdXJpL0hhaWZhL0lCTUBJQk1JTDwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl
cmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U3ViamVjdDogJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7UmU6IFtTaW1wbGVdIFN0YXR1cyBzdW1tYXJ5PC9mb250Pjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0x
IGZhY2U9IkFyaWFsIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9mb250PjwvdGFibGU+
DQo8cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8L2ZvbnQ+PGZv
bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpJJ20gY3VyaW91czogV2luZG93cyBN
ZXNzZW5nZXIsIHN1cHBvc2VkbHkgdXNpbmcgU0lQIGFuZCBJTVBQIHByZXNlbmNlLDxicj4NCmhh
cyBhIGJ1bmNoIG9mIHN0YXR1cyBpbmRpY2F0aW9ucywgc2ltaWxhciB0byB0aGUgb25lcyBtZW50
aW9uZWQgb24gdGhlPGJyPg0KbGlzdCAobHVuY2gsIGRvIG5vdCBkaXN0dXJiLCBldGMuKS4gSG93
IGFyZSB0aGV5IGVuY29kZWQ/PGJyPg0KPGJyPg0KUGV0ZXIgU2FpbnQtQW5kcmUgd3JvdGU6PGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IEZXSVcsIHdlIHByb3ZpZGUgdGhlIGZvbGxvd2luZyBzdGF0dXNl
cyAoc3RhdGk/KSBpbiBKYWJiZXI6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEuIFVuYXZhaWxhYmxl
IChtYXBzIHRvIENMT1NFRCk8YnI+DQomZ3Q7IDxicj4NCiZndDsgMi4gQXZhaWxhYmxlIChtYXBz
IHRvIE9QRU4pIHdpdGggc3ViLXN0YXR1c2VzOjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy0gYXdh
eTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOy0gZXh0ZW5kZWQgYXdheTxicj4NCiZndDsgJm5ic3A7
ICZuYnNwOy0gZG8gbm90IGRpc3R1cmI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDstIGZyZWUvZGVz
aXJpbmcgdG8gY2hhdDxicj4NCiZndDsgPGJyPg0KJmd0OyAzLiBJbnZpc2libGU8YnI+DQomZ3Q7
IDxicj4NCiZndDsgQW55IHN0YXR1cyBjYW4gYmUgZXh0ZW5kZWQgd2l0aCBhIG5hdHVyYWwtbGFu
Z3VhZ2UgZGVzY3JpcHRpb24gb2YgdGhlPGJyPg0KJmd0OyBzdGF0dXMuPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IE1vcmUgaW5mb3JtYXRpb24gYXQ8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuamFiYmVyLm9y
Zy9pZXRmL2RyYWZ0LW1pbGxlci1qYWJiZXItMDAuaHRtbCNjb21tb24tcHJlc2VuY2U8YnI+DQo8
L2ZvbnQ+DQo8cD4NCjxwPg0K
--=_alternative 0068ACD3C2256B9D_=--

From hgs@cs.columbia.edu  Tue Apr 16 16:16:29 2002
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 QAA06499
	for ; Tue, 16 Apr 2002 16:16:29 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA25239;
	Tue, 16 Apr 2002 16:15:27 -0400 (EDT)
Received: from cs.columbia.edu (slip-32-102-22-19.md.us.prserv.net [32.102.22.19])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g3GKFNPm004869
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 16 Apr 2002 16:15:26 -0400 (EDT)
Message-ID: <3CBC862E.BBEE9922@cs.columbia.edu>
Date: Tue, 16 Apr 2002 16:14:38 -0400
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com, impp@iastate.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 555
Subject: [Simple] Windows messenger
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: 

Xiaotao Wu in my lab just ran windump and confirmed that Windows
Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
SUBSCRIBE. For the "proof", see the message dumps at
http://www.cs.columbia.edu/sip/drafts/messenger.txt

To answer my own question: Messenger embraces and extends XPIDF:













From tony@att.com  Tue Apr 16 18:49:36 2002
Received: from jppxy1.proxy.att.com ([192.20.246.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06923
	for ; Tue, 16 Apr 2002 18:49:35 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by jppxy1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g3GMmWC18474
	for ; Wed, 17 Apr 2002 07:48:33 +0900 (JST)
Received: from att.com ([135.210.121.22])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020416224830gw100s10iue>
          (Authid: tony);
          Tue, 16 Apr 2002 22:48:30 +0000
Message-ID: <3CBCA9F0.6090607@att.com>
Date: Tue, 16 Apr 2002 18:47:12 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Justin Uberti 
CC: simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: Re: [Simple] Status summary
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 377
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: 

"Away with various configurable messages (CLOSED)" should really be
classified as OPEN, not closed. Although you are away, AOL still passes
messages through to you.

	Tony Hansen
	tony@att.com

Justin Uberti wrote:
 > AOL has open and closed statuses and hints.
 > * Online (OPEN)
 > * Offline (CLOSED)
 > * Away with various configurable messages (CLOSED)
 > * Idle (OPEN)




From Juberti@aol.com  Wed Apr 17 10:19:59 2002
Received: from imo-d09.mx.aol.com (imo-d09.mx.aol.com [205.188.157.41])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09361
	for ; Wed, 17 Apr 2002 10:19:59 -0400 (EDT)
Received: from Juberti@aol.com
	by imo-d09.mx.aol.com (mail_out_v32.5.) id 7.174.6d4a40b (15901);
	Wed, 17 Apr 2002 10:18:25 -0400 (EDT)
Received: from  pcsn602343 ([10.2.115.71]) by air-id09.mx.aol.com (v84.14) with ESMTP id MAILINID94-0417101825; Wed, 17 Apr 2002 10:18:25 -0400
From: "Justin Uberti" 
To: "Tony Hansen" 
Cc: , 
Subject: RE: [Simple] Status summary
Date: Wed, 17 Apr 2002 10:18:25 -0400
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3CBCA9F0.6090607@att.com>
Content-Length: 1056
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: 

Agreed; I had misunderstood the meaning of CLOSED.

Note that being away can cause a message to be routed elsewhere, (e.g. to
your pager if you are away on your desktop), but I suppose this is still
OPEN, since the message is still delivered somewhere.

Justin Uberti
America Online

> -----Original Message-----
> From: owner-impp@iastate.edu [mailto:owner-impp@iastate.edu]On Behalf Of
> tony@att.com
> Sent: Tuesday, April 16, 2002 6:47 PM
> To: Justin Uberti
> Cc: simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: Re: [Simple] Status summary
>
>
> "Away with various configurable messages (CLOSED)" should really be
> classified as OPEN, not closed. Although you are away, AOL still passes
> messages through to you.
>
>     Tony Hansen
>     tony@att.com
>
> Justin Uberti wrote:
>  > AOL has open and closed statuses and hints.
>  > * Online (OPEN)
>  > * Offline (CLOSED)
>  > * Away with various configurable messages (CLOSED)
>  > * Idle (OPEN)
>
>
>
>
>
>   [reminder: meta-impp@iastate.edu for non-technical discussions, please]
>
>


From tony@att.com  Wed Apr 17 14:28:51 2002
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10072
	for ; Wed, 17 Apr 2002 14:28:50 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g3HIRl516027
	for ; Wed, 17 Apr 2002 13:27:47 -0500 (CDT)
Received: from att.com ([135.210.41.41])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020417182747gw100s10goe>
          (Authid: tony);
          Wed, 17 Apr 2002 18:27:47 +0000
Message-ID: <3CBDBB8D.5000400@att.com>
Date: Wed, 17 Apr 2002 14:14:37 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
CC: simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: Re: [Simple] Status summary
References:  <3CBB4583.94152842@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1078
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: 

One aspect that hasn't come up yet in this conversation is something 
someone said at the ad-hoc mtg in MN: the temporal aspect of the various 
types of OPEN status messages. Why do you choose to use one message over 
another? Usually it's to give the others an idea of how quickly you'll 
respond.

Some of them mean "I'm doing stuff, but will probably respond to your 
message pretty quickly." (T = a couple minutes) Examples: Busy, On the 
Phone.

Some of them mean "I'm going to be gone for a while." (T = 1/2 - 1 hour) 
Example: Out to Lunch.

Some of them mean "Don't expect me to respond for hours." (T = 2-4 
hours) Example: Away, In Meetings.

Some of them mean "Don't expect me back for a long time." (T > 4 hours) 
Example: Out for the weekend.

When you go international, Out to Lunch doesn't mean a whole lot to 
anyone but English speakers. But specifying an expected time to be gone 
set at .5-1 hour certainly does translate well. Time is a pretty 
universal concept, and might be worth codifying as part of the status 
information.

	Tony Hansen
	tony@att.com


From AVSHALOM@il.ibm.com  Wed Apr 17 14:31:19 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10101
	for ; Wed, 17 Apr 2002 14:31:18 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA99332;
	Wed, 17 Apr 2002 20:30:12 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HIUBL83060;
	Wed, 17 Apr 2002 20:30:11 +0200
To: , 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Wed, 17 Apr 2002 21:30:13 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 17/04/2002 21:30:11,
	Serialize complete at 17/04/2002 21:30:11
Content-Type: multipart/alternative; boundary="=_alternative 0065A42EC2256B9E_="
Content-Length: 10473
Subject: [Simple] Re: PIDF status values
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: 

This is a multipart message in MIME format.
--=_alternative 0065A42EC2256B9E_=
Content-Type: text/plain; charset="us-ascii"

Following a discussion in the SIMPLE group I am not sure that values such 
as 
"away" or "busy" are really statuses. They seem to be *hints* to the user 
on how 
s/he should anticipate that the message will be handled. The actual 
handling of 
"away" for example can be displaying the message in hidden window in one 
system 
and in other system the message will be displayed in a pop up window.

In parallel it seems that this discussion should be a joint discussion of 
the 
SIMPLE and the IMPP groups.

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com






"Adrian Bateman" 
Sent by: owner-impp@iastate.edu
17/04/2002 13:39
Please respond to "Adrian Bateman"

 
        To:        "'Mark Day'" , "'Hiroyasu Sugano'" 
, "'Graham Klyne'" 
        cc:        
        Subject:        PIDF status values

 

This is a draft describing the my proposal for the structure of the
status values within PIDF. My example reflects the urn change
recommended by Graham and the use of the 'entity' attribute as discussed
previously on the list.

When it came down to it, I couldn't think of a tremendous amount to
write for the 4.2.4 section so if there are gaps you'd like mentioned,
please let me know, or fill them in :o).

To address Graham's issue with a status value registry, aren't we
covered by simply registering the xml namespace urn?

Regards,

Adrian.


4.1.4  The  element

   The  element contains one or more elements indicating status
   values. It can have multiple status values at the same time. By
   allowing multiple status values in a single  element,
different
   types of status values, e.g. reachability and location, can be
   represented by a . See Section 4.3 for an example with
multiple
   status values.

   This memo only defines the  status value element. Other status
   values may be included using the standard extensibility framework
   (see Section 4.2.4). Applications encountering unrecognized elements
   within  may ignore them, unless they carry a
mustUnderstand="YES"
   attribute (see section 4.2.3).


4.1.5  The  element

   The  element contains a CDATA value whose possible values are
   either "open" or "closed". The values "open" and "closed" has the
   same meaning as OPEN and CLOSED defined in RFC 2778 respectively, and
   stand for availability of receiving instant messages if the 
is
   for an instant messaging address. They also have meanings of general
   availability for other communication means. But, this memo does not
   specify them in detail.


---


4.2.4  Status value extensibility

   This memo only defines the  status value with values of "open"
   and "closed". Other status values are possible using the standard
   namespace-based extensibility rules defined above.

   For example, a location status value might be included thus:
 
       
         
           
             open
             home
           
           im:someone@example.com
         
       

   Some new status values will 'extend' the value of the 
element.
   For example, a status value defined for use with instant messaging
may
   include values such as 'away', 'busy' and 'offline'. In order that
   some level of interoperability be maintained with user agents that
   don't recognise the new extension, the  status value must also
   be included. This means that extensions are not obligated to define a
   mapping from each of their values to OPEN or CLOSED.




  [reminder: meta-impp@iastate.edu for non-technical discussions, please]




--=_alternative 0065A42EC2256B9E_=
Content-Type: text/html; charset="us-ascii"



Following a discussion in the SIMPLE group I am not sure that values such as 

"away" or "busy" are really statuses. They seem to be *hints* to the user on how 

s/he should anticipate that the message will be handled. The actual handling of 

"away" for example can be displaying the message in hidden window in one system 

and in other system the message will be displayed in a pop up window.



In parallel it seems that this discussion should be a joint discussion of the 

SIMPLE and the IMPP groups.



Avshalom Houri

Presence and Instant Messaging Architect

Lotus Sametime, IBM Software Group

avshalom@il.ibm.com















"Adrian Bateman" <bateman@acm.org>

Sent by: owner-impp@iastate.edu

17/04/2002 13:39

Please respond to "Adrian Bateman"



        

        To:        "'Mark Day'" <markday@cisco.com>, "'Hiroyasu Sugano'" <suga@flab.fujitsu.co.jp>, "'Graham Klyne'" <GK@ninebynine.org>

        cc:        <impp@iastate.edu>

        Subject:        PIDF status values



       




This is a draft describing the my proposal for the structure of the

status values within PIDF. My example reflects the urn change

recommended by Graham and the use of the 'entity' attribute as discussed

previously on the list.



When it came down to it, I couldn't think of a tremendous amount to

write for the 4.2.4 section so if there are gaps you'd like mentioned,

please let me know, or fill them in :o).



To address Graham's issue with a status value registry, aren't we

covered by simply registering the xml namespace urn?



Regards,



Adrian.





4.1.4  The <status> element



   The <status> element contains one or more elements indicating status

   values. It can have multiple status values at the same time. By

   allowing multiple status values in a single <tuple> element,

different

   types of status values, e.g. reachability and location, can be

   represented by a <tuple>. See Section 4.3 for an example with

multiple

   status values.



   This memo only defines the <basic> status value element. Other status

   values may be included using the standard extensibility framework

   (see Section 4.2.4). Applications encountering unrecognized elements

   within <status> may ignore them, unless they carry a

mustUnderstand="YES"

   attribute (see section 4.2.3).





4.1.5  The <basic> element



   The <basic> element contains a CDATA value whose possible values are

   either "open" or "closed". The values "open" and "closed" has the

   same meaning as OPEN and CLOSED defined in RFC 2778 respectively, and

   stand for availability of receiving instant messages if the <tuple>

is

   for an instant messaging address. They also have meanings of general

   availability for other communication means. But, this memo does not

   specify them in detail.





---





4.2.4  Status value extensibility



   This memo only defines the <basic> status value with values of "open"

   and "closed". Other status values are possible using the standard

   namespace-based extensibility rules defined above.



   For example, a location status value might be included thus:

   

       <presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"

           xmlns:local="urn:example-com:pidf-status-type"

           entity="pres:someone@example.com">

         <tuple id="im">

           <status>

             <basic>open</basic>

             <local:location>home</local:location>

           </status>

           <contact>im:someone@example.com</contact>

         </tuple>

       </presence>



   Some new status values will 'extend' the value of the <basic>

element.

   For example, a status value defined for use with instant messaging

may

   include values such as 'away', 'busy' and 'offline'. In order that

   some level of interoperability be maintained with user agents that

   don't recognise the new extension, the <basic> status value must also

   be included. This means that extensions are not obligated to define a

   mapping from each of their values to OPEN or CLOSED.









  [reminder: meta-impp@iastate.edu for non-technical discussions, please]








--=_alternative 0065A42EC2256B9E_=--

From AVSHALOM@il.ibm.com  Wed Apr 17 14:35:04 2002
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10147
	for ; Wed, 17 Apr 2002 14:35:03 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id UAA37058;
	Wed, 17 Apr 2002 20:34:02 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3HIY2l43618;
	Wed, 17 Apr 2002 20:34:02 +0200
To: impp@iastate.edu, simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Subject: Re: [Simple] Windows messenger
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Wed, 17 Apr 2002 21:34:05 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 17/04/2002 21:34:02,
	Serialize complete at 17/04/2002 21:34:02
Content-Type: multipart/alternative; boundary="=_alternative 0065FEF8C2256B9E_="
Content-Length: 4593
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: 

This is a multipart message in MIME format.
--=_alternative 0065FEF8C2256B9E_=
Content-Type: text/plain; charset="us-ascii"

I want to clarify the confusion. I have talked with Jonathan Christensen 
from MS and the status is this: 

The public .NET passport account uses a combination of SIP and  the MSN 
proprietary protocol for IM and presence.  A/V is negotiated with SIP and media is transported with standard RTP.

If you are talking with a SIP server the client talks SIP (you need to 
enable it via Tools/Options/Accounts/Communication Service). 

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com






Henning Schulzrinne 
Sent by: simple-admin@mailman.dynamicsoft.com
16/04/2002 23:14
Please respond to Henning Schulzrinne

 
        To:        simple@mailman.dynamicsoft.com, impp@iastate.edu
        cc: 
        Subject:        [Simple] Windows messenger

 

Xiaotao Wu in my lab just ran windump and confirmed that Windows
Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
SUBSCRIBE. For the "proof", see the message dumps at
http://www.cs.columbia.edu/sip/drafts/messenger.txt

To answer my own question: Messenger embraces and extends XPIDF:












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



--=_alternative 0065FEF8C2256B9E_=
Content-Type: text/html; charset="us-ascii"



I want to clarify the confusion. I have talked with Jonathan Christensen from MS and the status is this: 



The public .NET passport account uses a combination of SIP and  the MSN  proprietary protocol for IM and presence.  A/V is negotiated with SIP and media is transported with standard RTP.



If you are talking with a SIP server the client talks SIP (you need to enable it via Tools/Options/Accounts/Communication Service). 



Avshalom Houri

Presence and Instant Messaging Architect

Lotus Sametime, IBM Software Group

avshalom@il.ibm.com















Henning Schulzrinne <hgs@cs.columbia.edu>

Sent by: simple-admin@mailman.dynamicsoft.com

16/04/2002 23:14

Please respond to Henning Schulzrinne



        

        To:        simple@mailman.dynamicsoft.com, impp@iastate.edu

        cc:        

        Subject:        [Simple] Windows messenger



       




Xiaotao Wu in my lab just ran windump and confirmed that Windows

Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,

SUBSCRIBE. For the "proof", see the message dumps at

http://www.cs.columbia.edu/sip/drafts/messenger.txt



To answer my own question: Messenger embraces and extends XPIDF:



<presence>

<presentity uri="sip:xiaotaow@cs.columbia.edu;method=SUBSCRIBE" />

<atom id="1003">

<address uri="sip:128.59.19.251:13170;user=ip" priority="0.800000">

<status status="open" />

<msnsubstatus substatus="online" />

</address>

</atom>

</presence>

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple






--=_alternative 0065FEF8C2256B9E_=--

From bcampbell@dynamicsoft.com  Wed Apr 17 14:51:49 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10223
	for ; Wed, 17 Apr 2002 14:51:48 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3HIogX77907;
	Wed, 17 Apr 2002 13:50:42 -0500 (CDT)
From: "Ben Campbell" 
To: "Tony Hansen" 
Cc: , 
Subject: RE: [Simple] Status summary
Date: Wed, 17 Apr 2002 13:50:18 -0500
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)
In-reply-to: <3CBDBB8D.5000400@att.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 2025
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: 

It seems to me this concept is still more intended for _human_ consumption.
It would be dangerous to provide any protocol semantic or other automatic
processing based on the assumption that I will be back at a certain time,
unless we build in explicit expiration times for the piece of state.

So, all of the following can be handled by some sort of "away" status that
contains a human readable comment (or some other indicator for user display
purposes only).

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Tony Hansen
> Sent: Wednesday, April 17, 2002 1:15 PM
> Cc: simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: Re: [Simple] Status summary
>
>
> One aspect that hasn't come up yet in this conversation is something
> someone said at the ad-hoc mtg in MN: the temporal aspect of the various
> types of OPEN status messages. Why do you choose to use one message over
> another? Usually it's to give the others an idea of how quickly you'll
> respond.
>
> Some of them mean "I'm doing stuff, but will probably respond to your
> message pretty quickly." (T = a couple minutes) Examples: Busy, On the
> Phone.
>
> Some of them mean "I'm going to be gone for a while." (T = 1/2 - 1 hour)
> Example: Out to Lunch.
>
> Some of them mean "Don't expect me to respond for hours." (T = 2-4
> hours) Example: Away, In Meetings.
>
> Some of them mean "Don't expect me back for a long time." (T > 4 hours)
> Example: Out for the weekend.
>
> When you go international, Out to Lunch doesn't mean a whole lot to
> anyone but English speakers. But specifying an expected time to be gone
> set at .5-1 hour certainly does translate well. Time is a pretty
> universal concept, and might be worth codifying as part of the status
> information.
>
> 	Tony Hansen
> 	tony@att.com
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple


From bateman@acm.org  Wed Apr 17 15:15:52 2002
Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10313
	for ; Wed, 17 Apr 2002 15:15:51 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 16xutE-0002gM-00; Wed, 17 Apr 2002 20:14:48 +0100
Received: from modem-1152.wolf.dialup.pol.co.uk ([217.134.84.128] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 16xutA-0007zz-00; Wed, 17 Apr 2002 20:14:44 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Avshalom Houri'" , ,
        
Subject: RE: [Simple] Re: PIDF status values
Date: Wed, 17 Apr 2002 20:14:39 +0100
Organization: VisionTech Limited
Message-ID: <000401c1e644$1fbc4000$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: 
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 5673
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: 

On 17 April 2002 19:30, Avshalom Houri wrote:
> 
> Following a discussion in the SIMPLE group I am not sure that values 
> such as
> "away" or "busy" are really statuses. They seem to be *hints* to the
user on how 
> s/he should anticipate that the message will be handled. The actual
handling of 
> "away" for example can be displaying the message in hidden window in
one system 
> and in other system the message will be displayed in a pop up window. 

What's the difference between a status value and a hint? RFC 2778
doesn't define a hint, it merely refers to STATUS. In any event, in PIDF
we made a conscious decision to include only OPEN and CLOSED and to
leave the definition of other status ranges for future invention.

It seems to me that the value of some status elements will, perhaps more
often than not, be processed automatically, maybe to determine an icon
to display. These values are well defined and are as much status
information as open/closed, just intended for a different purpose.
Status values aren't limited only to those determining the presentity's
likely acceptance of instant messages. RFC 2778 just says that in that
case (instant messaging) the values OPEN and CLOSED are at minimum
necessary.

The language below uses 'away' and 'busy' simply as examples using words
that many people using current Instant Messaging agents will recognise.
If you'd prefer alternative language, by all means suggest some. My
point is to emphasise that we should maintain the basic open/closed
values for interoperability and that it isn't mandatory to define
mappings from other status ranges to the basic values.

> In parallel it seems that this discussion should be a joint discussion

> of the SIMPLE and the IMPP groups.

Yes, I for one welcome further input. The IMPP group is quiet and there
is much more activity in SIMPLE. In fact, I requested just such
discussion in my message to the SIMPLE list last Friday.

Best regards,

Adrian.

> 
> Avshalom Houri
> Presence and Instant Messaging Architect
> Lotus Sametime, IBM Software Group
> avshalom@il.ibm.com
> 
> 
> 
> 
> 
> 	"Adrian Bateman" 
> Sent by: owner-impp@iastate.edu 
> 
> 17/04/2002 13:39
> Please respond to "Adrian Bateman" 
>         
>         To:        "'Mark Day'" , "'Hiroyasu
Sugano'" , "'Graham Klyne'" 

>         cc:         
>         Subject:        PIDF status values 
> 
>        
> 
> 
> This is a draft describing the my proposal for the structure of the 
> status values within PIDF. My example reflects the urn change 
> recommended by Graham and the use of the 'entity' attribute as 
> discussed previously on the list.
> 
> When it came down to it, I couldn't think of a tremendous amount to 
> write for the 4.2.4 section so if there are gaps you'd like mentioned,

> please let me know, or fill them in :o).
> 
> To address Graham's issue with a status value registry, aren't we 
> covered by simply registering the xml namespace urn?
> 
> Regards,
> 
> Adrian.
> 
> 
> 4.1.4  The  element
> 
>   The  element contains one or more elements indicating status
>   values. It can have multiple status values at the same time. By
>   allowing multiple status values in a single  element,
different
>   types of status values, e.g. reachability and location, can be
>   represented by a . See Section 4.3 for an example with
multiple
>   status values.
> 
>   This memo only defines the  status value element. Other
status
>   values may be included using the standard extensibility framework
>   (see Section 4.2.4). Applications encountering unrecognized elements
>   within  may ignore them, unless they carry a
mustUnderstand="YES"
>   attribute (see section 4.2.3).
> 
> 
> 4.1.5  The  element
> 
>   The  element contains a CDATA value whose possible values are
>   either "open" or "closed". The values "open" and "closed" has the
>   same meaning as OPEN and CLOSED defined in RFC 2778 respectively,
and
>   stand for availability of receiving instant messages if the 
is
>   for an instant messaging address. They also have meanings of general
>   availability for other communication means. But, this memo does not
>   specify them in detail.
> 
> 
> ---
> 
> 
> 4.2.4  Status value extensibility
> 
>   This memo only defines the  status value with values of
"open"
>   and "closed". Other status values are possible using the standard
>   namespace-based extensibility rules defined above.
> 
>   For example, a location status value might be included thus:
>   
>                  xmlns:local="urn:example-com:pidf-status-type"
>           entity="pres:someone@example.com">
>         
>           
>             open
>             home
>           
>           im:someone@example.com
>          
>        
> 
>   Some new status values will 'extend' the value of the 
element.
>   For example, a status value defined for use with instant messaging
may
>   include values such as 'away', 'busy' and 'offline'. In order that
>   some level of interoperability be maintained with user agents that
>   don't recognise the new extension, the  status value must
also
>   be included. This means that extensions are not obligated to define
a
>   mapping from each of their values to OPEN or CLOSED.
> 
> 
> 
> 
>  [reminder: meta-impp@iastate.edu for non-technical discussions, 
> please]
> 
> 
> 
> 
> 



From pkyzivat@cisco.com  Wed Apr 17 15:29:13 2002
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 PAA10377
	for ; Wed, 17 Apr 2002 15:29:13 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3HJSNtJ029612;
	Wed, 17 Apr 2002 15:28:24 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI57885;
	Wed, 17 Apr 2002 15:31:18 -0400 (EDT)
Message-ID: <3CBDCCBF.9DA43CCC@cisco.com>
Date: Wed, 17 Apr 2002 15:27:59 -0400
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: Ben Campbell 
CC: Tony Hansen , simple@mailman.dynamicsoft.com,
        impp@iastate.edu
Subject: Re: [Simple] Status summary
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3064
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: 

I see some parallels between open/away/closed and 200/202/4xx.

- "Open" means (sort of) that a MESSAGE should return a 200 - will be displayed and hopefully seen immediately.

- "Away" means (sort of) that a MESSAGE should return a 202 - will be accepted, but may not be displayed, or if displayed may not be seen immediately.

- "Closed" means (sort of) that a MESSAGE should fail because there is nobody willing or able to receive it.

The parallels aren't perfect by any means. E.g. 200 doesn't really mean that the message has been seen. Yet in some sense I think the purpose of the presence status is to
give a hint about what is likely to happen if communication is attempted. Maybe it would be helpful to make better parallels.

	Paul

Ben Campbell wrote:
> 
> It seems to me this concept is still more intended for _human_ consumption.
> It would be dangerous to provide any protocol semantic or other automatic
> processing based on the assumption that I will be back at a certain time,
> unless we build in explicit expiration times for the piece of state.
> 
> So, all of the following can be handled by some sort of "away" status that
> contains a human readable comment (or some other indicator for user display
> purposes only).
> 
> > -----Original Message-----
> > From: simple-admin@mailman.dynamicsoft.com
> > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Tony Hansen
> > Sent: Wednesday, April 17, 2002 1:15 PM
> > Cc: simple@mailman.dynamicsoft.com; impp@iastate.edu
> > Subject: Re: [Simple] Status summary
> >
> >
> > One aspect that hasn't come up yet in this conversation is something
> > someone said at the ad-hoc mtg in MN: the temporal aspect of the various
> > types of OPEN status messages. Why do you choose to use one message over
> > another? Usually it's to give the others an idea of how quickly you'll
> > respond.
> >
> > Some of them mean "I'm doing stuff, but will probably respond to your
> > message pretty quickly." (T = a couple minutes) Examples: Busy, On the
> > Phone.
> >
> > Some of them mean "I'm going to be gone for a while." (T = 1/2 - 1 hour)
> > Example: Out to Lunch.
> >
> > Some of them mean "Don't expect me to respond for hours." (T = 2-4
> > hours) Example: Away, In Meetings.
> >
> > Some of them mean "Don't expect me back for a long time." (T > 4 hours)
> > Example: Out for the weekend.
> >
> > When you go international, Out to Lunch doesn't mean a whole lot to
> > anyone but English speakers. But specifying an expected time to be gone
> > set at .5-1 hour certainly does translate well. Time is a pretty
> > universal concept, and might be worth codifying as part of the status
> > information.
> >
> >       Tony Hansen
> >       tony@att.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 aki.niemi@nokia.com  Thu Apr 18 08:15:50 2002
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 IAA13089
	for ; Thu, 18 Apr 2002 08:15:48 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g3ICF6F16767
	for ; Thu, 18 Apr 2002 15:15:06 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 18 Apr 2002 15:14:47 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 18 Apr 2002 15:14:47 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Status summary
Date: Thu, 18 Apr 2002 15:14:46 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECD0@esebe013.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Status summary
Thread-Index: AcHmSgvjPy7lAhhYQv6gLxRU+BMT+wAh6iRw
To: , 
Cc: , , 
X-OriginalArrivalTime: 18 Apr 2002 12:14:47.0268 (UTC) FILETIME=[A1A6FA40:01C1E6D2]
Content-Length: 904
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA13089
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: 

> I see some parallels between open/away/closed and 200/202/4xx.
> 
> - "Open" means (sort of) that a MESSAGE should return a 200 - 
> will be displayed and hopefully seen immediately.
> 
> - "Away" means (sort of) that a MESSAGE should return a 202 - 
> will be accepted, but may not be displayed, or if displayed 
> may not be seen immediately.

Correct me if I'm wrong, but reading draft-ietf-sip-message-02.txt, my understanding was that the 202 would *not* convey information on the handling of the message, i.e., whether it is displayed or not. 

It is sent back by a GW, or a message relay, and simply means that the message wasn't actually delivered to the recipient, but stored, gatewayed, etc, and may be delivered at a later time if at all.

Similarly, the 200 only states, that the message was received by the recipient, not necessarily displayed, seen, read, understood, etc.

Cheers,
Aki  

From bcampbell@dynamicsoft.com  Thu Apr 18 09:05:23 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13239
	for ; Thu, 18 Apr 2002 09:05:23 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g3ID43X56243;
	Thu, 18 Apr 2002 08:04:04 -0500 (CDT)
From: "Ben Campbell" 
To: , 
Cc: , , 
Subject: RE: [Simple] Status summary
Date: Thu, 18 Apr 2002 08:03:38 -0500
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)
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECD0@esebe013.NOE.Nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 1483
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: 


> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Thursday, April 18, 2002 7:15 AM
> To: pkyzivat@cisco.com; bcampbell@dynamicsoft.com
> Cc: tony@att.com; simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: RE: [Simple] Status summary
>
>
> > I see some parallels between open/away/closed and 200/202/4xx.
> >
> > - "Open" means (sort of) that a MESSAGE should return a 200 -
> > will be displayed and hopefully seen immediately.
> >
> > - "Away" means (sort of) that a MESSAGE should return a 202 -
> > will be accepted, but may not be displayed, or if displayed
> > may not be seen immediately.
>
> Correct me if I'm wrong, but reading
> draft-ietf-sip-message-02.txt, my understanding was that the 202
> would *not* convey information on the handling of the message,
> i.e., whether it is displayed or not.
>
> It is sent back by a GW, or a message relay, and simply means
> that the message wasn't actually delivered to the recipient, but
> stored, gatewayed, etc, and may be delivered at a later time if at all.
>
> Similarly, the 200 only states, that the message was received by
> the recipient, not necessarily displayed, seen, read, understood, etc.

Yes, this is correct. For example, a given service _might_ choose to return
202 all the time, if it perhaps did not want to indicate to the sender that
some messages go directly and others get store-and-forwarded. (I'm
not_suggesting_ this behavior, but it is legal).


From pkyzivat@cisco.com  Thu Apr 18 09:09:30 2002
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 JAA13273
	for ; Thu, 18 Apr 2002 09:09:29 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3ID8ibI017105;
	Thu, 18 Apr 2002 09:08:45 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI61363;
	Thu, 18 Apr 2002 09:11:38 -0400 (EDT)
Message-ID: <3CBEC543.E89B8C44@cisco.com>
Date: Thu, 18 Apr 2002 09:08:20 -0400
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: bcampbell@dynamicsoft.com, tony@att.com, simple@mailman.dynamicsoft.com,
        impp@iastate.edu
Subject: Re: [Simple] Status summary
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECD0@esebe013.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1447
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: 

aki.niemi@nokia.com wrote:
> 
> > I see some parallels between open/away/closed and 200/202/4xx.
> >
> > - "Open" means (sort of) that a MESSAGE should return a 200 -
> > will be displayed and hopefully seen immediately.
> >
> > - "Away" means (sort of) that a MESSAGE should return a 202 -
> > will be accepted, but may not be displayed, or if displayed
> > may not be seen immediately.
> 
> Correct me if I'm wrong, but reading draft-ietf-sip-message-02.txt, my understanding was that the 202 would *not* convey information on the handling of the message, i.e., whether it is displayed or not.
> 
> It is sent back by a GW, or a message relay, and simply means that the message wasn't actually delivered to the recipient, but stored, gatewayed, etc, and may be delivered at a later time if at all.
> 
> Similarly, the 200 only states, that the message was received by the recipient, not necessarily displayed, seen, read, understood, etc.

You are not wrong - the meanings are not exactly the same,
which is why I qualified the statements above with 
"(sort of)", and in the next paragraph of my message...

Paul Kyzivat wrote:
> 
> The parallels aren't perfect by any means. E.g. 200 doesn't really mean
> that the message has been seen. Yet in some sense I think the purpose
> of the presence status is to give a hint about what is likely to happen
> if communication is attempted.
> Maybe it would be helpful to make better parallels.

	Paul

From DMoore@ezenia.com  Thu Apr 18 13:04:59 2002
Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13952
	for ; Thu, 18 Apr 2002 13:04:59 -0400 (EDT)
Received: from us-exchange-1.ezenia.com by dfw7sosrv11.alter.net with ESMTP 
	(peer crosschecked as: [208.209.226.82])
	id QQmldk18441;
	Thu, 18 Apr 2002 17:03:08 GMT
Received: by us-exchange-1.ezenia.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 18 Apr 2002 13:10:29 -0400
Message-ID: 
From: Duane Moore 
To: "'Christian Jansson'" ,
        Henning Schulzrinne ,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: RE: [Simple] Windows messenger
Date: Thu, 18 Apr 2002 13:10:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 1684
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: 

This is true, but is there any fully compliant SIP/SIMPLE/CPIM client
available yet?  I would expect future versions of Windows Messenger to
better support the standards as they are finalized.

-----Original Message-----
From: Christian Jansson [mailto:christian.jansson@hotsip.com] 
Sent: Thursday, April 18, 2002 9:37 AM
To: Henning Schulzrinne; simple@mailman.dynamicsoft.com; impp@iastate.edu
Subject: RE: [Simple] Windows messenger


But the Messenger seems to have a big problem with the presence
format. The presentity uri should identify the presentity for 
whom the presence data is being reported, but Messenger instead
sends the address of the receiver of the information!? 

The Messenger also does not have any Event header its NOTIFY
messages, and it sends a NOTIFY without any content to indicate
that it is offline.

/ Christian Jansson
 
> Xiaotao Wu in my lab just ran windump and confirmed that Windows
> Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
> SUBSCRIBE. For the "proof", see the message dumps at
> http://www.cs.columbia.edu/sip/drafts/messenger.txt
> 
> To answer my own question: Messenger embraces and extends XPIDF:
> 
> 
> 
> 
> 

> 
> 
> 

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



  [reminder: meta-impp@iastate.edu for non-technical discussions, please]

From nsyracus@cnri.reston.va.us  Fri Apr 19 07:24:19 2002
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 HAA16924
	for ; Fri, 19 Apr 2002 07:24:19 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16051;
	Fri, 19 Apr 2002 07:23:15 -0400 (EDT)
Message-Id: <200204191123.HAA16051@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 19 Apr 2002 07:23:15 -0400
Content-Length: 3309
Subject: [Simple] I-D ACTION:draft-ietf-sip-message-03.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-sip-message-03.txt
	Pages		: 19
	Date		: 18-Apr-02
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-message-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-message-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020418141051.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-message-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-message-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020418141051.I-D@ietf.org>

--OtherAccess--

--NextPart--



From aki.niemi@nokia.com  Fri Apr 19 09:31:36 2002
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 JAA17335
	for ; Fri, 19 Apr 2002 09:31:35 -0400 (EDT)
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.2.1/Switch-2.2.0) with ESMTP id g3JDUqF03559
	for ; Fri, 19 Apr 2002 16:30:52 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 19 Apr 2002 16:30:33 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 19 Apr 2002 16:30:33 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Statuses and response codes (Was: RE: [Simple] Status summary)
Date: Fri, 19 Apr 2002 16:30:33 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECD3@esebe013.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Status summary
Thread-Index: AcHm2ik1tHv71taQR4a5XxY7swhbBAAyp5Sg
To: 
Cc: , ,
        , 
X-OriginalArrivalTime: 19 Apr 2002 13:30:33.0638 (UTC) FILETIME=[61E9BC60:01C1E7A6]
Content-Length: 532
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA17335
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: 

Hi Paul,

> You are not wrong - the meanings are not exactly the same,
> which is why I qualified the statements above with 
> "(sort of)", and in the next paragraph of my message...

You are right, I probably got a little trigger happy with my response :-)

But if I edit the parallels you listed a little bit, could they still be used in a meaningful way?
  
	- Open: you can expect a 200 for the MESSAGE
	- Away: you probably can expect a 2xx
	- Closed: you can expect a 4xx, or a 202, but not a 200 for the MESSAGE

Cheers,
Aki

From pkyzivat@cisco.com  Fri Apr 19 13:35:01 2002
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 NAA18121
	for ; Fri, 19 Apr 2002 13:35:01 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3JHYEtV002601;
	Fri, 19 Apr 2002 13:34:14 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAI70570;
	Fri, 19 Apr 2002 13:37:08 -0400 (EDT)
Message-ID: <3CC054FD.796CABC9@cisco.com>
Date: Fri, 19 Apr 2002 13:33:49 -0400
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: Christian Huitema 
CC: aki.niemi@nokia.com, bcampbell@dynamicsoft.com, tony@att.com,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: Re: Statuses and response codes (Was: RE: [Simple] Status summary)
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1736
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: 

While the privacy concerns are significant, it seems to me that they should be largely equivalent in the two mechanisms. Someone who is intent on learning as much as
possible about my status will use every feature at hand, so hiding information via one channel but not the other is not useful.

Presence is not useful if it gives information that is often inconsistent with what I would discover by sending a MESSAGE or INVITE.

If I want to lie about my presence, then I should also set my UA up so that it lies in a consistent way to callers.

	Paul

Christian Huitema wrote:
> 
> >       - Open: you can expect a 200 for the MESSAGE
> >       - Away: you probably can expect a 2xx
> >       - Closed: you can expect a 4xx, or a 202, but not a 200 for the
> 
> We have to be a bit careful with this line of reasoning, and consider
> the privacy implications. I would argue that the response to MESSAGE
> SHOULD NOT provide an indication on the recipient's online status, or at
> least not in the general case. Otherwise, MESSAGE can be used as a
> covert channel to assess someone's presence status without going through
> the authorization mechanism built in subscriptions. Indeed, it may be OK
> to provide such status when the source of the message is an authorized
> subscriber to the user's presence, but you should also be a bit careful
> that the source URI is not forged.
> 
> Before anyone shrugs off the privacy complaint, consider the spooks'
> practice of locating a suspect's cell-phone. In a few occasion, the
> location was directly followed by a well targeted missile... From that
> point of view, the SMS' "read acknowledge" feature is terrible, and we
> should make sure to not emulate it.
> 
> -- Christian Huitema

From christian.jansson@hotsip.com  Thu Apr 18 11:38:29 2002
Received: from hotsip.com ([62.119.82.43])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13694
	for ; Thu, 18 Apr 2002 11:38:27 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Windows messenger
Date: Thu, 18 Apr 2002 17:37:21 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Windows messenger
Thread-Index: AcHlg9qqNNkbJmVSSxeBvo67HoHFVwBagWPg
From: "Christian Jansson" 
To: "Henning Schulzrinne" ,
        , 
Content-Length: 1169
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA13694
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: 

But the Messenger seems to have a big problem with the presence
format. The presentity uri should identify the presentity for 
whom the presence data is being reported, but Messenger instead
sends the address of the receiver of the information!? 

The Messenger also does not have any Event header its NOTIFY
messages, and it sends a NOTIFY without any content to indicate
that it is offline.

/ Christian Jansson
 
> Xiaotao Wu in my lab just ran windump and confirmed that Windows
> Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
> SUBSCRIBE. For the "proof", see the message dumps at
> http://www.cs.columbia.edu/sip/drafts/messenger.txt
> 
> To answer my own question: Messenger embraces and extends XPIDF:
> 
> 
> 
> 
> 

> 
> 
> 

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

From huitema@windows.microsoft.com  Fri Apr 19 11:31:46 2002
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17743
	for ; Fri, 19 Apr 2002 11:31:45 -0400 (EDT)
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 19 Apr 2002 08:30:10 -0700
Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 19 Apr 2002 08:30:44 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 19 Apr 2002 08:30:09 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 19 Apr 2002 08:30:08 -0700
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.3590.0);
	 Fri, 19 Apr 2002 08:27:06 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Statuses and response codes (Was: RE: [Simple] Status summary)
Date: Fri, 19 Apr 2002 08:27:06 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Statuses and response codes (Was: RE: [Simple] Status summary)
Thread-Index: AcHm2ik1tHv71taQR4a5XxY7swhbBAAyp5SgAARUKyA=
From: "Christian Huitema" 
To: , 
Cc: , ,
        , 
X-OriginalArrivalTime: 19 Apr 2002 15:27:06.0869 (UTC) FILETIME=[AA341A50:01C1E7B6]
Content-Length: 1098
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA17743
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: 

> 	- Open: you can expect a 200 for the MESSAGE
> 	- Away: you probably can expect a 2xx
> 	- Closed: you can expect a 4xx, or a 202, but not a 200 for the

We have to be a bit careful with this line of reasoning, and consider
the privacy implications. I would argue that the response to MESSAGE
SHOULD NOT provide an indication on the recipient's online status, or at
least not in the general case. Otherwise, MESSAGE can be used as a
covert channel to assess someone's presence status without going through
the authorization mechanism built in subscriptions. Indeed, it may be OK
to provide such status when the source of the message is an authorized
subscriber to the user's presence, but you should also be a bit careful
that the source URI is not forged.

Before anyone shrugs off the privacy complaint, consider the spooks'
practice of locating a suspect's cell-phone. In a few occasion, the
location was directly followed by a well targeted missile... From that
point of view, the SMS' "read acknowledge" feature is terrible, and we
should make sure to not emulate it.

-- Christian Huitema

From rmyers@nortelnetworks.com  Thu Apr 18 10:26:53 2002
Received: from zrtps0kn.us.nortel.com (zrtps0kn.nortelnetworks.com [47.140.192.55])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13498
	for ; Thu, 18 Apr 2002 10:26:53 -0400 (EDT)
Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25])
	by zrtps0kn.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3IEOAT15027;
	Thu, 18 Apr 2002 10:24:10 -0400 (EDT)
Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 18 Apr 2002 10:24:11 -0400
Message-ID: 
From: "Roberto Myers"
To: Avshalom Houri , impp@iastate.edu,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Windows messenger
Date: Thu, 18 Apr 2002 10:24:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1E6E4.B273F3C0"
Content-Length: 6184
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: 

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_01C1E6E4.B273F3C0
Content-Type: text/plain;
	charset="iso-8859-1"

Please unsuscribe roberto myers from dist. list

-----Original Message-----
From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
Sent: Wednesday, April 17, 2002 12:34 PM
To: impp@iastate.edu; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Windows messenger



I want to clarify the confusion. I have talked with Jonathan Christensen
from MS and the status is this: 

The public .NET passport account uses a combination of SIP and  the MSN
proprietary protocol for IM and presence.  A/V is negotiated with SIP and
media is transported with standard RTP.

If you are talking with a SIP server the client talks SIP (you need to
enable it via Tools/Options/Accounts/Communication Service). 

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com





	Henning Schulzrinne  
Sent by: simple-admin@mailman.dynamicsoft.com 


16/04/2002 23:14 
Please respond to Henning Schulzrinne 


        
        To:        simple@mailman.dynamicsoft.com, impp@iastate.edu 
        cc:         
        Subject:        [Simple] Windows messenger 

       


Xiaotao Wu in my lab just ran windump and confirmed that Windows
Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY, REGISTER,
SUBSCRIBE. For the "proof", see the message dumps at
http://www.cs.columbia.edu/sip/drafts/messenger.txt

To answer my own question: Messenger embraces and extends XPIDF:












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





------_=_NextPart_001_01C1E6E4.B273F3C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Please=20
unsuscribe roberto myers from dist. list



  
-----Original Message-----
From: Avshalom Houri=20
  [mailto:AVSHALOM@il.ibm.com]
Sent: Wednesday, April 17, =
2002 12:34=20
  PM
To: impp@iastate.edu;=20
  simple@mailman.dynamicsoft.com
Subject: Re: [Simple] =
Windows=20
  messenger


I =
want to=20
  clarify the confusion. I have talked with Jonathan Christensen from =
MS and the=20
  status is this: =


The public .NET passport account uses =
a combination=20
  of SIP and  the MSN  proprietary protocol for IM and=20
  presence.  A/V is =
negotiated=20
  with SIP and media is transported with standard RTP.

If you are=20
  talking with a SIP server the client talks SIP (you need to enable it =
via=20
  Tools/Options/Accounts/Communication Service). 

Avshalom Houri
Presence and Instant Messaging =
Architect
Lotus=20
  Sametime, IBM Software =
Group
avshalom@il.ibm.com





  

    
    

      
      Henning Schulzrinne=20
        <hgs@cs.columbia.edu> 
Sent by: simple-admin@mailman.dynamicsoft.com=20
        
16/04/2002 23:14 =

Please respond to Henning =
Schulzrinne=20
        

      		        =

        To: =
   =20
           simple@mailman.dynamicsoft.com, =
impp@iastate.edu=20
        
      =
  cc:  =20
              
 =20
              Subject:       =
 [Simple]=20
        Windows messenger 

   =20
           


Xiaotao Wu in my lab just ran windump and confirmed that=20
  Windows
Messenger Version 4.6(4.6.0077) uses SIP for NOTIFY,=20
  REGISTER,
SUBSCRIBE. For the "proof", see the message dumps=20
  at
http://www.cs.columbia.edu/sip/drafts/messenger.txt

To =
answer my=20
  own question: Messenger embraces and extends=20
  XPIDF:

<presence>
<presentity=20
  uri=3D"sip:xiaotaow@cs.columbia.edu;method=3DSUBSCRIBE" =
/>
<atom=20
  id=3D"1003">
<address =
uri=3D"sip:128.59.19.251:13170;user=3Dip"=20
  priority=3D"0.800000">
<status status=3D"open" =
/>
<msnsubstatus=20
  substatus=3D"online"=20
  =
/>
</address>
</atom>
</presence>
_____=
__________________________________________
simple=20
  mailing=20
  =
list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com=
/mailman/listinfo/simple




------_=_NextPart_001_01C1E6E4.B273F3C0--

From LAM@zurich.ibm.com  Mon Apr 22 09:44:57 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01100
	for ; Mon, 22 Apr 2002 09:44:57 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id PAB113476
	for ; Mon, 22 Apr 2002 15:43:52 +0200
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3MDhqS65138
	for ; Mon, 22 Apr 2002 15:43:52 +0200
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
From: "Lamine Brahimi" 
Date: Mon, 22 Apr 2002 15:43:50 +0200
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.9a |January 7, 2002) at
 22/04/2002 15:43:51
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 488
Subject: [Simple] about SIP
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: 

Dear all,

I'm a student who is developing the presence protocol based on SIP.
I have a general question. As a student, i do not have much information
about SIP situation and actual evolution in the market.
Is the SIP network (SIP proxy servers, registrars etc ...) already
developed, used, under developement ?
I looked for it but it seems to me that, so far, SIP is used only in
research circles and by a few "pioneer" companies.
Thanks for clarifying things for me,
Regards,

Lamine.


From mark.beckmann@sal.siemens.de  Mon Apr 22 11:18:13 2002
Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01339
	for ; Mon, 22 Apr 2002 11:18:12 -0400 (EDT)
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g3MFHAR10729
	for ; Mon, 22 Apr 2002 17:17:10 +0200 (MEST)
Received: from hvrz00da.hvr.siemens.de (hvrz00da.hvr.siemens.de [129.103.192.197])
	by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g3MFH9O21442
	for ; Mon, 22 Apr 2002 17:17:09 +0200 (MEST)
Received: by hvrz00da.hvr.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Mon, 22 Apr 2002 17:17:08 +0200
Message-ID: 
From: BECKMANN MARK 
To: simple@mailman.dynamicsoft.com
Date: Mon, 22 Apr 2002 17:17:07 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 811
Subject: [Simple] Data manipulation
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: 

Hello,

at the last IETF meeting, I had the impression that a solution for data
manipulation based on SOAP is preferred in the SIMPLE WG as it is also
proposed in the components draft. Now, I am not very familiar with the SOAP
protocol and I would like to know what exactly the benefit by using the SOAP
protocol is. From my point of view a presence user agent could basically
manipulate a presentities data by sending a message containing presence data
in a PIDF format. The fact that the data is sent from the presence user
agent to the presence agent would indicate that this is a data manipulation
procedure.

Best regards,

Mark

Mark Beckmann			Siemens AG

ICM MP PO8 SA 82
P.O.Box 100702			phone: +49 (5341) 906 1814
D-38228 Salzgitter   		fax:   +49 (5341) 906 2010

mailto: Mark.Beckmann@siemens.com



From jdrosen@dynamicsoft.com  Thu Apr 25 02:34:54 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11547
	for ; Thu, 25 Apr 2002 02:34:54 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.76])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3P6ZCLC005437;
	Thu, 25 Apr 2002 02:35:12 -0400 (EDT)
Message-ID: <3CC7A34A.7446963F@dynamicsoft.com>
Date: Thu, 25 Apr 2002 02:33:46 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson 
CC: simple@mailman.dynamicsoft.com
References: <20020320221024.31411.qmail@web11604.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1298
Subject: [Simple] Re: Version Info in Watcher Info
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: 

I just noticed this in my massive sip list backlog. It was originally
posted there, but belongs on simple.

The answer is that version does, in fact, belong as part of the top
level watcherinfo element. ID, however, serves the purpose to identify a
watcher uniquely, and so belongs as a watcher attribute. This change has
already been made.

For those wondering about the status of the promised updates to the
watcherinfo drafts - I have incorporated all wglc comments. The only
issue is an ongoing debate on other lists about DTD vs. schema....

-Jonathan R.

Sean Olson wrote:
> 
> I was curious why the version/id used for deltas
> is part of the watcher element and not the top level
> watcherinfo element. Is this to allow for simpler
> aggregation?
> 
> /sean
> 
> =====
> Sean Olson 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards(r)
> http://movies.yahoo.com/

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From LAM@zurich.ibm.com  Thu Apr 25 11:20:37 2002
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12971
	for ; Thu, 25 Apr 2002 11:20:36 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA50194
	for ; Thu, 25 Apr 2002 17:19:27 +0200
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3PFJRY35726
	for ; Thu, 25 Apr 2002 17:19:28 +0200
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
From: "Lamine Brahimi" 
Date: Thu, 25 Apr 2002 17:19:27 +0200
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.9a |January 7, 2002) at
 25/04/2002 17:19:27
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 773
Subject: [Simple] Can contact-headers point to URIs that do not support SIP ?
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: 

Dear all,

I have developped a presence service. Now I need to integrate it into
another project.
I would like to put an uri like: "tcp://toto:6700" as the Contact-address
in the Contact-header.
However this uri points to another application that does not use sip.
So i do not want to receive  sip message at this address. The subscribers
to the presentity
use this contact address to run another application we have defined.
My question is will sip messages be routed to this contact-address (I do
not know if this case was taken into account in chapter Locating SIP
server/ Computing list of next hops of rfc2453-bis07) ?
If true, is it possible to specify that this contact address is not a SIP
contact-addres so that  proxies etc .. must skip it ?

Regards,
Lamine.




From jdrosen@dynamicsoft.com  Sun Apr 28 00:58:41 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22647
	for ; Sun, 28 Apr 2002 00:58:41 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g3S4wmLC007722;
	Sun, 28 Apr 2002 00:58:48 -0400 (EDT)
Message-ID: <3CCB8135.89F0A820@dynamicsoft.com>
Date: Sun, 28 Apr 2002 00:57:25 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lamine Brahimi 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Can contact-headers point to URIs that do not support SIP ?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1518
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: 


Lamine Brahimi wrote:
> 
> Dear all,
> 
> I have developped a presence service. Now I need to integrate it into
> another project.
> I would like to put an uri like: "tcp://toto:6700" as the
> Contact-address
> in the Contact-header.
> However this uri points to another application that does not use sip.
> So i do not want to receive  sip message at this address. The
> subscribers
> to the presentity
> use this contact address to run another application we have defined.

I think you may not be talking about the contact header. The contact
header is used to determine where to send SIP NOTIFY requests, thats it.
It must be a SIP URL. You are talking about some kind of address that
would be used to launch another application. Presumably, if A subscribes
to B, A learns this address from the NOTIFY requests sent to it from B,
and then can use that to communicate. If this is what you have in mind,
you are actually talking about a contact address within the PIDF
document in the NOTIFY. This is purposefully extensible and can support
any type of URL.

However, there is no such thing as a tcp URL, as in your example above.
That is most certainly NOT what you want. 

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From Clemens.Schultz@icn.siemens.de  Tue Apr 30 08:47:16 2002
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04710
	for ; Tue, 30 Apr 2002 08:47:15 -0400 (EDT)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA18110
	for ; Tue, 30 Apr 2002 14:45:58 +0200 (MET DST)
Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA18345
	for ; Tue, 30 Apr 2002 14:45:32 +0200 (MET DST)
Received: by MCHH273E with Internet Mail Service (5.5.2653.19)
	id ; Tue, 30 Apr 2002 14:46:05 +0200
Message-ID: <35AF9DD2E324D4119DA00000D11D813E013EDF1A@blns203e.bln.icn.siemens.de>
From: Schultz Clemens 
To: simple@mailman.dynamicsoft.com
Date: Tue, 30 Apr 2002 14:45:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 504
Subject: [Simple] text attributes for IM?
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: 

Dear all,

is it anyhow foreseen to provide data with SIP MESSAGE that reflect attributes for the text (e.g. color, used font etc.)? Do you have any headers in mind, or is it really necessary to have proprietary solution.

Thanks,
Clemens

.................................................................................
Clemens B Schultz
SIEMENS AG			Information and Communication Mobile
ICM N PG U SE D6		Systems Engineering
Fon / Fax: +49 30 386 26780 / 49118
e.mail: clemens.schultz@icn.siemens.de


From petkos@dynamo.cs.columbia.edu  Tue Apr 30 09:38:37 2002
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 JAA04898
	for ; Tue, 30 Apr 2002 09:38:35 -0400 (EDT)
Received: from dynamo.cs.columbia.edu (dynamo.cs.columbia.edu [128.59.16.4])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA27759
	for ; Tue, 30 Apr 2002 09:37:30 -0400 (EDT)
Received: from dynamo.cs.columbia.edu (localhost [127.0.0.1])
	by dynamo.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g3UDbTMI019675
	for ; Tue, 30 Apr 2002 09:37:29 -0400 (EDT)
Received: (from petkos@localhost)
	by dynamo.cs.columbia.edu (8.12.1/8.12.1/Submit) id g3UDbSYI019674
	for simple@mailman.dynamicsoft.com; Tue, 30 Apr 2002 09:37:28 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200204301337.g3UDbSYI019674@dynamo.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Tue, 30 Apr 2002 09:37:28 -0400 (EDT)
X-Mailer: ELM [version 2.5 PL3]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 410
Subject: [Simple] text attributes for IM?
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: 

> is it anyhow foreseen to provide data with SIP MESSAGE that 
> reflect attributes for the text (e.g. color, used font etc.)? 
> Do you have any headers in mind, or is it really necessary 
> to have proprietary solution.

This has nothing to do with SIP. It is purely a content format issue.
You are free to send your favourite rich text format (e.g. html, MS-Word) 
in the payload of SIP MESSAGE.

--
Petri

From bateman@acm.org  Wed May  1 07:39:21 2002
Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11759
	for ; Wed, 1 May 2002 07:39:20 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 172sQp-0005Sy-00; Wed, 01 May 2002 12:37:59 +0100
Received: from modem-3656.zebra.dialup.pol.co.uk ([217.134.254.72] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 172sQo-0007PO-00; Wed, 01 May 2002 12:37:58 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Paul Kyzivat'" ,
        "'Henning G. Schulzrinne'" 
Cc: "'Jonathan Rosenberg'" ,
        "'Robert Sparks'" ,
        , 
Subject: RE: [Simple] notes from the SIMPLE components adhoc at IETF53
Date: Wed, 1 May 2002 12:37:38 +0100
Organization: VisionTech Limited
Message-ID: <002b01c1f104$9cbc16a0$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CAE2F14.A335A079@cisco.com>
Importance: Normal
Content-Length: 1295
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: 

On 06 April 2002 00:11, Paul Kyzivat wrote:
> Callerprefs provide a number of dimensions on which to classify a 
> contact (tuple). These could be mapped directly to status values. Or 
> they could be mapped to some new elements within a tuple. They are a 
> bit more complex than the what is currently defined by 
> urn:ietf:params:cpim-presence:status-type:basic. There are a number of

> preference parameter types (class, duplex, feature, language, media, 
> mobility, methods, priority), and each in turn has an enumerated set 
> of possible values. (There is also a "description" parameter, but it 
> probably should be mapped to , and a q-value that is already 
> represented as the priority attribute of .)

A new draft describing IMPP PIDF has been posted and should show up
shortly. It includes changes from recent IMPP discussions but still
leaves a few issues outstanding.

One question I have with reference to the text above is regarding the
priority attribute of . In the current draft, the priority is
defined in the range 0 to 255. The description above suggests mapping a
q-value to the priority. What range does this have? Do you feel the
priority as currently defined is appropriate or are there any
alternative suggestions?

Best regards,

Adrian.



From pkyzivat@cisco.com  Wed May  1 15:27:17 2002
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 PAA13046
	for ; Wed, 1 May 2002 15:27:17 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g41JPQDA001707;
	Wed, 1 May 2002 15:25:27 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAJ31545;
	Wed, 1 May 2002 15:28:19 -0400 (EDT)
Message-ID: <3CD0410B.7F685627@cisco.com>
Date: Wed, 01 May 2002 15:24:59 -0400
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: bateman@acm.org
CC: "'Henning G. Schulzrinne'" ,
        "'Jonathan Rosenberg'" ,
        "'Robert Sparks'" ,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <002b01c1f104$9cbc16a0$6405010a@ADRIANXP>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2157
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: 


Adrian Bateman wrote:
> 
> On 06 April 2002 00:11, Paul Kyzivat wrote:
> > Callerprefs provide a number of dimensions on which to classify a
> > contact (tuple). These could be mapped directly to status values. Or
> > they could be mapped to some new elements within a tuple. They are a
> > bit more complex than the what is currently defined by
> > urn:ietf:params:cpim-presence:status-type:basic. There are a number of
> 
> > preference parameter types (class, duplex, feature, language, media,
> > mobility, methods, priority), and each in turn has an enumerated set
> > of possible values. (There is also a "description" parameter, but it
> > probably should be mapped to , and a q-value that is already
> > represented as the priority attribute of .)
> 
> A new draft describing IMPP PIDF has been posted and should show up
> shortly. It includes changes from recent IMPP discussions but still
> leaves a few issues outstanding.
> 
> One question I have with reference to the text above is regarding the
> priority attribute of . In the current draft, the priority is
> defined in the range 0 to 255. The description above suggests mapping a
> q-value to the priority. What range does this have? Do you feel the
> priority as currently defined is appropriate or are there any
> alternative suggestions?

Hmm - good question. I had not looked very closely at the schema, and hadn't noticed that the priority range was 0-255. In callerprefs, the q-value is a real number in the
range [0.0-1.0]. The good and the bad of that is that the precision isn't defined, so you potentially have an infinite number of values, but don't know how many will
actually be supported.

Of course it is possible to map between the two ranges, though problems of roundoff may occur.

The mapping would be best if both standards agreed on the same range. The q-value definition is inherited by SIP (from HTTP?) so would be difficult to change. Is it
possible to change this to match in PIDF? If not, maybe something new is needed for the q-value to map to. (But it would be ugly to have two priority values, without a
clear reason for each.)

	Paul

From jdrosen@dynamicsoft.com  Thu May  2 22:00:35 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18019
	for ; Thu, 2 May 2002 22:00:35 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.172])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4320sLC012245
	for ; Thu, 2 May 2002 22:00:55 -0400 (EDT)
Message-ID: <3CD1EEFF.49E6F8F2@dynamicsoft.com>
Date: Thu, 02 May 2002 21:59:27 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; 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
Content-Length: 1658
Subject: [Simple] I-D on IM transport proposal
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: 

Folks,

I have just submitted an I-D that describes in detail the proposal for
the IM session model which I hinted at (or is it hand-waved at) during
IETF 53. The proposal uses the loose route capabilities of SIP to avoid
the problems we had with the original usage of MESSAGE. Until the draft
appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-simple-message-session-00.txt

I sincerely apologize for the delay in getting this out. Part of the
reason is that this intermediary issue is really broader than the IM
session model, and so I also wrote a separate I-D that describes a
proposal on how to address the bigger issue. Until that one appears, you
can pick it up at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt

These are written so as to be decoupled, i.e., the message session
proposal does not use the ideas in the session-policy draft, but it
references it and discusses the issues that motivated it.

I must also, according to the policies of rfc2026, inform the group that
I believe dynamicsoft may have IPR associated with these drafts. Yet,
fear not. It is being made available under our "its free if you don't
bug us" policy, which you can find described at
http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIP-UNIFY.txt.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From huitema@windows.microsoft.com  Mon Apr 29 17:01:52 2002
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 RAA02290
	for ; Mon, 29 Apr 2002 17:01:52 -0400 (EDT)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 29 Apr 2002 14:00:47 -0700
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Apr 2002 14:00:47 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 29 Apr 2002 14:00:47 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 29 Apr 2002 14:00:46 -0700
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.3590.0);
	 Mon, 29 Apr 2002 13:57:00 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] Can contact-headers point to URIs that do not support SIP ?
Date: Mon, 29 Apr 2002 13:56:59 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Can contact-headers point to URIs that do not support SIP ?
thread-index: AcHucVE6PNuBZWX2S6CXYf2E6FSVVgBTsxCw
From: "Christian Huitema" 
To: "Jonathan Rosenberg" ,
        "Lamine Brahimi" 
Cc: 
X-OriginalArrivalTime: 29 Apr 2002 20:57:00.0345 (UTC) FILETIME=[682A5A90:01C1EFC0]
Content-Length: 1046
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA02290
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: 

> > I have developped a presence service. Now I need to integrate it
into
> > another project.
> > I would like to put an uri like: "tcp://toto:6700" as the
> > Contact-address
> > in the Contact-header.
> > However this uri points to another application that does not use
sip.
> > So i do not want to receive  sip message at this address. The
> > subscribers
> > to the presentity
> > use this contact address to run another application we have defined.

> ...

We discussed solutions of this nature in the IMPP group in 2000-2001. In
theory, it would be conceivable to send a subscription request for a
resource "sip:alice@foo", and ask that the notifications be delivered to
"blahh://example.com/bob"; the SIP proxies would be asked to route this
message to the "nearest blahh gateway." However, we never reached
agreement on this. On the contrary, there was a strong demand to use
generic URL, e.g. "im:bob@example.com", and to rely on the routing
process to eventually deliver the message using the adequate transport.

-- Christian Huitema

From wayne.carr@intel.com  Thu May  2 13:04:13 2002
Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16597
	for ; Thu, 2 May 2002 13:04:12 -0400 (EDT)
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.42 2002/04/26 23:25:13 root Exp $) with ESMTP id g42H40K12770
	for ; Thu, 2 May 2002 17:04:00 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.17 2002/04/27 00:24:04 root Exp $) with SMTP id g42H1OW26922
	for ; Thu, 2 May 2002 17:01:24 GMT
Received: from fmsmsx019.fm.intel.com ([132.233.42.130])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050210071808678
 ; Thu, 02 May 2002 10:07:24 -0700
Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 2 May 2002 10:02:53 -0700
Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C251@orsmsx120.jf.intel.com>
From: "Carr, Wayne" 
To: "'Paul Kyzivat'" , bateman@acm.org
Cc: "'Henning G. Schulzrinne'" ,
        "'Jonathan Rosenberg'",
        "'Robert Sparks'" ,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: RE: [Simple] notes from the SIMPLE components adhoc at IETF53
Date: Thu, 2 May 2002 10:02:47 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Length: 3092
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: 

> Hmm - good question. I had not looked very closely at the 
> schema, and hadn't noticed that the priority range was 0-255. 

It's defined as that range in "4.1.5. The  element" ... "The value
of the
   attribute MUST be an integer ranged from 0 to 255."  I put it in the
schema to mirror that.

xml schema datatypes has IEEE floats and doubles and can set ranges.

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Wednesday, May 01, 2002 12:25 PM
> To: bateman@acm.org
> Cc: 'Henning G. Schulzrinne'; 'Jonathan Rosenberg'; 'Robert Sparks';
> simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
> 
> 
> Adrian Bateman wrote:
> > 
> > On 06 April 2002 00:11, Paul Kyzivat wrote:
> > > Callerprefs provide a number of dimensions on which to classify a
> > > contact (tuple). These could be mapped directly to status 
> values. Or
> > > they could be mapped to some new elements within a tuple. 
> They are a
> > > bit more complex than the what is currently defined by
> > > urn:ietf:params:cpim-presence:status-type:basic. There 
> are a number of
> > 
> > > preference parameter types (class, duplex, feature, 
> language, media,
> > > mobility, methods, priority), and each in turn has an 
> enumerated set
> > > of possible values. (There is also a "description" 
> parameter, but it
> > > probably should be mapped to , and a q-value that is already
> > > represented as the priority attribute of .)
> > 
> > A new draft describing IMPP PIDF has been posted and should show up
> > shortly. It includes changes from recent IMPP discussions but still
> > leaves a few issues outstanding.
> > 
> > One question I have with reference to the text above is 
> regarding the
> > priority attribute of . In the current draft, the 
> priority is
> > defined in the range 0 to 255. The description above 
> suggests mapping a
> > q-value to the priority. What range does this have? Do you feel the
> > priority as currently defined is appropriate or are there any
> > alternative suggestions?
> 
> Hmm - good question. I had not looked very closely at the 
> schema, and hadn't noticed that the priority range was 0-255. 
> In callerprefs, the q-value is a real number in the
> range [0.0-1.0]. The good and the bad of that is that the 
> precision isn't defined, so you potentially have an infinite 
> number of values, but don't know how many will
> actually be supported.
> 
> Of course it is possible to map between the two ranges, 
> though problems of roundoff may occur.
> 
> The mapping would be best if both standards agreed on the 
> same range. The q-value definition is inherited by SIP (from 
> HTTP?) so would be difficult to change. Is it
> possible to change this to match in PIDF? If not, maybe 
> something new is needed for the q-value to map to. (But it 
> would be ugly to have two priority values, without a
> clear reason for each.)
> 
> 	Paul
> 
> 
> 
>   [reminder: meta-impp@iastate.edu for non-technical 
> discussions, please]
> 

From huitema@windows.microsoft.com  Fri May  3 13:21:22 2002
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20561
	for ; Fri, 3 May 2002 13:21:22 -0400 (EDT)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 3 May 2002 10:20:15 -0700
Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 03 May 2002 10:20:15 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 3 May 2002 10:20:15 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 3 May 2002 10:20:13 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0);
	 Fri, 3 May 2002 10:16:12 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] I-D on IM transport proposal
Date: Fri, 3 May 2002 10:16:13 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] I-D on IM transport proposal
thread-index: AcHyRk4pGPWzGU5STT+VKoVT/k+ZQAAf3dKw
From: "Christian Huitema" 
To: "Jonathan Rosenberg" ,
        
X-OriginalArrivalTime: 03 May 2002 17:16:12.0470 (UTC) FILETIME=[39780D60:01C1F2C6]
Content-Length: 3423
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA20561
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: 

Jonathan,

In the message-session draft, you state that:

   The INVITE is processed normally by proxies. However, some proxy on
   the path might decide that the messaging stream needs to pass through
   an intermediary. To do that, it modifies the SDP, adding a "hop"
   attribute, containing a SIP URI for the hop. This URI need not be the
   URI of the proxy at all, but MUST always have a transport of TCP.

You explain further that this is indeed a violation of the general SIP
requirement, which state that proxies should leave the SIP payload
alone. Indeed, we are trying to move towards S-MIME security, which
would prevent such mangling.

I believe that the hop concept is fine, but that we must find a model in
which the "hop" requirement is inserted by the end system (UA), not the
proxy. We have to look at the main scenario that might require this hop
concept -- use of a different infrastructure for message sessions and
generic signaling. And we have to provide ways for the host to discover
that they should use this infrastructure: either configuration, or
dynamic discovery. For example, if the host sends too many messages
through the "signaling only" proxy, the proxy could send an error
response, indicating congestion and possibly suggesting an alternate
path.

-- Christian Huitema

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, May 02, 2002 6:59 PM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] I-D on IM transport proposal
> 
> Folks,
> 
> I have just submitted an I-D that describes in detail the proposal for
> the IM session model which I hinted at (or is it hand-waved at) during
> IETF 53. The proposal uses the loose route capabilities of SIP to
avoid
> the problems we had with the original usage of MESSAGE. Until the
draft
> appears in the archives, you can pick up a copy at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-simple-message-session-
> 00.txt
> 
> I sincerely apologize for the delay in getting this out. Part of the
> reason is that this intermediary issue is really broader than the IM
> session model, and so I also wrote a separate I-D that describes a
> proposal on how to address the bigger issue. Until that one appears,
you
> can pick it up at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-
> 00.txt
> 
> These are written so as to be decoupled, i.e., the message session
> proposal does not use the ideas in the session-policy draft, but it
> references it and discusses the issues that motivated it.
> 
> I must also, according to the policies of rfc2026, inform the group
that
> I believe dynamicsoft may have IPR associated with these drafts. Yet,
> fear not. It is being made available under our "its free if you don't
> bug us" policy, which you can find described at
> http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIP-UNIFY.txt.
> 
> Thanks,
> Jonathan R.
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From nsyracus@cnri.reston.va.us  Mon May  6 07:26:48 2002
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 HAA00735
	for ; Mon, 6 May 2002 07:26:47 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12911;
	Mon, 6 May 2002 07:25:33 -0400 (EDT)
Message-Id: <200205061125.HAA12911@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
Date: Mon, 06 May 2002 07:25:33 -0400
Content-Length: 2976
Subject: [Simple] I-D ACTION:draft-rosenberg-simple-message-session-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Using MESSAGE for IM Sessions
	Author(s)	: J. Rosenberg
	Filename	: draft-rosenberg-simple-message-session-00.txt
	Pages		: 11
	Date		: 03-May-02
	
The SIMPLE working group has been debating the issue of the IM
session model for quite some time. The primary issue is what
transport to use for the IMs once the session is established with
SIP. Proposals have included the SIP MESSAGE request itself, IMSX,
and a SIP spin-off, called IMTP. The usage of SIP MESSAGE, the very
first proposal, had been rejected by the group because of several
technical issues. This document revists that decision, based on the
recent enhancements made to SIP itself. We believe that SIP MESSAGE
now represents the ideal transport choice for the IM session model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-session-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-rosenberg-simple-message-session-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-rosenberg-simple-message-session-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:	<20020503122004.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-rosenberg-simple-message-session-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rosenberg-simple-message-session-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020503122004.I-D@ietf.org>

--OtherAccess--

--NextPart--



From pkyzivat@cisco.com  Mon May  6 11:15:03 2002
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 LAA01366
	for ; Mon, 6 May 2002 11:15:03 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g46FDgiw018207;
	Mon, 6 May 2002 11:13:43 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAJ50952;
	Mon, 6 May 2002 11:16:36 -0400 (EDT)
Message-ID: <3CD69D8C.854FEEF4@cisco.com>
Date: Mon, 06 May 2002 11:13:16 -0400
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: "Carr, Wayne" 
CC: bateman@acm.org, "'Henning G. Schulzrinne'" ,
        "'Jonathan Rosenberg'" ,
        "'Robert Sparks'" ,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <86DB568235A8D511ABAC0002A5072CA50316C251@orsmsx120.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3618
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: 

Wayne - Is it possible to consider changing priority to be a float in range [0.0-1.0], for consistency with the sip specification? (Or is there something else this also
needs to be consistent with?)

	Paul

"Carr, Wayne" wrote:
> 
> > Hmm - good question. I had not looked very closely at the
> > schema, and hadn't noticed that the priority range was 0-255.
> 
> It's defined as that range in "4.1.5. The  element" ... "The value
> of the
>    attribute MUST be an integer ranged from 0 to 255."  I put it in the
> schema to mirror that.
> 
> xml schema datatypes has IEEE floats and doubles and can set ranges.



> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Wednesday, May 01, 2002 12:25 PM
> > To: bateman@acm.org
> > Cc: 'Henning G. Schulzrinne'; 'Jonathan Rosenberg'; 'Robert Sparks';
> > simple@mailman.dynamicsoft.com; impp@iastate.edu
> > Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
> >
> >
> > Adrian Bateman wrote:
> > >
> > > On 06 April 2002 00:11, Paul Kyzivat wrote:
> > > > Callerprefs provide a number of dimensions on which to classify a
> > > > contact (tuple). These could be mapped directly to status
> > values. Or
> > > > they could be mapped to some new elements within a tuple.
> > They are a
> > > > bit more complex than the what is currently defined by
> > > > urn:ietf:params:cpim-presence:status-type:basic. There
> > are a number of
> > >
> > > > preference parameter types (class, duplex, feature,
> > language, media,
> > > > mobility, methods, priority), and each in turn has an
> > enumerated set
> > > > of possible values. (There is also a "description"
> > parameter, but it
> > > > probably should be mapped to , and a q-value that is already
> > > > represented as the priority attribute of .)
> > >
> > > A new draft describing IMPP PIDF has been posted and should show up
> > > shortly. It includes changes from recent IMPP discussions but still
> > > leaves a few issues outstanding.
> > >
> > > One question I have with reference to the text above is
> > regarding the
> > > priority attribute of . In the current draft, the
> > priority is
> > > defined in the range 0 to 255. The description above
> > suggests mapping a
> > > q-value to the priority. What range does this have? Do you feel the
> > > priority as currently defined is appropriate or are there any
> > > alternative suggestions?
> >
> > Hmm - good question. I had not looked very closely at the
> > schema, and hadn't noticed that the priority range was 0-255.
> > In callerprefs, the q-value is a real number in the
> > range [0.0-1.0]. The good and the bad of that is that the
> > precision isn't defined, so you potentially have an infinite
> > number of values, but don't know how many will
> > actually be supported.
> >
> > Of course it is possible to map between the two ranges,
> > though problems of roundoff may occur.
> >
> > The mapping would be best if both standards agreed on the
> > same range. The q-value definition is inherited by SIP (from
> > HTTP?) so would be difficult to change. Is it
> > possible to change this to match in PIDF? If not, maybe
> > something new is needed for the q-value to map to. (But it
> > would be ugly to have two priority values, without a
> > clear reason for each.)
> >
> >       Paul
> >
> >
> >
> >   [reminder: meta-impp@iastate.edu for non-technical
> > discussions, please]
> >
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From Tim.Moran@nokia.com  Mon May  6 11:43:34 2002
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01470
	for ; Mon, 6 May 2002 11:43:33 -0400 (EDT)
From: Tim.Moran@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g46FgkS28363
	for ; Mon, 6 May 2002 10:42:47 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 6 May 2002 08:42:24 -0500
Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 6 May 2002 10:41:12 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 6 May 2002 10:41:11 -0500
Message-ID: <278B6B0D76698D45BBA872CD23DD496A0A4332@daebe004.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sipping] I-D ACTION:draft-moran-sipping-filter-arch-00.txt
Thread-Index: AcH1FHJ4KkD8yjQIRZqoKCDU2dKIIg==
To: , 
X-OriginalArrivalTime: 06 May 2002 15:41:12.0143 (UTC) FILETIME=[730C6DF0:01C1F514]
Content-Length: 1062
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA01470
Subject: [Simple] [Sipping] I-D ACTION:draft-moran-sipping-filter-arch-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: 

Greetings,

We are looking for comments on this draft (see link below). Some topics for discussion are:
*	does this contain an adequate set of operators and constructs (what's not needed, what's missing)
*	is extendibility addressed well enough
*	what language should be used for implementation
*	and the ever famous scalability question

Thank you,

Tim & Sreeni


A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Architecture for Event Notification Filters
	Author(s)	: T. Moran, S. Addagatla
	Filename	: draft-moran-sipping-filter-arch-00.txt
	Pages		: 17
	Date		: 30-Apr-02
	
This document defines an extendible architecture whereby an event 
subscriber (client) may specify the rules for SIP event notification 
from the notifier (server). Potential solutions meeting the 
architecture specification are also provided in the annexes.  
Requirements for event filtering were previously described in [1].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-moran-sipping-filter-arch-00.txt


From adam@dynamicsoft.com  Mon May  6 20:03:13 2002
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 UAA02893;
	Mon, 6 May 2002 20:03:13 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g46Nx0u2007767;
	Mon, 6 May 2002 19:59:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 6 May 2002 20:01:31 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F3F8@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: Avshalom Houri , Tom Karlo 
Cc: Henning Schulzrinne , impp@iastate.edu,
        simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com,
        Peter Saint-Andre , Tony Hansen 
Subject: RE: [Simple] Status summary
Date: Mon, 6 May 2002 20:01:29 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Content-Length: 3332
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id UAA02893
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: 

I've been using XP Messenger with my own SIP-based IM client
for some time now. As I'm currently on an airplane (and without
a network), I can't include a packet trace. If you really want
me to ferret one out, let me know and I'll send you one.

/a

-----Original Message-----
From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com]
Sent: Tuesday, April 16, 2002 14:03
To: Tom Karlo
Cc: Henning Schulzrinne; impp@iastate.edu; simple@mailman.dynamicsoft.com;
simple-admin@mailman.dynamicsoft.com; Peter Saint-Andre; Tony Hansen
Subject: RE: [Simple] Status summary



What is sip based in the XP Windows messenger is in the VOIP part. The PIM
part is still using the MSN protocol (VER 119) as can be seen if you look at
the packets it sends. 

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com




Tom  Karlo  
Sent by: simple-admin@mailman.dynamicsoft.com 
16/04/2002 16:23 
Please respond to Tom  Karlo 
        
        To:        Avshalom Houri/Haifa/IBM@IBMIL, Henning Schulzrinne
 
        cc:        impp@iastate.edu, simple@mailman.dynamicsoft.com, Peter
Saint-Andre , Tony Hansen  
        Subject:        RE: [Simple] Status summary 

       


Actually, the latest Windows Messenger has been SIP-based for a while now (6
months?) My company is one of the carriers providing support. You might have
to check the XP messenger, although I do believe 4.6 would be the right one.
If you get the version where when making a phone call, you’re given a list
of services to choose from, then that’s the SIP one. The old one only
allowed you to use the Net2Phone protocol. 
 
Tom Karlo 
Net2Phone 
 
-----Original Message-----
From: Avshalom Houri [mailto:AVSHALOM@il.ibm.com] 
Sent: Tuesday, April 16, 2002 6:39 AM
To: Henning Schulzrinne
Cc: impp@iastate.edu; simple@mailman.dynamicsoft.com; Peter Saint-Andre;
Tony Hansen
Subject: Re: [Simple] Status summary 
 

I was checking the Windows messenger version 4.6. As far as I know: 
       * This version is based on the MSN protocol and not SIP. 
       * The SIP client is not publically available yet. 

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group
avshalom@il.ibm.com



  Henning Schulzrinne  
16/04/2002 00:26 
Please respond to Henning Schulzrinne         
       To:        Peter Saint-Andre  
       cc:        Tony Hansen ,
simple@mailman.dynamicsoft.com, impp@iastate.edu, Avshalom
Houri/Haifa/IBM@IBMIL 
       Subject:        Re: [Simple] Status summary 

      



I'm curious: Windows Messenger, supposedly using SIP and IMPP presence,
has a bunch of status indications, similar to the ones mentioned on the
list (lunch, do not disturb, etc.). How are they encoded?

Peter Saint-Andre wrote:
> 
> FWIW, we provide the following statuses (stati?) in Jabber:
> 
> 1. Unavailable (maps to CLOSED)
> 
> 2. Available (maps to OPEN) with sub-statuses:
>    - away
>    - extended away
>    - do not disturb
>    - free/desiring to chat
> 
> 3. Invisible
> 
> Any status can be extended with a natural-language description of the
> status.
> 
> More information at
> http://www.jabber.org/ietf/draft-miller-jabber-00.html#common-presence

From wayne.carr@intel.com  Mon May  6 20:23:04 2002
Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02984
	for ; Mon, 6 May 2002 20:23:04 -0400 (EDT)
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.45 2002/05/03 22:11:31 root Exp $) with ESMTP id g470KvH17671
	for ; Tue, 7 May 2002 00:20:57 GMT
Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110])
	by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.18 2002/05/02 20:17:19 root Exp $) with SMTP id g470JAt19721
	for ; Tue, 7 May 2002 00:19:10 GMT
Received: from FMSMSX017.fm.intel.com ([132.233.42.196])
 by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050617252008315
 ; Mon, 06 May 2002 17:25:20 -0700
Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 6 May 2002 17:20:52 -0700
Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C266@orsmsx120.jf.intel.com>
From: "Carr, Wayne" 
To: "'Paul Kyzivat'" ,
        "Carr, Wayne" 
Cc: bateman@acm.org, "'Henning G. Schulzrinne'" ,
        "'Jonathan Rosenberg'" ,
        "'Robert Sparks'",
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: RE: [Simple] notes from the SIMPLE components adhoc at IETF53
Date: Mon, 6 May 2002 17:20:44 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5027
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: 

> Wayne - Is it possible to consider changing priority to be a 
> float in range [0.0-1.0], for consistency with the sip 
> specification? (Or is there something else this also
> needs to be consistent with?)

The group was looking to see if the range needed to be changed for 'simple'.
I don't know if there are constraints that it be integer.  The q values
proposed in SIP are the same as in HTTP, restricted to at most 3 decimal
fractional digits (just decimal, not float notation with 'e').  Here's that
type defined in XML Schema.

  
    
      
    
  

Another option if the impp presence value needed to be an integer, would be
a range that's mappable easily to qvalue like [0..1000]



> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, May 06, 2002 8:13 AM
> To: Carr, Wayne
> Cc: bateman@acm.org; 'Henning G. Schulzrinne'; 'Jonathan Rosenberg';
> 'Robert Sparks'; simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
> 
> 
> Wayne - Is it possible to consider changing priority to be a 
> float in range [0.0-1.0], for consistency with the sip 
> specification? (Or is there something else this also
> needs to be consistent with?)
> 
> 	Paul
> 
> "Carr, Wayne" wrote:
> > 
> > > Hmm - good question. I had not looked very closely at the
> > > schema, and hadn't noticed that the priority range was 0-255.
> > 
> > It's defined as that range in "4.1.5. The  
> element" ... "The value
> > of the
> >    attribute MUST be an integer ranged from 0 to 255."  I 
> put it in the
> > schema to mirror that.
> > 
> > xml schema datatypes has IEEE floats and doubles and can set ranges.
> 
> 
> 
> > 
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > Sent: Wednesday, May 01, 2002 12:25 PM
> > > To: bateman@acm.org
> > > Cc: 'Henning G. Schulzrinne'; 'Jonathan Rosenberg'; 
> 'Robert Sparks';
> > > simple@mailman.dynamicsoft.com; impp@iastate.edu
> > > Subject: Re: [Simple] notes from the SIMPLE components 
> adhoc at IETF53
> > >
> > >
> > > Adrian Bateman wrote:
> > > >
> > > > On 06 April 2002 00:11, Paul Kyzivat wrote:
> > > > > Callerprefs provide a number of dimensions on which 
> to classify a
> > > > > contact (tuple). These could be mapped directly to status
> > > values. Or
> > > > > they could be mapped to some new elements within a tuple.
> > > They are a
> > > > > bit more complex than the what is currently defined by
> > > > > urn:ietf:params:cpim-presence:status-type:basic. There
> > > are a number of
> > > >
> > > > > preference parameter types (class, duplex, feature,
> > > language, media,
> > > > > mobility, methods, priority), and each in turn has an
> > > enumerated set
> > > > > of possible values. (There is also a "description"
> > > parameter, but it
> > > > > probably should be mapped to , and a q-value 
> that is already
> > > > > represented as the priority attribute of .)
> > > >
> > > > A new draft describing IMPP PIDF has been posted and 
> should show up
> > > > shortly. It includes changes from recent IMPP 
> discussions but still
> > > > leaves a few issues outstanding.
> > > >
> > > > One question I have with reference to the text above is
> > > regarding the
> > > > priority attribute of . In the current draft, the
> > > priority is
> > > > defined in the range 0 to 255. The description above
> > > suggests mapping a
> > > > q-value to the priority. What range does this have? Do 
> you feel the
> > > > priority as currently defined is appropriate or are there any
> > > > alternative suggestions?
> > >
> > > Hmm - good question. I had not looked very closely at the
> > > schema, and hadn't noticed that the priority range was 0-255.
> > > In callerprefs, the q-value is a real number in the
> > > range [0.0-1.0]. The good and the bad of that is that the
> > > precision isn't defined, so you potentially have an infinite
> > > number of values, but don't know how many will
> > > actually be supported.
> > >
> > > Of course it is possible to map between the two ranges,
> > > though problems of roundoff may occur.
> > >
> > > The mapping would be best if both standards agreed on the
> > > same range. The q-value definition is inherited by SIP (from
> > > HTTP?) so would be difficult to change. Is it
> > > possible to change this to match in PIDF? If not, maybe
> > > something new is needed for the q-value to map to. (But it
> > > would be ugly to have two priority values, without a
> > > clear reason for each.)
> > >
> > >       Paul
> > >
> > >
> > >
> > >   [reminder: meta-impp@iastate.edu for non-technical
> > > discussions, please]
> > >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From pkyzivat@cisco.com  Tue May  7 09:03:48 2002
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 JAA05008
	for ; Tue, 7 May 2002 09:03:47 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g47D1op9008775;
	Tue, 7 May 2002 09:01:50 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAJ56112;
	Tue, 7 May 2002 09:04:43 -0400 (EDT)
Message-ID: <3CD7D023.227E3A10@cisco.com>
Date: Tue, 07 May 2002 09:01:23 -0400
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: "Carr, Wayne" 
CC: bateman@acm.org, "'Henning G. Schulzrinne'" ,
        "'Jonathan Rosenberg'" ,
        "'Robert Sparks'" ,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
References: <86DB568235A8D511ABAC0002A5072CA50316C266@orsmsx120.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5624
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: 

Wayne,

I think what you seem to be suggesting below would work for me. But while I am pretty much illiterate in XML, "(0|1)(\.[0-9]{0,3})?" looks to me like it describes values in
range [0.000,1.999]. I would think something like "0|((0)?(\.[0-9]{0,3}))|(1(\.(0){0,3})?)" is needed to express the intent accurately.

	Paul

"Carr, Wayne" wrote:
> 
> > Wayne - Is it possible to consider changing priority to be a
> > float in range [0.0-1.0], for consistency with the sip
> > specification? (Or is there something else this also
> > needs to be consistent with?)
> 
> The group was looking to see if the range needed to be changed for 'simple'.
> I don't know if there are constraints that it be integer.  The q values
> proposed in SIP are the same as in HTTP, restricted to at most 3 decimal
> fractional digits (just decimal, not float notation with 'e').  Here's that
> type defined in XML Schema.
> 
>   
>     
>       
>     
>   
> 
> Another option if the impp presence value needed to be an integer, would be
> a range that's mappable easily to qvalue like [0..1000]
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Monday, May 06, 2002 8:13 AM
> > To: Carr, Wayne
> > Cc: bateman@acm.org; 'Henning G. Schulzrinne'; 'Jonathan Rosenberg';
> > 'Robert Sparks'; simple@mailman.dynamicsoft.com; impp@iastate.edu
> > Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
> >
> >
> > Wayne - Is it possible to consider changing priority to be a
> > float in range [0.0-1.0], for consistency with the sip
> > specification? (Or is there something else this also
> > needs to be consistent with?)
> >
> >       Paul
> >
> > "Carr, Wayne" wrote:
> > >
> > > > Hmm - good question. I had not looked very closely at the
> > > > schema, and hadn't noticed that the priority range was 0-255.
> > >
> > > It's defined as that range in "4.1.5. The 
> > element" ... "The value
> > > of the
> > >    attribute MUST be an integer ranged from 0 to 255."  I
> > put it in the
> > > schema to mirror that.
> > >
> > > xml schema datatypes has IEEE floats and doubles and can set ranges.
> >
> >
> >
> > >
> > > > -----Original Message-----
> > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > > Sent: Wednesday, May 01, 2002 12:25 PM
> > > > To: bateman@acm.org
> > > > Cc: 'Henning G. Schulzrinne'; 'Jonathan Rosenberg';
> > 'Robert Sparks';
> > > > simple@mailman.dynamicsoft.com; impp@iastate.edu
> > > > Subject: Re: [Simple] notes from the SIMPLE components
> > adhoc at IETF53
> > > >
> > > >
> > > > Adrian Bateman wrote:
> > > > >
> > > > > On 06 April 2002 00:11, Paul Kyzivat wrote:
> > > > > > Callerprefs provide a number of dimensions on which
> > to classify a
> > > > > > contact (tuple). These could be mapped directly to status
> > > > values. Or
> > > > > > they could be mapped to some new elements within a tuple.
> > > > They are a
> > > > > > bit more complex than the what is currently defined by
> > > > > > urn:ietf:params:cpim-presence:status-type:basic. There
> > > > are a number of
> > > > >
> > > > > > preference parameter types (class, duplex, feature,
> > > > language, media,
> > > > > > mobility, methods, priority), and each in turn has an
> > > > enumerated set
> > > > > > of possible values. (There is also a "description"
> > > > parameter, but it
> > > > > > probably should be mapped to , and a q-value
> > that is already
> > > > > > represented as the priority attribute of .)
> > > > >
> > > > > A new draft describing IMPP PIDF has been posted and
> > should show up
> > > > > shortly. It includes changes from recent IMPP
> > discussions but still
> > > > > leaves a few issues outstanding.
> > > > >
> > > > > One question I have with reference to the text above is
> > > > regarding the
> > > > > priority attribute of . In the current draft, the
> > > > priority is
> > > > > defined in the range 0 to 255. The description above
> > > > suggests mapping a
> > > > > q-value to the priority. What range does this have? Do
> > you feel the
> > > > > priority as currently defined is appropriate or are there any
> > > > > alternative suggestions?
> > > >
> > > > Hmm - good question. I had not looked very closely at the
> > > > schema, and hadn't noticed that the priority range was 0-255.
> > > > In callerprefs, the q-value is a real number in the
> > > > range [0.0-1.0]. The good and the bad of that is that the
> > > > precision isn't defined, so you potentially have an infinite
> > > > number of values, but don't know how many will
> > > > actually be supported.
> > > >
> > > > Of course it is possible to map between the two ranges,
> > > > though problems of roundoff may occur.
> > > >
> > > > The mapping would be best if both standards agreed on the
> > > > same range. The q-value definition is inherited by SIP (from
> > > > HTTP?) so would be difficult to change. Is it
> > > > possible to change this to match in PIDF? If not, maybe
> > > > something new is needed for the q-value to map to. (But it
> > > > would be ugly to have two priority values, without a
> > > > clear reason for each.)
> > > >
> > > >       Paul
> > > >
> > > >
> > > >
> > > >   [reminder: meta-impp@iastate.edu for non-technical
> > > > discussions, please]
> > > >
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >

From bateman@acm.org  Tue May  7 13:32:48 2002
Received: from mail7.svr.pol.co.uk (mail7.svr.pol.co.uk [195.92.193.21])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05852
	for ; Tue, 7 May 2002 13:32:48 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by mail7.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 1758o7-0008Ml-00; Tue, 07 May 2002 18:31:23 +0100
Received: from modem-3511.snake.dialup.pol.co.uk ([62.137.125.183] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 1758o6-0002Br-00; Tue, 07 May 2002 18:31:23 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Carr, Wayne'" ,
        "'Paul Kyzivat'" 
Cc: , 
Subject: RE: [Simple] notes from the SIMPLE components adhoc at IETF53
Date: Tue, 7 May 2002 18:31:04 +0100
Organization: VisionTech Limited
Message-ID: <000801c1f5ec$fa6a6c10$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <86DB568235A8D511ABAC0002A5072CA50316C266@orsmsx120.jf.intel.com>
Content-Length: 1076
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: 

On 07 May 2002 01:20, Carr, Wayne wrote:
> > Wayne - Is it possible to consider changing priority to be a float 
> > in range [0.0-1.0], for consistency with the sip specification? (Or 
> > is there something else this also needs to be consistent with?)
> 
> The group was looking to see if the range needed to be changed for 
> 'simple'. I don't know if there are constraints that it be integer.  
> The q values proposed in SIP are the same as in HTTP, restricted to at

> most 3 decimal fractional digits (just decimal, not float notation 
> with 'e').  Here's that type defined in XML Schema.
> 
>   
>     
>       
>     
>   
> 
> Another option if the impp presence value needed to be an integer, 
> would be a range that's mappable easily to qvalue like [0..1000]

My preference would be toward the integer value (I'm just happier
dealing with integers) but I don't have any substantial objections to
the alternative.

Adrian.



From pkyzivat@cisco.com  Tue May  7 14:45:56 2002
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 OAA06078
	for ; Tue, 7 May 2002 14:45:56 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g47IjBDd011418;
	Tue, 7 May 2002 14:45:11 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAJ59228;
	Tue, 7 May 2002 14:48:04 -0400 (EDT)
Message-ID: <3CD8209C.1DF74246@cisco.com>
Date: Tue, 07 May 2002 14:44:44 -0400
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: bateman@acm.org
CC: "'Carr, Wayne'" , simple@mailman.dynamicsoft.com,
        impp@iastate.edu
References: <000801c1f5ec$fa6a6c10$6405010a@ADRIANXP>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 351
Subject: [Simple] Re: priority range in PIDF
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: 

Adrian Bateman wrote:
> 
> My preference would be toward the integer value (I'm just happier
> dealing with integers) but I don't have any substantial objections to
> the alternative.

Just to be contrarian, I would prefer the decimal form for consistency with sip & http, but don't have an substantial objection to integers in range [0,1000].

	Paul

From wayne.carr@intel.com  Tue May  7 15:21:41 2002
Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06202
	for ; Tue, 7 May 2002 15:21:41 -0400 (EDT)
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.45 2002/05/03 22:11:31 root Exp $) with ESMTP id g47JLML01618
	for ; Tue, 7 May 2002 19:21:22 GMT
Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128])
	by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.18 2002/05/02 20:17:19 root Exp $) with SMTP id g47JIhi14258
	for ; Tue, 7 May 2002 19:18:48 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050712192913779
 ; Tue, 07 May 2002 12:19:30 -0700
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 7 May 2002 12:20:26 -0700
Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C26B@orsmsx120.jf.intel.com>
From: "Carr, Wayne" 
To: "'Paul Kyzivat'" ,
        "Carr, Wayne" 
Cc: bateman@acm.org, "'Henning G. Schulzrinne'" ,
        "'Jonathan Rosenberg'" ,
        "'Robert Sparks'",
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: RE: [Simple] notes from the SIMPLE components adhoc at IETF53
Date: Tue, 7 May 2002 12:20:22 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 7107
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: 

I had overspecified by including both minInclusive="0" and maxInclusive="1"
and then accidentally deleted both instead of just minInclusive and didn't
retest it. What I should have written was: 

  
    
      
      
    
  

Here's another way of specifying it that more directly mirrors
http://search.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-09.txt
(that's what I'm assuming this definition for SIP is coming from):

  
    
      
      
    
  

 



> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, May 07, 2002 6:01 AM
> To: Carr, Wayne
> Cc: bateman@acm.org; 'Henning G. Schulzrinne'; 'Jonathan Rosenberg';
> 'Robert Sparks'; simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: Re: [Simple] notes from the SIMPLE components adhoc at IETF53
> 
> 
> Wayne,
> 
> I think what you seem to be suggesting below would work for 
> me. But while I am pretty much illiterate in XML, 
> "(0|1)(\.[0-9]{0,3})?" looks to me like it describes values in
> range [0.000,1.999]. I would think something like 
> "0|((0)?(\.[0-9]{0,3}))|(1(\.(0){0,3})?)" is needed to 
> express the intent accurately.
> 
> 	Paul
> 
> "Carr, Wayne" wrote:
> > 
> > > Wayne - Is it possible to consider changing priority to be a
> > > float in range [0.0-1.0], for consistency with the sip
> > > specification? (Or is there something else this also
> > > needs to be consistent with?)
> > 
> > The group was looking to see if the range needed to be 
> changed for 'simple'.
> > I don't know if there are constraints that it be integer.  
> The q values
> > proposed in SIP are the same as in HTTP, restricted to at 
> most 3 decimal
> > fractional digits (just decimal, not float notation with 
> 'e').  Here's that
> > type defined in XML Schema.
> > 
> >   
> >     
> >       
> >     
> >   
> > 
> > Another option if the impp presence value needed to be an 
> integer, would be
> > a range that's mappable easily to qvalue like [0..1000]
> > 
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > Sent: Monday, May 06, 2002 8:13 AM
> > > To: Carr, Wayne
> > > Cc: bateman@acm.org; 'Henning G. Schulzrinne'; 'Jonathan 
> Rosenberg';
> > > 'Robert Sparks'; simple@mailman.dynamicsoft.com; impp@iastate.edu
> > > Subject: Re: [Simple] notes from the SIMPLE components 
> adhoc at IETF53
> > >
> > >
> > > Wayne - Is it possible to consider changing priority to be a
> > > float in range [0.0-1.0], for consistency with the sip
> > > specification? (Or is there something else this also
> > > needs to be consistent with?)
> > >
> > >       Paul
> > >
> > > "Carr, Wayne" wrote:
> > > >
> > > > > Hmm - good question. I had not looked very closely at the
> > > > > schema, and hadn't noticed that the priority range was 0-255.
> > > >
> > > > It's defined as that range in "4.1.5. The 
> > > element" ... "The value
> > > > of the
> > > >    attribute MUST be an integer ranged from 0 to 255."  I
> > > put it in the
> > > > schema to mirror that.
> > > >
> > > > xml schema datatypes has IEEE floats and doubles and 
> can set ranges.
> > >
> > >
> > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > > > Sent: Wednesday, May 01, 2002 12:25 PM
> > > > > To: bateman@acm.org
> > > > > Cc: 'Henning G. Schulzrinne'; 'Jonathan Rosenberg';
> > > 'Robert Sparks';
> > > > > simple@mailman.dynamicsoft.com; impp@iastate.edu
> > > > > Subject: Re: [Simple] notes from the SIMPLE components
> > > adhoc at IETF53
> > > > >
> > > > >
> > > > > Adrian Bateman wrote:
> > > > > >
> > > > > > On 06 April 2002 00:11, Paul Kyzivat wrote:
> > > > > > > Callerprefs provide a number of dimensions on which
> > > to classify a
> > > > > > > contact (tuple). These could be mapped directly to status
> > > > > values. Or
> > > > > > > they could be mapped to some new elements within a tuple.
> > > > > They are a
> > > > > > > bit more complex than the what is currently defined by
> > > > > > > urn:ietf:params:cpim-presence:status-type:basic. There
> > > > > are a number of
> > > > > >
> > > > > > > preference parameter types (class, duplex, feature,
> > > > > language, media,
> > > > > > > mobility, methods, priority), and each in turn has an
> > > > > enumerated set
> > > > > > > of possible values. (There is also a "description"
> > > > > parameter, but it
> > > > > > > probably should be mapped to , and a q-value
> > > that is already
> > > > > > > represented as the priority attribute of .)
> > > > > >
> > > > > > A new draft describing IMPP PIDF has been posted and
> > > should show up
> > > > > > shortly. It includes changes from recent IMPP
> > > discussions but still
> > > > > > leaves a few issues outstanding.
> > > > > >
> > > > > > One question I have with reference to the text above is
> > > > > regarding the
> > > > > > priority attribute of . In the current draft, the
> > > > > priority is
> > > > > > defined in the range 0 to 255. The description above
> > > > > suggests mapping a
> > > > > > q-value to the priority. What range does this have? Do
> > > you feel the
> > > > > > priority as currently defined is appropriate or are 
> there any
> > > > > > alternative suggestions?
> > > > >
> > > > > Hmm - good question. I had not looked very closely at the
> > > > > schema, and hadn't noticed that the priority range was 0-255.
> > > > > In callerprefs, the q-value is a real number in the
> > > > > range [0.0-1.0]. The good and the bad of that is that the
> > > > > precision isn't defined, so you potentially have an infinite
> > > > > number of values, but don't know how many will
> > > > > actually be supported.
> > > > >
> > > > > Of course it is possible to map between the two ranges,
> > > > > though problems of roundoff may occur.
> > > > >
> > > > > The mapping would be best if both standards agreed on the
> > > > > same range. The q-value definition is inherited by SIP (from
> > > > > HTTP?) so would be difficult to change. Is it
> > > > > possible to change this to match in PIDF? If not, maybe
> > > > > something new is needed for the q-value to map to. (But it
> > > > > would be ugly to have two priority values, without a
> > > > > clear reason for each.)
> > > > >
> > > > >       Paul
> > > > >
> > > > >
> > > > >
> > > > >   [reminder: meta-impp@iastate.edu for non-technical
> > > > > discussions, please]
> > > > >
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > >
> 

From nsyracus@cnri.reston.va.us  Wed May  8 07:30:01 2002
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 HAA08804
	for ; Wed, 8 May 2002 07:30:01 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01082;
	Wed, 8 May 2002 07:28:47 -0400 (EDT)
Message-Id: <200205081128.HAA01082@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 08 May 2002 07:28:46 -0400
Content-Length: 3309
Subject: [Simple] I-D ACTION:draft-ietf-sip-message-04.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-sip-message-04.txt
	Pages		: 20
	Date		: 07-May-02
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-message-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-message-04.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:	<20020507130225.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-message-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-message-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020507130225.I-D@ietf.org>

--OtherAccess--

--NextPart--



From suga@flab.fujitsu.co.jp  Fri May 10 01:49:20 2002
Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15688
	for ; Fri, 10 May 2002 01:49:19 -0400 (EDT)
Received: from m1.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0204-Fujitsu Gateway)
	id OAA28133 for ; Fri, 10 May 2002 14:48:09 +0900 (JST)
	(envelope-from suga@flab.fujitsu.co.jp)
Received: from dm.akashi.flab.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0204-Fujitsu Domain Master)
	id OAA00025 for ; Fri, 10 May 2002 14:48:08 +0900 (JST)
	(envelope-from suga@flab.fujitsu.co.jp)
Received: from dm.akashi.flab.fujitsu.co.jp by dm.akashi.flab.fujitsu.co.jp (8.9.3/3.7W-020129-Fujitsu Labs. Akashi Domain Mail Master)
	id OAA21748; Fri, 10 May 2002 14:48:07 +0900 (JST)
Received: (from uranus [10.254.214.227])
 by dm.akashi.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2002051014480709437
 ; Fri, 10 May 2002 14:48:07 +0900
Message-ID: <02e701c1f7e6$41534700$e3d6fe0a@uranus>
From: "Hiroyasu Sugano" 
To: "Paul Kyzivat" , 
Cc: "'Carr, Wayne'" , ,
        
References: <000801c1f5ec$fa6a6c10$6405010a@ADRIANXP> <3CD8209C.1DF74246@cisco.com>
Date: Fri, 10 May 2002 14:48:05 +0900
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
Content-Length: 509
Subject: [Simple] Re: priority range in PIDF
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: 

Paul Kyzivat wrote:
> Adrian Bateman wrote:
> >
> > My preference would be toward the integer value (I'm just happier
> > dealing with integers) but I don't have any substantial objections to
> > the alternative.
>
> Just to be contrarian, I would prefer the decimal form for consistency with sip &
http, but don't have an substantial objection to integers in range [0,1000].

I'm okay to go with the way of SIP and HTTP if there is no substantial objection to
it.
Any counter arguments?

-- Hiroyasu Sugano


From tsearle@indigosw.com  Fri May 10 05:38:44 2002
Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA16338
	for ; Fri, 10 May 2002 05:38:44 -0400 (EDT)
Received: (qmail 4710 invoked by alias); 10 May 2002 09:37:36 -0000
Received: from unknown (HELO indigosw.com) (194.78.202.25)
  by 0 with SMTP; 10 May 2002 09:37:36 -0000
Message-ID: <3CDB91E4.1050803@indigosw.com>
Date: Fri, 10 May 2002 11:24:52 +0200
From: Torrey Searle 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020501
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
CC: Jean-Luc Sonnet 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 401
Subject: [Simple] Offline messaging
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: 

In the current messaging draft, it seems that Message Replay attack 
prevention relies on the ability to determine that the message 
originated from a offline messaging server, and that the message is an 
offline message.  

Are their any plans on adding a way of marking a message as an offline 
message?
Is their any way for a server to identify itself as being offline 
messaging enabled?

Torrey


From billing@pommel.com  Thu May  9 05:56:31 2002
Received: from Sender ([217.19.72.100])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA12533
	for ; Thu, 9 May 2002 05:56:27 -0400 (EDT)
Message-Id: <200205090956.FAA12533@mailman.dynamicsoft.com>
From: "Evgeny L. Kalinin"
To: 
Reply-To: billing@pommel.com
X-Mailer: Advanced Mass Sender 3.2b (Built-In Smtp relay v2.0)
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="= Multipart Boundary 0509021300"
Date: Thu, 9 May 2002 13:00:39 +0300
Content-Length: 42227
Subject: [Simple] Looking for termination of our traffic in India, Pakistan, Bangladesh etc.
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: 

This is a multipart MIME message.

--= Multipart Boundary 0509021300
Content-Type: text/plain; charset="Windows-1251"
Content-Transfer-Encoding: 7bit

Dear Sirs, please don't consider this email as a SPAM even if it reached You by mistake.
Our company is a licensed telecom carrier in Greece and is operating succesfully on this market since year of 2000.
We currently have 3 POP's in Greece running VoIP (CISCO only via public Internet) for calling cards, corporate clients and call-shops.
Wea are looking for a reliable partner to provide us with good  quality and reasonable prices for termination of our traffic for
following destinations: India, Pakistan, Bangladesh, U.K.-Mobiles etc. (whole list with traffic in th.min per month You could find attached).
Actually, world-wide termination would be appreciated with majority of traffic for attached destinations.
All traffic is generated ny us only - no reselling.
Please contact us with Your offers.

With best regards,
Evgeny L. Kalinin
Manager


--= Multipart Boundary 0509021300
Content-Type: application/octet-stream;
	name="Wholesale Target Prices 2002_05.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="Wholesale Target Prices 2002_05.xls"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAB
AAAAOQAAAAAAAAAAEAAA/v///wAAAAD+////AAAAADgAAAD/////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
//////////////////////8JCBAAAAYFAP4czQfJQAAABgEAAOEAAgCwBMEA
AgAAAOIAAABcAHAAEQAARXZnZW55IEwuIEthbGluaW4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAA
AMABAAA9AQIAAwCcAAIADgAZAAIAAAASAAIAAAATAAIAAACvAQIAAAC8AQIA
AAA9ABIA6BceAKgbeC04AAAAAAABANoBQAACAAAAjQACAAAAIgACAAAADgAC
AAEAtwECAAAA2gACAAAAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwA
MQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAA
AAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwA
MQAaAMgAAAA9AJABAAAAAgAABQFBAHIAaQBhAGwAMQAaAMgABAAMAJABAAAB
AAAABQFBAHIAaQBhAGwAMQAaAMgABAAkAJABAAABAAAABQFBAHIAaQBhAGwA
MQAaALQAAAD/f5ABAAAAAgAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAA
AgAABQFBAHIAaQBhAGwAMQAaAKAAAAD/f5ABAAAAAgAABQFBAHIAaQBhAGwA
MQAaAPAAAAAJAJABAAAAAgAABQFBAHIAaQBhAGwAMQAaAMgAAAAIAJABAAAA
AgAABQFBAHIAaQBhAGwAMQAaANwAAAAJAJABAAAAAgAABQFBAHIAaQBhAGwA
MQAaANwAAAAIAJABAAAAAgAABQFBAHIAaQBhAGwAMQAaANwAAAD/f5ABAAAA
AgAABQFBAHIAaQBhAGwAHgQcAAUAFwAAIiQiIywjIzBfKTtcKCIkIiMsIyMw
XCkeBCEABgAcAAAiJCIjLCMjMF8pO1tSZWRdXCgiJCIjLCMjMFwpHgQiAAcA
HQAAIiQiIywjIzAuMDBfKTtcKCIkIiMsIyMwLjAwXCkeBCcACAAiAAAiJCIj
LCMjMC4wMF8pO1tSZWRdXCgiJCIjLCMjMC4wMFwpHgQ3ACoAMgAAXygiJCIq
ICMsIyMwXyk7XygiJCIqIFwoIywjIzBcKTtfKCIkIiogIi0iXyk7XyhAXyke
BC4AKQApAABfKCogIywjIzBfKTtfKCogXCgjLCMjMFwpO18oKiAiLSJfKTtf
KEBfKR4EPwAsADoAAF8oIiQiKiAjLCMjMC4wMF8pO18oIiQiKiBcKCMsIyMw
LjAwXCk7XygiJCIqICItIj8/Xyk7XyhAXykeBDYAKwAxAABfKCogIywjIzAu
MDBfKTtfKCogXCgjLCMjMC4wMFwpO18oKiAiLSI/P18pO18oQF8pHgQYAKQA
EwAAIiQiIywjIzA7XC0iJCIjLCMjMB4EHQClABgAACIkIiMsIyMwO1tSZWRd
XC0iJCIjLCMjMB4EHgCmABkAACIkIiMsIyMwLjAwO1wtIiQiIywjIzAuMDAe
BCMApwAeAAAiJCIjLCMjMC4wMDtbUmVkXVwtIiQiIywjIzAuMDAeBDUAqAAw
AABfLSIkIiogIywjIzBfLTtcLSIkIiogIywjIzBfLTtfLSIkIiogIi0iXy07
Xy1AXy0eBCwAqQAnAABfLSogIywjIzBfLTtcLSogIywjIzBfLTtfLSogIi0i
Xy07Xy1AXy0eBD0AqgA4AABfLSIkIiogIywjIzAuMDBfLTtcLSIkIiogIywj
IzAuMDBfLTtfLSIkIiogIi0iPz9fLTtfLUBfLR4ENACrAC8AAF8tKiAjLCMj
MC4wMF8tO1wtKiAjLCMjMC4wMF8tO18tKiAiLSI/P18tO18tQF8tHgQIAKwA
AwAAMF8pHgQLAK0ABgAAMC4wMDAwHgQKAK4ABQAAMC4wMDAeBFEArwBMAABf
KFskJC00MDldKiAjLCMjMC4wMDBfKTtfKFskJC00MDldKiBcKCMsIyMwLjAw
MFwpO18oWyQkLTQwOV0qICItIj8/P18pO18oQF8pHgRUALAATwAAXyhbJCQt
NDA5XSogIywjIzAuMDAwMF8pO18oWyQkLTQwOV0qIFwoIywjIzAuMDAwMFwp
O18oWyQkLTQwOV0qICItIj8/Pz9fKTtfKEBfKR4EFQCxABAAACJZZXMiOyJZ
ZXMiOyJObyIeBBoAsgAVAAAiVHJ1ZSI7IlRydWUiOyJGYWxzZSIeBBQAswAP
AAAiT24iOyJPbiI7Ik9mZiIeBDAAtAArAABbJCQtNDA5XSMsIyMwLjAwMDBf
KTtcKFskJC00MDldIywjIzAuMDAwMFwpHgQyALUALQAAWyQkLTQwOV0jLCMj
MC4wMDAwMF8pO1woWyQkLTQwOV0jLCMjMC4wMDAwMFwpHgQuALYAKQAAWyQk
LUMwOV0jLCMjMC4wMDAwMDtcLVskJC1DMDldIywjIzAuMDAwMDAeBBgAtwAT
AABbJCQtQzA5XSMsIyMwLjAwMDAwHgQSALgADQAAIiQiIywjIzAuMDAwMB4E
KwC5ACYAACIkIiMsIyMwLjAwMDBfKTtbUmVkXVwoIiQiIywjIzAuMDAwMFwp
HgQYALoAEwAAWyQkLTQwOV0jLCMjMC4wMDAwMB4EEAC7AAsAACMsIyMwLjAw
MDAwHgQXALwAEgAAWyQkLUMwOV0jLCMjMC4wMDAwHgQsAL0AJwAAWyQkLUMw
OV0jLCMjMC4wMDAwO1wtWyQkLUMwOV0jLCMjMC4wMDAwHgQxAL4ALAAAWyQk
LUMwOV0jLCMjMC4wMDAwO1tSZWRdXC1bJCQtQzA5XSMsIyMwLjAwMDAeBBkA
vwAUAABbJCQtQzA5XSMsIyMwLjAwMDAwMB4EJwDAACIAACIkIiMsIyMwLjAw
MDA7W1JlZF1cLSIkIiMsIyMwLjAwMDAeBAkAwQAEAAAwLjAlHgQ6AMIANQAA
XygqICMsIyMwLjAwMDBfKTtfKCogXCgjLCMjMC4wMDAwXCk7XygqICItIj8/
Xyk7XyhAXyngABQAAAAxAPX/IAAQAAAAAAAAAAAAwCDgABQAAQAAAPX/IAAA
9AAAAAAAAAAAwCDgABQAAQAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/
IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAA
APX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQA
AAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDg
ABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAA
wCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAA
AAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAA
AAAAAAAAwCDgABQAAAAxAAEAIAAQAAAAAAAAAAAAwCDgABQAAQArAPX/IAAA
+AAAAAAAAAAAwCDgABQAAQApAPX/IAAA+AAAAAAAAAAAwCDgABQABQC3APX/
IAAA8AAAAAAAAAAAwCDgABQAAQAqAPX/IAAA+AAAAAAAAAAAwCDgABQABwAA
APT/AAAA9AAAAAAAAAAAwCDgABQABgAAAPT/AAAA9AAAAAAAAAAAwCDgABQA
AQAJAPX/IAAA+AAAAAAAAAAAwCDgABQACAAxAAEAIAAQCAAAAAAAAAAAwCDg
ABQACAAxAAEAIwAQGAAAAAAAAAAAwCDgABQACAAxAAEAIQAQGAAAAAAAAAAA
wCDgABQACAAxAAEAIgAQGAAAAAAAAAAAwCDgABQACAAxAAEAEAAAGAAAAAAA
AAAAwCDgABQACQAxAAEAIAAQCAAAAAAAAAAAwCDgABQACgAxAAEAIgAQGAAA
AAAAAAAAwCDgABQACgAxAAEAIwAQGAAAAAAAAAAAwCDgABQACwAxAAEAEQAA
eAAAAAAAAAAAwCDgABQACAAxAAEAEgAQGAAAAAAAAAAAwCDgABQACAAxAAEA
EQAQGAAAAAAAAAAAwCDgABQACQAxAAEAIwAQOBFxQCBAIAAAwCDgABQACQAx
AAEAIQAQOBFxQCBAIAAAwCDgABQACQAxAAEAIgAQOAFxQABAIAAAwCDgABQA
CQAxAAEAIwAQOBF3QCBAIAAAwCDgABQACQAxAAEAIQAQOBF3QCBAIAAAwCDg
ABQACQAxAAEAIgAQOAF3QABAIAAAwCDgABQACQAxAAEAIQAQeBF3QCBAIAAA
wCDgABQACQAxAAEAIwAQOBFwQCAAIAAAwCDgABQACQAxAAEAIQAQOBFwQCAA
IAAAwCDgABQACQAxAAEAIgAQOAFwQAAAIAAAwCDgABQACQAxAAEAIwAQOBEQ
QCAAIAAAwCDgABQACQAxAAEAIQAQOBEQQCAAIAAAwCDgABQACQAxAAEAIgAQ
OAEQQAAAIAAAwCDgABQACQAxAAEAIQAQGAAAAAAAAAAAwCDgABQACQAIAAEA
IQAQPBF3QCBAIAAAwCDgABQACQAIAAEAIgAQPAF3QABAIAAAwCDgABQADQAx
AAEAEQAAeAAAAAAAAAAAwCDgABQADgAJAGEBEgAAOAAAAAAAAAAAwCDgABQA
DwAxAAEAIAAQCAAAAAAAAAAAwCDgABQADwAxAAEAIwAQGAAAAAAAAAAAwCDg
ABQADwAxAAEAIQAQGAAAAAAAAAAAwCDgABQADwAxAAEAIgAQGAAAAAAAAAAA
wCDgABQADQC3ACEBGgAAeCIAQCAAAAAAwCDgABQADwAxAAEAEAAAGAAAAAAA
AAAAwCDgABQACQAAAAEAIgAQPBFxQCBAIAAAwCDgABQACQAAAAEAIgAQPBFw
QCAAIAAAwCDgABQACQAAAAEAIgAQPBF3QCBAIAAAwCDgABQACQAAAAEAIgAQ
PBEQQCAAIAAAwCDgABQADQAxAAEAGgAAeCIiQCBAIAAENCDgABQADQC3ACEB
GgAAeCIiQCBAIAAENCDgABQADQAxAAEAEwAAeAIgQAAAIAAENCDgABQADQAx
AAEAEwAAeAICQABAAAAENCDgABQADQAxAAEAEwAAeAIAQAAAAAAENCDgABQA
DwAxAAEAIQAQWAAAAAAAAAAENCDgABQACAACAAEAIgAQHAAAAAAAAAAAwCDg
ABQADgACAGEBEgAAPAAAAAAAAAAAwCDgABQADwACAAEAIgAQHAAAAAAAAAAA
wCDgABQADQACACEBGgAAfCIiQCBAIAAENCDgABQACAACAAEAEgAQHAAAAAAA
AAAAwCDgABQADAACACEBIwAAPAICQABAAAAAwCDgABQADAACACEBIwAAPAIA
QAAAAAAAwCDgABQADAACACEBIwAAfAIAQAAAAAAAwCDgABQADAACACEBIwAA
PAIgQAAAIAAAwCDgABQADQAxAAEAEgAQeAIiQABAIAAENCDgABQADQAxAAEA
EgAQeCAiACBAIAAENCCTAgQAEIAD/5MCBAARgAb/kwIEABKABP+TAgQAE4AH
/5MCBAAUgAn/kwIEABWACP+TAgQAAIAA/5MCBAAWgAX/YAECAAAAhQAVAPEV
AAAAAA0AMjYgTWFyY2ggMjAwMowABAABAAEArgEEAAEAAQQXAAgAAQAAAAAA
AAAYABsAIAAAAQsAAAABAAAAAAAABzsAAAAABgAAAP8AwQEIAMEBAABgaQEA
/AByBEIAAABCAAAACwAAQWZnaGFuaXN0YW4HAABBbGJhbmlhCgAAQmFuZ2xh
ZGVzaBkAAEJhbmdsYWRlc2gsIENlbGwvU3AgU3Zjcy4RAABCYW5nbGFkZXNo
LCBEaGFrYQgAAEJ1bGdhcmlhGAAAQnVsZ2FyaWEsIENlbGwvIFNwLiBTdmNz
FgAAQ2hpbmEsIENlbGwvIFNwLiBTdmNzLg4AAENoaW5hLCBCZWlqaW5nBQAA
RWd5cHQRAABFZ3lwdCwgQWxleGFuZHJpYRQAAEVneXB0LCBDZWxsL1NwIFN2
Y3MuBQAASW5kaWENAABJbmRpYSwgQm9tYmF5FgAASW5kaWEsIENlbGwvIFNw
LiBTdmNzLg8AAEluZGlhLCBDYWxjdXR0YQ8AAEluZG9uZXNpYSwgQ2VsbBIA
AEluZG9uZXNpYSwgSmFrYXJ0YQUAAEtlbnlhFQAAS2VueWEsIENlbGwvU3Au
IFN2Y3MuDgAAS2VueWEsIE1vbWJhc2EOAABLZW55YSwgTmFpcm9iaQcAAE5p
Z2VyaWEWAABOaWdlcmlhIENlbGwvU3AuIFN2Y3MuDgAATmlnZXJpYSwgTGFn
b3MIAABQYWtpc3RhbhkAAFBha2lzdGFuLCBDZWxsLyBTcC4gU3Zjcy4TAABQ
YWtpc3RhbiwgSXNsYW1hYmFkEQAAUGFraXN0YW4sIEthcmFjaGkLAABQaGls
aXBwaW5lcxwAAFBoaWxpcHBpbmVzLCBDZWxsLyBTcC4gU3Zjcy4TAABQaGls
aXBwaW5lcywgTWFuaWxhBgAAUG9sYW5kFwAAUG9sYW5kLCBDZWxsLyBTcC4g
U3Zjcy4OAABQb2xhbmQsIFdhcnNhdwcAAFJvbWFuaWEYAABSb21hbmlhLCBD
ZWxsLyBTcC4gU3Zjcy4JAABTcmkgTGFua2EaAABTcmkgTGFua2EsIENlbGwv
IFNwLiBTdmNzLgUAAFN5cmlhBwAAVmlldG5hbRgAAFZpZXRuYW0sIENlbGwv
IFNwLiBTdmNzLgUAAElyYXEgAgAANjMDAAA2MzILAABJcmFuIFByb3BlcgsA
AElyYW4gVGVocmFuCwAASXJhbiBNb2JpbGUJAABJbmRvbmVzaWEFAABDaGlu
YQwAAEVneXB0LCBDYWlybwoAADk4LTkxMSw5MTMYAABUZXJtaW5hdGlvbiBk
ZXN0aW5hdGlvbnMQAABCdWxnYXJpYSAtIFNvZmlhDAAASW5kaWEsIERlbGhp
EAAAUGFraXN0YW4sIExhaG9yZQUAADYzMjQxEgAAUm9tYW5pYSwgQnVjdXJl
c3RpBAAAQ29kZRkAAFdob2xlc2FsZSBQcmljZSAoVVMkL21pbikVAABTZWxl
Y3RlZCBEZXN0aW5hdGlvbnMXAABXaG9sZXNhbGUgVGFyZ2V0IFByaWNlcwgA
AE1heSAyMDAyCgAAVS5LLiwgQ2VsbAMAADQ0Nx8AAE5vdGVzICh0cmFmZmlj
LCBLbWluIHBlciBtb250aCn/AEoACAA1EQAADAAAAMkRAACgAAAAUBIAACcB
AADcEgAAswEAAIETAABYAgAACxQAAOICAABtFAAARAMAAO0UAADEAwAAdxUA
AE4EAAAKAAAACQgQAAAGEAD+HM0HyUAAAAYBAAALAiwAAAAAAAAAAADeAAAA
pBsAAFQmAABYMQAA3jkAAKY/AABuRQAABksAAL5OAAANAAIAAQAMAAIAZAAP
AAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIA
AQCAAAgAAAAAAAAAAAAlAgQAAADwAIEAAgDBBBQAAAAVABUAEgAAJkMmOCZQ
JlImOCZGICZBCiZEgwACAAAAhAACAAAAJgAIAJqZmZmZmek/JwAIAJqZmZmZ
mek/KAAIAJDH4/F4PN4/KQAIAFK4HoXrUeA/TQCWBAAASABQAEwASgBfAGwA
bwBjAGEAbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAEEGADcALgDAz8BAgIACQAAAAAAZAABAAcALAECAAEALAEAAAAA
QQA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQELgBIUCBMYXNlckpldCAx
MTAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAMgCPAYYDeJydVVuOwzAI/Pcx
+r+SwRjsXmXb+19j0yaxwc3sSqsoP0xgeE7uVlt6fFMqmlNO9H4k3adZhpnz
ZtfytnMvw57T4zmBWgHQdQAlAu3ao+SKPAwBNACKAIOsGki3fgDV9qysO/KZ
bJsMHKpotAQyPQDfwtvt8Ty89sRc45cGz3ZR9wFZaQk4nbRAJ/5wOivN+bLS
vBY0ANDkkuOyOA7uNXCc1EKumzOQgKYUqYihCP871GuHwuyl/BWLfk/Lz98U
jauYJb9Me9Bxkub8FmjWWqq7VkVHKXadOVd4314nAgCmLwKOslIH5D27UPFc
DRXSUCFIEio6MEM9MSBU7CRhUReUVcsAUNeTvLBkRM8oYdR5pHrijuWLvE6I
hJns63pqSPvUkAEJhELEHWp2bMbMbzPu3+ekm+7v375eok7tuPXhp9d+PfrJ
qRFH2UagtT2vjRpMdsVkm9IFJq6L3on/ezgJ4XlvGudeWDAUtcpLFV/+plgV
7Iqiy9K49QGKW7xokfvluASqffi83h/UdHvHAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChACIACQBCAAEA
AQABAAAALAEsAZDH4/F4PM4/cT0K16NwzT8BAFUAAgAIAH0ADAAAAAAAtgEX
AAIAAAB9AAwAAQABAEkEGAACAAAAfQAMAAIAAgAkHxkABgAAAH0ADAADAAMA
AAwaAAIAAAB9AAwABAAEANsAFwACAAAAfQAMAAUABQDbFEQAAgAAAH0ADAAG
AAYAtgAXAAIAAAB9AAwABwAHAAA4GQACAAAAfQAMAAgAFADbABcAAgAAAH0A
DAAVAAABJAkXAAAAAACQACgAAAAhAAAAUnVzc2lhICAgICAgICAgICAgICAg
KENpc2NvK1JBRCApAAACDgAAAAAA3gAAAAAAFQAAAAgCEAAAAAAACgAtAAAA
AABAAQ8gCAIQAAEAAAAKACwBAAAAAAABDwAIAhAAAgAAAAoALAEAAAAAAAEP
AAgCEAADAAAACgA7AQAAAAAAAQ8gCAIQAAQAAAAKADwAAAAAAEABDyAIAhAA
BQAAAAoAwQIAAAAAwAEbIAgCEAAGAAAACgA8AAAAAADAASAACAIQAAcAAAAK
AB4AAAAAAEABDyAIAhAACAAAAAoA/wAAAAAAQAEPAAgCEAAJAAAACgD/AAAA
AABAAQ8ACAIQAAoAAAAKAP8AAAAAAEABDwAIAhAACwAAAAoA/wAAAAAAQAEP
AAgCEAAMAAAACgD/AAAAAABAAQ8ACAIQAA0AAAAKAP8AAAAAAEABDwAIAhAA
DgAAAAoA/wAAAAAAQAEPAAgCEAAPAAAACgD/AAAAAABAAQ8ACAIQABAAAAAI
AP8AAAAAAEABDwAIAhAAEQAAAAgA/wAAAAAAQAEPAAgCEAASAAAACAD/AAAA
AABAAQ8ACAIQABMAAAAIAP8AAAAAAEABDwAIAhAAFAAAAAgA/wAAAAAAQAEP
AAgCEAAVAAAACAD/AAAAAABAAQ8ACAIQABYAAAAIAP8AAAAAAEABDwAIAhAA
FwAAAAgA/wAAAAAAQAEPAAgCEAAYAAAACAD/AAAAAABAAQ8ACAIQABkAAAAI
AP8AAAAAAEABDwAIAhAAGgAAAAgA/wAAAAAAQAEPAAgCEAAbAAAACAD/AAAA
AABAAQ8ACAIQABwAAAAIAP8AAAAAAEABDwAIAhAAHQAAAAgA/wAAAAAAQAEP
AAgCEAAeAAAACAD/AAAAAABAAQ8ACAIQAB8AAAAIAP8AAAAAAEABDwC+ABIA
AQABADIAMgAyADMARQA0AAYA/QAKAAEABwBBAD0AAAC+AAoAAQAIAB8AHwAJ
AL4AEgACAAEAMgAyADIAMwBFADQABgD9AAoAAgAHAEIAPAAAAL4ACgACAAgA
HwAfAAkAvgASAAMAAQAyADIAMgAzAEUANAAGAP0ACgADAAcAQAA+AAAAvgAK
AAMACAAfAB8ACQC+ABQABAABADUANgA3ADQARgA0AEMABwD9AAoABQABAE0A
NAAAAAECBgAFAAIATgD9AAoABQADAD4AOgAAAAECBgAFAAQAOAD9AAoABQAF
AEcAOwAAAAECBgAFAAYAOQD9AAoABQAHAD8AQQAAAAECBgAGAAUASAABAgYA
BgAHACEAvgAKAAgAAAAaACIAAQD9AAoACAACACMAAAAAAH4CCgAIAAMAJAAA
QFdAAQIGAAgABAAcAH4CCgAIAAUASQABgEZAfgIKAAgABwA6AAAASUC+ABIA
CQAAABoAKQAqACsAHABKAAUAAQIGAAkABwA7AL4ACgAKAAAAGgAlAAEA/QAK
AAoAAgAmAAEAAAB+AgoACgADACcAADB2QAECBgAKAAQAHAB+AgoACgAFAEoA
AQAcQH4CCgAKAAcAPAAAwHJAvgASAAsAAAAaACUAJgAnABwASgAFAAECBgAL
AAcAPAC+AAoADAAAABoAJQABAP0ACgAMAAIAJgACAAAAfgIKAAwAAwAnAACA
i0ABAgYADAAEABwAfgIKAAwABQBKAAEAMkB+AgoADAAHADwAAABpQL4ACgAN
AAAAGgAlAAEA/QAKAA0AAgAmAAMAAAB+AgoADQADACcAgDDBQAECBgANAAQA
HAB+AgoADQAFAEoAAQA0QAECBgANAAcAPAC+AAoADgAAABoAJQABAP0ACgAO
AAIAJgAEAAAAfgIKAA4AAwAnAAAxwUABAgYADgAEABwAfgIKAA4ABQBKAAEA
FEABAgYADgAHADwAvgASAA8AAAAaACUAJgAnABwASgAFAAECBgAPAAcAPAC+
AAoAEAAAABoAJQABAP0ACgAQAAIAJgAFAAAAfgIKABAAAwAnAABwdkABAgYA
EAAEABwAfgIKABAABQBKAAEAIEB+AgoAEAAHADwAAABZQL4ACgARAAAAGgAl
AAEA/QAKABEAAgAmADUAAAB+AgoAEQADACcAAHB2QAECBgARAAQAHAB+AgoA
EQAFAEoAAQAYQAECBgARAAcAPAC+AAoAEgAAABoAJQABAP0ACgASAAIAJgAG
AAAAfgIKABIAAwAnAICN4UABAgYAEgAEABwAfgIKABIABQBKAAEAJkABAgYA
EgAHADwAvgASABMAAAAaACUAJgAnABwASgAFAAECBgATAAcAPAC+AAoAFAAA
ABoAJQABAP0ACgAUAAIAJgAxAAAAfgIKABQAAwAnAACAVUABAgYAFAAEABwA
fgIKABQABQBKAAEACEB+AgoAFAAHADwAAMBiQL4ACgAVAAAAGgAlAAEA/QAK
ABUAAgAmAAcAAAB+AgoAFQADACcAgNLAQAECBgAVAAQAHAB+AgoAFQAFAEoA
AADgPwECBgAVAAcAPAC+AAoAFgAAABoAJQABAP0ACgAWAAIAJgAIAAAAfgIK
ABYAAwAnAADRwEABAgYAFgAEABwAfgIKABYABQBKAAEABEABAgYAFgAHADwA
vgASABcAAAAaACUAJgAnABwASgAFAAECBgAXAAcAPAC+AAoAGAAAABoAJQAB
AP0ACgAYAAIAJgAJAAAAfgIKABgAAwAnAAAANEABAgYAGAAEABwAfgIKABgA
BQBKAAEALEB+AgoAGAAHADwAAABpQL4ACgAZAAAAGgAlAAEA/QAKABkAAgAm
AAoAAAB+AgoAGQADACcAAGBpQAECBgAZAAQAHAB+AgoAGQAFAEoAAQAwQAEC
BgAZAAcAPAC+AAoAGgAAABoAJQABAP0ACgAaAAIAJgAyAAAAfgIKABoAAwAn
AABAaUABAgYAGgAEABwAfgIKABoABQBKAAEAMEABAgYAGgAHADwAvgAKABsA
AAAaACUAAQD9AAoAGwACACYACwAAAH4CCgAbAAMAJwAAaJ9AAQIGABsABAAc
AH4CCgAbAAUASgABADJAAQIGABsABwA8AL4AEgAcAAAAGgAlACYAJwAcAEoA
BQABAgYAHAAHADwAvgAKAB0AAAAaACUAAQD9AAoAHQACACYADAAAAH4CCgAd
AAMAJwAAwFZAAQIGAB0ABAAcAH4CCgAdAAUASgABADNAfgIKAB0ABwA8AAAA
aUC+AAoAHgAAABoAJQABAP0ACgAeAAIAJgANAAAAfgIKAB4AAwAnAADRwUAB
AgYAHgAEABwAfgIKAB4ABQBKAAEAKkABAgYAHgAHADwAvgAKAB8AAAAaACUA
AQD9AAoAHwACACYADgAAAH4CCgAfAAMAJwCA9sFAAQIGAB8ABAAcAH4CCgAf
AAUASgABADNAAQIGAB8ABwA8ANcARADMCQAAbAIAADIAMgAyABgAVgAUAAAA
UAAgAFAAIABQAEwATAAgAFAATABMACAAUABMAEwAIABQAEwATABMACAAUABM
AAgCEAAgAAAACAD/AAAAAABAAQ8ACAIQACEAAAAIAP8AAAAAAEABDwAIAhAA
IgAAAAgA/wAAAAAAQAEPAAgCEAAjAAAACAD/AAAAAABAAQ8ACAIQACQAAAAI
AP8AAAAAAEABDwAIAhAAJQAAAAgA/wAAAAAAQAEPAAgCEAAmAAAACAD/AAAA
AABAAQ8ACAIQACcAAAAIAP8AAAAAAEABDwAIAhAAKAAAAAgA/wAAAAAAQAEP
AAgCEAApAAAACAD/AAAAAABAAQ8ACAIQACoAAAAIAP8AAAAAAEABDwAIAhAA
KwAAAAgA/wAAAAAAQAEPAAgCEAAsAAAACAD/AAAAAABAAQ8ACAIQAC0AAAAI
AP8AAAAAAEABDwAIAhAALgAAAAgA/wAAAAAAQAEPAAgCEAAvAAAACAD/AAAA
AABAAQ8ACAIQADAAAAAIAP8AAAAAAEABDwAIAhAAMQAAAAgA/wAAAAAAQAEP
AAgCEAAyAAAACAD/AAAAAABAAQ8ACAIQADMAAAAIAP8AAAAAAEABDwAIAhAA
NAAAAAgA/wAAAAAAQAEPAAgCEAA1AAAACAD/AAAAAABAAQ8ACAIQADYAAAAI
AP8AAAAAAEABDwAIAhAANwAAAAgA/wAAAAAAQAEPAAgCEAA4AAAACAD/AAAA
AABAAQ8ACAIQADkAAAAIAP8AAAAAAEABDwAIAhAAOgAAAAgA/wAAAAAAQAEP
AAgCEAA7AAAACAD/AAAAAABAAQ8ACAIQADwAAAAIAP8AAAAAAEABDwAIAhAA
PQAAAAgA/wAAAAAAQAEPAAgCEAA+AAAACAD/AAAAAABAAQ8ACAIQAD8AAAAI
AP8AAAAAAEABDwC+AAoAIAAAABoAJQABAP0ACgAgAAIAJgAPAAAAfgIKACAA
AwAnAIDWwUABAgYAIAAEABwAfgIKACAABQBKAAEAKkABAgYAIAAHADwAvgAK
ACEAAAAaACUAAQD9AAoAIQACACYANgAAAH4CCgAhAAMAJwAA2sFAAQIGACEA
BAAcAH4CCgAhAAUASgABACZAAQIGACEABwA8AL4AEgAiAAAAGgAlACYAJwAc
AEoABQABAgYAIgAHADwAvgAKACMAAAAaACUAAQD9AAoAIwACACYAMAAAAH4C
CgAjAAMAJwAAAE9AAQIGACMABAAcAH4CCgAjAAUASgABACRAfgIKACMABwA8
AAAALkC+AAoAJAAAABoAJQABAP0ACgAkAAIAJgAQAAAAfgIKACQAAwAnAACQ
uEABAgYAJAAEABwAfgIKACQABQBKAAEAJEABAgYAJAAHADwAvgAKACUAAAAa
ACUAAQD9AAoAJQACACYAEQAAAH4CCgAlAAMAJwAATbhAAQIGACUABAAcAH4C
CgAlAAUASgABABRAAQIGACUABwA8AL4AEgAmAAAAGgAlACYAJwAcAEoABQAB
AgYAJgAHADwAvgAKACcAAAAaACUAAQD9AAoAJwACACYALQAAAH4CCgAnAAMA
JwAAgFhAAQIGACcABAAcAH4CCgAnAAUASgABADBAfgIKACcABwA8AAAAPkC+
AAoAKAAAABoAJQABAP0ACgAoAAIAJgAuAAAAfgIKACgAAwAnAACAWEABAgYA
KAAEABwAfgIKACgABQBKAAEAMUABAgYAKAAHADwAvgAKACkAAAAaACUAAQD9
AAoAKQACACYALwAAAP0ACgApAAMAJwAzAAAAAQIGACkABAAcAH4CCgApAAUA
SgABADJAAQIGACkABwA8AL4AEgAqAAAAGgAlACYAJwAcAEoABQABAgYAKgAH
ADwAvgAKACsAAAAaACUAAQD9AAoAKwACACYAKgAAAH4CCgArAAMAJwAAII5A
AQIGACsABAAcAH4CCgArAAUASgABADZAfgIKACsABwA8AAAANEC+ABIALAAA
ABoAJQAmACcAHABKAAUAAQIGACwABwA8AL4ACgAtAAAAGgAlAAEA/QAKAC0A
AgAmABIAAAB+AgoALQADACcAAMBvQAECBgAtAAQAHAB+AgoALQAFAEoAAADQ
P34CCgAtAAcAPAAAAD5AvgAKAC4AAAAaACUAAQD9AAoALgACACYAEwAAAH4C
CgAuAAMAJwAAwG9AAQIGAC4ABAAcAH4CCgAuAAUASgABADtAAQIGAC4ABwA8
AL4ACgAvAAAAGgAlAAEA/QAKAC8AAgAmABQAAAB+AgoALwADACcAwNDYQAEC
BgAvAAQAHAB+AgoALwAFAEoAAQAzQAECBgAvAAcAPAC+AAoAMAAAABoAJQAB
AP0ACgAwAAIAJgAVAAAAfgIKADAAAwAnAADco0ABAgYAMAAEABwAfgIKADAA
BQBKAAEAMUABAgYAMAAHADwAvgASADEAAAAaACUAJgAnABwASgAFAAECBgAx
AAcAPAC+AAoAMgAAABoAJQABAP0ACgAyAAIAJgAWAAAAfgIKADIAAwAnAABA
bUABAgYAMgAEABwAfgIKADIABQBKAAEANkB+AgoAMgAHADwAAMBiQL4ACgAz
AAAAGgAlAAEA/QAKADMAAgAmABcAAAB+AgoAMwADACcAUJMMQQECBgAzAAQA
HAB+AgoAMwAFAEoAAADQPwECBgAzAAcAPAC+AAoANAAAABoAJQABAP0ACgA0
AAIAJgAYAAAAfgIKADQAAwAnAABKokABAgYANAAEABwAfgIKADQABQBKAAEA
JEABAgYANAAHADwAvgASADUAAAAaACUAJgAnABwASgAFAAECBgA1AAcAPAC+
AAoANgAAABoAJQABAP0ACgA2AAIAJgAZAAAAfgIKADYAAwAnAAAAV0ABAgYA
NgAEABwAfgIKADYABQBLAAEAMkB+AgoANgAHADwAAEBvQL4ACgA3AAAAGgAl
AAEA/QAKADcAAgAmABoAAAB+AgoANwADACcAANiMQAECBgA3AAQAHAB+AgoA
NwAFAEsAAQA1QAECBgA3AAcAPAC+AAoAOAAAABoAJQABAP0ACgA4AAIAJgAb
AAAAfgIKADgAAwAnACCW9kABAgYAOAAEABwAfgIKADgABQBLAAEAMkABAgYA
OAAHADwAvgAKADkAAAAaACUAAQD9AAoAOQACACYAHAAAAH4CCgA5AAMAJwCA
AsJAAQIGADkABAAcAH4CCgA5AAUASwABAChAAQIGADkABwA8AL4ACgA6AAAA
GgAlAAEA/QAKADoAAgAmADcAAAB+AgoAOgADACcAAA3CQAECBgA6AAQAHAB+
AgoAOgAFAEsAAQAoQAECBgA6AAcAPAC+ABIAOwAAABoAJQAmACcAHABLAAUA
AQIGADsABwA8AL4ACgA8AAAAGgAlAAEA/QAKADwAAgAmAB0AAAD9AAoAPAAD
ACcAKwAAAAECBgA8AAQAHAB+AgoAPAAFAEsAAQBUQH4CCgA8AAcAPAAAAElA
vgAKAD0AAAAaACUAAQD9AAoAPQACADAAHgAAAP0ACgA9AAMAMQA4AAAAAQIG
AD0ABAAcAH4CCgA9AAUASwABACRAAQIGAD0ABwA8AL4ACgA+AAAAGgAlAAEA
/QAKAD4AAgAwAB8AAAD9AAoAPgADADEALAAAAAECBgA+AAQAHAB+AgoAPgAF
AEsAAQBOQAECBgA+AAcAPAC+ABIAPwAAABoAJQAmACcAHABLAAUAAQIGAD8A
BwA8ANcARAC8CgAAbAJMAEwAIABQAEwATAAgAFAATABMACAAUAAgAFAATABM
AEwAIABQAEwATAAgAFAATABMAEwATAAgAFAATABMAAgCEABAAAAACAD/AAAA
AABAAQ8ACAIQAEEAAAAIAP8AAAAAAEABDwAIAhAAQgAAAAgA/wAAAAAAQAEP
AAgCEABDAAAACAD/AAAAAABAAQ8ACAIQAEQAAAAIAP8AAAAAAEABDwAIAhAA
RQAAAAgA/wAAAAAAQAEPAAgCEABGAAAACAD/AAAAAABAAQ8ACAIQAEcAAAAI
AP8AAAAAAEABDwAIAhAASAAAAAgA/wAAAAAAQAEPAAgCEABJAAAACAD/AAAA
AABAAQ8ACAIQAEoAAAAIAP8AAAAAAEABDwAIAhAASwAAAAgA/wAAAAAAQAEP
AAgCEABMAAAACAD/AAAAAABAAQ8ACAIQAE0AAAAIAP8AAAAAAEABDwAIAhAA
TgAAAAgA/wAAAAAAQAEPAAgCEABPAAAACAD/AAAAAABAAQ8ACAIQAFAAAAAI
AP8AAAAAAEABDwAIAhAAUQAAAAgA/wAAAAAAQAEPIAgCEABSAAAACAD/AAAA
AABAAQ8ACAIQAFMAAAAIAP8AAAAAAEABDwAIAhAAVAAAAAgA/wAAAAAAQAEP
AAgCEABVAAAACAD/AAAAAABAAQ8ACAIQAFYAAAAIAP8AAAAAAEABDwAIAhAA
VwAAAAgA/wAAAAAAQAEPAAgCEABYAAAACAD/AAAAAABAAQ8ACAIQAFkAAAAI
AP8AAAAAAEABDwAIAhAAWgAAAAgA/wAAAAAAQAEPAAgCEABbAAAACAD/AAAA
AABAAQ8ACAIQAFwAAAAIAP8AAAAAAEABDwAIAhAAXQAAAAgA/wAAAAAAQAEP
AAgCEABeAAAACAD/AAAAAABAAQ8ACAIQAF8AAAAIAP8AAAAAAEABDwC+AAoA
QAAAABoAJQABAP0ACgBAAAIAJgAgAAAAfgIKAEAAAwAnAAAASEABAgYAQAAE
ABwAfgIKAEAABQBKAAEAFEB+AgoAQAAHADwAAAAuQL4ACgBBAAAAGgAlAAEA
/QAKAEEAAgAmACEAAAB+AgoAQQADACcAAPKyQAECBgBBAAQAHAB+AgoAQQAF
AEoAAQAcQAECBgBBAAcAPAC+AAoAQgAAABoAJQABAP0ACgBCAAIAJgAiAAAA
fgIKAEIAAwAnAADWskABAgYAQgAEABwAfgIKAEIABQBKAAEACEABAgYAQgAH
ADwAvgASAEMAAAAaACUAJgAnABwASgAFAAECBgBDAAcAPAC+AAoARAAAABoA
JQABAP0ACgBEAAIAJgAjAAAAfgIKAEQAAwAnAAAAREABAgYARAAEABwAfgIK
AEQABQBKAAEAIkB+AgoARAAHADwAAAAkQL4ACgBFAAAAGgAlAAEA/QAKAEUA
AgAmADkAAAB+AgoARQADACcAABB5QAECBgBFAAQAHAB+AgoARQAFAEoAAQAI
QAECBgBFAAcAPAC+AAoARgAAABoAJQABAP0ACgBGAAIAJgAkAAAAfgIKAEYA
AwAnAACQeUABAgYARgAEABwAfgIKAEYABQBKAAEAIkABAgYARgAHADwAvgAS
AEcAAAAaACUAKAAnABwASgAFAAECBgBHAAcAPAC+AAoASAAAABoAJQABAP0A
CgBIAAIAJgAlAAAAfgIKAEgAAwAnAACAV0ABAgYASAAEABwAfgIKAEgABQBK
AAEAMEB+AgoASAAHADwAAAAuQL4ACgBJAAAAGgAlAAEA/QAKAEkAAgAmACYA
AAB+AgoASQADACcAAH/CQAECBgBJAAQAHAB+AgoASQAFAEoAAQAyQAECBgBJ
AAcAPAC+ABIASgAAABoAJQAmACcAHABKAAUAAQIGAEoABwA8AL4ACgBLAAAA
GgAlAAEA/QAKAEsAAgAmACcAAAB+AgoASwADACcAABiOQAECBgBLAAQAHAB+
AgoASwAFAEoAAQA1QH4CCgBLAAcAPAAAADlAvgASAEwAAAAaACUAJgAnABwA
SgAFAAECBgBMAAcAPAC+AAoATQAAABoAJQABAP0ACgBNAAIAJgA/AAAA/QAK
AE0AAwAnAEAAAAABAgYATQAEABwAfgIKAE0ABQBKAAEAHEB+AgoATQAHADwA
AMBSQL4AEgBOAAAAGgAlACYAJwAcAEoABQABAgYATgAHADwAvgAKAE8AAAAa
ACUAAQD9AAoATwACACYAKAAAAH4CCgBPAAMAJwAAAFVAAQIGAE8ABAAcAH4C
CgBPAAUASgABgEFAfgIKAE8ABwA8AAAASUC+AAoAUAAAABoAJQABAP0ACgBQ
AAIAJgApAAAAfgIKAFAAAwAnAICQwEABAgYAUAAEABwAfgIKAFAABQBKAAAA
REABAgYAUAAHADwAvgAOAFEAAAAaACwALQAuAAMAAQIGAFEABQBMAAECBgBR
AAcAPQC+AAoAUgAAABoAHQABAAECBgBSAAcALwC+AAoAUwAAABoAHQABAAEC
BgBTAAcALwC+AAoAVAAAABoAHQABAAECBgBUAAcALwC+AAoAVQAAABoAHQAB
AAECBgBVAAcALwC+AAoAVgAAABoAHQABAAECBgBWAAcALwC+AAoAVwAAABoA
HQABAAECBgBXAAcALwC+AAoAWAAAABoAHQABAAECBgBYAAcALwC+AAoAWQAA
ABoAHQABAAECBgBZAAcALwC+AAoAWgAAABoAHQABAAECBgBaAAcALwC+AAoA
WwAAABoAHQABAAECBgBbAAcALwC+AAoAXAAAABoAHQABAAECBgBcAAcALwC+
AAoAXQAAABoAHQABAAECBgBdAAcALwC+AAoAXgAAABoAHQABAAECBgBeAAcA
LwC+AAoAXwAAABoAHQABAAECBgBfAAcALwDXAEQAPggAAGwCUABMAEwAIABQ
AEwATAAgAFAATAAgAFAAIABQACAAUABMACYAGAAYABgAGAAYABgAGAAYABgA
GAAYABgAGAAIAhAAYAAAAAgA/wAAAAAAQAEPAAgCEABhAAAACAD/AAAAAABA
AQ8ACAIQAGIAAAAIAP8AAAAAAEABDwAIAhAAYwAAAAgA/wAAAAAAQAEPAAgC
EABkAAAACAD/AAAAAABAAQ8ACAIQAGUAAAAIAP8AAAAAAEABDwAIAhAAZgAA
AAgA/wAAAAAAQAEPAAgCEABnAAAACAD/AAAAAABAAQ8ACAIQAGgAAAAIAP8A
AAAAAEABDwAIAhAAaQAAAAgA/wAAAAAAQAEPAAgCEABqAAAACAD/AAAAAABA
AQ8ACAIQAGsAAAAIAP8AAAAAAEABDwAIAhAAbAAAAAgA/wAAAAAAQAEPAAgC
EABtAAAACAD/AAAAAABAAQ8ACAIQAG4AAAAIAP8AAAAAAEABDwAIAhAAbwAA
AAgA/wAAAAAAQAEPAAgCEABwAAAACAD/AAAAAABAAQ8ACAIQAHEAAAAIAP8A
AAAAAEABDwAIAhAAcgAAAAgA/wAAAAAAQAEPAAgCEABzAAAACAD/AAAAAABA
AQ8ACAIQAHQAAAAIAP8AAAAAAEABDwAIAhAAdQAAAAgA/wAAAAAAQAEPAAgC
EAB2AAAACAD/AAAAAABAAQ8ACAIQAHcAAAAIAP8AAAAAAEABDwAIAhAAeAAA
AAgA/wAAAAAAQAEPAAgCEAB5AAAACAD/AAAAAABAAQ8ACAIQAHoAAAAIAP8A
AAAAAEABDwAIAhAAewAAAAgA/wAAAAAAQAEPAAgCEAB8AAAACAD/AAAAAABA
AQ8ACAIQAH0AAAAIAP8AAAAAAEABDwAIAhAAfgAAAAgA/wAAAAAAQAEPAAgC
EAB/AAAACAD/AAAAAABAAQ8AvgAKAGAAAAAaAB0AAQABAgYAYAAHAC8AvgAK
AGEAAAAaAB0AAQABAgYAYQAHAC8AvgAKAGIAAAAaAB0AAQABAgYAYgAHAC8A
vgAKAGMAAAAaAB0AAQABAgYAYwAHAC8AvgAKAGQAAAAaAB0AAQABAgYAZAAH
AC8AvgAKAGUAAAAaAB0AAQABAgYAZQAHAC8AvgAKAGYAAAAaAB0AAQABAgYA
ZgAHAC8AvgAKAGcAAAAaAB0AAQABAgYAZwAHAC8AvgAKAGgAAAAaAB0AAQAB
AgYAaAAHAC8AvgAKAGkAAAAaAB0AAQABAgYAaQAHAC8AvgAKAGoAAAAaAB0A
AQABAgYAagAHAC8AvgAKAGsAAAAaAB0AAQABAgYAawAHAC8AvgAKAGwAAAAa
AB0AAQABAgYAbAAHAC8AvgAKAG0AAAAaAB0AAQABAgYAbQAHAC8AvgAKAG4A
AAAaAB0AAQABAgYAbgAHAC8AvgAKAG8AAAAaAB0AAQABAgYAbwAHAC8AvgAK
AHAAAAAaAB0AAQABAgYAcAAHAC8AvgAKAHEAAAAaAB0AAQABAgYAcQAHAC8A
vgAKAHIAAAAaAB0AAQABAgYAcgAHAC8AvgAKAHMAAAAaAB0AAQABAgYAcwAH
AC8AvgAKAHQAAAAaAB0AAQABAgYAdAAHAC8AvgAKAHUAAAAaAB0AAQABAgYA
dQAHAC8AvgAKAHYAAAAaAB0AAQABAgYAdgAHAC8AvgAKAHcAAAAaAB0AAQAB
AgYAdwAHAC8AvgAKAHgAAAAaAB0AAQABAgYAeAAHAC8AvgAKAHkAAAAaAB0A
AQABAgYAeQAHAC8AvgAKAHoAAAAaAB0AAQABAgYAegAHAC8AvgAKAHsAAAAa
AB0AAQABAgYAewAHAC8AvgAKAHwAAAAaAB0AAQABAgYAfAAHAC8AvgAKAH0A
AAAaAB0AAQABAgYAfQAHAC8AvgAKAH4AAAAaAB0AAQABAgYAfgAHAC8AvgAK
AH8AAAAaAB0AAQABAgYAfwAHAC8A1wBEAIAFAABsAhgAGAAYABgAGAAYABgA
GAAYABgAGAAYABgAGAAYABgAGAAYABgAGAAYABgAGAAYABgAGAAYABgAGAAY
ABgACAIQAIAAAAAIAP8AAAAAAEABDwAIAhAAgQAAAAgA/wAAAAAAQAEPAAgC
EACCAAAACAD/AAAAAABAAQ8ACAIQAIMAAAAIAP8AAAAAAEABDwAIAhAAhAAA
AAgA/wAAAAAAQAEPAAgCEACFAAAACAD/AAAAAABAAQ8ACAIQAIYAAAAIAP8A
AAAAAEABDwAIAhAAhwAAAAgA/wAAAAAAQAEPAAgCEACIAAAACAD/AAAAAABA
AQ8ACAIQAIkAAAAIAP8AAAAAAEABDwAIAhAAigAAAAgA/wAAAAAAQAEPAAgC
EACLAAAACAD/AAAAAABAAQ8ACAIQAIwAAAAIAP8AAAAAAEABDwAIAhAAjQAA
AAgA/wAAAAAAQAEPAAgCEACOAAAACAD/AAAAAABAAQ8ACAIQAI8AAAAIAP8A
AAAAAEABDwAIAhAAkAAAAAgA/wAAAAAAQAEPAAgCEACRAAAACAD/AAAAAABA
AQ8ACAIQAJIAAAAIAP8AAAAAAEABDwAIAhAAkwAAAAgA/wAAAAAAQAEPAAgC
EACUAAAACAD/AAAAAABAAQ8ACAIQAJUAAAAIAP8AAAAAAEABDwAIAhAAlgAA
AAgA/wAAAAAAQAEPAAgCEACXAAAACAD/AAAAAABAAQ8ACAIQAJgAAAAIAP8A
AAAAAEABDwAIAhAAmQAAAAgA/wAAAAAAQAEPAAgCEACaAAAACAD/AAAAAABA
AQ8ACAIQAJsAAAAIAP8AAAAAAEABDwAIAhAAnAAAAAgA/wAAAAAAQAEPAAgC
EACdAAAACAD/AAAAAABAAQ8ACAIQAJ4AAAAIAP8AAAAAAEABDwAIAhAAnwAA
AAgA/wAAAAAAQAEPAL4ACgCAAAAAGgAdAAEAAQIGAIAABwAvAL4ACgCBAAAA
GgAdAAEAAQIGAIEABwAvAL4ACgCCAAAAGgAdAAEAAQIGAIIABwAvAL4ACgCD
AAAAGgAdAAEAAQIGAIMABwAvAL4ACgCEAAAAGgAdAAEAAQIGAIQABwAvAL4A
CgCFAAAAGgAdAAEAAQIGAIUABwAvAL4ACgCGAAAAGgAdAAEAAQIGAIYABwAv
AL4ACgCHAAAAGgAdAAEAAQIGAIcABwAvAL4ACgCIAAAAGgAdAAEAAQIGAIgA
BwAvAL4ACgCJAAAAGgAdAAEAAQIGAIkABwAvAL4ACgCKAAAAGgAdAAEAAQIG
AIoABwAvAL4ACgCLAAAAGgAdAAEAAQIGAIsABwAvAL4ACgCMAAAAGgAdAAEA
AQIGAIwABwAvAL4ACgCNAAAAGgAdAAEAAQIGAI0ABwAvAL4ACgCOAAAAGgAd
AAEAAQIGAI4ABwAvAL4ACgCPAAAAGgAdAAEAAQIGAI8ABwAvAL4ACgCQAAAA
GgAdAAEAAQIGAJAABwAvAL4ACgCRAAAAGgAdAAEAAQIGAJEABwAvAL4ACgCS
AAAAGgAdAAEAAQIGAJIABwAvAL4ACgCTAAAAGgAdAAEAAQIGAJMABwAvAL4A
CgCUAAAAGgAdAAEAAQIGAJQABwAvAL4ACgCVAAAAGgAdAAEAAQIGAJUABwAv
AL4ACgCWAAAAGgAdAAEAAQIGAJYABwAvAL4ACgCXAAAAGgAdAAEAAQIGAJcA
BwAvAL4ACgCYAAAAGgAdAAEAAQIGAJgABwAvAL4ACgCZAAAAGgAdAAEAAQIG
AJkABwAvAL4ACgCaAAAAGgAdAAEAAQIGAJoABwAvAL4ACgCbAAAAGgAdAAEA
AQIGAJsABwAvAL4ACgCcAAAAGgAdAAEAAQIGAJwABwAvAL4ACgCdAAAAGgAd
AAEAAQIGAJ0ABwAvAL4ACgCeAAAAGgAdAAEAAQIGAJ4ABwAvAL4ACgCfAAAA
GgAdAAEAAQIGAJ8ABwAvANcARACABQAAbAIYABgAGAAYABgAGAAYABgAGAAY
ABgAGAAYABgAGAAYABgAGAAYABgAGAAYABgAGAAYABgAGAAYABgAGAAYAAgC
EACgAAAACAD/AAAAAABAAQ8ACAIQAKEAAAAIAP8AAAAAAEABDwAIAhAAogAA
AAgA/wAAAAAAQAEPAAgCEACjAAAACAD/AAAAAABAAQ8ACAIQAKQAAAAIAP8A
AAAAAEABDwAIAhAApQAAAAgA/wAAAAAAQAEPAAgCEACmAAAACAD/AAAAAABA
AQ8ACAIQAKcAAAAIAP8AAAAAAEABDwAIAhAAqAAAAAgA/wAAAAAAQAEPAAgC
EACpAAAACAD/AAAAAABAAQ8ACAIQAKoAAAAIAP8AAAAAAEABDwAIAhAAqwAA
AAgA/wAAAAAAQAEPAAgCEACsAAAACAD/AAAAAABAAQ8ACAIQAK0AAAAIAP8A
AAAAAEABDwAIAhAArgAAAAgA/wAAAAAAQAEPAAgCEACvAAAACAD/AAAAAABA
AQ8ACAIQALAAAAAIAP8AAAAAAEABDwAIAhAAsQAAAAgA/wAAAAAAQAEPAAgC
EACyAAAACAD/AAAAAABAAQ8ACAIQALMAAAAIAP8AAAAAAEABDwAIAhAAtAAA
AAgA/wAAAAAAQAEPAAgCEAC1AAAACAD/AAAAAABAAQ8ACAIQALYAAAAIAP8A
AAAAAEABDwAIAhAAtwAAAAgA/wAAAAAAQAEPAAgCEAC4AAAACAD/AAAAAABA
AQ8ACAIQALkAAAAIAP8AAAAAAEABDwAIAhAAugAAAAgA/wAAAAAAQAEPAAgC
EAC7AAAACAD/AAAAAABAAQ8ACAIQALwAAAAIAP8AAAAAAEABDwAIAhAAvQAA
AAgA/wAAAAAAQAEPAAgCEAC+AAAACAD/AAAAAABAAQ8ACAIQAL8AAAAIAP8A
AAAAAEABDwC+AAoAoAAAABoAHQABAAECBgCgAAcALwC+AAoAoQAAABoAHQAB
AAECBgChAAcALwC+AAoAogAAABoAHQABAAECBgCiAAcALwC+AAoAowAAABoA
HQABAAECBgCjAAcALwC+AAoApAAAABoAHQABAAECBgCkAAcALwC+AAoApQAA
ABoAHQABAAECBgClAAcALwC+AAoApgAAABoAHQABAAECBgCmAAcALwC+AAoA
pwAAABoAHQABAAECBgCnAAcALwC+AAoAqAAAABoAHQABAAECBgCoAAcALwC+
AAoAqQAAABoAHQABAAECBgCpAAcALwC+AAoAqgAAABoAHQABAAECBgCqAAcA
LwC+AAoAqwAAABoAHQABAAECBgCrAAcALwC+AAoArAAAABoAHQABAAECBgCs
AAcALwC+AAoArQAAABoAHQABAAECBgCtAAcALwC+AAoArgAAABoAHQABAAEC
BgCuAAcALwC+AAoArwAAABoAHQABAAECBgCvAAcALwC+AAoAsAAAABoAHQAB
AAECBgCwAAcALwC+AAoAsQAAABoAHQABAAECBgCxAAcALwC+AAoAsgAAABoA
HQABAAECBgCyAAcALwC+AAoAswAAABoAHQABAAECBgCzAAcALwABAgYAtAAB
AB4AAQIGALQABwAvAAECBgC1AAEAHgABAgYAtQAHAC8AAQIGALYAAQAeAAEC
BgC2AAcALwABAgYAtwABAB4AAQIGALcABwAvAAECBgC4AAEAHgABAgYAuAAH
AC8AAQIGALkAAQAeAAECBgC5AAcALwABAgYAugABAB4AAQIGALoABwAvAAEC
BgC7AAEAHgABAgYAuwAHAC8AAQIGALwAAQAeAAECBgC8AAcALwABAgYAvQAB
AB4AAQIGAL0ABwAvAAECBgC+AAEAHgABAgYAvgAHAC8AAQIGAL8AAQAeAAEC
BgC/AAcALwDXAEQAUAUAAGwCGAAYABgAGAAYABgAGAAYABgAGAAYABgAGAAY
ABgAGAAYABgAGAAYABQAFAAUABQAFAAUABQAFAAUABQAFAAIAhAAwAABAAgA
/wAAAAAAQAEPAAgCEADBAAEACAD/AAAAAABAAQ8ACAIQAMIAAQAIAP8AAAAA
AEABDwAIAhAAwwABAAgA/wAAAAAAQAEPAAgCEADEAAEACAD/AAAAAABAAQ8A
CAIQAMUAAQAIAP8AAAAAAEABDwAIAhAAxgABAAgA/wAAAAAAQAEPAAgCEADH
AAEACAD/AAAAAABAAQ8ACAIQAMgAAQAIAP8AAAAAAEABDwAIAhAAyQABAAgA
/wAAAAAAQAEPAAgCEADKAAEACAD/AAAAAABAAQ8ACAIQAMsAAQAIAP8AAAAA
AEABDwAIAhAAzAABAAgA/wAAAAAAQAEPAAgCEADNAAEACAD/AAAAAABAAQ8A
CAIQAM4AAQAIAP8AAAAAAEABDwAIAhAAzwABAAgA/wAAAAAAQAEPAAgCEADQ
AAEAAgD/AAAAAABAAQ8ACAIQANEAAQACAP8AAAAAAEABDwAIAhAA0gABAAIA
/wAAAAAAQAEPAAgCEADTAAEAAgD/AAAAAABAAQ8ACAIQANQAAQACAP8AAAAA
AEABDwAIAhAA1QABAAIA/wAAAAAAQAEPAAgCEADWAAEAAgD/AAAAAABAAQ8A
CAIQANcAAQACAP8AAAAAAEABDwAIAhAA2AABAAIA/wAAAAAAQAEPAAgCEADZ
AAEAAgD/AAAAAABAAQ8ACAIQANoAAQACAP8AAAAAAEABDwAIAhAA2wABAAIA
/wAAAAAAQAEPAAgCEADcAAEAAgD/AAAAAABAAQ8ACAIQAN0AAQACAP8AAAAA
AEABDwABAgYAwAABAB4AAQIGAMAABwAvAAECBgDBAAEAHgABAgYAwQAHAC8A
AQIGAMIAAQAeAAECBgDCAAcALwABAgYAwwABAB4AAQIGAMMABwAvAAECBgDE
AAEAHgABAgYAxAAHAC8AAQIGAMUAAQAeAAECBgDFAAcALwABAgYAxgABAB4A
AQIGAMYABwAvAAECBgDHAAEAHgABAgYAxwAHAC8AAQIGAMgAAQAeAAECBgDI
AAcALwABAgYAyQABAB4AAQIGAMkABwAvAAECBgDKAAEAHgABAgYAygAHAC8A
AQIGAMsAAQAeAAECBgDMAAEAHgABAgYAzQABAB4AAQIGAM4AAQAeAAECBgDP
AAEAHgABAgYA0AABAB4A1wBAAHADAABEAhQAFAAUABQAFAAUABQAFAAUABQA
FAAKAAoACgAKAAoACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+AhIAvgcA
AAIAQAAAAGQAXwAAAAAAoAAEAAQABQBBAAoAAAAIAC8AQAACAB0ADwADAAAA
AAAAAQAAAAAAAAAdAA8AAisABwAAAAEAKwArAAcH5QAKAAEABQAFAAEAAgDv
AAYAAAA3AAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAA
AAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAMwAAAAIAAAAAQAAAEgAAAAEAAAA
UAAAAAgAAABsAAAAEgAAAIgAAAALAAAAoAAAAAwAAACsAAAADQAAALgAAAAT
AAAAxAAAAAIAAADkBAAAHgAAABIAAABFdmdlbnkgTC4gS2FsaW5pbgBlAB4A
AAASAAAARXZnZW55IEwuIEthbGluaW4AZQAeAAAAEAAAAE1pY3Jvc29mdCBF
eGNlbABAAAAAgJLuKSlcwQFAAAAAABKIVGvywAFAAAAAALTwQSz3wQEDAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAA
AAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAADoAAAACQAAAAEAAABQAAAADwAA
AFgAAAAXAAAAgAAAAAsAAACIAAAAEAAAAJAAAAATAAAAmAAAABYAAACgAAAA
DQAAAKgAAAAMAAAAwgAAAAIAAADkBAAAHgAAAB0AAABBdXJvcmEgR2xvYmFs
IFNvbHV0aW9ucyBTLkEuADIwMAMAAADtDgkACwAAAAAAAAALAAAAAAAAAAsA
AAAAAAAACwAAAAAAAAAeEAAAAQAAAA4AAAAyNiBNYXJjaCAyMDAyAAwQAAAC
AAAAHgAAAAsAAABXb3Jrc2hlZXRzAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAG
AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEA
AAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAA
AB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAA
/v///ykAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAD+////MQAAADIAAAAz
AAAANAAAADUAAAA2AAAANwAAAP7////9/////v//////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////9SAG8A
bwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAFgAFAf//////////AgAAACAIAgAAAAAAwAAAAAAA
AEYAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAAAFcAbwByAGsAYgBv
AG8AawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAASAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAHBPAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkA
bgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACgAAgEBAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAoAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBt
AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf//
/////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ADAAAAAAEAAAAAAAAA==

--= Multipart Boundary 0509021300--

From rsparks@dynamicsoft.com  Fri May 10 09:35:48 2002
Received: from crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17022
	for ; Fri, 10 May 2002 09:35:48 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4ADceV00772
	for ; Fri, 10 May 2002 08:38:40 -0500
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Date: 10 May 2002 08:34:35 -0500
Message-Id: <1021037675.1186.3.camel@dhcp152.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 84
Subject: [Simple] administrivia : termination post
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: 

Grr - I fumbled in the approval interface letting that one through.

Sorry.

RjS




From wayne.carr@intel.com  Fri May 10 13:55:01 2002
Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17761
	for ; Fri, 10 May 2002 13:55:00 -0400 (EDT)
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by hebe.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.38 2002/05/09 18:12:41 root Exp $) with SMTP id g4AHrpI05119
	for ; Fri, 10 May 2002 17:53:51 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26])
 by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002051011013417842
 ; Fri, 10 May 2002 11:01:34 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 10 May 2002 10:53:50 -0700
Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C283@orsmsx120.jf.intel.com>
From: "Carr, Wayne" 
To: "'Hiroyasu Sugano'" ,
        Paul Kyzivat, bateman@acm.org
Cc: "Carr, Wayne" , simple@mailman.dynamicsoft.com,
        impp@iastate.edu
Date: Fri, 10 May 2002 10:53:48 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1376
Subject: [Simple] RE: priority range in PIDF
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: 

I'll send out an updated schema in a few minutes.  We also need to change
the text so high priority is higher values (not lower like it is now).

Section 4.1.5.  
Old wording: "The value of the attribute MUST be an integer ranged from 0 to
255 and the smaller integer means the higher priority."  
Suggested new wording: "The value of the attribute MUST be an decimal number
between 0 and 1 inclusive with at most 3 digits after the decimal point.
Higher values indicate higher priority.  Examples of priority values are 0,
0.021, 0.5, 1.00" 

 

> -----Original Message-----
> From: Hiroyasu Sugano [mailto:suga@flab.fujitsu.co.jp]
> Sent: Thursday, May 09, 2002 10:48 PM
> To: Paul Kyzivat; bateman@acm.org
> Cc: 'Carr, Wayne'; simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: Re: priority range in PIDF
> 
> 
> Paul Kyzivat wrote:
> > Adrian Bateman wrote:
> > >
> > > My preference would be toward the integer value (I'm just happier
> > > dealing with integers) but I don't have any substantial 
> objections to
> > > the alternative.
> >
> > Just to be contrarian, I would prefer the decimal form for 
> consistency with sip &
> http, but don't have an substantial objection to integers in 
> range [0,1000].
> 
> I'm okay to go with the way of SIP and HTTP if there is no 
> substantial objection to
> it.
> Any counter arguments?
> 
> -- Hiroyasu Sugano
> 

From bcampbell@dynamicsoft.com  Mon May 13 15:17:53 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02022
	for ; Mon, 13 May 2002 15:17:52 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4DJGbX11506;
	Mon, 13 May 2002 14:16:37 -0500 (CDT)
From: "Ben Campbell" 
To: "Sip" , "Simple" 
Cc: "Robert Sparks" ,
        "Jon Peterson" ,
        "Dean Willis" ,
        "Brian. Rosen@Marconi. Com" ,
        "Jo@Ipdialog. Com" 
Date: Mon, 13 May 2002 14:16:26 -0500
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
Content-Length: 1152
Subject: [Simple] Message draft changes
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: 

Hi all,

I submitted draft-ietf-sip-message-04 last week. This version contains a few
AD requested changes, primarily in the area of congestion control.
Specifically:

1) Added an applicability statement clarifying the difference between the
pager and session models, and that this draft only defines the pager model.

2) Strengthened the congestion control section:

   * 1300 byte hard limit for physical payload size for pager model. This
applies to the actual payload only, not indirect content. Fragmenting
content across multiple requests is prohibited for pager model.

   * Overlapping MESSAGE requests outside of dialog but to same request-URI
are prohibited.
   * Overlapping MESSAGE requests inside a dialog are prohibited unless
every hop of the dialog uses a congestion-controlled transport, in which
case the strength is SHOULD NOT.

3) Trimmed the author list and added contributor section.

I do not believe we need to do another WGLC for these changes. Any new
feedback to 04 can be captured as part of the IETF last call.

The draft is available at:

http://www.ietf.org/internet-drafts/draft-ietf-sip-message-04.txt

Thanks!

Ben.



From jdrosen@dynamicsoft.com  Mon May 13 17:07:25 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02400
	for ; Mon, 13 May 2002 17:07:25 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.182])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4DL7hYH007427;
	Mon, 13 May 2002 17:07:43 -0400 (EDT)
Message-ID: <3CE02AC4.E1002C25@dynamicsoft.com>
Date: Mon, 13 May 2002 17:06:12 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Campbell 
CC: Tony Hansen , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Status summary
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3624
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: 

This thread stalled, but I think we need to pick it up again.

The main issue we have to answer with status values are what kinds of
things would an automata do with them, which would require that they
have some kind of standardized meaning, as opposed to just a freeform
note meant for human consumption. Some things that have come up on the
lists:

* map to an icon (mapping is a local matter)
* present to the user in their language (could alternatively be done by
translating the note value, but I think its more robust if there is a
defined set of values)
* decide whether or not to forward a call to the user
* decide whether or not the user is available for an automatically
created conference call

all of the above are either impossible without, or much enhanced by,
well defined meanings for a set of attributes. Of course you can always
define more later on, but I still feel that a reasonably well defined
set is a useful thing.

-Jonathan R.

Ben Campbell wrote:
> 
> It seems to me this concept is still more intended for _human_
> consumption.
> It would be dangerous to provide any protocol semantic or other
> automatic
> processing based on the assumption that I will be back at a certain
> time,
> unless we build in explicit expiration times for the piece of state.
> 
> So, all of the following can be handled by some sort of "away" status
> that
> contains a human readable comment (or some other indicator for user
> display
> purposes only).
> 
> > -----Original Message-----
> > From: simple-admin@mailman.dynamicsoft.com
> > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Tony Hansen
> > Sent: Wednesday, April 17, 2002 1:15 PM
> > Cc: simple@mailman.dynamicsoft.com; impp@iastate.edu
> > Subject: Re: [Simple] Status summary
> >
> >
> > One aspect that hasn't come up yet in this conversation is something
> > someone said at the ad-hoc mtg in MN: the temporal aspect of the
> various
> > types of OPEN status messages. Why do you choose to use one message
> over
> > another? Usually it's to give the others an idea of how quickly you'll
> > respond.
> >
> > Some of them mean "I'm doing stuff, but will probably respond to your
> > message pretty quickly." (T = a couple minutes) Examples: Busy, On the
> > Phone.
> >
> > Some of them mean "I'm going to be gone for a while." (T = 1/2 - 1
> hour)
> > Example: Out to Lunch.
> >
> > Some of them mean "Don't expect me to respond for hours." (T = 2-4
> > hours) Example: Away, In Meetings.
> >
> > Some of them mean "Don't expect me back for a long time." (T > 4
> hours)
> > Example: Out for the weekend.
> >
> > When you go international, Out to Lunch doesn't mean a whole lot to
> > anyone but English speakers. But specifying an expected time to be
> gone
> > set at .5-1 hour certainly does translate well. Time is a pretty
> > universal concept, and might be worth codifying as part of the status
> > information.
> >
> >       Tony Hansen
> >       tony@att.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

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From hgs@cs.columbia.edu  Mon May 13 19:17:01 2002
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 TAA02788
	for ; Mon, 13 May 2002 19:17:00 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA20429;
	Mon, 13 May 2002 19:15:40 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4DNFd2i023712
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 13 May 2002 19:15:40 -0400 (EDT)
Message-ID: <3CE0490B.1080506@cs.columbia.edu>
Date: Mon, 13 May 2002 19:15:23 -0400
From: Henning Schulzrinne 
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: Ben Campbell , Tony Hansen ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Status summary
References:  <3CE02AC4.E1002C25@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 4847
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: 

Is there a candidate set that we can draw on? One additional 
consideration is that it would be nice if there were trivial mappings to 
existing widely-used systems, as gatewaying will presumably be common 
until SIMPLE remains the only protocol in existence :-)

 From the survey of existing systems, we have:

Busy (MSN, Yahoo)
Away (AT&T, MSN, Jabber, AOL)
Be right back (AT&T, MSN)
Do not disturb (Jabber, AT&T)
on the phone (AT&T, MSN, Yahoo)
out to lunch (MSN, Yahoo)
Extended away (Jabber)
Not at home/desk/office (Yahoo)
Stepped out (Yahoo)
Idle (AOL)
Be right back (Yahoo)
Free (presumably all of them)

"Busy" and "do not disturb" seem to be similar.

Once you have "out to lunch", you probably need the other meals, too, 
with suitable locale reflecting siesta, afternoon Kaffee, and similar 
activities. This is also not likely to translate well.

"Away", "extended away", "not at my X" also appear difficult to 
distinguish, unless you have some indication as to how long this status 
has been in effect. (Classical residual waiting time problem.)

I can't quite figure out the difference between "Idle" and "Away". AOL 
sets the status to Idle if somebody hasn't been typing for 10 minutes, 
so maybe this is just an automated "Away".

Thus, this seems like a pretty simple exercise for a minimal set:
- Away (with suitable textual indication, as to lunch, dinner, vacation, 
prison, afterlife, or whatever)
- Idle (maybe)
- Busy
- On the phone
- Free

Jonathan Rosenberg wrote:
> This thread stalled, but I think we need to pick it up again.
> 
> The main issue we have to answer with status values are what kinds of
> things would an automata do with them, which would require that they
> have some kind of standardized meaning, as opposed to just a freeform
> note meant for human consumption. Some things that have come up on the
> lists:
> 
> * map to an icon (mapping is a local matter)
> * present to the user in their language (could alternatively be done by
> translating the note value, but I think its more robust if there is a
> defined set of values)
> * decide whether or not to forward a call to the user
> * decide whether or not the user is available for an automatically
> created conference call
> 
> all of the above are either impossible without, or much enhanced by,
> well defined meanings for a set of attributes. Of course you can always
> define more later on, but I still feel that a reasonably well defined
> set is a useful thing.
> 
> -Jonathan R.
> 
> Ben Campbell wrote:
> 
>>It seems to me this concept is still more intended for _human_
>>consumption.
>>It would be dangerous to provide any protocol semantic or other
>>automatic
>>processing based on the assumption that I will be back at a certain
>>time,
>>unless we build in explicit expiration times for the piece of state.
>>
>>So, all of the following can be handled by some sort of "away" status
>>that
>>contains a human readable comment (or some other indicator for user
>>display
>>purposes only).
>>
>>
>>>-----Original Message-----
>>>From: simple-admin@mailman.dynamicsoft.com
>>>[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Tony Hansen
>>>Sent: Wednesday, April 17, 2002 1:15 PM
>>>Cc: simple@mailman.dynamicsoft.com; impp@iastate.edu
>>>Subject: Re: [Simple] Status summary
>>>
>>>
>>>One aspect that hasn't come up yet in this conversation is something
>>>someone said at the ad-hoc mtg in MN: the temporal aspect of the
>>
>>various
>>
>>>types of OPEN status messages. Why do you choose to use one message
>>
>>over
>>
>>>another? Usually it's to give the others an idea of how quickly you'll
>>>respond.
>>>
>>>Some of them mean "I'm doing stuff, but will probably respond to your
>>>message pretty quickly." (T = a couple minutes) Examples: Busy, On the
>>>Phone.
>>>
>>>Some of them mean "I'm going to be gone for a while." (T = 1/2 - 1
>>
>>hour)
>>
>>>Example: Out to Lunch.
>>>
>>>Some of them mean "Don't expect me to respond for hours." (T = 2-4
>>>hours) Example: Away, In Meetings.
>>>
>>>Some of them mean "Don't expect me back for a long time." (T > 4
>>
>>hours)
>>
>>>Example: Out for the weekend.
>>>
>>>When you go international, Out to Lunch doesn't mean a whole lot to
>>>anyone but English speakers. But specifying an expected time to be
>>
>>gone
>>
>>>set at .5-1 hour certainly does translate well. Time is a pretty
>>>universal concept, and might be worth codifying as part of the status
>>>information.
>>>
>>>      Tony Hansen
>>>      tony@att.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 tony@att.com  Mon May 13 20:45:38 2002
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03071
	for ; Mon, 13 May 2002 20:45:38 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g4E0iS6m018564
	for ; Mon, 13 May 2002 19:44:28 -0500 (CDT)
Received: from att.com ([135.210.83.15])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020514004426gw100aipd8e>
          (Authid: tony);
          Tue, 14 May 2002 00:44:27 +0000
Message-ID: <3CE05D8B.6050906@att.com>
Date: Mon, 13 May 2002 20:42:51 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Status summary
References:  <3CE02AC4.E1002C25@dynamicsoft.com> <3CE0490B.1080506@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2283
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: 

Henning Schulzrinne wrote:

> Is there a candidate set that we can draw on? One additional 
> consideration is that it would be nice if there were trivial mappings to 
> existing widely-used systems, as gatewaying will presumably be common 
> until SIMPLE remains the only protocol in existence :-)
> 
>  From the survey of existing systems, we have:
> 
> Busy (MSN, Yahoo)
> Away (AT&T, MSN, Jabber, AOL)
> Be right back (AT&T, MSN)
> Do not disturb (Jabber, AT&T)
> on the phone (AT&T, MSN, Yahoo)
> out to lunch (MSN, Yahoo)
> Extended away (Jabber)
> Not at home/desk/office (Yahoo)
> Stepped out (Yahoo)
> Idle (AOL)
> Be right back (Yahoo)
> Free (presumably all of them)
> 
> "Busy" and "do not disturb" seem to be similar.
> 
> Once you have "out to lunch", you probably need the other meals, too, 
> with suitable locale reflecting siesta, afternoon Kaffee, and similar 
> activities. This is also not likely to translate well.
> 
> "Away", "extended away", "not at my X" also appear difficult to 
> distinguish, unless you have some indication as to how long this status 
> has been in effect. (Classical residual waiting time problem.)
> 
> I can't quite figure out the difference between "Idle" and "Away". AOL 
> sets the status to Idle if somebody hasn't been typing for 10 minutes, 
> so maybe this is just an automated "Away".


AT&T, MSN and Yahoo all have the option of automatically setting the 
option to a status such as Away or Idle after a certain amount of 
idleness has passed.


> Thus, this seems like a pretty simple exercise for a minimal set:
> - Away (with suitable textual indication, as to lunch, dinner, vacation, 
> prison, afterlife, or whatever)
> - Idle (maybe)
> - Busy
> - On the phone

> - Free


Your "on the phone" is just another version of Busy.

I see the following set:

	Free (Available)
	Busy
	Away, for an
		indeterminate amount of time
		short time
		long time

Each could also be annotated with additional text.

Busy means "I'm doing stuff, so may not respond right away. Annotations 
for Busy would be things such as "On the phone" and "In a meeting".

The time based settings are purely subjective values, not concrete 
values. The indeterminate time would be appropriate for use by an idle 
timer.

	Tony Hansen
	tony@att.com


From hgs@cs.columbia.edu  Mon May 13 20:54:23 2002
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 UAA03127
	for ; Mon, 13 May 2002 20:54:22 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA26229;
	Mon, 13 May 2002 20:53:12 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4E0rB2i026910
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 13 May 2002 20:53:11 -0400 (EDT)
Message-ID: <3CE05FE7.2090904@cs.columbia.edu>
Date: Mon, 13 May 2002 20:52:55 -0400
From: Henning Schulzrinne 
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Hansen 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Status summary
References:  <3CE02AC4.E1002C25@dynamicsoft.com> <3CE0490B.1080506@cs.columbia.edu> <3CE05D8B.6050906@att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1149
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: 

> Your "on the phone" is just another version of Busy.

Agreed; the only reason I kept it separate is that a SIP device may know 
this condition specifically. It might be useful to have a two-level 
hierarchy of labels, as in busy.phone and busy.meeting.

> 
> I see the following set:
> 
>     Free (Available)
>     Busy
>     Away, for an
>         indeterminate amount of time
>         short time
>         long time
> 
> Each could also be annotated with additional text.
> 
> Busy means "I'm doing stuff, so may not respond right away. Annotations 
> for Busy would be things such as "On the phone" and "In a meeting".
> 
> The time based settings are purely subjective values, not concrete 
> values. The indeterminate time would be appropriate for use by an idle 
> timer.

It would be nice to be able to provide an explicit time of return. With 
calendar integration, this wouldn't be too hard. Obviously, this would 
be optional.

> 
>     Tony Hansen
>     tony@att.com
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple



From AVSHALOM@il.ibm.com  Tue May 14 04:22:05 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04361
	for ; Tue, 14 May 2002 04:22:05 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4E8KMGV057298;
	Tue, 14 May 2002 10:20:22 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4E8KEH151662;
	Tue, 14 May 2002 10:20:17 +0200
To: simple@mailman.dynamicsoft.com, Henning Schulzrinne 
MIME-Version: 1.0
Subject: Re: [Simple] Status summary
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Tue, 14 May 2002 11:20:36 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 14/05/2002 11:20:21,
	Serialize complete at 14/05/2002 11:20:21
Content-Type: multipart/alternative; boundary="=_alternative 002DD78BC2256BB9_="
Content-Length: 6183
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: 

This is a multipart message in MIME format.
--=_alternative 002DD78BC2256BB9_=
Content-Type: text/plain; charset="us-ascii"

It seems that there is a place for another state - Do Not Disturb (DND).
DND means that although I am online messages sent to me will not reach me.
Thus, the blocking of the messages can be done in the client of the 
originator.

So the states that we will have are:
* Free (Available)
* Busy (Open but I am busy)
* DND (Closed for communication)
* Away, for an
    indeterminate amount of time (used also by automatic away sensed by 
the client)
    short time (set manually)
    long time (set manually)

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group





Henning Schulzrinne 
Sent by: simple-admin@mailman.dynamicsoft.com
14/05/2002 03:52
Please respond to Henning Schulzrinne

 
        To:        Tony Hansen 
        cc:        simple@mailman.dynamicsoft.com
        Subject:        Re: [Simple] Status summary

 

> Your "on the phone" is just another version of Busy.

Agreed; the only reason I kept it separate is that a SIP device may know 
this condition specifically. It might be useful to have a two-level 
hierarchy of labels, as in busy.phone and busy.meeting.

> 
> I see the following set:
> 
>     Free (Available)
>     Busy
>     Away, for an
>         indeterminate amount of time
>         short time
>         long time
> 
> Each could also be annotated with additional text.
> 
> Busy means "I'm doing stuff, so may not respond right away. Annotations 
> for Busy would be things such as "On the phone" and "In a meeting".
> 
> The time based settings are purely subjective values, not concrete 
> values. The indeterminate time would be appropriate for use by an idle 
> timer.

It would be nice to be able to provide an explicit time of return. With 
calendar integration, this wouldn't be too hard. Obviously, this would 
be optional.

> 
>     Tony Hansen
>     tony@att.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



--=_alternative 002DD78BC2256BB9_=
Content-Type: text/html; charset="us-ascii"



It seems that there is a place for another state - Do Not Disturb (DND).

DND means that although I am online messages sent to me will not reach me.

Thus, the blocking of the messages can be done in the client of the originator.



So the states that we will have are:

* Free (Available)

* Busy (Open but I am busy)

* DND (Closed for communication)

* Away, for an

    indeterminate amount of time (used also by automatic away sensed by the client)

    short time (set manually)

    long time (set manually)



Avshalom Houri

Presence and Instant Messaging Architect

Lotus Sametime, IBM Software Group













Henning Schulzrinne <hgs@cs.columbia.edu>

Sent by: simple-admin@mailman.dynamicsoft.com

14/05/2002 03:52

Please respond to Henning Schulzrinne



        

        To:        Tony Hansen <tony@att.com>

        cc:        simple@mailman.dynamicsoft.com

        Subject:        Re: [Simple] Status summary



       




> Your "on the phone" is just another version of Busy.



Agreed; the only reason I kept it separate is that a SIP device may know 

this condition specifically. It might be useful to have a two-level 

hierarchy of labels, as in busy.phone and busy.meeting.



> 

> I see the following set:

> 

>     Free (Available)

>     Busy

>     Away, for an

>         indeterminate amount of time

>         short time

>         long time

> 

> Each could also be annotated with additional text.

> 

> Busy means "I'm doing stuff, so may not respond right away. Annotations 

> for Busy would be things such as "On the phone" and "In a meeting".

> 

> The time based settings are purely subjective values, not concrete 

> values. The indeterminate time would be appropriate for use by an idle 

> timer.



It would be nice to be able to provide an explicit time of return. With 

calendar integration, this wouldn't be too hard. Obviously, this would 

be optional.



> 

>     Tony Hansen

>     tony@att.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






--=_alternative 002DD78BC2256BB9_=--

From mhammer@cisco.com  Tue May 14 10:42:45 2002
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 KAA05376
	for ; Tue, 14 May 2002 10:42:45 -0400 (EDT)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EEfPNq003062;
	Tue, 14 May 2002 10:41:25 -0400 (EDT)
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 AAV88476;
	Tue, 14 May 2002 10:35:57 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020514102804.00b07408@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 14 May 2002 10:38:17 -0400
To: "Avshalom Houri" 
From: Michael Hammer 
Subject: Re: [Simple] Status summary
Cc: simple@mailman.dynamicsoft.com, Henning Schulzrinne 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Content-Length: 5029
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: 


Avshalom,



So what is the difference between a busy and a DND?  Some of this
seems to boil down to the explicit not available (Busy, DND) and the
implicit (Away).  So essentially there is:



Closed-permanent (Explicit:  De-registration)

Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)

Open-Active      (Implicit:  Actively
using)

Open-Inactive    (Implicit:  Away so Maybe).



One last comment:  Since some of this may reveal presence, it may be
a good idea to recommend a default that must be manually over-ridden to
allow that type of information to be sent (protect privacy).



Mike



At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:




It seems that there is a
place for another state - Do Not Disturb (DND). 


DND means that although I am online messages sent to
me will not reach me. 

Thus, the blocking of the messages can be done in the
client of the originator. 



So the states that we will have
are: 

* Free (Available)

* Busy (Open but I am busy)

* DND (Closed for communication) 

* Away, for an

   indeterminate amount of time (used also by automatic away
sensed by the client)

   short time (set manually)

   long time (set manually) 



Avshalom Houri 

Presence and Instant Messaging
Architect 

Lotus Sametime, IBM Software
Group 







Henning Schulzrinne
<hgs@cs.columbia.edu> 

Sent by:
simple-admin@mailman.dynamicsoft.com 



14/05/2002 03:52 

Please respond to Henning
Schulzrinne 

       


       
To:        Tony Hansen
<tony@att.com> 

       
cc:       
simple@mailman.dynamicsoft.com 

       
Subject:        Re: [Simple] Status
summary 



      
 



> Your "on the phone" is just another
version of Busy.



Agreed; the only reason I kept it separate is that a SIP device may know


this condition specifically. It might be useful to have a two-level 


hierarchy of labels, as in busy.phone and busy.meeting.



> 

> I see the following set:

> 

>     Free (Available)

>     Busy

>     Away, for an

>         indeterminate amount
of time

>         short time

>         long time

> 

> Each could also be annotated with additional text.

> 

> Busy means "I'm doing stuff, so may not respond right away.
Annotations 

> for Busy would be things such as "On the phone" and
"In a meeting".

> 

> The time based settings are purely subjective values, not concrete


> values. The indeterminate time would be appropriate for use by an
idle 

> timer.



It would be nice to be able to provide an explicit time of return. With


calendar integration, this wouldn't be too hard. Obviously, this would


be optional.



> 

>     Tony Hansen

>     tony@att.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 mhammer@cisco.com  Tue May 14 10:43:52 2002
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 KAA05397
	for ; Tue, 14 May 2002 10:43:51 -0400 (EDT)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EEgac1003163;
	Tue, 14 May 2002 10:42:36 -0400 (EDT)
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 AAV88488;
	Tue, 14 May 2002 10:37:08 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020514104136.00ba6f08@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 14 May 2002 10:42:04 -0400
To: "Avshalom Houri" 
From: Michael Hammer 
Subject: Re: [Simple] Status summary
Cc: simple@mailman.dynamicsoft.com, Henning Schulzrinne 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 2986
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: 

Try again hitting the right button.

Avshalom,

So what is the difference between a busy and a DND?  Some of this seems to 
boil down to the explicit not available (Busy, DND) and the implicit 
(Away).  So essentially there is:

Closed-permanent (Explicit:  De-registration)
Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)
Open-Active      (Implicit:  Actively using)
Open-Inactive    (Implicit:  Away so Maybe).

One last comment:  Since some of this may reveal presence, it may be a good 
idea to recommend a default that must be manually over-ridden to allow that 
type of information to be sent (protect privacy).

Mike


At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:

>It seems that there is a place for another state - Do Not Disturb (DND).
>DND means that although I am online messages sent to me will not reach me.
>Thus, the blocking of the messages can be done in the client of the 
>originator.
>
>So the states that we will have are:
>* Free (Available)
>* Busy (Open but I am busy)
>* DND (Closed for communication)
>* Away, for an
>    indeterminate amount of time (used also by automatic away sensed by 
> the client)
>    short time (set manually)
>    long time (set manually)
>
>Avshalom Houri
>Presence and Instant Messaging Architect
>Lotus Sametime, IBM Software Group
>
>
>
>Henning Schulzrinne 
>Sent by: simple-admin@mailman.dynamicsoft.com
>
>14/05/2002 03:52
>Please respond to Henning Schulzrinne
>
>         To:        Tony Hansen 
>         cc:        simple@mailman.dynamicsoft.com
>         Subject:        Re: [Simple] Status summary
>
>
>
> > Your "on the phone" is just another version of Busy.
>
>Agreed; the only reason I kept it separate is that a SIP device may know
>this condition specifically. It might be useful to have a two-level
>hierarchy of labels, as in busy.phone and busy.meeting.
>
> >
> > I see the following set:
> >
> >     Free (Available)
> >     Busy
> >     Away, for an
> >         indeterminate amount of time
> >         short time
> >         long time
> >
> > Each could also be annotated with additional text.
> >
> > Busy means "I'm doing stuff, so may not respond right away. Annotations
> > for Busy would be things such as "On the phone" and "In a meeting".
> >
> > The time based settings are purely subjective values, not concrete
> > values. The indeterminate time would be appropriate for use by an idle
> > timer.
>
>It would be nice to be able to provide an explicit time of return. With
>calendar integration, this wouldn't be too hard. Obviously, this would
>be optional.
>
> >
> >     Tony Hansen
> >     tony@att.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 AVSHALOM@il.ibm.com  Tue May 14 11:05:51 2002
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05539
	for ; Tue, 14 May 2002 11:05:51 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4EF4L31058402;
	Tue, 14 May 2002 17:04:22 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4EF4K980302;
	Tue, 14 May 2002 17:04:21 +0200
To: Michael Hammer 
Cc: Henning Schulzrinne , simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Subject: Re: [Simple] Status summary
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Tue, 14 May 2002 18:04:21 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 14/05/2002 18:04:21,
	Serialize complete at 14/05/2002 18:04:21
Content-Type: multipart/alternative; boundary="=_alternative 0052CE8AC2256BB9_="
Content-Length: 10416
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: 

This is a multipart message in MIME format.
--=_alternative 0052CE8AC2256BB9_=
Content-Type: text/plain; charset="us-ascii"

I understood busy as an hint that means that I am busy so please disturb 
me only if it is a urgent issue. So it is Open-Active while DND is 
Closed-Active.

Avshalom





Michael Hammer 
14/05/2002 17:38
Please respond to Michael Hammer

 
        To:        Avshalom Houri/Haifa/IBM@IBMIL
        cc:        simple@mailman.dynamicsoft.com, Henning Schulzrinne 
        Subject:        Re: [Simple] Status summary

 

Avshalom,

So what is the difference between a busy and a DND?  Some of this seems to 
boil down to the explicit not available (Busy, DND) and the implicit 
(Away).  So essentially there is:

Closed-permanent (Explicit:  De-registration)
Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)
Open-Active      (Implicit:  Actively using)
Open-Inactive    (Implicit:  Away so Maybe).

One last comment:  Since some of this may reveal presence, it may be a 
good idea to recommend a default that must be manually over-ridden to 
allow that type of information to be sent (protect privacy).

Mike

At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:

It seems that there is a place for another state - Do Not Disturb (DND). 
DND means that although I am online messages sent to me will not reach me. 
Thus, the blocking of the messages can be done in the client of the 
originator. 

So the states that we will have are: 
* Free (Available)
* Busy (Open but I am busy)
* DND (Closed for communication) 
* Away, for an
   indeterminate amount of time (used also by automatic away sensed by the 
client)
   short time (set manually)
   long time (set manually) 

Avshalom Houri 
Presence and Instant Messaging Architect 
Lotus Sametime, IBM Software Group 



Henning Schulzrinne  
Sent by: simple-admin@mailman.dynamicsoft.com 

14/05/2002 03:52 
Please respond to Henning Schulzrinne 
        
        To:        Tony Hansen  
        cc:        simple@mailman.dynamicsoft.com 
        Subject:        Re: [Simple] Status summary 

       

> Your "on the phone" is just another version of Busy.

Agreed; the only reason I kept it separate is that a SIP device may know 
this condition specifically. It might be useful to have a two-level 
hierarchy of labels, as in busy.phone and busy.meeting.

> 
> I see the following set:
> 
>     Free (Available)
>     Busy
>     Away, for an
>         indeterminate amount of time
>         short time
>         long time
> 
> Each could also be annotated with additional text.
> 
> Busy means "I'm doing stuff, so may not respond right away. Annotations 
> for Busy would be things such as "On the phone" and "In a meeting".
> 
> The time based settings are purely subjective values, not concrete 
> values. The indeterminate time would be appropriate for use by an idle 
> timer.

It would be nice to be able to provide an explicit time of return. With 
calendar integration, this wouldn't be too hard. Obviously, this would 
be optional.

> 
>     Tony Hansen
>     tony@att.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



--=_alternative 0052CE8AC2256BB9_=
Content-Type: text/html; charset="us-ascii"



I understood busy as an hint that means that I am busy so please disturb me only if it is a urgent issue. So it is Open-Active while DND is Closed-Active.



Avshalom













Michael Hammer <mhammer@cisco.com>

14/05/2002 17:38

Please respond to Michael Hammer



        

        To:        Avshalom Houri/Haifa/IBM@IBMIL

        cc:        simple@mailman.dynamicsoft.com, Henning Schulzrinne <hgs@cs.columbia.edu>

        Subject:        Re: [Simple] Status summary



       




Avshalom,



So what is the difference between a busy and a DND?  Some of this seems to boil down to the explicit not available (Busy, DND) and the implicit (Away).  So essentially there is:



Closed-permanent (Explicit:  De-registration)

Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)

Open-Active      (Implicit:  Actively using)

Open-Inactive    (Implicit:  Away so Maybe).



One last comment:  Since some of this may reveal presence, it may be a good idea to recommend a default that must be manually over-ridden to allow that type of information to be sent (protect privacy).



Mike



At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:



It seems that there is a place for another state - Do Not Disturb (DND). 

DND means that although I am online messages sent to me will not reach me. 

Thus, the blocking of the messages can be done in the client of the originator. 



So the states that we will have are: 

* Free (Available)

* Busy (Open but I am busy)

* DND (Closed for communication) 

* Away, for an

   indeterminate amount of time (used also by automatic away sensed by the client)

   short time (set manually)

   long time (set manually) 



Avshalom Houri 

Presence and Instant Messaging Architect 

Lotus Sametime, IBM Software Group 







Henning Schulzrinne <hgs@cs.columbia.edu> 

Sent by: simple-admin@mailman.dynamicsoft.com 



14/05/2002 03:52 

Please respond to Henning Schulzrinne 

        

        To:        Tony Hansen <tony@att.com> 

        cc:        simple@mailman.dynamicsoft.com 

        Subject:        Re: [Simple] Status summary 



       



> Your "on the phone" is just another version of Busy.



Agreed; the only reason I kept it separate is that a SIP device may know 

this condition specifically. It might be useful to have a two-level 

hierarchy of labels, as in busy.phone and busy.meeting.



> 

> I see the following set:

> 

>     Free (Available)

>     Busy

>     Away, for an

>         indeterminate amount of time

>         short time

>         long time

> 

> Each could also be annotated with additional text.

> 

> Busy means "I'm doing stuff, so may not respond right away. Annotations 

> for Busy would be things such as "On the phone" and "In a meeting".

> 

> The time based settings are purely subjective values, not concrete 

> values. The indeterminate time would be appropriate for use by an idle 

> timer.



It would be nice to be able to provide an explicit time of return. With 

calendar integration, this wouldn't be too hard. Obviously, this would 

be optional.



> 

>     Tony Hansen

>     tony@att.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






--=_alternative 0052CE8AC2256BB9_=--

From tony@att.com  Tue May 14 12:09:10 2002
Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05782
	for ; Tue, 14 May 2002 12:09:10 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g4EG80Df006976
	for ; Tue, 14 May 2002 12:08:00 -0400 (EDT)
Received: from att.com ([135.210.34.41])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020514160759gw100aiqrte>
          (Authid: tony);
          Tue, 14 May 2002 16:07:59 +0000
Message-ID: <3CE135F5.8070309@att.com>
Date: Tue, 14 May 2002 12:06:13 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Status summary
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3552
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: 

All of the statuses that Henning and I proposed were OPEN statuses. That
is, they were all to be used when messages were allowed to be sent.

That is, to our list you'd add CLOSED, which equates to the Offline
status for most services.

Now, Closed but active (your DND/Do Not Disturb) is an interesting
status. I don't think the rfc2778 model supports that. Do we need
annotated CLOSED statuses? Do we need a way of saying "I'm around, but
don't bother me"?

(AT&T's IM Anywhere service once supported the equivalent to annotated
CLOSED statuses. We eventually got rid of the concept.)

	Tony

Avshalom Houri wrote:
 >
 > I understood busy as an hint that means that I am busy so please disturb
 > me only if it is a urgent issue. So it is Open-Active while DND is
 > Closed-Active.
 >
 > Avshalom
 >
 > Michael Hammer 
 >
 > Avshalom,
 >
 > So what is the difference between a busy and a DND?  Some of this seems
 > to boil down to the explicit not available (Busy, DND) and the implicit
 > (Away).  So essentially there is:
 >
 > Closed-permanent (Explicit:  De-registration)
 > Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)
 > Open-Active      (Implicit:  Actively using)
 > Open-Inactive    (Implicit:  Away so Maybe).
 >
 > One last comment:  Since some of this may reveal presence, it may be a
 > good idea to recommend a default that must be manually over-ridden to
 > allow that type of information to be sent (protect privacy).
 >
 > Mike
 >
 > At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:
 >
 > It seems that there is a place for another state - Do Not Disturb (DND).
 > DND means that although I am online messages sent to me will not 
reach me.
 > Thus, the blocking of the messages can be done in the client of the
 > originator.
 >
 > So the states that we will have are:
 > * Free (Available)
 > * Busy (Open but I am busy)
 > * DND (Closed for communication)
 > * Away, for an
 >   indeterminate amount of time (used also by automatic away sensed by
 > the client)
 >   short time (set manually)
 >   long time (set manually)
 >
 > Avshalom Houri
 > Presence and Instant Messaging Architect
 > Lotus Sametime, IBM Software Group
 >
 >
 >
 > Henning Schulzrinne 
 > Sent by: simple-admin@mailman.dynamicsoft.com
 >
 > 14/05/2002 03:52
 > Please respond to Henning Schulzrinne
 >
 >        To:        Tony Hansen 
 >        cc:        simple@mailman.dynamicsoft.com
 >         Subject:        Re: [Simple] Status summary
 >
 >
 >
 >  > Your "on the phone" is just another version of Busy.
 >
 > Agreed; the only reason I kept it separate is that a SIP device may know
 > this condition specifically. It might be useful to have a two-level
 > hierarchy of labels, as in busy.phone and busy.meeting.
 >
 >  >
 >  > I see the following set:
 >  >
 >  >     Free (Available)
 >  >     Busy
 >  >     Away, for an
 >  >         indeterminate amount of time
 >  >         short time
 >  >         long time
 >  >
 >  > Each could also be annotated with additional text.
 >  >
 >  > Busy means "I'm doing stuff, so may not respond right away. 
Annotations
 >  > for Busy would be things such as "On the phone" and "In a meeting".
 >  >
 >  > The time based settings are purely subjective values, not concrete
 >  > values. The indeterminate time would be appropriate for use by an idle
 >  > timer.
 >
 > It would be nice to be able to provide an explicit time of return. With
 > calendar integration, this wouldn't be too hard. Obviously, this would
 > be optional.




From AVSHALOM@il.ibm.com  Tue May 14 12:22:11 2002
Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05887
	for ; Tue, 14 May 2002 12:22:11 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g4EGL2Sx044072
	for ; Tue, 14 May 2002 18:21:02 +0200
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4EGL1H124520
	for ; Tue, 14 May 2002 18:21:01 +0200
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Subject: Re: [Simple] Status summary
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: 
From: "Avshalom Houri" 
Date: Tue, 14 May 2002 19:21:00 +0300
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 14/05/2002 19:21:01,
	Serialize complete at 14/05/2002 19:21:01
Content-Type: multipart/alternative; boundary="=_alternative 0059D31AC2256BB9_="
Content-Length: 11093
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: 

This is a multipart message in MIME format.
--=_alternative 0059D31AC2256BB9_=
Content-Type: text/plain; charset="us-ascii"

Lotus Sametime has DND and users use it a lot. It is like closing the door 
and putting do not disturb on the door. People know that you are there but 
will not disturb you. In DND you can open an IM session with someone that 
you wish to talk to but you are not bothered by IMs.

Avshalom
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group





Tony Hansen 
Sent by: simple-admin@mailman.dynamicsoft.com
14/05/2002 19:06
Please respond to Tony Hansen

 
        To:        simple@mailman.dynamicsoft.com
        cc: 
        Subject:        Re: [Simple] Status summary

 

All of the statuses that Henning and I proposed were OPEN statuses. That
is, they were all to be used when messages were allowed to be sent.

That is, to our list you'd add CLOSED, which equates to the Offline
status for most services.

Now, Closed but active (your DND/Do Not Disturb) is an interesting
status. I don't think the rfc2778 model supports that. Do we need
annotated CLOSED statuses? Do we need a way of saying "I'm around, but
don't bother me"?

(AT&T's IM Anywhere service once supported the equivalent to annotated
CLOSED statuses. We eventually got rid of the concept.)

                 Tony

Avshalom Houri wrote:
 >
 > I understood busy as an hint that means that I am busy so please 
disturb
 > me only if it is a urgent issue. So it is Open-Active while DND is
 > Closed-Active.
 >
 > Avshalom
 >
 > Michael Hammer 
 >
 > Avshalom,
 >
 > So what is the difference between a busy and a DND?  Some of this seems
 > to boil down to the explicit not available (Busy, DND) and the implicit
 > (Away).  So essentially there is:
 >
 > Closed-permanent (Explicit:  De-registration)
 > Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)
 > Open-Active      (Implicit:  Actively using)
 > Open-Inactive    (Implicit:  Away so Maybe).
 >
 > One last comment:  Since some of this may reveal presence, it may be a
 > good idea to recommend a default that must be manually over-ridden to
 > allow that type of information to be sent (protect privacy).
 >
 > Mike
 >
 > At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:
 >
 > It seems that there is a place for another state - Do Not Disturb 
(DND).
 > DND means that although I am online messages sent to me will not 
reach me.
 > Thus, the blocking of the messages can be done in the client of the
 > originator.
 >
 > So the states that we will have are:
 > * Free (Available)
 > * Busy (Open but I am busy)
 > * DND (Closed for communication)
 > * Away, for an
 >   indeterminate amount of time (used also by automatic away sensed by
 > the client)
 >   short time (set manually)
 >   long time (set manually)
 >
 > Avshalom Houri
 > Presence and Instant Messaging Architect
 > Lotus Sametime, IBM Software Group
 >
 >
 >
 > Henning Schulzrinne 
 > Sent by: simple-admin@mailman.dynamicsoft.com
 >
 > 14/05/2002 03:52
 > Please respond to Henning Schulzrinne
 >
 >        To:        Tony Hansen 
 >        cc:        simple@mailman.dynamicsoft.com
 >         Subject:        Re: [Simple] Status summary
 >
 >
 >
 >  > Your "on the phone" is just another version of Busy.
 >
 > Agreed; the only reason I kept it separate is that a SIP device may 
know
 > this condition specifically. It might be useful to have a two-level
 > hierarchy of labels, as in busy.phone and busy.meeting.
 >
 >  >
 >  > I see the following set:
 >  >
 >  >     Free (Available)
 >  >     Busy
 >  >     Away, for an
 >  >         indeterminate amount of time
 >  >         short time
 >  >         long time
 >  >
 >  > Each could also be annotated with additional text.
 >  >
 >  > Busy means "I'm doing stuff, so may not respond right away. 
Annotations
 >  > for Busy would be things such as "On the phone" and "In a meeting".
 >  >
 >  > The time based settings are purely subjective values, not concrete
 >  > values. The indeterminate time would be appropriate for use by an 
idle
 >  > timer.
 >
 > It would be nice to be able to provide an explicit time of return. With
 > calendar integration, this wouldn't be too hard. Obviously, this would
 > be optional.



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



--=_alternative 0059D31AC2256BB9_=
Content-Type: text/html; charset="us-ascii"



Lotus Sametime has DND and users use it a lot. It is like closing the door and putting do not disturb on the door. People know that you are there but will not disturb you. In DND you can open an IM session with someone that you wish to talk to but you are not bothered by IMs.



Avshalom

Presence and Instant Messaging Architect

Lotus Sametime, IBM Software Group













Tony Hansen <tony@att.com>

Sent by: simple-admin@mailman.dynamicsoft.com

14/05/2002 19:06

Please respond to Tony Hansen



        

        To:        simple@mailman.dynamicsoft.com

        cc:        

        Subject:        Re: [Simple] Status summary



       




All of the statuses that Henning and I proposed were OPEN statuses. That

is, they were all to be used when messages were allowed to be sent.



That is, to our list you'd add CLOSED, which equates to the Offline

status for most services.



Now, Closed but active (your DND/Do Not Disturb) is an interesting

status. I don't think the rfc2778 model supports that. Do we need

annotated CLOSED statuses? Do we need a way of saying "I'm around, but

don't bother me"?



(AT&T's IM Anywhere service once supported the equivalent to annotated

CLOSED statuses. We eventually got rid of the concept.)



                 Tony



Avshalom Houri wrote:

 >

 > I understood busy as an hint that means that I am busy so please disturb

 > me only if it is a urgent issue. So it is Open-Active while DND is

 > Closed-Active.

 >

 > Avshalom

 >

 > Michael Hammer <mhammer@cisco.com>

 >

 > Avshalom,

 >

 > So what is the difference between a busy and a DND?  Some of this seems

 > to boil down to the explicit not available (Busy, DND) and the implicit

 > (Away).  So essentially there is:

 >

 > Closed-permanent (Explicit:  De-registration)

 > Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)

 > Open-Active      (Implicit:  Actively using)

 > Open-Inactive    (Implicit:  Away so Maybe).

 >

 > One last comment:  Since some of this may reveal presence, it may be a

 > good idea to recommend a default that must be manually over-ridden to

 > allow that type of information to be sent (protect privacy).

 >

 > Mike

 >

 > At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:

 >

 > It seems that there is a place for another state - Do Not Disturb (DND).

 > DND means that although I am online messages sent to me will not 

reach me.

 > Thus, the blocking of the messages can be done in the client of the

 > originator.

 >

 > So the states that we will have are:

 > * Free (Available)

 > * Busy (Open but I am busy)

 > * DND (Closed for communication)

 > * Away, for an

 >   indeterminate amount of time (used also by automatic away sensed by

 > the client)

 >   short time (set manually)

 >   long time (set manually)

 >

 > Avshalom Houri

 > Presence and Instant Messaging Architect

 > Lotus Sametime, IBM Software Group

 >

 >

 >

 > Henning Schulzrinne <hgs@cs.columbia.edu>

 > Sent by: simple-admin@mailman.dynamicsoft.com

 >

 > 14/05/2002 03:52

 > Please respond to Henning Schulzrinne

 >

 >        To:        Tony Hansen <tony@att.com>

 >        cc:        simple@mailman.dynamicsoft.com

 >         Subject:        Re: [Simple] Status summary

 >

 >

 >

 >  > Your "on the phone" is just another version of Busy.

 >

 > Agreed; the only reason I kept it separate is that a SIP device may know

 > this condition specifically. It might be useful to have a two-level

 > hierarchy of labels, as in busy.phone and busy.meeting.

 >

 >  >

 >  > I see the following set:

 >  >

 >  >     Free (Available)

 >  >     Busy

 >  >     Away, for an

 >  >         indeterminate amount of time

 >  >         short time

 >  >         long time

 >  >

 >  > Each could also be annotated with additional text.

 >  >

 >  > Busy means "I'm doing stuff, so may not respond right away. 

Annotations

 >  > for Busy would be things such as "On the phone" and "In a meeting".

 >  >

 >  > The time based settings are purely subjective values, not concrete

 >  > values. The indeterminate time would be appropriate for use by an idle

 >  > timer.

 >

 > It would be nice to be able to provide an explicit time of return. With

 > calendar integration, this wouldn't be too hard. Obviously, this would

 > be optional.







_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple






--=_alternative 0059D31AC2256BB9_=--

From Ramiro_Liscano@Mitel.COM  Tue May 14 12:47:17 2002
Received: from Mitel.COM ([216.191.234.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06012
	for ; Tue, 14 May 2002 12:47:12 -0400 (EDT)
Received: from rndex50.software.mitel.com (rndex50 [134.199.17.160]) 
	by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id MAA16277;
	Tue, 14 May 2002 12:45:58 -0400 (EDT)
Received: by rndex50.ottawa.mitel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 14 May 2002 12:45:58 -0400
Message-ID: <29B5A21C13C8D51190F900805F65B4EC23FACF@rndex50.ottawa.mitel.com>
From: "Liscano, Ramiro" 
To: "'Tony Hansen'" , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Status summary
Date: Tue, 14 May 2002 12:45:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4809
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: 

It seems to me that DND behaves much like a Closed Permanent since the watchers
cannot commence a communication session with the Presentity. If the primary purpose
of presence is to enable communications then if you cannot communicate then
you should not be available.

Busy on the other hand still allows a Watcher to communicate with a Presentity.
The reality is that it carries many meanings that depend on the relationship with
other persons. It seems to me that there are only 3 accurate states:

 Closed-permanent (Explicit:  De-registration, DND)
 Open-Active      (Implicit:  Actively using, context is sent to watchers)
 Open-Inactive    (Implicit:  Away, Out to lunch, etc.).

It is relatively difficult to define these states unless you define an Ontology
based on a context.

Ramiro Liscano
Mitel Networks
350 Legget Dr. PO Box 13089
Kanata, Ontario, Canada K2K 2W7
tel: (613) 592-2122 x4966
fax: (613) 592-7836

-----Original Message-----
From: Tony Hansen [mailto:tony@att.com]
Sent: Tuesday, May 14, 2002 12:06 PM
To: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Status summary


All of the statuses that Henning and I proposed were OPEN statuses. That
is, they were all to be used when messages were allowed to be sent.

That is, to our list you'd add CLOSED, which equates to the Offline
status for most services.

Now, Closed but active (your DND/Do Not Disturb) is an interesting
status. I don't think the rfc2778 model supports that. Do we need
annotated CLOSED statuses? Do we need a way of saying "I'm around, but
don't bother me"?

(AT&T's IM Anywhere service once supported the equivalent to annotated
CLOSED statuses. We eventually got rid of the concept.)

	Tony

Avshalom Houri wrote:
 >
 > I understood busy as an hint that means that I am busy so please disturb
 > me only if it is a urgent issue. So it is Open-Active while DND is
 > Closed-Active.
 >
 > Avshalom
 >
 > Michael Hammer 
 >
 > Avshalom,
 >
 > So what is the difference between a busy and a DND?  Some of this seems
 > to boil down to the explicit not available (Busy, DND) and the implicit
 > (Away).  So essentially there is:
 >
 > Closed-permanent (Explicit:  De-registration)
 > Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)
 > Open-Active      (Implicit:  Actively using)
 > Open-Inactive    (Implicit:  Away so Maybe).
 >
 > One last comment:  Since some of this may reveal presence, it may be a
 > good idea to recommend a default that must be manually over-ridden to
 > allow that type of information to be sent (protect privacy).
 >
 > Mike
 >
 > At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:
 >
 > It seems that there is a place for another state - Do Not Disturb (DND).
 > DND means that although I am online messages sent to me will not 
reach me.
 > Thus, the blocking of the messages can be done in the client of the
 > originator.
 >
 > So the states that we will have are:
 > * Free (Available)
 > * Busy (Open but I am busy)
 > * DND (Closed for communication)
 > * Away, for an
 >   indeterminate amount of time (used also by automatic away sensed by
 > the client)
 >   short time (set manually)
 >   long time (set manually)
 >
 > Avshalom Houri
 > Presence and Instant Messaging Architect
 > Lotus Sametime, IBM Software Group
 >
 >
 >
 > Henning Schulzrinne 
 > Sent by: simple-admin@mailman.dynamicsoft.com
 >
 > 14/05/2002 03:52
 > Please respond to Henning Schulzrinne
 >
 >        To:        Tony Hansen 
 >        cc:        simple@mailman.dynamicsoft.com
 >         Subject:        Re: [Simple] Status summary
 >
 >
 >
 >  > Your "on the phone" is just another version of Busy.
 >
 > Agreed; the only reason I kept it separate is that a SIP device may know
 > this condition specifically. It might be useful to have a two-level
 > hierarchy of labels, as in busy.phone and busy.meeting.
 >
 >  >
 >  > I see the following set:
 >  >
 >  >     Free (Available)
 >  >     Busy
 >  >     Away, for an
 >  >         indeterminate amount of time
 >  >         short time
 >  >         long time
 >  >
 >  > Each could also be annotated with additional text.
 >  >
 >  > Busy means "I'm doing stuff, so may not respond right away. 
Annotations
 >  > for Busy would be things such as "On the phone" and "In a meeting".
 >  >
 >  > The time based settings are purely subjective values, not concrete
 >  > values. The indeterminate time would be appropriate for use by an idle
 >  > timer.
 >
 > It would be nice to be able to provide an explicit time of return. With
 > calendar integration, this wouldn't be too hard. Obviously, this would
 > be optional.



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

From mhammer@cisco.com  Tue May 14 13:23:18 2002
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 NAA06154
	for ; Tue, 14 May 2002 13:23:18 -0400 (EDT)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EHMZhc017700;
	Tue, 14 May 2002 13:22:36 -0400 (EDT)
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 AAV90320;
	Tue, 14 May 2002 13:17:07 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020514131415.00b1ce58@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 14 May 2002 13:22:05 -0400
To: "Liscano, Ramiro" 
From: Michael Hammer 
Subject: RE: [Simple] Status summary
Cc: "'Tony Hansen'" , simple@mailman.dynamicsoft.com
In-Reply-To: <29B5A21C13C8D51190F900805F65B4EC23FACF@rndex50.ottawa.mite
 l.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 5743
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: 

Ramiro,

Would there ever be a distinction between:

Closed-permanent as in unreachable
Closed-temporary as in reachable, but does not want to communicate.

I am also wondering if it is possible to have an emergency 
over-ride.  Closed may mean that messages are dumped if received.  But, if 
you are open to receiving emergency broadcast IMs, they could be 
accepted.  Thus you may be closed to some grade of messages, but open to 
others from the same sender.

Mike


At 12:45 PM 5/14/2002 -0400, Liscano, Ramiro wrote:
>It seems to me that DND behaves much like a Closed Permanent since the 
>watchers
>cannot commence a communication session with the Presentity. If the 
>primary purpose
>of presence is to enable communications then if you cannot communicate then
>you should not be available.
>
>Busy on the other hand still allows a Watcher to communicate with a 
>Presentity.
>The reality is that it carries many meanings that depend on the 
>relationship with
>other persons. It seems to me that there are only 3 accurate states:
>
>  Closed-permanent (Explicit:  De-registration, DND)
>  Open-Active      (Implicit:  Actively using, context is sent to watchers)
>  Open-Inactive    (Implicit:  Away, Out to lunch, etc.).
>
>It is relatively difficult to define these states unless you define an 
>Ontology
>based on a context.
>
>Ramiro Liscano
>Mitel Networks
>350 Legget Dr. PO Box 13089
>Kanata, Ontario, Canada K2K 2W7
>tel: (613) 592-2122 x4966
>fax: (613) 592-7836
>
>-----Original Message-----
>From: Tony Hansen [mailto:tony@att.com]
>Sent: Tuesday, May 14, 2002 12:06 PM
>To: simple@mailman.dynamicsoft.com
>Subject: Re: [Simple] Status summary
>
>
>All of the statuses that Henning and I proposed were OPEN statuses. That
>is, they were all to be used when messages were allowed to be sent.
>
>That is, to our list you'd add CLOSED, which equates to the Offline
>status for most services.
>
>Now, Closed but active (your DND/Do Not Disturb) is an interesting
>status. I don't think the rfc2778 model supports that. Do we need
>annotated CLOSED statuses? Do we need a way of saying "I'm around, but
>don't bother me"?
>
>(AT&T's IM Anywhere service once supported the equivalent to annotated
>CLOSED statuses. We eventually got rid of the concept.)
>
>         Tony
>
>Avshalom Houri wrote:
>  >
>  > I understood busy as an hint that means that I am busy so please disturb
>  > me only if it is a urgent issue. So it is Open-Active while DND is
>  > Closed-Active.
>  >
>  > Avshalom
>  >
>  > Michael Hammer 
>  >
>  > Avshalom,
>  >
>  > So what is the difference between a busy and a DND?  Some of this seems
>  > to boil down to the explicit not available (Busy, DND) and the implicit
>  > (Away).  So essentially there is:
>  >
>  > Closed-permanent (Explicit:  De-registration)
>  > Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)
>  > Open-Active      (Implicit:  Actively using)
>  > Open-Inactive    (Implicit:  Away so Maybe).
>  >
>  > One last comment:  Since some of this may reveal presence, it may be a
>  > good idea to recommend a default that must be manually over-ridden to
>  > allow that type of information to be sent (protect privacy).
>  >
>  > Mike
>  >
>  > At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:
>  >
>  > It seems that there is a place for another state - Do Not Disturb (DND).
>  > DND means that although I am online messages sent to me will not
>reach me.
>  > Thus, the blocking of the messages can be done in the client of the
>  > originator.
>  >
>  > So the states that we will have are:
>  > * Free (Available)
>  > * Busy (Open but I am busy)
>  > * DND (Closed for communication)
>  > * Away, for an
>  >   indeterminate amount of time (used also by automatic away sensed by
>  > the client)
>  >   short time (set manually)
>  >   long time (set manually)
>  >
>  > Avshalom Houri
>  > Presence and Instant Messaging Architect
>  > Lotus Sametime, IBM Software Group
>  >
>  >
>  >
>  > Henning Schulzrinne 
>  > Sent by: simple-admin@mailman.dynamicsoft.com
>  >
>  > 14/05/2002 03:52
>  > Please respond to Henning Schulzrinne
>  >
>  >        To:        Tony Hansen 
>  >        cc:        simple@mailman.dynamicsoft.com
>  >         Subject:        Re: [Simple] Status summary
>  >
>  >
>  >
>  >  > Your "on the phone" is just another version of Busy.
>  >
>  > Agreed; the only reason I kept it separate is that a SIP device may know
>  > this condition specifically. It might be useful to have a two-level
>  > hierarchy of labels, as in busy.phone and busy.meeting.
>  >
>  >  >
>  >  > I see the following set:
>  >  >
>  >  >     Free (Available)
>  >  >     Busy
>  >  >     Away, for an
>  >  >         indeterminate amount of time
>  >  >         short time
>  >  >         long time
>  >  >
>  >  > Each could also be annotated with additional text.
>  >  >
>  >  > Busy means "I'm doing stuff, so may not respond right away.
>Annotations
>  >  > for Busy would be things such as "On the phone" and "In a meeting".
>  >  >
>  >  > The time based settings are purely subjective values, not concrete
>  >  > values. The indeterminate time would be appropriate for use by an idle
>  >  > timer.
>  >
>  > It would be nice to be able to provide an explicit time of return. With
>  > calendar integration, this wouldn't be too hard. Obviously, this would
>  > be optional.
>
>
>
>_______________________________________________
>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 bateman@acm.org  Tue May 14 17:38:36 2002
Received: from mail7.svr.pol.co.uk (mail7.svr.pol.co.uk [195.92.193.21])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06891
	for ; Tue, 14 May 2002 17:38:35 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by mail7.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 177jz4-0002pN-00; Tue, 14 May 2002 22:37:26 +0100
Received: from modem-2762.tiger.dialup.pol.co.uk ([62.136.218.202] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 177jz2-0000NC-00; Tue, 14 May 2002 22:37:25 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Tony Hansen'" , 
Subject: RE: [Simple] Status summary
Date: Tue, 14 May 2002 22:36:15 +0100
Organization: VisionTech Limited
Message-ID: <000001c1fb8f$63e2af20$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <3CE135F5.8070309@att.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 2786
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: 

On 14 May 2002 17:06, Tony Hansen wrote:
> All of the statuses that Henning and I proposed were OPEN statuses. 
> That is, they were all to be used when messages were allowed to be 
> sent.
> 
> That is, to our list you'd add CLOSED, which equates to the Offline 
> status for most services.
> 
> Now, Closed but active (your DND/Do Not Disturb) is an interesting 
> status. I don't think the rfc2778 model supports that. Do we need 
> annotated CLOSED statuses? Do we need a way of saying "I'm around, but

> don't bother me"?

I don't believe 2778 precludes this. It says that there is a state
CLOSED which refers to the acceptability of instant messages. It doesn't
prevent you from qualifying that with additional status information, in
fact this is explicitly allowed by including other status values from
alternative ranges.

In PIDF, we propose that a basic status is supported providing OPEN and
CLOSED status values. For instant messages this has the meaning
expressed in 2778. It may have a meaning for other communication means,
but we don't specify what those are. We also provide for the concept
(and we're having discussions in IMPP about improving the wording) of a
status value that operates in the same semantic range as basic, but
provides for greater granularity (this appears to be the topic of this
thread). Finally, we allow other status values from ranges unrelated to
the acceptability or otherwise of instant messages.

For the class of status values that operate in a similar fashion to the
basic OPEN and CLOSED but with greater fidelity, we explain that these
values should be included in conjunction with the basic value. This
means that you could specify open and
away or closed and
away. Down-level user agents without knowledge of
whatever namespace im: referred to in this instance would still use the
basic values.

Now, in this context, my suggestion would be to focus on determining an
acceptable range of status values that can be used by user agents for
such things as displaying icons, or whatever, without necessarily having
to decide on whether those values imply open or closed which I've
suggested here before will lead to inevitable conflict. It may be that
user agents will interpret the combination of basic and 'im' status
value in determining what to display but it seems apparent that almost
every popular system has slight differences. Perhaps, therefore,
determining this status range is more about defining an acceptable
limited vocabulary than trying to rationalise the different values.

Regards,

Adrian.


> 
> (AT&T's IM Anywhere service once supported the equivalent to annotated

> CLOSED statuses. We eventually got rid of the concept.)
> 
> 	Tony



From bateman@acm.org  Wed May 15 02:14:11 2002
Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08439
	for ; Wed, 15 May 2002 02:14:11 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 177s1x-00082U-00; Wed, 15 May 2002 07:12:57 +0100
Received: from modem-2323.monkey.dialup.pol.co.uk ([217.135.217.19] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 177s1x-0001ar-00; Wed, 15 May 2002 07:12:57 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Christian Huitema'" ,
        "'Tony Hansen'" , 
Subject: RE: [Simple] Status summary
Date: Wed, 15 May 2002 07:11:57 +0100
Organization: VisionTech Limited
Message-ID: <001601c1fbd7$6b452ac0$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 1605
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: 

I'm not sure I agree that closed is closed and everything else should be
open, but I certainly agree about trying to overload two different
concepts into the status field. PIDF supports multiple status values so
in a sense, that isn't a problem, but hence my suggestion that you let
basic hold OPEN/CLOSED and have an IM status that simply agrees a common
vocabulary of the states that a person may wish to describe about
themselves. How those values get set is a matter for the local agent,
for example, whether the agent automatically sets "away" after a period
of inactivity.

Adrian.

On 15 May 2002 02:07, Christian Huitema wrote:
> Short summary: closed is closed; everything else ought to be a 
> variation of "open".
> 
> I have the impression that we are trying to overload two different 
> concepts in the "status" field: on one hand, information on what we 
> know about the person, e.g. busy or not, ready to take a phone call or

> not, and on the other hand information about the presence agent, i.e. 
> connected to the network or not. Obviously, there is some relation: in

> the absence of any presence agent, the best we can state is some 
> variation of "off-line" -- i.e. "closed". On the other hand, every 
> information about the status of a person is a shade of gray: I may be 
> on the phone but still willing to read your IM; I may be out to lunch,

> but my agent is capable of filling up for me; I may have placed a 
> do-not-disturb sign on my door, but my agent may me authorize to still

> disturb me if some really important event happens.
> 
> -- Christian Huitema
> 
> 



From huitema@windows.microsoft.com  Tue May 14 21:08:45 2002
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07533
	for ; Tue, 14 May 2002 21:08:44 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 14 May 2002 18:07:36 -0700
Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 14 May 2002 18:07:36 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 14 May 2002 18:07:35 -0700
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.4905);
	 Tue, 14 May 2002 18:07:35 -0700
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.3590.0);
	 Tue, 14 May 2002 18:07:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] Status summary
Date: Tue, 14 May 2002 18:07:34 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Status summary
thread-index: AcH7kHoofMXl6hXhTauHhk/lPxZpGQAG6r5A
From: "Christian Huitema" 
To: , "Tony Hansen" ,
        
X-OriginalArrivalTime: 15 May 2002 01:07:34.0950 (UTC) FILETIME=[E5AF4460:01C1FBAC]
Content-Length: 915
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id VAA07533
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: 

Short summary: closed is closed; everything else ought to be a variation
of "open".

I have the impression that we are trying to overload two different
concepts in the "status" field: on one hand, information on what we know
about the person, e.g. busy or not, ready to take a phone call or not,
and on the other hand information about the presence agent, i.e.
connected to the network or not. Obviously, there is some relation: in
the absence of any presence agent, the best we can state is some
variation of "off-line" -- i.e. "closed". On the other hand, every
information about the status of a person is a shade of gray: I may be on
the phone but still willing to read your IM; I may be out to lunch, but
my agent is capable of filling up for me; I may have placed a
do-not-disturb sign on my door, but my agent may me authorize to still
disturb me if some really important event happens.

-- Christian Huitema

From dgboyer@avaya.com  Wed May 15 11:38:18 2002
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10044
	for ; Wed, 15 May 2002 11:38:18 -0400 (EDT)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4FFZPP15392
	for ; Wed, 15 May 2002 11:35:25 -0400 (EDT)
Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4FFZPT15372
	for ; Wed, 15 May 2002 11:35:25 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Status summary
Date: Wed, 15 May 2002 11:37:52 -0400
Message-ID: <8CA1128D59AD27429985B397118CEDDFC4438B@nj7460avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Status summary
Thread-Index: AcH7kHoofMXl6hXhTauHhk/lPxZpGQAG6r5AAB5vLTA=
From: "Boyer, David G (Dave)" 
To: "Christian Huitema" , ,
        "Tony Hansen" , 
Content-Length: 1758
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA10044
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: 

Christian -

There are really 3 states - present (available for communication), not present
(closed - unavailable for communication, unknown (presentity has denied watcher
access to their information, network problem, client down, user agent problem,
etc.).  The subfield of a closed status can be "unknown" covering the third
case, but I do think there are really 3 states.

Dave Boyer

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> Sent: Tuesday, May 14, 2002 9:08 PM
> To: bateman@acm.org; Tony Hansen; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Status summary
> 
> 
> Short summary: closed is closed; everything else ought to be 
> a variation
> of "open".
> 
> I have the impression that we are trying to overload two different
> concepts in the "status" field: on one hand, information on 
> what we know
> about the person, e.g. busy or not, ready to take a phone call or not,
> and on the other hand information about the presence agent, i.e.
> connected to the network or not. Obviously, there is some relation: in
> the absence of any presence agent, the best we can state is some
> variation of "off-line" -- i.e. "closed". On the other hand, every
> information about the status of a person is a shade of gray: 
> I may be on
> the phone but still willing to read your IM; I may be out to 
> lunch, but
> my agent is capable of filling up for me; I may have placed a
> do-not-disturb sign on my door, but my agent may me authorize to still
> disturb me if some really important event happens.
> 
> -- Christian Huitema
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From dgboyer@avaya.com  Wed May 15 12:25:25 2002
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10249
	for ; Wed, 15 May 2002 12:25:25 -0400 (EDT)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09077
	for ; Wed, 15 May 2002 12:22:36 -0400 (EDT)
Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09063
	for ; Wed, 15 May 2002 12:22:36 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Status summary
Date: Wed, 15 May 2002 12:24:59 -0400
Message-ID: <8CA1128D59AD27429985B397118CEDDFC4438F@nj7460avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Status summary
Thread-Index: AcH7ZyW3Pg+GEVZJQOq/jnnVOVKN3QAxZuIA
From: "Boyer, David G (Dave)" 
To: "Liscano, Ramiro" , "Tony Hansen" ,
        
Content-Length: 5809
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA10249
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: 


> -----Original Message-----
> From: Liscano, Ramiro [mailto:Ramiro_Liscano@mitel.com]
> Sent: Tuesday, May 14, 2002 12:46 PM
> To: 'Tony Hansen'; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Status summary
> 
> 
> It seems to me that DND behaves much like a Closed Permanent 
> since the watchers
> cannot commence a communication session with the Presentity. 
> If the primary purpose
> of presence is to enable communications then if you cannot 
> communicate then
> you should not be available.

The inverse of this is also useful - Person not available but
communication (at least to a messaging system) is available.  It
can be useful to see that someone is not present, you may just
want to leave them a message and would rather not talk with them.
> 
> Busy on the other hand still allows a Watcher to communicate 
> with a Presentity.
> The reality is that it carries many meanings that depend on 
> the relationship with
> other persons. It seems to me that there are only 3 accurate states:
> 
>  Closed-permanent (Explicit:  De-registration, DND)
>  Open-Active      (Implicit:  Actively using, context is sent 
> to watchers)
>  Open-Inactive    (Implicit:  Away, Out to lunch, etc.).
> 
> It is relatively difficult to define these states unless you 
> define an Ontology
> based on a context.
> 
> Ramiro Liscano
> Mitel Networks
> 350 Legget Dr. PO Box 13089
> Kanata, Ontario, Canada K2K 2W7
> tel: (613) 592-2122 x4966
> fax: (613) 592-7836
> 
> -----Original Message-----
> From: Tony Hansen [mailto:tony@att.com]
> Sent: Tuesday, May 14, 2002 12:06 PM
> To: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Status summary
> 
> 
> All of the statuses that Henning and I proposed were OPEN 
> statuses. That
> is, they were all to be used when messages were allowed to be sent.
> 
> That is, to our list you'd add CLOSED, which equates to the Offline
> status for most services.
> 
> Now, Closed but active (your DND/Do Not Disturb) is an interesting
> status. I don't think the rfc2778 model supports that. Do we need
> annotated CLOSED statuses? Do we need a way of saying "I'm around, but
> don't bother me"?
> 
> (AT&T's IM Anywhere service once supported the equivalent to annotated
> CLOSED statuses. We eventually got rid of the concept.)
> 
> 	Tony
> 
> Avshalom Houri wrote:
>  >
>  > I understood busy as an hint that means that I am busy so 
> please disturb
>  > me only if it is a urgent issue. So it is Open-Active while DND is
>  > Closed-Active.
>  >
>  > Avshalom
>  >
>  > Michael Hammer 
>  >
>  > Avshalom,
>  >
>  > So what is the difference between a busy and a DND?  Some 
> of this seems
>  > to boil down to the explicit not available (Busy, DND) and 
> the implicit
>  > (Away).  So essentially there is:
>  >
>  > Closed-permanent (Explicit:  De-registration)
>  > Closed-temporary (Explicit:  Busy, DND, Out to lunch, etc.)
>  > Open-Active      (Implicit:  Actively using)
>  > Open-Inactive    (Implicit:  Away so Maybe).
>  >
>  > One last comment:  Since some of this may reveal presence, 
> it may be a
>  > good idea to recommend a default that must be manually 
> over-ridden to
>  > allow that type of information to be sent (protect privacy).
>  >
>  > Mike
>  >
>  > At 11:20 AM 5/14/2002 +0300, Avshalom Houri wrote:
>  >
>  > It seems that there is a place for another state - Do Not 
> Disturb (DND).
>  > DND means that although I am online messages sent to me will not 
> reach me.
>  > Thus, the blocking of the messages can be done in the client of the
>  > originator.
>  >
>  > So the states that we will have are:
>  > * Free (Available)
>  > * Busy (Open but I am busy)
>  > * DND (Closed for communication)
>  > * Away, for an
>  >   indeterminate amount of time (used also by automatic 
> away sensed by
>  > the client)
>  >   short time (set manually)
>  >   long time (set manually)
>  >
>  > Avshalom Houri
>  > Presence and Instant Messaging Architect
>  > Lotus Sametime, IBM Software Group
>  >
>  >
>  >
>  > Henning Schulzrinne 
>  > Sent by: simple-admin@mailman.dynamicsoft.com
>  >
>  > 14/05/2002 03:52
>  > Please respond to Henning Schulzrinne
>  >
>  >        To:        Tony Hansen 
>  >        cc:        simple@mailman.dynamicsoft.com
>  >         Subject:        Re: [Simple] Status summary
>  >
>  >
>  >
>  >  > Your "on the phone" is just another version of Busy.
>  >
>  > Agreed; the only reason I kept it separate is that a SIP 
> device may know
>  > this condition specifically. It might be useful to have a two-level
>  > hierarchy of labels, as in busy.phone and busy.meeting.
>  >
>  >  >
>  >  > I see the following set:
>  >  >
>  >  >     Free (Available)
>  >  >     Busy
>  >  >     Away, for an
>  >  >         indeterminate amount of time
>  >  >         short time
>  >  >         long time
>  >  >
>  >  > Each could also be annotated with additional text.
>  >  >
>  >  > Busy means "I'm doing stuff, so may not respond right away. 
> Annotations
>  >  > for Busy would be things such as "On the phone" and "In 
> a meeting".
>  >  >
>  >  > The time based settings are purely subjective values, 
> not concrete
>  >  > values. The indeterminate time would be appropriate for 
> use by an idle
>  >  > timer.
>  >
>  > It would be nice to be able to provide an explicit time of 
> return. With
>  > calendar integration, this wouldn't be too hard. 
> Obviously, this would
>  > be optional.
> 
> 
> 
> _______________________________________________
> 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 sriramp@nortelnetworks.com  Wed May 15 20:45:02 2002
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11687
	for ; Wed, 15 May 2002 20:45:02 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4G0hvV21257;
	Wed, 15 May 2002 19:43:57 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 15 May 2002 19:43:49 -0500
Message-ID: 
From: "Sriram Parameswar"
To: "'Boyer, David G (Dave)'" ,
        Christian Huitema
	 , bateman@acm.org,
        Tony Hansen
	 , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Status summary
Date: Wed, 15 May 2002 19:43:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1FC72.BDCEC300"
Content-Length: 8634
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: 

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_01C1FC72.BDCEC300
Content-Type: text/plain;
	charset="iso-8859-1"

This has been a long thread - and as I stated in Minneapolis, 3GPP argued
long and hard on the same point. 

I would like to reiterate that we should stick with the only two values
guaranteed to interoperate - from RFC 2778 "OPEN" and "CLOSED". Everything
else is simply additional hints about my Presence status - these may
include:

* time based (when I expect to be back to OPEN or CLOSE as the case may be)
* contextual status hints (Out to lunch, Busy - meeting etc.)

Thanks,
Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com]
Sent: Wednesday, May 15, 2002 10:38 AM
To: Christian Huitema; bateman@acm.org; Tony Hansen;
simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Status summary


Christian -

There are really 3 states - present (available for communication), not
present
(closed - unavailable for communication, unknown (presentity has denied
watcher
access to their information, network problem, client down, user agent
problem,
etc.).  The subfield of a closed status can be "unknown" covering the third
case, but I do think there are really 3 states.

Dave Boyer

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> Sent: Tuesday, May 14, 2002 9:08 PM
> To: bateman@acm.org; Tony Hansen; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Status summary
> 
> 
> Short summary: closed is closed; everything else ought to be 
> a variation
> of "open".
> 
> I have the impression that we are trying to overload two different
> concepts in the "status" field: on one hand, information on 
> what we know
> about the person, e.g. busy or not, ready to take a phone call or not,
> and on the other hand information about the presence agent, i.e.
> connected to the network or not. Obviously, there is some relation: in
> the absence of any presence agent, the best we can state is some
> variation of "off-line" -- i.e. "closed". On the other hand, every
> information about the status of a person is a shade of gray: 
> I may be on
> the phone but still willing to read your IM; I may be out to 
> lunch, but
> my agent is capable of filling up for me; I may have placed a
> do-not-disturb sign on my door, but my agent may me authorize to still
> disturb me if some really important event happens.
> 
> -- Christian Huitema
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

------_=_NextPart_001_01C1FC72.BDCEC300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Status summary




This has been a long thread - and as I stated in =
Minneapolis, 3GPP argued long and hard on the same point. 




I would like to reiterate that we should stick with =
the only two values guaranteed to interoperate - from RFC 2778 =
"OPEN" and "CLOSED". Everything else is simply =
additional hints about my Presence status - these may =
include:



* time based (when I expect to be back to OPEN or =
CLOSE as the case may be)

* contextual status hints (Out to lunch, Busy - =
meeting etc.)




Thanks,

Sriram




__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-684-3986

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com






-----Original Message-----

From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com]

Sent: Wednesday, May 15, 2002 10:38 AM

To: Christian Huitema; bateman@acm.org; Tony =
Hansen;

simple@mailman.dynamicsoft.com

Subject: RE: [Simple] Status summary






Christian -




There are really 3 states - present (available for =
communication), not present

(closed - unavailable for communication, unknown =
(presentity has denied watcher

access to their information, network problem, client =
down, user agent problem,

etc.).  The subfield of a closed status can be =
"unknown" covering the third

case, but I do think there are really 3 =
states.




Dave Boyer




> -----Original Message-----

> From: Christian Huitema [mailto:huitema@windows.mic=
rosoft.com]

> Sent: Tuesday, May 14, 2002 9:08 PM

> To: bateman@acm.org; Tony Hansen; =
simple@mailman.dynamicsoft.com

> Subject: RE: [Simple] Status summary

> 

> 

> Short summary: closed is closed; everything =
else ought to be 

> a variation

> of "open".

> 

> I have the impression that we are trying to =
overload two different

> concepts in the "status" field: on =
one hand, information on 

> what we know

> about the person, e.g. busy or not, ready to =
take a phone call or not,

> and on the other hand information about the =
presence agent, i.e.

> connected to the network or not. Obviously, =
there is some relation: in

> the absence of any presence agent, the best we =
can state is some

> variation of "off-line" -- i.e. =
"closed". On the other hand, every

> information about the status of a person is a =
shade of gray: 

> I may be on

> the phone but still willing to read your IM; I =
may be out to 

> lunch, but

> my agent is capable of filling up for me; I may =
have placed a

> do-not-disturb sign on my door, but my agent =
may me authorize to still

> disturb me if some really important event =
happens.

> 

> -- Christian Huitema

> =
_______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple=


> 

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple=






------_=_NextPart_001_01C1FC72.BDCEC300--

From tony@att.com  Wed May 15 22:11:18 2002
Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11980
	for ; Wed, 15 May 2002 22:11:17 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g4G2A86m015513
	for ; Wed, 15 May 2002 21:10:09 -0500 (CDT)
Received: from att.com ([135.210.40.18])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020516021008gw100aippee>
          (Authid: tony);
          Thu, 16 May 2002 02:10:08 +0000
Message-ID: <3CE3140A.7030103@att.com>
Date: Wed, 15 May 2002 22:06:02 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Status summary
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 4091
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: 

Since Jonathan reopened this thread a couple of days ago, no one has 
advocated changing the set of OPEN and CLOSED.

All we've been talking about is those additional hints to add to the 
Presence Status.

In fact, my suggestion a couple of days ago (and clarified in subsequent 
messages) was somewhat similar to what you stated, that OPEN should be 
annotated by:

     Available
     Busy (but still able to receive messages)
     Away, for various subjective time values
	(unknown, short time, long time),
	but still able to receive messages

I feel that additional text can be added that gives additional 
information, such as "Out to lunch" and "In a meeting".

One suggestion is that the hint for OPEN should be a freeform string 
whose first word is one of the 3 words "Available", "Busy", and "Away", 
and each of which can optionally have the string "/Short-Time", 
"/Long-Time" and "/Unknown-Time" attached. Anything after that is 
totally up to the client and the user.

	Tony Hansen
	tony@att.com

Sriram Parameswar wrote:

> This has been a long thread - and as I stated in Minneapolis, 3GPP 
> argued long and hard on the same point.
> 
> I would like to reiterate that we should stick with the only two values 
> guaranteed to interoperate - from RFC 2778 "OPEN" and "CLOSED". 
> Everything else is simply additional hints about my Presence status - 
> these may include:
> 
> * time based (when I expect to be back to OPEN or CLOSE as the case may be)
> * contextual status hints (Out to lunch, Busy - meeting etc.)
> 
> Thanks,
> Sriram
> 
> __________________________________________
> Sriram Parameswar              Phone: 972-685-8540
> Interactive Multimedia Server (IMS) Fax: 972-684-3986
> Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com
> 
> 
> -----Original Message-----
> From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com]
> Sent: Wednesday, May 15, 2002 10:38 AM
> To: Christian Huitema; bateman@acm.org; Tony Hansen;
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Status summary
> 
> 
> Christian -
> 
> There are really 3 states - present (available for communication), not 
> present
> (closed - unavailable for communication, unknown (presentity has denied 
> watcher
> access to their information, network problem, client down, user agent 
> problem,
> etc.).  The subfield of a closed status can be "unknown" covering the third
> case, but I do think there are really 3 states.
> 
> Dave Boyer
> 
>  > -----Original Message-----
>  > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
>  > Sent: Tuesday, May 14, 2002 9:08 PM
>  > To: bateman@acm.org; Tony Hansen; simple@mailman.dynamicsoft.com
>  > Subject: RE: [Simple] Status summary
>  >
>  >
>  > Short summary: closed is closed; everything else ought to be
>  > a variation
>  > of "open".
>  >
>  > I have the impression that we are trying to overload two different
>  > concepts in the "status" field: on one hand, information on
>  > what we know
>  > about the person, e.g. busy or not, ready to take a phone call or not,
>  > and on the other hand information about the presence agent, i.e.
>  > connected to the network or not. Obviously, there is some relation: in
>  > the absence of any presence agent, the best we can state is some
>  > variation of "off-line" -- i.e. "closed". On the other hand, every
>  > information about the status of a person is a shade of gray:
>  > I may be on
>  > the phone but still willing to read your IM; I may be out to
>  > lunch, but
>  > my agent is capable of filling up for me; I may have placed a
>  > do-not-disturb sign on my door, but my agent may me authorize to still
>  > disturb me if some really important event happens.
>  >
>  > -- Christian Huitema
>  > _______________________________________________
>  > simple mailing list
>  > simple@mailman.dynamicsoft.com
>  > http://mailman.dynamicsoft.com/mailman/listinfo/simple
>  >
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 



From netbean@earthlink.net  Wed May 15 22:20:14 2002
Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12028
	for ; Wed, 15 May 2002 22:20:13 -0400 (EDT)
Received: from earthlink.net ([63.195.116.64])
 by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May  7 2001))
 with ESMTP id <0GW600E1BMFS1G@mta6.snfc21.pbi.net> for
 simple@mailman.dynamicsoft.com; Wed, 15 May 2002 19:19:04 -0700 (PDT)
Date: Wed, 15 May 2002 18:49:49 -0700
From: Debi Jones 
Subject: Re: [Simple] Status summary
To: Tony Hansen 
Cc: simple@mailman.dynamicsoft.com
Reply-to: netbean@earthlink.net
Message-id: <3CE3103C.7F6F61@earthlink.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.73 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: 
 <3CE3140A.7030103@att.com>
Content-Length: 4701
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: 

Where does "invisible" fit?  Invisible defined as presence info not viewable by
others on the network.
It certainly isn't a status indicator for OPEN.  Multiple cases for CLOSED is
intrinsically a bad idea.

...Debi

Tony Hansen wrote:

> Since Jonathan reopened this thread a couple of days ago, no one has
> advocated changing the set of OPEN and CLOSED.
>
> All we've been talking about is those additional hints to add to the
> Presence Status.
>
> In fact, my suggestion a couple of days ago (and clarified in subsequent
> messages) was somewhat similar to what you stated, that OPEN should be
> annotated by:
>
>      Available
>      Busy (but still able to receive messages)
>      Away, for various subjective time values
>         (unknown, short time, long time),
>         but still able to receive messages
>
> I feel that additional text can be added that gives additional
> information, such as "Out to lunch" and "In a meeting".
>
> One suggestion is that the hint for OPEN should be a freeform string
> whose first word is one of the 3 words "Available", "Busy", and "Away",
> and each of which can optionally have the string "/Short-Time",
> "/Long-Time" and "/Unknown-Time" attached. Anything after that is
> totally up to the client and the user.
>
>         Tony Hansen
>         tony@att.com
>
> Sriram Parameswar wrote:
>
> > This has been a long thread - and as I stated in Minneapolis, 3GPP
> > argued long and hard on the same point.
> >
> > I would like to reiterate that we should stick with the only two values
> > guaranteed to interoperate - from RFC 2778 "OPEN" and "CLOSED".
> > Everything else is simply additional hints about my Presence status -
> > these may include:
> >
> > * time based (when I expect to be back to OPEN or CLOSE as the case may be)
> > * contextual status hints (Out to lunch, Busy - meeting etc.)
> >
> > Thanks,
> > Sriram
> >
> > __________________________________________
> > Sriram Parameswar              Phone: 972-685-8540
> > Interactive Multimedia Server (IMS) Fax: 972-684-3986
> > Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com
> >
> >
> > -----Original Message-----
> > From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com]
> > Sent: Wednesday, May 15, 2002 10:38 AM
> > To: Christian Huitema; bateman@acm.org; Tony Hansen;
> > simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Status summary
> >
> >
> > Christian -
> >
> > There are really 3 states - present (available for communication), not
> > present
> > (closed - unavailable for communication, unknown (presentity has denied
> > watcher
> > access to their information, network problem, client down, user agent
> > problem,
> > etc.).  The subfield of a closed status can be "unknown" covering the third
> > case, but I do think there are really 3 states.
> >
> > Dave Boyer
> >
> >  > -----Original Message-----
> >  > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> >  > Sent: Tuesday, May 14, 2002 9:08 PM
> >  > To: bateman@acm.org; Tony Hansen; simple@mailman.dynamicsoft.com
> >  > Subject: RE: [Simple] Status summary
> >  >
> >  >
> >  > Short summary: closed is closed; everything else ought to be
> >  > a variation
> >  > of "open".
> >  >
> >  > I have the impression that we are trying to overload two different
> >  > concepts in the "status" field: on one hand, information on
> >  > what we know
> >  > about the person, e.g. busy or not, ready to take a phone call or not,
> >  > and on the other hand information about the presence agent, i.e.
> >  > connected to the network or not. Obviously, there is some relation: in
> >  > the absence of any presence agent, the best we can state is some
> >  > variation of "off-line" -- i.e. "closed". On the other hand, every
> >  > information about the status of a person is a shade of gray:
> >  > I may be on
> >  > the phone but still willing to read your IM; I may be out to
> >  > lunch, but
> >  > my agent is capable of filling up for me; I may have placed a
> >  > do-not-disturb sign on my door, but my agent may me authorize to still
> >  > disturb me if some really important event happens.
> >  >
> >  > -- Christian Huitema
> >  > _______________________________________________
> >  > simple mailing list
> >  > simple@mailman.dynamicsoft.com
> >  > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >  >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple


From tony@att.com  Wed May 15 23:35:59 2002
Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12277
	for ; Wed, 15 May 2002 23:35:58 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g4G3YmDf007948
	for ; Wed, 15 May 2002 23:34:48 -0400 (EDT)
Received: from att.com ([135.210.40.18])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020516033447gw100aipqce>
          (Authid: tony);
          Thu, 16 May 2002 03:34:47 +0000
Message-ID: <3CE327DC.1040304@att.com>
Date: Wed, 15 May 2002 23:30:36 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Status summary
References:  <3CE3140A.7030103@att.com> <3CE3103C.7F6F61@earthlink.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 5047
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: 

Invisible is CLOSED as far as any recipient of the status is concerned. 
Everyone else thinks you're not on, so it's indistinguishable from the 
CLOSED state.

	Tony Hansen
	tony@att.com

Debi Jones wrote:

> Where does "invisible" fit?  Invisible defined as presence info not viewable by
> others on the network.
> It certainly isn't a status indicator for OPEN.  Multiple cases for CLOSED is
> intrinsically a bad idea.
> 
> ...Debi
> 
> Tony Hansen wrote:
> 
> 
>>Since Jonathan reopened this thread a couple of days ago, no one has
>>advocated changing the set of OPEN and CLOSED.
>>
>>All we've been talking about is those additional hints to add to the
>>Presence Status.
>>
>>In fact, my suggestion a couple of days ago (and clarified in subsequent
>>messages) was somewhat similar to what you stated, that OPEN should be
>>annotated by:
>>
>>     Available
>>     Busy (but still able to receive messages)
>>     Away, for various subjective time values
>>        (unknown, short time, long time),
>>        but still able to receive messages
>>
>>I feel that additional text can be added that gives additional
>>information, such as "Out to lunch" and "In a meeting".
>>
>>One suggestion is that the hint for OPEN should be a freeform string
>>whose first word is one of the 3 words "Available", "Busy", and "Away",
>>and each of which can optionally have the string "/Short-Time",
>>"/Long-Time" and "/Unknown-Time" attached. Anything after that is
>>totally up to the client and the user.
>>
>>        Tony Hansen
>>        tony@att.com
>>
>>Sriram Parameswar wrote:
>>
>>
>>>This has been a long thread - and as I stated in Minneapolis, 3GPP
>>>argued long and hard on the same point.
>>>
>>>I would like to reiterate that we should stick with the only two values
>>>guaranteed to interoperate - from RFC 2778 "OPEN" and "CLOSED".
>>>Everything else is simply additional hints about my Presence status -
>>>these may include:
>>>
>>>* time based (when I expect to be back to OPEN or CLOSE as the case may be)
>>>* contextual status hints (Out to lunch, Busy - meeting etc.)
>>>
>>>Thanks,
>>>Sriram
>>>
>>>__________________________________________
>>>Sriram Parameswar              Phone: 972-685-8540
>>>Interactive Multimedia Server (IMS) Fax: 972-684-3986
>>>Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com
>>>
>>>
>>>-----Original Message-----
>>>From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com]
>>>Sent: Wednesday, May 15, 2002 10:38 AM
>>>To: Christian Huitema; bateman@acm.org; Tony Hansen;
>>>simple@mailman.dynamicsoft.com
>>>Subject: RE: [Simple] Status summary
>>>
>>>
>>>Christian -
>>>
>>>There are really 3 states - present (available for communication), not
>>>present
>>>(closed - unavailable for communication, unknown (presentity has denied
>>>watcher
>>>access to their information, network problem, client down, user agent
>>>problem,
>>>etc.).  The subfield of a closed status can be "unknown" covering the third
>>>case, but I do think there are really 3 states.
>>>
>>>Dave Boyer
>>>
>>> > -----Original Message-----
>>> > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
>>> > Sent: Tuesday, May 14, 2002 9:08 PM
>>> > To: bateman@acm.org; Tony Hansen; simple@mailman.dynamicsoft.com
>>> > Subject: RE: [Simple] Status summary
>>> >
>>> >
>>> > Short summary: closed is closed; everything else ought to be
>>> > a variation
>>> > of "open".
>>> >
>>> > I have the impression that we are trying to overload two different
>>> > concepts in the "status" field: on one hand, information on
>>> > what we know
>>> > about the person, e.g. busy or not, ready to take a phone call or not,
>>> > and on the other hand information about the presence agent, i.e.
>>> > connected to the network or not. Obviously, there is some relation: in
>>> > the absence of any presence agent, the best we can state is some
>>> > variation of "off-line" -- i.e. "closed". On the other hand, every
>>> > information about the status of a person is a shade of gray:
>>> > I may be on
>>> > the phone but still willing to read your IM; I may be out to
>>> > lunch, but
>>> > my agent is capable of filling up for me; I may have placed a
>>> > do-not-disturb sign on my door, but my agent may me authorize to still
>>> > disturb me if some really important event happens.
>>> >
>>> > -- Christian Huitema
>>> > _______________________________________________
>>> > simple mailing list
>>> > simple@mailman.dynamicsoft.com
>>> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>> >
>>>_______________________________________________
>>>simple mailing list
>>>simple@mailman.dynamicsoft.com
>>>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>
>>>
>>_______________________________________________
>>simple mailing list
>>simple@mailman.dynamicsoft.com
>>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 



From jdrosen@dynamicsoft.com  Thu May 16 17:22:16 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15347
	for ; Thu, 16 May 2002 17:22:16 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GLMdYH011908;
	Thu, 16 May 2002 17:22:39 -0400 (EDT)
Message-ID: <3CE422C3.9ACB6758@dynamicsoft.com>
Date: Thu, 16 May 2002 17:21:07 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: simple@mailman.dynamicsoft.com
References: <2038BCC78B1AD641891A0D1AE133DBB777912D@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 4885
Subject: [Simple] Re: Comments on presence-06
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: 


hisham.khartabil@nokia.com wrote:
> 
> I hope this is not too late.

Well, WGLC expired some time ago, but I need to do an update because of
the privacy mess, so I can eek in some minor stuff.

> 
> 3. Definitions
> 
> In a normal interpretation on client and server, a client requests and a
> server responds. They perform opposite tasks.
> 
> This leads to the confusion in understanding definitions of Presence
> Client and Presence Server. In this specification, they do the same
> thing and that is to respond to SUBSCRIBE requests and generate NOTIFY
> requests.
> 
> I understand that they share the common name of Presence Agent, but
> calling them Presence Client and Server does not make sense to me. My
> suggestion would be to keep Presence Server as is and change Presence
> Client to something like Presence Edge Server (or something similar to
> highlight the fact that it is the end point).
> 
> Presence Client definition is not used in the description through out
> the document. Section 6.11 hardly uses it when talking about migrations.

I think "edge presence server" is a bit better, but beyond that, I see
your point. I'll change.

> 
> 4. Overview of Operation
> 
> Third paragraph states
> 
>   "If authorization could not be obtained at this
>    time, the subscription is considered "pending", and a 202 response is
>    returned. "
> 
> then
> 
>   "As the state of the presentity changes, the PA
>    generates NOTIFYs for all subscribers with authorized subscriptions.
>    The state of the subscription itself is carried in the Subscription-
>    State header of the NOTIFY, and would typically indicate whether the
>    subscription is active or pending."
> 
> Now, if NOTIFYs are generated, as a result of a change in state of
> presentity, to authorised subscribers only, why would you ever send an
> state update NOTIFY with subscription-state of pending. If the last
> sentence was not talking about NOTIFY updates, it should be split from
> the sentence above it.

I added appropriate transitions. The text now reads:

As the state of the presentity changes, the PA generates
NOTIFYs containing those state changes to all subscribers with
authorized subscriptions. Changes in the state of the subscription
itself can also trigger NOTIFY requests; that state carried in the
Subscription-State header of the NOTIFY, and would typically indicate
whether the subscription is active or pending.

> 
> 5. Usage of Presence URLs
> If the protocol-independent form is used in the R-URI, how do you know
> where the next hop is? do you still apply procedures in sip-srv draft on
> the pres url?

Those procedures would actually result in the translation to a sip URL.
No, you would use a local outbound proxy, much like the tel URL
handling. I'll add a sentence.

> 
> 6.3
> "The body of a SUBSCRIBE request MAY contain a body" should say "A
> SUBSCRIBE request MAY contain a body"

Right.

> 
> 6.6.2
> Third paragraph
> 
>   "For pending subscriptions, the
>    state of the presentity SHOULD include some kind of textual note that
>    indicates a pending status."
> 
> Why is that necessary to merit a SHOULD? It sounds like redundant info
> to me. Subscription-state header carries that info already.

Thats true, but I view the end user as the customer of one, and the UA
as a customer of the other. Clearly, the UA can present to the user.
However, it turns out that this split is really useful for the buddylist
package, since the state of the subscription to the entire list is
actually not the same as the state of the subscription to an individual
buddy. To keep things uniform, I'd therefore like to keep this a should.

> 
> 6.11
> - "On occasion" should be "On occasions".

No, I believe the current usage is gramatically correct. 

> 
> - paragraph 4 states
>   "However, just because a PUA indicates it can accept
>    subscriptions, does not mean a PA should migrate the subscriptions
>    there."
> 
> Why not? I thought this was the dynamic means defining the condition of
> the migration to take place in this package.

The next sentence gives the caveat; it shouldn't if its composing
presence information from multiple PUA.

> 
> 9.5 and 9.6.1 is full of missed spaces. eg. "SUBSCRIBEand"

Fixed.

> 
> 13.
> Reference 3 should be "Common Presence and Instant Messaging (CPIM)"

OK, I'll fix.

> 
> General comment:
> - Fetch of presence info is not mentioned at all in the document. Is the
> intentional?

No, its just not specific to presence. I'll add a sentence in the
overview section.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jdrosen@dynamicsoft.com  Thu May 16 17:48:00 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15444
	for ; Thu, 16 May 2002 17:48:00 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GLmJYH011940;
	Thu, 16 May 2002 17:48:19 -0400 (EDT)
Message-ID: <3CE428C8.FDA1EF8A@dynamicsoft.com>
Date: Thu, 16 May 2002 17:46:48 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sriram Parameswar 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] draft-ietf-simple-presence-06 WGLC comments
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1842
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: 

sorry for the delay.... 

Sriram Parameswar wrote:
> 
> Hi All,
> 
> The draft looks good. My comments/questions are as follows:
> 
> *       Section 4 - "In fact, behavior of the presence agent for handing
> a SUBSCRIBE with Expires of zero is no different than for any other
> expiration value; all SUBSCRIBE requests result in a triggered NOTIFY
> with the current presentity and subscription state". My question is on a
> presence 'fetch' - what happens if a SUBSCRIBE is not authorized so the
> first NOTIFY contains either 'bogus' presence information or no body -
> if an automaton then performs an authorization (using some mechanism)
> and sends another NOTIFY with actual presence information - is this
> valid?

It wouldn't, since the subscription expired. What will happen in this
case is that the initial NOTIFY indicates a state of pending on the
subscription, and a bogus presence (probably pending). When the
authorization is provided, there is no NOTIFY. Next time the fetch is
made, the authorization is there. That is why watcherinfo has this
waiting state, so that the presentity can authorize fetches long after
the subscription has expired.

> Either way (valid or not valid) it would be good to have a line
> of clarification on how Presence fetches in the un-authorized case are
> handled.

The point is not to specify specific handling for the expires=0 case...

> *       RFC 2119 key words (MUST, SHOULD etc.) lack a space after them
> in sections - 7.2, 9.2, 9.5.

Fixed.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From Vasilis.Polychronidis@Openwave.com  Mon May 20 07:36:16 2002
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 HAA00771
	for ; Mon, 20 May 2002 07:36:15 -0400 (EDT)
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27])
          by oe-mp2.bizmailsrvcs.net
          (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with ESMTP
          id <20020520113504.CLGE397.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Mon, 20 May 2002 06:35:04 -0500
Received: from Openwave.com ([4.41.16.162]) by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with ESMTP
          id <20020520113459.YPTW25565.oe-ismta2.bizmailsrvcs.net@Openwave.com>;
          Mon, 20 May 2002 06:34:59 -0500
Message-ID: <3CE8DF61.5060008@Openwave.com>
Date: Mon, 20 May 2002 04:34:57 -0700
From: Vasilis Polychronidis 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Christian Huitema ,
        Jonathan Rosenberg 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] I-D on IM transport proposal
References: 
Content-Type: multipart/alternative;
 boundary="------------090907030305030608030605"
Content-Length: 10996
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: 

--------------090907030305030608030605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear Jonathan great ID..
This multiple hop idea is great!
Now I would like to understand how we can accomplish conferencing with 
multiple
conferencing servers (multiple intermediaries).
About Christian's idea of having the UA inserting the hops I think it is 
a good one too however
this should only happen after the UA is authenticated with the proxy.
The UA is not a trusted entity and should not be allowed to do such 
things as adding hops without
prior authentication with the proxy.

In principle this ID can be used to establish messaging session via 
intermediaries that talk
SIP, CPIM/TCP , CPIM/HTTP, etc.

BR,

-Vasilis Polychronidis

Christian Huitema wrote:

>Jonathan,
>
>In the message-session draft, you state that:
>
>   The INVITE is processed normally by proxies. However, some proxy on
>   the path might decide that the messaging stream needs to pass through
>   an intermediary. To do that, it modifies the SDP, adding a "hop"
>   attribute, containing a SIP URI for the hop. This URI need not be the
>   URI of the proxy at all, but MUST always have a transport of TCP.
>
>You explain further that this is indeed a violation of the general SIP
>requirement, which state that proxies should leave the SIP payload
>alone. Indeed, we are trying to move towards S-MIME security, which
>would prevent such mangling.
>
>I believe that the hop concept is fine, but that we must find a model in
>which the "hop" requirement is inserted by the end system (UA), not the
>proxy. We have to look at the main scenario that might require this hop
>concept -- use of a different infrastructure for message sessions and
>generic signaling. And we have to provide ways for the host to discover
>that they should use this infrastructure: either configuration, or
>dynamic discovery. For example, if the host sends too many messages
>through the "signaling only" proxy, the proxy could send an error
>response, indicating congestion and possibly suggesting an alternate
>path.
>
>-- Christian Huitema
>
>>-----Original Message-----
>>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>>Sent: Thursday, May 02, 2002 6:59 PM
>>To: simple@mailman.dynamicsoft.com
>>Subject: [Simple] I-D on IM transport proposal
>>
>>Folks,
>>
>>I have just submitted an I-D that describes in detail the proposal for
>>the IM session model which I hinted at (or is it hand-waved at) during
>>IETF 53. The proposal uses the loose route capabilities of SIP to
>>
>avoid
>
>>the problems we had with the original usage of MESSAGE. Until the
>>
>draft
>
>>appears in the archives, you can pick up a copy at:
>>
>>http://www.jdrosen.net/papers/draft-rosenberg-simple-message-session-
>>00.txt
>>
>>I sincerely apologize for the delay in getting this out. Part of the
>>reason is that this intermediary issue is really broader than the IM
>>session model, and so I also wrote a separate I-D that describes a
>>proposal on how to address the bigger issue. Until that one appears,
>>
>you
>
>>can pick it up at:
>>
>>http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-
>>00.txt
>>
>>These are written so as to be decoupled, i.e., the message session
>>proposal does not use the ideas in the session-policy draft, but it
>>references it and discusses the issues that motivated it.
>>
>>I must also, according to the policies of rfc2026, inform the group
>>
>that
>
>>I believe dynamicsoft may have IPR associated with these drafts. Yet,
>>fear not. It is being made available under our "its free if you don't
>>bug us" policy, which you can find described at
>>http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIP-UNIFY.txt.
>>
>>Thanks,
>>Jonathan R.
>>--
>>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
>>Chief Scientist                         First Floor
>>dynamicsoft                             East Hanover, NJ 07936
>>jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
>>http://www.jdrosen.net                  PH:  (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
>
>


--------------090907030305030608030605
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





Dear Jonathan great ID..

This multiple hop idea is great!

Now I would like to understand how we can accomplish conferencing with multiple

conferencing servers (multiple intermediaries).

About Christian's idea of having the UA inserting the hops I think it is
a good one too however 

this should only happen after the UA is authenticated with the proxy.

The UA is not a trusted entity and should not be allowed to do such things
as adding hops without

prior authentication with the proxy.



In principle this ID can be used to establish messaging session via intermediaries
that talk

SIP, CPIM/TCP , CPIM/HTTP, etc.



BR,



-Vasilis Polychronidis



Christian Huitema wrote:



  
Jonathan,

In the message-session draft, you state that:

   The INVITE is processed normally by proxies. However, some proxy on
   the path might decide that the messaging stream needs to pass through
   an intermediary. To do that, it modifies the SDP, adding a "hop"
   attribute, containing a SIP URI for the hop. This URI need not be the
   URI of the proxy at all, but MUST always have a transport of TCP.

You explain further that this is indeed a violation of the general SIP
requirement, which state that proxies should leave the SIP payload
alone. Indeed, we are trying to move towards S-MIME security, which
would prevent such mangling.

I believe that the hop concept is fine, but that we must find a model in
which the "hop" requirement is inserted by the end system (UA), not the
proxy. We have to look at the main scenario that might require this hop
concept -- use of a different infrastructure for messa
ge sessions and
generic signaling. And we have to provide ways for the host to discover
that they should use this infrastructure: either configuration, or
dynamic discovery. For example, if the host sends too many messages
through the "signaling only" proxy, the proxy could send an error
response, indicating congestion and possibly suggesting an alternate
path.

-- Christian Huitema


  

    
-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, May 02, 2002 6:59 PM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] I-D on IM transport proposal

Folks,

I have just submitted an I-D that describes in detail the proposal for
the IM session model which I hinted at (or is it hand-waved at) during
IETF 53. The proposal uses the loose route capabilities of SIP to

    

    
avoid

    

      
the problems we had with the original usage of MESSAGE. Until the

      

      
draft

      

        
appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-simple-message-session-
00.txt

I sincerely apologize for the delay in getting this out. Part of the
reason is that this intermediary issue is really broader than the IM
session model, and so I also wrote a separate I-D that describes a
proposal on how to address the bigger issue. Until that one appears,

        

        
you

        

          
can pick it up at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-
00.txt

These are written so as to be decoupled, i.e., the message session
proposal does not use the ideas in the session-policy draft, but it
references it and discusses the issues that motivated it.

I must also, according to the policies of rfc2026, inform the group

          

          
that

          

            
I believe dynamicsoft may have IPR associated with these drafts. Yet,
fear not. It is being made available under our "its free if you don't
bug us" policy, which you can find described at
http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIP-UNIFY.txt.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (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



            

            

            
            

--------------090907030305030608030605--




From Vasilis.Polychronidis@Openwave.com  Mon May 20 15:08:28 2002
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 PAA02090
	for ; Mon, 20 May 2002 15:08:27 -0400 (EDT)
Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27])
          by oe-mp2.bizmailsrvcs.net
          (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with ESMTP
          id <20020520190714.LQZP397.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>;
          Mon, 20 May 2002 14:07:14 -0500
Received: from Openwave.com ([62.17.22.131]) by oe-ismta2.bizmailsrvcs.net
          (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with ESMTP
          id <20020520190713.ZRLN25565.oe-ismta2.bizmailsrvcs.net@Openwave.com>;
          Mon, 20 May 2002 14:07:13 -0500
Message-ID: <3CE9495C.3070903@Openwave.com>
Date: Mon, 20 May 2002 12:07:08 -0700
From: Vasilis Polychronidis 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Christian Huitema 
CC: Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] I-D on IM transport proposal
References: 
Content-Type: multipart/alternative;
 boundary="------------070501070508030000070800"
Content-Length: 1604
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: 

--------------070501070508030000070800
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

>
>
>
>Uh, what do you mean when you say that "the UA is not a trusted entity"?
>One of the elements of the security architecture is precisely to ensure
>that only the UA is trusted with the content of the payload of the SIP
>message -- this include the possibility to encrypt and sign that
>payload.
>
Ok as long as the UA is authenticated i.e. security architecture.
So I think we are in agreement.

>
>
>-- Christian Huitema
>
>


--------------070501070508030000070800
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit







  

Uh, what do you mean when you say that "the UA is not a trusted entity"?
One of the elements of the security architecture is precisely to ensure
that only the UA is trusted with the content of the payload of the SIP
message -- this include the possibility to encrypt and sign that
payload.

  

  Ok as long as the UA is authenticated i.e. security
architecture.

So I think we are in agreement.

  

    


-- Christian Huitema



    

    

    
    

--------------070501070508030000070800--




From bcampbell@dynamicsoft.com  Mon May 20 16:11:12 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02328
	for ; Mon, 20 May 2002 16:11:10 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4KK9VX85084;
	Mon, 20 May 2002 15:09:31 -0500 (CDT)
From: "Ben Campbell" 
To: "Avshalom Houri" , ,
        "Henning Schulzrinne" 
Subject: RE: [Simple] Status summary
Date: Mon, 20 May 2002 15:09:18 -0500
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)
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 2673
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: 

I would suggest that DnD does not necessarily mean that I will not receive a
message. It means I am asking you not to send me a message. What happens if
you send one anyway is entirely a matter of my local policy.


-----Original Message-----
From: simple-admin@mailman.dynamicsoft.com
[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Avshalom Houri
Sent: Tuesday, May 14, 2002 3:21 AM
To: simple@mailman.dynamicsoft.com; Henning Schulzrinne
Subject: Re: [Simple] Status summary



It seems that there is a place for another state - Do Not Disturb (DND).
DND means that although I am online messages sent to me will not reach me.
Thus, the blocking of the messages can be done in the client of the
originator.

So the states that we will have are:
* Free (Available)
* Busy (Open but I am busy)
* DND (Closed for communication)
* Away, for an
   indeterminate amount of time (used also by automatic away sensed by the
client)
   short time (set manually)
   long time (set manually)

Avshalom Houri
Presence and Instant Messaging Architect
Lotus Sametime, IBM Software Group



Henning Schulzrinne 
Sent by: simple-admin@mailman.dynamicsoft.com
14/05/2002 03:52
Please respond to Henning Schulzrinne

        To:        Tony Hansen 
        cc:        simple@mailman.dynamicsoft.com
        Subject:        Re: [Simple] Status summary




> Your "on the phone" is just another version of Busy.

Agreed; the only reason I kept it separate is that a SIP device may know
this condition specifically. It might be useful to have a two-level
hierarchy of labels, as in busy.phone and busy.meeting.

>
> I see the following set:
>
>     Free (Available)
>     Busy
>     Away, for an
>         indeterminate amount of time
>         short time
>         long time
>
> Each could also be annotated with additional text.
>
> Busy means "I'm doing stuff, so may not respond right away. Annotations
> for Busy would be things such as "On the phone" and "In a meeting".
>
> The time based settings are purely subjective values, not concrete
> values. The indeterminate time would be appropriate for use by an idle
> timer.

It would be nice to be able to provide an explicit time of return. With
calendar integration, this wouldn't be too hard. Obviously, this would
be optional.

>
>     Tony Hansen
>     tony@att.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 bcampbell@dynamicsoft.com  Mon May 20 16:15:51 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02364
	for ; Mon, 20 May 2002 16:15:49 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4KKEQX85431;
	Mon, 20 May 2002 15:14:26 -0500 (CDT)
From: "Ben Campbell" 
To: , "Tony Hansen" 
Cc: 
Subject: RE: [Simple] Status summary
Date: Mon, 20 May 2002 15:14:13 -0500
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)
In-Reply-To: <3CE3103C.7F6F61@earthlink.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 5665
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: 

Invisible isn't a status in the sense that you communicate an invisible
status to a watcher. Invisible really means that, while you are online, able
to send IMs, and possibly able to receive them, you choose not to provide
presence status to that effect.

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Debi Jones
> Sent: Wednesday, May 15, 2002 8:50 PM
> To: Tony Hansen
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Status summary
>
>
> Where does "invisible" fit?  Invisible defined as presence info
> not viewable by
> others on the network.
> It certainly isn't a status indicator for OPEN.  Multiple cases
> for CLOSED is
> intrinsically a bad idea.
>
> ...Debi
>
> Tony Hansen wrote:
>
> > Since Jonathan reopened this thread a couple of days ago, no one has
> > advocated changing the set of OPEN and CLOSED.
> >
> > All we've been talking about is those additional hints to add to the
> > Presence Status.
> >
> > In fact, my suggestion a couple of days ago (and clarified in subsequent
> > messages) was somewhat similar to what you stated, that OPEN should be
> > annotated by:
> >
> >      Available
> >      Busy (but still able to receive messages)
> >      Away, for various subjective time values
> >         (unknown, short time, long time),
> >         but still able to receive messages
> >
> > I feel that additional text can be added that gives additional
> > information, such as "Out to lunch" and "In a meeting".
> >
> > One suggestion is that the hint for OPEN should be a freeform string
> > whose first word is one of the 3 words "Available", "Busy", and "Away",
> > and each of which can optionally have the string "/Short-Time",
> > "/Long-Time" and "/Unknown-Time" attached. Anything after that is
> > totally up to the client and the user.
> >
> >         Tony Hansen
> >         tony@att.com
> >
> > Sriram Parameswar wrote:
> >
> > > This has been a long thread - and as I stated in Minneapolis, 3GPP
> > > argued long and hard on the same point.
> > >
> > > I would like to reiterate that we should stick with the only
> two values
> > > guaranteed to interoperate - from RFC 2778 "OPEN" and "CLOSED".
> > > Everything else is simply additional hints about my Presence status -
> > > these may include:
> > >
> > > * time based (when I expect to be back to OPEN or CLOSE as
> the case may be)
> > > * contextual status hints (Out to lunch, Busy - meeting etc.)
> > >
> > > Thanks,
> > > Sriram
> > >
> > > __________________________________________
> > > Sriram Parameswar              Phone: 972-685-8540
> > > Interactive Multimedia Server (IMS) Fax: 972-684-3986
> > > Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com
> > >
> > >
> > > -----Original Message-----
> > > From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com]
> > > Sent: Wednesday, May 15, 2002 10:38 AM
> > > To: Christian Huitema; bateman@acm.org; Tony Hansen;
> > > simple@mailman.dynamicsoft.com
> > > Subject: RE: [Simple] Status summary
> > >
> > >
> > > Christian -
> > >
> > > There are really 3 states - present (available for communication), not
> > > present
> > > (closed - unavailable for communication, unknown (presentity
> has denied
> > > watcher
> > > access to their information, network problem, client down, user agent
> > > problem,
> > > etc.).  The subfield of a closed status can be "unknown"
> covering the third
> > > case, but I do think there are really 3 states.
> > >
> > > Dave Boyer
> > >
> > >  > -----Original Message-----
> > >  > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> > >  > Sent: Tuesday, May 14, 2002 9:08 PM
> > >  > To: bateman@acm.org; Tony Hansen; simple@mailman.dynamicsoft.com
> > >  > Subject: RE: [Simple] Status summary
> > >  >
> > >  >
> > >  > Short summary: closed is closed; everything else ought to be
> > >  > a variation
> > >  > of "open".
> > >  >
> > >  > I have the impression that we are trying to overload two different
> > >  > concepts in the "status" field: on one hand, information on
> > >  > what we know
> > >  > about the person, e.g. busy or not, ready to take a phone
> call or not,
> > >  > and on the other hand information about the presence agent, i.e.
> > >  > connected to the network or not. Obviously, there is some
> relation: in
> > >  > the absence of any presence agent, the best we can state is some
> > >  > variation of "off-line" -- i.e. "closed". On the other hand, every
> > >  > information about the status of a person is a shade of gray:
> > >  > I may be on
> > >  > the phone but still willing to read your IM; I may be out to
> > >  > lunch, but
> > >  > my agent is capable of filling up for me; I may have placed a
> > >  > do-not-disturb sign on my door, but my agent may me
> authorize to still
> > >  > disturb me if some really important event happens.
> > >  >
> > >  > -- Christian Huitema
> > >  > _______________________________________________
> > >  > simple mailing list
> > >  > simple@mailman.dynamicsoft.com
> > >  > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > >  >
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > >
> >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple


From dgboyer@avaya.com  Mon May 20 16:21:38 2002
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02405
	for ; Mon, 20 May 2002 16:21:37 -0400 (EDT)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04715
	for ; Mon, 20 May 2002 16:18:44 -0400 (EDT)
Received: from nj7460avexu1.global.avaya.com (h198-152-6-51.avaya.com [198.152.6.51])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04699
	for ; Mon, 20 May 2002 16:18:44 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Status summary
x-mimeole: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 20 May 2002 16:21:09 -0400
Message-ID: <8CA1128D59AD27429985B397118CEDDFC443DC@nj7460avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Status summary
Thread-Index: AcIAOzgEeEgO9kRjSqysvZCV/ydN/QAADiLw
From: "Boyer, David G (Dave)" 
To: "Ben Campbell" , ,
        "Tony Hansen" 
Cc: 
Content-Length: 6636
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id QAA02405
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: 

Ben,

I think this gets at the notion I was trying to express when 
someone may not allow you to receive their presence info (temporarily
or permanently).  You
may not be able to receive a presentities presence info but
you still can communicate with them (this applies equally for
IM and phone based communications).

Dave

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Monday, May 20, 2002 4:14 PM
> To: netbean@earthlink.net; Tony Hansen
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Status summary
> 
> 
> Invisible isn't a status in the sense that you communicate an 
> invisible
> status to a watcher. Invisible really means that, while you 
> are online, able
> to send IMs, and possibly able to receive them, you choose 
> not to provide
> presence status to that effect.
> 
> > -----Original Message-----
> > From: simple-admin@mailman.dynamicsoft.com
> > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Debi Jones
> > Sent: Wednesday, May 15, 2002 8:50 PM
> > To: Tony Hansen
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] Status summary
> >
> >
> > Where does "invisible" fit?  Invisible defined as presence info
> > not viewable by
> > others on the network.
> > It certainly isn't a status indicator for OPEN.  Multiple cases
> > for CLOSED is
> > intrinsically a bad idea.
> >
> > ...Debi
> >
> > Tony Hansen wrote:
> >
> > > Since Jonathan reopened this thread a couple of days ago, 
> no one has
> > > advocated changing the set of OPEN and CLOSED.
> > >
> > > All we've been talking about is those additional hints to 
> add to the
> > > Presence Status.
> > >
> > > In fact, my suggestion a couple of days ago (and 
> clarified in subsequent
> > > messages) was somewhat similar to what you stated, that 
> OPEN should be
> > > annotated by:
> > >
> > >      Available
> > >      Busy (but still able to receive messages)
> > >      Away, for various subjective time values
> > >         (unknown, short time, long time),
> > >         but still able to receive messages
> > >
> > > I feel that additional text can be added that gives additional
> > > information, such as "Out to lunch" and "In a meeting".
> > >
> > > One suggestion is that the hint for OPEN should be a 
> freeform string
> > > whose first word is one of the 3 words "Available", 
> "Busy", and "Away",
> > > and each of which can optionally have the string "/Short-Time",
> > > "/Long-Time" and "/Unknown-Time" attached. Anything after that is
> > > totally up to the client and the user.
> > >
> > >         Tony Hansen
> > >         tony@att.com
> > >
> > > Sriram Parameswar wrote:
> > >
> > > > This has been a long thread - and as I stated in 
> Minneapolis, 3GPP
> > > > argued long and hard on the same point.
> > > >
> > > > I would like to reiterate that we should stick with the only
> > two values
> > > > guaranteed to interoperate - from RFC 2778 "OPEN" and "CLOSED".
> > > > Everything else is simply additional hints about my 
> Presence status -
> > > > these may include:
> > > >
> > > > * time based (when I expect to be back to OPEN or CLOSE as
> > the case may be)
> > > > * contextual status hints (Out to lunch, Busy - meeting etc.)
> > > >
> > > > Thanks,
> > > > Sriram
> > > >
> > > > __________________________________________
> > > > Sriram Parameswar              Phone: 972-685-8540
> > > > Interactive Multimedia Server (IMS) Fax: 972-684-3986
> > > > Nortel Networks, Richardson USA  Email: 
> sriramp@nortelnetworks.com
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com]
> > > > Sent: Wednesday, May 15, 2002 10:38 AM
> > > > To: Christian Huitema; bateman@acm.org; Tony Hansen;
> > > > simple@mailman.dynamicsoft.com
> > > > Subject: RE: [Simple] Status summary
> > > >
> > > >
> > > > Christian -
> > > >
> > > > There are really 3 states - present (available for 
> communication), not
> > > > present
> > > > (closed - unavailable for communication, unknown (presentity
> > has denied
> > > > watcher
> > > > access to their information, network problem, client 
> down, user agent
> > > > problem,
> > > > etc.).  The subfield of a closed status can be "unknown"
> > covering the third
> > > > case, but I do think there are really 3 states.
> > > >
> > > > Dave Boyer
> > > >
> > > >  > -----Original Message-----
> > > >  > From: Christian Huitema 
[mailto:huitema@windows.microsoft.com]
> > >  > Sent: Tuesday, May 14, 2002 9:08 PM
> > >  > To: bateman@acm.org; Tony Hansen; simple@mailman.dynamicsoft.com
> > >  > Subject: RE: [Simple] Status summary
> > >  >
> > >  >
> > >  > Short summary: closed is closed; everything else ought to be
> > >  > a variation
> > >  > of "open".
> > >  >
> > >  > I have the impression that we are trying to overload two different
> > >  > concepts in the "status" field: on one hand, information on
> > >  > what we know
> > >  > about the person, e.g. busy or not, ready to take a phone
> call or not,
> > >  > and on the other hand information about the presence agent, i.e.
> > >  > connected to the network or not. Obviously, there is some
> relation: in
> > >  > the absence of any presence agent, the best we can state is some
> > >  > variation of "off-line" -- i.e. "closed". On the other hand, every
> > >  > information about the status of a person is a shade of gray:
> > >  > I may be on
> > >  > the phone but still willing to read your IM; I may be out to
> > >  > lunch, but
> > >  > my agent is capable of filling up for me; I may have placed a
> > >  > do-not-disturb sign on my door, but my agent may me
> authorize to still
> > >  > disturb me if some really important event happens.
> > >  >
> > >  > -- Christian Huitema
> > >  > _______________________________________________
> > >  > simple mailing list
> > >  > simple@mailman.dynamicsoft.com
> > >  > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > >  >
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > >
> >
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
> _______________________________________________
> 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 netbean@earthlink.net  Mon May 20 17:16:20 2002
Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02615
	for ; Mon, 20 May 2002 17:16:20 -0400 (EDT)
Received: from earthlink.net ([63.195.116.64])
 by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May  7 2001))
 with ESMTP id <0GWF00IFPHP6D4@mta5.snfc21.pbi.net> for
 simple@mailman.dynamicsoft.com; Mon, 20 May 2002 14:15:08 -0700 (PDT)
Date: Mon, 20 May 2002 13:22:11 -0700
From: Debi Jones 
Subject: Re: [Simple] Status summary
To: "Boyer, David G (Dave)" 
Cc: Ben Campbell , Tony Hansen ,
        simple@mailman.dynamicsoft.com
Reply-to: netbean@earthlink.net
Message-id: <3CE95AF2.D26D63D6@earthlink.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.73 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: 
 <8CA1128D59AD27429985B397118CEDDFC443DC@nj7460avexu1.global.avaya.com>
Content-Length: 7451
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: 

Right David.

If compared to say caller id information, there are two states of identity
information unavailable: blocked or service not available in the user's service
area.  One can't tell whether the information is "unavailable" due to blocking
or the absence of the service.

This applies to mobile users in a possible backwards compatibility situation or
intentional blocking of presence status.  Exactly as Dave said.

"Boyer, David G (Dave)" wrote:

> Ben,
>
> I think this gets at the notion I was trying to express when
> someone may not allow you to receive their presence info (temporarily
> or permanently).  You
> may not be able to receive a presentities presence info but
> you still can communicate with them (this applies equally for
> IM and phone based communications).
>
> Dave
>
> > -----Original Message-----
> > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> > Sent: Monday, May 20, 2002 4:14 PM
> > To: netbean@earthlink.net; Tony Hansen
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] Status summary
> >
> >
> > Invisible isn't a status in the sense that you communicate an
> > invisible
> > status to a watcher. Invisible really means that, while you
> > are online, able
> > to send IMs, and possibly able to receive them, you choose
> > not to provide
> > presence status to that effect.
> >
> > > -----Original Message-----
> > > From: simple-admin@mailman.dynamicsoft.com
> > > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Debi Jones
> > > Sent: Wednesday, May 15, 2002 8:50 PM
> > > To: Tony Hansen
> > > Cc: simple@mailman.dynamicsoft.com
> > > Subject: Re: [Simple] Status summary
> > >
> > >
> > > Where does "invisible" fit?  Invisible defined as presence info
> > > not viewable by
> > > others on the network.
> > > It certainly isn't a status indicator for OPEN.  Multiple cases
> > > for CLOSED is
> > > intrinsically a bad idea.
> > >
> > > ...Debi
> > >
> > > Tony Hansen wrote:
> > >
> > > > Since Jonathan reopened this thread a couple of days ago,
> > no one has
> > > > advocated changing the set of OPEN and CLOSED.
> > > >
> > > > All we've been talking about is those additional hints to
> > add to the
> > > > Presence Status.
> > > >
> > > > In fact, my suggestion a couple of days ago (and
> > clarified in subsequent
> > > > messages) was somewhat similar to what you stated, that
> > OPEN should be
> > > > annotated by:
> > > >
> > > >      Available
> > > >      Busy (but still able to receive messages)
> > > >      Away, for various subjective time values
> > > >         (unknown, short time, long time),
> > > >         but still able to receive messages
> > > >
> > > > I feel that additional text can be added that gives additional
> > > > information, such as "Out to lunch" and "In a meeting".
> > > >
> > > > One suggestion is that the hint for OPEN should be a
> > freeform string
> > > > whose first word is one of the 3 words "Available",
> > "Busy", and "Away",
> > > > and each of which can optionally have the string "/Short-Time",
> > > > "/Long-Time" and "/Unknown-Time" attached. Anything after that is
> > > > totally up to the client and the user.
> > > >
> > > >         Tony Hansen
> > > >         tony@att.com
> > > >
> > > > Sriram Parameswar wrote:
> > > >
> > > > > This has been a long thread - and as I stated in
> > Minneapolis, 3GPP
> > > > > argued long and hard on the same point.
> > > > >
> > > > > I would like to reiterate that we should stick with the only
> > > two values
> > > > > guaranteed to interoperate - from RFC 2778 "OPEN" and "CLOSED".
> > > > > Everything else is simply additional hints about my
> > Presence status -
> > > > > these may include:
> > > > >
> > > > > * time based (when I expect to be back to OPEN or CLOSE as
> > > the case may be)
> > > > > * contextual status hints (Out to lunch, Busy - meeting etc.)
> > > > >
> > > > > Thanks,
> > > > > Sriram
> > > > >
> > > > > __________________________________________
> > > > > Sriram Parameswar              Phone: 972-685-8540
> > > > > Interactive Multimedia Server (IMS) Fax: 972-684-3986
> > > > > Nortel Networks, Richardson USA  Email:
> > sriramp@nortelnetworks.com
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Boyer, David G (Dave) [mailto:dgboyer@avaya.com]
> > > > > Sent: Wednesday, May 15, 2002 10:38 AM
> > > > > To: Christian Huitema; bateman@acm.org; Tony Hansen;
> > > > > simple@mailman.dynamicsoft.com
> > > > > Subject: RE: [Simple] Status summary
> > > > >
> > > > >
> > > > > Christian -
> > > > >
> > > > > There are really 3 states - present (available for
> > communication), not
> > > > > present
> > > > > (closed - unavailable for communication, unknown (presentity
> > > has denied
> > > > > watcher
> > > > > access to their information, network problem, client
> > down, user agent
> > > > > problem,
> > > > > etc.).  The subfield of a closed status can be "unknown"
> > > covering the third
> > > > > case, but I do think there are really 3 states.
> > > > >
> > > > > Dave Boyer
> > > > >
> > > > >  > -----Original Message-----
> > > > >  > From: Christian Huitema
> [mailto:huitema@windows.microsoft.com]
> > > >  > Sent: Tuesday, May 14, 2002 9:08 PM
> > > >  > To: bateman@acm.org; Tony Hansen; simple@mailman.dynamicsoft.com
> > > >  > Subject: RE: [Simple] Status summary
> > > >  >
> > > >  >
> > > >  > Short summary: closed is closed; everything else ought to be
> > > >  > a variation
> > > >  > of "open".
> > > >  >
> > > >  > I have the impression that we are trying to overload two different
> > > >  > concepts in the "status" field: on one hand, information on
> > > >  > what we know
> > > >  > about the person, e.g. busy or not, ready to take a phone
> > call or not,
> > > >  > and on the other hand information about the presence agent, i.e.
> > > >  > connected to the network or not. Obviously, there is some
> > relation: in
> > > >  > the absence of any presence agent, the best we can state is some
> > > >  > variation of "off-line" -- i.e. "closed". On the other hand, every
> > > >  > information about the status of a person is a shade of gray:
> > > >  > I may be on
> > > >  > the phone but still willing to read your IM; I may be out to
> > > >  > lunch, but
> > > >  > my agent is capable of filling up for me; I may have placed a
> > > >  > do-not-disturb sign on my door, but my agent may me
> > authorize to still
> > > >  > disturb me if some really important event happens.
> > > >  >
> > > >  > -- Christian Huitema
> > > >  > _______________________________________________
> > > >  > simple mailing list
> > > >  > simple@mailman.dynamicsoft.com
> > > >  > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > >  >
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > >
> > >
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >
> > _______________________________________________
> > 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 jdrosen@dynamicsoft.com  Mon May 20 19:15:02 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02964
	for ; Mon, 20 May 2002 19:15:02 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.84])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4KNFPYH016728
	for ; Mon, 20 May 2002 19:15:25 -0400 (EDT)
Message-ID: <3CE98330.1CC2A07A@dynamicsoft.com>
Date: Mon, 20 May 2002 19:13:52 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; 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
Content-Length: 2852
Subject: [Simple] updates to presence and watcherinfo drafts
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: 

Folks,

I've just submitted updates to the presence and two watcherinfo drafts.
Until they appear in the archives, you can pick them up at:

http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-02.txt
http://www.jdrosen.net/papers/draft-ietf-simple-winfo-format-02.txt
http://www.jdrosen.net/papers/draft-ietf-simple-presence-07.txt

All three reflect comments received during WGLC. The changes are:

presence
--------

* removed textual and reference dependencies on draft-ietf-sip-privacy,
since this draft is now defunct. The spec now talks generally about
using any future extensions for network asserted identity.

* changed "presence client" to "edge presence agent"

* removed section on firewall and nat traversal; the draft referenced
(draft-ietf-sip-nat) has an uncertain future, and in any case, this spec
is not the place for discussion of these issues.

* added contributors section

watcherinfo-package
-------------------

* updated the text on constructing a complete view of watcherinfo
state from partial notifies. This takes into account the new
partial/full state flag, and the document-wide versioning instead of
per-watcher versioning from -01. Moved this into the watcherinfo
document format.

* Removed sending watcherinfo subscriptions on the same dialog as the
original subscription. There is no need for this; the original
subscription will deliver state in the Subscription-State header of
the notifies. Thus, there is no need for special case behavior.

* beefed up security considerations

* additional text on usage of state agents and forking

* added IANA registration of the winfo event template.

watcherinfo format
------------------

* changed first-subscribed to duration-subscribed, to avoid the need
for clock synchronization.

* added the ID and version attributes

* clarified that the URI in the watcher element is an AOR.

* Removed duration attribution from watcher element, per IETF 53.

* converted to schema

* changed resource element to watcher-list, and the uri attribute to
the resource attribute.

* added a display-name attribute to the watcher element, and made the
value of the watcher element a URI

* added MIME type registration for application/watcherinfo+xml

* added a state=full or partial attribute, to determine whether the
watcherinfo document contains full state or an update.

* added text on generation of the document, and using the document to
generate coherent watcherinfo.



I believe all three docs are complete and correct.


-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From huitema@windows.microsoft.com  Mon May 20 15:04:33 2002
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02057
	for ; Mon, 20 May 2002 15:04:27 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 20 May 2002 12:03:14 -0700
Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 May 2002 12:03:14 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 20 May 2002 12:03:09 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 20 May 2002 12:03:09 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0);
	 Mon, 20 May 2002 12:03:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Simple] I-D on IM transport proposal
Date: Mon, 20 May 2002 12:03:09 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] I-D on IM transport proposal
thread-index: AcH/8m2r8X6rYUKtSBuIXGbq6GGgFAAPiL/w
From: "Christian Huitema" 
To: "Vasilis Polychronidis" ,
        "Jonathan Rosenberg" 
Cc: 
X-OriginalArrivalTime: 20 May 2002 19:03:09.0279 (UTC) FILETIME=[FB3526F0:01C20030]
Content-Length: 628
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA02057
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: 

> About Christian's idea of having the UA inserting the hops I think it
is a 
> good one too however this should only happen after the UA is
authenticated 
> with the proxy. The UA is not a trusted entity and should not be
allowed 
> to do such things as adding hops without prior authentication with the

> proxy.

Uh, what do you mean when you say that "the UA is not a trusted entity"?
One of the elements of the security architecture is precisely to ensure
that only the UA is trusted with the content of the payload of the SIP
message -- this include the possibility to encrypt and sign that
payload.

-- Christian Huitema

From Ya-Ching.Tan@icn.siemens.de  Tue May 21 10:17:57 2002
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05495
	for ; Tue, 21 May 2002 10:17:56 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA00296;
	Tue, 21 May 2002 16:16:32 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA18024;
	Tue, 21 May 2002 16:12:37 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Tue, 21 May 2002 10:35:25 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DB4@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 
To: "'Jonathan Rosenberg'" ,
        simple@mailman.dynamicsoft.com
Subject: [Simple] Contact header mandatory in NOTIFY
Date: Tue, 21 May 2002 10:35:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 190
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: 

Contact headers should be added to the NOTIFY requests in the examples of 
draft-ietf-simple-presence-07, as they are mandatory according to 8.1 of 
draft-ietf-sip-events.

- Ya-Ching



 

From jdrosen@dynamicsoft.com  Tue May 21 12:03:07 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05835
	for ; Tue, 21 May 2002 12:03:07 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.234])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4LG3RYH017600;
	Tue, 21 May 2002 12:03:28 -0400 (EDT)
Message-ID: <3CEA6F6C.E5ED2850@dynamicsoft.com>
Date: Tue, 21 May 2002 12:01:48 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tan Ya-Ching ICM N PG U ID A 1 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Contact header mandatory in NOTIFY
References: <5B4D0C5BA65ECA46969C1419122317E6E74DB4@mchh161e>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 605
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: 

Thanks. I'll fix.

-Jonathan R.

Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
> Contact headers should be added to the NOTIFY requests in the examples
> of
> draft-ietf-simple-presence-07, as they are mandatory according to 8.1 of
> 
> draft-ietf-sip-events.
> 
> - Ya-Ching
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From jon.peterson@neustar.biz  Wed May 22 04:54:42 2002
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08541
	for ; Wed, 22 May 2002 04:54:41 -0400 (EDT)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4M8rUc28711
	for ; Wed, 22 May 2002 04:53:31 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 22 May 2002 03:53:25 -0500
Message-ID: <70565611B164D511957A001083FCDD560187034B@va02.va.neustar.com>
From: "Peterson, Jon" 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Wed, 22 May 2002 03:53:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4826
Subject: [Simple] revised SIMPLE charter - comments?
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: 

Folks,

Enclosed is a proposed revision to the charter of the SIMPLE working group.
Most of the changes reflected in this version concern the new direction
towards architecting a complete buddylist-style instant messaging
application. We'd welcome any comments or suggestions on the text or
deliverables below.

Jon Peterson
NeuStar, Inc.
SIMPLE co-chair

-----

SIP for Instant Messaging and Presence Leveraging Extensions (simple) 

Chair(s):
Robert Sparks 
Jon Peterson 

Applications Area Director(s): 
Ned Freed 
Patrik Faltstrom 

Applications Area Advisor: 
Patrik Faltstrom 

Mailing Lists: 
General Discussion:simple@mailman.dynamicsoft.com 
To Subscribe: http://mailman.dynamicsoft.com/mailman/listinfo/simple 
Archive: Archive: http://mailman.dynamicsoft.com/pipermail/simple 

Description of Working Group: 

This working group focuses on the application of the Session Initiation
Protocol (SIP, RFC 3261) to the suite of services collectively known as
instant messaging and presence (IMP). The IETF has committed to producing an
interoperable standard for these services compliant to the requirements for
IM
outlined in RFC 2779 (including the security and privacy requirements there)
and in the Common Presence and Instant Messaging (CPIM) specification,
developed
within the IMPP working group. As the most common services for which SIP is
used 
share quite a bit in common with IMP, the adaptation of SIP to IMP seems a 
natural choice given the widespread support for (and relative maturity of)
the 
SIP standard. 

The primary work of this group will be to generate: 

1. A proposed standard SIP extension documenting the transport of Instant
Messages in SIP, compliant to the requirements for IM outlined in RFC 2779,
CPIM and in BCP 41 (so that the transport implications of the extension 
with respect to network congestion are considered in the design). 

2. A proposed standard SIP event package and any related protocol 
mechanisms used to support presence, compliant to the requirements for 
presence outlined in RFC 2779 and CPIM. 

3. An architecture for the implementation of a traditional buddylist-
based instant messaging and presence application with SIP, including for
example new mechanisms for message confirmation delivery, indications for
when 
a party is in the process of typing a message, secure buddylist manipulation

operations, and the extension of the CPIM presence format to describe
typical 
IM states.

All SIMPLE proposals fulfilling these goals must document the mappings of 
their operation to CPIM. Any SIP extensions proposed in the course of this 
development will, after a last call process, be transferred to the SIP WG 
for consideration as formal SIP extensions.

The working group will work within the framework for presence and IM
described in RFC 2778. The extensions it defines must also be compliant with
the SIP processes for extensions. The group cannot modify baseline SIP
behavior or define a new version of SIP for IM and presence. If the group
determines that any capabilities requiring an extension to SIP are needed,
the group will seek to define such extensions within the SIP working group, 
and then use them here. 

The working group will operate in close cooperation with the IMPP working
group, which will be completing CPIM in parallel. The working group will
also cooperate with any other groups defined to standardize other presence
and IM systems, to ensure maximum sharing of information and avoid
reinvention of the wheel. The working group will cooperate with the SIP
working group, soliciting reviews to ensure its extensions meet SIPs
requirements. The working group will also collaborate with the SIP WG to
ensure consistent operation of the SUBSCRIBE and NOTIFY methods across
the other applications being defined for its use. 

Goals and Milestones:
Apr 02    Submission of event package for presence to IESG for publication 
as Proposed Standard
May 02    Submission of watcher information drafts to IESG for publication 
as Proposed Standards
Jun 02    Submission of CPIM mapping draft to IESG for publication as 
Informational
Jun 02    Submission of instant messaging session drafts to IESG for 
publication as Proposed Standards
Jul 02    Submission of buddylist package set to IESG for publication as 
Proposed Standards
Jul 02    Submission of buddylist auth/modify requirements draft to IESG 
for publication as Informational
Aug 02    Submission of SIMPLE PIDF profile to IESG for publication as 
Proposed Standard
Aug 02    Submission of advanced messaging requirements draft to IESG for 
publication as Informational
Sep 02    Submission of Presence/IM System Architecture draft to IESG for 
publication as Informational

From nsyracus@cnri.reston.va.us  Wed May 22 07:22:30 2002
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 HAA08977
	for ; Wed, 22 May 2002 07:22:30 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22807;
	Wed, 22 May 2002 07:21:00 -0400 (EDT)
Message-Id: <200205221121.HAA22807@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
Date: Wed, 22 May 2002 07:20:59 -0400
Content-Length: 3042
Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-package-02.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: A Session Initiation Protocol (SIP)Event 
                          Template-Package for Watcher Information
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-winfo-package-02.txt
	Pages		: 19
	Date		: 21-May-02
	
This document defines the watcher information template-package for
the SIP event framework. Watcher information refers to the set of
users subscribed to a particular resource within a particular event
package. Watcher information changes dynamically as users subscribe,
unsubscribe, are approved, or are rejected. A user can subscribe to
this information, and therefore learn about changes to it. This event
package is a template-package because it can be applied to any event
package, including itself.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-winfo-package-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-winfo-package-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020521141753.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-winfo-package-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-winfo-package-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020521141753.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Wed May 22 07:22:34 2002
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 HAA08982
	for ; Wed, 22 May 2002 07:22:34 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22823;
	Wed, 22 May 2002 07:21:04 -0400 (EDT)
Message-Id: <200205221121.HAA22823@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
Date: Wed, 22 May 2002 07:21:04 -0400
Content-Length: 3146
Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-format-02.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: An Extensible Markup Language (XML) Based Format for 
                          Watcher Information
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-winfo-format-02.txt
	Pages		: 14
	Date		: 21-May-02
	
Watchers are defined as entities that request (i.e., subscribe to)
information about a resource. There is fairly complex state
associated with these subscriptions. The union of the state for all
subscriptions to a particular resource is called the watcher
information for that resource. This state is dynamic, changing as
subscribers come and go. As a result, it is possible, and indeed
useful, to subscribe to the watcher information for a particular
resource. In order to enable this, a format is needed to describe the
state of watchers on a resource. This specification describes an XML
document format for such state.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-winfo-format-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-winfo-format-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020521141802.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-winfo-format-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-winfo-format-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020521141802.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Wed May 22 07:22:39 2002
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 HAA08987
	for ; Wed, 22 May 2002 07:22:39 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22839;
	Wed, 22 May 2002 07:21:09 -0400 (EDT)
Message-Id: <200205221121.HAA22839@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
Date: Wed, 22 May 2002 07:21:09 -0400
Content-Length: 3089
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-07.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: Session Initiation Protocol (SIP) Extensions for 
                          Presence
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-presence-07.txt
	Pages		: 26
	Date		: 21-May-02
	
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications of user presence. User
presence is defined as the willingness and ability of a user to
communicate with other users on the network. Historically, presence
has been limited to 'on-line' and 'off-line' indicators; the notion
of presence here is broader. Subscriptions and notifications of user
presence are supported by defining an event package within the
general SIP event notification framework. This protocol is also
compliant with the Common Presence and Instant Messaging (CPIM)
framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-presence-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-presence-07.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:	<20020521141811.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020521141811.I-D@ietf.org>

--OtherAccess--

--NextPart--



From lynlvl@netscape.net  Thu May 23 10:32:01 2002
Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13561
	for ; Thu, 23 May 2002 10:32:01 -0400 (EDT)
From: lynlvl@netscape.net
Received: from lynlvl@netscape.net
	by imo-d06.mx.aol.com (mail_out_v32.5.) id u.ec.403326b (16238)
	 for ; Thu, 23 May 2002 10:30:39 -0400 (EDT)
Received: from  netscape.net (mow-d03.webmail.aol.com [205.188.138.67]) by air-in03.mx.aol.com (v86.12) with ESMTP id MAILININ32-0523103039; Thu, 23 May 2002 10:30:39 -0400
Date: Thu, 23 May 2002 10:28:28 -0400
To: simple@mailman.dynamicsoft.com
Message-ID: <204C593C.11C55076.000690C1@netscape.net>
X-Mailer: Atlas Mailer 2.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 1174
Subject: [Simple] RE: simple -- confirmation of subscription -- request 337504
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: 

simple-request@mailman.dynamicsoft.com wrote:

>simple -- confirmation of subscription -- request 337504
>
>We have received a request from 192.6.111.72 for subscription of your
>email address, , to the
>simple@mailman.dynamicsoft.com mailing list.  To confirm the request,
>please send a message to simple-request@mailman.dynamicsoft.com, and
>either:
>
>- maintain the subject line as is (the reply's additional "Re:" is
>ok),
>
>- or include the following line - and only the following line - in the
>message body: 
>
>confirm 337504
>
>(Simply sending a 'reply' to this message should work from most email
>interfaces, since that usually leaves the subject line in the right
>form.)
>
>If you do not wish to subscribe to this list, please simply disregard
>this message.  Send questions to simple-admin@mailman.dynamicsoft.com.
>


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


From rsparks@dynamicsoft.com  Wed May 29 14:43:04 2002
Received: from crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09452
	for ; Wed, 29 May 2002 14:43:04 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4TIk1V21306
	for ; Wed, 29 May 2002 13:46:01 -0500
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 29 May 2002 13:40:35 -0500
Message-Id: <1022697635.1189.5.camel@dhcp150.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 81
Subject: [Simple] Test 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: 

It's quiet here. Too quiet.
Making sure its not the reflector's fault...

RjS




From daotruti@rd.francetelecom.com  Thu May 30 03:59:07 2002
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id DAA11732
	for ; Thu, 30 May 2002 03:59:05 -0400 (EDT)
Received: from parmhs2.rd.francetelecom.fr ([10.193.117.61]) by parsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 30 May 2002 09:48:40 +0200
content-class: urn:content-classes:message
Subject: RE: [Simple] Test message
Date: Thu, 30 May 2002 09:48:40 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Thread-Topic: [Simple] Test message
Thread-Index: AcIHQ4poqZafP3MwEdazbwCAXxnaMAAamPgg
From: "DAO TRUNG Tin FTRD/DAC/ISS" 
To: "Robert Sparks" ,
        
X-OriginalArrivalTime: 30 May 2002 07:48:41.0085 (UTC) FILETIME=[6A6A4AD0:01C207AE]
Content-Length: 501
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA11732
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: 

Also, making sure thats your Presence_User_Agents have the "open" status ...

TdT

-----Message d'origine-----
De : Robert Sparks [mailto:rsparks@dynamicsoft.com]
Envoyé : mercredi 29 mai 2002 20:41
À : simple@mailman.dynamicsoft.com
Objet : [Simple] Test message


It's quiet here. Too quiet.
Making sure its not the reflector's fault...

RjS



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

From tanglih@cn.ibm.com  Thu May 30 22:18:12 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14806
	for ; Thu, 30 May 2002 22:17:10 -0400 (EDT)
Received: from d23rh901.au.ibm.com (d23rh901.au.ibm.com [9.185.167.100])
	by ausmtp01.au.ibm.com (8.12.1/8.12.1) with ESMTP id g4V2A9GZ147134;
	Fri, 31 May 2002 12:10:09 +1000
Received: from d23m0018.cn.ibm.com (cnnco01.cn.ibm.com [9.181.2.71])
	by d23rh901.au.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4V2EV1104786;
	Fri, 31 May 2002 12:14:33 +1000
Subject: Status discussion again RE: [Simple] Test message
To: "DAO TRUNG Tin FTRD/DAC/ISS" 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Fri, 31 May 2002 10:16:26 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.9a |January 7, 2002) at
 31/05/2002 10:16:31
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Length: 3520
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id WAA14806
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: 

It's always open, but no driving force for input and output.:) Need
inspiration...

Here is the point. 'Open' status only describes an objective communication
possibility. We may need something like 'Eager to chat!' or 'I want to be
silent.' to describe the user's subjective attitude to communication.
One is the capability (open or closed), the other is the availability
(user's willingness). That's what we have got known from the previous
status discussion.

So can we summary status as below?
Open
    - availble  // always ready to chat
    - away      // temporarily not available
    - invisible // only available to someone I want to chat
    - busy      // not ready to chat or no immediately response to messages
    - in call   // may ready to chat later
Closed
    - unavailable      // disconnect and can't chat
    - do not disturb   // don't want to receive message but close the
channel


Best regards,

Tang Lihua
Research Member, Infrastructure Technology
IBM China Research Lab.
Phone: (8610)62986677-542 Tie line: 905-542
Email:  tanglih@cn.ibm.com


                                                                                                                      
                      "DAO TRUNG Tin                                                                                  
                      FTRD/DAC/ISS"                    To:       "Robert Sparks" ,           
                                                    
                      m.com>                           cc:                                                            
                      Sent by:                         Subject:  RE: [Simple] Test message                            
                      simple-admin@mailman.dyna                                                                       
                      micsoft.com                                                                                     
                                                                                                                      
                                                                                                                      
                      2002-05-30 15:48                                                                                
                      Please respond to "DAO                                                                          
                      TRUNG Tin FTRD/DAC/ISS"                                                                         
                                                                                                                      
                                                                                                                      



Also, making sure thats your Presence_User_Agents have the "open" status
...

TdT

-----Message d'origine-----
De : Robert Sparks [mailto:rsparks@dynamicsoft.com]
Envoyé : mercredi 29 mai 2002 20:41
À : simple@mailman.dynamicsoft.com
Objet : [Simple] Test message


It's quiet here. Too quiet.
Making sure its not the reflector's fault...

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 jdrosen@dynamicsoft.com  Fri May 31 14:10:44 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17457
	for ; Fri, 31 May 2002 14:10:44 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VIAxYH028598;
	Fri, 31 May 2002 14:10:59 -0400 (EDT)
Message-ID: <3CF7BC51.6CFF41B4@dynamicsoft.com>
Date: Fri, 31 May 2002 14:09:21 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Rohan Mahy , sipping@ietf.org,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
References: <3CF62BAE.A73C9FCD@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2867
Subject: [Simple] PIDF for buddylists, was: Re: [Sipping] request to adopt registration
 package as WG item
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: 

I think my comments on using PIDF for the reg package are covered in a
separate email; I'll focus here on the PIDF v. buddylist concept.
However, this is well into simple territory (and IMPP), so I am cc'ing
those lists.

inline:

Paul Kyzivat wrote:
> 
> comments inline.
> 

> > However, note that in cases of notifications of changes, this issue
> > becomes largely moot. Changes in presence of buddies happen one at a
> > time, so that each notify would usually contain just a single presenec
> > doc anyway. THe exception is if the buddylist server is batching the
> > notifies in order to reduce overhead.
> 
> I think batching is potentially an important application of buddylists.
> Buddylist servers may also be a good place to implement filtering to
> further reduce the traffic that
> the subscriber is exposed to. These potentials would be enhanced by
> being able to return the presence of multiple presentities in a single
> presence document.

I agree it would be helpful, although the difference between multipart
and multiple presentities in a single document is not huge. The real
problem is that this is somewhat of a new direction for PIDF late in the
game, and in PIDF was engineered to be minimalistic. Adding support for
a new feature is likely to meet with some resistance. I suppose we could
define an extension to PIDF, although to be honest, from a read of the
schema its not clear to me that a single document with multiple presence
elements is actually disallowed, in whcih case its already there. Of
course, its not likely to be interoperable...


> 
> > > it would then make
> > > sense to subscribe to presence of either presentities or buddylists
> > > without needed to know which is which.
> >
> > There are differences, most notably in the need for diffs in the case
> of
> > buddylist.
> 
> Seems to me these aren't important differences. The features that seem
> important for buddylists and less important for presence of an
> individual are also at least
> potentially useful for the presence of an individual.

Well, the diff feature is critical for buddylist, and currently
undefined for presence. Therefore, we need to have at least a new
package for it. We would also need some new attributes to support the
diffs (a partial/full flag, as we needed for watcherinfo), so we are at
least talking about an extension to PIDF even if multiple presence
elements are allowed. I would be OK with doing that; the difference
between it and multipart is not huge, but its definitely better.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

From bateman@acm.org  Sat Jun  1 10:46:09 2002
Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24142
	for ; Sat, 1 Jun 2002 10:46:09 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17EA1c-0000Sf-00; Sat, 01 Jun 2002 15:38:36 +0100
Received: from modem-392.python.dialup.pol.co.uk ([217.134.209.136] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17EA1Z-0004I3-00; Sat, 01 Jun 2002 15:38:33 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" 
Cc: 
Subject: RE: Status discussion again RE: [Simple] Test message
Date: Sat, 1 Jun 2002 15:37:35 +0100
Organization: VisionTech Limited
Message-ID: <001301c20979$e23d34b0$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: 
Importance: Normal
Content-Length: 1834
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: 

On 31 May 2002 03:16, Li Hua Tang wrote:
> 
> It's always open, but no driving force for input and output.:) Need 
> inspiration...
> 
> Here is the point. 'Open' status only describes an objective 
> communication possibility. We may need something like 'Eager to chat!'

> or 'I want to be silent.' to describe the user's subjective attitude 
> to communication. One is the capability (open or closed), the other is

> the availability (user's willingness). That's what we have got known 
> from the previous status discussion.
> 
> So can we summary status as below?
> Open
>     - availble  // always ready to chat
>     - away      // temporarily not available
>     - invisible // only available to someone I want to chat
>     - busy      // not ready to chat or no immediately response to
messages
>     - in call   // may ready to chat later
> Closed
>     - unavailable      // disconnect and can't chat
>     - do not disturb   // don't want to receive message but close the
> channel


(Apart from the fact that invisible can't really be a state (visibly
invisible?) so should look just like disconnnected,) I'll try to
reiterate my thoughts on this discussion from a different tack.

Why is it important to try to distill the different IM status values
into a definitive set? I don't believe that the group will reach
consensus on a definitive minimal set because one person's busy is
another's do-not-disturb. Doesn't the benefit come from having a
*reasonably* small and *well-known* vocabulary for IM status values? You
don't even really need to decide which are open and which are closed -
PIDF allows for that already.

Perhaps rather than trying to find the set of status values, attention
might be focussed on the reason for having such a set and the values
might fall out of that discussion?

Regards,

Adrian.



From wayne.carr@intel.com  Tue Jun  4 15:14:26 2002
Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05814
	for ; Tue, 4 Jun 2002 15:14:25 -0400 (EDT)
Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37])
	by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.48 2002/05/24 00:39:04 root Exp $) with ESMTP id g54JBQL21171
	for ; Tue, 4 Jun 2002 19:11:26 GMT
Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108])
	by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.22 2002/05/24 00:38:22 root Exp $) with SMTP id g54JAk015414
	for ; Tue, 4 Jun 2002 19:10:46 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.42.26])
 by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002060412121115592
 ; Tue, 04 Jun 2002 12:12:11 -0700
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 4 Jun 2002 12:12:50 -0700
Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C394@orsmsx120.jf.intel.com>
From: "Carr, Wayne" 
To: "'Jonathan Rosenberg'" ,
        Paul Kyzivat 
Cc: Rohan Mahy , sipping@ietf.org,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
Subject: RE: [Simple] PIDF for buddylists, was: Re: [Sipping] request to a
	dopt registration package as WG item
Date: Tue, 4 Jun 2002 12:12:43 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4056
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: 

> from a read of the schema its not clear to me that a single document
> with multiple presence elements is actually disallowed, in whcih case 
> its already there.

XML documents have a single root element.  In PIDF, presence is the root
element so there's only one presence element.  

Someone could define another XML format with some other root element that
included multiple PIDF presence elements inside that other root element. (or
some non XML format could carry multiple XML documents)

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, May 31, 2002 11:09 AM
> To: Paul Kyzivat
> Cc: Rohan Mahy; sipping@ietf.org; simple@mailman.dynamicsoft.com;
> impp@iastate.edu
> Subject: [Simple] PIDF for buddylists, was: Re: [Sipping] request to
> adopt registration package as WG item
> 
> 
> I think my comments on using PIDF for the reg package are covered in a
> separate email; I'll focus here on the PIDF v. buddylist concept.
> However, this is well into simple territory (and IMPP), so I am cc'ing
> those lists.
> 
> inline:
> 
> Paul Kyzivat wrote:
> > 
> > comments inline.
> > 
> 
> > > However, note that in cases of notifications of changes, 
> this issue
> > > becomes largely moot. Changes in presence of buddies 
> happen one at a
> > > time, so that each notify would usually contain just a 
> single presenec
> > > doc anyway. THe exception is if the buddylist server is 
> batching the
> > > notifies in order to reduce overhead.
> > 
> > I think batching is potentially an important application of 
> buddylists.
> > Buddylist servers may also be a good place to implement filtering to
> > further reduce the traffic that
> > the subscriber is exposed to. These potentials would be enhanced by
> > being able to return the presence of multiple presentities 
> in a single
> > presence document.
> 
> I agree it would be helpful, although the difference between multipart
> and multiple presentities in a single document is not huge. The real
> problem is that this is somewhat of a new direction for PIDF 
> late in the
> game, and in PIDF was engineered to be minimalistic. Adding 
> support for
> a new feature is likely to meet with some resistance. I 
> suppose we could
> define an extension to PIDF, although to be honest, from a read of the
> schema its not clear to me that a single document with 
> multiple presence
> elements is actually disallowed, in whcih case its already there. Of
> course, its not likely to be interoperable...
> 
> 
> > 
> > > > it would then make
> > > > sense to subscribe to presence of either presentities 
> or buddylists
> > > > without needed to know which is which.
> > >
> > > There are differences, most notably in the need for diffs 
> in the case
> > of
> > > buddylist.
> > 
> > Seems to me these aren't important differences. The 
> features that seem
> > important for buddylists and less important for presence of an
> > individual are also at least
> > potentially useful for the presence of an individual.
> 
> Well, the diff feature is critical for buddylist, and currently
> undefined for presence. Therefore, we need to have at least a new
> package for it. We would also need some new attributes to support the
> diffs (a partial/full flag, as we needed for watcherinfo), so 
> we are at
> least talking about an extension to PIDF even if multiple presence
> elements are allowed. I would be OK with doing that; the difference
> between it and multipart is not huge, but its definitely better.
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From pkyzivat@cisco.com  Wed Jun  5 17:03:16 2002
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 RAA10102
	for ; Wed, 5 Jun 2002 17:03:15 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g55L0uCL021864;
	Wed, 5 Jun 2002 17:00:57 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAL50294;
	Wed, 5 Jun 2002 17:05:02 -0400 (EDT)
Message-ID: <3CFE7BE9.3F84A182@cisco.com>
Date: Wed, 05 Jun 2002 17:00:25 -0400
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: Rohan Mahy , sipping@ietf.org,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
References: <3CF62BAE.A73C9FCD@cisco.com> <3CF7BC51.6CFF41B4@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 4451
Subject: [Simple] Re: PIDF for buddylists
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: 

Jonathan,

Maybe I missed a document. You mention below the importance of diffs when reporting presence for buddylists. But I don't find any mention of diffs in
draft-rosenberg-simple-buddylist-package-00. Or do you just mean that delivery of presence documents individually from each member of the buddylist as it changes is a form
of diff?

Upon thinking about this further, I think the existing presence document might be sufficient.

Consider - is there any fundamental difference between a named buddylist and an address of record? If I view a buddylist as an address of record, then to populate it I
simply REGISTER the addresses of the buddies as contacts. Then instead of a BLSS, I need a presence server with access to the location service populated by the registrar.
And instead of a presence document with multiple presentities, I get a presence document with a single presentity (my buddylist name) and a bunch of contacts for my
buddies. 

This would put a high priority on permitting diffs in the presence documents.

Having buddylists represented this way would provide other opportunities to use them.

	Paul

Jonathan Rosenberg wrote:
> 
> I think my comments on using PIDF for the reg package are covered in a
> separate email; I'll focus here on the PIDF v. buddylist concept.
> However, this is well into simple territory (and IMPP), so I am cc'ing
> those lists.
> 
> inline:
> 
> Paul Kyzivat wrote:
> >
> > comments inline.
> >
> 
> > > However, note that in cases of notifications of changes, this issue
> > > becomes largely moot. Changes in presence of buddies happen one at a
> > > time, so that each notify would usually contain just a single presenec
> > > doc anyway. THe exception is if the buddylist server is batching the
> > > notifies in order to reduce overhead.
> >
> > I think batching is potentially an important application of buddylists.
> > Buddylist servers may also be a good place to implement filtering to
> > further reduce the traffic that
> > the subscriber is exposed to. These potentials would be enhanced by
> > being able to return the presence of multiple presentities in a single
> > presence document.
> 
> I agree it would be helpful, although the difference between multipart
> and multiple presentities in a single document is not huge. The real
> problem is that this is somewhat of a new direction for PIDF late in the
> game, and in PIDF was engineered to be minimalistic. Adding support for
> a new feature is likely to meet with some resistance. I suppose we could
> define an extension to PIDF, although to be honest, from a read of the
> schema its not clear to me that a single document with multiple presence
> elements is actually disallowed, in whcih case its already there. Of
> course, its not likely to be interoperable...
> 
> >
> > > > it would then make
> > > > sense to subscribe to presence of either presentities or buddylists
> > > > without needed to know which is which.
> > >
> > > There are differences, most notably in the need for diffs in the case
> > of
> > > buddylist.
> >
> > Seems to me these aren't important differences. The features that seem
> > important for buddylists and less important for presence of an
> > individual are also at least
> > potentially useful for the presence of an individual.
> 
> Well, the diff feature is critical for buddylist, and currently
> undefined for presence. Therefore, we need to have at least a new
> package for it. We would also need some new attributes to support the
> diffs (a partial/full flag, as we needed for watcherinfo), so we are at
> least talking about an extension to PIDF even if multiple presence
> elements are allowed. I would be OK with doing that; the difference
> between it and multipart is not huge, but its definitely better.
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP

From jdrosen@dynamicsoft.com  Thu Jun  6 15:28:01 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13686
	for ; Thu, 6 Jun 2002 15:28:01 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.87])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g56JSJYH007361;
	Thu, 6 Jun 2002 15:28:19 -0400 (EDT)
Message-ID: <3CFFB76F.2070907@dynamicsoft.com>
Date: Thu, 06 Jun 2002 15:26:39 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Rohan Mahy , sipping@ietf.org,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
References: <3CFE7BE9.3F84A182@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2446
Subject: [Simple] Re: PIDF for buddylists
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: 


Paul Kyzivat wrote:
> Jonathan,
> 
> Maybe I missed a document. You mention below the importance of diffs
> when reporting presence for buddylists. But I don't find any mention of
> diffs in
> draft-rosenberg-simple-buddylist-package-00. 

You're right, actually. I thought about this more since posting, and its 
not really needed. With watcherinfo (which does have diffs), you are 
again getting notified about a list of things. However, the list itself 
is dynamic and conveyed through the notifications itself. You therefore 
need to have a flag as to whether the update is full state or partial 
state, so that you know whether or not to delete a watcher because their 
entry is not in the list (delete for full state, don't for partial).

Now, in the case of buddylists, presumably the list itself is known to 
the client through other means, and therefore, this particular flag is 
not needed.

> Or do you just mean that
> delivery of presence documents individually from each member of the
> buddylist as it changes is a form
> of diff?
> 
> Upon thinking about this further, I think the existing presence document
> might be sufficient.

Wayne convinced me that we need to define a trivial new format; one that 
has a new top-level XML element, and the sub-element is presence from PIDF.

> 
> Consider - is there any fundamental difference between a named buddylist
> and an address of record? If I view a buddylist as an address of record,
> then to populate it I
> simply REGISTER the addresses of the buddies as contacts. 

Are you proposing an actual REGISTER for this? I think this is a pretty 
big deviation from the meaning of REGISTER.

> Then instead
> of a BLSS, I need a presence server with access to the location service
> populated by the registrar.
> And instead of a presence document with multiple presentities, I get a
> presence document with a single presentity (my buddylist name) and a
> bunch of contacts for my
> buddies. 

How would you have out the contacts for the buddies? You've shifted 
everything down a layer, so the bottom falls out as far as I can tell...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From pkyzivat@cisco.com  Thu Jun  6 17:23:03 2002
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 RAA14030
	for ; Thu, 6 Jun 2002 17:23:03 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g56LM87f007419;
	Thu, 6 Jun 2002 17:22:09 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAL57082;
	Thu, 6 Jun 2002 17:26:16 -0400 (EDT)
Message-ID: <3CFFD262.28CDB056@cisco.com>
Date: Thu, 06 Jun 2002 17:21:38 -0400
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: Rohan Mahy , sipping@ietf.org,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
References: <3CFE7BE9.3F84A182@cisco.com> <3CFFB76F.2070907@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5027
Subject: [Simple] Re: PIDF for buddylists
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: 

Comments inline. Best results when viewed in fixed width font.

	Paul

Jonathan Rosenberg wrote:
> 
> Paul Kyzivat wrote:
> > Jonathan,
> >
> > Maybe I missed a document. You mention below the importance of diffs
> > when reporting presence for buddylists. But I don't find any mention of
> > diffs in
> > draft-rosenberg-simple-buddylist-package-00.
> 
> You're right, actually. I thought about this more since posting, and its
> not really needed. With watcherinfo (which does have diffs), you are
> again getting notified about a list of things. However, the list itself
> is dynamic and conveyed through the notifications itself. You therefore
> need to have a flag as to whether the update is full state or partial
> state, so that you know whether or not to delete a watcher because their
> entry is not in the list (delete for full state, don't for partial).
> 
> Now, in the case of buddylists, presumably the list itself is known to
> the client through other means, and therefore, this particular flag is
> not needed.

I'm not sure this is a reasonable assumption. As long as we remain silent on how the list is managed, it is risky to assume that every subscriber has complete knowledge of
the list content.

There seem to be two reasonable alternatives here: provide diff information on presence reports from buddylists, or else provide a defined way to monitor the content of a
buddylist itself.

> 
> > Or do you just mean that
> > delivery of presence documents individually from each member of the
> > buddylist as it changes is a form
> > of diff?
> >
> > Upon thinking about this further, I think the existing presence document
> > might be sufficient.
> 
> Wayne convinced me that we need to define a trivial new format; one that
> has a new top-level XML element, and the sub-element is presence from PIDF.

Depends on outcome of discussion below. Possibly some form of change will be required.

> 
> >
> > Consider - is there any fundamental difference between a named buddylist
> > and an address of record? If I view a buddylist as an address of record,
> > then to populate it I
> > simply REGISTER the addresses of the buddies as contacts.
> 
> Are you proposing an actual REGISTER for this? I think this is a pretty
> big deviation from the meaning of REGISTER.

I am proposing (as a strawhorse) that the concept of buddylist be subsumed into a slightly broader role for address of record. This is largely a conceptual change - I don't
think the mechanics of managing address of record need to change.

It is already permissible to populate a location service with an address of record either by using REGISTER or by some other method. One other method might be by uploading
a buddylist.

> 
> > Then instead
> > of a BLSS, I need a presence server with access to the location service
> > populated by the registrar.
> > And instead of a presence document with multiple presentities, I get a
> > presence document with a single presentity (my buddylist name) and a
> > bunch of contacts for my
> > buddies.
> 
> How would you have out the contacts for the buddies? You've shifted
> everything down a layer, so the bottom falls out as far as I can tell...

Yeah, I didn't bother to mention that, and you caught me. :-)

What I have in mind is that presence should be viewed as hierarchical. It is already that way, sort of, but only two levels are acknowledged in the hierarchy. The
presentity can have status, and each of the contacts can have status.

In registrations, it is permissible for the Contacts defining one address of record to themselves be addresses of record that have lower level definitions, etc. (I realize
there aren't many, if any, published use cases for this.)

If you want to understand the full hierarchical structure of registrations of that sort, you have to drill down one level at a time. It should be possible to do exactly the
same thing for presence. Alternately, it might be more helpful for a presence subscription to be recursive, perhaps optionally. (This would be something like what has been
proposed for the conference info event package.)

As an example, consider the following hierarchy:

                     everybody@bedrock.com
                     /         |         \
    barney@bedrock.com  fred@bedrock.com pebbles@bedrock.com
          /             /      |        \        \
        ...            /       |         \       ...
                      /        |          \
                     /         |           \
fred.mobile@cells.r.us fflintstone@msn.com 1234@bedrock.com;user=phone


These could all be valid sip addresses to call. They are also potentially all valid presentities to request presence documents for. What is the difference if I ask for the
presence of 'everybody' and get info about its three subordinates, or if I ask for the presence of 'fred' and get the status of his three alternate devices? 

Why does there have to be an arbitrary distinction that 'everybody' is a buddylist, but 'fred' is an address of record?

	Paul

From bryan.thale@motorola.com  Thu Jun  6 19:16:56 2002
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14374
	for ; Thu, 6 Jun 2002 19:16:55 -0400 (EDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA16717 for ; Thu, 6 Jun 2002 16:15:20 -0700 (MST)]
Received: [from artibeus.nsr.labs.mot.com (artibeus.nsr.labs.mot.com [173.23.95.73]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA04827 for ; Thu, 6 Jun 2002 16:15:38 -0700 (MST)]
Received: from motorola.com (localhost [127.0.0.1])
	by artibeus.nsr.labs.mot.com (8.11.6/8.11.6) with ESMTP id g56NHnu02826
	for ; Thu, 6 Jun 2002 18:17:49 -0500
Message-ID: <3CFFED9D.B807A1DB@motorola.com>
Date: Thu, 06 Jun 2002 18:17:49 -0500
From: Bryan Thale 
Organization: Networks & Infrastructure Research, Motorola Labs
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: PIDF for buddylists
References: <3CFE7BE9.3F84A182@cisco.com> <3CFFD262.28CDB056@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1933
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: 

> As an example, consider the following hierarchy:
>
>                      everybody@bedrock.com
>                      /         |         \
>     barney@bedrock.com  fred@bedrock.com pebbles@bedrock.com
>           /             /      |        \        \
>         ...            /       |         \       ...
>                       /        |          \
>                      /         |           \
> fred.mobile@cells.r.us fflintstone@msn.com 1234@bedrock.com;user=phone
>
> These could all be valid sip addresses to call. They are also potentially all valid presentities to request presence documents for. What is the difference if I ask for the
> presence of 'everybody' and get info about its three subordinates, or if I ask for the presence of 'fred' and get the status of his three alternate devices?
>
> Why does there have to be an arbitrary distinction that 'everybody' is a buddylist, but 'fred' is an address of record?

Looking at it from the other direction, what does it mean to call a
buddylist?

Placing a call to 'fred' will eventually resolve down to one device or
at least one user.  That probably isn't what would be intended by a call
to 'everybody' which sounds
more like a multiparty call.  If buddylists and AoRs are
indistinguishable, how would a SIP application know what is the right
thing to do?

> Consider - is there any fundamental difference between a named buddylist
> and an address of record?

Isn't the difference that a buddylist is simply a handle used to
conveniently reference a group of AoRs for the purpose of reporting
presence info while an AoR is an alias
whose purpose is to stand in for a particular destination address until
such time as it can be fully resolved?  Thus, a buddylist represents a
group of information sources
while an AoR represents a single destination.

Bryan.

--
Bryan Thale
Networks & Infrastructure Research, Motorola Labs
mailto:bryan.thale@motorola.com

From bryan.thale@motorola.com  Thu Jun  6 19:04:41 2002
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14308
	for ; Thu, 6 Jun 2002 19:04:41 -0400 (EDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA11060 for ; Thu, 6 Jun 2002 16:03:05 -0700 (MST)]
Received: [from artibeus.nsr.labs.mot.com (artibeus.nsr.labs.mot.com [173.23.95.73]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA02385 for ; Thu, 6 Jun 2002 16:03:05 -0700 (MST)]
Received: from motorola.com (localhost [127.0.0.1])
	by artibeus.nsr.labs.mot.com (8.11.6/8.11.6) with ESMTP id g56N5Yu02794
	for ; Thu, 6 Jun 2002 18:05:34 -0500
Message-ID: <3CFFEABE.F3E3D839@motorola.com>
Date: Thu, 06 Jun 2002 18:05:34 -0500
From: Bryan Thale 
Organization: Networks & Infrastructure Research, Motorola Labs
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: PIDF for buddylists
References: <3CFE7BE9.3F84A182@cisco.com> <3CFFD262.28CDB056@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1936
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: 

> As an example, consider the following hierarchy:
>
>                      everybody@bedrock.com
>                      /         |         \
>     barney@bedrock.com  fred@bedrock.com pebbles@bedrock.com
>           /             /      |        \        \
>         ...            /       |         \       ...
>                       /        |          \
>                      /         |           \
> fred.mobile@cells.r.us fflintstone@msn.com 1234@bedrock.com;user=phone
>
> These could all be valid sip addresses to call. They are also potentially all valid presentities to request presence documents for. What is the difference if I ask for the
> presence of 'everybody' and get info about its three subordinates, or if I ask for the presence of 'fred' and get the status of his three alternate devices?
>
> Why does there have to be an arbitrary distinction that 'everybody' is a buddylist, but 'fred' is an address of record?

Looking at it from the other direction, what does it mean to call a buddylist?

Placing a call to 'fred' will eventually resolve down to one device or at least one user.  That probably isn't what would be intended by a call to 'everybody' which sounds
more like a multiparty call.  If buddylists and AoRs are indistinguishable, how would a SIP application know what is the right thing to do?

> Consider - is there any fundamental difference between a named buddylist
> and an address of record?

Isn't the difference that a buddylist is simply a handle used to conveniently reference a group of AoRs for the purpose of reporting presence info while an AoR is an alias
whose purpose is to stand in for a particular destination address until such time as it can be fully resolved?  Thus, a buddylist represents a group of information sources
while an AoR represents a single destination.

Bryan.

--
Bryan Thale
Networks & Infrastructure Research, Motorola Labs
mailto:bryan.thale@motorola.com




From pkyzivat@cisco.com  Fri Jun  7 13:30:09 2002
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 NAA17476
	for ; Fri, 7 Jun 2002 13:30:09 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g57HTKQh029149;
	Fri, 7 Jun 2002 13:29:21 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAL61233;
	Fri, 7 Jun 2002 13:33:28 -0400 (EDT)
Message-ID: <3D00ED53.93AF8D@cisco.com>
Date: Fri, 07 Jun 2002 13:28:51 -0400
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: Bryan Thale 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Re: PIDF for buddylists
References: <3CFE7BE9.3F84A182@cisco.com> <3CFFD262.28CDB056@cisco.com> <3CFFEABE.F3E3D839@motorola.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1683
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: 


Bryan Thale wrote:
> 
> Looking at it from the other direction, what does it mean to call a buddylist?
> 
> Placing a call to 'fred' will eventually resolve down to one device or at least one user.  That probably isn't what would be intended by a call to 'everybody' which sounds
> more like a multiparty call.  If buddylists and AoRs are indistinguishable, how would a SIP application know what is the right thing to do?

Well, maybe I should have called it 'anybody' instead of 'everybody'.

It certainly is plausible that I want just want to talk to any member of bedrock. In this respect it is just like calling 'fred' and getting any of fred's devices.

Calling all of them is harder, in many respects. It probably requires establishing a conference mixer, etc. If that is what you want, it can be achieved in a variety of
ways. You could subscribe to presence, and then call all the contacts that are present. Or you could send an INVITE with a Request-Disposition of 'redirect'. This would
return you all the contact addresses of the members in a 300 response, and you could use that to do multiple invitations.

> 
> > Consider - is there any fundamental difference between a named buddylist
> > and an address of record?
> 
> Isn't the difference that a buddylist is simply a handle used to conveniently reference a group of AoRs for the purpose of reporting presence info while an AoR is an alias
> whose purpose is to stand in for a particular destination address until such time as it can be fully resolved?  Thus, a buddylist represents a group of information sources
> while an AoR represents a single destination.

They still sound like the same thing to me.

	Paul

From jdrosen@dynamicsoft.com  Sun Jun  9 01:57:11 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23516
	for ; Sun, 9 Jun 2002 01:57:11 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.53])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g595vRYH009093;
	Sun, 9 Jun 2002 01:57:27 -0400 (EDT)
Message-ID: <3D02EDE4.4080809@dynamicsoft.com>
Date: Sun, 09 Jun 2002 01:55:48 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Rohan Mahy , sipping@ietf.org,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
References: <3CFFD262.28CDB056@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 5311
Subject: [Simple] Re: PIDF for buddylists
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: 


Paul Kyzivat wrote:
 >>
>>Now, in the case of buddylists, presumably the list itself is known to
>>the client through other means, and therefore, this particular flag is
>>not needed.
> 
> 
> I'm not sure this is a reasonable assumption. As long as we remain
> silent on how the list is managed, it is risky to assume that every
> subscriber has complete knowledge of
> the list content.

Well, the question is whether this package is the right thing to let 
someone know that the list itself has changed, as opposed to just the 
presence of a user on the list changing.

> 
> There seem to be two reasonable alternatives here: provide diff
> information on presence reports from buddylists, or else provide a
> defined way to monitor the content of a
> buddylist itself.

Right. My preference is to have a separate package for that. Indeed, 
there are several "lists" that one might have and wish to watch for 
changes in - authorization lists, deny lists, group lists (for group IM, 
for example), and so on. Itd' be nice those were all handled consistently.


>>Are you proposing an actual REGISTER for this? I think this is a
>>pretty
>>big deviation from the meaning of REGISTER.
> 
> 
> I am proposing (as a strawhorse) that the concept of buddylist be
> subsumed into a slightly broader role for address of record. This is
> largely a conceptual change - I don't
> think the mechanics of managing address of record need to change.
> 
> It is already permissible to populate a location service with an address
> of record either by using REGISTER or by some other method. One other
> method might be by uploading
> a buddylist.

I am still very uncomfortable with this. If an INVITE arrives for that 
"address of record" the call will fork to the people in your buddy list. 
I don't think this is what you really want to have happen. Probably you 
really want a conference call. Thats generally different from a call to 
an AOR that represents a user, as we know it today. Since I personally 
would only communicate with one of my registered contacts, forking and 
then cancelling unanswered branches makes sense. However, if the AOR 
represents a group, all of the "registered contacts" would communicate, 
and therefore, the conference call makes more sense.




>>How would you have out the contacts for the buddies? You've shifted
>>everything down a layer, so the bottom falls out as far as I can
>> tell...
> 
> Yeah, I didn't bother to mention that, and you caught me. :-)
> 
> What I have in mind is that presence should be viewed as hierarchical.
> It is already that way, sort of, but only two levels are acknowledged in
> the hierarchy. The
> presentity can have status, and each of the contacts can have status.
> 
> In registrations, it is permissible for the Contacts defining one
> address of record to themselves be addresses of record that have lower
> level definitions, etc. (I realize
> there aren't many, if any, published use cases for this.)

Generally, call forwarding.

> 
> If you want to understand the full hierarchical structure of
> registrations of that sort, you have to drill down one level at a time.
> It should be possible to do exactly the
> same thing for presence. Alternately, it might be more helpful for a
> presence subscription to be recursive, perhaps optionally. (This would
> be something like what has been
> proposed for the conference info event package.)
> 
> As an example, consider the following hierarchy:
> 
>                      everybody@bedrock.com
>                      /         |         \
>     barney@bedrock.com  fred@bedrock.com pebbles@bedrock.com
>           /             /      |        \        \
>         ...            /       |         \       ...
>                       /        |          \
>                      /         |           \
> fred.mobile@cells.r.us fflintstone@msn.com 1234@bedrock.com;user=phone
> 
> 
> These could all be valid sip addresses to call. They are also
> potentially all valid presentities to request presence documents for.
> What is the difference if I ask for the
> presence of 'everybody' and get info about its three subordinates, or if
> I ask for the presence of 'fred' and get the status of his three
> alternate devices? 

At the very least, I think users who subscribe to this thing will want 
to know the difference.

Beyond that, there is likely to be differences in the information you 
would want to convey at each level. Indeed, in PIDF today, very little 
information exists at the presentity level; its all at the contact 
level. To show that your model is sensible, I think you need to 
demonstarte that the same information and state applies to any level in 
the hierarchy above.

Don't get me wrong - I am not saying that what you are proposing is a
bad idea. In fact, its quite intriguing. But, its a big deviation from 
PIDF today, and from the architectural model that has been the 
foundation of PIDF for some time (RFC 2778).

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From Ya-Ching.Tan@icn.siemens.de  Mon Jun 10 03:56:50 2002
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27780
	for ; Mon, 10 Jun 2002 03:56:48 -0400 (EDT)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA14619;
	Mon, 10 Jun 2002 09:55:23 +0200 (MET DST)
Received: from mchh168e.mch4.siemens.de ([139.21.130.175])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA02850;
	Mon, 10 Jun 2002 09:55:25 +0200 (MET DST)
Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Mon, 10 Jun 2002 09:55:25 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E08@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 
To: "'jdrosen@dynamicsoft.com'" 
Cc: "'simple@mailman.dynamicsoft.com'" 
Subject: [SIMPLE] Comments on draft-ietf-simple-presence-07
Date: Mon, 10 Jun 2002 09:55:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1279
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: 

Section 9.1 Privacy
The 2nd bullet  "User may not want to reveal that they
have accepted subscription from certain users".

I can understand if user may not want to reveal that
he has _rejected_ subscriptions from certain users. 
That's polite blocking. But I am not aware of not 
revealing accepting subscriptions. Does the user 
reject it, but the present agent actually sets up the
subscription? That can't work. We can't send NOTIFY
to a subscriber if his subscription appeared (to him) to
have been rejected.

Nits:

Section 4   2nd paragraph

o "The subcription is carried along SIP proxies as any other 
    request would be".

   "subscription" => "SUBSCRIBE request"

o "...it eventually arrives at a presence server, which can 
   either terminate the subscription..."

   "terminate the subscription" => "serves as  the 
   terminating point for the SUBSCRIBE request and
   handles the subscription"

Section 4  6th paragraph

o "This (refresh) SUBSCRIBE is nearly identical to the 
    initial one, but contains the dialog identifier, different 
    sequence numbers, and a set of Route headers..."
    =>
    "...but contains the To tag, a higher sequence number,
    and possibly a set of Route headers..."

Section 9.2
o "http" => "HTTP"


Regards,
Ya-Ching





From pkyzivat@cisco.com  Mon Jun 10 15:57:10 2002
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 PAA02087
	for ; Mon, 10 Jun 2002 15:57:10 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5AJtieL026067;
	Mon, 10 Jun 2002 15:55:44 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAL70374;
	Mon, 10 Jun 2002 15:59:51 -0400 (EDT)
Message-ID: <3D050421.72F23DAC@cisco.com>
Date: Mon, 10 Jun 2002 15:55:13 -0400
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: sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu
References: <3CFFD262.28CDB056@cisco.com> <3D02EDE4.4080809@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 8838
Subject: [Simple] Re: PIDF for buddylists
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: 

Jonathan - more comments below.

	Paul

Jonathan Rosenberg wrote:
> 
> > There seem to be two reasonable alternatives here: provide diff
> > information on presence reports from buddylists, or else provide a
> > defined way to monitor the content of a
> > buddylist itself.
> 
> Right. My preference is to have a separate package for that. Indeed,
> there are several "lists" that one might have and wish to watch for
> changes in - authorization lists, deny lists, group lists (for group IM,
> for example), and so on. Itd' be nice those were all handled consistently.

Whether there is a separate package or not, there may still be a need for diff information. 

The presence event package doesn't provide for diffs. In the absence of filters, it returns all information about the presentity, including all tuples, in each
notification.

Your proposal has distinguished buddylist from presentity. The buddylist eventpackage returns a full set of information about all buddy presentities upon an initial
subscription, and thereafter effectively returns diffs in the sense that it only returns information about individual buddies whose presence status has changed.

So the effect is that there is support for diffs on some but not all of the information. This makes sense if you assume that there might be a lot of buddies per buddylist,
but not a lot of tuples per presentity. But this is only an assumption. There are plausible cases where there might be many tuples for a presentity.

Now I have suggested we merge the concept of a buddylist that has a number of presentities with the concept of a presentity that has a number of tuples. If we do this, then
it gets harder to distinguish when to use a diff behavior and when not to. While this presents a problem to be solved, once it is solved, it will work when the application
is conceptually a presentity with lots of tuples as well as when it is a buddylist with lots of buddies.

One solution would be analogous to what you have already proposed: use two different event package names to distinguish whether the returned notification stream uses diffs
or not. (Even though the addressed entity being subscribed to is an address of record in both cases.) But while this would still be possible, I think there is probably a
better choice. For instance, this might be incorporated into a filter definition.  

> > I am proposing (as a strawhorse) that the concept of buddylist be
> > subsumed into a slightly broader role for address of record. This is
> > largely a conceptual change - I don't
> > think the mechanics of managing address of record need to change.
> >
> > It is already permissible to populate a location service with an address
> > of record either by using REGISTER or by some other method. One other
> > method might be by uploading
> > a buddylist.
> 
> I am still very uncomfortable with this. If an INVITE arrives for that
> "address of record" the call will fork to the people in your buddy list.
> I don't think this is what you really want to have happen. Probably you
> really want a conference call. Thats generally different from a call to
> an AOR that represents a user, as we know it today. Since I personally
> would only communicate with one of my registered contacts, forking and
> then cancelling unanswered branches makes sense. However, if the AOR
> represents a group, all of the "registered contacts" would communicate,
> and therefore, the conference call makes more sense.

Which makes sense depends on context. There are lots of useful examples of a group address that I might want to call and really only want to talk to one member of the
group. For instance I might want to call anybody in a particular household, or in a department of an organization.

Nor do I think a given list will only be used one way or the other. There are times when I might want to send a reminder to all members of a group, and other times when I
just need to deal with some member of the group. So this is a matter of expressing the desired manner of using the list, rather than a characteristic of the definition of
the list.

> At the very least, I think users who subscribe to this thing will want
> to know the difference.

If we can come up with a clear definition of what the difference is, then it should be relatively simple to encode that in a presence document, e.g. as a new sort of status
value.

The hard part is defining the difference. This is *already* a problem: suppose I have two devices, a phone that does voice, and a PC that does chat. I register them both
with the same address of record: sip:paul@foo.org. If this same information is translated or rerepresented as a presence document, then it will appear as two tuples for the
presentity. 

What are the implications of doing this:

1) Suppose you have a device capable of either voice or chat. It can generate in invitation offering both. If you send an invitation to my address of record, it will
presumably be forked, and one or the other of my endpoints will be chosen, but you will have little choice in which.

2) A suitable presence client will show them both, perhaps annotated to indicate what media each supports. Using the same device as above, coupled to the presence client,
you can choose which device to send an invitation to. If you wish, you can initiate an invitation to each, and so use both media.

3) In (2) I assumed that your presence-coupled UA sent invitations to the contact address of a tuple. If instead it send the invitation to the presentity address (address
of record) then the results are more like (1), but more disconcerting. I may think I am calling your phone but get your chat UA instead.

There would perhaps be a better, or at least more consistent, result if we consider the location service to have the full set of information that the presence document
represents for a presentity. A forking proxy for an address-of-record would be able to use all of this information to process a call. But to get reasonable and consistent
behavior for calls that are presence driven and those that are not, the presence information almost certainly needs to be enriched to indicate *why* multiple tuples are
present and how choices among them should be made. This is similar to the information provided by callerprefs, but may need further enrichment.

> 
> Beyond that, there is likely to be differences in the information you
> would want to convey at each level. Indeed, in PIDF today, very little
> information exists at the presentity level; its all at the contact
> level. To show that your model is sensible, I think you need to
> demonstarte that the same information and state applies to any level in
> the hierarchy above.

The presentity level information is pretty minimal in pidf today. Its not clear whether this is a problem or not. In large measure the extra information at the tuple level
is there to characterize the differences between the tuples, or the intended role of each tuple. As long as you assume there is a single top level element, then it needs
less of this information.

OTOH, there is some merit in producing a rollup for the top of the hierarchy - e.g. a status value that somehow represents the aggregate status. This is probably pretty
easy as long as you restrict status to OPEN and CLOSED. (Presentity is OPEN if any of the tuples are OPEN.) However this is probably simplistic. There may be no general
algorithm for deriving the status of the presentity from the status' of the tuples. If this has to be explicitly generated, then it may not be worth providing.

One simple way of reflecting the general model would be to change the schema so that a  could contain another  as an alternative to anyURL. This would
permit the hierarchy to be exploded in a single document. But even without this, there is nothing to prevent interpretation of the URL in a  as a reference to
another presentity.

> 
> Don't get me wrong - I am not saying that what you are proposing is a
> bad idea. In fact, its quite intriguing. But, its a big deviation from
> PIDF today, and from the architectural model that has been the
> foundation of PIDF for some time (RFC 2778).

Hey, I'm happy not be be considered insane for proposing it. :-)

I reread that, and I don't think what I am suggesting does a violence to that model. Of course that model doesn't suggest or imply this sort of implementation, but neither
does it seem to prevent it. But were we to go in this direction it would probably be advisable to discuss these concepts specifically.

I realize that this is still half baked. I'm just testing the ideas now. My earlier comments on the registration event package were also part of this same concept. I
haven't responded to your comments on that because that part is still in the oven.

	Paul

From bateman@acm.org  Mon Jun 10 17:53:05 2002
Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02473
	for ; Mon, 10 Jun 2002 17:53:05 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17HX4e-0008Qi-00; Mon, 10 Jun 2002 22:51:40 +0100
Received: from modem-3510.zebra.dialup.pol.co.uk ([81.76.157.182] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17HX4e-0006YL-00; Mon, 10 Jun 2002 22:51:40 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Paul Kyzivat'" ,
        "'Jonathan Rosenberg'" 
Cc: , , 
Date: Mon, 10 Jun 2002 22:50:26 +0100
Organization: VisionTech Limited
Message-ID: <000d01c210c8$d7d3a2b0$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <3D050421.72F23DAC@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 930
Subject: [Simple] RE: PIDF for buddylists
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: 

On 10 June 2002 20:55, Paul Kyzivat wrote:
> Jonathan Rosenberg wrote:
> > Don't get me wrong - I am not saying that what you are proposing is 
> > a
> > bad idea. In fact, its quite intriguing. But, its a big deviation
from 
> > PIDF today, and from the architectural model that has been the 
> > foundation of PIDF for some time (RFC 2778).
> 
> Hey, I'm happy not be be considered insane for proposing it. :-)
> 
> I reread that, and I don't think what I am suggesting does a violence 
> to that model. Of course that model doesn't suggest or imply this sort

> of implementation, but neither does it seem to prevent it. But were we

> to go in this direction it would probably be advisable to discuss 
> these concepts specifically.

Don't forget that 2778/2779 only defined the base
vocabulary/requirements. CPIM/PIDF/etc define the implementation
decisions taken to produce our standard IMPP that fits the model.

Adrian.



From pkyzivat@cisco.com  Mon Jun 10 18:53:54 2002
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 SAA02680
	for ; Mon, 10 Jun 2002 18:53:53 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5AMq3Ai007891;
	Mon, 10 Jun 2002 18:52:03 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAL71464;
	Mon, 10 Jun 2002 18:56:10 -0400 (EDT)
Message-ID: <3D052D75.B2B7F829@cisco.com>
Date: Mon, 10 Jun 2002 18:51:33 -0400
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: bateman@acm.org
CC: sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu
References: <000d01c210c8$d7d3a2b0$6405010a@ADRIANXP>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2150
Subject: [Simple] Re: PIDF for buddylists
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: 

Adrian Bateman wrote:
> 
> Don't forget that 2778/2779 only defined the base
> vocabulary/requirements. CPIM/PIDF/etc define the implementation
> decisions taken to produce our standard IMPP that fits the model.

Yes. I'm mindful that what we are discussing here is likely at minimum an extension to PIDF. I don't want to derail plans for timely progress on presence.

Hopefully extensions should be sufficient, and could come down the pipeline after the current stuff progresses.

One way to represent more than one level of hierarchy is simply to include a  element in a  as an extension element. So it could also be added as an
optional element in a future extension and be backward compatible.

A subscription option to receive differences rather than full updates could be encoded in the body as part of a filter. This would make sense, since it is a sort of filter.
And it would be compatible with the current direction.

One thing that might be a problem would be indicating that a response has had filtering and/or differencing applied. Some of it could be handled as extension values in
tuples, but I can foresee a need to know this at the  level too. One possible change to the current proposed PIDF format that might help here would be to make
explicit provision for extension values within  itself. This would look like:

      
         
            
            
*           
         
         
      

Another approach for handling this kind of change would be to simply define a different presence document type for representing diffs and multilevel presence status.
Clients wanting to use it would then have to be prepared for servers that can't handle it, by falling back to the old PIDF.

	Paul

From bateman@acm.org  Tue Jun 11 01:52:23 2002
Received: from imailg1.svr.pol.co.uk (imailg1.svr.pol.co.uk [195.92.195.179])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03835
	for ; Tue, 11 Jun 2002 01:52:22 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by imailg1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17HeYU-0001XV-00; Tue, 11 Jun 2002 06:50:58 +0100
Received: from modem-147.rhino.dialup.pol.co.uk ([62.137.96.147] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17HeYT-0006NO-00; Tue, 11 Jun 2002 06:50:57 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Paul Kyzivat'" 
Cc: , , 
Date: Tue, 11 Jun 2002 06:49:48 +0100
Organization: VisionTech Limited
Message-ID: <001501c2110b$cc6cccb0$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <3D052D75.B2B7F829@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 1735
Subject: [Simple] RE: PIDF for buddylists
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: 

On 10 June 2002 23:51, Paul Kyzivat wrote:
> One thing that might be a problem would be indicating that a response 
> has had filtering and/or differencing applied. Some of it could be 
> handled as extension values in tuples, but I can foresee a need to 
> know this at the  level too. One possible change to the 
> current proposed PIDF format that might help here would be to make 
> explicit provision for extension values within  itself. This

> would look like:
> 
>       
>          
>             
>                              maxOccurs="unbounded"/>
> *            *              maxOccurs="unbounded"/>
>          
>          
>       

This has been mentioned in the past, but AFAIK, this is the first
concrete example of *why* we should make it. In the past, I think I've
probably stuck with the letter of 2778 using our current approach, but
on the basis that this is such a small change, has been requested a few
times, and generally looks like a good idea, I think we should adopt it.

> Another approach for handling this kind of change would be to simply 
> define a different presence document type for representing diffs and 
> multilevel presence status. Clients wanting to use it would then have 
> to be prepared for servers that can't handle it, by falling back to 
> the old PIDF.

I'd like to avoid that if possible - I think we should make the change.

Adrian.



From jon.peterson@neustar.biz  Tue Jun 11 04:48:05 2002
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04372
	for ; Tue, 11 Jun 2002 04:48:04 -0400 (EDT)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65])
	by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g5B8kmT26962;
	Tue, 11 Jun 2002 03:46:48 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 11 Jun 2002 03:46:44 -0500
Message-ID: <70565611B164D511957A001083FCDD56018703CD@va02.va.neustar.com>
From: "Peterson, Jon" 
To: "'simple@mailman.dynamicsoft.com'" 
Cc: "'rsparks@dynamicsoft.com'" 
Date: Tue, 11 Jun 2002 03:46:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2317
Subject: [Simple] Message 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: 

Now that the presence and watcherinfo work has gone forward to the IESG, we
need to return to the issue of message sessions - we are quite a bit overdue
on our deliverable to solve this problem, largely because many of the core
SIP/SIMPLE people have been focusing on some other issues. As those of you
who have followed the discussion regarding the MESSAGE method draft in the
SIP WG are aware, there is now a better transition strategy emerging to
determine how one segues from paging mode to session mode. At least one case
in which we know we would like to transition is when large content (a binary
media file, for example) is being transmitted over instant messages.
However, although we know what message sessions are and what we'd like to
use them for, we still have not arrived at any conclusions in the SIMPLE WG
on the actual session protocol.

Two proposals have been made for session protocols:

http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-01.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-session-0
0.txt

In Minneapolis, we all collectively took an action item to review these
approaches in order to determine their suitability. At the time, however,
the second of these drafts was not available. We also really have no
criteria on which to evaluate these drafts other than the requirements that
fall out of CPIM.

It is important that we arrive at some consensus about pursuing one (or
both) of these documents as working group items shortly. At the very least,
determining that they comply with CPIM guidelines is critical. The chairs
would therefore like to solicit some volunteers to review these proposals in
the next TWO weeks in the light of the following documents from the IMPP WG:

http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-02.txt
http://www.ietf.org/rfc/rfc2779.txt

If you can commit to provide a written review of the comformance of one of
the session protocol proposals to CPIM guidelines within the timeline,
please contact the chairs (myself and Robert) privately; we'll assign
reviewers shortly.

We would also welcome any general discussion of the merits of these
protocols, whether it is preferable to pursue one or both of these
proposals, suggested requirements and so on. 

Jon Peterson
NeuStar, Inc.
SIMPLE WG co-chair


From peter.lewis@upperside.fr  Tue Jun 11 07:54:24 2002
Received: from smtp5.cluster.oleane.net (smtp5.cluster.oleane.net [195.25.12.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04888
	for ; Tue, 11 Jun 2002 07:54:23 -0400 (EDT)
Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp5.cluster.oleane.net with SMTP id g5BBr4g47950 for ; Tue, 11 Jun 2002 13:53:04 +0200 (CEST)
Message-ID: <015001c2113f$7e228ac0$0701a8c0@oleane.com>
From: "Peter Lewis" 
To: 
Date: Tue, 11 Jun 2002 13:59:51 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_014D_01C21150.41576E60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Length: 1456
Subject: [Simple] International SIP 2003
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_014D_01C21150.41576E60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The fourth edition of International SIP, the largest international =
gathering exclusively dedicated to SIP, will take place January 21 to 24 =
2003 in Paris (Sofitel Bercy).=20
A call for proposals is online at:
http://www.upperside.fr/intersip03/sip03intro.htm




------=_NextPart_000_014D_01C21150.41576E60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











 


The fourth edition of International SIP, the largest =

international gathering exclusively dedicated to SIP, will take place =
January 21=20
to 24 2003 in Paris (Sofitel Bercy). 


A call for proposals is online at:


http://www.upp=
erside.fr/intersip03/sip03intro.htm


 


 


 


------=_NextPart_000_014D_01C21150.41576E60--


From wayne.carr@intel.com  Tue Jun 11 17:04:41 2002
Received: from pallas.or.intel.com (pallas.or.intel.com [134.134.214.21])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06628
	for ; Tue, 11 Jun 2002 17:04:40 -0400 (EDT)
Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129])
	by pallas.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g5BL4dt25693
	for ; Tue, 11 Jun 2002 21:04:39 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.42.28])
 by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002061113544311987
 ; Tue, 11 Jun 2002 13:54:43 -0700
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 11 Jun 2002 12:45:00 -0700
Message-ID: <86DB568235A8D511ABAC0002A5072CA50316C3E1@orsmsx120.jf.intel.com>
From: "Carr, Wayne" 
To: "'Adrian Bateman'" ,
        "'Paul Kyzivat'"
	 
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com, impp@iastate.edu
Date: Tue, 11 Jun 2002 12:44:52 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 3043
Subject: [Simple] RE: PIDF for buddylists
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: 

I've been away travelling and haven't been following this - so apologies in
advance.

The proposal looks like adding the ability to add extensions as the direct
child of the presence element.  That's already in
http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt  The **
part of the suggested schema section below are in the XML schema now.

Also for people not familiar with XML schema --  in another Internet Draft
someone can define a new XML format in a new namespace that includes the
PIDF format presence element (lists of them if they want).  They don't need
to redefine PIDF in their draft, they just include it by including an
element with the pidf namespace - so can have lists of presence elements.

I think the PIDF format is flexible enough that it can handle the types of
things being discussed without changes to PIDF itself.

> -----Original Message-----
> From: Adrian Bateman [mailto:bateman@acm.org]
> Sent: Monday, June 10, 2002 10:50 PM
> To: 'Paul Kyzivat'
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; impp@iastate.edu
> Subject: RE: PIDF for buddylists
> 
> 
> On 10 June 2002 23:51, Paul Kyzivat wrote:
> > One thing that might be a problem would be indicating that 
> a response 
> > has had filtering and/or differencing applied. Some of it could be 
> > handled as extension values in tuples, but I can foresee a need to 
> > know this at the  level too. One possible change to the 
> > current proposed PIDF format that might help here would be to make 
> > explicit provision for extension values within  
> itself. This
> 
> > would look like:
> > 
> >       
> >          
> >              maxOccurs="unbounded"/>
> >              >                 maxOccurs="unbounded"/>
> > *            minOccurs="0"
> > *              maxOccurs="unbounded"/>
> >          
> >           use="required"/>
> >       
> 
> This has been mentioned in the past, but AFAIK, this is the first
> concrete example of *why* we should make it. In the past, I think I've
> probably stuck with the letter of 2778 using our current approach, but
> on the basis that this is such a small change, has been 
> requested a few
> times, and generally looks like a good idea, I think we 
> should adopt it.
> 
> > Another approach for handling this kind of change would be 
> to simply 
> > define a different presence document type for representing 
> diffs and 
> > multilevel presence status. Clients wanting to use it would 
> then have 
> > to be prepared for servers that can't handle it, by falling back to 
> > the old PIDF.
> 
> I'd like to avoid that if possible - I think we should make 
> the change.
> 
> Adrian.
> 
> 
> 
> 
> 
>   [reminder: meta-impp@iastate.edu for non-technical 
> discussions, please]
> 

From pkyzivat@cisco.com  Tue Jun 11 17:34:17 2002
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 RAA06742
	for ; Tue, 11 Jun 2002 17:34:17 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5BLYDqs019397;
	Tue, 11 Jun 2002 17:34:13 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAL78080;
	Tue, 11 Jun 2002 17:38:20 -0400 (EDT)
Message-ID: <3D066CB7.F2F37BE6@cisco.com>
Date: Tue, 11 Jun 2002 17:33:43 -0400
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: "Carr, Wayne" 
CC: "'Adrian Bateman'" , sipping@ietf.org,
        simple@mailman.dynamicsoft.com, impp@iastate.edu
References: <86DB568235A8D511ABAC0002A5072CA50316C3E1@orsmsx120.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1212
Subject: [Simple] Re: PIDF for buddylists
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: 


"Carr, Wayne" wrote:
> 
> The proposal looks like adding the ability to add extensions as the direct
> child of the presence element.  That's already in
> http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt  The **
> part of the suggested schema section below are in the XML schema now.

Oops! I was looking at an old version. Dumb, because I had the newer one too and just looked at the wrong one. So I guess no prep-work is required to permit later migration
to the kinds of changes I am speculating about.

> Also for people not familiar with XML schema --  in another Internet Draft
> someone can define a new XML format in a new namespace that includes the
> PIDF format presence element (lists of them if they want).  They don't need
> to redefine PIDF in their draft, they just include it by including an
> element with the pidf namespace - so can have lists of presence elements.

Yes, or course. But that would require adopting a new sip content-type to go forward.

> 
> I think the PIDF format is flexible enough that it can handle the types of
> things being discussed without changes to PIDF itself.

Since the change I was looking for has already been made, I must agree.

	Paul

From bateman@acm.org  Wed Jun 12 01:41:24 2002
Received: from mail7.svr.pol.co.uk (mail7.svr.pol.co.uk [195.92.193.21])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08090
	for ; Wed, 12 Jun 2002 01:41:24 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by mail7.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17I0sk-0004c1-00; Wed, 12 Jun 2002 06:41:22 +0100
Received: from modem-1079.tiger.dialup.pol.co.uk ([62.136.212.55] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17I0sj-0004i8-00; Wed, 12 Jun 2002 06:41:21 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Carr, Wayne'" 
Cc: , , 
Subject: RE: [Simple] RE: PIDF for buddylists
Date: Wed, 12 Jun 2002 06:40:00 +0100
Organization: VisionTech Limited
Message-ID: <000201c211d3$9e9f3200$6405010a@ADRIANXP>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <86DB568235A8D511ABAC0002A5072CA50316C3E1@orsmsx120.jf.intel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 3524
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: 

Sorry for not following the recent changes closely enough. I'm glad this
change was made :o)

Adrian.


On 11 June 2002 20:44, Carr, Wayne wrote:
> I've been away travelling and haven't been following this - so 
> apologies in advance.
> 
> The proposal looks like adding the ability to add extensions as the 
> direct child of the presence element.  That's already in 
> http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-pidf-05.txt  
> The ** part of the suggested schema section below are in the XML 
> schema now.
> 
> Also for people not familiar with XML schema --  in another Internet 
> Draft someone can define a new XML format in a new namespace that 
> includes the PIDF format presence element (lists of them if they 
> want).  They don't need to redefine PIDF in their draft, they just 
> include it by including an element with the pidf namespace - so can 
> have lists of presence elements.
> 
> I think the PIDF format is flexible enough that it can handle the 
> types of things being discussed without changes to PIDF itself.
> 
> > -----Original Message-----
> > From: Adrian Bateman [mailto:bateman@acm.org]
> > Sent: Monday, June 10, 2002 10:50 PM
> > To: 'Paul Kyzivat'
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; 
> > impp@iastate.edu
> > Subject: RE: PIDF for buddylists
> > 
> > 
> > On 10 June 2002 23:51, Paul Kyzivat wrote:
> > > One thing that might be a problem would be indicating that
> > a response
> > > has had filtering and/or differencing applied. Some of it could be

> > > handled as extension values in tuples, but I can foresee a need to

> > > know this at the  level too. One possible change to the 
> > > current proposed PIDF format that might help here would be to make

> > > explicit provision for extension values within 
> > itself. This
> > 
> > > would look like:
> > > 
> > >       
> > >          
> > >              > maxOccurs="unbounded"/>
> > >              > >                 maxOccurs="unbounded"/>
> > > *            > minOccurs="0"
> > > *              maxOccurs="unbounded"/>
> > >          
> > >           > use="required"/>
> > >       
> > 
> > This has been mentioned in the past, but AFAIK, this is the first
> > concrete example of *why* we should make it. In the past, I think
I've 
> > probably stuck with the letter of 2778 using our current approach,
but 
> > on the basis that this is such a small change, has been requested a 
> > few times, and generally looks like a good idea, I think we
> > should adopt it.
> > 
> > > Another approach for handling this kind of change would be
> > to simply
> > > define a different presence document type for representing
> > diffs and
> > > multilevel presence status. Clients wanting to use it would
> > then have
> > > to be prepared for servers that can't handle it, by falling back 
> > > to the old PIDF.
> > 
> > I'd like to avoid that if possible - I think we should make the 
> > change.
> > 
> > Adrian.
> > 
> > 
> > 
> > 
> > 
> >   [reminder: meta-impp@iastate.edu for non-technical discussions, 
> > please]
> > 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 



From LAM@zurich.ibm.com  Wed Jun 12 04:18:25 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08564
	for ; Wed, 12 Jun 2002 04:18:25 -0400 (EDT)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5C8IOqq042252
	for ; Wed, 12 Jun 2002 10:18:24 +0200
Received: from d13ml006 (d13ml006.ch.ibm.com [9.13.8.67])
	by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5C8IOx80064
	for ; Wed, 12 Jun 2002 10:18:24 +0200
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: 
From: "Lamine Brahimi" 
Date: Wed, 12 Jun 2002 10:18:23 +0200
X-MIMETrack: Serialize by Router on D13ML006/13/M/IBM(Release 5.0.9a |January 7, 2002) at
 12/06/2002 10:18:23
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 518
Subject: [Simple] Urgent: SIMPLE on the market
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: 

Dear all,

I would like to know if there is some Instant Messaging softwares that
already use SIP and SIMPLE protocols.
I know that Windows XP Messenger use a part of it in collaboration with
Microsoft Messenger protocol.
Is there any other Research prototypes or proprietary products using SIMPLE
?
I have developed a Presence protocol based on SIMPLE for my diploma thesis,
and
I would like to know if there are other products in order to mention them
in my final thesis report as a related work.

Thanks,

Lamine.


From jdrosen@dynamicsoft.com  Thu Jun 13 03:56:35 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12560
	for ; Thu, 13 Jun 2002 03:56:35 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.86])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5D7uVYH012860;
	Thu, 13 Jun 2002 03:56:32 -0400 (EDT)
Message-ID: <3D080A2A.4010308@dynamicsoft.com>
Date: Wed, 12 Jun 2002 22:57:46 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Torrey Searle 
CC: simple@mailman.dynamicsoft.com, Jean-Luc Sonnet
 
Subject: Re: [Simple] Offline messaging
References: <3CDB91E4.1050803@indigosw.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1461
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: 

Digging through old emails, noticed there was no reply to this....

Torrey Searle wrote:
> In the current messaging draft, it seems that Message Replay attack 
> prevention relies on the ability to determine that the message 
> originated from a offline messaging server, and that the message is an 
> offline message.  
> 
> Are their any plans on adding a way of marking a message as an offline 
> message?

How would you trust such a marking?

I think there is no real way to reliably differentiate an offline 
message from a replayed one. The best you can hope for is that the 
offiline messaging server actually sends a new message, signing it, with 
the original messages, headers, signatures, and all, as the payload. 
Thats certainly possible with MESSAGE.

Generally, I think that, when there is a message received which has an 
old date, the user needs to be prompted to determine what to do. It 
could in fact be a new message, but the sender has an unsynchronized 
clock which is off by a day or two. You see that frequently in email....

I believe the MESSAGE draft pretty much provides that guideline.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com



From jdrosen@dynamicsoft.com  Thu Jun 13 03:58:40 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12579
	for ; Thu, 13 Jun 2002 03:58:40 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.86])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5D7uNYH012857;
	Thu, 13 Jun 2002 03:56:26 -0400 (EDT)
Message-ID: <3D08089B.6010805@dynamicsoft.com>
Date: Wed, 12 Jun 2002 22:51:07 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bateman@acm.org
CC: "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'"
 ,
        simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <001301c20979$e23d34b0$6405010a@ADRIANXP>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3524
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: 

Once again this one has stalled, but I think Adrian has captured the 
essence of why below:

Adrian Bateman wrote:
> On 31 May 2002 03:16, Li Hua Tang wrote:
> 
>>So can we summary status as below?
>>Open
>>    - availble  // always ready to chat
>>    - away      // temporarily not available
>>    - invisible // only available to someone I want to chat
>>    - busy      // not ready to chat or no immediately response to
> 
> messages
> 
>>    - in call   // may ready to chat later
>>Closed
>>    - unavailable      // disconnect and can't chat
>>    - do not disturb   // don't want to receive message but close the
>>channel
> 
> 
> 
> (Apart from the fact that invisible can't really be a state (visibly
> invisible?) so should look just like disconnnected,) I'll try to
> reiterate my thoughts on this discussion from a different tack.
> 
> Why is it important to try to distill the different IM status values
> into a definitive set? I don't believe that the group will reach
> consensus on a definitive minimal set because one person's busy is
> another's do-not-disturb. Doesn't the benefit come from having a
> *reasonably* small and *well-known* vocabulary for IM status values? You
> don't even really need to decide which are open and which are closed -
> PIDF allows for that already.
> 
> Perhaps rather than trying to find the set of status values, attention
> might be focussed on the reason for having such a set and the values
> might fall out of that discussion?

This is the essence of the problem. We don't know *why* we want these 
various status values. Until we know what kinds of things we need to do 
with them, it will be hard to determine what we want to do.

SO, I propose that we focus discussion instead on the things that might 
be done with such inforamtion. Most importantly, they are things that an 
automata would do, since anything else can be handled by the note.

* display icons appropriate to the status

   This would in fact argue for a set of common reasons, such as "on the 
phone" and "in a meeting", irregardless if they don't say anything much 
beyond CLOSED or OPEN in terms of the ability to receive an IM.

* Provide local language versions of the status

   Similar to the above item, it would require a set of common reasons.

* have the secretary automatically connected to the boss in a phone 
call, when the boss becomes available, where the *secretary* defines 
available

This is an interesting one. TO date, our assumption was that 
availability is the decision of the presentity; that it decides whether 
or not it wants to receive calls. THere is an argument to be made that, 
in the case above, for example, the watcher wants to determine what 
availability means, based on "raw" information about the boss - whether 
they are in a call or not, in a meeting or not, and so on. In order for 
that to work, the secretary's application needs detailed information on 
what the boss is doing so that it can make a decision.



I am sure there are others; suggestions welcome, as well as comments on 
the above list. Again, I propose we focus on the usages for the status 
values, rather than on the values themselves.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com



From pkyzivat@cisco.com  Thu Jun 13 08:59:23 2002
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 IAA13557
	for ; Thu, 13 Jun 2002 08:59:23 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5DCxkgu006014;
	Thu, 13 Jun 2002 08:59:46 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAL86826;
	Thu, 13 Jun 2002 09:03:53 -0400 (EDT)
Message-ID: <3D089723.2314815@cisco.com>
Date: Thu, 13 Jun 2002 08:59:15 -0400
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: bateman@acm.org, simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <001301c20979$e23d34b0$6405010a@ADRIANXP> <3D08089B.6010805@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2251
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: 


Jonathan Rosenberg wrote:
> 
> Once again this one has stalled, but I think Adrian has captured the
> essence of why below:
> 
> Adrian Bateman wrote:
> > Perhaps rather than trying to find the set of status values, attention
> > might be focussed on the reason for having such a set and the values
> > might fall out of that discussion?
> 
> This is the essence of the problem. We don't know *why* we want these
> various status values. Until we know what kinds of things we need to do
> with them, it will be hard to determine what we want to do.
> 
> SO, I propose that we focus discussion instead on the things that might
> be done with such inforamtion. Most importantly, they are things that an
> automata would do, since anything else can be handled by the note.

I agree that this is a useful way to progress.

Some time ago I tried, rather unsuccessfully, to make a point about the sorts of statuses that are being proposed. I will try again:

Most of the statuses can be classified into one of two buckets:
- what the presentity is *doing*
  ("on the phone", "in meeting", "on vacation")
- what the presentity is *willing to do*
  ("open"?, "do not disturb"?, "emergency calls only")

Choosing one sort or another seems to be a matter of philosophy. You choose to represent what is being done if you are generating the status automatically and don't know
what the presentity is willing to do, or if you want to put the onus on the caller to decide. You can choose to represent what the presentity is willing to do if the user
is explicitly setting the status, if the user has set policy on how to determine what he is willing to do, and if you want to avoid failed attempts to communicate by
accurately representing willingness.

Automatons can use either sort to display icons, etc. The second sort are beter for caller automatons that automatically place calls, because the automaton has less to
infer. OTOH, if you want to report that sort of status automatically then it will require a complex automaton in the presentity to infer the status from actions.

I suppose we need both sorts, but it would be useful to be mindful of what kind the things we are defining are, and to attempt to make a reasonably complete set of each. 

	Paul

From Brian.Rosen@marconi.com  Thu Jun 13 10:03:42 2002
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 KAA13764
	for ; Thu, 13 Jun 2002 10:03:41 -0400 (EDT)
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 KAA08071;
	Thu, 13 Jun 2002 10:03:37 -0400 (EDT)
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 KAA07449;
	Thu, 13 Jun 2002 10:03:37 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 13 Jun 2002 10:03:36 -0400
Message-ID: <313680C9A886D511A06000204840E1CF030B54ED@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Jonathan Rosenberg'" , bateman@acm.org
Cc: "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'"
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: Status discussion again RE: [Simple] Test message
Date: Thu, 13 Jun 2002 10:03:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5476
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: 

Your admin screening for a boss is one example of forwarding
decisions based on presence.   There are others:
	Voicemail diversion based on presence
	Forward to cellphone when I'm not in the office
	...

There are other things a remote party might do depending on my
presence.  One really rich vein is a group call (call out
ad-hoc conference).  How about:
	Don't call a person marked >="busy" on a group call-out
	Display who might not be able to respond to a group call
		before you place it
	Prompt for an IM when you try to call someone who is "on the phone",
		but put up an alert when you try to call someone who is DND.
	
Also consider an IM system on a PC and a SIP Phone on the same desk.
Presumably, there is one presence system shared among them which could
be three independent implementations (two watchers and one presentity).  
Thus "local" knowledge needs to be standardized to allow:
	Change alert mechanism for incoming calls (a simple example would
		be a more discreet alert if you were busy)
	Choose an appropriate voicemail greeting
	Don't set an alert if no one is there to see it
	Send an away message when an IM comes
	...

I think there is need to have a pretty well specified set of states,
hard though that may be.

Brian
	
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, June 12, 2002 10:51 PM
> To: bateman@acm.org
> Cc: 'Li Hua Tang'; 'DAO TRUNG Tin FTRD/DAC/ISS';
> simple@mailman.dynamicsoft.com
> Subject: Re: Status discussion again RE: [Simple] Test message
> 
> 
> Once again this one has stalled, but I think Adrian has captured the 
> essence of why below:
> 
> Adrian Bateman wrote:
> > On 31 May 2002 03:16, Li Hua Tang wrote:
> > 
> >>So can we summary status as below?
> >>Open
> >>    - availble  // always ready to chat
> >>    - away      // temporarily not available
> >>    - invisible // only available to someone I want to chat
> >>    - busy      // not ready to chat or no immediately response to
> > 
> > messages
> > 
> >>    - in call   // may ready to chat later
> >>Closed
> >>    - unavailable      // disconnect and can't chat
> >>    - do not disturb   // don't want to receive message but 
> close the
> >>channel
> > 
> > 
> > 
> > (Apart from the fact that invisible can't really be a state (visibly
> > invisible?) so should look just like disconnnected,) I'll try to
> > reiterate my thoughts on this discussion from a different tack.
> > 
> > Why is it important to try to distill the different IM status values
> > into a definitive set? I don't believe that the group will reach
> > consensus on a definitive minimal set because one person's busy is
> > another's do-not-disturb. Doesn't the benefit come from having a
> > *reasonably* small and *well-known* vocabulary for IM 
> status values? You
> > don't even really need to decide which are open and which 
> are closed -
> > PIDF allows for that already.
> > 
> > Perhaps rather than trying to find the set of status 
> values, attention
> > might be focussed on the reason for having such a set and the values
> > might fall out of that discussion?
> 
> This is the essence of the problem. We don't know *why* we want these 
> various status values. Until we know what kinds of things we 
> need to do 
> with them, it will be hard to determine what we want to do.
> 
> SO, I propose that we focus discussion instead on the things 
> that might 
> be done with such inforamtion. Most importantly, they are 
> things that an 
> automata would do, since anything else can be handled by the note.
> 
> * display icons appropriate to the status
> 
>    This would in fact argue for a set of common reasons, such 
> as "on the 
> phone" and "in a meeting", irregardless if they don't say 
> anything much 
> beyond CLOSED or OPEN in terms of the ability to receive an IM.
> 
> * Provide local language versions of the status
> 
>    Similar to the above item, it would require a set of 
> common reasons.
> 
> * have the secretary automatically connected to the boss in a phone 
> call, when the boss becomes available, where the *secretary* defines 
> available
> 
> This is an interesting one. TO date, our assumption was that 
> availability is the decision of the presentity; that it 
> decides whether 
> or not it wants to receive calls. THere is an argument to be 
> made that, 
> in the case above, for example, the watcher wants to determine what 
> availability means, based on "raw" information about the boss 
> - whether 
> they are in a call or not, in a meeting or not, and so on. In 
> order for 
> that to work, the secretary's application needs detailed 
> information on 
> what the boss is doing so that it can make a decision.
> 
> 
> 
> I am sure there are others; suggestions welcome, as well as 
> comments on 
> the above list. Again, I propose we focus on the usages for 
> the status 
> values, rather than on the values themselves.
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From pkyzivat@cisco.com  Thu Jun 13 11:13:38 2002
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 LAA14039
	for ; Thu, 13 Jun 2002 11:13:38 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5DFDaXg018164;
	Thu, 13 Jun 2002 11:13:37 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAL88068;
	Thu, 13 Jun 2002 11:17:43 -0400 (EDT)
Message-ID: <3D08B681.E018320E@cisco.com>
Date: Thu, 13 Jun 2002 11:13:05 -0400
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: "Rosen, Brian" 
CC: "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <313680C9A886D511A06000204840E1CF030B54ED@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2169
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: 

Another more extreme version of "forwarding decisions based on presence" is in a call center. What you really want is for the capabilities and capacity of each agent to be
reported via presence, and for a server to subscribe to this presence information for all candidate agents. Then it can make forwarding decisions based on optimizing across
all the candidate agents.

For this, you need rich presence information, about media supported, skills, loading, possibly cost. This is more information than is needed for most informal usage, but I
think these cases are merely the extremes of a continuum of applications of presence. I don't know if SIMPLE is interested in the more specialized forms of presence.

	Paul

"Rosen, Brian" wrote:
> 
> Your admin screening for a boss is one example of forwarding
> decisions based on presence.   There are others:
>         Voicemail diversion based on presence
>         Forward to cellphone when I'm not in the office
>         ...
> 
> There are other things a remote party might do depending on my
> presence.  One really rich vein is a group call (call out
> ad-hoc conference).  How about:
>         Don't call a person marked >="busy" on a group call-out
>         Display who might not be able to respond to a group call
>                 before you place it
>         Prompt for an IM when you try to call someone who is "on the phone",
>                 but put up an alert when you try to call someone who is DND.
> 
> Also consider an IM system on a PC and a SIP Phone on the same desk.
> Presumably, there is one presence system shared among them which could
> be three independent implementations (two watchers and one presentity).
> Thus "local" knowledge needs to be standardized to allow:
>         Change alert mechanism for incoming calls (a simple example would
>                 be a more discreet alert if you were busy)
>         Choose an appropriate voicemail greeting
>         Don't set an alert if no one is there to see it
>         Send an away message when an IM comes
>         ...
> 
> I think there is need to have a pretty well specified set of states,
> hard though that may be.
> 
> Brian

From seancolson@yahoo.com  Thu Jun 13 12:22:20 2002
Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA14339
	for ; Thu, 13 Jun 2002 12:22:19 -0400 (EDT)
Message-ID: <20020613162219.39388.qmail@web11603.mail.yahoo.com>
Received: from [131.107.3.75] by web11603.mail.yahoo.com via HTTP; Thu, 13 Jun 2002 09:22:19 PDT
Date: Thu, 13 Jun 2002 09:22:19 -0700 (PDT)
From: Sean Olson 
Subject: Re: Status discussion again RE: [Simple] Test message
To: Paul Kyzivat ,
        "Rosen, Brian" 
Cc: "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3D08B681.E018320E@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 3061
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: 

I may be misunderstanding you, but I don't
believe capacity and capabilities are necessarily
things you want to publish as presence. I agree
they are useful things to have for routing 
decisions, I just don't think they should be
part of a presence document.

Rather, I would prefer to see something like
CC/PP used in conjunction with presence to enable
the scenarios you are talking about.

/sean

--- Paul Kyzivat  wrote:
> Another more extreme version of "forwarding
> decisions based on presence" is in a call center.
> What you really want is for the capabilities and
> capacity of each agent to be
> reported via presence, and for a server to subscribe
> to this presence information for all candidate
> agents. Then it can make forwarding decisions based
> on optimizing across
> all the candidate agents.
> 
> For this, you need rich presence information, about
> media supported, skills, loading, possibly cost.
> This is more information than is needed for most
> informal usage, but I
> think these cases are merely the extremes of a
> continuum of applications of presence. I don't know
> if SIMPLE is interested in the more specialized
> forms of presence.
> 
> 	Paul
> 
> "Rosen, Brian" wrote:
> > 
> > Your admin screening for a boss is one example of
> forwarding
> > decisions based on presence.   There are others:
> >         Voicemail diversion based on presence
> >         Forward to cellphone when I'm not in the
> office
> >         ...
> > 
> > There are other things a remote party might do
> depending on my
> > presence.  One really rich vein is a group call
> (call out
> > ad-hoc conference).  How about:
> >         Don't call a person marked >="busy" on a
> group call-out
> >         Display who might not be able to respond
> to a group call
> >                 before you place it
> >         Prompt for an IM when you try to call
> someone who is "on the phone",
> >                 but put up an alert when you try
> to call someone who is DND.
> > 
> > Also consider an IM system on a PC and a SIP Phone
> on the same desk.
> > Presumably, there is one presence system shared
> among them which could
> > be three independent implementations (two watchers
> and one presentity).
> > Thus "local" knowledge needs to be standardized to
> allow:
> >         Change alert mechanism for incoming calls
> (a simple example would
> >                 be a more discreet alert if you
> were busy)
> >         Choose an appropriate voicemail greeting
> >         Don't set an alert if no one is there to
> see it
> >         Send an away message when an IM comes
> >         ...
> > 
> > I think there is need to have a pretty well
> specified set of states,
> > hard though that may be.
> > 
> > Brian
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

From pkyzivat@cisco.com  Thu Jun 13 16:30:34 2002
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 QAA15091
	for ; Thu, 13 Jun 2002 16:30:33 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5DKUqe4016174;
	Thu, 13 Jun 2002 16:30:53 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAL90998;
	Thu, 13 Jun 2002 16:34:59 -0400 (EDT)
Message-ID: <3D0900DE.2053AA84@cisco.com>
Date: Thu, 13 Jun 2002 16:30:22 -0400
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: Sean Olson 
CC: "Rosen, Brian" ,
        "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <20020613162219.39388.qmail@web11603.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1872
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: 


Sean Olson wrote:
> 
> I may be misunderstanding you, but I don't
> believe capacity and capabilities are necessarily
> things you want to publish as presence. I agree
> they are useful things to have for routing
> decisions, I just don't think they should be
> part of a presence document.

Maybe we aren't thinking of the same things, because I see these as very relevant to presence.

For instance, capability/willingness to communicate on the subject of auto-repair is just a slightly more refined form of the business/personal distinction.

Another sort of capability is media. I might be available for voice only, or for voice and/or IM and/or video at a given address.

Capacity can be viewed a couple of ways: maybe I can do IM both on my phone and my PC, but I can do it well on my PC with a keyboard, whereas I can only do it poorly on my
phone. 

Capacity can also be a function of the person manning the presentity. Suppose the address is sip:answers@cars.r.us.com. Sometimes there is an auto guru manning it, so the
capacity for auto-repair is high. Other times only a trainee is present, who will try, but isn't very good at auto-repair questions. So the capacity is less.

> 
> Rather, I would prefer to see something like
> CC/PP used in conjunction with presence to enable
> the scenarios you are talking about.

I hadn't heard of CC/PP until now. After a (very) quick search, it sounds like it is solving a different problem. Perhaps it is still applicable, but if so it would still
need to be integrated with presence somehow. If it is XML, then perhaps it could be embedded in a special  in the presence document. Because this stuff can change
dynamically, and the presence client may need it to decide who to call, it would be bad to have to initiate some other sort of session with the presentity or contact to get
this information.

	Paul

From seancolson@yahoo.com  Thu Jun 13 18:41:39 2002
Received: from web11602.mail.yahoo.com (web11602.mail.yahoo.com [216.136.172.54])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA15494
	for ; Thu, 13 Jun 2002 18:41:39 -0400 (EDT)
Message-ID: <20020613224139.65227.qmail@web11602.mail.yahoo.com>
Received: from [131.107.3.72] by web11602.mail.yahoo.com via HTTP; Thu, 13 Jun 2002 15:41:39 PDT
Date: Thu, 13 Jun 2002 15:41:39 -0700 (PDT)
From: Sean Olson 
Subject: Re: Status discussion again RE: [Simple] Test message
To: Paul Kyzivat 
Cc: "Rosen, Brian" ,
        "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3D0900DE.2053AA84@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 2930
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: 

I think we are talking about different things. Part
of the confusion on "status" is that it can refer
to *at least* three different things:

 1. Presence - can I communicate
 2. Availability - do I want to communicate
 3. Capability - what are the mechanisms I have 
       at my disposal to communicate with

I believe a raw notion of capability (e-mail, http,
sip, etc.) may be appropriate for a "presence"
document.

However, more advanced notions such as I support
H.263 video or I have a color display capable of
640x480 resolution, etc. are a bit of a stretch.

Part of these device capabilities are covered
by CC/PP (the target application is web browsing,
but the CC/PP framework can be extended to much
broader capabilities ala RDF)

/sean

--- Paul Kyzivat  wrote:
> 
> 
> Sean Olson wrote:
> > 
> > I may be misunderstanding you, but I don't
> > believe capacity and capabilities are necessarily
> > things you want to publish as presence. I agree
> > they are useful things to have for routing
> > decisions, I just don't think they should be
> > part of a presence document.
> 
> Maybe we aren't thinking of the same things, because
> I see these as very relevant to presence.
> 
> For instance, capability/willingness to communicate
> on the subject of auto-repair is just a slightly
> more refined form of the business/personal
> distinction.
> 
> Another sort of capability is media. I might be
> available for voice only, or for voice and/or IM
> and/or video at a given address.
> 
> Capacity can be viewed a couple of ways: maybe I can
> do IM both on my phone and my PC, but I can do it
> well on my PC with a keyboard, whereas I can only do
> it poorly on my
> phone. 
> 
> Capacity can also be a function of the person
> manning the presentity. Suppose the address is
> sip:answers@cars.r.us.com. Sometimes there is an
> auto guru manning it, so the
> capacity for auto-repair is high. Other times only a
> trainee is present, who will try, but isn't very
> good at auto-repair questions. So the capacity is
> less.
> 
> > 
> > Rather, I would prefer to see something like
> > CC/PP used in conjunction with presence to enable
> > the scenarios you are talking about.
> 
> I hadn't heard of CC/PP until now. After a (very)
> quick search, it sounds like it is solving a
> different problem. Perhaps it is still applicable,
> but if so it would still
> need to be integrated with presence somehow. If it
> is XML, then perhaps it could be embedded in a
> special  in the presence document. Because
> this stuff can change
> dynamically, and the presence client may need it to
> decide who to call, it would be bad to have to
> initiate some other sort of session with the
> presentity or contact to get
> this information.
> 
> 	Paul


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

From pkyzivat@cisco.com  Mon Jun 17 09:01:13 2002
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 JAA00917
	for ; Mon, 17 Jun 2002 09:01:13 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5HD0TmY029282;
	Mon, 17 Jun 2002 09:00:29 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAM01286;
	Mon, 17 Jun 2002 09:04:35 -0400 (EDT)
Message-ID: <3D0DDD4D.68DCDE21@cisco.com>
Date: Mon, 17 Jun 2002 08:59:57 -0400
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: Sean Olson 
CC: "Rosen, Brian" ,
        "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <20020613224139.65227.qmail@web11602.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 4741
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: 

Sean,

I have not been following the technologies (CC/PP & RDF) that you reference, but I did poke around a bit to figure out what you are referring to.

These may indeed be interesting technologies, applicable to this problem space. But it isn't clear that they were intended for it, so it will be necessary to verify if they
are applicable, and how they might be made to fit. Since you clearly know more about them, can you say more about what you have in mind?

In particular, I gather that these are descriptive notations, encoded in XML, and probably say nothing about how they might be delivered. When we are discussing presence,
then it would make sense to me that they would be delivered as part of a presence document (at least the capabilities part) or possibly as part of a presence filter (the
preference part). Do you agree, or do you have something else in mind?

More below.

	Paul

Sean Olson wrote:
> 
> I think we are talking about different things. Part
> of the confusion on "status" is that it can refer
> to *at least* three different things:
> 
>  1. Presence - can I communicate
>  2. Availability - do I want to communicate
>  3. Capability - what are the mechanisms I have
>        at my disposal to communicate with
> 
> I believe a raw notion of capability (e-mail, http,
> sip, etc.) may be appropriate for a "presence"
> document.

I think we clearly need more than this. The existing status work has scoped itself strictly to IM, but people also want to apply it to voice, so we clearly need to
distinguish capability to communicate via IM from capability to communicate via voice.

> 
> However, more advanced notions such as I support
> H.263 video or I have a color display capable of
> 640x480 resolution, etc. are a bit of a stretch.

There has to be a line somewhere, but it is difficult to decide exactly where to draw that line. I think it must at least include the medium at the highest level
(video/voice/IM). Below that level it may be reasonable to assume that communication will be possible in some way, possibly involving transcoders.

> 
> Part of these device capabilities are covered
> by CC/PP (the target application is web browsing,
> but the CC/PP framework can be extended to much
> broader capabilities ala RDF)
> 
> /sean
> 
> --- Paul Kyzivat  wrote:
> >
> >
> > Sean Olson wrote:
> > >
> > > I may be misunderstanding you, but I don't
> > > believe capacity and capabilities are necessarily
> > > things you want to publish as presence. I agree
> > > they are useful things to have for routing
> > > decisions, I just don't think they should be
> > > part of a presence document.
> >
> > Maybe we aren't thinking of the same things, because
> > I see these as very relevant to presence.
> >
> > For instance, capability/willingness to communicate
> > on the subject of auto-repair is just a slightly
> > more refined form of the business/personal
> > distinction.
> >
> > Another sort of capability is media. I might be
> > available for voice only, or for voice and/or IM
> > and/or video at a given address.
> >
> > Capacity can be viewed a couple of ways: maybe I can
> > do IM both on my phone and my PC, but I can do it
> > well on my PC with a keyboard, whereas I can only do
> > it poorly on my
> > phone.
> >
> > Capacity can also be a function of the person
> > manning the presentity. Suppose the address is
> > sip:answers@cars.r.us.com. Sometimes there is an
> > auto guru manning it, so the
> > capacity for auto-repair is high. Other times only a
> > trainee is present, who will try, but isn't very
> > good at auto-repair questions. So the capacity is
> > less.
> >
> > >
> > > Rather, I would prefer to see something like
> > > CC/PP used in conjunction with presence to enable
> > > the scenarios you are talking about.
> >
> > I hadn't heard of CC/PP until now. After a (very)
> > quick search, it sounds like it is solving a
> > different problem. Perhaps it is still applicable,
> > but if so it would still
> > need to be integrated with presence somehow. If it
> > is XML, then perhaps it could be embedded in a
> > special  in the presence document. Because
> > this stuff can change
> > dynamically, and the presence client may need it to
> > decide who to call, it would be bad to have to
> > initiate some other sort of session with the
> > presentity or contact to get
> > this information.
> >
> >       Paul
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From dean.willis@softarmor.com  Mon Jun 17 19:33:27 2002
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 TAA02732
	for ; Mon, 17 Jun 2002 19:33:26 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g5HNX6V28581;
	Mon, 17 Jun 2002 18:33:07 -0500
From: "Dean Willis" 
To: "'Sean Olson'" ,
        "'Paul Kyzivat'" 
Cc: "'Rosen, Brian'" ,
        "'Jonathan Rosenberg'" , ,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        
Subject: RE: Status discussion again RE: [Simple] Test message
Date: Mon, 17 Jun 2002 18:32:16 -0500
Message-ID: <071a01c21657$38248b00$eb036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <20020613224139.65227.qmail@web11602.mail.yahoo.com>
Importance: Normal
Content-Length: 319
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: 

> I believe a raw notion of capability (e-mail, http,
> sip, etc.) may be appropriate for a "presence"
> document.

Yes! But I think of this as "style" or "mode" rather than capability. It
expresses the semantic of "I prefer to communicate in this mode" rather
than "My equipment is outfitted with a ____ ".

--
Dean



From pkyzivat@cisco.com  Tue Jun 18 08:56:51 2002
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 IAA04935
	for ; Tue, 18 Jun 2002 08:56:51 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5ICvBnt018759;
	Tue, 18 Jun 2002 08:57:11 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAM08563;
	Tue, 18 Jun 2002 09:01:17 -0400 (EDT)
Message-ID: <3D0F2E07.3390C89D@cisco.com>
Date: Tue, 18 Jun 2002 08:56:39 -0400
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: Dean Willis 
CC: "'Sean Olson'" ,
        "'Rosen, Brian'" ,
        "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <071a01c21657$38248b00$eb036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 844
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: 


Dean Willis wrote:
> 
> > I believe a raw notion of capability (e-mail, http,
> > sip, etc.) may be appropriate for a "presence"
> > document.
> 
> Yes! But I think of this as "style" or "mode" rather than capability. It
> expresses the semantic of "I prefer to communicate in this mode" rather
> than "My equipment is outfitted with a ____ ".

By all means, think of it that way if it makes you feel better. 

But it amounts to the same thing either way. After all, this is *presence*, so you aren't just saying you prefer to communicate in that mode - you are saying you are (or
believe you are) ready and capable of doing so.

(It wouldn't be very useful to advertise your presence for IM unless you actually could receive IM messages.)

The major difference is perhaps that you may be capable of modes that your prefer not to use.

	Paul

From dean.willis@softarmor.com  Tue Jun 18 22:57:54 2002
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 WAA07397
	for ; Tue, 18 Jun 2002 22:57:54 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g5J2rgV06089;
	Tue, 18 Jun 2002 21:53:42 -0500
Message-ID: <008301c2173c$888e77f0$2dacff0c@C1893415A>
From: "Dean Willis" 
To: "Paul Kyzivat" 
Cc: "'Sean Olson'" ,
        "'Rosen, Brian'" ,
        "'Jonathan Rosenberg'" , ,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        
References: <071a01c21657$38248b00$eb036e3f@TXDWILLIS2> <3D0F2E07.3390C89D@cisco.com>
Subject: Re: Status discussion again RE: [Simple] Test message
Date: Tue, 18 Jun 2002 21:53:45 -0500
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
Content-Length: 1924
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: 

When the 3G people talk "capability" they sometimes mean "I have a
160x160 display in 4-shade gray, the following fonts, a speaker phone, a
microphone, AMR, EFR, and FR codecs, and a camera that can capture QQCIF
at 4 fps.  My contract allows authorization of RABs to 144kbps after
8:00 PM in my local time zone. My keyboard map is "  . . .

overloaded term.

--
Dean

----- Original Message -----
From: "Paul Kyzivat" 
To: "Dean Willis" 
Cc: "'Sean Olson'" ; "'Rosen, Brian'"
; "'Jonathan Rosenberg'"
; ; "'Li Hua Tang'"
; "'DAO TRUNG Tin FTRD/DAC/ISS'"
; 
Sent: Tuesday, June 18, 2002 7:56 AM
Subject: Re: Status discussion again RE: [Simple] Test message


>
>
> Dean Willis wrote:
> >
> > > I believe a raw notion of capability (e-mail, http,
> > > sip, etc.) may be appropriate for a "presence"
> > > document.
> >
> > Yes! But I think of this as "style" or "mode" rather than
capability. It
> > expresses the semantic of "I prefer to communicate in this mode"
rather
> > than "My equipment is outfitted with a ____ ".
>
> By all means, think of it that way if it makes you feel better.
>
> But it amounts to the same thing either way. After all, this is
*presence*, so you aren't just saying you prefer to communicate in that
mode - you are saying you are (or
> believe you are) ready and capable of doing so.
>
> (It wouldn't be very useful to advertise your presence for IM unless
you actually could receive IM messages.)
>
> The major difference is perhaps that you may be capable of modes that
your prefer not to use.
>
> Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>


From dean.willis@softarmor.com  Tue Jun 18 22:58:22 2002
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 WAA07414
	for ; Tue, 18 Jun 2002 22:58:22 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g5J2wGV06121;
	Tue, 18 Jun 2002 21:58:17 -0500
Message-ID: <008b01c2173d$2b8474a0$2dacff0c@C1893415A>
From: "Dean Willis" 
To: "Peterson, Jon" ,
        
Cc: 
References: <70565611B164D511957A001083FCDD56018703CD@va02.va.neustar.com>
Subject: Re: [Simple] Message sessions
Date: Tue, 18 Jun 2002 21:58:20 -0500
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
Content-Length: 778
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: 

Jon asked:
> Now that the presence and watcherinfo work has gone forward to the
IESG, we
> need to return to the issue of message sessions - we are quite a bit
overdue
. . .
> Two proposals have been made for session protocols:
>
> http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-01.txt
>
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-sessi
on-0
> 0.txt

I personally lean towards the mrose approach. BEEP does a decent job of
the message delivery operation. It allows standardized relay elements to
be added as needed and provides for a sort of path-discovery that would
appear to be beneficial in firewall traversal scenarios. It provides a
nice layering distinctiuon between "can I talk to you" and "may I talk
to the network".

--
Dean


From hgs@cs.columbia.edu  Wed Jun 19 13:42:10 2002
Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10165
	for ; Wed, 19 Jun 2002 13:42:09 -0400 (EDT)
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by thoth.sbs.de (8.11.6/8.11.6) with ESMTP id g5JHg7h03361;
	Wed, 19 Jun 2002 19:42:07 +0200 (MEST)
Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56])
	by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g5JHg5i23705;
	Wed, 19 Jun 2002 19:42:06 +0200 (MEST)
Received: from alpha.mchp.siemens.de (alpha [139.23.202.151])
		by mail-y.mchp.siemens.de with ESMTP id g5JHg4VZ026696;
		Wed, 19 Jun 2002 19:42:04 +0200 (MET DST)
Received: from cs.columbia.edu (mhpa6v8c [139.23.202.84])
		by alpha.mchp.siemens.de with ESMTP id g5JHg4q9029130;
		Wed, 19 Jun 2002 19:42:04 +0200 (MET DST)
Message-ID: <3D10C246.3060803@cs.columbia.edu>
Date: Wed, 19 Jun 2002 13:41:26 -0400
From: Henning Schulzrinne 
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis 
CC: "Peterson, Jon" , simple@mailman.dynamicsoft.com,
        rsparks@dynamicsoft.com
Subject: Re: [Simple] Message sessions
References: <70565611B164D511957A001083FCDD56018703CD@va02.va.neustar.com> <008b01c2173d$2b8474a0$2dacff0c@C1893415A>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1864
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: 

I would prefer simple-message-session. I don't want to have to 
administer two very different types of devices, with different (and, in 
the case of mrose, undefined) network management.

I still agree with the argument in simple-message that a unified 
mechanism for page and session is very desirable. Transitioning and 
gatewaying will be much easier.

I don't see why mrose has an advantage in "standardized relay elements 
to be added as needed". What can be added there that can't be added in 
simple-message?

I'm afraid I find the "firewall discovery" item too vague to understand 
what exactly the advantage would be.

The overall system complexity, in terms of explaining what's going on 
and in terms of implementing, seem far less in a unified system where 
page and session mode share conceptual elements where this makes sense.

Dean Willis wrote:
> Jon asked:
> 
>>Now that the presence and watcherinfo work has gone forward to the
> 
> IESG, we
> 
>>need to return to the issue of message sessions - we are quite a bit
> 
> overdue
> . . .
> 
>>Two proposals have been made for session protocols:
>>
>>http://www.ietf.org/internet-drafts/draft-mrose-simple-exchange-01.txt
>>
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-sessi
> on-0
> 
>>0.txt
> 
> 
> I personally lean towards the mrose approach. BEEP does a decent job of
> the message delivery operation. It allows standardized relay elements to
> be added as needed and provides for a sort of path-discovery that would
> appear to be beneficial in firewall traversal scenarios. It provides a
> nice layering distinctiuon between "can I talk to you" and "may I talk
> to the network".
> 
> --
> Dean
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple



From vishal@knowsys.net  Thu Jun 20 08:10:48 2002
Received: from nghmail ([63.104.239.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id IAA13245
	for ; Thu, 20 Jun 2002 08:10:47 -0400 (EDT)
Received: (qmail 22824 invoked from network); 20 Jun 2002 13:08:52 -0000
Received: from unknown (HELO MC11VOIP) (61.11.57.40)
  by nghmail with SMTP; 20 Jun 2002 13:08:52 -0000
Message-ID: <004601c21853$d226b720$5601a8c0@knowsys.net>
From: "vishal" 
To: 
Date: Thu, 20 Jun 2002 17:42:43 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0041_01C21881.E1EABB60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Length: 1641
Subject: [Simple] buddy list draft
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0041_01C21881.E1EABB60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi ,
    Is there any draft available which talks about buddy list management =
,I mean what message should be sent to add,delete and modify  buddy list =
information

regards, vishal

Vishal ,
Knowledge Systems Pvt Ltd  ,INDIA
470, East End Main Road =20
9th Block Jayanagar ,
Bangalore 560 069 =20
Telephone: +91-80-6545252

------=_NextPart_000_0041_01C21881.E1EABB60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi ,


    Is there any draft =
available=20
which talks about buddy list management ,I mean what message should be =
sent to=20
add,delete and modify  buddy list information


 


regards, vishal


 


Vishal ,
Knowledge Systems Pvt =
Ltd =20
,INDIA
470, East End Main Road  
9th Block Jayanagar =
,
Bangalore=20
560 069  
Telephone: +91-80-6545252


------=_NextPart_000_0041_01C21881.E1EABB60--


From jdrosen@dynamicsoft.com  Thu Jun 20 09:40:05 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13555
	for ; Thu, 20 Jun 2002 09:40:04 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.185])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5KDe4YH018098;
	Thu, 20 Jun 2002 09:40:05 -0400 (EDT)
Message-ID: <3D11DB33.2020105@dynamicsoft.com>
Date: Thu, 20 Jun 2002 09:40:03 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: vishal 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] buddy list draft
References: <004601c21853$d226b720$5601a8c0@knowsys.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1011
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: 

There is nothing yet, beyond things like using the web (which I still 
think is the best means whenever its available). One of the items on our 
new charter is a requirements document for manipulation of buddy lists, 
amongst other operations, which will lead to a specification for such 
manipulations.

-Jonathan R.

vishal wrote:
> Hi ,
>     Is there any draft available which talks about buddy list management
> ,I mean what message should be sent to add,delete and modify buddy list
> information
>  
> regards, vishal
>  
> Vishal ,
> Knowledge Systems Pvt Ltd  ,INDIA
> 470, East End Main Road  
> 9th Block Jayanagar ,
> Bangalore 560 069  
> Telephone: +91-80-6545252
> 


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From bcampbell@dynamicsoft.com  Thu Jun 20 17:30:15 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14900
	for ; Thu, 20 Jun 2002 17:30:14 -0400 (EDT)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g5KLUBr28766;
	Thu, 20 Jun 2002 16:30:11 -0500 (CDT)
Message-ID: <3D124922.4010509@dynamicsoft.com>
Date: Thu, 20 Jun 2002 16:29:06 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simple 
CC: Ben Campbell ,
        Jonathan Rosenberg
 ,
        Brian Stucker ,
        Sean Olson ,
        Jon Peterson
 
References: <3D00F561.9010208@dynamicsoft.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 7242
Subject: [Simple] Choosing a mechanism for presence publication.
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: 

Several of us have engaged in an offline discussion on how to handle the 
publication of presence imformation from a PUA to a remote PA. We think 
we have reached a preliminary conclusion on the mechanism choice. This 
email reflects (what I believe to be) the consensus of that group so 
far. The bottom line is, there is significant advantage in using a SIP 
based mechanism.

There has been some controversy over the choice of mechanism by which
SIMPLE presence user agents publish information to remote presence
agents. The two most favored approaches so far have been the creation of
a new SIP method for the purpose, and the use of HTTP.

Nature of Presence Publication:

We propose a model for presence composition where more than one PUA may
publish on behalf of a single presentity. Those PUAs may exist in
separate administrative domains. The publications eventually make it to 
a logical network element that composes the views of presence sent by 
the various PUAs into a composite presence document. For the moment, at 
least, we are calling this logical element a "compositor". This model 
implies a few assumptions for publication:

1) A PUA must be capable of remotely publishing a presence document to a 
compositor. There is no requirement so far for the PUA to query a PA to 
determine what document it had published previously. We assume the PUA 
can subscribe to the final composed document via SIMPLE.

2) A presence document can be expressed by a MIME body part.

3) The document published by a PUA to a particular input is not
dependent upon previous publications to that input. The only transaction
semantic for a given input is "replace". (Note that this does not
prevent the compositor from applying complex application semantics to
compose the input, along with all other inputs, into a composite
presence document.) Any versioning is handled by payload itself.

4) The composition semantics belong to the local policy of the
compositor. The PUA does not need to understand these semantics, and
cannot expect to make composition policy choices as part of the
publication action. If a principle needs to make composition policy
decisions, that is through some other mechanism.

5) There may be multiple PUAs publishing on behalf of the same
presentity. There is no assumption that these PUAs all connect through
the same network, or even belong to the same administrative or security 
domain.

Differences between HTTP and SIP publication:

HTTP is well suited for moving data around in the form of MIME body
parts. An HTTP client-to-server publication solution would not require
much work to specify. A SOAP over HTTP solution would additionally allow
complex transaction semantics with little additional work.

HTTP, however, does not have a well-defined routing model at the
application level. It works fine if the publication point is well known
and fairly static, but it will require additional work to deal with
situations where the publication point changes dynamically.

SIP, on the otherhand, is built around the concept of mobility of
endpoints. The SIP proxy, registrar, and location service concepts
provide a rich mechanism of finding a dynamically changing endpoint from
and address of record.

SIP, however, does not have an existing method suited for presence
publication. REGISTER gets us part of the way, but has well-known
limitations when used for this purpose. SIP is, by nature, also adept at
moving around MIME payloads, so the creation of such a method is not a
particularly difficult task.

Motivation for a SIP based mechanism:

The application-level routing capabilities of SIP can be very useful for
presence publication. If all PUAs for a given presentity exist in the
same administrative domain, then they can most likely publish directly
to a compositor. But if PUAs exist outside the administrative domain, it
is likely they will not be able to do so.

For example, suppose that Alice uses a presence service that allows
multiple PUAs to publish to a compositor inside the service provider
network. Further suppose that Alice wishes to incorporate presence
information from an external provider, that has no business relationship
with her primary provider. For this example, Alice wishes to use a
shared browsing service that tracks the "location" she is currently
browsing in the web. That service acts as a PUA on Alice's behalf, and
publishes the information to her primary presence provider. Other users
of the shared browsing service can subscribe to her presence
information, and determine when they are browsing the same site.

The presence provider is highly unlikely to allow the external PUA to
send data directly to the compositor. But if Alice registers a contact
with a methods parameter value of "PUBLISH", that PUA can send a publish
request to an edge proxy in the presence providers network, and use
Alice's address of record as the requestURI. This AoR could be her
normal SIP URI, or it could be a special AoR for the purposes of
presence publication. The proxy forwards the request to the compositor,
without the external PUA having to talk directly to the compositor, or
even know its IP address.

Now consider that Alice's primary providor is actually an enterprise.
That enterprise has different compositors for different departments. The
external provider has no way of knowing this internal organization, nor
does it know what department Alice works in. Still, Alice register's her 
publication contact at an enterprise registrar, the external
provider sends the publish request to Alice's address of record, and the
companies internal SIP network handles things from there, eventually
getting the request to the correct compositor.

The composition model does not at first appear to require publishing to
dynamically changing PAs. But a very powerful, but often forgotten,
aspect of SIMPLE is it allows a PA to exist on an end-user device.
Indeed, some early implentations of SIMPLE rely on exactly that model.
It is reasonable to expect the composition model above to co-exist with
end-user device PAs, where the PA location changes dynamically.

For example, imagine Alice hosts a PA on her PC, which aquires its IP
address via DHCP. This address changes relatively frequently, and 
registers a publish contact with an enterprise registrar. Now,
imagine she also has a mobile phone which contains a PUA. She wants her
presence document to show a combined view of her PCs concept of her
presence and her mobile phone service's concept of her precence. She
cannot simply tell the mobile service her PC address since it changes
often. Instead, she tells the service an AoR to publish presence to.
The mobile service publishes presence state to that AoR, which resolves
to a SIP proxy or redirect server. Normal SIP proxy or redirect behavior
is invoked to get the publication to Alice's PC based on her publish 
contact registration.

It is our opinion that SIP style routing is very useful for presence
publication. Without the application level routing capabilities of SIP,
it would be difficult to build these sort of services. It is more
appropriate to add a publication mechanism to SIP than to standardize
SIP-style routing features for HTTP proxies.


From tony@att.com  Thu Jun 20 22:12:34 2002
Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15690
	for ; Thu, 20 Jun 2002 22:12:34 -0400 (EDT)
Received: from maillennium.att.com ([135.25.114.99])
	by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g5L2CWgY018617
	for ; Thu, 20 Jun 2002 22:12:33 -0400 (EDT)
Received: from att.com ([135.210.40.170])
          by maillennium.att.com (mailgw1) with SMTP
          id <20020621021231gw1009aru9e>
          (Authid: tony);
          Fri, 21 Jun 2002 02:12:31 +0000
Message-ID: <3D128B90.8080600@att.com>
Date: Thu, 20 Jun 2002 22:12:32 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simple 
Subject: Re: [Simple] Choosing a mechanism for presence publication.
References: <3D00F561.9010208@dynamicsoft.com> <3D124922.4010509@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 573
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: 

I feel that this is going in the right direction and agree with the 
conclusion to use a SIP enhancement for doing publication.

	Tony Hansen
	tony@att.com

Ben Campbell wrote:
> Several of us have engaged in an offline discussion on how to handle the 
> publication of presence imformation from a PUA to a remote PA. We think 
> we have reached a preliminary conclusion on the mechanism choice. This 
> email reflects (what I believe to be) the consensus of that group so 
> far. The bottom line is, there is significant advantage in using a SIP 
> based mechanism.  ...


From bcampbell@dynamicsoft.com  Fri Jun 21 16:55:01 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18836
	for ; Fri, 21 Jun 2002 16:55:00 -0400 (EDT)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g5LKsIr25601;
	Fri, 21 Jun 2002 15:54:18 -0500 (CDT)
Message-ID: <3D139238.8010102@dynamicsoft.com>
Date: Fri, 21 Jun 2002 15:53:12 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sean Olson 
CC: Paul Kyzivat ,
        "Rosen, Brian"
 ,
        "'Jonathan Rosenberg'"
 , bateman@acm.org,
        "'Li Hua Tang'"
 ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'"
 ,
        simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <20020613224139.65227.qmail@web11602.mail.yahoo.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3624
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: 

Sean Olson wrote:
> I think we are talking about different things. Part
> of the confusion on "status" is that it can refer
> to *at least* three different things:
> 
>  1. Presence - can I communicate
>  2. Availability - do I want to communicate
>  3. Capability - what are the mechanisms I have 
>        at my disposal to communicate with
> 
> I believe a raw notion of capability (e-mail, http,
> sip, etc.) may be appropriate for a "presence"
> document.
> 
> However, more advanced notions such as I support
> H.263 video or I have a color display capable of
> 640x480 resolution, etc. are a bit of a stretch.
> 
> Part of these device capabilities are covered
> by CC/PP (the target application is web browsing,
> but the CC/PP framework can be extended to much
> broader capabilities ala RDF)

One could also make this sort of thing up to the underlying 
communication protocol, rather than move them as part of presence. For 
example, I might have a SIP contact in a presence document. I don't have 
to add what codecs I support. If someone wants to talk to me, they send 
an INVITE, and the normal SIP process figures out the codec. There is of 
course some benefit to knowing the mode (am I INVITEing for a video 
session vs. a voice session.)


> 
> /sean
> 
> --- Paul Kyzivat  wrote:
> 
>>
>>Sean Olson wrote:
>>
>>>I may be misunderstanding you, but I don't
>>>believe capacity and capabilities are necessarily
>>>things you want to publish as presence. I agree
>>>they are useful things to have for routing
>>>decisions, I just don't think they should be
>>>part of a presence document.
>>
>>Maybe we aren't thinking of the same things, because
>>I see these as very relevant to presence.
>>
>>For instance, capability/willingness to communicate
>>on the subject of auto-repair is just a slightly
>>more refined form of the business/personal
>>distinction.
>>
>>Another sort of capability is media. I might be
>>available for voice only, or for voice and/or IM
>>and/or video at a given address.
>>
>>Capacity can be viewed a couple of ways: maybe I can
>>do IM both on my phone and my PC, but I can do it
>>well on my PC with a keyboard, whereas I can only do
>>it poorly on my
>>phone. 
>>
>>Capacity can also be a function of the person
>>manning the presentity. Suppose the address is
>>sip:answers@cars.r.us.com. Sometimes there is an
>>auto guru manning it, so the
>>capacity for auto-repair is high. Other times only a
>>trainee is present, who will try, but isn't very
>>good at auto-repair questions. So the capacity is
>>less.
>>
>>
>>>Rather, I would prefer to see something like
>>>CC/PP used in conjunction with presence to enable
>>>the scenarios you are talking about.
>>
>>I hadn't heard of CC/PP until now. After a (very)
>>quick search, it sounds like it is solving a
>>different problem. Perhaps it is still applicable,
>>but if so it would still
>>need to be integrated with presence somehow. If it
>>is XML, then perhaps it could be embedded in a
>>special  in the presence document. Because
>>this stuff can change
>>dynamically, and the presence client may need it to
>>decide who to call, it would be bad to have to
>>initiate some other sort of session with the
>>presentity or contact to get
>>this information.
>>
>>	Paul
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 




From pkyzivat@cisco.com  Fri Jun 21 18:45:28 2002
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 SAA19180
	for ; Fri, 21 Jun 2002 18:45:28 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5LMjfjX019617;
	Fri, 21 Jun 2002 18:45:41 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAM32030;
	Fri, 21 Jun 2002 18:49:47 -0400 (EDT)
Message-ID: <3D13AC75.B14B3AAE@cisco.com>
Date: Fri, 21 Jun 2002 18:45:09 -0400
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: Ben Campbell 
CC: Sean Olson ,
        "Rosen, Brian" ,
        "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <20020613224139.65227.qmail@web11602.mail.yahoo.com> <3D139238.8010102@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 985
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: 

Regarding what sort of "capabilities" should be reflected in presence, knowing the mode (audio, video, etc.) is very important. Individual codecs is probably going too far.

But this is a fine line. While I probably don't want to describe codecs for audio, I perhaps do want to describe the "codecs" for application - e.g. application/wb -
because the likelihood of success isn't very good without.

Maybe this is a matter of judicious use of wildcards - advertise audio/* but application/wb.

	Paul

Ben Campbell wrote:
> 
> One could also make this sort of thing up to the underlying
> communication protocol, rather than move them as part of presence. For
> example, I might have a SIP contact in a presence document. I don't have
> to add what codecs I support. If someone wants to talk to me, they send
> an INVITE, and the normal SIP process figures out the codec. There is of
> course some benefit to knowing the mode (am I INVITEing for a video
> session vs. a voice session.)

From seancolson@yahoo.com  Fri Jun 21 19:40:34 2002
Received: from web11605.mail.yahoo.com (web11605.mail.yahoo.com [216.136.172.57])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id TAA19360
	for ; Fri, 21 Jun 2002 19:40:34 -0400 (EDT)
Message-ID: <20020621234033.95187.qmail@web11605.mail.yahoo.com>
Received: from [207.46.137.9] by web11605.mail.yahoo.com via HTTP; Fri, 21 Jun 2002 16:40:33 PDT
Date: Fri, 21 Jun 2002 16:40:33 -0700 (PDT)
From: Sean Olson 
Subject: Re: Status discussion again RE: [Simple] Test message
To: Paul Kyzivat ,
        Ben Campbell 
Cc: Sean Olson ,
        "Rosen, Brian" ,
        "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3D13AC75.B14B3AAE@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1699
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: 

Mode seems to make sense. I like the idea
of announcing supported MIME types, BUT I think
it is very dangerous to infer applications from
MIME types (as you hint at for the 
application/wb case). I see this leading to a
rathole. Could we set the bar at just 
announcing "modes" for now? 

/sean

--- Paul Kyzivat  wrote:
> Regarding what sort of "capabilities" should be
> reflected in presence, knowing the mode (audio,
> video, etc.) is very important. Individual codecs is
> probably going too far.
> 
> But this is a fine line. While I probably don't want
> to describe codecs for audio, I perhaps do want to
> describe the "codecs" for application - e.g.
> application/wb -
> because the likelihood of success isn't very good
> without.
> 
> Maybe this is a matter of judicious use of wildcards
> - advertise audio/* but application/wb.
> 
> 	Paul
> 
> Ben Campbell wrote:
> > 
> > One could also make this sort of thing up to the
> underlying
> > communication protocol, rather than move them as
> part of presence. For
> > example, I might have a SIP contact in a presence
> document. I don't have
> > to add what codecs I support. If someone wants to
> talk to me, they send
> > an INVITE, and the normal SIP process figures out
> the codec. There is of
> > course some benefit to knowing the mode (am I
> INVITEing for a video
> > session vs. a voice session.)
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

From nsyracus@cnri.reston.va.us  Mon Jun 24 07:49:56 2002
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 HAA00771
	for ; Mon, 24 Jun 2002 07:49:55 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00840;
	Mon, 24 Jun 2002 07:49:13 -0400 (EDT)
Message-Id: <200206241149.HAA00840@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
Date: Mon, 24 Jun 2002 07:49:13 -0400
Content-Length: 2887
Subject: [Simple] I-D ACTION:draft-allen-simple-msg-3gpp-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: 3GPP work on SIP based messaging
	Author(s)	: A. Allen
	Filename	: draft-allen-simple-msg-3gpp-00.txt
	Pages		: 6
	Date		: 21-Jun-02
	
The 3rd Generation Partnership Project (3GPP) is using SIP RFC 3261
[1] as the session establishment protocol for the 3GPP IP Multimedia
Core Network Subsystem (IM CN Subsystem).
3GPP has recently started working on messaging over the IM CN
Subsystem.  It is intended that this will utilize the IM CN Subsystem
for delivery and may be based on IEFT protocols including the work
being performed in the SIMPLE working group.
In this document is provided an outline and areas of interest of the
3GPP work on SIP based messaging for the information of the SIMPLE
working group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-allen-simple-msg-3gpp-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-allen-simple-msg-3gpp-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-allen-simple-msg-3gpp-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:	<20020621140602.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-allen-simple-msg-3gpp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-allen-simple-msg-3gpp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020621140602.I-D@ietf.org>

--OtherAccess--

--NextPart--



From pkyzivat@cisco.com  Tue Jun 25 01:23:22 2002
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 BAA03640
	for ; Tue, 25 Jun 2002 01:23:21 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5P5NYvl014191;
	Tue, 25 Jun 2002 01:23:35 -0400 (EDT)
Received: from cisco.com (sjc-vpn2-896.cisco.com [10.21.115.128])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAM40701;
	Tue, 25 Jun 2002 01:27:31 -0400 (EDT)
Message-ID: <3D17FE2C.60CDC385@cisco.com>
Date: Tue, 25 Jun 2002 01:22:52 -0400
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: Sean Olson 
CC: Ben Campbell ,
        "Rosen, Brian" ,
        "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <20020621234033.95187.qmail@web11605.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1320
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: 


Sean Olson wrote:
> 
> Mode seems to make sense. I like the idea
> of announcing supported MIME types, BUT I think
> it is very dangerous to infer applications from
> MIME types (as you hint at for the
> application/wb case). I see this leading to a
> rathole. Could we set the bar at just
> announcing "modes" for now?


You have to tell me what you mean by "mode" then.

I don't think of application/wb as an "application" in any specific sense. As far as I am concerned, "application" and "voice" are simply different subdivisions of the
overall mimetype namespace. But "voice" in its own right is much more specific than "application" is. I have a reasonable chance of deciding if I can support "voice"
without more detail. (If I can't support the offered codecs then I can probably find a transcoder that can convert to something I do understand.)

But by itself "application" tells me nothing about what I will be expected to do. And in general there are no transcoders that can convert between application/wb that I
support and application/foo that I don't - there is no least common denominator between subtypes of application. 

If the bar is set so low that mime subtypes can never be used, then presence will not be at all useful for any media that happen to be described by subtypes of application.

	Paul

From seancolson@yahoo.com  Tue Jun 25 02:37:36 2002
Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA03880
	for ; Tue, 25 Jun 2002 02:37:35 -0400 (EDT)
Received: from 12-235-154-217.client.attbi.com (HELO BOB) (seancolson@12.235.154.217 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Jun 2002 06:37:30 -0000
Reply-To: 
From: "Sean Olson" 
To: "'Paul Kyzivat'" 
Cc: "'Ben Campbell'" ,
        "'Rosen, Brian'" ,
        "'Jonathan Rosenberg'" , ,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        
Subject: RE: Status discussion again RE: [Simple] Test message
Date: Mon, 24 Jun 2002 23:37:35 -0700
Message-ID: <000001c21c12$cb7ab1c0$6601a8c0@BOB>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <3D17FE2C.60CDC385@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 2696
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: 

What I mean is that while application/wb may give you a clue as to the
application,
text/html, image/jpeg, or even message/sip do not. MIME types are not
usually
a good indication of the application that will process that media. 
"voice" is interesting, but as a MIME type would more likely be
represented as
the less useful audio/g711, etc. 

If what you want to convey is a list of MIME types, that's fine. I just
don't want to confuse that with a list of applications. (Of course, MIME
types
are best represented with a suitable subtype as you mention)

By mode, I meant a token that succintly defines an application -- like
"voice" perhaps.
But I definitely don't want to get into the game of defining a list of
codecs ... this 
is much better handled by SIP itself than by a presence document format.

/sean


-----Original Message-----
From: simple-admin@mailman.dynamicsoft.com
[mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Paul Kyzivat
Sent: Monday, June 24, 2002 10:23 PM
To: Sean Olson
Cc: Ben Campbell; Rosen, Brian; 'Jonathan Rosenberg'; bateman@acm.org;
'Li Hua Tang'; 'DAO TRUNG Tin FTRD/DAC/ISS';
simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message




Sean Olson wrote:
> 
> Mode seems to make sense. I like the idea
> of announcing supported MIME types, BUT I think
> it is very dangerous to infer applications from
> MIME types (as you hint at for the
> application/wb case). I see this leading to a
> rathole. Could we set the bar at just
> announcing "modes" for now?


You have to tell me what you mean by "mode" then.

I don't think of application/wb as an "application" in any specific
sense. As far as I am concerned, "application" and "voice" are simply
different subdivisions of the overall mimetype namespace. But "voice" in
its own right is much more specific than "application" is. I have a
reasonable chance of deciding if I can support "voice" without more
detail. (If I can't support the offered codecs then I can probably find
a transcoder that can convert to something I do understand.)

But by itself "application" tells me nothing about what I will be
expected to do. And in general there are no transcoders that can convert
between application/wb that I support and application/foo that I don't -
there is no least common denominator between subtypes of application. 

If the bar is set so low that mime subtypes can never be used, then
presence will not be at all useful for any media that happen to be
described by subtypes of application.

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


From aki.niemi@nokia.com  Tue Jun 25 09:21:53 2002
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 JAA05008
	for ; Tue, 25 Jun 2002 09:21:53 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5PDNfW22368
	for ; Tue, 25 Jun 2002 16:23:42 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 25 Jun 2002 16:21:51 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 25 Jun 2002 16:21:51 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message sessions
Date: Tue, 25 Jun 2002 16:21:51 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE33C@esebe013.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message sessions
Thread-Index: AcIXuTuQ/elXHPCLSDuf9UxUbxd0LAD0ru2A
To: , 
Cc: , ,
        
X-OriginalArrivalTime: 25 Jun 2002 13:21:51.0651 (UTC) FILETIME=[44761730:01C21C4B]
Content-Length: 3081
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA05008
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: 

Hi,

I would also prefer simple-message-session, mainly because of the ability to have a unified mechanism for both the paging mode and the session mode IM. Also, having SIP MESSAGE as the session transport may have benefits in multiparty sessions. 

However, I don't see any reason why simple-exchange shouldn't progress as well. Ultimately these are session IM "codecs", and I don't think having several of them hurts as long as there is one that by default is supported by all implementations.

So perhaps we should have simple-message-session as a WG item for SIMPLE, but encourage simple-exchange to progress as well. Maybe towards Informational RFC status, if not standards track? 

Cheers,
Aki 


> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Wednesday, June 19, 2002 8:41 PM
> To: Dean Willis
> Cc: Peterson, Jon; simple@mailman.dynamicsoft.com;
> rsparks@dynamicsoft.com
> Subject: Re: [Simple] Message sessions
> 
> 
> I would prefer simple-message-session. I don't want to have to 
> administer two very different types of devices, with 
> different (and, in 
> the case of mrose, undefined) network management.
> 
> I still agree with the argument in simple-message that a unified 
> mechanism for page and session is very desirable. Transitioning and 
> gatewaying will be much easier.
> 
> I don't see why mrose has an advantage in "standardized relay 
> elements 
> to be added as needed". What can be added there that can't be 
> added in 
> simple-message?
> 
> I'm afraid I find the "firewall discovery" item too vague to 
> understand 
> what exactly the advantage would be.
> 
> The overall system complexity, in terms of explaining what's going on 
> and in terms of implementing, seem far less in a unified system where 
> page and session mode share conceptual elements where this 
> makes sense.
> 
> Dean Willis wrote:
> > Jon asked:
> > 
> >>Now that the presence and watcherinfo work has gone forward to the
> > 
> > IESG, we
> > 
> >>need to return to the issue of message sessions - we are quite a bit
> > 
> > overdue
> > . . .
> > 
> >>Two proposals have been made for session protocols:
> >>
> >>http://www.ietf.org/internet-drafts/draft-mrose-simple-excha
nge-01.txt
>>
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-sessi
> on-0
> 
>>0.txt
> 
> 
> I personally lean towards the mrose approach. BEEP does a decent job of
> the message delivery operation. It allows standardized relay elements to
> be added as needed and provides for a sort of path-discovery that would
> appear to be beneficial in firewall traversal scenarios. It provides a
> nice layering distinctiuon between "can I talk to you" and "may I talk
> to the network".
> 
> --
> Dean
> 
> _______________________________________________
> 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 jdrosen@dynamicsoft.com  Tue Jun 25 17:34:42 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06505
	for ; Tue, 25 Jun 2002 17:34:41 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.192])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5PLYfYH022376
	for ; Tue, 25 Jun 2002 17:34:41 -0400 (EDT)
Message-ID: <3D18E1EF.7050700@dynamicsoft.com>
Date: Tue, 25 Jun 2002 17:34:39 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1590
Subject: [Simple] updated buddy list package draft
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: 

Folks,

I've submitted an update to the buddy list event package. As this is now 
a charter item based on our new charter, it also has a new -ietf name. 
Until it appears in the archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-presencelist-package-00.txt

Some of the changes since the previous version:

* change from the term "buddy list" to "presence list" and "buddy" to 
"presentity" since apparently buddy list is an AOL term.

* specified a new XML document type, using XML schema, that adds list 
capability to PIDF. THis is now a mandatory-to imeplement type for this 
package. You also need to support PIDF and MAY support multipart/mixed.

* a presence-list can contain presentities and also other 
presence-lists. This requires the presence list server (PLS) to itself 
use the presence-list package when subscribing to elements in the list, 
and then backing off to regular presence if that package is not 
supported. This is a potential issue.

* formal specification of algorithm to support partial updates.

* IANA registrations of new namespace and MIME type.

There are several open issues. I will send separate emails on those, one 
per each open issue, in order to facilitate discussion.

THanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From jdrosen@dynamicsoft.com  Tue Jun 25 22:25:12 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07313
	for ; Tue, 25 Jun 2002 22:25:12 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.192])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5Q2PDYH022507
	for ; Tue, 25 Jun 2002 22:25:13 -0400 (EDT)
Message-ID: <3D192608.6030407@dynamicsoft.com>
Date: Tue, 25 Jun 2002 22:25:12 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 997
Subject: [Simple] new I-D on data requirements
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: 

Folks,

Myself and Markus Isomaki have submitted an Internet Draft that is a 
first cut at requirements for management of buddy list and authorization 
list functions (this is also a new item on our charter). Until it 
appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt

In addition to the baseline requirements for these functions, the draft 
also proposes a model for unifying these problems. This is also a first 
cut; comments and criticisms and welcome.

My aim is to determine if there is consensus to adopt this as the 
starting point for our work item on this topic.

Thanks!

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From vishal@knowsys.net  Wed Jun 26 02:21:55 2002
Received: from nghmail ([63.104.239.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA07951
	for ; Wed, 26 Jun 2002 02:21:55 -0400 (EDT)
Received: (qmail 28508 invoked from network); 26 Jun 2002 07:19:38 -0000
Received: from unknown (HELO MC11VOIP) (61.11.57.36)
  by nghmail with SMTP; 26 Jun 2002 07:19:38 -0000
Message-ID: <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net>
From: "vishal" 
To: "Jonathan Rosenberg" ,
        
References: <3D192608.6030407@dynamicsoft.com>
Subject: Re: [Simple] new I-D on data requirements
Date: Wed, 26 Jun 2002 11:52:26 +0530
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.00.2615.200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Length: 2719
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: 

Dr Jonathon,
   I think following requirements can also be added to this draft
section 2.2

1. Server SHOULD be able to contact other servers in case buddy list
   not found in local storage.
2. server should be able to accept requests coming directly from client
  or via intermediate entity like proxy (if it includes authetication
  info).
3. server should be able to route response over same route as request i.e
   support for record-route.
4.  MUST have Multicast capability at server i.e UDP support .In case buddy
list  shared by many user ,modified by one user then server SHOULD be able
to synchronize cache of
clients.
5. Server SHOULD be able to limit maximum number of users sharing buddy
   list.
6. Server SHOULD be able to specify maximum buddy list nesting(list within
list) level.

section 2.2 REQ 8: A buddy list should be considered deleted when all the
owners of buddy list have deleted it. Deleted buddy list should not be
accessible after deletion

section 4.3 (protocol requirements)

1. Support for conference invitation to multiple users .Command can be
   sent to buddy list server with buddy list name .Server MUST resolve
   buddy list to buddy(s) and send INVITE message (or route through
intermediate entity)
   to all online users after checking their status.

regards, vishal



----- Original Message -----
From: Jonathan Rosenberg 
To: 
Sent: Wednesday, June 26, 2002 7:55 AM
Subject: [Simple] new I-D on data requirements


> Folks,
>
> Myself and Markus Isomaki have submitted an Internet Draft that is a
> first cut at requirements for management of buddy list and authorization
> list functions (this is also a new item on our charter). Until it
> appears in the archives, you can pick up a copy at:
>
> http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt
>
> In addition to the baseline requirements for these functions, the draft
> also proposes a model for unifying these problems. This is also a first
> cut; comments and criticisms and welcome.
>
> My aim is to determine if there is consensus to adopt this as the
> starting point for our work item on this topic.
>
> Thanks!
>
> -Jonathan R.
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From jose@tct.hut.fi  Wed Jun 26 09:21:02 2002
Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09127
	for ; Wed, 26 Jun 2002 09:21:01 -0400 (EDT)
Received: (from www@localhost)
	by keskus.tct.hut.fi (8.10.0/8.10.0) id g5QDKtB16772;
	Wed, 26 Jun 2002 16:20:55 +0300 (EET DST)
From: Costa Requena 
X-Authentication-Warning: keskus.tct.hut.fi: www set sender to jose@tct.hut.fi using -f
To: vishal 
Subject: Re: [Simple] new I-D on data requirements
Message-ID: <1025097655.3d19bfb781f8d@keskus.tct.hut.fi>
Date: Wed, 26 Jun 2002 16:20:55 +0300 (EET DST)
Cc: Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
References: <3D192608.6030407@dynamicsoft.com> <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net>
In-Reply-To: <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Originating-IP: 192.100.124.220
Content-Length: 1115
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: 

Hi Vishal,

I have some comments:

>    I think following requirements can also be added to this draft
> section 2.2
> 
> 1. Server SHOULD be able to contact other servers in case buddy list
>    not found in local storage.

Are you proposing some recursive mechanism in case the buddy list contain a 
nested buddy list? It could be OK if the nested buddy list is within the 
same domain but it could have some security flaws when fetching the buddy list 
from other serves/domain. I think it should be stated that nested buddy list 
should contain FQDN within the local domain.

> 4.  MUST have Multicast capability at server i.e UDP support .In case
> buddy
> list  shared by many user ,modified by one user then server SHOULD be
> able
> to synchronize cache of
> clients.

Correct me if I'm wrong but is the idea to share the same buddy list by multiple 
users? I think that each presentity has its own buddy list, despite he/she can 
use different list to perform the buddy list functionality. The same buddy list 
can be used from different termianls but still the owner or presentity  is the 
same.

BR
Jose

From petkos@cs.columbia.edu  Wed Jun 26 10:12:51 2002
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 KAA09347
	for ; Wed, 26 Jun 2002 10:12:50 -0400 (EDT)
Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5])
	by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5QECoxc001776;
	Wed, 26 Jun 2002 10:12:50 -0400 (EDT)
Received: (from petkos@localhost)
	by dynasty.cs.columbia.edu (8.9.3/8.9.3) id KAA03547;
	Wed, 26 Jun 2002 10:12:49 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200206261412.KAA03547@dynasty.cs.columbia.edu>
To: simple@mailman.dynamicsoft.com
Date: Wed, 26 Jun 2002 10:12:49 -0400 (EDT)
Cc: vishal@knowsys.net
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 559
Subject: [Simple] new I-D on data requirements
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: 

Vishal,

> section 4.3 (protocol requirements)
>
> 1. Support for conference invitation to multiple users .Command can be
>   sent to buddy list server with buddy list name .Server MUST resolve
>   buddy list to buddy(s) and send INVITE message (or route through
> intermediate entity)
>   to all online users after checking their status.
>
> regards, vishal

This was not conferencing requirements draft.
Anyway, conf-reqs draft includes this mass-invitation 
requirement (as well as many other requirements listed also
in the buddylist reqs draft).

Petri

From jdrosen@dynamicsoft.com  Wed Jun 26 10:50:41 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09498
	for ; Wed, 26 Jun 2002 10:50:41 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.192])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5QEoeYH022821;
	Wed, 26 Jun 2002 10:50:40 -0400 (EDT)
Message-ID: <3D19D4C0.1080608@dynamicsoft.com>
Date: Wed, 26 Jun 2002 10:50:40 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: vishal 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] new I-D on data requirements
References: <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 4263
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: 


vishal wrote:
> Dr Jonathon,
>    I think following requirements can also be added to this draft
> section 2.2
> 
> 1. Server SHOULD be able to contact other servers in case buddy list
>    not found in local storage.

Let me make sure I understand. I want to manipulate the list 
sip:myfriends@domain.com. So, I contact the server for example.com. It 
realizes that it doesn't own domain.com, so it forwards the control 
requests to domain.com. Is that what you want?

If so, it sounds like a basic proxy function, as provided by both SIP 
and HTTP as well. If thats what you mean, I am OK with that.



> 2. server should be able to accept requests coming directly from client
>   or via intermediate entity like proxy (if it includes authetication
>   info).

Is this not the same as 1.?

> 3. server should be able to route response over same route as request
> i.e
>    support for record-route.

Are you talking about the requests to manipulate the buddy list? There 
is no notion of session here - this is a transactional/RPC type of 
protocol. Record-routing makes no sense for transactional mechanisms. 
Thats why you can't record-route OPTIONS in SIP. If you are asking for 
the response to follow the same path as the request, thats part of the 
definition of proxying.


> 4.  MUST have Multicast capability at server i.e UDP support .In case
> buddy
> list  shared by many user ,modified by one user then server SHOULD be
> able
> to synchronize cache of
> clients.

I agree with the existence of multiple clients. Thats already captured 
in REQ 12. However, cache synchronization (which is also a requirement) 
is not the same as multicast, and I would personally rather shoot myself 
in the head than try to develop a distributed cache synchronization 
protocol using multicast. Regardless, this document is about 
requirements, not implementation, and I believe the requirement for 
multiple cached copies, each of which can be manipulated, is already 
captured in REQ 11 and REQ 12.



> 5. Server SHOULD be able to limit maximum number of users sharing buddy
>    list.

What does it mean to "share" in this context? Share meaning "number of 
simultaneously cached copies?" Share meaning "number of subscriptions to 
the list"?


> 6. Server SHOULD be able to specify maximum buddy list nesting(list
> within
> list) level.

Since the a list within a list may not be local, there is no way for a 
server to even know what the depth is, since the tree is effectively 
distributed across the servers that own the various lists. From the 
perspective of a server, each list is of depth one - it contains entries 
that are subscribed to, period.


> 
> section 2.2 REQ 8: A buddy list should be considered deleted when all
> the
> owners of buddy list have deleted it. Deleted buddy list should not be
> accessible after deletion

You have a different model in mind than is currently specified in the 
document. I think you view there as being a list that is replicated once 
for each "owner" that accesses the list. When an owner modifies their 
replicated instance, that change is copied across all other instances. 
However, when deleted, only their instance is deleted. The list would 
still continue to exist for others.

I don't really see the benefit in this model, as opposed to the current 
model, where there is just one list.


> 
> section 4.3 (protocol requirements)
> 
> 1. Support for conference invitation to multiple users .Command can be
>    sent to buddy list server with buddy list name .Server MUST resolve
>    buddy list to buddy(s) and send INVITE message (or route through
> intermediate entity)
>    to all online users after checking their status.

This is outside the scope of this document. This document is about 
manipulating the list. As Petri has pointed out, you are asking for a 
mass invitation function, which is covered in his conferencing 
requirements document.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From jdrosen@dynamicsoft.com  Wed Jun 26 10:52:26 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09521
	for ; Wed, 26 Jun 2002 10:52:26 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.192])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5QEqKYH022824;
	Wed, 26 Jun 2002 10:52:20 -0400 (EDT)
Message-ID: <3D19D523.4030005@dynamicsoft.com>
Date: Wed, 26 Jun 2002 10:52:19 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Petri K. Koskelainen" 
CC: simple@mailman.dynamicsoft.com, vishal@knowsys.net
Subject: Re: [Simple] new I-D on data requirements
References: <200206261412.KAA03547@dynasty.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1350
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: 


Petri K. Koskelainen wrote:
> Vishal,
> 
> 
>>section 4.3 (protocol requirements)
>>
>>1. Support for conference invitation to multiple users .Command can be
>>  sent to buddy list server with buddy list name .Server MUST resolve
>>  buddy list to buddy(s) and send INVITE message (or route through
>>intermediate entity)
>>  to all online users after checking their status.
>>
>>regards, vishal
> 
> 
> This was not conferencing requirements draft.
> Anyway, conf-reqs draft includes this mass-invitation 
> requirement (as well as many other requirements listed also
> in the buddylist reqs draft).

Indeed, many of the functions here are needed for conferencing as well. 
This was the reason for my attempt to provide a generalized model at the 
end. It was my hope that this generalized model would support the data 
manipulation for conferencing as well. Certainly, conferencing has many 
other requirements that are beyond the scope of data manipulation, but 
some aspects are certainly in scope.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From hisham.khartabil@nokia.com  Wed Jun 26 11:12:57 2002
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 LAA09652
	for ; Wed, 26 Jun 2002 11:12:56 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5QFDOi13083
	for ; Wed, 26 Jun 2002 18:13:24 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 26 Jun 2002 18:12:55 +0300
Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 26 Jun 2002 18:12:55 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 26 Jun 2002 18:12:54 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message sessions
Date: Wed, 26 Jun 2002 18:12:54 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20376@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message sessions
Thread-Index: AcIXuTuQ/elXHPCLSDuf9UxUbxd0LAD0ru2AAGVPIfA=
To: , , 
Cc: , ,
        
X-OriginalArrivalTime: 26 Jun 2002 15:12:54.0972 (UTC) FILETIME=[F285EFC0:01C21D23]
Content-Length: 4602
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA09652
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: 

I also prefer simple-message-session for the same reasons provided by others.

I do have one objection though and that of course has something to do with the hop attribute and the proxy manipulating the body.

Now, Jonathan hates objections without alternate suggestion, so here is one :)

We define 2 new headers, media-type and media-path.

We define media-type to contain message/sip

media-type: message/sip

We define media-path to contain what the hop attribute contains. This works much like path-header except that it's specifying the path of the media and that it reaches the UAs.

These headers are of course reflected in the response so that both UAs learn the media path.

Of course, we can just define one header called sip-message-media-path (or something similar), that this limits extensibility.

I haven't thought about this thoroughly, so flame me.

Regards,
Hisham


> -----Original Message-----
> From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Tuesday, June 25, 2002 4:22 PM
> To: hgs@cs.columbia.edu; dean.willis@softarmor.com
> Cc: jon.peterson@neustar.biz; simple@mailman.dynamicsoft.com;
> rsparks@dynamicsoft.com
> Subject: RE: [Simple] Message sessions
> 
> 
> Hi,
> 
> I would also prefer simple-message-session, mainly because of 
> the ability to have a unified mechanism for both the paging 
> mode and the session mode IM. Also, having SIP MESSAGE as the 
> session transport may have benefits in multiparty sessions. 
> 
> However, I don't see any reason why simple-exchange shouldn't 
> progress as well. Ultimately these are session IM "codecs", 
> and I don't think having several of them hurts as long as 
> there is one that by default is supported by all implementations.
> 
> So perhaps we should have simple-message-session as a WG item 
> for SIMPLE, but encourage simple-exchange to progress as 
> well. Maybe towards Informational RFC status, if not standards track? 
> 
> Cheers,
> Aki 
> 
> 
> > -----Original Message-----
> > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Wednesday, June 19, 2002 8:41 PM
> > To: Dean Willis
> > Cc: Peterson, Jon; simple@mailman.dynamicsoft.com;
> > rsparks@dynamicsoft.com
> > Subject: Re: [Simple] Message sessions
> > 
> > 
> > I would prefer simple-message-session. I don't want to have to 
> > administer two very different types of devices, with 
> > different (and, in 
> > the case of mrose, undefined) network management.
> > 
> > I still agree with the argument in simple-message that a unified 
> > mechanism for page and session is very desirable. Transitioning and 
> > gatewaying will be much easier.
> > 
> > I don't see why mrose has an advantage in "standardized relay 
> > elements 
> > to be added as needed". What can be added there that can't be 
> > added in 
> > simple-message?
> > 
> > I'm afraid I find the "firewall discovery" item too vague to 
> > understand 
> > what exactly the advantage would be.
> > 
> > The overall system complexity, in terms of explaining 
> what's going on 
> > and in terms of implementing, seem far less in a unified 
> system where 
> > page and session mode share conceptual elements where this 
> > makes sense.
> > 
> > Dean Willis wrote:
> > > Jon asked:
> > > 
> > >>Now that the presence and watcherinfo work has gone forward to the
> > > 
> > > IESG, we
> > > 
> > >>need to return to the issue of message sessions - we are 
> quite a bit
> > > 
> > > overdue
> > > . . .
> > > 
> > >>Two proposals have been made for session protocols:
> > >>
> > >>http://www.ietf.org/internet-drafts/draft-mrose-simple-excha
> nge-01.txt
> >>
> > 
> > 
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-message-sessi
> on-0
> 
>>0.txt
> 
> 
> I personally lean towards the mrose approach. BEEP does a decent job of
> the message delivery operation. It allows standardized relay elements to
> be added as needed and provides for a sort of path-discovery that would
> appear to be beneficial in firewall traversal scenarios. It provides a
> nice layering distinctiuon between "can I talk to you" and "may I talk
> to the network".
> 
> --
> Dean
> 
> _______________________________________________
> 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 jose@tct.hut.fi  Wed Jun 26 12:39:07 2002
Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10017
	for ; Wed, 26 Jun 2002 12:39:07 -0400 (EDT)
Received: from pc110 (pc110.tct.hut.fi [130.233.154.110])
	by keskus.tct.hut.fi (8.10.0/8.10.0) with SMTP id g5QGd2r22355;
	Wed, 26 Jun 2002 19:39:02 +0300 (EET DST)
From: "jose" 
To: "Jonathan Rosenberg" ,
        "Petri K. Koskelainen" 
Cc: , 
Subject: RE: [Simple] new I-D on data requirements
Date: Wed, 26 Jun 2002 19:39:02 +0300
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)
In-Reply-To: <3D19D523.4030005@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 1791
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: 

Hi,

Some comments!

> >
> >>section 4.3 (protocol requirements)
> >>
> >>1. Support for conference invitation to multiple users
> .Command can be
> >>  sent to buddy list server with buddy list name .Server
> MUST resolve
> >>  buddy list to buddy(s) and send INVITE message (or route through
> >>intermediate entity)
> >>  to all online users after checking their status.
> >>
> >>regards, vishal
> >
> >
> > This was not conferencing requirements draft.
> > Anyway, conf-reqs draft includes this mass-invitation
> > requirement (as well as many other requirements listed also
> > in the buddylist reqs draft).
>
> Indeed, many of the functions here are needed for
> conferencing as well.
> This was the reason for my attempt to provide a generalized
> model at the
> end. It was my hope that this generalized model would support
> the data
> manipulation for conferencing as well. Certainly,
> conferencing has many
> other requirements that are beyond the scope of data
> manipulation, but
> some aspects are certainly in scope.

Certainly, conferencing have many other requirements but probably the
proposed generic model would fit just as a piece within the conferencing
machinery.
(probably into the membership control).

Petri what do you think?
BR
Jose

> -Jonathan R.
>
>
>
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From jdrosen@dynamicsoft.com  Wed Jun 26 14:28:24 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10352
	for ; Wed, 26 Jun 2002 14:28:24 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.192])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5QIS8YH023051;
	Wed, 26 Jun 2002 14:28:08 -0400 (EDT)
Message-ID: <3D1A07B7.9080701@dynamicsoft.com>
Date: Wed, 26 Jun 2002 14:28:07 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: aki.niemi@nokia.com, hgs@cs.columbia.edu, dean.willis@softarmor.com,
        jon.peterson@neustar.biz, simple@mailman.dynamicsoft.com,
        rsparks@dynamicsoft.com
Subject: Re: [Simple] Message sessions
References: <2038BCC78B1AD641891A0D1AE133DBB7C20376@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1110
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: 


hisham.khartabil@nokia.com wrote:
> We define 2 new headers, media-type and media-path.
> 
> We define media-type to contain message/sip
> 
> media-type: message/sip
> 
> We define media-path to contain what the hop attribute contains. This
> works much like path-header except that it's specifying the path of the
> media and that it reaches the UAs.
> 
> These headers are of course reflected in the response so that both UAs
> learn the media path.
> 
> Of course, we can just define one header called sip-message-media-path
> (or something similar), that this limits extensibility.
> 
> I haven't thought about this thoroughly, so flame me.

In what way does this differ from:

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From petkos@cs.columbia.edu  Wed Jun 26 15:20:36 2002
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 PAA10538
	for ; Wed, 26 Jun 2002 15:20:36 -0400 (EDT)
Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5])
	by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g5QJKRxc026753;
	Wed, 26 Jun 2002 15:20:27 -0400 (EDT)
Received: (from petkos@localhost)
	by dynasty.cs.columbia.edu (8.9.3/8.9.3) id PAA23241;
	Wed, 26 Jun 2002 15:20:26 -0400 (EDT)
From: "Petri K. Koskelainen" 
Message-Id: <200206261920.PAA23241@dynasty.cs.columbia.edu>
Subject: Re: [Simple] new I-D on data requirements
To: jose@tct.hut.fi (jose)
Date: Wed, 26 Jun 2002 15:20:26 -0400 (EDT)
Cc: jdrosen@dynamicsoft.com (Jonathan Rosenberg),
        petkos@cs.columbia.edu (Petri K. Koskelainen),
        simple@mailman.dynamicsoft.com, vishal@knowsys.net
In-Reply-To:  from "jose" at Jun 26, 2002 07:39:02 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1830
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: 

> Certainly, conferencing have many other requirements but probably the
> proposed generic model would fit just as a piece within the conferencing
> machinery.
> (probably into the membership control).
> 
> Petri what do you think?
> BR
> Jose


I guess it is too early to speculate on that.
(well, it is always possible to speculate)

First we have to create and agree on the requirements
for all use cases (data/conference/group manipulation)
and then to analyse whether general create/add/delete etc
solution can be utilized for all of them.

It might be useful to have one common data manipulation
solution, and then a lot of extensions for specific use
cases. On the other hand, it may turn out that the
benefit of having one solution for a couple of
create/add/delete functions is relative small
if the real problems are elsewhere, and this
minor issue enforces the use of same mechanism 
for extensions as well (e.g. XML, SOAP, ACAP, whatever
mechanism). Moreover, it may require too many compromises
if we have to interpret for each command that "if this
is conference, then do this, if this is a buddylist then do that".
Buddylist and conference semantics are very close, 
but still different. 

General solution may also restrict the specific use cases too much. 
For example, buddylist requirements say that it must be possible 
to authorize only specific users to manipulate the list. 
What if conferencing scenario would like
to separate between delete and update operations ?
(this was just an example)

The danger is that the general solution always have to enable
the most complex and feature-rich solution thus combining
the worst of every use case. If own dedicated solution is 
developed for each use, it may be simpler and more effective.

But as said earlier, we have to wait for the requirements.

--
Petri

From hisham.khartabil@nokia.com  Thu Jun 27 01:45:13 2002
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 BAA12293
	for ; Thu, 27 Jun 2002 01:45:12 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5R5l3W03525
	for ; Thu, 27 Jun 2002 08:47:03 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 27 Jun 2002 08:45:12 +0300
Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 27 Jun 2002 08:45:12 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 27 Jun 2002 08:45:12 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message sessions
Date: Thu, 27 Jun 2002 08:45:11 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20377@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message sessions
Thread-Index: AcIdP7Inwp0yTrb0QXqkQsXEQxySUQAXcaig
To: 
Cc: , , ,
        , ,
        
X-OriginalArrivalTime: 27 Jun 2002 05:45:12.0110 (UTC) FILETIME=[CDE36CE0:01C21D9D]
Content-Length: 1718
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id BAA12293
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: 


> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, June 26, 2002 9:28 PM
> To: Khartabil Hisham (NMP/Helsinki)
> Cc: Niemi Aki (NET/Espoo); hgs@cs.columbia.edu;
> dean.willis@softarmor.com; jon.peterson@neustar.biz;
> simple@mailman.dynamicsoft.com; rsparks@dynamicsoft.com
> Subject: Re: [Simple] Message sessions
> 
> 
> 
> 
> hisham.khartabil@nokia.com wrote:
> > We define 2 new headers, media-type and media-path.
> > 
> > We define media-type to contain message/sip
> > 
> > media-type: message/sip
> > 
> > We define media-path to contain what the hop attribute 
> contains. This
> > works much like path-header except that it's specifying the 
> path of the
> > media and that it reaches the UAs.
> > 
> > These headers are of course reflected in the response so 
> that both UAs
> > learn the media path.
> > 
> > Of course, we can just define one header called 
> sip-message-media-path
> > (or something similar), that this limits extensibility.
> > 
> > I haven't thought about this thoroughly, so flame me.
> 
> In what way does this differ from:
> 
> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-se
> ssion-policy-00.txt

Sorry, I haven't read that one yet. But I scanned it quickly and looked the examples. It is probably not that different.

- Hisham


> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> 

From nsyracus@cnri.reston.va.us  Thu Jun 27 06:41:12 2002
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 GAA13167
	for ; Thu, 27 Jun 2002 06:41:12 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09422;
	Thu, 27 Jun 2002 06:40:28 -0400 (EDT)
Message-Id: <200206271040.GAA09422@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
Date: Thu, 27 Jun 2002 06:40:28 -0400
Content-Length: 2882
Subject: [Simple] I-D ACTION:draft-rosenberg-simple-data-req-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for Manipulation of Data Elements in 
                          SIMPLE Systems
	Author(s)	: J. Rosenberg, M. Isomaki
	Filename	: draft-rosenberg-simple-data-req-00.txt
	Pages		: 14
	Date		: 26-Jun-02
	
In an instant messaging and presence application, it is frequently
necessary for the user to configure a number of pieces of
information. Users will need to manipulate their buddy list, adding
and removing presentities, and manipulate their authorization lists,
which specify the set of users that can subscribe to their presence.
In this document, we provide a set of requirements for such data
manipulations, and provide a framework for viewing them in a common
way.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-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-rosenberg-simple-data-req-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-rosenberg-simple-data-req-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:	<20020626135002.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-rosenberg-simple-data-req-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rosenberg-simple-data-req-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020626135002.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Thu Jun 27 06:41:18 2002
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 GAA13172
	for ; Thu, 27 Jun 2002 06:41:18 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09439;
	Thu, 27 Jun 2002 06:40:34 -0400 (EDT)
Message-Id: <200206271040.GAA09439@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
Date: Thu, 27 Jun 2002 06:40:34 -0400
Content-Length: 3040
Subject: [Simple] I-D ACTION:draft-kiss-simple-presence-wireless-reqs-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for Presence Service based on 3GPP 
                          specifications and wireless environment 
                          characteristics
	Author(s)	: K. Kiss, G. Bajko
	Filename	: draft-kiss-simple-presence-wireless-reqs-00.txt
	Pages		: 10
	Date		: 26-Jun-02
	
This Internet-Draft defines requirements for Presence Service based 
on 3GPP specifications and wireless environment characteristics. The 
requirements presented in this document are proposed to be evaluated 
by the SIMPLE Working Group. The result of this evaluation process 
could help to determine the work expected to be done in IETF and 
identify the work which might be done in other standardization 
bodies, such as 3GPP. Thus, a more precise work-share between 
standardization bodies could be worked out.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kiss-simple-presence-wireless-reqs-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kiss-simple-presence-wireless-reqs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-kiss-simple-presence-wireless-reqs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020626135015.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-kiss-simple-presence-wireless-reqs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-kiss-simple-presence-wireless-reqs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020626135015.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Thu Jun 27 06:41:28 2002
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 GAA13177
	for ; Thu, 27 Jun 2002 06:41:28 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09475;
	Thu, 27 Jun 2002 06:40:44 -0400 (EDT)
Message-Id: <200206271040.GAA09475@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
Date: Thu, 27 Jun 2002 06:40:44 -0400
Content-Length: 3058
Subject: [Simple] I-D ACTION:draft-olson-simple-publish-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIMPLE Presence Publication Mechanism
	Author(s)	: B. Campbell
	Filename	: draft-olson-simple-publish-00.txt
	Pages		: 21
	Date		: 26-Jun-02
	
This document describes an extension to the Session Initiation
Protocol (SIP) [1].  The purpose of this extension is to create a
means for publishing event state (notably presence information) as
part of the SIMPLE [4] framework for presence and instant messaging.
The method described in this document allows presence information to
be published to a presence agent on behalf of a user.  This method
can be extended to support publication of other event state, but it
is not intended to be a general-purpose mechanism for transport of
arbitrary data as there are better suited mechanisms for this purpose
(ftp, http, etc.) This method is intended to be a simple, light-
weight mechanism that employs SIP in order to support SIMPLE
services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-olson-simple-publish-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-olson-simple-publish-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-olson-simple-publish-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:	<20020626135036.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-olson-simple-publish-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-olson-simple-publish-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020626135036.I-D@ietf.org>

--OtherAccess--

--NextPart--



From vishal@knowsys.net  Thu Jun 27 09:04:32 2002
Received: from nghmail ([63.104.239.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA13738
	for ; Thu, 27 Jun 2002 09:04:32 -0400 (EDT)
Received: (qmail 21885 invoked from network); 27 Jun 2002 14:02:04 -0000
Received: from unknown (HELO MC11VOIP) (61.11.57.68)
  by nghmail with SMTP; 27 Jun 2002 14:02:04 -0000
Message-ID: <00b501c21ddb$3cddb000$5601a8c0@knowsys.net>
From: "vishal" 
To: "Jonathan Rosenberg" 
Cc: 
References: <004a01c21cd9$da2c1c00$5601a8c0@knowsys.net> <3D19D4C0.1080608@dynamicsoft.com>
Subject: Re: [Simple] new I-D on data requirements
Date: Thu, 27 Jun 2002 18:33:54 +0530
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.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Length: 5599
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: 

Hi,
  please find my comments below
regards, vishal

----- Original Message -----
From: Jonathan Rosenberg 
To: vishal 
Cc: 
Sent: Wednesday, June 26, 2002 8:20 PM
Subject: Re: [Simple] new I-D on data requirements


>
>
> vishal wrote:
> > Dr Jonathon,
> >    I think following requirements can also be added to this draft
> > section 2.2
> >
> > 1. Server SHOULD be able to contact other servers in case buddy list
> >    not found in local storage.
>
> Let me make sure I understand. I want to manipulate the list
> sip:myfriends@domain.com. So, I contact the server for example.com. It
> realizes that it doesn't own domain.com, so it forwards the control
> requests to domain.com. Is that what you want?
>
> If so, it sounds like a basic proxy function, as provided by both SIP
> and HTTP as well. If thats what you mean, I am OK with that.

yes , I mean buddy list server(BLS) MUST be able to forward incoming
requests to appropriate BLS .(As i understood BLS is separate component than
proxy so BLS SHOULD also support this feature).

>
> > 2. server should be able to accept requests coming directly from client
> >   or via intermediate entity like proxy (if it includes authetication
> >   info).
>
> Is this not the same as 1.?
>
> > 3. server should be able to route response over same route as request
> > i.e
> >    support for record-route.
>
> Are you talking about the requests to manipulate the buddy list? There
> is no notion of session here - this is a transactional/RPC type of
> protocol. Record-routing makes no sense for transactional mechanisms.
> Thats why you can't record-route OPTIONS in SIP. If you are asking for
> the response to follow the same path as the request, thats part of the
> definition of proxying.
>
    (no comment)
>
> > 4.  MUST have Multicast capability at server i.e UDP support .In case
> > buddy
> > list  shared by many user ,modified by one user then server SHOULD be
> > able
> > to synchronize cache of
> > clients.
>
> I agree with the existence of multiple clients. Thats already captured
> in REQ 12. However, cache synchronization (which is also a requirement)
> is not the same as multicast, and I would personally rather shoot myself
> in the head than try to develop a distributed cache synchronization
> protocol using multicast. Regardless, this document is about
> requirements, not implementation, and I believe the requirement for
> multiple cached copies, each of which can be manipulated, is already
> captured in REQ 11 and REQ 12.
>
>
>
> > 5. Server SHOULD be able to limit maximum number of users sharing buddy
> >    list.
>
> What does it mean to "share" in this context? Share meaning "number of
> simultaneously cached copies?" Share meaning "number of subscriptions to
> the list"?
>
     I mean "number of subscriptions to the list ".

>
> > 6. Server SHOULD be able to specify maximum buddy list nesting(list
> > within
> > list) level.
>
> Since the a list within a list may not be local, there is no way for a
> server to even know what the depth is, since the tree is effectively
> distributed across the servers that own the various lists. From the
> perspective of a server, each list is of depth one - it contains entries
> that are subscribed to, period.
>
  yes I agree... if the list is not local then this info can not be
maintained but
 this is useful info.
>
> >
> > section 2.2 REQ 8: A buddy list should be considered deleted when all
> > the
> > owners of buddy list have deleted it. Deleted buddy list should not be
> > accessible after deletion
>
> You have a different model in mind than is currently specified in the
> document. I think you view there as being a list that is replicated once
> for each "owner" that accesses the list. When an owner modifies their
> replicated instance, that change is copied across all other instances.
> However, when deleted, only their instance is deleted. The list would
> still continue to exist for others.
>
> I don't really see the benefit in this model, as opposed to the current
> model, where there is just one list.

Different instances mean ,server will track number of users sharing this
list and their association with user(s).As soon as somebody deletes list
,his association will be deleted and number of instance will be decremented
.No need to maintain separate copy of list.This list will not "visible" to
the user who deleted .Similarly if new user wants to associate itself then
just
adjust number of instance and association ,no need to create list. (I
apologise for discussing implementation issues here...)

>
>
> >
> > section 4.3 (protocol requirements)
> >
> > 1. Support for conference invitation to multiple users .Command can be
> >    sent to buddy list server with buddy list name .Server MUST resolve
> >    buddy list to buddy(s) and send INVITE message (or route through
> > intermediate entity)
> >    to all online users after checking their status.
>
> This is outside the scope of this document. This document is about
> manipulating the list. As Petri has pointed out, you are asking for a
> mass invitation function, which is covered in his conferencing
> requirements document.
>
> -Jonathan R.
>
>
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
>


From Ya-Ching.Tan@icn.siemens.de  Thu Jun 27 11:01:38 2002
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14118
	for ; Thu, 27 Jun 2002 11:01:37 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA14906;
	Thu, 27 Jun 2002 17:01:19 +0200 (MET DST)
Received: from mchh168e.mch4.siemens.de ([139.21.130.175])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA12142;
	Thu, 27 Jun 2002 17:01:32 +0200 (MET DST)
Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Thu, 27 Jun 2002 17:01:32 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E27@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 
To: "'bcampbell@dynamicsoft.com'" ,
        "'seanol@microsoft.com'" 
Cc: simple@mailman.dynamicsoft.com
Subject: [SIMPLE] PState (Publication-State) Header
Date: Thu, 27 Jun 2002 17:01:17 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1177
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: 

draft-olson-simple-publish-00.txt introduced the PState header. It is stated
that "The response to the PUBLISH MUST contain the Publication-State header
in order to provide the publisher the duration for which the publication is
considered valid. The value of this may be decreased from the expiration
given by the publisher in the original PUBLISH method, but SHOULD NOT be
increased".

I have some questions:

- If the expiration value in the response is mandatory and it depends on the
expiration given by the publisher, shouldn't it be mandatory for the
publisher to give a value in PUBLISH ? The draft only states the "the
PUBLISH may contain an expiration value". Another way is to specify in the
draft a default expiration value in the absence of the Expires header in
PUBLISH.

- Why can't the Expires header be used instead of adding a new header PState
?

- If the event state that is published through the PUBLISH method is
soft-state, where would the expiration timer be running and what happens
when it expires? Does the presence agent send a notification to the watchers
when it happens and if yes, what should the state be changed to ?


Regards,
Ya-Ching






From jdrosen@dynamicsoft.com  Thu Jun 27 11:32:45 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14283
	for ; Thu, 27 Jun 2002 11:32:45 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.122])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5RFWiYH023646;
	Thu, 27 Jun 2002 11:32:45 -0400 (EDT)
Message-ID: <3D1B301B.9020008@dynamicsoft.com>
Date: Thu, 27 Jun 2002 11:32:43 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sean Olson , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] updated buddy list package draft
References: <20020625220559.90169.qmail@web11605.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2278
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: 

Sean responded privately; forwarding my reply to the list for discussion.


Sean Olson wrote:
 > I've only taken a very quick glance at the document.
 > My first impression is that we should support this
 > as a template package -- presence.list or something
 > like that.

I also think thats reasonable.

 > I also think we should use multipart/mixed
 > instead of creating a new conglomerated PIDF format.
 > This ties into the notion of a template package
 > because you can subscribe to a list of entities and
 > get event state for those entities in multiple
 > (MIME) documents. Otherwise we have to invent
 > two flavors for every event document format: one
 > for a single document and one for a compound document.

This is listed as one of the open issues in the doc.

The only problem I had with multipart/mixed is that
the conflomerated PIDF format provides some additional
information. Namely, it provides the partial/full flag
and a version number. The partial/full flag is used
to support partial updates. Without it, if you get a NOTIFY
that lists N things in the list, does that mean that there
are only N things on the list (so that you should delete anything
but those N), or just that only those N are being reported (so that you
don't delete anything but those N)?

The version number, we can live without (we can use cseq instead), but
it works better than cseq. Whenever you see a gap in sequence numbers,
and you have partial notifications, you need to trigger a full-state
update. The spec says that this is done in the immediate NOTIFY caused
by a SUBSCRIBE. Now, if we use cseq, we need to trigger full state
updates on gaps in cseq. Gaps in cseq can happen because of a
re-authentication of the NOTIFY at a proxy, for example. So, even though
there is no gap in the document sequence, there is a gap in the cseq
sequence. The result would be a needless full-state update. Not
catastrophic, just wasteful.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com



From seanol@windows.microsoft.com  Thu Jun 27 11:34:08 2002
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 LAA14302
	for ; Thu, 27 Jun 2002 11:34:08 -0400 (EDT)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 27 Jun 2002 08:34:06 -0700
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Jun 2002 08:34:06 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 27 Jun 2002 08:34:05 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 27 Jun 2002 08:34:05 -0700
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.3590.0);
	 Thu, 27 Jun 2002 08:34:04 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6236.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [SIMPLE] PState (Publication-State) Header
Date: Thu, 27 Jun 2002 08:34:03 -0700
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [SIMPLE] PState (Publication-State) Header
thread-index: AcId64p7OE4t2TAwSraDvIeq3qYDfAAA1dAA
From: "Sean Olson" 
To: "Tan Ya-Ching  ICM N PG U ID A 1" ,
        
Cc: 
X-OriginalArrivalTime: 27 Jun 2002 15:34:04.0997 (UTC) FILETIME=[11EE1F50:01C21DF0]
Content-Length: 2511
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA14302
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: 

Some answers inline below.
Thanks for the quick comments!
/sean

-----Original Message-----
From: Tan Ya-Ching ICM N PG U ID A 1
[mailto:Ya-Ching.Tan@icn.siemens.de] 
Sent: Thursday, June 27, 2002 8:01 AM
To: 'bcampbell@dynamicsoft.com'; Sean Olson
Cc: simple@mailman.dynamicsoft.com
Subject: [SIMPLE] PState (Publication-State) Header



draft-olson-simple-publish-00.txt introduced the PState header. It is
stated that "The response to the PUBLISH MUST contain the
Publication-State header in order to provide the publisher the duration
for which the publication is considered valid. The value of this may be
decreased from the expiration given by the publisher in the original
PUBLISH method, but SHOULD NOT be increased".

I have some questions:

- If the expiration value in the response is mandatory and it depends on
the expiration given by the publisher, shouldn't it be mandatory for the
publisher to give a value in PUBLISH ? The draft only states the "the
PUBLISH may contain an expiration value". Another way is to specify in
the draft a default expiration value in the absence of the Expires
header in PUBLISH.

[Sean] I don't believe it should be mandatory for the publisher. It is
mandatory in the response to make it clear
       that this is soft-state. The publisher, however, may have no
prior notion of how long the publication state
       is valid for -- it may even be indefinite.

- Why can't the Expires header be used instead of adding a new header
PState ?

[Sean] The reasoning is that we should avoid using Expires: in the same
manner as REGISTER. But this is a
       valid question and Jonathan has pointed out that Expires: would
be a more appropriate header as well.
       I'm open to changing this in the -01 version of this draft.

- If the event state that is published through the PUBLISH method is
soft-state, where would the expiration timer be running and what happens
when it expires? Does the presence agent send a notification to the
watchers when it happens and if yes, what should the state be changed to
?

[Sean] The expiration timer would be running in the presence agent in
our model. When the timer expires, the state
       is purged, and a notification should be generated. The state
would be changed to the composite state resulting
       from the removal of this slot (i.e. the compositor should be
involved to determine the new composite state).
       This should be more clearly spelled out and will be included in a
-01 draft.

Regards,
Ya-Ching






From seancolson@yahoo.com  Fri Jun 28 02:11:07 2002
Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA16798
	for ; Fri, 28 Jun 2002 02:11:06 -0400 (EDT)
Received: from 12-235-154-217.client.attbi.com (HELO BOB) (seancolson@12.235.154.217 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Jun 2002 06:11:06 -0000
Reply-To: 
From: "Sean Olson" 
To: "'Jonathan Rosenberg'" ,
        
Subject: RE: [Simple] updated buddy list package draft
Date: Thu, 27 Jun 2002 23:11:15 -0700
Message-ID: <000301c21e6a$9c5aacb0$6601a8c0@BOB>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3D1B301B.9020008@dynamicsoft.com>
Content-Length: 3690
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: 

The version information could be a compelling reason to adopt a
composite PIDF
format. This would be made even more compelling if there was a standard
way to handle versioning information across event packages -- even if
this
was constrained to XML only formats.

To be clear, there are several requirements I think should be
considered:

1) Version information that can be used to differentiate event documents
in a
   temporal fashion (this can be considered independently from partial
vs.
   full state)

2) A method for differentiating full state from partial state (perhaps
implicitly)

3) A means to represent a compound document that is a result of 1 or
more
   individual event documents with a uniform and straightforward
procedure
   for recovering the individual documents

4) A means to send a partial update with a uniform and straightforward
   procedure to construct the updated state based on this partial update
   and a previous full state

/sean


-----Original Message-----
From: simple-admin@mailman.dynamicsoft.com
[mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Jonathan
Rosenberg
Sent: Thursday, June 27, 2002 8:33 AM
To: Sean Olson; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] updated buddy list package draft


Sean responded privately; forwarding my reply to the list for
discussion.


Sean Olson wrote:
 > I've only taken a very quick glance at the document.
 > My first impression is that we should support this
 > as a template package -- presence.list or something
 > like that.

I also think thats reasonable.

 > I also think we should use multipart/mixed
 > instead of creating a new conglomerated PIDF format.
 > This ties into the notion of a template package
 > because you can subscribe to a list of entities and
 > get event state for those entities in multiple
 > (MIME) documents. Otherwise we have to invent
 > two flavors for every event document format: one
 > for a single document and one for a compound document.

This is listed as one of the open issues in the doc.

The only problem I had with multipart/mixed is that
the conflomerated PIDF format provides some additional information.
Namely, it provides the partial/full flag and a version number. The
partial/full flag is used to support partial updates. Without it, if you
get a NOTIFY that lists N things in the list, does that mean that there
are only N things on the list (so that you should delete anything but
those N), or just that only those N are being reported (so that you
don't delete anything but those N)?

The version number, we can live without (we can use cseq instead), but
it works better than cseq. Whenever you see a gap in sequence numbers,
and you have partial notifications, you need to trigger a full-state
update. The spec says that this is done in the immediate NOTIFY caused
by a SUBSCRIBE. Now, if we use cseq, we need to trigger full state
updates on gaps in cseq. Gaps in cseq can happen because of a
re-authentication of the NOTIFY at a proxy, for example. So, even though
there is no gap in the document sequence, there is a gap in the cseq
sequence. The result would be a needless full-state update. Not
catastrophic, just wasteful.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


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


From nsyracus@cnri.reston.va.us  Fri Jun 28 06:37:40 2002
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 GAA17573
	for ; Fri, 28 Jun 2002 06:37:40 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17500;
	Fri, 28 Jun 2002 06:36:53 -0400 (EDT)
Message-Id: <200206281036.GAA17500@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
Date: Fri, 28 Jun 2002 06:36:53 -0400
Content-Length: 2877
Subject: [Simple] I-D ACTION:draft-barnes-simple-imsx-prot-eval-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: IMSX Protocol Evaluation for Session Based IM
	Author(s)	: M. Barnes
	Filename	: draft-barnes-simple-imsx-prot-eval-00.txt
	Pages		: 10
	Date		: 27-Jun-02
	
This document is submitted to the SIMPLE WG as part of the ongoing 
discussion on the selection of the protocol for support of Session 
Based Instant Messaging.  It evaluates the suitability of the IMSX 
protocol as a transport for Session Based IM.  IMSX defines a BEEP 
profile for exchanging CPIM messages after SIP has performed its 
session setup signaling. This document evaluates IMSX against the 
IMPP requirements and its ability to interoperate with other IM 
systems based upon the CPIM profile.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-barnes-simple-imsx-prot-eval-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-barnes-simple-imsx-prot-eval-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-barnes-simple-imsx-prot-eval-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:	<20020627133126.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-barnes-simple-imsx-prot-eval-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-barnes-simple-imsx-prot-eval-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020627133126.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Mon Jul  1 06:40:00 2002
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 GAA04063
	for ; Mon, 1 Jul 2002 06:39:59 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22433;
	Mon, 1 Jul 2002 06:38:52 -0400 (EDT)
Message-Id: <200207011038.GAA22433@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
Date: Mon, 01 Jul 2002 06:38:52 -0400
Content-Length: 2845
Subject: [Simple] I-D ACTION:draft-ietf-simple-presencelist-package-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: A SIP Event Package for List Presence
	Author(s)	: J. Rosenberg, B. Campbell
	Filename	: draft-ietf-simple-presencelist-package-00.txt
	Pages		: 17
	Date		: 28-Jun-02
	
This document presents a SIP event package for subscribing to a list
of presentities. Instead of the subscriber sending a SUBSCRIBE to
each presentity individually, the subscriber can subscribe to their
presence list as a whole, and then receive notifications when the
state of any of the presentities on the list changes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presencelist-package-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-presencelist-package-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-presencelist-package-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:	<20020628142820.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presencelist-package-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presencelist-package-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020628142820.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Mon Jul  1 06:40:00 2002
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 GAA04062
	for ; Mon, 1 Jul 2002 06:39:59 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22480;
	Mon, 1 Jul 2002 06:39:03 -0400 (EDT)
Message-Id: <200207011039.GAA22480@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 01 Jul 2002 06:39:02 -0400
Content-Length: 3309
Subject: [Simple] I-D ACTION:draft-ietf-sip-message-05.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-sip-message-05.txt
	Pages		: 22
	Date		: 28-Jun-02
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-message-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-message-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020628142840.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-message-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-message-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020628142840.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Mon Jul  1 06:40:00 2002
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 GAA04064
	for ; Mon, 1 Jul 2002 06:39:59 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22463;
	Mon, 1 Jul 2002 06:38:58 -0400 (EDT)
Message-Id: <200207011038.GAA22463@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
Date: Mon, 01 Jul 2002 06:38:57 -0400
Content-Length: 2838
Subject: [Simple] I-D ACTION:draft-ietf-simple-cpim-mapping-01.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: CPIM Mapping of SIMPLE Presence and Instant Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-simple-cpim-mapping-01.txt
	Pages		: 13
	Date		: 28-Jun-02
	
The SIMPLE work group has defined a SIP events package for
distribution of presence information. It has also proposed a MESSAGE
extension for the transport of instant messages. This document
describes how those mechanisms map to the abstract CPIM service, in
order to interoperate with other CPIM compliant presence and instant
messaging services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-cpim-mapping-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-cpim-mapping-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-cpim-mapping-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020628142830.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-cpim-mapping-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-cpim-mapping-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020628142830.I-D@ietf.org>

--OtherAccess--

--NextPart--



From Ya-Ching.Tan@icn.siemens.de  Mon Jul  1 09:54:31 2002
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04740
	for ; Mon, 1 Jul 2002 09:54:31 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA14899;
	Mon, 1 Jul 2002 15:54:28 +0200 (MET DST)
Received: from mchh168e.mch4.siemens.de ([139.21.130.175])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA06977;
	Mon, 1 Jul 2002 15:54:29 +0200 (MET DST)
Received: by mchh168e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Mon, 1 Jul 2002 15:54:29 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E35@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 
To: "'Ben Campbell'" 
Cc: "'simple@mailman.dynamicsoft.com'" 
Date: Mon, 1 Jul 2002 15:54:23 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 3252
Subject: [Simple] RE: [SIP] Provisional response for 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: 

Hi,

I refer to the last paragraph of Section 9 of draft-ietf-sip-message-05.txt
:

   It has been suggested that provisional responses should 
   not be allowed for pager-model MESSAGE requests.  
   However, it is not possible to require special treatment for 
   MESSAGE, since many proxy servers will not be aware 
   of the MESSAGE method.  Therefore MESSAGE requests 
   will receive the same provisional response treatment as 
   any other non-INVITE method, as described in the SIP 
   specification.

The paragraph seems to imply that provisional responses are normally
generated for MESSAGE requests, which is not the case, as the SIP
specification states that provisional response SHOULD NOT be issued for a
non-INVITE request. I was actually hoping that the draft would relax the
non-method-specific guideline by allowing the generation of the 100 (Trying)
provisional response for MESSAGE by UAS and stateful proxies. The reason
being that some UAS may not respond with a final respond immediately even
though they SHOULD. For example, if a message relay receives a MESSAGE with
Expires:0, instead of sending a 202 immediately, it may (incorrectly?)
decide to check if the final user is available in order to forward the
message immediately (and even awaits the 200 OK from the final user). This
can result in a lot of retransmissions on hops where the MESSAGE has been
forwarded over UDP, causing unnecessary congestions.

Regards,
Ya-Ching


| -----Original Message-----
| From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
| Sent: 29 May 2002 15:46
| To: Tan Ya-Ching ICM N PG U ID A 1
| Subject: Re: [SIP] Provisional response for MESSAGE
| 
| 
| Thanks! The first part of the paragraph was geared towards 
| 2543 proxies, 
| but I was not explicit about it. Also, a "SHOULD NOT" does not 
| effectively prohibit anything. It means you shouldn't do it 
| unless you 
| have a good, clear reason to do so. In some networks, it _might_ be 
| reasonable to violate the should not if you have a problem 
| with lots of 
| retransmissions.
| 
| I will re-word the paragraph to make it clearer in terms of 3261.
| 
| Thanks!
| 
| Ben.
| 
| Tan Ya-Ching ICM N PG U ID A 1 wrote:
| > Hi,
| > 
| > The last paragraph of draft-ietf-sip-message-04 section 9 
| states that :
| > 
| > "It has been suggested that provisional responses should not be used
| > for pager-model MESSAGE requests.  However, this is not possible, as
| > many proxy servers will not be aware of the MESSAGE method, and will
| > treat MESSAGE requests using the standard non-invite transaction.
| > Additionally, prohibiting provisional responses may in some cases
| > increase the number of retries, and actually make 
| congestion problems
| > worse.  Therefore MESSAGE requests SHOULD receive the same
| > provisional response treatment as any other non-INVITE method, as
| > described in the SIP specification."
| > 
| > But RFC 3261 (8.2.6.1 for UAS, 16.2 for stateful proxy, 
| 16.11 stateless
| > proxy) states that provisional response SHOULD NOT be issued for a
| > non-INVITE request. So this is effectively 'prohibiting provisional
| > responses' and 'may in some cases increase the number of retries'.
| > 
| > 
| > Regards,
| > Ya-Ching
| > 
| > 
| 
| 
| 

From nsyracus@cnri.reston.va.us  Tue Jul  2 06:31:59 2002
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 GAA08139
	for ; Tue, 2 Jul 2002 06:31:59 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01055;
	Tue, 2 Jul 2002 06:31:12 -0400 (EDT)
Message-Id: <200207021031.GAA01055@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
Date: Tue, 02 Jul 2002 06:31:12 -0400
Content-Length: 2896
Subject: [Simple] I-D ACTION:draft-allen-simple-msg-3gpp-01.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: 3GPP work related to SIP based messaging
	Author(s)	: A. Allen
	Filename	: draft-allen-simple-msg-3gpp-01.txt
	Pages		: 7
	Date		: 01-Jul-02
	
The 3rd Generation Partnership Project (3GPP) is using SIP RFC 3261
[1] as the session establishment protocol for the 3GPP IP Multimedia
Core Network Subsystem (IM CN Subsystem, IMS).  3GPP has recently
started working on messaging over the IM CN Subsystem.  It is
intended that this will utilize the IM CN Subsystem for delivery and
may be based on IETF protocols including the work being performed in
the SIMPLE working group.  In this document is provided an outline
and areas of interest of the 3GPP work on IMS messaging for the
information of the SIMPLE working group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-allen-simple-msg-3gpp-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-allen-simple-msg-3gpp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-allen-simple-msg-3gpp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020701152003.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-allen-simple-msg-3gpp-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-allen-simple-msg-3gpp-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020701152003.I-D@ietf.org>

--OtherAccess--

--NextPart--



From pkyzivat@cisco.com  Tue Jul  2 09:25:19 2002
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 JAA08713
	for ; Tue, 2 Jul 2002 09:25:19 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g62DPitf014803;
	Tue, 2 Jul 2002 09:25:44 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAM76438;
	Tue, 2 Jul 2002 09:29:51 -0400 (EDT)
Message-ID: <3D21A9B7.D719EEF4@cisco.com>
Date: Tue, 02 Jul 2002 09:25:11 -0400
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] updated buddy list package draft
References: <3D18E1EF.7050700@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2475
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: 

Jonathan,

Here are some comments about the new spin on this package.

	Paul

- You have the PLS subscribe using the From of its own subscriber. This sounds good, but it limits a significant optimization: If the PLS has many users that subscribe to
the same presence list, and/or if some presentities appear in many lists, the PLS can realize a significant savings by subscribing only once to a particular presentity.
Clearly there are tradeoffs here. Generally I prefer to get things right first and worry about optimizations later. But this may be too big an optimization to forego. 

- One solution to the above may be to use the identity of the owner of the list to subscribe to its elements. The owner then gets to decide who can access the gathered
information. Perhaps we can specify that the definition of a presence list SHOULD (MAY?) specify the expected type of each element.

- It seems ugly to use trial and error to decide whether to subscribe to presencelist or presence. Perhaps the definition of a presence list should be assumed to specify
which is which, with trial and error as a fallback.

- typo: 3.7 still mentions a BLSS.

- typo: 4.1 - reference to watcherinfo seems to be cut/paste error. 

- That same sentence in 4.1, which suggests triggering a full state refresh, ought to be conditional on the received document containing partial state. (If you get one out
of order but with full state, then you don't need to refresh.)

- question: what should a PLS do if a presence list is revised while there are subscriptions outstanding? Presumably it should do a full refresh.

- If a presence list contains references to other presence lists, the resulting presence-list document is flattened - only the top level presence list is named as an
entity. I think it would be better if a  contained a mixture of  and  elements, reflecting the structure of the actual presence
list.

- Somebody objected to the creation of a new document format because it prevents turning this into a package that can be applied to other event types. I have mixed feelings
about the tradeoffs involved, but *if* that is a goal then I have a suggestion. How about defining a document type that does nothing but describe the hierarchical structure
of the list, together with the version, and possibly a version of each element. Then transmit the values of each revised element, or each element, as separate elements in
multipart/mixed.

From pkyzivat@cisco.com  Tue Jul  2 14:32:54 2002
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 OAA09680
	for ; Tue, 2 Jul 2002 14:32:53 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g62IWqlt011355;
	Tue, 2 Jul 2002 14:32:53 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAM79107;
	Tue, 2 Jul 2002 14:36:59 -0400 (EDT)
Message-ID: <3D21F1B3.8F2D72B0@cisco.com>
Date: Tue, 02 Jul 2002 14:32:19 -0400
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: seancolson@yahoo.com
CC: "'Ben Campbell'" ,
        "'Rosen, Brian'" ,
        "'Jonathan Rosenberg'" , bateman@acm.org,
        "'Li Hua Tang'" ,
        "'DAO TRUNG Tin FTRD/DAC/ISS'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: Status discussion again RE: [Simple] Test message
References: <000001c21c12$cb7ab1c0$6601a8c0@BOB>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 4710
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: 

Sorry - I'm way behind in my mail. 

It still seems to me we are talking past one another. Maybe this comes down to differences about the purpose of presence.

My assumption is that the purpose of presence is to convey willingness to participate in interactive communication. An important subcase of this is when the communication
will be realitime communication initiated via sip - perhaps IM, perhaps voice, perhaps something else.

An important aspect of presence in this regard is determining in advance whether successful communication will be possible. I don't want to call you unless there is a
likelihood that you will answer. Similarly, I don't want to call with voice if all you are willing to do is IM.

If I do send you an invite, we negotiate the kind of communication we are willing to do in common using an exchange of SDP. The media types carried in the SDP don't
explicitly say what applications should be used, but they imply it, because if the invitation is successful, the two ends will be exchanging data in those mime types and
doing something with it. There is nothing else in the invitation to say what will be done. This is true whether the mime type is audio/g711, text/html, image/jpeg or
application/wb.

In the case of audio or image, it is pretty clear what sort of application will be required regardless of the subtype. This is also true to a lesser extent for text. For
application, it is pretty much impossible to figure out what kind of application might be needed, or whether it is available.

So, I think it makes pretty good sense to advertise the mimetype/subtype as part of presence. How much of it is presented to a presence subscriber could be a function of
the UI at the subscriber end.

Frankly, I am not at all convinced that mime types are the best way to describe media in sip, but that is water over the dam.

	Paul

Sean Olson wrote:
> 
> What I mean is that while application/wb may give you a clue as to the
> application,
> text/html, image/jpeg, or even message/sip do not. MIME types are not
> usually
> a good indication of the application that will process that media.
> "voice" is interesting, but as a MIME type would more likely be
> represented as
> the less useful audio/g711, etc.
> 
> If what you want to convey is a list of MIME types, that's fine. I just
> don't want to confuse that with a list of applications. (Of course, MIME
> types
> are best represented with a suitable subtype as you mention)
> 
> By mode, I meant a token that succintly defines an application -- like
> "voice" perhaps.
> But I definitely don't want to get into the game of defining a list of
> codecs ... this
> is much better handled by SIP itself than by a presence document format.
> 
> /sean
> 
> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Paul Kyzivat
> Sent: Monday, June 24, 2002 10:23 PM
> To: Sean Olson
> Cc: Ben Campbell; Rosen, Brian; 'Jonathan Rosenberg'; bateman@acm.org;
> 'Li Hua Tang'; 'DAO TRUNG Tin FTRD/DAC/ISS';
> simple@mailman.dynamicsoft.com
> Subject: Re: Status discussion again RE: [Simple] Test message
> 
> Sean Olson wrote:
> >
> > Mode seems to make sense. I like the idea
> > of announcing supported MIME types, BUT I think
> > it is very dangerous to infer applications from
> > MIME types (as you hint at for the
> > application/wb case). I see this leading to a
> > rathole. Could we set the bar at just
> > announcing "modes" for now?
> 
> You have to tell me what you mean by "mode" then.
> 
> I don't think of application/wb as an "application" in any specific
> sense. As far as I am concerned, "application" and "voice" are simply
> different subdivisions of the overall mimetype namespace. But "voice" in
> its own right is much more specific than "application" is. I have a
> reasonable chance of deciding if I can support "voice" without more
> detail. (If I can't support the offered codecs then I can probably find
> a transcoder that can convert to something I do understand.)
> 
> But by itself "application" tells me nothing about what I will be
> expected to do. And in general there are no transcoders that can convert
> between application/wb that I support and application/foo that I don't -
> there is no least common denominator between subtypes of application.
> 
> If the bar is set so low that mime subtypes can never be used, then
> presence will not be at all useful for any media that happen to be
> described by subtypes of application.
> 
>         Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From pkyzivat@cisco.com  Tue Jul  2 19:50:59 2002
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 TAA10620
	for ; Tue, 2 Jul 2002 19:50:59 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g62NpM4i001942;
	Tue, 2 Jul 2002 19:51:23 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAM81013;
	Tue, 2 Jul 2002 19:55:30 -0400 (EDT)
Message-ID: <3D223C5A.5E908CF@cisco.com>
Date: Tue, 02 Jul 2002 19:50:50 -0400
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: Tan Ya-Ching ICM N PG U ID A 1 
CC: "'Ben Campbell'" ,
        "'simple@mailman.dynamicsoft.com'" 
Subject: Re: [Simple] RE: [SIP] Provisional response for MESSAGE
References: <5B4D0C5BA65ECA46969C1419122317E6E74E35@mchh161e>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2222
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: 

I would like to continue this train of thought. I can see cases when a proxy might want to return a 182 Queued response to a message. For instance, a specialized proxy that
selects among alternative destinations for the message based upon presence. If none of the alternatives is Open to accept the message, it may wish to return Queued until it
can pick a destination and deliver the message.

This could be done using a B2BUA that stores the message persistently, returns 202, and then waits to deliver the message. But if it doesn't want to be stateful, the Queud
tactic is interesting, even though it requires another interim status to be returned fairly often.

	Paul

Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
> Hi,
> 
> I refer to the last paragraph of Section 9 of draft-ietf-sip-message-05.txt
> :
> 
>    It has been suggested that provisional responses should
>    not be allowed for pager-model MESSAGE requests.
>    However, it is not possible to require special treatment for
>    MESSAGE, since many proxy servers will not be aware
>    of the MESSAGE method.  Therefore MESSAGE requests
>    will receive the same provisional response treatment as
>    any other non-INVITE method, as described in the SIP
>    specification.
> 
> The paragraph seems to imply that provisional responses are normally
> generated for MESSAGE requests, which is not the case, as the SIP
> specification states that provisional response SHOULD NOT be issued for a
> non-INVITE request. I was actually hoping that the draft would relax the
> non-method-specific guideline by allowing the generation of the 100 (Trying)
> provisional response for MESSAGE by UAS and stateful proxies. The reason
> being that some UAS may not respond with a final respond immediately even
> though they SHOULD. For example, if a message relay receives a MESSAGE with
> Expires:0, instead of sending a 202 immediately, it may (incorrectly?)
> decide to check if the final user is available in order to forward the
> message immediately (and even awaits the 200 OK from the final user). This
> can result in a lot of retransmissions on hops where the MESSAGE has been
> forwarded over UDP, causing unnecessary congestions.
> 
> Regards,
> Ya-Ching

From mikko.lonnfors@nokia.com  Thu Jul  4 06:18:23 2002
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 GAA16226
	for ; Thu, 4 Jul 2002 06:18:21 -0400 (EDT)
From: mikko.lonnfors@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g64AGpd17024
	for ; Thu, 4 Jul 2002 13:16:51 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 4 Jul 2002 13:18:19 +0300
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 4 Jul 2002 13:18:19 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] revised SIMPLE charter - comments?
Date: Thu, 4 Jul 2002 13:18:18 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBB68@esebe004.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] revised SIMPLE charter - comments?
Thread-Index: AcIBb7PgikI5u2D7THmwUQML4+62RwhxgQpA
To: , 
X-OriginalArrivalTime: 04 Jul 2002 10:18:19.0694 (UTC) FILETIME=[1E8A8CE0:01C22344]
Content-Length: 6092
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA16226
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: 

Hi folks,

New charter looks like a step to right direction. 
Some comments inline:


> -----Original Message-----
> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: 22 May, 2002 11:53
> To: 'simple@mailman.dynamicsoft.com'
> Subject: [Simple] revised SIMPLE charter - comments?
> 
> Description of Working Group: 
> 
> This working group focuses on the application of the Session 
> Initiation
> Protocol (SIP, RFC 3261) to the suite of services 
> collectively known as
> instant messaging and presence (IMP). The IETF has committed 
> to producing an
> interoperable standard for these services compliant to the 
> requirements for
> IM
> outlined in RFC 2779 (including the security and privacy 
> requirements there)
> and in the Common Presence and Instant Messaging (CPIM) specification,
> developed
> within the IMPP working group. As the most common services 
> for which SIP is
> used 
> share quite a bit in common with IMP, the adaptation of SIP 
> to IMP seems a 
> natural choice given the widespread support for (and relative 
> maturity of)
> the 
> SIP standard. 
> 
> The primary work of this group will be to generate: 
> 
> 1. A proposed standard SIP extension documenting the 
> transport of Instant
> Messages in SIP, compliant to the requirements for IM 
> outlined in RFC 2779,
> CPIM and in BCP 41 (so that the transport implications of the 
> extension 
> with respect to network congestion are considered in the design). 
> 
> 2. A proposed standard SIP event package and any related protocol 
> mechanisms used to support presence, compliant to the 
> requirements for 
> presence outlined in RFC 2779 and CPIM. 
> 
> 3. An architecture for the implementation of a traditional buddylist-
> based instant messaging and presence application with SIP, 
> including for
> example new mechanisms for message confirmation delivery, 
> indications for
> when 
> a party is in the process of typing a message, secure 
> buddylist manipulation
> 
> operations, and the extension of the CPIM presence format to describe
> typical 
> IM states.
> 
> All SIMPLE proposals fulfilling these goals must document the 
> mappings of 
> their operation to CPIM. Any SIP extensions proposed in the 
> course of this 
> development will, after a last call process, be transferred 
> to the SIP WG 
> for consideration as formal SIP extensions.
> 
> The working group will work within the framework for presence and IM
> described in RFC 2778. The extensions it defines must also be 
> compliant with
> the SIP processes for extensions. The group cannot modify baseline SIP
> behavior or define a new version of SIP for IM and presence. 
> If the group
> determines that any capabilities requiring an extension to 
> SIP are needed,
> the group will seek to define such extensions within the SIP 
> working group, 
> and then use them here. 
> 
> The working group will operate in close cooperation with the 
> IMPP working
> group, which will be completing CPIM in parallel. The working 
> group will
> also cooperate with any other groups defined to standardize 
> other presence
> and IM systems, to ensure maximum sharing of information and avoid
> reinvention of the wheel. The working group will cooperate 
> with the SIP
> working group, soliciting reviews to ensure its extensions meet SIPs
> requirements. The working group will also collaborate with 
> the SIP WG to
> ensure consistent operation of the SUBSCRIBE and NOTIFY methods across
> the other applications being defined for its use. 
> 
> Goals and Milestones:
> Apr 02    Submission of event package for presence to IESG 
> for publication 
> as Proposed Standard
> May 02    Submission of watcher information drafts to IESG 
> for publication 
> as Proposed Standards
> Jun 02    Submission of CPIM mapping draft to IESG for publication as 
> Informational
> Jun 02    Submission of instant messaging session drafts to IESG for 
> publication as Proposed Standards
> Jul 02    Submission of buddylist package set to IESG for 
> publication as 
> Proposed Standards
> Jul 02    Submission of buddylist auth/modify requirements 
> draft to IESG 
> for publication as Informational

There are also some other 'management' requirements for presence service, 
for example presence authorization and presence uploading. Could this work item
be extended to include also those. Also the actual solution spec. seems to be
missing. Could that be added to charter as well?

> Aug 02    Submission of SIMPLE PIDF profile to IESG for 
> publication as 
> Proposed Standard

To my understanding this item is mainly targeted to specify SIMPLE specific 
status values. I was just wondering if the scope of this working item could 
be extended to contain items like support for partial notifications?

> Aug 02    Submission of advanced messaging requirements draft 
> to IESG for 
> publication as Informational

Could the actual solution specification also be added to charter?

> Sep 02    Submission of Presence/IM System Architecture draft 
> to IESG for 
> publication as Informational

This item seems a bit unclear to me. If the purpose of this item 
is to provide information how all different SIMPLE specifications fit 
together then this sounds reasonable but otherwise I don't see much value in this.

Here is a list of missing WG items that in my mind would benefit SIMPLE group:
- Filtering solutions for presence and winfo:
Solution could be either generic or event package specific. There has already 
been some discussions on the SIPPING list about this topic and I would like to ask 
whether this should be handled in SIPPING or in SIMPLE wg?

-Partial notifications: 
Partial notifications means that instead of PS always sending complete presence state
it could only send data that has actually changed. For example winfo already allows this
kind of functionality. I understand that this is not CPIM compliant feature but it is 
still very important (at least for wireless environments) and would be good
if SIMPLE and IMPP WGs could consider adopting this as wg work item.
 	
regards
- Mikko 

From hisham.khartabil@nokia.com  Thu Jul  4 08:57:44 2002
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 IAA16741
	for ; Thu, 4 Jul 2002 08:57:44 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g64CwEi22260
	for ; Thu, 4 Jul 2002 15:58:14 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 4 Jul 2002 15:57:43 +0300
Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 4 Jul 2002 15:57:43 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 4 Jul 2002 15:57:43 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Choosing a mechanism for presence publication.
Date: Thu, 4 Jul 2002 15:57:42 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203B9@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Choosing a mechanism for presence publication.
Thread-Index: AcIYoy06tDhnFwkWTx2futm/PDkRxwKtp8mA
To: , 
Cc: , ,
        , 
X-OriginalArrivalTime: 04 Jul 2002 12:57:43.0225 (UTC) FILETIME=[62D99290:01C2235A]
Content-Length: 8525
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA16741
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: 

My main concern is that if the PUBLISH gets big enough contents, the PUA has to POST the presence info to some HTTP server and send a PUBLISH to the Presence Server with content-indirection. The Presence Serve then has to GET using HTTP. This is like going around in a circle. Why not just use HTTP in the first place and avoid all this.

BIND to the presence server can help you discover where to publish your presence info using HTTP.

Regards,
Hisham

> -----Original Message-----
> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Friday, June 21, 2002 12:29 AM
> To: Simple
> Cc: Ben Campbell; Jonathan Rosenberg; Brian Stucker; Sean Olson; Jon
> Peterson
> Subject: [Simple] Choosing a mechanism for presence publication.
> 
> 
> Several of us have engaged in an offline discussion on how to 
> handle the 
> publication of presence imformation from a PUA to a remote 
> PA. We think 
> we have reached a preliminary conclusion on the mechanism 
> choice. This 
> email reflects (what I believe to be) the consensus of that group so 
> far. The bottom line is, there is significant advantage in 
> using a SIP 
> based mechanism.
> 
> There has been some controversy over the choice of mechanism by which
> SIMPLE presence user agents publish information to remote presence
> agents. The two most favored approaches so far have been the 
> creation of
> a new SIP method for the purpose, and the use of HTTP.
> 
> Nature of Presence Publication:
> 
> We propose a model for presence composition where more than 
> one PUA may
> publish on behalf of a single presentity. Those PUAs may exist in
> separate administrative domains. The publications eventually 
> make it to 
> a logical network element that composes the views of presence sent by 
> the various PUAs into a composite presence document. For the 
> moment, at 
> least, we are calling this logical element a "compositor". This model 
> implies a few assumptions for publication:
> 
> 1) A PUA must be capable of remotely publishing a presence 
> document to a 
> compositor. There is no requirement so far for the PUA to 
> query a PA to 
> determine what document it had published previously. We 
> assume the PUA 
> can subscribe to the final composed document via SIMPLE.
> 
> 2) A presence document can be expressed by a MIME body part.
> 
> 3) The document published by a PUA to a particular input is not
> dependent upon previous publications to that input. The only 
> transaction
> semantic for a given input is "replace". (Note that this does not
> prevent the compositor from applying complex application semantics to
> compose the input, along with all other inputs, into a composite
> presence document.) Any versioning is handled by payload itself.
> 
> 4) The composition semantics belong to the local policy of the
> compositor. The PUA does not need to understand these semantics, and
> cannot expect to make composition policy choices as part of the
> publication action. If a principle needs to make composition policy
> decisions, that is through some other mechanism.
> 
> 5) There may be multiple PUAs publishing on behalf of the same
> presentity. There is no assumption that these PUAs all connect through
> the same network, or even belong to the same administrative 
> or security 
> domain.
> 
> Differences between HTTP and SIP publication:
> 
> HTTP is well suited for moving data around in the form of MIME body
> parts. An HTTP client-to-server publication solution would not require
> much work to specify. A SOAP over HTTP solution would 
> additionally allow
> complex transaction semantics with little additional work.
> 
> HTTP, however, does not have a well-defined routing model at the
> application level. It works fine if the publication point is 
> well known
> and fairly static, but it will require additional work to deal with
> situations where the publication point changes dynamically.
> 
> SIP, on the otherhand, is built around the concept of mobility of
> endpoints. The SIP proxy, registrar, and location service concepts
> provide a rich mechanism of finding a dynamically changing 
> endpoint from
> and address of record.
> 
> SIP, however, does not have an existing method suited for presence
> publication. REGISTER gets us part of the way, but has well-known
> limitations when used for this purpose. SIP is, by nature, 
> also adept at
> moving around MIME payloads, so the creation of such a method is not a
> particularly difficult task.
> 
> Motivation for a SIP based mechanism:
> 
> The application-level routing capabilities of SIP can be very 
> useful for
> presence publication. If all PUAs for a given presentity exist in the
> same administrative domain, then they can most likely publish directly
> to a compositor. But if PUAs exist outside the administrative 
> domain, it
> is likely they will not be able to do so.
> 
> For example, suppose that Alice uses a presence service that allows
> multiple PUAs to publish to a compositor inside the service provider
> network. Further suppose that Alice wishes to incorporate presence
> information from an external provider, that has no business 
> relationship
> with her primary provider. For this example, Alice wishes to use a
> shared browsing service that tracks the "location" she is currently
> browsing in the web. That service acts as a PUA on Alice's behalf, and
> publishes the information to her primary presence provider. 
> Other users
> of the shared browsing service can subscribe to her presence
> information, and determine when they are browsing the same site.
> 
> The presence provider is highly unlikely to allow the external PUA to
> send data directly to the compositor. But if Alice registers a contact
> with a methods parameter value of "PUBLISH", that PUA can 
> send a publish
> request to an edge proxy in the presence providers network, and use
> Alice's address of record as the requestURI. This AoR could be her
> normal SIP URI, or it could be a special AoR for the purposes of
> presence publication. The proxy forwards the request to the 
> compositor,
> without the external PUA having to talk directly to the compositor, or
> even know its IP address.
> 
> Now consider that Alice's primary providor is actually an enterprise.
> That enterprise has different compositors for different 
> departments. The
> external provider has no way of knowing this internal 
> organization, nor
> does it know what department Alice works in. Still, Alice 
> register's her 
> publication contact at an enterprise registrar, the external
> provider sends the publish request to Alice's address of 
> record, and the
> companies internal SIP network handles things from there, eventually
> getting the request to the correct compositor.
> 
> The composition model does not at first appear to require 
> publishing to
> dynamically changing PAs. But a very powerful, but often forgotten,
> aspect of SIMPLE is it allows a PA to exist on an end-user device.
> Indeed, some early implentations of SIMPLE rely on exactly that model.
> It is reasonable to expect the composition model above to 
> co-exist with
> end-user device PAs, where the PA location changes dynamically.
> 
> For example, imagine Alice hosts a PA on her PC, which aquires its IP
> address via DHCP. This address changes relatively frequently, and 
> registers a publish contact with an enterprise registrar. Now,
> imagine she also has a mobile phone which contains a PUA. She 
> wants her
> presence document to show a combined view of her PCs concept of her
> presence and her mobile phone service's concept of her precence. She
> cannot simply tell the mobile service her PC address since it changes
> often. Instead, she tells the service an AoR to publish presence to.
> The mobile service publishes presence state to that AoR, 
> which resolves
> to a SIP proxy or redirect server. Normal SIP proxy or 
> redirect behavior
> is invoked to get the publication to Alice's PC based on her publish 
> contact registration.
> 
> It is our opinion that SIP style routing is very useful for presence
> publication. Without the application level routing 
> capabilities of SIP,
> it would be difficult to build these sort of services. It is more
> appropriate to add a publication mechanism to SIP than to standardize
> SIP-style routing features for HTTP proxies.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jundery@ubiquity.net  Thu Jul  4 11:27:27 2002
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA17241
	for ; Thu, 4 Jul 2002 11:27:26 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 4 Jul 2002 15:27:52 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Choosing a mechanism for presence publication.
Date: Thu, 4 Jul 2002 16:29:16 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE018C23B1@GBNEWP0758M.eu.ubiquity.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Choosing a mechanism for presence publication.
Thread-Index: AcIYoy06tDhnFwkWTx2futm/PDkRxwKtp8mAAAUXBhA=
From: "James Undery" 
To: , ,
        
Content-Length: 975
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA17241
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: 


> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]

> My main concern is that if the PUBLISH gets big enough 
> contents, the PUA has to POST the presence info to some HTTP 
> server and send a PUBLISH to the Presence Server with 
> content-indirection. The Presence Serve then has to GET using 
> HTTP. This is like going around in a circle. Why not just use 
> HTTP in the first place and avoid all this.
> 
> BIND to the presence server can help you discover where to 
> publish your presence info using HTTP.

I sortof agree with Hisham here, how I envisaged this working was The presentity using BIND to provide the "compositor" with the locations of PUAs. Depending on the URL the compositor would then fetch and aggregate the information from the PUAs using a sutable mechanism (e.g. SIP scheme use SUB/NOT, HTTP use GET). The "compositor" itself would just look like a regular PUA to subscribers (i.e. use SUB/NOT).

From sriramp@nortelnetworks.com  Thu Jul  4 15:11:18 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17895
	for ; Thu, 4 Jul 2002 15:11:18 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g64JBV125622
	for ; Thu, 4 Jul 2002 14:11:31 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 4 Jul 2002 14:11:16 -0500
Message-ID: 
From: "Sriram Parameswar" 
To: simple@mailman.dynamicsoft.com
Date: Thu, 4 Jul 2002 14:11:16 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2238E.924F8B90"
Content-Length: 6072
Subject: [Simple] Questions/comments on draft-olson-simple-publish-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: 

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_01C2238E.924F8B90
Content-Type: text/plain;
	charset="iso-8859-1"

Hi:

Overall I liked the document and agree with its purpose. Just have a few
questions and comments:

1. The draft seems to take it for granted that the Compositor/Presence Agent
supports the PUBLISH method. Given that we already have presence deployed -
I would like to see some mechanism to (a) establish that the
compositor/presence agent supports the PUBLISH method (b) a fallback
mechanism in case it doesn't: example back to using REGISTER or other
mechanisms.

2. I understand the motivation to limit PUBLISH to event state publishing.
However since we are taking the trouble to add a whole new method to SIP, I
would like to see you establish some extensibility mechanisms within the
method so it may be extended to publish other things like CPL, etc. I do not
buy the argument in the Abstract that there are better mechanisms to publish
things like CPL.

3. In section 1.1.1 it says "Each PUA publishes a full view of presence from
its perspective--each publication carries full state, and does not depend on
previous states for the particular PUA." Why can't each PUA publish
incremental/differential presence state - after all the compositor should
have the logic to handle this.

4. The whole motivation for slots (and future standardization of slot names)
and the use of the PTYPE header, may be solved if cpim-pidf simply adds the
RFC2778 mandated "Contact Means". I have contacted the pidf authors on this.
Is there any other need for the PTYPE header - the Contact Means tag would
carry the same meaning.

5. PStream tracking - the document reiterates that PUBLISH does not
establish a dialog, as dialogs create state to keep track of. Then the
discussion on REGISTER says "However, this does not guarantee that clients
will follow the rules, and thus, sequencing may be lost as a result". If the
Compositor/PA has to keep track of PStream to keep temporal ordering - how
have we reduced the state that has to be maintained. Also if clients do not
'follow the rules' and uses different Pstream values for PUBLISH, again
sequencing is lost. I am not sure that PStream buys us anything more than
simply requiring clients to PUBLISH using the same Call-ID.

Regards,


Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com

------_=_NextPart_001_01C2238E.924F8B90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Questions/comments on draft-olson-simple-publish-00.txt




Hi:




Overall I liked the document and agree with its =
purpose. Just have a few questions and comments:




1. The draft seems to take it for granted that the =
Compositor/Presence Agent supports the PUBLISH method. Given that we =
already have presence deployed - I would like to see some mechanism to =
(a) establish that the compositor/presence agent supports the PUBLISH =
method (b) a fallback mechanism in case it doesn't: example back to =
using REGISTER or other mechanisms.



2. I understand the motivation to limit PUBLISH to =
event state publishing. However since we are taking the trouble to add =
a whole new method to SIP, I would like to see you establish some =
extensibility mechanisms within the method so it may be extended to =
publish other things like CPL, etc. I do not buy the argument in the =
Abstract that there are better mechanisms to publish things like =
CPL.



3. In section 1.1.1 it says "Each PUA publishes =
a full view of presence from its perspective--each publication carries =
full state, and does not depend on previous states for the particular =
PUA." Why can't each PUA publish incremental/differential presence =
state - after all the compositor should have the logic to handle =
this.



4. The whole motivation for slots (and future =
standardization of slot names) and the use of the PTYPE header, may be =
solved if cpim-pidf simply adds the RFC2778 mandated "Contact =
Means". I have contacted the pidf authors on this. Is there any =
other need for the PTYPE header - the Contact Means tag would carry the =
same meaning.



5. PStream tracking - the document reiterates that =
PUBLISH does not establish a dialog, as dialogs create state to keep =
track of. Then the discussion on REGISTER says "However, this does not =
guarantee that clients will follow the rules, and thus, sequencing may =
be lost as a result". If the Compositor/PA has to keep track of PStream =
to keep temporal ordering - how have we reduced the state that has to =
be maintained. Also if clients do not 'follow the rules' and uses =
different Pstream values for PUBLISH, again sequencing is lost. I am =
not sure that PStream buys us anything more than simply requiring =
clients to PUBLISH using the same Call-ID.



Regards,






Sriram

__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-684-3986

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com





------_=_NextPart_001_01C2238E.924F8B90--

From sriramp@nortelnetworks.com  Thu Jul  4 16:52:44 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18253
	for ; Thu, 4 Jul 2002 16:52:44 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g64Kqv102315;
	Thu, 4 Jul 2002 15:52:57 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 4 Jul 2002 15:52:42 -0500
Message-ID: 
From: "Sriram Parameswar" 
To: "'simple@mailman.dynamicsoft.com'" 
Cc: "'aallen@dynamicsoft.com'" ,
        "'aki.niemi@nokia.com'" 
Date: Thu, 4 Jul 2002 15:52:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2239C.BD72E890"
Content-Length: 2849
Subject: [Simple] Comment: draft-allen-simple-msg-3gpp-01.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: 

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_01C2239C.BD72E890
Content-Type: text/plain;
	charset="iso-8859-1"

Hi:

Minor comment on the draft - I did not see explicit mention of Instant
Messaging sessions. As you are aware - this is one area that is being worked
on in the SIMPLE WG. I think this merits mention as it is explicitly called
out in TR 22.940 in Section 5 "Session based messaging: The sender(s) and
the receiver(s) have to join to a messaging session". The draft does mention
a chat room, however session based IMs need not occur only in the context of
a chat room.

Thanks,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


------_=_NextPart_001_01C2239C.BD72E890
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Comment: draft-allen-simple-msg-3gpp-01.txt




Hi:




Minor comment on the draft - I did not =
see explicit mention of Instant Messaging sessions. As you are aware - =
this is one area that is being worked on in the SIMPLE WG. I think this =
merits mention as it is explicitly called out in TR 22.940 in Section 5 =
"Session based =
messaging: The =
sender(s) and the receiver(s) have to join to a messaging =
session". The draft does mention a =
chat room, however session based IMs need not occur only in the context =
of a chat room.



Thanks,




Sriram




__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: =
972-685-8540

Interactive Multimedia Server (IMS) =
Fax: 972-684-3986

Nortel Networks, Richardson =
USA  Email: =
sriramp@nortelnetworks.com





------_=_NextPart_001_01C2239C.BD72E890--

From jdrosen@dynamicsoft.com  Fri Jul  5 14:38:22 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21777
	for ; Fri, 5 Jul 2002 14:38:21 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g65IcAYH028425;
	Fri, 5 Jul 2002 14:38:11 -0400 (EDT)
Message-ID: <3D25E790.6090104@dynamicsoft.com>
Date: Fri, 05 Jul 2002 14:38:08 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: bcampbell@dynamicsoft.com, simple@mailman.dynamicsoft.com,
        bstucker@nortelnetworks.com, seanol@windows.microsoft.com,
        jon.peterson@neustar.biz
Subject: Re: [Simple] Choosing a mechanism for presence publication.
References: <2038BCC78B1AD641891A0D1AE133DBB7C203B9@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1638
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: 


hisham.khartabil@nokia.com wrote:
> My main concern is that if the PUBLISH gets big enough contents, the PUA
> has to POST the presence info to some HTTP server and send a PUBLISH to
> the Presence Server with content-indirection. The Presence Serve then
> has to GET using HTTP. This is like going around in a circle. Why not
> just use HTTP in the first place and avoid all this.

Well, the indirection is needed only if you don't have e2e congestion 
control. We're working on that.

> 
> BIND to the presence server can help you discover where to publish your
> presence info using HTTP.

The problem is that the server that you need to publish to may not be 
accessible directly by HTTP. COnsider the example in the draft about the 
PA deep within a multi-level enterprise, or the case where the PA is a 
registered PC.

I can understand the desire for HTTP - I've been on both sides of this 
fence! My current leaning is for sip publish because, practically 
speaking, there were a number of cases where http didn't work. I also 
think that the presence publication problem is sufficiently different 
from a number of other "data publication" things we're looking at (see 
http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt), 
where i do believe HTTP/SOAP is better.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From jdrosen@dynamicsoft.com  Fri Jul  5 15:03:39 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21897
	for ; Fri, 5 Jul 2002 15:03:39 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g65J3cYH028438;
	Fri, 5 Jul 2002 15:03:39 -0400 (EDT)
Message-ID: <3D25ED87.1080203@dynamicsoft.com>
Date: Fri, 05 Jul 2002 15:03:35 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mikko.lonnfors@nokia.com
CC: jon.peterson@neustar.biz, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] revised SIMPLE charter - comments?
References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBB68@esebe004.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3161
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: 


mikko.lonnfors@nokia.com wrote:
> Hi folks,
> 
> New charter looks like a step to right direction. 
> Some comments inline:
> 
>>Jul 02    Submission of buddylist auth/modify requirements 
>>draft to IESG 
>>for publication as Informational
> 
> 
> There are also some other 'management' requirements for presence service, 
> for example presence authorization and presence uploading. Could this work item
> be extended to include also those.

Presence uploading is being considered separately; see the publish draft 
just recently submitted. Other general management issues are in scope, 
IMHO. In fact:

http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt

looks at the problem more generally.



> Also the actual solution spec. seems to be
> missing. Could that be added to charter as well?

I think the idea was to get the requirements doc done and then move onto 
the solution do as a result of another recharter.


>>Aug 02    Submission of advanced messaging requirements draft 
>>to IESG for 
>>publication as Informational
> 
> 
> Could the actual solution specification also be added to charter?

Same as above.


> 
> 
>>Sep 02    Submission of Presence/IM System Architecture draft 
>>to IESG for 
>>publication as Informational
> 
> 
> This item seems a bit unclear to me. If the purpose of this item 
> is to provide information how all different SIMPLE specifications fit 
> together then this sounds reasonable but otherwise I don't see much value in this.

Its the "overall architecture" document that shows how all this various 
stuff fits together to build complete systems.

> 
> Here is a list of missing WG items that in my mind would benefit SIMPLE group:


> - Filtering solutions for presence and winfo:
> Solution could be either generic or event package specific. There has already 
> been some discussions on the SIPPING list about this topic and I would like to ask 
> whether this should be handled in SIPPING or in SIMPLE wg?

Good question. It could be either. Its not a SIP extension, in fact. If 
its for sip-events generally, probably sipping is better, but simple has 
more cycles...


> 
> -Partial notifications: 
> Partial notifications means that instead of PS always sending complete presence state
> it could only send data that has actually changed. For example winfo already allows this
> kind of functionality. I understand that this is not CPIM compliant feature but it is 
> still very important (at least for wireless environments) and would be good
> if SIMPLE and IMPP WGs could consider adopting this as wg work item.

The presence list package provides partial notifications, on the level 
of granularity of individual presentity. Do you feel there is really a 
need for partial notifications at a finer granularity? I am not convinced.

Thanks,
Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From jon.peterson@neustar.biz  Fri Jul  5 18:04:58 2002
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22477
	for ; Fri, 5 Jul 2002 18:04:58 -0400 (EDT)
Received: from chiimc01.il.neustar.com (chih650b-eth-s4p2c0.il.neustar.com [209.173.57.65])
	by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g65M4M505578;
	Fri, 5 Jul 2002 17:04:37 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 5 Jul 2002 17:04:07 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA810A02E5@STNTEXCH2>
From: "Peterson, Jon" 
To: "'simple@mailman.dynamicsoft.com'" 
Cc: "'rsparks@dynamicsoft.com'" 
Date: Fri, 5 Jul 2002 17:04:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1014
Subject: [Simple] SIMPLE draft agenda
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: 

Below find the proposed agenda for the SIMPLE WG meeting in Yokohama. Please
let us know if you have any suggestions or corrections. 

Jon Peterson
NeuStar, Inc.

----

SIP for Instant Messaging and Presence Leveraging Extensions WG (simple)
 
Wednesday, July 17 at 0900-1130
===================================
 
Chairs: Robert Sparks (rsparks@dynamicsoft.com)
        Jon Peterson  (jon.peterson@neustar.biz)
 
Agenda:
 
0900 - Agenda Bashing/Charter Review (Chairs)
0910 - MESSAGE update (draft-ietf-sip-message-05)
       CPIM draft update (draft-ietf-simple-cpim-mapping-01)
0920 - Presence List Event Package 
       draft-ietf-simple-presencelist-package-00
0940 - SIMPLE Data Manipulation Requirements
       draft-ietf-rosenberg-simple-data-req-00
1000 - Presence Publication
       draft-olson-simple-publish-00
1025 - 3GPP drafts
       draft-allen-simple-msg-3gpp-01
       draft-kiss-simple-presence-wireless-reqs
1050 - Message sessions
       IMSX analysis (draft-barnes-simple-imsx-prot-eval-00)


From jose@tct.hut.fi  Sat Jul  6 14:23:55 2002
Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25710
	for ; Sat, 6 Jul 2002 14:23:55 -0400 (EDT)
Received: from tele.tct.hut.fi (tele.tct.hut.fi [130.233.154.160])
	by keskus.tct.hut.fi (8.10.0/8.10.0) with ESMTP id g66INjr10971;
	Sat, 6 Jul 2002 21:23:45 +0300 (EET DST)
Date: Sat, 6 Jul 2002 21:23:45 +0300 (EET DST)
From: Costa Requena 
To: 
cc: , ,
        , ,
        , 
Subject: RE: [Simple] Choosing a mechanism for presence publication.
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7C203B9@esebe019.NOE.Nokia.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 9248
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: 

Hi Hisham,

I completely agree!
If PUBLISH suffer from Content Indirection we are going around the same
problem once more. Would it be much cleaner approach to use HTTP as
publishing mechanism?
BR
Jose

 On Thu, 4 Jul 2002 hisham.khartabil@nokia.com
wrote:

> My main concern is that if the PUBLISH gets big enough contents, the PUA has to POST the presence info to some HTTP server and send a PUBLISH to the Presence Server with content-indirection. The Presence Serve then has to GET using HTTP. This is like going around in a circle. Why not just use HTTP in the first place and avoid all this.
>
> BIND to the presence server can help you discover where to publish your presence info using HTTP.
>
> Regards,
> Hisham
>
> > -----Original Message-----
> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> > Sent: Friday, June 21, 2002 12:29 AM
> > To: Simple
> > Cc: Ben Campbell; Jonathan Rosenberg; Brian Stucker; Sean Olson; Jon
> > Peterson
> > Subject: [Simple] Choosing a mechanism for presence publication.
> >
> >
> > Several of us have engaged in an offline discussion on how to
> > handle the
> > publication of presence imformation from a PUA to a remote
> > PA. We think
> > we have reached a preliminary conclusion on the mechanism
> > choice. This
> > email reflects (what I believe to be) the consensus of that group so
> > far. The bottom line is, there is significant advantage in
> > using a SIP
> > based mechanism.
> >
> > There has been some controversy over the choice of mechanism by which
> > SIMPLE presence user agents publish information to remote presence
> > agents. The two most favored approaches so far have been the
> > creation of
> > a new SIP method for the purpose, and the use of HTTP.
> >
> > Nature of Presence Publication:
> >
> > We propose a model for presence composition where more than
> > one PUA may
> > publish on behalf of a single presentity. Those PUAs may exist in
> > separate administrative domains. The publications eventually
> > make it to
> > a logical network element that composes the views of presence sent by
> > the various PUAs into a composite presence document. For the
> > moment, at
> > least, we are calling this logical element a "compositor". This model
> > implies a few assumptions for publication:
> >
> > 1) A PUA must be capable of remotely publishing a presence
> > document to a
> > compositor. There is no requirement so far for the PUA to
> > query a PA to
> > determine what document it had published previously. We
> > assume the PUA
> > can subscribe to the final composed document via SIMPLE.
> >
> > 2) A presence document can be expressed by a MIME body part.
> >
> > 3) The document published by a PUA to a particular input is not
> > dependent upon previous publications to that input. The only
> > transaction
> > semantic for a given input is "replace". (Note that this does not
> > prevent the compositor from applying complex application semantics to
> > compose the input, along with all other inputs, into a composite
> > presence document.) Any versioning is handled by payload itself.
> >
> > 4) The composition semantics belong to the local policy of the
> > compositor. The PUA does not need to understand these semantics, and
> > cannot expect to make composition policy choices as part of the
> > publication action. If a principle needs to make composition policy
> > decisions, that is through some other mechanism.
> >
> > 5) There may be multiple PUAs publishing on behalf of the same
> > presentity. There is no assumption that these PUAs all connect through
> > the same network, or even belong to the same administrative
> > or security
> > domain.
> >
> > Differences between HTTP and SIP publication:
> >
> > HTTP is well suited for moving data around in the form of MIME body
> > parts. An HTTP client-to-server publication solution would not require
> > much work to specify. A SOAP over HTTP solution would
> > additionally allow
> > complex transaction semantics with little additional work.
> >
> > HTTP, however, does not have a well-defined routing model at the
> > application level. It works fine if the publication point is
> > well known
> > and fairly static, but it will require additional work to deal with
> > situations where the publication point changes dynamically.
> >
> > SIP, on the otherhand, is built around the concept of mobility of
> > endpoints. The SIP proxy, registrar, and location service concepts
> > provide a rich mechanism of finding a dynamically changing
> > endpoint from
> > and address of record.
> >
> > SIP, however, does not have an existing method suited for presence
> > publication. REGISTER gets us part of the way, but has well-known
> > limitations when used for this purpose. SIP is, by nature,
> > also adept at
> > moving around MIME payloads, so the creation of such a method is not a
> > particularly difficult task.
> >
> > Motivation for a SIP based mechanism:
> >
> > The application-level routing capabilities of SIP can be very
> > useful for
> > presence publication. If all PUAs for a given presentity exist in the
> > same administrative domain, then they can most likely publish directly
> > to a compositor. But if PUAs exist outside the administrative
> > domain, it
> > is likely they will not be able to do so.
> >
> > For example, suppose that Alice uses a presence service that allows
> > multiple PUAs to publish to a compositor inside the service provider
> > network. Further suppose that Alice wishes to incorporate presence
> > information from an external provider, that has no business
> > relationship
> > with her primary provider. For this example, Alice wishes to use a
> > shared browsing service that tracks the "location" she is currently
> > browsing in the web. That service acts as a PUA on Alice's behalf, and
> > publishes the information to her primary presence provider.
> > Other users
> > of the shared browsing service can subscribe to her presence
> > information, and determine when they are browsing the same site.
> >
> > The presence provider is highly unlikely to allow the external PUA to
> > send data directly to the compositor. But if Alice registers a contact
> > with a methods parameter value of "PUBLISH", that PUA can
> > send a publish
> > request to an edge proxy in the presence providers network, and use
> > Alice's address of record as the requestURI. This AoR could be her
> > normal SIP URI, or it could be a special AoR for the purposes of
> > presence publication. The proxy forwards the request to the
> > compositor,
> > without the external PUA having to talk directly to the compositor, or
> > even know its IP address.
> >
> > Now consider that Alice's primary providor is actually an enterprise.
> > That enterprise has different compositors for different
> > departments. The
> > external provider has no way of knowing this internal
> > organization, nor
> > does it know what department Alice works in. Still, Alice
> > register's her
> > publication contact at an enterprise registrar, the external
> > provider sends the publish request to Alice's address of
> > record, and the
> > companies internal SIP network handles things from there, eventually
> > getting the request to the correct compositor.
> >
> > The composition model does not at first appear to require
> > publishing to
> > dynamically changing PAs. But a very powerful, but often forgotten,
> > aspect of SIMPLE is it allows a PA to exist on an end-user device.
> > Indeed, some early implentations of SIMPLE rely on exactly that model.
> > It is reasonable to expect the composition model above to
> > co-exist with
> > end-user device PAs, where the PA location changes dynamically.
> >
> > For example, imagine Alice hosts a PA on her PC, which aquires its IP
> > address via DHCP. This address changes relatively frequently, and
> > registers a publish contact with an enterprise registrar. Now,
> > imagine she also has a mobile phone which contains a PUA. She
> > wants her
> > presence document to show a combined view of her PCs concept of her
> > presence and her mobile phone service's concept of her precence. She
> > cannot simply tell the mobile service her PC address since it changes
> > often. Instead, she tells the service an AoR to publish presence to.
> > The mobile service publishes presence state to that AoR,
> > which resolves
> > to a SIP proxy or redirect server. Normal SIP proxy or
> > redirect behavior
> > is invoked to get the publication to Alice's PC based on her publish
> > contact registration.
> >
> > It is our opinion that SIP style routing is very useful for presence
> > publication. Without the application level routing
> > capabilities of SIP,
> > it would be difficult to build these sort of services. It is more
> > appropriate to add a publication mechanism to SIP than to standardize
> > SIP-style routing features for HTTP proxies.
> >
> > _______________________________________________
> > 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 jose@tct.hut.fi  Sat Jul  6 14:30:54 2002
Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25777
	for ; Sat, 6 Jul 2002 14:30:54 -0400 (EDT)
Received: from tele.tct.hut.fi (tele.tct.hut.fi [130.233.154.160])
	by keskus.tct.hut.fi (8.10.0/8.10.0) with ESMTP id g66IUpr11170;
	Sat, 6 Jul 2002 21:30:51 +0300 (EET DST)
Date: Sat, 6 Jul 2002 21:30:51 +0300 (EET DST)
From: Costa Requena 
To: Jonathan Rosenberg 
cc: , ,
        , ,
        , 
Subject: Re: [Simple] Choosing a mechanism for presence publication.
In-Reply-To: <3D25E790.6090104@dynamicsoft.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1801
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: 

Hi,

The problem with PUBLISH is e2e congestion control and that's one of the
drawbacks.
Could it be listed what are the scenarios where HTTP cannot be used. I
see that "draft-rosenberg-simple-data-req-00.txt" clearly set the
requirements for data management and presence publishing is one clear
example. Therefore, it would be wise to list pros and cons of using HTTP
versus PUBLISH.
BR
Jose


On Fri, 5 Jul 2002, Jonathan Rosenberg wrote:

>
>
> hisham.khartabil@nokia.com wrote:
> > My main concern is that if the PUBLISH gets big enough contents, the PUA
> > has to POST the presence info to some HTTP server and send a PUBLISH to
> > the Presence Server with content-indirection. The Presence Serve then
> > has to GET using HTTP. This is like going around in a circle. Why not
> > just use HTTP in the first place and avoid all this.
>
> Well, the indirection is needed only if you don't have e2e congestion
> control. We're working on that.
>
> >
> > BIND to the presence server can help you discover where to publish your
> > presence info using HTTP.
>
> The problem is that the server that you need to publish to may not be
> accessible directly by HTTP. COnsider the example in the draft about the
> PA deep within a multi-level enterprise, or the case where the PA is a
> registered PC.
>
> I can understand the desire for HTTP - I've been on both sides of this
> fence! My current leaning is for sip publish because, practically
> speaking, there were a number of cases where http didn't work. I also
> think that the presence publication problem is sufficiently different
> from a number of other "data publication" things we're looking at (see
> http://www.jdrosen.net/papers/draft-rosenberg-simple-data-req-00.txt),
> where i do believe HTTP/SOAP is better.
>
> -Jonathan R.
>
>
>
>


From sriramp@nortelnetworks.com  Sun Jul  7 19:42:04 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00507
	for ; Sun, 7 Jul 2002 19:42:03 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g67Ng8N16891;
	Sun, 7 Jul 2002 18:42:09 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Sun, 7 Jul 2002 18:41:55 -0500
Message-ID: 
From: "Sriram Parameswar" 
To: Jonathan Rosenberg , bcampbell@dynamicsoft.com,
        simple@mailman.dynamicsoft.com
Date: Sun, 7 Jul 2002 18:41:48 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2260F.DC91E8F0"
Content-Length: 3559
Subject: [Simple] Question: draft-ietf-simple-presencelist-package-00.
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: 

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_01C2260F.DC91E8F0
Content-Type: text/plain;
	charset="iso-8859-1"

Jonathan/Ben:

Question on the 'presencelist' draft. 

Section 3.5 NOTIFY bodies :
"The PIDF format only supports information for a single presentity.
Therefore, its usage is limited to notifications that report a change in
state for a single presentity. It is mandated in order to facilitate
operation of the PLS. The PLS can simply pass on any presence documents it
receives from the presentities in a notification, without modification."

Does this mean in a presencelist of A, B and C. If the Notify from B comes
back to the PLS with a PIDF body, it is passed on unmodified? The reason I
ask is that in section 4.2 (Constructing Coherent Presence State)there is
extensive discussion on the use of version and state - which is available
only in PLIDF.

My guess is that the PLS (which sends out individual SUBSCRIBEs) has to
convert from PIDF to PLIDF when receiving individual NOTIFYs spaced out in
time. Section 3.5 may need some changes to clarify this.

Thanks,

Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com

------_=_NextPart_001_01C2260F.DC91E8F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






Question: draft-ietf-simple-presencelist-package-00.




Jonathan/Ben:




Question on the 'presencelist' draft. 




Section 3.5 NOTIFY bodies :

"The PIDF format only supports information for =
a single presentity. Therefore, its usage is limited to notifications =
that report a change in state for a single presentity. It is mandated =
in order to facilitate operation of the PLS. The PLS can simply pass on =
any presence documents it receives from the presentities in a =
notification, without modification."



Does this mean in a presencelist of A, B and C. If =
the Notify from B comes back to the PLS with a PIDF body, it is passed =
on unmodified? The reason I ask is that in section 4.2 (Constructing =
Coherent Presence State)there is extensive discussion on the use of =
version and state - which is available only in PLIDF.



My guess is that the PLS (which sends out individual =
SUBSCRIBEs) has to convert from PIDF to PLIDF when receiving individual =
NOTIFYs spaced out in time. Section 3.5 may need some changes to =
clarify this.



Thanks,




Sriram

__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-684-3986

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com





------_=_NextPart_001_01C2260F.DC91E8F0--

From jdrosen@dynamicsoft.com  Mon Jul  8 02:12:01 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01607
	for ; Mon, 8 Jul 2002 02:12:01 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.12])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g686BvYH028983;
	Mon, 8 Jul 2002 02:11:58 -0400 (EDT)
Message-ID: <3D292D2B.6060607@dynamicsoft.com>
Date: Mon, 08 Jul 2002 02:11:55 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sriram Parameswar 
CC: bcampbell@dynamicsoft.com, simple@mailman.dynamicsoft.com
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1756
Subject: [Simple] Re: Question: draft-ietf-simple-presencelist-package-00.
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: 

inline.

Sriram Parameswar wrote:
> Jonathan/Ben: 
> 
> Question on the 'presencelist' draft. 
> 
> Section 3.5 NOTIFY bodies : 
> "The PIDF format only supports information for a single presentity.
> Therefore, its usage is limited to notifications that report a change in
> state for a single presentity. It is mandated in order to facilitate
> operation of the PLS. The PLS can simply pass on any presence documents
> it receives from the presentities in a notification, without
> modification."
> 
> Does this mean in a presencelist of A, B and C. If the Notify from B
> comes back to the PLS with a PIDF body, it is passed on unmodified? 

The idea was that this should be allowed, yes.

> The
> reason I ask is that in section 4.2 (Constructing Coherent Presence
> State)there is extensive discussion on the use of version and state -
> which is available only in PLIDF.

True. However, the spec also talks about handlign the case of PIDF and 
multipart/mixed, in which case the version is "faked" to be one higher 
than the previous, and the state is assumed to be partial.

> 
> My guess is that the PLS (which sends out individual SUBSCRIBEs) has to
> convert from PIDF to PLIDF when receiving individual NOTIFYs spaced out
> in time. Section 3.5 may need some changes to clarify this.

It was my hope to avoid needless conversions of formats. Amongst other 
things, they will break any e2e signatures.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From hisham.khartabil@nokia.com  Mon Jul  8 08:42:42 2002
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 IAA00903
	for ; Mon, 8 Jul 2002 08:42:41 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g68ChBi14324
	for ; Mon, 8 Jul 2002 15:43:11 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Mon, 8 Jul 2002 15:42:41 +0300
Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 8 Jul 2002 15:42:41 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 8 Jul 2002 15:42:41 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 8 Jul 2002 15:42:40 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203C9@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on PUBLISH
Thread-Index: AcImfPJ/lruOYk7DRBCJMuWKjjwJXQ==
To: 
X-OriginalArrivalTime: 08 Jul 2002 12:42:41.0097 (UTC) FILETIME=[F2CAC390:01C2267C]
Content-Length: 1810
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA00903
Subject: [Simple] Comments on PUBLISH
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: 

1. The concept of Input slots seems a bit vague. Does a slot represent entities that publish presence info of the same type, eg: geographic location? i.e. All devices that publish geographic location information fit into that slot? If so, why is a use device not a GeoLoc entity?

A User device can publish geographic location information as well as the user's availability for voice and IM, for example. How do slots work in that scenario?

Also, how does a Presence Compositor know which publication belongs to which slot?

Perhaps I miss understood this concept completely.


2. Document assumes that all presence publication is achieved using PUBLISH. That is not true. A example, as a matter of fact, is the GeoLoc.

3. PType header: If is described as useful for 2 things:

- the document that is being published is part of a larger composite document. How does PType here help? If PType is defined to be "mobile", how does that tell the compositor that it belongs to a larger composite document? I would have thought the presentity URI would be used for that purpose.

- The document that is being published will be applied to many components of the composed document. Please give me an example of this. I fail to understand how this could be done.

This is something for the PUBLISH body, not a SIP header.

4. PStream header: How does a header that looks like call-id guarantees correct sequencing of messages? Header like Date, and information in the message body seem like a much better way of sequencing.

5. PState Header: why is it defined that way? why not PExpires or just Expires?

6. I don't think its the PA who should decide how long a PUBLISH is valid for. How is that possible? I publish from my PC that's I'm available for IM for one hour, why would a PA override that?

Regards,
Hisham

From bcampbell@dynamicsoft.com  Tue Jul  9 15:00:14 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05885
	for ; Tue, 9 Jul 2002 15:00:13 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g69Ixnr38181;
	Tue, 9 Jul 2002 13:59:50 -0500 (CDT)
Message-ID: <3D2B3309.7050304@dynamicsoft.com>
Date: Tue, 09 Jul 2002 14:01:29 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sriram Parameswar 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Questions/comments on draft-olson-simple-publish-00.txt
References: 
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3633
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: 

Sriram Parameswar wrote:
> Hi:
> 
> Overall I liked the document and agree with its purpose. Just have a few 
> questions and comments:
> 
> 1. The draft seems to take it for granted that the Compositor/Presence 
> Agent supports the PUBLISH method. Given that we already have presence 
> deployed - I would like to see some mechanism to (a) establish that the 
> compositor/presence agent supports the PUBLISH method (b) a fallback 
> mechanism in case it doesn't: example back to using REGISTER or other 
> mechanisms.

The draft is only proposing a mechanism. It does not in anyway assume 
that other mechanisms do not exist. If the compositor supports other SIP 
methods, but not PUBLISH, I would think 504 responses and OPTIONS 
provide a sufficient mechanism to discover this.

If you are asking that we mandate that all compositors support REGISTER 
as a fallback for backwards compatibility, then I do not agree.

> 
> 2. I understand the motivation to limit PUBLISH to event state 
> publishing. However since we are taking the trouble to add a whole new 
> method to SIP, I would like to see you establish some extensibility 
> mechanisms within the method so it may be extended to publish other 
> things like CPL, etc. I do not buy the argument in the Abstract that 
> there are better mechanisms to publish things like CPL.

By limiting the scope, we were not trying to say it was not possible to 
use it for other things. We were trying to say that we did not worry 
about requirements beyond those for event publishing.

> 
> 3. In section 1.1.1 it says "Each PUA publishes a full view of presence 
> from its perspective--each publication carries full state, and does not 
> depend on previous states for the particular PUA." Why can't each PUA 
> publish incremental/differential presence state - after all the 
> compositor should have the logic to handle this.

If you by incremental state, you mean a situation where the compositor 
cannot intepret a publication P(n) without also having received P(0) 
through P(n-1), then that is a much bigger problem than we were 
attempting to solve.

> 
> 4. The whole motivation for slots (and future standardization of slot 
> names) and the use of the PTYPE header, may be solved if cpim-pidf 
> simply adds the RFC2778 mandated "Contact Means". I have contacted the 
> pidf authors on this. Is there any other need for the PTYPE header - the 
> Contact Means tag would carry the same meaning.

We still may need the ptype to deal with situations where the 
compositor/PA might not otherwise interpret the payload. Even if all the 
info we need is in the cpim-pidf payload, other event type payloads may 
not have this information.

> 
> 5. PStream tracking - the document reiterates that PUBLISH does not 
> establish a dialog, as dialogs create state to keep track of. Then the 
> discussion on REGISTER says "However, this does not guarantee that 
> clients will follow the rules, and thus, sequencing may be lost as a 
> result". If the Compositor/PA has to keep track of PStream to keep 
> temporal ordering - how have we reduced the state that has to be 
> maintained. Also if clients do not 'follow the rules' and uses different 
> Pstream values for PUBLISH, again sequencing is lost. I am not sure that 
> PStream buys us anything more than simply requiring clients to PUBLISH 
> using the same Call-ID.
> 
> Regards,
> 
> 
> Sriram
> __________________________________________
> Sriram Parameswar              Phone: 972-685-8540
> Interactive Multimedia Server (IMS) Fax: 972-684-3986
> Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com
> 




From bindignavile.srinivas@nokia.com  Tue Jul  9 17:27:23 2002
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06402
	for ; Tue, 9 Jul 2002 17:27:23 -0400 (EDT)
From: bindignavile.srinivas@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g69LV5j20568
	for ; Tue, 9 Jul 2002 16:31:05 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Tue, 9 Jul 2002 16:27:21 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 9 Jul 2002 16:27:05 -0500
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Tue, 9 Jul 2002 17:27:04 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Query about Group Creation in SIP
Thread-Index: AcInjQCQYZpxd/G6QcqpWjvSd1zcgQAAkTrw
To: 
X-OriginalArrivalTime: 09 Jul 2002 21:27:05.0982 (UTC) FILETIME=[5FBCF1E0:01C2278F]
Content-Length: 329
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA06402
Subject: [Simple] Query about Group Creation in SIP
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: 

> Hi,
> I was interested in finding out if there has been any work done on SIP extensions for group creation in the SIMPLE WG. I have not been able to find any drafts regarding this issue in the other SIP related WGs too!
> 
> B. Srinivas
> Senior Research Engineer
> NRC Boston
> Tel:    (781) 993-3786
> FAX: (781) 993-1907
> 

From jdrosen@dynamicsoft.com  Wed Jul 10 08:40:35 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09017
	for ; Wed, 10 Jul 2002 08:40:35 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.86])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6ACeaYH001931;
	Wed, 10 Jul 2002 08:40:37 -0400 (EDT)
Message-ID: <3D2C2B3F.40509@dynamicsoft.com>
Date: Wed, 10 Jul 2002 08:40:31 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bindignavile.srinivas@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Query about Group Creation in SIP
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1180
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: 

We are chartered to develop requirements for such manipulation, and then 
develop (or more likely, choose amongst existing) a protocol to meet the 
requirements. A stab at such requirements document can be found at:

http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt

-Jonathan R.

bindignavile.srinivas@nokia.com wrote:
>>Hi,
>>I was interested in finding out if there has been any work done on SIP
> 
> extensions for group creation in the SIMPLE WG. I have not been able to
> find any drafts regarding this issue in the other SIP related WGs too!
> 
>>B. Srinivas
>>Senior Research Engineer
>>NRC Boston
>>Tel:    (781) 993-3786
>>FAX: (781) 993-1907
>>
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From lachlan.brazier@siemens.com  Thu Jul 11 03:44:01 2002
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 DAA12115
	for ; Thu, 11 Jul 2002 03:44:00 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id g6B7iS924142
	for ; Thu, 11 Jul 2002 09:44:28 +0200
Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41])
	by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g6B7iRQD019210
	for ; Thu, 11 Jul 2002 09:44:27 +0200 (MET DST)
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id <34N5YYGB>; Thu, 11 Jul 2002 09:44:25 +0200
Message-ID: 
From: Brazier Lachlan 
To: simple@mailman.dynamicsoft.com
Date: Thu, 11 Jul 2002 09:44:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C228AE.C67174E0"
Content-Length: 1842
Subject: [Simple] SIP-specific event notification draft?
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: 

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_01C228AE.C67174E0
Content-Type: text/plain

Hello,

I lost track with all the drafts and RFC's concerning SIP.

I was looking for the

"SIP-specific event notification" draft 

as mentioned in

draft-ietf-simple-presence-07.txt

but  I couldn't find it. Is it a RFC? Which number?

Sorry if I missed an anouncement somewhere.

Lachlan

------_=_NextPart_001_01C228AE.C67174E0
Content-Type: text/html
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTMuMTIiPg0KPFRJVExFPlNJUC1zcGVj
aWZpYyBldmVudCBub3RpZmljYXRpb24gZHJhZnQ/PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0K
DQo8UD48Rk9OVCBTSVpFPTI+SGVsbG8sPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+
SSBsb3N0IHRyYWNrIHdpdGggYWxsIHRoZSBkcmFmdHMgYW5kIFJGQydzIGNvbmNlcm5pbmcgU0lQ
LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkkgd2FzIGxvb2tpbmcgZm9yIHRoZTwv
Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZxdW90O1NJUC1zcGVjaWZpYyBldmVudCBu
b3RpZmljYXRpb24mcXVvdDsgZHJhZnQgPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+
YXMgbWVudGlvbmVkIGluPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ZHJhZnQtaWV0
Zi1zaW1wbGUtcHJlc2VuY2UtMDcudHh0PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+
YnV0Jm5ic3A7IEkgY291bGRuJ3QgZmluZCBpdC4gSXMgaXQgYSBSRkM/IFdoaWNoIG51bWJlcj88
L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Tb3JyeSBpZiBJIG1pc3NlZCBhbiBhbm91
bmNlbWVudCBzb21ld2hlcmUuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+TGFjaGxh
bjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg==

------_=_NextPart_001_01C228AE.C67174E0--

From sriramp@nortelnetworks.com  Thu Jul 11 09:59:18 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13139
	for ; Thu, 11 Jul 2002 09:59:18 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BDxSs05882;
	Thu, 11 Jul 2002 08:59:28 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 11 Jul 2002 08:59:14 -0500
Message-ID: 
From: "Sriram Parameswar" 
To: "'Brazier Lachlan'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] SIP-specific event notification draft?
Date: Thu, 11 Jul 2002 08:59:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C228E3.23605C00"
Content-Length: 2582
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: 

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_01C228E3.23605C00
Content-Type: text/plain;
	charset="iso-8859-1"

RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification

 

Enjoy

 

Sriram

-----Original Message-----
From: Brazier Lachlan [mailto:lachlan.brazier@siemens.com]
Sent: Thursday, July 11, 2002 2:44 AM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] SIP-specific event notification draft?



Hello, 

I lost track with all the drafts and RFC's concerning SIP. 

I was looking for the 

"SIP-specific event notification" draft 

as mentioned in 

draft-ietf-simple-presence-07.txt 

but  I couldn't find it. Is it a RFC? Which number? 

Sorry if I missed an anouncement somewhere. 

Lachlan 


------_=_NextPart_001_01C228E3.23605C00
Content-Type: text/html;
	charset="iso-8859-1"




SIP-specific event notification draft?






RFC 3265 - Session Initiation Protocol (SIP)-Specific Event 
Notification


 


Enjoy


 


Sriram



  
-----Original Message-----
From: Brazier Lachlan 
  [mailto:lachlan.brazier@siemens.com]
Sent: Thursday, July 11, 2002 
  2:44 AM
To: simple@mailman.dynamicsoft.com
Subject: 
  [Simple] SIP-specific event notification draft?


  
Hello, 

  
I lost track with all the drafts and RFC's concerning 
  SIP. 

  
I was looking for the 

  
"SIP-specific event notification" draft 

  
as mentioned in 

  
draft-ietf-simple-presence-07.txt 

  
but  I couldn't find it. Is it a RFC? Which 
  number? 

  
Sorry if I missed an anouncement somewhere. 

  
Lachlan 


------_=_NextPart_001_01C228E3.23605C00--

From peter.paeppinghaus@icn.siemens.de  Fri Jul 12 05:12:48 2002
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16398
	for ; Fri, 12 Jul 2002 05:12:47 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA28531
	for ; Fri, 12 Jul 2002 11:12:30 +0200 (MET DST)
Received: from icn.siemens.de ([139.21.148.41])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA09000
	for ; Fri, 12 Jul 2002 11:12:45 +0200 (MET DST)
Message-ID: <3D2E9D8D.6040509@icn.siemens.de>
Date: Fri, 12 Jul 2002 11:12:45 +0200
From: Peter =?ISO-8859-1?Q?P=E4ppinghaus?= 
Organization: Siemens AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en,de
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 1514
Subject: [Simple] Message session & associated dialog
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: 

Hi,

so far I have not been following the discussions about message sessions, 
so maybe I am cooking up something that was discussed already.

Message sessions are somewhat hybrid in nature: on the one hand they are 
not part of the dialog that initiated the message session, on the other 
hand they are associated with this dialog. I think it would be helpful 
if this association relation is reflected somehow in the MESSAGE 
requests sent in a message session.

draft-rosenberg-simple-message-session-00 is silent about construction 
of Call-ID and From and To header tags in the MESSAGE requests sent 
within a message session.

Following RFC 3261 the MESSAGE requests should receive Call-IDs 
different from the Call-ID of the associated dialog. This is necessary 
in order not to mess up the CSeq numbering.
But it seems reasonable to me that they would share the From and To tag 
values with the From and To tag values of the associated dialog.

If one would introduce a new informational header, say "Assoc-Call-ID" 
carrying the value of the Call-ID of the associated dialog, then it 
would be possible to reconstruct the dialog ID of the associated dialog 
from the MESSAGE requests in the message session. I think this would be 
very useful.

-- 
Dr. Peter Päppinghaus
Siemens AG            | Phone:    +49 89 - 722 40065
ICM N PG U ID A1      | Fax:      +49 89 - 722 58726
Hofmannstr. 51        | Visitors: Building 1702 / Room 530
D - 81359 München     | Email:    peter.paeppinghaus@icn.siemens.de


From jdrosen@dynamicsoft.com  Sat Jul 13 09:22:43 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21022
	for ; Sat, 13 Jul 2002 09:22:43 -0400 (EDT)
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6DDMeYH005420;
	Sat, 13 Jul 2002 09:22:41 -0400 (EDT)
Message-ID: <3D302998.3050004@dynamicsoft.com>
Date: Sat, 13 Jul 2002 09:22:32 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Peter_P=E4ppinghaus?=
 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 2456
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: 

inline.

Peter Päppinghaus wrote:
> Hi,
> 
> so far I have not been following the discussions about message sessions,
> 
> so maybe I am cooking up something that was discussed already.
> 
> Message sessions are somewhat hybrid in nature: on the one hand they are
> 
> not part of the dialog that initiated the message session, on the other 
> hand they are associated with this dialog. I think it would be helpful 
> if this association relation is reflected somehow in the MESSAGE 
> requests sent in a message session.

Well, they are associated just like an RTP stream is associated with the 
dialog that sets it up. In the case of RTP, the association occurs 
through the port numbers handed out in the SDP. For MESSAGE, the idea is 
that its the request URI. So, in an INVITE, the sdp would be like:

c=IN IP4 host.example.com
t=0 0
m=message 54344 SIP
a=user:ahss7aa9

which would result in receiving IMs that look like, in part:

MESSAGE sip:ahss7aa9@host.example.com SIP/2.0

the request URI is used for the demux, as a result.



> 
> draft-rosenberg-simple-message-session-00 is silent about construction 
> of Call-ID and From and To header tags in the MESSAGE requests sent 
> within a message session.

Well, the draft was just a proposal.

I guess the messages would all use the same dialog ID, with increasing 
CSeq within the dialog. Different dialog ID than the INVITE one, of course.


> 
> Following RFC 3261 the MESSAGE requests should receive Call-IDs 
> different from the Call-ID of the associated dialog. This is necessary 
> in order not to mess up the CSeq numbering.

Right.

> But it seems reasonable to me that they would share the From and To tag 
> values with the From and To tag values of the associated dialog.

I don't see any need for that; see above.

> 
> If one would introduce a new informational header, say "Assoc-Call-ID" 
> carrying the value of the Call-ID of the associated dialog, then it 
> would be possible to reconstruct the dialog ID of the associated dialog 
> from the MESSAGE requests in the message session. I think this would be 
> very useful.
> 

Why?

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


From pkyzivat@cisco.com  Mon Jul 15 09:27:17 2002
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 JAA01067
	for ; Mon, 15 Jul 2002 09:27:17 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6FDRgDQ017744;
	Mon, 15 Jul 2002 09:27:42 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN27112;
	Mon, 15 Jul 2002 09:31:49 -0400 (EDT)
Message-ID: <3D32CDAB.51210C4E@cisco.com>
Date: Mon, 15 Jul 2002 09:27:07 -0400
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: Peter =?iso-8859-1?Q?P=E4ppinghaus?= ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1401
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: 

Jonathan Rosenberg wrote:
> 
> > draft-rosenberg-simple-message-session-00 is silent about construction
> > of Call-ID and From and To header tags in the MESSAGE requests sent
> > within a message session.
> 
> Well, the draft was just a proposal.
> 
> I guess the messages would all use the same dialog ID, with increasing
> CSeq within the dialog. Different dialog ID than the INVITE one, of course.

It makes sense that all the messages share a dialog. The question is: what causes this dialog to be established?

There are currently two ways of establishing a dialog:

- the 2xx reply to an INVITE can establish one

- the 2xx reply to a SUBSCRIBE can establish one

In the case we are discussing, MESSAGE requests are the only thing being sent along the path where we want a dialog. But we don't want the response to every MESSAGE request
to establish a dialog. Some possibilities:

- send a medialess INVITE to establish a dialog, and then send the MESSAGEs within that dialog.

- permit the recipient of a MESSAGE to decide contextually whether to establish a dialog. (Would require some rules to prevent doing so when all the flow control
constraints haven't been met.)

Sending another INVITE is straightforward, but seems a bit circuitous and wasteful of round trips. But using the MESSAGE to do this may lead to a blurring of the
distinction between page and session mode messaging.

	Paul

From bcampbell@dynamicsoft.com  Mon Jul 15 20:37:09 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02947
	for ; Mon, 15 Jul 2002 20:37:09 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6G0athZ010017;
	Mon, 15 Jul 2002 19:36:56 -0500 (CDT)
Message-ID: <3D336AA6.6050202@dynamicsoft.com>
Date: Mon, 15 Jul 2002 19:36:54 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Jonathan Rosenberg ,
        =?ISO-8859-1?Q?Peter_?=
 =?ISO-8859-1?Q?P=E4ppinghaus?= ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2027
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: 

Paul Kyzivat wrote:
> Jonathan Rosenberg wrote:
> 
>>>draft-rosenberg-simple-message-session-00 is silent about construction
>>>of Call-ID and From and To header tags in the MESSAGE requests sent
>>>within a message session.
>>
>>Well, the draft was just a proposal.
>>
>>I guess the messages would all use the same dialog ID, with increasing
>>CSeq within the dialog. Different dialog ID than the INVITE one, of course.
> 
> 
> It makes sense that all the messages share a dialog. The question is: what causes this dialog to be established?
> 
> There are currently two ways of establishing a dialog:
> 
> - the 2xx reply to an INVITE can establish one
> 
> - the 2xx reply to a SUBSCRIBE can establish one
> 
> In the case we are discussing, MESSAGE requests are the only thing being sent along the path where we want a dialog. But we don't want the response to every MESSAGE request
> to establish a dialog. Some possibilities:
> 
> - send a medialess INVITE to establish a dialog, and then send the MESSAGEs within that dialog.
> 
> - permit the recipient of a MESSAGE to decide contextually whether to establish a dialog. (Would require some rules to prevent doing so when all the flow control
> constraints haven't been met.)
> 
> Sending another INVITE is straightforward, but seems a bit circuitous and wasteful of round trips. But using the MESSAGE to do this may lead to a blurring of the
> distinction between page and session mode messaging.
> 

That blurring concerns me a lot. A method where a successful request 
sometimes creates a dialog, and sometimes does not, is problematic. In 
particular, letting the recipient select whether a session is created 
may ignore the wishes of the sender.

In particular, I can imagine a client might exist that supports page 
mode, but not session mode. If I send you a MESSAGE request with such a 
client, and you add a contact header to your response with the 
assumption that it will create a dialog, what happens? You think we are 
in a dialog, but I think we are not.


From pkyzivat@cisco.com  Mon Jul 15 21:21:22 2002
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 VAA03133
	for ; Mon, 15 Jul 2002 21:21:22 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6G1Lm72002707;
	Mon, 15 Jul 2002 21:21:48 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN32098;
	Mon, 15 Jul 2002 21:25:55 -0400 (EDT)
Message-ID: <3D33750A.85F8BFD2@cisco.com>
Date: Mon, 15 Jul 2002 21:21:14 -0400
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: Ben Campbell 
CC: Jonathan Rosenberg ,
        "Peter 
	=?iso-8859-1?Q?P=E4ppinghaus?=" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2347
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: 

Ben - I agree with you. But I can't tell if you:

- believe jonathan's proposal already implies 
  use of invite to establish the dialog

- think invite ought to be used

- have some other way in mind to set up the dialog

	Paul

Ben Campbell wrote:
> 
> Paul Kyzivat wrote:
> > Jonathan Rosenberg wrote:
> >
> >>>draft-rosenberg-simple-message-session-00 is silent about construction
> >>>of Call-ID and From and To header tags in the MESSAGE requests sent
> >>>within a message session.
> >>
> >>Well, the draft was just a proposal.
> >>
> >>I guess the messages would all use the same dialog ID, with increasing
> >>CSeq within the dialog. Different dialog ID than the INVITE one, of course.
> >
> >
> > It makes sense that all the messages share a dialog. The question is: what causes this dialog to be established?
> >
> > There are currently two ways of establishing a dialog:
> >
> > - the 2xx reply to an INVITE can establish one
> >
> > - the 2xx reply to a SUBSCRIBE can establish one
> >
> > In the case we are discussing, MESSAGE requests are the only thing being sent along the path where we want a dialog. But we don't want the response to every MESSAGE request
> > to establish a dialog. Some possibilities:
> >
> > - send a medialess INVITE to establish a dialog, and then send the MESSAGEs within that dialog.
> >
> > - permit the recipient of a MESSAGE to decide contextually whether to establish a dialog. (Would require some rules to prevent doing so when all the flow control
> > constraints haven't been met.)
> >
> > Sending another INVITE is straightforward, but seems a bit circuitous and wasteful of round trips. But using the MESSAGE to do this may lead to a blurring of the
> > distinction between page and session mode messaging.
> >
> 
> That blurring concerns me a lot. A method where a successful request
> sometimes creates a dialog, and sometimes does not, is problematic. In
> particular, letting the recipient select whether a session is created
> may ignore the wishes of the sender.
> 
> In particular, I can imagine a client might exist that supports page
> mode, but not session mode. If I send you a MESSAGE request with such a
> client, and you add a contact header to your response with the
> assumption that it will create a dialog, what happens? You think we are
> in a dialog, but I think we are not.

From andrew@terminaltechnologies.com  Mon Jul 15 21:56:25 2002
Received: from nt1 ([207.224.78.58])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id VAA03315
	for ; Mon, 15 Jul 2002 21:56:24 -0400 (EDT)
Received: from  growler (207.224.78.57) by NT1 (MailMax 4. 7. 0. 9) with ESMTP id 39060332 for simple@mailman.dynamicsoft.com; Mon, 15 Jul 2002 21:45:06 -0400 EDT
Reply-To: 
From: "Andrew" 
To: 
Date: Mon, 15 Jul 2002 21:58:31 -0400
Message-ID: <005801c22c6c$49f35890$d402a8c0@hq.tti.us>
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
Importance: Normal
Content-Length: 681
Subject: [Simple] Working message dumps for MS Messenger ...
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: 

Presently trying to get my presence/proxy server running with MS Messenger.
Sort of a pain without any docs from MS but progress is being made.


I've seen the dumps from Columbia and have gone over them with them, but am
still a little confused. Can someone supply some message dumps between two
end users on different machines with a proxy/presence server on yet another
machine?

Specifically I'd love to see:

END USER A --------- SUB TO END USER B------- > Proxy/Presence
END USER A <-------- SUB 200 OK ---------------------- Proxy/Presence
END USER A <--------- NOTIFY ----------------------------- Proxy/Presence

Any help and suggestions would be great.

Thanks,
Andrew



From aki.niemi@nokia.com  Tue Jul 16 00:47:09 2002
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 AAA03824
	for ; Tue, 16 Jul 2002 00:47:09 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6G4lei01185
	for ; Tue, 16 Jul 2002 07:47:40 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 16 Jul 2002 07:47:08 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 16 Jul 2002 07:47:08 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message session & associated dialog
Date: Tue, 16 Jul 2002 07:47:33 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED7A@esebe013.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message session & associated dialog
Thread-Index: AcIsA9wmDgQFIBJYRy+HsoQlHy+nuwAfcS+w
To: , 
Cc: , 
X-OriginalArrivalTime: 16 Jul 2002 04:47:08.0048 (UTC) FILETIME=[D7130100:01C22C83]
Content-Length: 2853
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id AAA03824
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: 

Hi All,

I don't understand why you would need to have a dialog for the one-shot message. I think it has been already explained in both sip-message and message-session why such a thing is not a good idea. However, if something more concrete than the "imaginary" dialog is needed, then MESSAGE as media in an INVITEd session is the way to do it. This is what I thought Jonathan was also referring to in his mail, i.e., what Call-ID is used in MESSAGEs within the session media and so on.

Having MESSAGE set up a dialog (for example) may sound reasonable, but when would such a dialog end? Would I have to remember this dialog indefinitely, just in case someone replies to it?

Using a "dummy" INVITE is also problematic. Not only does it blur the paging mode and the session mode, but also, what happens if the other end rejects? How would a user determine whether to accept or reject a "medialess" INVITE?

Cheers,
Aki 

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, July 15, 2002 4:27 PM
> To: Jonathan Rosenberg
> Cc: Peter Päppinghaus; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Message session & associated dialog
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > > draft-rosenberg-simple-message-session-00 is silent about 
> construction
> > > of Call-ID and From and To header tags in the MESSAGE 
> requests sent
> > > within a message session.
> > 
> > Well, the draft was just a proposal.
> > 
> > I guess the messages would all use the same dialog ID, with 
> increasing
> > CSeq within the dialog. Different dialog ID than the INVITE 
> one, of course.
> 
> It makes sense that all the messages share a dialog. The 
> question is: what causes this dialog to be established?
> 
> There are currently two ways of establishing a dialog:
> 
> - the 2xx reply to an INVITE can establish one
> 
> - the 2xx reply to a SUBSCRIBE can establish one
> 
> In the case we are discussing, MESSAGE requests are the only 
> thing being sent along the path where we want a dialog. But 
> we don't want the response to every MESSAGE request
> to establish a dialog. Some possibilities:
> 
> - send a medialess INVITE to establish a dialog, and then 
> send the MESSAGEs within that dialog.
> 
> - permit the recipient of a MESSAGE to decide contextually 
> whether to establish a dialog. (Would require some rules to 
> prevent doing so when all the flow control
> constraints haven't been met.)
> 
> Sending another INVITE is straightforward, but seems a bit 
> circuitous and wasteful of round trips. But using the MESSAGE 
> to do this may lead to a blurring of the
> distinction between page and session mode messaging.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From bcampbell@dynamicsoft.com  Tue Jul 16 01:58:14 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04072
	for ; Tue, 16 Jul 2002 01:58:13 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6G5vohZ032772;
	Tue, 16 Jul 2002 00:57:51 -0500 (CDT)
Message-ID: <3D33B5D9.8010907@dynamicsoft.com>
Date: Tue, 16 Jul 2002 00:57:45 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Jonathan Rosenberg ,
        =?ISO-8859-1?Q?Peter_?=
 =?ISO-8859-1?Q?P=E4ppinghaus?= ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2509
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: 

Paul Kyzivat wrote:
> Ben - I agree with you. But I can't tell if you:
> 
> - believe jonathan's proposal already implies 
>   use of invite to establish the dialog
> 
> - think invite ought to be used
> 
> - have some other way in mind to set up the dialog
> 
> 	Paul
> 

If by Jonathan's proposal you mean 
draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE.



> Ben Campbell wrote:
> 
>>Paul Kyzivat wrote:
>>
>>>Jonathan Rosenberg wrote:
>>>
>>>
>>>>>draft-rosenberg-simple-message-session-00 is silent about construction
>>>>>of Call-ID and From and To header tags in the MESSAGE requests sent
>>>>>within a message session.
>>>>
>>>>Well, the draft was just a proposal.
>>>>
>>>>I guess the messages would all use the same dialog ID, with increasing
>>>>CSeq within the dialog. Different dialog ID than the INVITE one, of course.
>>>
>>>
>>>It makes sense that all the messages share a dialog. The question is: what causes this dialog to be established?
>>>
>>>There are currently two ways of establishing a dialog:
>>>
>>>- the 2xx reply to an INVITE can establish one
>>>
>>>- the 2xx reply to a SUBSCRIBE can establish one
>>>
>>>In the case we are discussing, MESSAGE requests are the only thing being sent along the path where we want a dialog. But we don't want the response to every MESSAGE request
>>>to establish a dialog. Some possibilities:
>>>
>>>- send a medialess INVITE to establish a dialog, and then send the MESSAGEs within that dialog.
>>>
>>>- permit the recipient of a MESSAGE to decide contextually whether to establish a dialog. (Would require some rules to prevent doing so when all the flow control
>>>constraints haven't been met.)
>>>
>>>Sending another INVITE is straightforward, but seems a bit circuitous and wasteful of round trips. But using the MESSAGE to do this may lead to a blurring of the
>>>distinction between page and session mode messaging.
>>>
>>
>>That blurring concerns me a lot. A method where a successful request
>>sometimes creates a dialog, and sometimes does not, is problematic. In
>>particular, letting the recipient select whether a session is created
>>may ignore the wishes of the sender.
>>
>>In particular, I can imagine a client might exist that supports page
>>mode, but not session mode. If I send you a MESSAGE request with such a
>>client, and you add a contact header to your response with the
>>assumption that it will create a dialog, what happens? You think we are
>>in a dialog, but I think we are not.
> 




From Markus.Isomaki@nokia.com  Tue Jul 16 03:34:43 2002
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 DAA04400
	for ; Tue, 16 Jul 2002 03:34:43 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6G7ZGi00602
	for ; Tue, 16 Jul 2002 10:35:16 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 16 Jul 2002 10:34:40 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 16 Jul 2002 10:34:39 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Questions/comments on draft-olson-simple-publish-00.txt
Date: Tue, 16 Jul 2002 10:34:39 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Questions/comments on draft-olson-simple-publish-00.txt
Thread-Index: AcIne4mSbBl6E1U2TzCtI5xdDFZ4JgFFELHA
To: , 
Cc: 
X-OriginalArrivalTime: 16 Jul 2002 07:34:39.0834 (UTC) FILETIME=[3E67D3A0:01C22C9B]
Content-Length: 5802
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA04400
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: 

Hi,

Ben Campbell wrote:
> > 3. In section 1.1.1 it says "Each PUA publishes a full view 
> of presence 
> > from its perspective--each publication carries full state, 
> and does not 
> > depend on previous states for the particular PUA." Why 
> can't each PUA 
> > publish incremental/differential presence state - after all the 
> > compositor should have the logic to handle this.
> 
> If you by incremental state, you mean a situation where the 
> compositor 
> cannot intepret a publication P(n) without also having received P(0) 
> through P(n-1), then that is a much bigger problem than we were 
> attempting to solve.

I think there should be a way to publish only limited changes to the composite presence state. If a user has a single device from which he publishes the presence state, it does not make sense to allways send the full document/state when some small bit changes. Talking about CPIM, I think it should be possible to publish changes in each tuple separately, without the need to always send all of them. I don't think "diff" type of deltas are needed, but there should be some kind of granularity. (Actually, the same should apply to SUB/NOT too.)

From the PUBLISH draft I understood that the "slot" model and PType header could somehow accomplish this. However, it is assumed that this happens between multiple physical devices. In my opinion a single device should be able to partition the presence state as well, which seems to require multiple PUAs per device?

Markus 

> -----Original Message-----
> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: 09 July, 2002 22:01
> To: Sriram Parameswar
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Questions/comments on
> draft-olson-simple-publish-00.txt
> 
> 
> Sriram Parameswar wrote:
> > Hi:
> > 
> > Overall I liked the document and agree with its purpose. 
> Just have a few 
> > questions and comments:
> > 
> > 1. The draft seems to take it for granted that the 
> Compositor/Presence 
> > Agent supports the PUBLISH method. Given that we already 
> have presence 
> > deployed - I would like to see some mechanism to (a) 
> establish that the 
> > compositor/presence agent supports the PUBLISH method (b) a 
> fallback 
> > mechanism in case it doesn't: example back to using 
> REGISTER or other 
> > mechanisms.
> 
> The draft is only proposing a mechanism. It does not in anyway assume 
> that other mechanisms do not exist. If the compositor 
> supports other SIP 
> methods, but not PUBLISH, I would think 504 responses and OPTIONS 
> provide a sufficient mechanism to discover this.
> 
> If you are asking that we mandate that all compositors 
> support REGISTER 
> as a fallback for backwards compatibility, then I do not agree.
> 
> > 
> > 2. I understand the motivation to limit PUBLISH to event state 
> > publishing. However since we are taking the trouble to add 
> a whole new 
> > method to SIP, I would like to see you establish some extensibility 
> > mechanisms within the method so it may be extended to publish other 
> > things like CPL, etc. I do not buy the argument in the 
> Abstract that 
> > there are better mechanisms to publish things like CPL.
> 
> By limiting the scope, we were not trying to say it was not 
> possible to 
> use it for other things. We were trying to say that we did not worry 
> about requirements beyond those for event publishing.
> 
> > 
> > 3. In section 1.1.1 it says "Each PUA publishes a full view 
> of presence 
> > from its perspective--each publication carries full state, 
> and does not 
> > depend on previous states for the particular PUA." Why 
> can't each PUA 
> > publish incremental/differential presence state - after all the 
> > compositor should have the logic to handle this.
> 
> If you by incremental state, you mean a situation where the 
> compositor 
> cannot intepret a publication P(n) without also having received P(0) 
> through P(n-1), then that is a much bigger problem than we were 
> attempting to solve.
> 
> > 
> > 4. The whole motivation for slots (and future 
> standardization of slot 
> > names) and the use of the PTYPE header, may be solved if cpim-pidf 
> > simply adds the RFC2778 mandated "Contact Means". I have 
> contacted the 
> > pidf authors on this. Is there any other need for the PTYPE 
> header - the 
> > Contact Means tag would carry the same meaning.
> 
> We still may need the ptype to deal with situations where the 
> compositor/PA might not otherwise interpret the payload. Even 
> if all the 
> info we need is in the cpim-pidf payload, other event type 
> payloads may 
> not have this information.
> 
> > 
> > 5. PStream tracking - the document reiterates that PUBLISH does not 
> > establish a dialog, as dialogs create state to keep track 
> of. Then the 
> > discussion on REGISTER says "However, this does not guarantee that 
> > clients will follow the rules, and thus, sequencing may be 
> lost as a 
> > result". If the Compositor/PA has to keep track of PStream to keep 
> > temporal ordering - how have we reduced the state that has to be 
> > maintained. Also if clients do not 'follow the rules' and 
> uses different 
> > Pstream values for PUBLISH, again sequencing is lost. I am 
> not sure that 
> > PStream buys us anything more than simply requiring clients 
> to PUBLISH 
> > using the same Call-ID.
> > 
> > Regards,
> > 
> > 
> > Sriram
> > __________________________________________
> > Sriram Parameswar              Phone: 972-685-8540
> > Interactive Multimedia Server (IMS) Fax: 972-684-3986
> > Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com
> > 
> 
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From bcampbell@dynamicsoft.com  Tue Jul 16 04:01:38 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04541
	for ; Tue, 16 Jul 2002 04:01:37 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6G81ZhZ040653;
	Tue, 16 Jul 2002 03:01:36 -0500 (CDT)
Message-ID: <3D33D2D8.9080508@dynamicsoft.com>
Date: Tue, 16 Jul 2002 03:01:28 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
CC: sriramp@nortelnetworks.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Questions/comments on draft-olson-simple-publish-00.txt
References: 
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1713
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: 

Markus.Isomaki@nokia.com wrote:
> Hi,
> 
> Ben Campbell wrote:
> 
>>>3. In section 1.1.1 it says "Each PUA publishes a full view 
>>
>>of presence 
>>
>>>from its perspective--each publication carries full state, 
>>
>>and does not 
>>
>>>depend on previous states for the particular PUA." Why 
>>
>>can't each PUA 
>>
>>>publish incremental/differential presence state - after all the 
>>>compositor should have the logic to handle this.
>>
>>If you by incremental state, you mean a situation where the 
>>compositor 
>>cannot intepret a publication P(n) without also having received P(0) 
>>through P(n-1), then that is a much bigger problem than we were 
>>attempting to solve.
> 
> 
> I think there should be a way to publish only limited changes to the composite presence state. If a user has a single device from which he publishes the presence state, it does not make sense to allways send the full document/state when some small bit changes. Talking about CPIM, I think it should be possible to publish changes in each tuple separately, without the need to always send all of them. I don't think "diff" type of deltas are needed, but there should be some kind of granularity. (Actually, the same should apply to SUB/NOT too.)
> 
> From the PUBLISH draft I understood that the "slot" model and PType header could somehow accomplish this. However, it is assumed that this happens between multiple physical devices. In my opinion a single device should be able to partition the presence state as well, which seems to require multiple PUAs per device?

The model in the publish draft is entirely a logical model. There is no 
reason at all why a single physical device could not publish to multiple 
slots.



From vkg@lucent.com  Tue Jul 16 08:39:17 2002
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05382
	for ; Tue, 16 Jul 2002 08:39:17 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6GCdGY12629;
	Tue, 16 Jul 2002 08:39:16 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id HAA21248; Tue, 16 Jul 2002 07:39:14 -0500 (CDT)
Message-ID: <3D3413F0.8000804@lucent.com>
Date: Tue, 16 Jul 2002 07:39:12 -0500
From: "Vijay K. Gurbani" 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bcampbell@dynamicsoft.com
CC: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 828
Subject: [Simple] -05 MESSAGE and Expires header
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: 

Ben:

Any reasons why -05 MESSAGE I-D overloads "Expires: 0" to mean
immediate attention.  Maybe we can use "Priority: Urgent" instead; since
the Priority header is defined in 3261 and "may be factored into
decisions about call routing and acceptance".

I think that overloading the Expires header here is confusing; 3261's
use of "Expires: 0" in conjunction with REGISTER means something
entirely different -- that this registration is invalid.  From a
semantic point of view, "Expires: 0" with REGISTER to mean
deregistration appears to make sense; but "Expires: 0" with MESSAGE to
mean immediate delivery appears incongrous.

If it is not too late, maybe you can consider using the Priority header.
I won't be able to make it to simple WG meeting tomorrow, so I just
wanted to bring this to you attention.

Thanks,

- vijay


From Ya-Ching.Tan@icn.siemens.de  Tue Jul 16 08:54:10 2002
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05489
	for ; Tue, 16 Jul 2002 08:54:09 -0400 (EDT)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA27261;
	Tue, 16 Jul 2002 14:54:07 +0200 (MET DST)
Received: from mchh169e.mch4.siemens.de ([139.21.130.176])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA02166;
	Tue, 16 Jul 2002 14:54:08 +0200 (MET DST)
Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Tue, 16 Jul 2002 14:54:09 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 
To: "'Vijay K. Gurbani'" , bcampbell@dynamicsoft.com
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Tue, 16 Jul 2002 14:54:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 264
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: 

Vijay,

It is stated in RFC 3261 section 20.19 Expires that :
"The precise meaning of this (header) is method dependant".

The use of the Expires header in MESSAGE is as it is defined in -05. It has
only one meaning, so there is no overloading.

Regards,
Ya-Ching

From vkg@lucent.com  Tue Jul 16 09:04:34 2002
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05571
	for ; Tue, 16 Jul 2002 09:04:34 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6GD4XY28571;
	Tue, 16 Jul 2002 09:04:33 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id IAA29151; Tue, 16 Jul 2002 08:04:31 -0500 (CDT)
Message-ID: <3D3419CF.4010905@lucent.com>
Date: Tue, 16 Jul 2002 08:04:15 -0500
From: "Vijay K. Gurbani" 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tan Ya-Ching ICM N PG U ID A 1 
CC: bcampbell@dynamicsoft.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 605
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: 

Tan Ya-Ching ICM N PG U ID A 1 wrote:
> Vijay,
> 
> It is stated in RFC 3261 section 20.19 Expires that :
> "The precise meaning of this (header) is method dependant".

Agreed.

> The use of the Expires header in MESSAGE is as it is defined in -05. It has
> only one meaning, so there is no overloading.

That is debatable; good thing about ASCII protocols is that they are
self describing.  Thus, having a "Priority: Urgent" is far more
preferable to overloading "Expires: 0" to mean immediate handling.
"Priority: Urgent" in this case makes it far more easy to figure
out what is going on.

- vijay





From bcampbell@dynamicsoft.com  Tue Jul 16 09:26:17 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05737
	for ; Tue, 16 Jul 2002 09:26:17 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6GDQ8hZ062203;
	Tue, 16 Jul 2002 08:26:09 -0500 (CDT)
Message-ID: <3D341EE8.2050800@dynamicsoft.com>
Date: Tue, 16 Jul 2002 08:26:00 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Vijay K. Gurbani" 
CC: Tan Ya-Ching ICM N PG U ID A 1 ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> <3D3419CF.4010905@lucent.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 839
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: 

Vijay K. Gurbani wrote:
> Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
>> Vijay,
>>
>> It is stated in RFC 3261 section 20.19 Expires that :
>> "The precise meaning of this (header) is method dependant".
> 
> 
> Agreed.
> 
>> The use of the Expires header in MESSAGE is as it is defined in -05. 
>> It has
>> only one meaning, so there is no overloading.
> 
> 
> That is debatable; good thing about ASCII protocols is that they are
> self describing.  Thus, having a "Priority: Urgent" is far more
> preferable to overloading "Expires: 0" to mean immediate handling.
> "Priority: Urgent" in this case makes it far more easy to figure
> out what is going on.
> 
> - vijay
> 
> 
> 
> 

I do not have strong feelings on this one way or another--either 
approach works for me. I will bow to the will of the majority. Anyone 
else have comments?



From pkyzivat@cisco.com  Tue Jul 16 10:18:47 2002
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 KAA05951
	for ; Tue, 16 Jul 2002 10:18:47 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6GEJ9Na014298;
	Tue, 16 Jul 2002 10:19:10 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN34690;
	Tue, 16 Jul 2002 10:23:16 -0400 (EDT)
Message-ID: <3D342B3B.E093356C@cisco.com>
Date: Tue, 16 Jul 2002 10:18:35 -0400
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: Ben Campbell 
CC: Jonathan Rosenberg ,
        "Peter 
	=?iso-8859-1?Q?P=E4ppinghaus?=" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 5316
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: 

below...

Ben Campbell wrote:
> 
> Paul Kyzivat wrote:
> > Ben - I agree with you. But I can't tell if you:
> >
> > - believe jonathan's proposal already implies
> >   use of invite to establish the dialog
> >
> > - think invite ought to be used
> >
> > - have some other way in mind to set up the dialog
> >
> >       Paul
> >
> 
> If by Jonathan's proposal you mean
> draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE.

Yes, that is the one. I guess I wasn't clear about my concern. Here is the call flow from draft-rosenberg-simple-message-session-00:

       Caller               Proxy               Relay              Callee
          |(1) INVITE         |                   |                   |
          |m=54344            |                   |                   |
          |c=1.2.3.4          |                   |                   |
          |------------------>|(2) INVITE         |                   |
          |                   |m=54344            |                   |
          |                   |c=1.2.3.4          |                   |
          |                   |hop=sip:relay      |                   |
          |                   |-------------------------------------->|
          |                   |(3) 200 OK         |                   |
          |                   |m=44345            |                   |
          |                   |c=4.3.2.1          |                   |
          |(4) 200 OK         |<--------------------------------------|
          |m=44345            |                   |                   |
          |c=4.3.2.1          |                   |                   |
          |hop=sip:relay      |                   |                   |
          |<------------------|                   |                   |
          |(5) ACK            |                   |                   |
          |---------------------------------------------------------->|
          |                   |                   |(6) MESSAGE        |
          |                   |                   |ruri=1.2.3.4:54344 |
          |                   |                   |Route=sip:relay    |
          |                   |                   |<------------------|
          |(7) MESSAGE        |                   |                   |
          |ruri=1.2.3.4:54344 |                   |                   |
          |<--------------------------------------|                   |
          |(8) 200 OK         |                   |                   |
          |-------------------------------------->|                   |
          |                   |                   |(9) 200 OK         |
          |                   |                   |------------------>|
          |(10) MESSAGE       |                   |                   |
          |ruri=4.3.2.1:44345 |                   |                   |
          |Route=sip:relay    |                   |                   |
          |-------------------------------------->|                   |
          |                   |                   |(11) MESSAGE       |
          |                   |                   |ruri=4.3.2.1:44345 |
          |                   |                   |------------------>|
          |                   |                   |(12) 200 OK        |
          |                   |                   |<------------------|
          |(13) 200 OK        |                   |                   |
          |<--------------------------------------|                   |
          |(14) BYE           |                   |                   |
          |---------------------------------------------------------->|
          |(15) 200 OK        |                   |                   |
          |<----------------------------------------------------------|

This shows the MESSAGEs that are not part of any dialog. 

Then, earlier in this thread:

Jonathan Rosenberg wrote:
> 
> Peter Päppinghaus wrote:
> > draft-rosenberg-simple-message-session-00 is silent about construction
> > of Call-ID and From and To header tags in the MESSAGE requests sent
> > within a message session.
> 
> Well, the draft was just a proposal.
> 
> I guess the messages would all use the same dialog ID, with increasing
> CSeq within the dialog. Different dialog ID than the INVITE one, of course.

This last sentence is what started this discussion. If the messages are to use the same dialog ID, and it is a different dialog ID than the INVITE, then where does this
other dialog come from?

In the above flow, it would have to be implicit in the first MESSAGE (6), which seems wrong.

Another possibility (but also dubious) would be to generate a new INVITE between (5) and (6), from caller to callee, using the route header that involves the relay. This
would be a media-less invite with the sole purpose of establishing a dialog. Then, the messages could be sent within the context of this dialog.

The simplest answer here is just to say that the messages don't share a dialog.

Or, it could be considered like REGISTER, where register refreshes SHOULD be sent using the same callid yet there is no dialog. Session oriented messages could also be sent
using the same callid without any implication that this is a dialog. (But I don't like this much either.)

	Paul

From peter.paeppinghaus@icn.siemens.de  Tue Jul 16 11:06:39 2002
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06166
	for ; Tue, 16 Jul 2002 11:06:38 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA18337;
	Tue, 16 Jul 2002 17:06:20 +0200 (MET DST)
Received: from icn.siemens.de ([139.21.148.41])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA06924;
	Tue, 16 Jul 2002 17:06:37 +0200 (MET DST)
Message-ID: <3D34367D.4070008@icn.siemens.de>
Date: Tue, 16 Jul 2002 17:06:37 +0200
From: Peter =?ISO-8859-1?Q?P=E4ppinghaus?= 
Organization: Siemens AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en,de
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Ben Campbell ,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> <3D342B3B.E093356C@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 7001
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: 

Comments inline.

Paul Kyzivat wrote:

> below...
> 
> Ben Campbell wrote:
> 
>>Paul Kyzivat wrote:
>>
>>>Ben - I agree with you. But I can't tell if you:
>>>
>>>- believe jonathan's proposal already implies
>>>  use of invite to establish the dialog
>>>
>>>- think invite ought to be used
>>>
>>>- have some other way in mind to set up the dialog
>>>
>>>      Paul
>>>
>>>
>>If by Jonathan's proposal you mean
>>draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE.
>>
> 
> Yes, that is the one. I guess I wasn't clear about my concern. Here is the call flow from draft-rosenberg-simple-message-session-00:
> 
>        Caller               Proxy               Relay              Callee
>           |(1) INVITE         |                   |                   |
>           |m=54344            |                   |                   |
>           |c=1.2.3.4          |                   |                   |
>           |------------------>|(2) INVITE         |                   |
>           |                   |m=54344            |                   |
>           |                   |c=1.2.3.4          |                   |
>           |                   |hop=sip:relay      |                   |
>           |                   |-------------------------------------->|
>           |                   |(3) 200 OK         |                   |
>           |                   |m=44345            |                   |
>           |                   |c=4.3.2.1          |                   |
>           |(4) 200 OK         |<--------------------------------------|
>           |m=44345            |                   |                   |
>           |c=4.3.2.1          |                   |                   |
>           |hop=sip:relay      |                   |                   |
>           |<------------------|                   |                   |
>           |(5) ACK            |                   |                   |
>           |---------------------------------------------------------->|
>           |                   |                   |(6) MESSAGE        |
>           |                   |                   |ruri=1.2.3.4:54344 |
>           |                   |                   |Route=sip:relay    |
>           |                   |                   |<------------------|
>           |(7) MESSAGE        |                   |                   |
>           |ruri=1.2.3.4:54344 |                   |                   |
>           |<--------------------------------------|                   |
>           |(8) 200 OK         |                   |                   |
>           |-------------------------------------->|                   |
>           |                   |                   |(9) 200 OK         |
>           |                   |                   |------------------>|
>           |(10) MESSAGE       |                   |                   |
>           |ruri=4.3.2.1:44345 |                   |                   |
>           |Route=sip:relay    |                   |                   |
>           |-------------------------------------->|                   |
>           |                   |                   |(11) MESSAGE       |
>           |                   |                   |ruri=4.3.2.1:44345 |
>           |                   |                   |------------------>|
>           |                   |                   |(12) 200 OK        |
>           |                   |                   |<------------------|
>           |(13) 200 OK        |                   |                   |
>           |<--------------------------------------|                   |
>           |(14) BYE           |                   |                   |
>           |---------------------------------------------------------->|
>           |(15) 200 OK        |                   |                   |
>           |<----------------------------------------------------------|
> 
> This shows the MESSAGEs that are not part of any dialog. 
> 
> Then, earlier in this thread:
> 
> Jonathan Rosenberg wrote:
> 
>>Peter Päppinghaus wrote:
>>
>>>draft-rosenberg-simple-message-session-00 is silent about construction
>>>of Call-ID and From and To header tags in the MESSAGE requests sent
>>>within a message session.
>>>
>>Well, the draft was just a proposal.
>>
>>I guess the messages would all use the same dialog ID, with increasing
>>CSeq within the dialog. Different dialog ID than the INVITE one, of course.
>>
> 
> This last sentence is what started this discussion. If the messages are to use the same dialog ID, and it is a different dialog ID than the INVITE, then where does this
> other dialog come from?


What starts the topic - in my opinion - is simply the observation that 
the messages within a message session are intended to be threaded 
together, and this should be reflected SOMEHOW.

For example, there should be a means to guarantee correct sequencing. 
Unless one thinks about a completely different approach to this - like 
e.g. the one in draft-olson-simple-publish-00 - the most natural 
approach seems to be to let the messages of a message session be 
threaded together by sharing their From tag, To tag and Call-ID values, 
und use CSeq numbering for sequencing.

Since RFC 3261 leaves room for SIP extensions to "define other means for 
creating dialogs", why not stipulate the following: when a response to 
an INVITE creates a message session, it creates at the same time (beyond 
the signaling dialog) a second dialog, namely a media-dialog?

The route of this media-dialog is based on information contained in the 
SDP of the signaling dialog. In the same manner a dialog ID for this 
media-dialog could also be negotiated in the SDP of the signaling 
dialog. Termination of the signaling dialog should imply termination of 
its associated media-dialog. (As far as I understand, RFC 3261 also 
leaves room for that.)


> In the above flow, it would have to be implicit in the first MESSAGE (6), which seems wrong.
> 
> Another possibility (but also dubious) would be to generate a new INVITE between (5) and (6), from caller to callee, using the route header that involves the relay. This
> would be a media-less invite with the sole purpose of establishing a dialog. Then, the messages could be sent within the context of this dialog.
> 
> The simplest answer here is just to say that the messages don't share a dialog.
> 
> Or, it could be considered like REGISTER, where register refreshes SHOULD be sent using the same callid yet there is no dialog. Session oriented messages could also be sent
> using the same callid without any implication that this is a dialog. (But I don't like this much either.)
> 
> 	Paul


-- 
Dr. Peter Päppinghaus
Siemens AG            | Phone:    +49 89 - 722 40065
ICM N PG U ID A1      | Fax:      +49 89 - 722 58726
Hofmannstr. 51        | Visitors: Building 1702 / Room 530
D - 81359 München     | Email:    peter.paeppinghaus@icn.siemens.de


From sriramp@nortelnetworks.com  Tue Jul 16 11:32:48 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06336
	for ; Tue, 16 Jul 2002 11:32:48 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6GFWqi11944;
	Tue, 16 Jul 2002 10:32:52 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 16 Jul 2002 10:32:38 -0500
Message-ID: 
From: "Sriram Parameswar" 
To: "'Ben Campbell'" ,
        "Vijay K. Gurbani"
	 
Cc: Tan Ya-Ching ICM N PG U ID A 1 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Tue, 16 Jul 2002 10:32:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C22CDD.FE55DDF0"
Content-Length: 6430
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: 

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_01C22CDD.FE55DDF0
Content-Type: text/plain;
	charset="iso-8859-1"

Personally I would not like to use Priority and leave the Expires semantic
as is. 

As justification take this example: if you have several IM sessions in
progress, and the window which logs your session with your significant-other
is buried below a ton of other windows. When a message arrives with a
Priority "Urgent" - 'House on Fire' the application (please note - I said
application nothing to do with protocol) could decide to pop the window to
the top. This would not be possible if we overload Priority.

Regards,

Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
Sent: Tuesday, July 16, 2002 8:26 AM
To: Vijay K. Gurbani
Cc: Tan Ya-Ching ICM N PG U ID A 1; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header


Vijay K. Gurbani wrote:
> Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
>> Vijay,
>>
>> It is stated in RFC 3261 section 20.19 Expires that :
>> "The precise meaning of this (header) is method dependant".
> 
> 
> Agreed.
> 
>> The use of the Expires header in MESSAGE is as it is defined in -05. 
>> It has
>> only one meaning, so there is no overloading.
> 
> 
> That is debatable; good thing about ASCII protocols is that they are
> self describing.  Thus, having a "Priority: Urgent" is far more
> preferable to overloading "Expires: 0" to mean immediate handling.
> "Priority: Urgent" in this case makes it far more easy to figure
> out what is going on.
> 
> - vijay
> 
> 
> 
> 

I do not have strong feelings on this one way or another--either 
approach works for me. I will bow to the will of the majority. Anyone 
else have comments?


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

------_=_NextPart_001_01C22CDD.FE55DDF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] -05 MESSAGE and Expires header




Personally I would not like to use Priority and leave =
the Expires semantic as is. 




As justification take this example: if you have =
several IM sessions in progress, and the window which logs your session =
with your significant-other is buried below a ton of other windows. =
When a message arrives with a Priority "Urgent" - 'House on =
Fire' the application (please note - I said application nothing to do =
with protocol) could decide to pop the window to the top. This would =
not be possible if we overload Priority.



Regards,




Sriram

__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-684-3986

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com






-----Original Message-----

From: Ben Campbell [mailto:bcampbell@dynamicsoft.c=
om]

Sent: Tuesday, July 16, 2002 8:26 AM

To: Vijay K. Gurbani

Cc: Tan Ya-Ching ICM N PG U ID A 1; =
simple@mailman.dynamicsoft.com

Subject: Re: [Simple] -05 MESSAGE and Expires =
header






Vijay K. Gurbani wrote:

> Tan Ya-Ching ICM N PG U ID A 1 wrote:

> 

>> Vijay,

>>

>> It is stated in RFC 3261 section 20.19 =
Expires that :

>> "The precise meaning of this (header) =
is method dependant".

> 

> 

> Agreed.

> 

>> The use of the Expires header in MESSAGE is =
as it is defined in -05. 

>> It has

>> only one meaning, so there is no =
overloading.

> 

> 

> That is debatable; good thing about ASCII =
protocols is that they are

> self describing.  Thus, having a =
"Priority: Urgent" is far more

> preferable to overloading "Expires: =
0" to mean immediate handling.

> "Priority: Urgent" in this case makes =
it far more easy to figure

> out what is going on.

> 

> - vijay

> 

> 

> 

> 




I do not have strong feelings on this one way or =
another--either 

approach works for me. I will bow to the will of the =
majority. Anyone 

else have comments?






_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple=






------_=_NextPart_001_01C22CDD.FE55DDF0--

From Fred.Oleary@sylantro.com  Tue Jul 16 12:09:55 2002
Received: from mailserver.sylantro.com ([65.200.90.207])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA06568
	for ; Tue, 16 Jul 2002 12:09:54 -0400 (EDT)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7);); Tue, 16 Jul 2002 09:03:28 -0700
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <1Y4A7M06>; Tue, 16 Jul 2002 09:03:28 -0700
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD018F11C8@mailserver.sylantro.com>
From: "Fred O'Leary" 
To: "Ben Campbell" ,
        "Vijay K. Gurbani" 
cc: "Tan Ya-Ching ICM N PG U ID A 1" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Tue, 16 Jul 2002 09:03:23 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 112A9C5A1239878-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Length: 1458
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: 

I vote for the 'priority' header. Mixing headers/semantics is a sure-fire
path the iter-op problems. The urgent message doesn't 'expire immediately'
and "Expires: 0" implies something like that. 
-Fred

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
Sent: Tuesday, July 16, 2002 6:26 AM
To: Vijay K. Gurbani
Cc: Tan Ya-Ching ICM N PG U ID A 1; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header


Vijay K. Gurbani wrote:
> Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
>> Vijay,
>>
>> It is stated in RFC 3261 section 20.19 Expires that :
>> "The precise meaning of this (header) is method dependant".
> 
> 
> Agreed.
> 
>> The use of the Expires header in MESSAGE is as it is defined in -05. 
>> It has
>> only one meaning, so there is no overloading.
> 
> 
> That is debatable; good thing about ASCII protocols is that they are
> self describing.  Thus, having a "Priority: Urgent" is far more
> preferable to overloading "Expires: 0" to mean immediate handling.
> "Priority: Urgent" in this case makes it far more easy to figure
> out what is going on.
> 
> - vijay
> 
> 
> 
> 

I do not have strong feelings on this one way or another--either 
approach works for me. I will bow to the will of the majority. Anyone 
else have comments?


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


From dsardana@seven.com  Tue Jul 16 12:59:03 2002
Received: from rwc-ex0.corp.seven.com ([209.19.68.212])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06844
	for ; Tue, 16 Jul 2002 12:59:02 -0400 (EDT)
Received: from seven.com ([10.0.10.123]) by rwc-ex0.corp.seven.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 16 Jul 2002 10:01:18 -0700
Message-ID: <3D3450A9.D47B0910@seven.com>
Date: Tue, 16 Jul 2002 09:58:17 -0700
From: Bobby Sardana 
Organization: Seven Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Campbell 
CC: "Vijay K. Gurbani" ,
        Tan Ya-Ching ICM N PG U ID A 1 ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> <3D3419CF.4010905@lucent.com> <3D341EE8.2050800@dynamicsoft.com>
Content-Type: multipart/alternative;
 boundary="------------8251D6713A71D2D5B286E601"
X-OriginalArrivalTime: 16 Jul 2002 17:01:18.0320 (UTC) FILETIME=[67151700:01C22CEA]
Content-Length: 3480
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: 

--------------8251D6713A71D2D5B286E601
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'll cast my vote for the Priority header. Expires: 0 somehow implies that
the message needs to be dropped.

regards,

Bobby Sardana.
dsardana@seven.com

Ben Campbell wrote:

> Vijay K. Gurbani wrote:
> > Tan Ya-Ching ICM N PG U ID A 1 wrote:
> >
> >> Vijay,
> >>
> >> It is stated in RFC 3261 section 20.19 Expires that :
> >> "The precise meaning of this (header) is method dependant".
> >
> >
> > Agreed.
> >
> >> The use of the Expires header in MESSAGE is as it is defined in -05.
> >> It has
> >> only one meaning, so there is no overloading.
> >
> >
> > That is debatable; good thing about ASCII protocols is that they are
> > self describing.  Thus, having a "Priority: Urgent" is far more
> > preferable to overloading "Expires: 0" to mean immediate handling.
> > "Priority: Urgent" in this case makes it far more easy to figure
> > out what is going on.
> >
> > - vijay
> >
> >
> >
> >
>
> I do not have strong feelings on this one way or another--either
> approach works for me. I will bow to the will of the majority. Anyone
> else have comments?
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

--
___________________________

Bobby Sardana |  SEVEN
Software Engineer, Engineering
___________________________

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
dsardana@seven.com
www.seven.com



--------------8251D6713A71D2D5B286E601
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



I'll cast my vote for the Priority header. Expires: 0 somehow implies that
the message needs to be dropped.

regards,

Bobby Sardana.

dsardana@seven.com

Ben Campbell wrote:

Vijay K. Gurbani wrote:

> Tan Ya-Ching ICM N PG U ID A 1 wrote:

>

>> Vijay,

>>

>> It is stated in RFC 3261 section 20.19 Expires that :

>> "The precise meaning of this (header) is method dependant".

>

>

> Agreed.

>

>> The use of the Expires header in MESSAGE is as it is defined in
-05.

>> It has

>> only one meaning, so there is no overloading.

>

>

> That is debatable; good thing about ASCII protocols is that they
are

> self describing.  Thus, having a "Priority: Urgent" is far more

> preferable to overloading "Expires: 0" to mean immediate handling.

> "Priority: Urgent" in this case makes it far more easy to figure

> out what is going on.

>

> - vijay

>

>

>

>

I do not have strong feelings on this one way or another--either

approach works for me. I will bow to the will of the majority. Anyone

else have comments?

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple



-- 
___________________________ 

Bobby Sardana |  SEVEN 
Software Engineer, Engineering  
___________________________ 

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
dsardana@seven.com
www.seven.com

 

--------------8251D6713A71D2D5B286E601--


From mhammer@cisco.com  Tue Jul 16 13:39:56 2002
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 NAA07018
	for ; Tue, 16 Jul 2002 13:39:56 -0400 (EDT)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6GHeKr1010786;
	Tue, 16 Jul 2002 13:40:20 -0400 (EDT)
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 AAZ91183;
	Tue, 16 Jul 2002 13:34:49 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020716133802.00b40db8@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 16 Jul 2002 13:39:44 -0400
To: Bobby Sardana 
From: Michael Hammer 
Subject: Re: [Simple] -05 MESSAGE and Expires header
Cc: Ben Campbell ,
        "Vijay K. Gurbani" ,
        Tan Ya-Ching ICM N PG U ID A 1 ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3D3450A9.D47B0910@seven.com>
References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e>
 <3D3419CF.4010905@lucent.com>
 <3D341EE8.2050800@dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 1696
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: 

Is it possible to deliver a message with an indication that it is 
expired/stale?

Mike


At 09:58 AM 7/16/2002 -0700, Bobby Sardana wrote:
>I'll cast my vote for the Priority header. Expires: 0 somehow implies that 
>the message needs to be dropped.
>
>regards,
>
>Bobby Sardana.
>dsardana@seven.com
>
>Ben Campbell wrote:
>>Vijay K. Gurbani wrote:
>> > Tan Ya-Ching ICM N PG U ID A 1 wrote:
>> >
>> >> Vijay,
>> >>
>> >> It is stated in RFC 3261 section 20.19 Expires that :
>> >> "The precise meaning of this (header) is method dependant".
>> >
>> >
>> > Agreed.
>> >
>> >> The use of the Expires header in MESSAGE is as it is defined in -05.
>> >> It has
>> >> only one meaning, so there is no overloading.
>> >
>> >
>> > That is debatable; good thing about ASCII protocols is that they are
>> > self describing.  Thus, having a "Priority: Urgent" is far more
>> > preferable to overloading "Expires: 0" to mean immediate handling.
>> > "Priority: Urgent" in this case makes it far more easy to figure
>> > out what is going on.
>> >
>> > - vijay
>> >
>> >
>> >
>> >
>>
>>I do not have strong feelings on this one way or another--either
>>approach works for me. I will bow to the will of the majority. Anyone
>>else have comments?
>>
>>_______________________________________________
>>simple mailing list
>>simple@mailman.dynamicsoft.com
>>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>--
>___________________________
>
>Bobby Sardana |  SEVEN
>Software Engineer, Engineering
>___________________________
>
>901 Marshall St.
>Redwood City, CA 94063
>650.381.2535 (v)
>650.216.6455 (f)
>dsardana@seven.com
>www.seven.com
>


From dsardana@seven.com  Tue Jul 16 13:44:20 2002
Received: from rwc-ex0.corp.seven.com ([209.19.68.212])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07070
	for ; Tue, 16 Jul 2002 13:44:19 -0400 (EDT)
Received: from seven.com ([10.0.10.123]) by rwc-ex0.corp.seven.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 16 Jul 2002 10:46:35 -0700
Message-ID: <3D345B45.5300EC60@seven.com>
Date: Tue, 16 Jul 2002 10:43:33 -0700
From: Bobby Sardana 
Organization: Seven Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Hammer 
CC: Ben Campbell ,
        "Vijay K. Gurbani" ,
        Tan Ya-Ching ICM N PG U ID A 1 ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e>
	 <3D3419CF.4010905@lucent.com>
	 <3D341EE8.2050800@dynamicsoft.com> <4.3.2.7.2.20020716133802.00b40db8@cia.cisco.com>
Content-Type: multipart/alternative;
 boundary="------------BC3F45C54E0C30CBDE88BE03"
X-OriginalArrivalTime: 16 Jul 2002 17:46:35.0009 (UTC) FILETIME=[BA5AEF10:01C22CF0]
Content-Length: 5457
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: 

--------------BC3F45C54E0C30CBDE88BE03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Expires:0 appears to provide the following semantics:

a. The message needs to be dropped (stale?)
b. The message does not have an explicit expiration (infinite)

Michael Hammer wrote:

> Is it possible to deliver a message with an indication that it is
> expired/stale?

An erroneous implementation might. Why introduce the ambiguity.

regards,

Bobby Sardana.
dsardana@seven.com

>
>
> Mike
>
> At 09:58 AM 7/16/2002 -0700, Bobby Sardana wrote:
> >I'll cast my vote for the Priority header. Expires: 0 somehow implies that
> >the message needs to be dropped.
> >
> >regards,
> >
> >Bobby Sardana.
> >dsardana@seven.com
> >
> >Ben Campbell wrote:
> >>Vijay K. Gurbani wrote:
> >> > Tan Ya-Ching ICM N PG U ID A 1 wrote:
> >> >
> >> >> Vijay,
> >> >>
> >> >> It is stated in RFC 3261 section 20.19 Expires that :
> >> >> "The precise meaning of this (header) is method dependant".
> >> >
> >> >
> >> > Agreed.
> >> >
> >> >> The use of the Expires header in MESSAGE is as it is defined in -05.
> >> >> It has
> >> >> only one meaning, so there is no overloading.
> >> >
> >> >
> >> > That is debatable; good thing about ASCII protocols is that they are
> >> > self describing.  Thus, having a "Priority: Urgent" is far more
> >> > preferable to overloading "Expires: 0" to mean immediate handling.
> >> > "Priority: Urgent" in this case makes it far more easy to figure
> >> > out what is going on.
> >> >
> >> > - vijay
> >> >
> >> >
> >> >
> >> >
> >>
> >>I do not have strong feelings on this one way or another--either
> >>approach works for me. I will bow to the will of the majority. Anyone
> >>else have comments?
> >>
> >>_______________________________________________
> >>simple mailing list
> >>simple@mailman.dynamicsoft.com
> >>http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >
> >--
> >___________________________
> >
> >Bobby Sardana |  SEVEN
> >Software Engineer, Engineering
> >___________________________
> >
> >901 Marshall St.
> >Redwood City, CA 94063
> >650.381.2535 (v)
> >650.216.6455 (f)
> >dsardana@seven.com
> >www.seven.com
> >

--
___________________________

Bobby Sardana |  SEVEN
Software Engineer, Engineering
___________________________

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
dsardana@seven.com
www.seven.com



--------------BC3F45C54E0C30CBDE88BE03
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Expires:0 appears to provide the following semantics:

a. The message needs to be dropped (stale?)

b. The message does not have an explicit expiration (infinite)

Michael Hammer wrote:

Is it possible to deliver a message with an indication
that it is

expired/stale?

An erroneous implementation might. Why introduce the ambiguity.

regards,

Bobby Sardana.

dsardana@seven.com

 

Mike

At 09:58 AM 7/16/2002 -0700, Bobby Sardana wrote:

>I'll cast my vote for the Priority header. Expires: 0 somehow implies
that

>the message needs to be dropped.

>

>regards,

>

>Bobby Sardana.

>dsardana@seven.com

>

>Ben Campbell wrote:

>>Vijay K. Gurbani wrote:

>> > Tan Ya-Ching ICM N PG U ID A 1 wrote:

>> >

>> >> Vijay,

>> >>

>> >> It is stated in RFC 3261 section 20.19 Expires that :

>> >> "The precise meaning of this (header) is method dependant".

>> >

>> >

>> > Agreed.

>> >

>> >> The use of the Expires header in MESSAGE is as it is defined
in -05.

>> >> It has

>> >> only one meaning, so there is no overloading.

>> >

>> >

>> > That is debatable; good thing about ASCII protocols is that they
are

>> > self describing.  Thus, having a "Priority: Urgent" is far
more

>> > preferable to overloading "Expires: 0" to mean immediate handling.

>> > "Priority: Urgent" in this case makes it far more easy to figure

>> > out what is going on.

>> >

>> > - vijay

>> >

>> >

>> >

>> >

>>

>>I do not have strong feelings on this one way or another--either

>>approach works for me. I will bow to the will of the majority. Anyone

>>else have comments?

>>

>>_______________________________________________

>>simple mailing list

>>simple@mailman.dynamicsoft.com

>><http://mailman.dynamicsoft.com/mailman/listinfo/simple>http://mailman.dynamicsoft.com/mailman/listinfo/simple

>

>--

>___________________________

>

>Bobby Sardana |  SEVEN

>Software Engineer, Engineering

>___________________________

>

>901 Marshall St.

>Redwood City, CA 94063

>650.381.2535 (v)

>650.216.6455 (f)

>dsardana@seven.com

>www.seven.com

>



-- 
___________________________ 

Bobby Sardana |  SEVEN 
Software Engineer, Engineering  
___________________________ 

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
dsardana@seven.com
www.seven.com

 

--------------BC3F45C54E0C30CBDE88BE03--


From mhammer@cisco.com  Tue Jul 16 14:26:37 2002
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 OAA07279
	for ; Tue, 16 Jul 2002 14:26:37 -0400 (EDT)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6GIR1a9017353;
	Tue, 16 Jul 2002 14:27:02 -0400 (EDT)
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 AAZ91668;
	Tue, 16 Jul 2002 14:21:31 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020716142439.00b8a820@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 16 Jul 2002 14:26:25 -0400
To: Bobby Sardana 
From: Michael Hammer 
Subject: Re: [Simple] -05 MESSAGE and Expires header
Cc: Ben Campbell ,
        "Vijay K. Gurbani" ,
        Tan Ya-Ching ICM N PG U ID A 1 ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3D345B45.5300EC60@seven.com>
References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e>
 <3D3419CF.4010905@lucent.com>
 <3D341EE8.2050800@dynamicsoft.com>
 <4.3.2.7.2.20020716133802.00b40db8@cia.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 2756
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: 

Bobby,

I vaguely recall a prior discussion on the possibility of stale 
messages.  Not trying to propose anything, just wanted to be sure Expires: 
0 does not have more than one semantic associated.

Mike


At 10:43 AM 7/16/2002 -0700, Bobby Sardana wrote:
>Expires:0 appears to provide the following semantics:
>
>a. The message needs to be dropped (stale?)
>b. The message does not have an explicit expiration (infinite)
>
>Michael Hammer wrote:
>>Is it possible to deliver a message with an indication that it is
>>expired/stale?
>An erroneous implementation might. Why introduce the ambiguity.
>
>regards,
>
>Bobby Sardana.
>dsardana@seven.com
>>
>>
>>Mike
>>
>>At 09:58 AM 7/16/2002 -0700, Bobby Sardana wrote:
>> >I'll cast my vote for the Priority header. Expires: 0 somehow implies that
>> >the message needs to be dropped.
>> >
>> >regards,
>> >
>> >Bobby Sardana.
>> >dsardana@seven.com
>> >
>> >Ben Campbell wrote:
>> >>Vijay K. Gurbani wrote:
>> >> > Tan Ya-Ching ICM N PG U ID A 1 wrote:
>> >> >
>> >> >> Vijay,
>> >> >>
>> >> >> It is stated in RFC 3261 section 20.19 Expires that :
>> >> >> "The precise meaning of this (header) is method dependant".
>> >> >
>> >> >
>> >> > Agreed.
>> >> >
>> >> >> The use of the Expires header in MESSAGE is as it is defined in -05.
>> >> >> It has
>> >> >> only one meaning, so there is no overloading.
>> >> >
>> >> >
>> >> > That is debatable; good thing about ASCII protocols is that they are
>> >> > self describing.  Thus, having a "Priority: Urgent" is far more
>> >> > preferable to overloading "Expires: 0" to mean immediate handling.
>> >> > "Priority: Urgent" in this case makes it far more easy to figure
>> >> > out what is going on.
>> >> >
>> >> > - vijay
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >>I do not have strong feelings on this one way or another--either
>> >>approach works for me. I will bow to the will of the majority. Anyone
>> >>else have comments?
>> >>
>> >>_______________________________________________
>> >>simple mailing list
>> >>simple@mailman.dynamicsoft.com
>> >><http://mailman 
>> .dynamicsoft.com/mailman/listinfo/simple>http://mailman.dynamicsoft.com/mailman/listinfo/simple 
>>
>> >
>> >--
>> >___________________________
>> >
>> >Bobby Sardana |  SEVEN
>> >Software Engineer, Engineering
>> >___________________________
>> >
>> >901 Marshall St.
>> >Redwood City, CA 94063
>> >650.381.2535 (v)
>> >650.216.6455 (f)
>> >dsardana@seven.com
>> >www.seven.com
>> >
>
>--
>___________________________
>
>Bobby Sardana |  SEVEN
>Software Engineer, Engineering
>___________________________
>
>901 Marshall St.
>Redwood City, CA 94063
>650.381.2535 (v)
>650.216.6455 (f)
>dsardana@seven.com
>www.seven.com
>


From pkyzivat@cisco.com  Tue Jul 16 15:23:25 2002
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 PAA07492
	for ; Tue, 16 Jul 2002 15:23:25 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6GJNqZM027649;
	Tue, 16 Jul 2002 15:23:52 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN36979;
	Tue, 16 Jul 2002 15:27:59 -0400 (EDT)
Message-ID: <3D3472A5.307D922D@cisco.com>
Date: Tue, 16 Jul 2002 15:23:17 -0400
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: jdrosen@dynamicsoft.com, peter.paeppinghaus@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED7A@esebe013.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1173
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: 


aki.niemi@nokia.com wrote:
> 
> Hi All,
> 
> I don't understand why you would need to have a dialog for the one-shot message.

As far as I am concerned, none of this discussion has anything to do with one-shot (page mode) messages. It would indeed be a bad idea to require a dialog for page-mode
messages.

> Having MESSAGE set up a dialog (for example) may sound reasonable, but when would such a dialog end? Would I have to remember this dialog indefinitely, just in case someone replies to it?

Agree there are a multitude of problems with this.

> Using a "dummy" INVITE is also problematic. Not only does it blur the paging mode and the session mode, but also, what happens if the other end rejects? How would a user determine whether to accept or reject a "medialess" INVITE?

It does raise some issues. I think they are resolvable, but it isn't clear that they are worth resolving.

I am becoming convinced that the best solution is to say that the message "session" consists of page-mode messages over the negotiated route, without any common dialog,
common callid, etc. Any message ordering that is required can be handled in the message body using CPIM.

	Paul

From bcampbell@dynamicsoft.com  Tue Jul 16 18:18:39 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08051
	for ; Tue, 16 Jul 2002 18:18:37 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6GMI3hZ002845;
	Tue, 16 Jul 2002 17:18:04 -0500 (CDT)
Message-ID: <3D349B91.3090802@dynamicsoft.com>
Date: Tue, 16 Jul 2002 17:17:53 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Jonathan Rosenberg ,
        =?ISO-8859-1?Q?Peter_?=
 =?ISO-8859-1?Q?P=E4ppinghaus?= ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> <3D342B3B.E093356C@cisco.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 5689
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: 

Paul Kyzivat wrote:
> below...
> 
> Ben Campbell wrote:
> 
>>Paul Kyzivat wrote:
>>
>>>Ben - I agree with you. But I can't tell if you:
>>>
>>>- believe jonathan's proposal already implies
>>>  use of invite to establish the dialog
>>>
>>>- think invite ought to be used
>>>
>>>- have some other way in mind to set up the dialog
>>>
>>>      Paul
>>>
>>
>>If by Jonathan's proposal you mean
>>draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE.
> 
> 
> Yes, that is the one. I guess I wasn't clear about my concern. Here is the call flow from draft-rosenberg-simple-message-session-00:
> 
>        Caller               Proxy               Relay              Callee
>           |(1) INVITE         |                   |                   |
>           |m=54344            |                   |                   |
>           |c=1.2.3.4          |                   |                   |
>           |------------------>|(2) INVITE         |                   |
>           |                   |m=54344            |                   |
>           |                   |c=1.2.3.4          |                   |
>           |                   |hop=sip:relay      |                   |
>           |                   |-------------------------------------->|
>           |                   |(3) 200 OK         |                   |
>           |                   |m=44345            |                   |
>           |                   |c=4.3.2.1          |                   |
>           |(4) 200 OK         |<--------------------------------------|
>           |m=44345            |                   |                   |
>           |c=4.3.2.1          |                   |                   |
>           |hop=sip:relay      |                   |                   |
>           |<------------------|                   |                   |
>           |(5) ACK            |                   |                   |
>           |---------------------------------------------------------->|
>           |                   |                   |(6) MESSAGE        |
>           |                   |                   |ruri=1.2.3.4:54344 |
>           |                   |                   |Route=sip:relay    |
>           |                   |                   |<------------------|
>           |(7) MESSAGE        |                   |                   |
>           |ruri=1.2.3.4:54344 |                   |                   |
>           |<--------------------------------------|                   |
>           |(8) 200 OK         |                   |                   |
>           |-------------------------------------->|                   |
>           |                   |                   |(9) 200 OK         |
>           |                   |                   |------------------>|
>           |(10) MESSAGE       |                   |                   |
>           |ruri=4.3.2.1:44345 |                   |                   |
>           |Route=sip:relay    |                   |                   |
>           |-------------------------------------->|                   |
>           |                   |                   |(11) MESSAGE       |
>           |                   |                   |ruri=4.3.2.1:44345 |
>           |                   |                   |------------------>|
>           |                   |                   |(12) 200 OK        |
>           |                   |                   |<------------------|
>           |(13) 200 OK        |                   |                   |
>           |<--------------------------------------|                   |
>           |(14) BYE           |                   |                   |
>           |---------------------------------------------------------->|
>           |(15) 200 OK        |                   |                   |
>           |<----------------------------------------------------------|
> 
> This shows the MESSAGEs that are not part of any dialog. 
> 
> Then, earlier in this thread:
> 
> Jonathan Rosenberg wrote:
> 
>>Peter Päppinghaus wrote:
>>
>>>draft-rosenberg-simple-message-session-00 is silent about construction
>>>of Call-ID and From and To header tags in the MESSAGE requests sent
>>>within a message session.
>>
>>Well, the draft was just a proposal.
>>
>>I guess the messages would all use the same dialog ID, with increasing
>>CSeq within the dialog. Different dialog ID than the INVITE one, of course.
> 
> 
> This last sentence is what started this discussion. If the messages are to use the same dialog ID, and it is a different dialog ID than the INVITE, then where does this
> other dialog come from?
> 
> In the above flow, it would have to be implicit in the first MESSAGE (6), which seems wrong.
> 
> Another possibility (but also dubious) would be to generate a new INVITE between (5) and (6), from caller to callee, using the route header that involves the relay. This
> would be a media-less invite with the sole purpose of establishing a dialog. Then, the messages could be sent within the context of this dialog.
> 
> The simplest answer here is just to say that the messages don't share a dialog.
> 
> Or, it could be considered like REGISTER, where register refreshes SHOULD be sent using the same callid yet there is no dialog. Session oriented messages could also be sent
> using the same callid without any implication that this is a dialog. (But I don't like this much either.)
> 

OK, I see. My initial reaction is to just say the messages don't share a 
dialog. I don't think we want to deal with the implications of saying 
they do share a dialog (i.e. record-route, contact headers, etc.)



From bcampbell@dynamicsoft.com  Tue Jul 16 19:24:17 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08358
	for ; Tue, 16 Jul 2002 19:24:15 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6GNO5hZ007095;
	Tue, 16 Jul 2002 18:24:06 -0500 (CDT)
Message-ID: <3D34AB0B.1060401@dynamicsoft.com>
Date: Tue, 16 Jul 2002 18:23:55 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bobby Sardana 
CC: "Vijay K. Gurbani" ,
        Tan Ya-Ching ICM N PG U ID A 1
 ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <5B4D0C5BA65ECA46969C1419122317E6E74E60@mchh161e> <3D3419CF.4010905@lucent.com> <3D341EE8.2050800@dynamicsoft.com> <3D3450A9.D47B0910@seven.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1843
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: 

So, for all that have commented on this thread, is the description of 
Expires in RFC 3261 sufficient? If so, we can fix this by simply 
dropping the sentence about "Expires:0".

Or do you think the MESSAGE draft needs to contain additional language 
concerning "Priority"?

Bobby Sardana wrote:
> I'll cast my vote for the Priority header. Expires: 0 somehow implies 
> that the message needs to be dropped.
> 
> regards,
> 
> Bobby Sardana.
> dsardana@seven.com
> 
> Ben Campbell wrote:
> 
>> Vijay K. Gurbani wrote:
>> > Tan Ya-Ching ICM N PG U ID A 1 wrote:
>> >
>> >> Vijay,
>> >>
>> >> It is stated in RFC 3261 section 20.19 Expires that :
>> >> "The precise meaning of this (header) is method dependant".
>> >
>> >
>> > Agreed.
>> >
>> >> The use of the Expires header in MESSAGE is as it is defined in -05.
>> >> It has
>> >> only one meaning, so there is no overloading.
>> >
>> >
>> > That is debatable; good thing about ASCII protocols is that they are
>> > self describing.  Thus, having a "Priority: Urgent" is far more
>> > preferable to overloading "Expires: 0" to mean immediate handling.
>> > "Priority: Urgent" in this case makes it far more easy to figure
>> > out what is going on.
>> >
>> > - vijay
>> >
>> >
>> >
>> >
>>
>> I do not have strong feelings on this one way or another--either
>> approach works for me. I will bow to the will of the majority. Anyone
>> else have comments?
>>
>> _______________________________________________
>> simple mailing list
>> simple@mailman.dynamicsoft.com
>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>
> -- 
> ___________________________ 
> 
> Bobby Sardana |  SEVEN 
> Software Engineer, Engineering  
> ___________________________ 
> 
> 901 Marshall St.
> Redwood City, CA 94063
> 650.381.2535 (v)
> 650.216.6455 (f)
> dsardana@seven.com
> www.seven.com
> 
>  




From seancolson@yahoo.com  Tue Jul 16 19:54:24 2002
Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id TAA08511
	for ; Tue, 16 Jul 2002 19:54:20 -0400 (EDT)
Message-ID: <20020716235415.24341.qmail@web11604.mail.yahoo.com>
Received: from [133.93.76.168] by web11604.mail.yahoo.com via HTTP; Tue, 16 Jul 2002 16:54:15 PDT
Date: Tue, 16 Jul 2002 16:54:15 -0700 (PDT)
From: Sean Olson 
Subject: Re: [Simple] -05 MESSAGE and Expires header
To: Ben Campbell ,
        Bobby Sardana 
Cc: "Vijay K. Gurbani" ,
        Tan Ya-Ching ICM N PG U ID A 1 ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3D34AB0B.1060401@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 2547
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: 

Which are we trying to convey:

  1) The message expires on reception
  2) This is an urgent message

(1) seems to be solved by Expires:
(2) seems to be solved by Priority

/sean

--- Ben Campbell  wrote:
> So, for all that have commented on this thread, is
> the description of 
> Expires in RFC 3261 sufficient? If so, we can fix
> this by simply 
> dropping the sentence about "Expires:0".
> 
> Or do you think the MESSAGE draft needs to contain
> additional language 
> concerning "Priority"?
> 
> Bobby Sardana wrote:
> > I'll cast my vote for the Priority header.
> Expires: 0 somehow implies 
> > that the message needs to be dropped.
> > 
> > regards,
> > 
> > Bobby Sardana.
> > dsardana@seven.com
> > 
> > Ben Campbell wrote:
> > 
> >> Vijay K. Gurbani wrote:
> >> > Tan Ya-Ching ICM N PG U ID A 1 wrote:
> >> >
> >> >> Vijay,
> >> >>
> >> >> It is stated in RFC 3261 section 20.19 Expires
> that :
> >> >> "The precise meaning of this (header) is
> method dependant".
> >> >
> >> >
> >> > Agreed.
> >> >
> >> >> The use of the Expires header in MESSAGE is as
> it is defined in -05.
> >> >> It has
> >> >> only one meaning, so there is no overloading.
> >> >
> >> >
> >> > That is debatable; good thing about ASCII
> protocols is that they are
> >> > self describing.  Thus, having a "Priority:
> Urgent" is far more
> >> > preferable to overloading "Expires: 0" to mean
> immediate handling.
> >> > "Priority: Urgent" in this case makes it far
> more easy to figure
> >> > out what is going on.
> >> >
> >> > - vijay
> >> >
> >> >
> >> >
> >> >
> >>
> >> I do not have strong feelings on this one way or
> another--either
> >> approach works for me. I will bow to the will of
> the majority. Anyone
> >> else have comments?
> >>
> >> _______________________________________________
> >> simple mailing list
> >> simple@mailman.dynamicsoft.com
> >>
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >>
> > -- 
> > ___________________________ 
> > 
> > Bobby Sardana |  SEVEN 
> > Software Engineer, Engineering  
> > ___________________________ 
> > 
> > 901 Marshall St.
> > Redwood City, CA 94063
> > 650.381.2535 (v)
> > 650.216.6455 (f)
> > dsardana@seven.com
> > www.seven.com
> > 
> >  
> 
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

From fluffy@cisco.com  Tue Jul 16 20:16:11 2002
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08643
	for ; Tue, 16 Jul 2002 20:16:09 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6H0Fk4l000976;
	Tue, 16 Jul 2002 17:15:46 -0700 (PDT)
Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ADL64995;
	Tue, 16 Jul 2002 17:16:06 -0700 (PDT)
From: "Cullen Jennings" 
To: 
Cc: , "Vijay K. Gurbani" 
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Tue, 16 Jul 2002 17:15:50 -0700
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)
In-Reply-To: <3D3413F0.8000804@lucent.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 1591
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: 

To quote the honorable Mr. Sparks "leave it alone"

I don't think that it is fundamentally broken (other than of course the lame
name). Priority is definitely not the right thing to use. I would vote for
just going with it as it is.

Cullen


> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Vijay K.
> Gurbani
> Sent: Tuesday, July 16, 2002 5:39 AM
> To: bcampbell@dynamicsoft.com
> Cc: simple@mailman.dynamicsoft.com
> Subject: [Simple] -05 MESSAGE and Expires header
>
>
> Ben:
>
> Any reasons why -05 MESSAGE I-D overloads "Expires: 0" to mean
> immediate attention.  Maybe we can use "Priority: Urgent" instead; since
> the Priority header is defined in 3261 and "may be factored into
> decisions about call routing and acceptance".
>
> I think that overloading the Expires header here is confusing; 3261's
> use of "Expires: 0" in conjunction with REGISTER means something
> entirely different -- that this registration is invalid.  From a
> semantic point of view, "Expires: 0" with REGISTER to mean
> deregistration appears to make sense; but "Expires: 0" with MESSAGE to
> mean immediate delivery appears incongrous.
>
> If it is not too late, maybe you can consider using the Priority header.
> I won't be able to make it to simple WG meeting tomorrow, so I just
> wanted to bring this to you attention.
>
> Thanks,
>
> - vijay
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From bcampbell@dynamicsoft.com  Tue Jul 16 20:29:46 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08742
	for ; Tue, 16 Jul 2002 20:29:44 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6H0TXhZ011468;
	Tue, 16 Jul 2002 19:29:34 -0500 (CDT)
Message-ID: <3D34BA62.5090908@dynamicsoft.com>
Date: Tue, 16 Jul 2002 19:29:22 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings 
CC: simple@mailman.dynamicsoft.com, "Vijay K. Gurbani" ,
        "Sip@Ietf. Org" 
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: 
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1977
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: 

Yes--this was pretty much the mood of the room in the SIMPLE wg meeting. 
It was also mentioned that this is a SIP draft, and any decisions must 
be made on the SIP list. (I am copying this message to SIP).

So, my current plan is to leave it alone. If others disagree, please 
express that on the SIP list.


Thanks!

Ben.


Cullen Jennings wrote:
> To quote the honorable Mr. Sparks "leave it alone"
> 
> I don't think that it is fundamentally broken (other than of course the lame
> name). Priority is definitely not the right thing to use. I would vote for
> just going with it as it is.
> 
> Cullen
> 
> 
> 
>>-----Original Message-----
>>From: simple-admin@mailman.dynamicsoft.com
>>[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Vijay K.
>>Gurbani
>>Sent: Tuesday, July 16, 2002 5:39 AM
>>To: bcampbell@dynamicsoft.com
>>Cc: simple@mailman.dynamicsoft.com
>>Subject: [Simple] -05 MESSAGE and Expires header
>>
>>
>>Ben:
>>
>>Any reasons why -05 MESSAGE I-D overloads "Expires: 0" to mean
>>immediate attention.  Maybe we can use "Priority: Urgent" instead; since
>>the Priority header is defined in 3261 and "may be factored into
>>decisions about call routing and acceptance".
>>
>>I think that overloading the Expires header here is confusing; 3261's
>>use of "Expires: 0" in conjunction with REGISTER means something
>>entirely different -- that this registration is invalid.  From a
>>semantic point of view, "Expires: 0" with REGISTER to mean
>>deregistration appears to make sense; but "Expires: 0" with MESSAGE to
>>mean immediate delivery appears incongrous.
>>
>>If it is not too late, maybe you can consider using the Priority header.
>>I won't be able to make it to simple WG meeting tomorrow, so I just
>>wanted to bring this to you attention.
>>
>>Thanks,
>>
>>- vijay
>>
>>_______________________________________________
>>simple mailing list
>>simple@mailman.dynamicsoft.com
>>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>
> 
> 




From adam@dynamicsoft.com  Tue Jul 16 20:41:46 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08845
	for ; Tue, 16 Jul 2002 20:41:46 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com ([63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6H0fOEU012464;
	Tue, 16 Jul 2002 20:41:26 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <306APYXX>; Tue, 16 Jul 2002 19:41:41 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F325F46A@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: Ben Campbell ,
        Bobby Sardana
	 
Cc: "Vijay K. Gurbani" ,
        Tan Ya-Ching ICM N PG U ID A 1
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Tue, 16 Jul 2002 19:41:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2903
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: 

Personally, I think the "Expires" handling is sufficient
and unambiguious.

The use of "Priority" would be inappropriate. High priority
items don't necessarily have a high urgency -- and what you're
trying to communicate here is urgency, not priority.

However, I'd take a different tact: this is really a disposition
for the message.

In the final equasion, though, I think it's all a moot point,
since "Expires: 0" works just fine.

/a

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Tuesday, July 16, 2002 18:24
> To: Bobby Sardana
> Cc: Vijay K. Gurbani; Tan Ya-Ching ICM N PG U ID A 1;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] -05 MESSAGE and Expires header
> 
> 
> So, for all that have commented on this thread, is the description of 
> Expires in RFC 3261 sufficient? If so, we can fix this by simply 
> dropping the sentence about "Expires:0".
> 
> Or do you think the MESSAGE draft needs to contain additional 
> language 
> concerning "Priority"?
> 
> Bobby Sardana wrote:
> > I'll cast my vote for the Priority header. Expires: 0 
> somehow implies 
> > that the message needs to be dropped.
> > 
> > regards,
> > 
> > Bobby Sardana.
> > dsardana@seven.com
> > 
> > Ben Campbell wrote:
> > 
> >> Vijay K. Gurbani wrote:
> >> > Tan Ya-Ching ICM N PG U ID A 1 wrote:
> >> >
> >> >> Vijay,
> >> >>
> >> >> It is stated in RFC 3261 section 20.19 Expires that :
> >> >> "The precise meaning of this (header) is method dependant".
> >> >
> >> >
> >> > Agreed.
> >> >
> >> >> The use of the Expires header in MESSAGE is as it is 
> defined in -05.
> >> >> It has
> >> >> only one meaning, so there is no overloading.
> >> >
> >> >
> >> > That is debatable; good thing about ASCII protocols is 
> that they are
> >> > self describing.  Thus, having a "Priority: Urgent" is far more
> >> > preferable to overloading "Expires: 0" to mean immediate 
> handling.
> >> > "Priority: Urgent" in this case makes it far more easy to figure
> >> > out what is going on.
> >> >
> >> > - vijay
> >> >
> >> >
> >> >
> >> >
> >>
> >> I do not have strong feelings on this one way or another--either
> >> approach works for me. I will bow to the will of the 
> majority. Anyone
> >> else have comments?
> >>
> >> _______________________________________________
> >> simple mailing list
> >> simple@mailman.dynamicsoft.com
> >> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >>
> > -- 
> > ___________________________ 
> > 
> > Bobby Sardana |  SEVEN 
> > Software Engineer, Engineering  
> > ___________________________ 
> > 
> > 901 Marshall St.
> > Redwood City, CA 94063
> > 650.381.2535 (v)
> > 650.216.6455 (f)
> > dsardana@seven.com
> > www.seven.com
> > 
> >  
> 
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From dean.willis@softarmor.com  Tue Jul 16 22:17:12 2002
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 WAA09202
	for ; Tue, 16 Jul 2002 22:17:11 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g6H2HE332144
	for ; Tue, 16 Jul 2002 21:17:14 -0500
From: "Dean Willis" 
To: 
Date: Tue, 16 Jul 2002 21:17:03 -0500
Message-ID: <002901c22d38$0b3fe330$7e4d5d85@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 12259
Subject: [Simple] Rough notes on SIMPLE session
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: 

My rough notes are attached. Please send amendments to the chairs.

---
Dean


Notes SIMPLE Working Group, IETF 54 0900-1130 17Jul02

Agenda presented, accepted

MESSAGE Update, Ben Campbell

  MESSAGE method in UETF last call, waiting IESG feedback. There have
  been several small changes. This draft has added an option for large
  messages if congestion-safe transport os used. Also clarified
  Expires header, although new discussion of this topic has occurred
  on list in the last 24 hours. Use of 0-value Expires as "immediate"
  request label is an open question vs "Priority". Audience poll
  favored current usage with 0-value. There has been discussion of a
  stronger requirement for REGISTER with method-message. Current
  discussion is to leave it as currently documented. Motion made from
  floor to leave well enough alone -- barring major issues, just go
  with the current form.

CPIM Mapping, Ben Campbell

  Recent draft has minor changes to sync with 3261, but has CPIM
  dependencies. IMPP chair Mark Day reports that CPIM has experienced
  a resurgence of interest and may be the last deliverable from IMPP,
  with a due date on the order of "a couple of months".

SIMPLE Data Manipluation Requirements, Jonathan Rosenberg

  Presence List Changes:

  Terminology change from "buddy list" to "presence list" in latest
  draft. More data than PIDF needed due to requirement for partial
  update, including full/partial update flags to allow differential
  updates. Lists may include lists, so the list server subscribes to
  list package for each entry rather than the basic presence package,
  thereby providing nesting. 

  Open Issue #1: Should PL be a Template package? Discussion presented
  in slides. Open question -- is a new body type required? Current
  draft proposes a multipart body with a madatory base class and an
  optional seperate "collection" body with references to other
  elements. This preserves the original bodies in an unmodified
  fashion and allows package-indpendent collection servers. Example
  bodies presented in slides. Comment from floor: this has some
  similarity to SynchML and may justify examination thereof. Comment
  from floor: This multi-level approach is interesting, but the given
  approach has a lot of overhead. Also the proposal doesn't seem to
  have any way to distinguish multiple elements. 2nd comment
  adddressed, spec requires that templateable packages specify a URI
  to reference elements. Application/versioninfo should be an XML
  document with full referencing. Comment from Patrik: Mixing MIME
  dividers and XML dividers can be problematic, especially if
  signatures are used. Response: Reason author likes multipart/mixed
  rather than pidf is that this appproach preserves signatures and
  seems to work. 

  Open Issue #2: Too Many Choices

  Current draft allows PIDF, PLIDF, Multipart Mixed, all of which have
  assorted issues discussed in slides. The Collection Template
  approach discussed above seems to allow mixing of these types while
  clearing all of the noted issues. 

  Open Issue #3: State of Suscriptions

  The Presence List Server is a "fan-out" server. There's currently no
  way to know the state of the fanned-out subscriptions on a
  transitive basis. Proposal is to aggregate this information in
  listinfo format as proposed in collection template class, then
  support partial updates. Discussion: What would the event header
  look like? Proposed alternative: multipart/mixed with message/sip
  inside. This would reduce maintenance of collection
  formats. Response is tha t this would keep all of the overhead of
  SIP routing information -- cseqs, etc. and would create a great deal
  of overhead problematic for wireless applications. 

  Open Issue #4: Sharing Of Versions

  Issues discussed in slides, all cleared by proposed collection model.

  Open Issue #5: Which Package does PLS use?

  Several options proposed: 1) presence.collection, fallback to
  presence, 2) add labels to lists so they can be parsed as lists 3)
  user has to KNOW that a subscribed list is a list, not an
  individual, 4) Server OPTION The URI to discover that it is a list,
  then uses appropriate package, which works as long as role of URI is
  fixed. 5) disallow recursion. Comments requested: Question: How are
  1, 3 ,and 4 not complementary? Ans: Original proposal was "All but
  2". This results in notifications that exceed the scope of the
  subscription, which could be confusing to sort out. Question: How do
  you identify these? The event header was "buddy list", what now?
  Ans: It was always a request URI, the only thing that changes is the
  event name. Question: Could the AOR be a bddy list? Ans: Yes, but
  not in an overloaded condition where the URI presents both an
  indivdual and a list. This would seem to be a reasonable
  interpretation of URI usage. Question: What about multipart
  recursion? Extended discussion followed . . . discussion deferred to
  offline. Question: If something has presence but not presence
  collection, would it be reasonable to serve up presence instead of a
  prsence collection? Ans: yes. This will be clarified in
  draft. Audience polled: Is going in the direction of a template
  class generally reasonable? Answer favorable, none opposed.


Data Requirements, Jonathan Rosenberg
  
  Presence and IM ssytems use multiple data elements to drive the
  application. We need to manipulate these data items, interact with,
  change, etc. them. This is disjoint from the subscription and
  notification mechanism, and includes read and write mechanisms with
  caching (offline access, and modification) and security requirements
  (listed in draft). Question: Does this create additional
  requirements around concurrent offline changes and reconciliation?
  Ans: Not a requirements issue but an implementation issue. Comment:
  This topic could use its own working group, we should perhaps not
  solve it here. Ans: We're just talking about requirements and really
  expect to reuse an existing solution like SyncML. Comment: Should
  study data model in ACAP very carefully. Ans: Authors are already
  working with ACAP author to analyze. Extended discssion on tradeoff
  of authorization, inheritance, and cacheing issues followed. Open
  issues include 1) Do enough of the data manipulation type thihngs we
  do fit under this model to justify further work, 2) Should we
  generalize or do something specific for presence lists? 3) How do we
  align with SIP conf work? 4) Should we adopt as a WG item? Comment:
  This is a large problem space, and includes things like WebDAV,
  XPath, XML database, and probably becomes at least a New York sized
  rathole. It probably would be a bad idea to choose to do something
  limited to the presence list problem. Comment: There's a lot of
  overlap with W3C and other work, we should collaborate. Comment:
  This is similar to the UA configuration task, can we combine them?
  Comment: Is this really a semantic manipulation problem, or a remove
  text editing problem?  Comment: What is start with a pure XML
  framework, then we can use stuff like XPath and see if it
  works. Comments: We should at least work on this here, starting from
  specific topics in charter. Poll: Should this work be adopted as a
  wokring group item toward existing charter goal? Response favorable,
  none opposed.

The PUBLISH Method, Sean Olson
  
  The critical issues here depend on the composition model in the
  preceeding discussion. The basic model is discussed in the
  slides. The contentious component of the draft is the "slot" model
  of presence composition. Open issues include: 1) Should we
  includeCPL problem in scope, Proposal, No. 2) Is "slot" idea right
  way to go? 3) Do we need to standardize PType tokens? 40 Should
  PType require IANA registration? 5) Should PState be replaced with
  Expires header?  

  Comments: This seems to be the micro-version of WebDAV, but
  scope-limited for just the PL problem. This may argue that the very
  general "PUBLISH" name is too broad. Also, do we really want to
  differentiate between hard-state and soft-state data? Ans: Name can
  be changed. Authors have deliberately restricted to soft-state
  because this data has direct correlation or "binding" with SIP
  routing and cannot be well addressed by other mechanisms like
  WebDAV. Hard-state information does not seem to have this
  characteristic. This is particularly crucial for third-party
  manipulation of soft-state information given only a SIP URI as a key
  to that information. SIMPLE isn't deployable without this and it has
  to be fixed NOW. The requirement here is scoped explicitly by SIP
  Events. Comment: Can we identify a reasonable stopping point? The
  model of having to find a "stopping point" based on a SIP URI seems
  reasonably common. Proposal: Could we do PUBLISH via a reversed
  subscribe/notify model? Discussion of this approach not
  favorable. Question: How does one manage policy of slot composition?
  Ans: The composition policy of a compositor is locally determined.

3GPP Presence Requirements, Krizstian Kiss

  Slides summarize requirements. from draft. Discussion of requirememt
  "Keep all PUAs aware of each other's publishing": Comment that this
  seems to be contradictory, it would be better to make publishing
  transparent across devices. Ans: This is because we have "network
  attributes" that have to work this way. Further discussion
  deferred. Comment: there are requirements for filtering in a lot of
  our discussions, we should add to charter. Comment: partial
  notification is messy. We need to clarify this. For example, CPIM
  and partial notification are conflicting requirements. Comments on
  requirment for anonymous subscription: This means the subscriber is
  anoynmous, not that the subscription is invisible to the prsentity,
  right? Ans: yes. Comment: If geoloc is part of presence document,
  how does it get composited? Ans: simply -- just reference the geoloc
  document. There are lots of authorization issues around WHO can
  update and/or see geoloc. Discussion: Is it reasonable to accept
  requirement from 3GPP? Discussion: Rather than having "3GPP
  requriements" on our charter, shouldn't we simply integrate these
  requirements into our chartered requiremeents documents? This
  proposal seems to be generally favorable to the audience. 

3GPP Instant Messaging Requirements, Aki Niemi

  This document is intended as a "heads up" to IETF. The work is at a
  very early stage in 3GPP. Formal requirements are expected by IETF55.

IMSX Protocol Evaluation for Session-Based IM, Mary Barnes

  Analysis presented. Comment: Although it doesn't currently support
  threading, BEEP could so so easily. Aomment: Although there may be
  objections to implememnting yet another protocol in a node, SIP does
  shine at multiprotocol stories and really does work well with a mix
  of transports and codecs. Comment: The status of IMXP does not seem
  clear, as there have been apparent strategic shifts by the author
  (Jabber). Comment: Rohan said something about IMTP and strategic
  subsets and Fred Baker, but this reporter didn't parse it. Comment:
  messages are somewhat like media, and somewhat not like media, and
  we probably don't need a divergence between session and pager
  model. Comment: We seem to have only one proposal -- use SIP. The
  idea of defining IMTP as a seperate protocol subset seems
  pointless. Defining the session model as a stream of MESSAGES
  bounded by a dialog seems like the right thing to do. Comment: Using
  SIP without changing the name clearly violates the spirit and letter
  of our own SIP guidelines and has potential interop
  problems. Comment: If somebody is going to define a new proposal,
  they need to do it really soon. We really DO have only one draft
  under current consideration. Proposal: Let's just move forward with
  Jonathan's draft, in a non-exclusive sense. Discussion seems to
  favor this as the baseline default, and we can do additional stuff
  later if needed. We should immediately discuss on list and conclude
  whetehr we go forward immediately with SIP or a renamed SIP-subset
  (IMTP).


From mhammer@cisco.com  Wed Jul 17 11:00:17 2002
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 LAA11470
	for ; Wed, 17 Jul 2002 11:00:17 -0400 (EDT)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6HF0e1W017059;
	Wed, 17 Jul 2002 11:00:40 -0400 (EDT)
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 AAZ98843;
	Wed, 17 Jul 2002 10:55:10 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020717105028.00b5cda0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 17 Jul 2002 11:00:04 -0400
To: Ben Campbell 
From: Michael Hammer 
Subject: Re: [Simple] Message session & associated dialog
Cc: Paul Kyzivat ,
        Jonathan Rosenberg ,
        Peter  
 =?iso-8859-1?Q?P=E4ppinghaus?= ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3D349B91.3090802@dynamicsoft.com>
References: <3D2E9D8D.6040509@icn.siemens.de>
 <3D302998.3050004@dynamicsoft.com>
 <3D32CDAB.51210C4E@cisco.com>
 <3D336AA6.6050202@dynamicsoft.com>
 <3D33750A.85F8BFD2@cisco.com>
 <3D33B5D9.8010907@dynamicsoft.com>
 <3D342B3B.E093356C@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Length: 6271
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA11470
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: 

Ben,

If you substitute RTP stream for MESSAGE stream in this discussion are 
there any differences?  That is, is the correlation between the RTP stream 
and the SIP signaling stream any different?  Can we conclude that the 
operational requirements of both these media streams would be parallel?

Mike


At 05:17 PM 7/16/2002 -0500, Ben Campbell wrote:
>Paul Kyzivat wrote:
>>below...
>>Ben Campbell wrote:
>>
>>>Paul Kyzivat wrote:
>>>
>>>>Ben - I agree with you. But I can't tell if you:
>>>>
>>>>- believe jonathan's proposal already implies
>>>>  use of invite to establish the dialog
>>>>
>>>>- think invite ought to be used
>>>>
>>>>- have some other way in mind to set up the dialog
>>>>
>>>>      Paul
>>>
>>>If by Jonathan's proposal you mean
>>>draft-rosenberg-simple-message-session-00, it fairly explicitly uses INVITE.
>>
>>Yes, that is the one. I guess I wasn't clear about my concern. Here is 
>>the call flow from draft-rosenberg-simple-message-session-00:
>>        Caller               Proxy               Relay              Callee
>>           |(1) INVITE         |                   |                   |
>>           |m=54344            |                   |                   |
>>           |c=1.2.3.4          |                   |                   |
>>           |------------------>|(2) INVITE         |                   |
>>           |                   |m=54344            |                   |
>>           |                   |c=1.2.3.4          |                   |
>>           |                   |hop=sip:relay      |                   |
>>           |                   |-------------------------------------->|
>>           |                   |(3) 200 OK         |                   |
>>           |                   |m=44345            |                   |
>>           |                   |c=4.3.2.1          |                   |
>>           |(4) 200 OK         |<--------------------------------------|
>>           |m=44345            |                   |                   |
>>           |c=4.3.2.1          |                   |                   |
>>           |hop=sip:relay      |                   |                   |
>>           |<------------------|                   |                   |
>>           |(5) ACK            |                   |                   |
>>           |---------------------------------------------------------->|
>>           |                   |                   |(6) MESSAGE        |
>>           |                   |                   |ruri=1.2.3.4:54344 |
>>           |                   |                   |Route=sip:relay    |
>>           |                   |                   |<------------------|
>>           |(7) MESSAGE        |                   |                   |
>>           |ruri=1.2.3.4:54344 |                   |                   |
>>           |<--------------------------------------|                   |
>>           |(8) 200 OK         |                   |                   |
>>           |-------------------------------------->|                   |
>>           |                   |                   |(9) 200 OK         |
>>           |                   |                   |------------------>|
>>           |(10) MESSAGE       |                   |                   |
>>           |ruri=4.3.2.1:44345 |                   |                   |
>>           |Route=sip:relay    |                   |                   |
>>           |-------------------------------------->|                   |
>>           |                   |                   |(11) MESSAGE       |
>>           |                   |                   |ruri=4.3.2.1:44345 |
>>           |                   |                   |------------------>|
>>           |                   |                   |(12) 200 OK        |
>>           |                   |                   |<------------------|
>>           |(13) 200 OK        |                   |                   |
>>           |<--------------------------------------|                   |
>>           |(14) BYE           |                   |                   |
>>           |---------------------------------------------------------->|
>>           |(15) 200 OK        |                   |                   |
>>           |<----------------------------------------------------------|
>>This shows the MESSAGEs that are not part of any dialog.
>>Then, earlier in this thread:
>>Jonathan Rosenberg wrote:
>>
>>>Peter Päppinghaus wrote:
>>>
>>>>draft-rosenberg-simple-message-session-00 is silent about construction
>>>>of Call-ID and From and To header tags in the MESSAGE requests sent
>>>>within a message session.
>>>
>>>Well, the draft was just a proposal.
>>>
>>>I guess the messages would all use the same dialog ID, with increasing
>>>CSeq within the dialog. Different dialog ID than the INVITE one, of course.
>>
>>This last sentence is what started this discussion. If the messages are 
>>to use the same dialog ID, and it is a different dialog ID than the 
>>INVITE, then where does this
>>other dialog come from?
>>In the above flow, it would have to be implicit in the first MESSAGE (6), 
>>which seems wrong.
>>Another possibility (but also dubious) would be to generate a new INVITE 
>>between (5) and (6), from caller to callee, using the route header that 
>>involves the relay. This
>>would be a media-less invite with the sole purpose of establishing a 
>>dialog. Then, the messages could be sent within the context of this dialog.
>>The simplest answer here is just to say that the messages don't share a 
>>dialog.
>>Or, it could be considered like REGISTER, where register refreshes SHOULD 
>>be sent using the same callid yet there is no dialog. Session oriented 
>>messages could also be sent
>>using the same callid without any implication that this is a dialog. (But 
>>I don't like this much either.)
>
>OK, I see. My initial reaction is to just say the messages don't share a 
>dialog. I don't think we want to deal with the implications of saying they 
>do share a dialog (i.e. record-route, contact headers, etc.)
>
>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple


From bcampbell@dynamicsoft.com  Wed Jul 17 20:15:42 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13100
	for ; Wed, 17 Jul 2002 20:15:41 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6I0FPhZ013365;
	Wed, 17 Jul 2002 19:15:26 -0500 (CDT)
Message-ID: <3D360892.3070204@dynamicsoft.com>
Date: Wed, 17 Jul 2002 19:15:14 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Hammer 
CC: Paul Kyzivat ,
        Jonathan Rosenberg
 ,
        =?ISO-8859-1?Q?Peter_P=E4ppinghaus?=
 ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> <3D342B3B.E093356C@cisco.com> <4.3.2.7.2.20020717105028.00b5cda0@cia.cisco.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 6686
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: 

It seems it would make sense for it to be the same. The MESSAGE stream 
should be just another media stream from the perspective of the 
associated dialog.

Michael Hammer wrote:
> Ben,
> 
> If you substitute RTP stream for MESSAGE stream in this discussion are 
> there any differences?  That is, is the correlation between the RTP 
> stream and the SIP signaling stream any different?  Can we conclude that 
> the operational requirements of both these media streams would be parallel?
> 
> Mike
> 
> 
> At 05:17 PM 7/16/2002 -0500, Ben Campbell wrote:
> 
>> Paul Kyzivat wrote:
>>
>>> below...
>>> Ben Campbell wrote:
>>>
>>>> Paul Kyzivat wrote:
>>>>
>>>>> Ben - I agree with you. But I can't tell if you:
>>>>>
>>>>> - believe jonathan's proposal already implies
>>>>>  use of invite to establish the dialog
>>>>>
>>>>> - think invite ought to be used
>>>>>
>>>>> - have some other way in mind to set up the dialog
>>>>>
>>>>>      Paul
>>>>
>>>>
>>>> If by Jonathan's proposal you mean
>>>> draft-rosenberg-simple-message-session-00, it fairly explicitly uses 
>>>> INVITE.
>>>
>>>
>>> Yes, that is the one. I guess I wasn't clear about my concern. Here 
>>> is the call flow from draft-rosenberg-simple-message-session-00:
>>>        Caller               Proxy               Relay              
>>> Callee
>>>           |(1) INVITE         |                   |                   |
>>>           |m=54344            |                   |                   |
>>>           |c=1.2.3.4          |                   |                   |
>>>           |------------------>|(2) INVITE         |                   |
>>>           |                   |m=54344            |                   |
>>>           |                   |c=1.2.3.4          |                   |
>>>           |                   |hop=sip:relay      |                   |
>>>           |                   |-------------------------------------->|
>>>           |                   |(3) 200 OK         |                   |
>>>           |                   |m=44345            |                   |
>>>           |                   |c=4.3.2.1          |                   |
>>>           |(4) 200 OK         |<--------------------------------------|
>>>           |m=44345            |                   |                   |
>>>           |c=4.3.2.1          |                   |                   |
>>>           |hop=sip:relay      |                   |                   |
>>>           |<------------------|                   |                   |
>>>           |(5) ACK            |                   |                   |
>>>           |---------------------------------------------------------->|
>>>           |                   |                   |(6) MESSAGE        |
>>>           |                   |                   |ruri=1.2.3.4:54344 |
>>>           |                   |                   |Route=sip:relay    |
>>>           |                   |                   |<------------------|
>>>           |(7) MESSAGE        |                   |                   |
>>>           |ruri=1.2.3.4:54344 |                   |                   |
>>>           |<--------------------------------------|                   |
>>>           |(8) 200 OK         |                   |                   |
>>>           |-------------------------------------->|                   |
>>>           |                   |                   |(9) 200 OK         |
>>>           |                   |                   |------------------>|
>>>           |(10) MESSAGE       |                   |                   |
>>>           |ruri=4.3.2.1:44345 |                   |                   |
>>>           |Route=sip:relay    |                   |                   |
>>>           |-------------------------------------->|                   |
>>>           |                   |                   |(11) MESSAGE       |
>>>           |                   |                   |ruri=4.3.2.1:44345 |
>>>           |                   |                   |------------------>|
>>>           |                   |                   |(12) 200 OK        |
>>>           |                   |                   |<------------------|
>>>           |(13) 200 OK        |                   |                   |
>>>           |<--------------------------------------|                   |
>>>           |(14) BYE           |                   |                   |
>>>           |---------------------------------------------------------->|
>>>           |(15) 200 OK        |                   |                   |
>>>           |<----------------------------------------------------------|
>>> This shows the MESSAGEs that are not part of any dialog.
>>> Then, earlier in this thread:
>>> Jonathan Rosenberg wrote:
>>>
>>>> Peter Päppinghaus wrote:
>>>>
>>>>> draft-rosenberg-simple-message-session-00 is silent about construction
>>>>> of Call-ID and From and To header tags in the MESSAGE requests sent
>>>>> within a message session.
>>>>
>>>>
>>>> Well, the draft was just a proposal.
>>>>
>>>> I guess the messages would all use the same dialog ID, with increasing
>>>> CSeq within the dialog. Different dialog ID than the INVITE one, of 
>>>> course.
>>>
>>>
>>> This last sentence is what started this discussion. If the messages 
>>> are to use the same dialog ID, and it is a different dialog ID than 
>>> the INVITE, then where does this
>>> other dialog come from?
>>> In the above flow, it would have to be implicit in the first MESSAGE 
>>> (6), which seems wrong.
>>> Another possibility (but also dubious) would be to generate a new 
>>> INVITE between (5) and (6), from caller to callee, using the route 
>>> header that involves the relay. This
>>> would be a media-less invite with the sole purpose of establishing a 
>>> dialog. Then, the messages could be sent within the context of this 
>>> dialog.
>>> The simplest answer here is just to say that the messages don't share 
>>> a dialog.
>>> Or, it could be considered like REGISTER, where register refreshes 
>>> SHOULD be sent using the same callid yet there is no dialog. Session 
>>> oriented messages could also be sent
>>> using the same callid without any implication that this is a dialog. 
>>> (But I don't like this much either.)
>>
>>
>> OK, I see. My initial reaction is to just say the messages don't share 
>> a dialog. I don't think we want to deal with the implications of 
>> saying they do share a dialog (i.e. record-route, contact headers, etc.)
>>
>>
>> _______________________________________________
>> simple mailing list
>> simple@mailman.dynamicsoft.com
>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 




From jdrosen@dynamicsoft.com  Wed Jul 17 22:25:00 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA13492
	for ; Wed, 17 Jul 2002 22:25:00 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.9])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6I2OsYH010758;
	Wed, 17 Jul 2002 22:24:55 -0400 (EDT)
Message-ID: <3D3626F3.3080106@dynamicsoft.com>
Date: Thu, 18 Jul 2002 11:24:51 +0900
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Adam Roach 
CC: Ben Campbell ,
        Bobby Sardana
 ,
        "Vijay K. Gurbani" ,
        Tan Ya-Ching ICM
 N PG U ID A 1 ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <9BF66EBF6BEFD942915B4D4D45C051F325F46A@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 4339
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: 

Expires is method specific, since its precise interpretation is method 
specific. The general notion is that it indicates a lifetime of 
something; a point after which the thing is no longer valid. I think 
that this more genearl definition is an exact match to our need here, 
and the current Expires text is an appropriate instantiation of it for 
MESSAGE.

I believe that priority is quite different. A message can be for 
immediate delivery, and be either urgent ("my house is on fire") or not 
("leaving now for lunch"). A message can be OK for storage (some 
non-zero expires) and be urgent ("I need that business presentation by 
10pm!") or non-urgent ("Did you see that movie"). The fact that two 
things can be used orthogonally is a sign that they are, in fact, two 
different things.

I strongly support keeping Expires as currently defined.

-Jonathan R.

Adam Roach wrote:
> Personally, I think the "Expires" handling is sufficient
> and unambiguious.
> 
> The use of "Priority" would be inappropriate. High priority
> items don't necessarily have a high urgency -- and what you're
> trying to communicate here is urgency, not priority.
> 
> However, I'd take a different tact: this is really a disposition
> for the message.
> 
> In the final equasion, though, I think it's all a moot point,
> since "Expires: 0" works just fine.
> 
> /a
> 
> 
>>-----Original Message-----
>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
>>Sent: Tuesday, July 16, 2002 18:24
>>To: Bobby Sardana
>>Cc: Vijay K. Gurbani; Tan Ya-Ching ICM N PG U ID A 1;
>>simple@mailman.dynamicsoft.com
>>Subject: Re: [Simple] -05 MESSAGE and Expires header
>>
>>
>>So, for all that have commented on this thread, is the description of 
>>Expires in RFC 3261 sufficient? If so, we can fix this by simply 
>>dropping the sentence about "Expires:0".
>>
>>Or do you think the MESSAGE draft needs to contain additional 
>>language 
>>concerning "Priority"?
>>
>>Bobby Sardana wrote:
>>
>>>I'll cast my vote for the Priority header. Expires: 0 
>>
>>somehow implies 
>>
>>>that the message needs to be dropped.
>>>
>>>regards,
>>>
>>>Bobby Sardana.
>>>dsardana@seven.com
>>>
>>>Ben Campbell wrote:
>>>
>>>
>>>>Vijay K. Gurbani wrote:
>>>>
>>>>>Tan Ya-Ching ICM N PG U ID A 1 wrote:
>>>>>
>>>>>
>>>>>>Vijay,
>>>>>>
>>>>>>It is stated in RFC 3261 section 20.19 Expires that :
>>>>>>"The precise meaning of this (header) is method dependant".
>>>>>
>>>>>
>>>>>Agreed.
>>>>>
>>>>>
>>>>>>The use of the Expires header in MESSAGE is as it is 
>>>>>
>>defined in -05.
>>
>>>>>>It has
>>>>>>only one meaning, so there is no overloading.
>>>>>
>>>>>
>>>>>That is debatable; good thing about ASCII protocols is 
>>>>
>>that they are
>>
>>>>>self describing.  Thus, having a "Priority: Urgent" is far more
>>>>>preferable to overloading "Expires: 0" to mean immediate 
>>>>
>>handling.
>>
>>>>>"Priority: Urgent" in this case makes it far more easy to figure
>>>>>out what is going on.
>>>>>
>>>>>- vijay
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>I do not have strong feelings on this one way or another--either
>>>>approach works for me. I will bow to the will of the 
>>>
>>majority. Anyone
>>
>>>>else have comments?
>>>>
>>>>_______________________________________________
>>>>simple mailing list
>>>>simple@mailman.dynamicsoft.com
>>>>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>>
>>>
>>>-- 
>>>___________________________ 
>>>
>>>Bobby Sardana |  SEVEN 
>>>Software Engineer, Engineering  
>>>___________________________ 
>>>
>>>901 Marshall St.
>>>Redwood City, CA 94063
>>>650.381.2535 (v)
>>>650.216.6455 (f)
>>>dsardana@seven.com
>>>www.seven.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
> 


-- 
---
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


From peter.paeppinghaus@icn.siemens.de  Thu Jul 18 06:09:24 2002
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14775
	for ; Thu, 18 Jul 2002 06:09:23 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id MAA17851;
	Thu, 18 Jul 2002 12:09:20 +0200 (MET DST)
Received: from icn.siemens.de ([139.21.148.41])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id MAA08119;
	Thu, 18 Jul 2002 12:09:21 +0200 (MET DST)
Message-ID: <3D3693D0.2030901@icn.siemens.de>
Date: Thu, 18 Jul 2002 12:09:20 +0200
From: Peter =?ISO-8859-1?Q?P=E4ppinghaus?= 
Organization: Siemens AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2
X-Accept-Language: en,de
MIME-Version: 1.0
To: Ben Campbell 
CC: Michael Hammer , Paul Kyzivat ,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D2E9D8D.6040509@icn.siemens.de> <3D302998.3050004@dynamicsoft.com> <3D32CDAB.51210C4E@cisco.com> <3D336AA6.6050202@dynamicsoft.com> <3D33750A.85F8BFD2@cisco.com> <3D33B5D9.8010907@dynamicsoft.com> <3D342B3B.E093356C@cisco.com> <4.3.2.7.2.20020717105028.00b5cda0@cia.cisco.com> <3D360892.3070204@dynamicsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 7651
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: 

I am certainly not an expert on RTP, but elaborating on the
RTP stream / MESSAGE stream comparison:
RTP services certainly include sequence numbering.

How would sequence numbering be obtained, if the MESSAGE requests of a 
message session stream all have different Call-IDs?

Could not a shared Call-ID play a similar role that an SSRC 
(synchronization source identifier) plays in RTP, and the CSeq header 
field play the role that the sequence number field plays in RTP headers?

Peter

Ben Campbell wrote:

> It seems it would make sense for it to be the same. The MESSAGE stream 
> should be just another media stream from the perspective of the 
> associated dialog.
> 
> Michael Hammer wrote:
> 
>> Ben,
>>
>> If you substitute RTP stream for MESSAGE stream in this discussion are 
>> there any differences?  That is, is the correlation between the RTP 
>> stream and the SIP signaling stream any different?  Can we conclude 
>> that the operational requirements of both these media streams would be 
>> parallel?
>>
>> Mike
>>
>>
>> At 05:17 PM 7/16/2002 -0500, Ben Campbell wrote:
>>
>>> Paul Kyzivat wrote:
>>>
>>>> below...
>>>> Ben Campbell wrote:
>>>>
>>>>> Paul Kyzivat wrote:
>>>>>
>>>>>> Ben - I agree with you. But I can't tell if you:
>>>>>>
>>>>>> - believe jonathan's proposal already implies
>>>>>>  use of invite to establish the dialog
>>>>>>
>>>>>> - think invite ought to be used
>>>>>>
>>>>>> - have some other way in mind to set up the dialog
>>>>>>
>>>>>>      Paul
>>>>>
>>>>>
>>>>>
>>>>> If by Jonathan's proposal you mean
>>>>> draft-rosenberg-simple-message-session-00, it fairly explicitly 
>>>>> uses INVITE.
>>>>
>>>>
>>>>
>>>> Yes, that is the one. I guess I wasn't clear about my concern. Here 
>>>> is the call flow from draft-rosenberg-simple-message-session-00:
>>>>        Caller               Proxy               Relay              
>>>> Callee
>>>>           |(1) INVITE         |                   |                   |
>>>>           |m=54344            |                   |                   |
>>>>           |c=1.2.3.4          |                   |                   |
>>>>           |------------------>|(2) INVITE         |                   |
>>>>           |                   |m=54344            |                   |
>>>>           |                   |c=1.2.3.4          |                   |
>>>>           |                   |hop=sip:relay      |                   |
>>>>           |                   |-------------------------------------->|
>>>>           |                   |(3) 200 OK         |                   |
>>>>           |                   |m=44345            |                   |
>>>>           |                   |c=4.3.2.1          |                   |
>>>>           |(4) 200 OK         |<--------------------------------------|
>>>>           |m=44345            |                   |                   |
>>>>           |c=4.3.2.1          |                   |                   |
>>>>           |hop=sip:relay      |                   |                   |
>>>>           |<------------------|                   |                   |
>>>>           |(5) ACK            |                   |                   |
>>>>           |---------------------------------------------------------->|
>>>>           |                   |                   |(6) MESSAGE        |
>>>>           |                   |                   |ruri=1.2.3.4:54344 |
>>>>           |                   |                   |Route=sip:relay    |
>>>>           |                   |                   |<------------------|
>>>>           |(7) MESSAGE        |                   |                   |
>>>>           |ruri=1.2.3.4:54344 |                   |                   |
>>>>           |<--------------------------------------|                   |
>>>>           |(8) 200 OK         |                   |                   |
>>>>           |-------------------------------------->|                   |
>>>>           |                   |                   |(9) 200 OK         |
>>>>           |                   |                   |------------------>|
>>>>           |(10) MESSAGE       |                   |                   |
>>>>           |ruri=4.3.2.1:44345 |                   |                   |
>>>>           |Route=sip:relay    |                   |                   |
>>>>           |-------------------------------------->|                   |
>>>>           |                   |                   |(11) MESSAGE       |
>>>>           |                   |                   |ruri=4.3.2.1:44345 |
>>>>           |                   |                   |------------------>|
>>>>           |                   |                   |(12) 200 OK        |
>>>>           |                   |                   |<------------------|
>>>>           |(13) 200 OK        |                   |                   |
>>>>           |<--------------------------------------|                   |
>>>>           |(14) BYE           |                   |                   |
>>>>           |---------------------------------------------------------->|
>>>>           |(15) 200 OK        |                   |                   |
>>>>           |<----------------------------------------------------------|
>>>> This shows the MESSAGEs that are not part of any dialog.
>>>> Then, earlier in this thread:
>>>> Jonathan Rosenberg wrote:
>>>>
>>>>> Peter Päppinghaus wrote:
>>>>>
>>>>>> draft-rosenberg-simple-message-session-00 is silent about 
>>>>>> construction
>>>>>> of Call-ID and From and To header tags in the MESSAGE requests sent
>>>>>> within a message session.
>>>>>
>>>>>
>>>>>
>>>>> Well, the draft was just a proposal.
>>>>>
>>>>> I guess the messages would all use the same dialog ID, with increasing
>>>>> CSeq within the dialog. Different dialog ID than the INVITE one, of 
>>>>> course.
>>>>
>>>>
>>>>
>>>> This last sentence is what started this discussion. If the messages 
>>>> are to use the same dialog ID, and it is a different dialog ID than 
>>>> the INVITE, then where does this
>>>> other dialog come from?
>>>> In the above flow, it would have to be implicit in the first MESSAGE 
>>>> (6), which seems wrong.
>>>> Another possibility (but also dubious) would be to generate a new 
>>>> INVITE between (5) and (6), from caller to callee, using the route 
>>>> header that involves the relay. This
>>>> would be a media-less invite with the sole purpose of establishing a 
>>>> dialog. Then, the messages could be sent within the context of this 
>>>> dialog.
>>>> The simplest answer here is just to say that the messages don't 
>>>> share a dialog.
>>>> Or, it could be considered like REGISTER, where register refreshes 
>>>> SHOULD be sent using the same callid yet there is no dialog. Session 
>>>> oriented messages could also be sent
>>>> using the same callid without any implication that this is a dialog. 
>>>> (But I don't like this much either.)
>>>
>>>
>>>
>>> OK, I see. My initial reaction is to just say the messages don't 
>>> share a dialog. I don't think we want to deal with the implications 
>>> of saying they do share a dialog (i.e. record-route, contact headers, 
>>> etc.)
>>>
>>>
>>> _______________________________________________
>>> simple mailing list
>>> simple@mailman.dynamicsoft.com
>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>
>>
>>
> 
> 
> 


-- 
Dr. Peter Päppinghaus
Siemens AG            | Phone:    +49 89 - 722 40065
ICM N PG U ID A1      | Fax:      +49 89 - 722 58726
Hofmannstr. 51        | Visitors: Building 1702 / Room 530
D - 81359 München     | Email:    peter.paeppinghaus@icn.siemens.de


From peter.lewis@upperside.fr  Thu Jul 18 08:23:05 2002
Received: from smtp5.cluster.oleane.net (smtp5.cluster.oleane.net [195.25.12.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15206
	for ; Thu, 18 Jul 2002 08:23:05 -0400 (EDT)
Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp5.cluster.oleane.net with SMTP id g6ICN1U82512 for ; Thu, 18 Jul 2002 14:23:05 +0200 (CEST)
Message-ID: <007a01c22e57$14bda300$0701a8c0@oleane.com>
From: "Peter Lewis" 
To: 
Date: Thu, 18 Jul 2002 14:31:42 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0077_01C22E67.D5C100A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Length: 1558
Subject: [Simple] International SIP conference, Paris, third edition
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0077_01C22E67.D5C100A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

International SIP conference, Paris, third edition.
The principal worldwide SIP event will take place in Paris from 14 to 17 =
January 2003.
The call for proposals dead line has been postponed to August 21st.
Please get all details at:
http://www.upperside.fr/intersip03/sip03intro.htm




------=_NextPart_000_0077_01C22E67.D5C100A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











International SIP conference, Paris, third=20
edition.


The principal worldwide SIP event will take place in =
Paris=20
from 14 to 17 January 2003.


The call for proposals dead line has been postponed =
to August=20
21st.


Please get all details at:


http://www.upp=
erside.fr/intersip03/sip03intro.htm


 


 


 


------=_NextPart_000_0077_01C22E67.D5C100A0--


From aki.niemi@nokia.com  Thu Jul 18 10:28:05 2002
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 KAA15646
	for ; Thu, 18 Jul 2002 10:28:04 -0400 (EDT)
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.2.1/Switch-2.2.0) with ESMTP id g6IESai26759
	for ; Thu, 18 Jul 2002 17:28:36 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 18 Jul 2002 17:28:04 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 18 Jul 2002 17:28:03 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message session & associated dialog
Date: Thu, 18 Jul 2002 17:28:03 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED85@esebe013.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message session & associated dialog
Thread-Index: AcIuRYk1kaX8Dsf7SjGbZ0i7jYYhwQAIIeWQ
To: , 
Cc: , , ,
        
X-OriginalArrivalTime: 18 Jul 2002 14:28:04.0071 (UTC) FILETIME=[53B58770:01C22E67]
Content-Length: 517
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA15646
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: 

> I am certainly not an expert on RTP, but elaborating on the
> RTP stream / MESSAGE stream comparison:
> RTP services certainly include sequence numbering.

Much of the reason RTP would have sequence numbering probably lies in the fact that the underlying transport protocol (UDP) provides no guarantees on sequential delivery of packets.

However, TCP does, so the message-session would only need the CSeq in MESSAGE to sequence overlapping requests. As far as I know, this is currently not allowed. 
 
Cheers,
Aki

From bstucker@nortelnetworks.com  Thu Jul 18 14:09:53 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16330
	for ; Thu, 18 Jul 2002 14:09:53 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6IIA4Q13674;
	Thu, 18 Jul 2002 13:10:04 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 18 Jul 2002 13:09:49 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E04B470AE@zrc2c012.us.nortel.com>
From: "Brian Stucker" 
To: hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Comments on PUBLISH
Date: Thu, 18 Jul 2002 13:09:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C22E86.4DFCBE60"
Content-Length: 11750
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: 

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_01C22E86.4DFCBE60
Content-Type: text/plain;
	charset="iso-8859-1"

Comments embedded within...

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: Monday, July 08, 2002 7:43 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Comments on PUBLISH
> 
> 
> 1. The concept of Input slots seems a bit vague. Does a slot 
> represent entities that publish presence info of the same 
> type, eg: geographic location? i.e. All devices that publish 
> geographic location information fit into that slot? If so, 
> why is a use device not a GeoLoc entity?
> 
> A User device can publish geographic location information as 
> well as the user's availability for voice and IM, for 
> example. How do slots work in that scenario?
> 
> Also, how does a Presence Compositor know which publication 
> belongs to which slot?
> 
> Perhaps I miss understood this concept completely.

I'll let Jonathan answer that one..

> 
> 
> 2. Document assumes that all presence publication is achieved 
> using PUBLISH. That is not true. A example, as a matter of 
> fact, is the GeoLoc.

The idea here is that GeoLoc, if it so wished, could use the PUBLISH method
to update a presence server. I do not believe that the intent was to provide
EVERY way of publishing presence information via this draft, but a single,
standardizable approach that covers off as much ground as possible without
becoming overly complex. For instance, the compositor can still use
registration information to build the presence document. PUBLISH is simply
one tentacle feeding the octopus.

> 
> 3. PType header: If is described as useful for 2 things:
> 
> - the document that is being published is part of a larger 
> composite document. How does PType here help? If PType is 
> defined to be "mobile", how does that tell the compositor 
> that it belongs to a larger composite document? I would have 
> thought the presentity URI would be used for that purpose.
> 
> - The document that is being published will be applied to 
> many components of the composed document. Please give me an 
> example of this. I fail to understand how this could be done.
> 
> This is something for the PUBLISH body, not a SIP header.

The header is optional. Some compositor functions may want more information
about what to do with the message body,  where the contents of the message
body can't easily convey what is intended. You could put the CPIM-PIDF tuple
id here if you liked, or leave it totally off.

> 
> 4. PStream header: How does a header that looks like call-id 
> guarantees correct sequencing of messages? Header like Date, 
> and information in the message body seem like a much better 
> way of sequencing.

Let's say I have two devices, and they faithfully put the date header in, as
you suggest, but there's no easy way to figure out from the message content
that the PUBLISH messages from these two sources are, in fact, from two
sources. So, the result of that is to either require the clients to use the
same callid/tags and keep bumping up the CSeq (ala the weak/brittle solution
for REGISTER), or we give them an additional way to provide a token that the
compositor can track against to correlate that this set of PUBLISH messages
came from the same place, without getting into tag/callid mayhem.

> 
> 5. PState Header: why is it defined that way? why not 
> PExpires or just Expires?

A'la subscription-state. Expires is confusing. Does it mean when the message
itself expires, or the content of the message?

> 
> 6. I don't think its the PA who should decide how long a 
> PUBLISH is valid for. How is that possible? I publish from my 
> PC that's I'm available for IM for one hour, why would a PA 
> override that?

The PA is the repository of this information, and as such needs to control
how long it is responsible for such. You could apply the same logic to say
that a registrar shouldn't limit the amount of time that a contact is
registered for. If the client wants to stay registered for 137 years, then
so be it. Same goes for event subscriptions. A PUBLISH uses finite resources
at the compositor, therefore, the compositor should have final word in how
long it's willing to allow those resource to be used at one shot.

> 
> Regards,
> Hisham
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

------_=_NextPart_001_01C22E86.4DFCBE60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Comments on PUBLISH




Comments embedded within...




> -----Original Message-----

> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia=
.com]

> Sent: Monday, July 08, 2002 7:43 AM

> To: simple@mailman.dynamicsoft.com

> Subject: [Simple] Comments on PUBLISH

> 

> 

> 1. The concept of Input slots seems a bit =
vague. Does a slot 

> represent entities that publish presence info =
of the same 

> type, eg: geographic location? i.e. All devices =
that publish 

> geographic location information fit into that =
slot? If so, 

> why is a use device not a GeoLoc entity?

> 

> A User device can publish geographic location =
information as 

> well as the user's availability for voice and =
IM, for 

> example. How do slots work in that =
scenario?

> 

> Also, how does a Presence Compositor know which =
publication 

> belongs to which slot?

> 

> Perhaps I miss understood this concept =
completely.




I'll let Jonathan answer that one..




> 

> 

> 2. Document assumes that all presence =
publication is achieved 

> using PUBLISH. That is not true. A example, as =
a matter of 

> fact, is the GeoLoc.




The idea here is that GeoLoc, if it so wished, could =
use the PUBLISH method to update a presence server. I do not believe =
that the intent was to provide EVERY way of publishing presence =
information via this draft, but a single, standardizable approach that =
covers off as much ground as possible without becoming overly complex. =
For instance, the compositor can still use registration information to =
build the presence document. PUBLISH is simply one tentacle feeding the =
octopus.



> 

> 3. PType header: If is described as useful for =
2 things:

> 

> - the document that is being published is part =
of a larger 

> composite document. How does PType here help? =
If PType is 

> defined to be "mobile", how does that =
tell the compositor 

> that it belongs to a larger composite document? =
I would have 

> thought the presentity URI would be used for =
that purpose.

> 

> - The document that is being published will be =
applied to 

> many components of the composed document. =
Please give me an 

> example of this. I fail to understand how this =
could be done.

> 

> This is something for the PUBLISH body, not a =
SIP header.




The header is optional. Some compositor functions may =
want more information about what to do with the message body,  =
where the contents of the message body can't easily convey what is =
intended. You could put the CPIM-PIDF tuple id here if you liked, or =
leave it totally off.



> 

> 4. PStream header: How does a header that looks =
like call-id 

> guarantees correct sequencing of messages? =
Header like Date, 

> and information in the message body seem like a =
much better 

> way of sequencing.




Let's say I have two devices, and they faithfully put =
the date header in, as you suggest, but there's no easy way to figure =
out from the message content that the PUBLISH messages from these two =
sources are, in fact, from two sources. So, the result of that is to =
either require the clients to use the same callid/tags and keep bumping =
up the CSeq (ala the weak/brittle solution for REGISTER), or we give =
them an additional way to provide a token that the compositor can track =
against to correlate that this set of PUBLISH messages came from the =
same place, without getting into tag/callid mayhem.



> 

> 5. PState Header: why is it defined that way? =
why not 

> PExpires or just Expires?




A'la subscription-state. Expires is confusing. Does =
it mean when the message itself expires, or the content of the =
message?



> 

> 6. I don't think its the PA who should decide =
how long a 

> PUBLISH is valid for. How is that possible? I =
publish from my 

> PC that's I'm available for IM for one hour, =
why would a PA 

> override that?




The PA is the repository of this information, and as =
such needs to control how long it is responsible for such. You could =
apply the same logic to say that a registrar shouldn't limit the amount =
of time that a contact is registered for. If the client wants to stay =
registered for 137 years, then so be it. Same goes for event =
subscriptions. A PUBLISH uses finite resources at the compositor, =
therefore, the compositor should have final word in how long it's =
willing to allow those resource to be used at one shot.



> 

> Regards,

> Hisham

> =
_______________________________________________

> simple mailing list

> simple@mailman.dynamicsoft.com

> http://mailman.dynamicsoft.com/mailman/listinfo/simple=


> 





------_=_NextPart_001_01C22E86.4DFCBE60--

From jdrosen@dynamicsoft.com  Sun Jul 21 01:30:14 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26011
	for ; Sun, 21 Jul 2002 01:30:14 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.192])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6L5UCYH014701;
	Sun, 21 Jul 2002 01:30:12 -0400 (EDT)
Message-ID: <3D3A46E3.8020900@dynamicsoft.com>
Date: Sun, 21 Jul 2002 14:30:11 +0900
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com,
        mhammer@cisco.com, pkyzivat@cisco.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED85@esebe013.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2497
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: 

Before I comment on this point below, let me state outright that I do 
NOT believe that the MESSAGE requests exist in any dialog. THe only 
dialog in existence is the one through INVITE. It was my belief that the 
"media stream" in this case was a sequence of what effectively look like 
page mode requests. However, I would like to provide sequencing for 
them, and so CSeq is natural for that. In order to use CSeq, you must 
have a well defined scope in which they exist. I had merely indicated 
that this was a "dialog ID" - meaning the To-tag, From-tag, and call-id, 
which does not imply the existence of a dialog.

More below:

aki.niemi@nokia.com wrote:
>>I am certainly not an expert on RTP, but elaborating on the
>>RTP stream / MESSAGE stream comparison:
>>RTP services certainly include sequence numbering.
> 
> 
> Much of the reason RTP would have sequence numbering probably lies in
> the fact that the underlying transport protocol (UDP) provides no
> guarantees on sequential delivery of packets.
> 
> However, TCP does, so the message-session would only need the CSeq in
> MESSAGE to sequence overlapping requests. As far as I know, this is
> currently not allowed. 

With the existence of intermediary relays, you cannot guarantee 
end-to-end sequencing any longer.

However, it occurs to me that if the URI is the point of demux at the 
UAS, then the scope of the sequence numbers can be within that URI. In 
other words, each MESSAGE in the message media stream could (and 
probably should, thinking about this more) have a unique call-id. The 
cseq increment by one for each message sent by the originating UA. The 
UAS will provide a URI of sufficient uniqueness that it won't receive 
any messages at the URI except for ones sent by the originator. Thus, 
the cseq can provide ordering within the scope of the r-uri as seen by 
the UAS.


I think, however, we should focus on the bigger issue of whether this is 
really SIP, or whether we should go back to the older IMTP proposal. 
There was some debate on that during the meeting. I am still collecting 
thoughts on that, and welcome comments from others.

-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


From vpapageorgiou@dsl.pipex.com  Sun Jul 21 18:06:56 2002
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.190.223.73])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28768
	for ; Sun, 21 Jul 2002 18:06:55 -0400 (EDT)
Received: from vas (81-86-154-229.dsl.pipex.com [81.86.154.229])
	by colossus.systems.pipex.net (Postfix) with ESMTP id D04C916000340
	for ; Sun, 21 Jul 2002 23:06:53 +0100 (BST)
From: "Mr Vasilis Papageorgiou" 
To: 
Date: Sun, 21 Jul 2002 23:06:42 +0100
Message-ID: <000001c23102$e9349c30$0300a8c0@vas>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0001_01C2310B.4AF90430"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 6385
Subject: [Simple] SIMPLE / DynamicSoft Question
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C2310B.4AF90430
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Everybody.
 
I have couple of questions if you have couple of minutes to spare.
 
1.	Do the DymanicSoft products include/support the presence and
location extensions the SIMPLE group is working on?
2.	Are there any Open Source implementations that support the
SIMPLE draft extensions?
 
 
Thanks in advance for your time and help.
 
Regards
Mr Vasilis Papageorgiou

------=_NextPart_000_0001_01C2310B.4AF90430
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






















Hello =
Everybody…



 



I have couple of =
questions if
you have couple of minutes to spare.



 



    
 
  1. Do the DymanicSoft
     products include/support the presence and location extensions the =
SIMPLE
     group is working on?
    2. 
 
  2. Are there any Open Source =
implementations
     that support the SIMPLE draft =
extensions?
    3. 




 



 



Thanks in advance for =
your
time and help.



 



Regards



Mr Vasilis =
Papageorgiou









------=_NextPart_000_0001_01C2310B.4AF90430--



From hisham.khartabil@nokia.com  Mon Jul 22 05:42:47 2002
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 FAA00436
	for ; Mon, 22 Jul 2002 05:42:46 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6M9hIi16094
	for ; Mon, 22 Jul 2002 12:43:19 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 22 Jul 2002 12:42:45 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 22 Jul 2002 12:42:45 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Mon, 22 Jul 2002 12:42:44 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203EA@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] -05 MESSAGE and Expires header
Thread-Index: AcIuBY6OLe/FTntMQLS13f5W+xX2owDWtAdg
To: , 
Cc: , , ,
        , 
X-OriginalArrivalTime: 22 Jul 2002 09:42:45.0589 (UTC) FILETIME=[21F37850:01C23164]
Content-Length: 6247
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA00436
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: 


> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, July 18, 2002 5:25 AM
> To: Adam Roach
> Cc: Ben Campbell; Bobby Sardana; Vijay K. Gurbani; Tan 
> Ya-Ching ICMN PG
> U ID A 1; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] -05 MESSAGE and Expires header
> 
> 
> Expires is method specific, since its precise interpretation 
> is method 
> specific. The general notion is that it indicates a lifetime of 
> something; a point after which the thing is no longer valid. I think 
> that this more genearl definition is an exact match to our need here, 
> and the current Expires text is an appropriate instantiation 
> of it for 
> MESSAGE.


How do you interpret "the thing is no longer valid" to mean immediate delivery?

In 3261, it says about Priority header "For example, it may be factored into decisions about call routing and acceptance". So, if you want your message to be delivered immediately, you are playing with the routing, hence Priority header.

Message saying "Leaving for lunch now" with Expires 0 to me says that this message expires immediately (just like a SUBSCRIBE with expires 0 means this subscription expires immediately), not that it requires immediate delivery. It also means "don't bother replying, I've left already".

I think using expires for routing decisions is a hack.

The questions are: 

- Is Priority header used for user interface purposes only, or for routing decisions as well?
- When is a message urgent but does not require immediate delivery?

If I need the business presentation by 10pm and its 7am, then the message does not require immediate delivery nor is it urgent, but if its 9:55pm, then its urgent and certainly needs immediate delivery.

Regards,
Hisham


> 
> I believe that priority is quite different. A message can be for 
> immediate delivery, and be either urgent ("my house is on 
> fire") or not 
> ("leaving now for lunch"). A message can be OK for storage (some 
> non-zero expires) and be urgent ("I need that business 
> presentation by 
> 10pm!") or non-urgent ("Did you see that movie"). The fact that two 
> things can be used orthogonally is a sign that they are, in fact, two 
> different things.
> 
> I strongly support keeping Expires as currently defined.
> 
> -Jonathan R.
> 
> Adam Roach wrote:
> > Personally, I think the "Expires" handling is sufficient
> > and unambiguious.
> > 
> > The use of "Priority" would be inappropriate. High priority
> > items don't necessarily have a high urgency -- and what you're
> > trying to communicate here is urgency, not priority.
> > 
> > However, I'd take a different tact: this is really a disposition
> > for the message.
> > 
> > In the final equasion, though, I think it's all a moot point,
> > since "Expires: 0" works just fine.
> > 
> > /a
> > 
> > 
> >>-----Original Message-----
> >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> >>Sent: Tuesday, July 16, 2002 18:24
> >>To: Bobby Sardana
> >>Cc: Vijay K. Gurbani; Tan Ya-Ching ICM N PG U ID A 1;
> >>simple@mailman.dynamicsoft.com
> >>Subject: Re: [Simple] -05 MESSAGE and Expires header
> >>
> >>
> >>So, for all that have commented on this thread, is the 
> description of 
> >>Expires in RFC 3261 sufficient? If so, we can fix this by simply 
> >>dropping the sentence about "Expires:0".
> >>
> >>Or do you think the MESSAGE draft needs to contain additional 
> >>language 
> >>concerning "Priority"?
> >>
> >>Bobby Sardana wrote:
> >>
> >>>I'll cast my vote for the Priority header. Expires: 0 
> >>
> >>somehow implies 
> >>
> >>>that the message needs to be dropped.
> >>>
> >>>regards,
> >>>
> >>>Bobby Sardana.
> >>>dsardana@seven.com
> >>>
> >>>Ben Campbell wrote:
> >>>
> >>>
> >>>>Vijay K. Gurbani wrote:
> >>>>
> >>>>>Tan Ya-Ching ICM N PG U ID A 1 wrote:
> >>>>>
> >>>>>
> >>>>>>Vijay,
> >>>>>>
> >>>>>>It is stated in RFC 3261 section 20.19 Expires that :
> >>>>>>"The precise meaning of this (header) is method dependant".
> >>>>>
> >>>>>
> >>>>>Agreed.
> >>>>>
> >>>>>
> >>>>>>The use of the Expires header in MESSAGE is as it is 
> >>>>>
> >>defined in -05.
> >>
> >>>>>>It has
> >>>>>>only one meaning, so there is no overloading.
> >>>>>
> >>>>>
> >>>>>That is debatable; good thing about ASCII protocols is 
> >>>>
> >>that they are
> >>
> >>>>>self describing.  Thus, having a "Priority: Urgent" is far more
> >>>>>preferable to overloading "Expires: 0" to mean immediate 
> >>>>
> >>handling.
> >>
> >>>>>"Priority: Urgent" in this case makes it far more easy to figure
> >>>>>out what is going on.
> >>>>>
> >>>>>- vijay
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>I do not have strong feelings on this one way or another--either
> >>>>approach works for me. I will bow to the will of the 
> >>>
> >>majority. Anyone
> >>
> >>>>else have comments?
> >>>>
> >>>>_______________________________________________
> >>>>simple mailing list
> >>>>simple@mailman.dynamicsoft.com
> >>>>http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >>>>
> >>>
> >>>-- 
> >>>___________________________ 
> >>>
> >>>Bobby Sardana |  SEVEN 
> >>>Software Engineer, Engineering  
> >>>___________________________ 
> >>>
> >>>901 Marshall St.
> >>>Redwood City, CA 94063
> >>>650.381.2535 (v)
> >>>650.216.6455 (f)
> >>>dsardana@seven.com
> >>>www.seven.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
> > 
> 
> 
> -- 
> ---
> 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 hisham.khartabil@nokia.com  Mon Jul 22 06:09:47 2002
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 GAA00565
	for ; Mon, 22 Jul 2002 06:09:46 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MAAJi03436
	for ; Mon, 22 Jul 2002 13:10:19 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 22 Jul 2002 13:09:46 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 22 Jul 2002 13:09:46 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Comments on PUBLISH
Date: Mon, 22 Jul 2002 13:09:45 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203EB@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Comments on PUBLISH
Thread-Index: AcIuhuB9iLdv0batQyayM6X6fL+tCwC3f99A
To: , 
X-OriginalArrivalTime: 22 Jul 2002 10:09:46.0054 (UTC) FILETIME=[E7D2CE60:01C23167]
Content-Length: 3178
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA00565
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: 

-----Original Message-----
From: ext Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Thursday, July 18, 2002 9:10 PM
To: Khartabil Hisham (NMP/Helsinki); simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Comments on PUBLISH


Comments embedded within... 
> -----Original Message----- 
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] 
> Sent: Monday, July 08, 2002 7:43 AM 
> To: simple@mailman.dynamicsoft.com 
> Subject: [Simple] Comments on PUBLISH 
> 
> 

> 
>> 4. PStream header: How does a header that looks like call-id 
>> guarantees correct sequencing of messages? Header like Date, 
>> and information in the message body seem like a much better 
>> way of sequencing. 
>Let's say I have two devices, and they faithfully put the date header in, as you suggest, but there's no easy way to figure out from the message content that the PUBLISH messages from these two
>sources are, in fact, from two sources. So, the result of that is to either require the clients to use the same callid/tags and keep bumping up the CSeq (ala the weak/brittle solution for
>REGISTER), or we give them an additional way to provide a token that the compositor can track against to correlate that this set of PUBLISH messages came from the same place, without getting into 
>tag/callid mayhem.
>

if a publisher has to remember the value of the PSteam header and still use CSeq for sequencing, then its the same weak/brittle solution. You might as well use the call-id header and save yourself the bandwidth. If the PSteam header carried a sequence number of its own, then I can understand its purpose, but I still think that this information is better carried in the body.

 
>> 5. PState Header: why is it defined that way? why not 
>> PExpires or just Expires? 
>A'la subscription-state. Expires is confusing. Does it mean when the message itself expires, or the content of the message?

This is what the PUBLISH draft has to document. Expires is method dependent as we all know.

> 
>> 6. I don't think its the PA who should decide how long a 
>> PUBLISH is valid for. How is that possible? I publish from my 
>> PC that's I'm available for IM for one hour, why would a PA 
>> override that? 
>The PA is the repository of this information, and as such needs to control how long it is responsible for such. You could apply the same logic to say that a registrar shouldn't limit the amount of >time that a contact is registered for. If the client wants to stay registered for 137 years, then so be it. Same goes for event subscriptions. A PUBLISH uses finite resources at the compositor,
>therefore, the compositor should have final word in how long it's willing to allow those resource to be used at one shot.

Ok, why is it a MUST then? How does the compositor tell the publisher that this publication is valid until you update it if the compositor doesn't care about how long the PUBLISH is valid for. Is Expires-header mandatory in PUBLISH request? If so, why?

Regards, 
Hisham 
> _______________________________________________ 
> simple mailing list 
> simple@mailman.dynamicsoft.com 
> http://mailman.dynamicsoft.com/mailman/listinfo/simple 
> 

From hisham.khartabil@nokia.com  Mon Jul 22 06:34:33 2002
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 GAA00683
	for ; Mon, 22 Jul 2002 06:34:32 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MAZ4i20559
	for ; Mon, 22 Jul 2002 13:35:05 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 22 Jul 2002 13:34:31 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 22 Jul 2002 13:34:31 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message session & associated dialog
Date: Mon, 22 Jul 2002 13:34:30 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203EC@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message session & associated dialog
Thread-Index: AcIsBC+bxZCahR/nQzK182k523SIOAFZg3hw
To: , 
Cc: , 
X-OriginalArrivalTime: 22 Jul 2002 10:34:31.0657 (UTC) FILETIME=[5D4FD590:01C2316B]
Content-Length: 2931
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA00683
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: 

Forget for a second that instant message inside a session use sip. To instantiate a session for any type of media, it being voice, video, white board, etc, we use INVITE. Now think of IM as another media, INVITE would be used for that too.

It just happens that the protocol used to carry the instant messages in this case is SIP, just like RTP is used to carry audio. They are not related to signalling.

Continuing to compare RTP and SIP as the media carrying protocol. The port identified in SDP is the one that is used to group the packets, so it being RTP or SIP is irrelevant. If, during signalling in the INVITE, you indicate that audio packets are received on port 45123 and IM packets are received on port 45130, then there is no need to create a dialog to group the packets. You can  just use the port.

To sequencing, CSeq is enough in this case since IMs are grouped together because they are received on the same port (you can replace 'port' with 'socket' if you wish.

Regards,
Hisham

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, July 15, 2002 4:27 PM
> To: Jonathan Rosenberg
> Cc: Peter Päppinghaus; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Message session & associated dialog
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > > draft-rosenberg-simple-message-session-00 is silent about 
> construction
> > > of Call-ID and From and To header tags in the MESSAGE 
> requests sent
> > > within a message session.
> > 
> > Well, the draft was just a proposal.
> > 
> > I guess the messages would all use the same dialog ID, with 
> increasing
> > CSeq within the dialog. Different dialog ID than the INVITE 
> one, of course.
> 
> It makes sense that all the messages share a dialog. The 
> question is: what causes this dialog to be established?
> 
> There are currently two ways of establishing a dialog:
> 
> - the 2xx reply to an INVITE can establish one
> 
> - the 2xx reply to a SUBSCRIBE can establish one
> 
> In the case we are discussing, MESSAGE requests are the only 
> thing being sent along the path where we want a dialog. But 
> we don't want the response to every MESSAGE request
> to establish a dialog. Some possibilities:
> 
> - send a medialess INVITE to establish a dialog, and then 
> send the MESSAGEs within that dialog.
> 
> - permit the recipient of a MESSAGE to decide contextually 
> whether to establish a dialog. (Would require some rules to 
> prevent doing so when all the flow control
> constraints haven't been met.)
> 
> Sending another INVITE is straightforward, but seems a bit 
> circuitous and wasteful of round trips. But using the MESSAGE 
> to do this may lead to a blurring of the
> distinction between page and session mode messaging.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From adam@dynamicsoft.com  Mon Jul 22 09:50:50 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01318
	for ; Mon, 22 Jul 2002 09:50:50 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6MDoSCU001960;
	Mon, 22 Jul 2002 09:50:28 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <306APZSW>; Mon, 22 Jul 2002 08:50:46 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A2EC@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'hisham.khartabil@nokia.com'" ,
        Jonathan Rosenberg ,
        Adam Roach
	 
Cc: Ben Campbell , dsardana@seven.com,
        vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Mon, 22 Jul 2002 08:50:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 812
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: 

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> - When is a message urgent but does not require immediate delivery?

Are you proposing an "Urgency" header, or confusing priority with
urgency? I'll see if I can accurately demonstrate their orthangonality.

High Priority, Low Urgency:
  Note to new residents: failure to file income taxes by April
  15th can lead to substantial penalties.

Low Priority, High Urgency:
  You have 5 minutes to come by and pick up the rest of your lunch
  or I'm going to throw it away.
                             
High Priority, High Urgency:
  There's a tornado coming your way!

Low Priority, Low Urgency:
  Llamas can make four distinct noises: humming, clucking, orgling, and
  a high pitched, rhythmic alarm sound.

/a

From pkyzivat@cisco.com  Mon Jul 22 09:52:07 2002
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 JAA01344
	for ; Mon, 22 Jul 2002 09:52:07 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6MDqW4V027038;
	Mon, 22 Jul 2002 09:52:33 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN62727;
	Mon, 22 Jul 2002 09:56:39 -0400 (EDT)
Message-ID: <3D3C0DFD.CC504B1@cisco.com>
Date: Mon, 22 Jul 2002 09:51:57 -0400
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: aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de,
        bcampbell@dynamicsoft.com, mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED85@esebe013.NOE.Nokia.com> <3D3A46E3.8020900@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2577
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: 


Jonathan Rosenberg wrote:
> 
> Before I comment on this point below, let me state outright that I do
> NOT believe that the MESSAGE requests exist in any dialog. THe only
> dialog in existence is the one through INVITE. It was my belief that the
> "media stream" in this case was a sequence of what effectively look like
> page mode requests.

Good! 

It was my (mis)interpretation that you were suggesting otherwise that set off this thread.

> However, I would like to provide sequencing for
> them, and so CSeq is natural for that. In order to use CSeq, you must
> have a well defined scope in which they exist. I had merely indicated
> that this was a "dialog ID" - meaning the To-tag, From-tag, and call-id,
> which does not imply the existence of a dialog.

I'm unconfortable with using "dialog ID" without there being a dialog. I can't at the moment give a solid reason why this is wrong, but it feels like an abuse.

> However, it occurs to me that if the URI is the point of demux at the
> UAS, then the scope of the sequence numbers can be within that URI. In
> other words, each MESSAGE in the message media stream could (and
> probably should, thinking about this more) have a unique call-id. The
> cseq increment by one for each message sent by the originating UA. The
> UAS will provide a URI of sufficient uniqueness that it won't receive
> any messages at the URI except for ones sent by the originator. Thus,
> the cseq can provide ordering within the scope of the r-uri as seen by
> the UAS.

If we continue the analogy with RTP streams, then this seems like a bad assumption. In the case of RTP, we never assume that all the packets arrive from the same source.
This can be violated in many cases, such as when transferring a call, where one sender is replaced by another, but the receiver remains invariant.

Why can't we rely on the message content to provide ordering, and the reliablility of the transport to guarantee delivery? Of course text content won't provide ordering,
but that will provide more encouragement to use CPIM. 

> 
> I think, however, we should focus on the bigger issue of whether this is
> really SIP, or whether we should go back to the older IMTP proposal.
> There was some debate on that during the meeting. I am still collecting
> thoughts on that, and welcome comments from others.

Given a choice between SIP and something that is "almost-SIP" or an "extended-subset-of-SIP", I would choose SIP. If its not going to be SIP, then lets have something that
does exactly what it needs to do in the simplest possible way.

	Paul

From kpatil@sta.samsung.com  Wed Jul 17 20:09:45 2002
Received: from stamail.telecom.sna.samsung.com (mail1.sta.samsung.com [63.166.115.3])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13066
	for ; Wed, 17 Jul 2002 20:09:45 -0400 (EDT)
Received: by stamail.telecom.sna.samsung.com with Internet Mail Service (5.5.2653.19)
	id <37042X1A>; Wed, 17 Jul 2002 19:14:18 -0500
Message-ID: <4B9386E83999D411997100508BAF206A061F4FC3@stamail.telecom.sna.samsung.com>
From: Kedar Patil 
To: "'simple@mailman.dynamicsoft.com'" 
Date: Wed, 17 Jul 2002 19:14:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C22DF0.0B573220"
Content-Length: 2582
Subject: [Simple] Presence : Content-Length header field value
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: 

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_01C22DF0.0B573220
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

I need some clarification about what Content-Length header
field value can be.

Documnet : draft-ietf-simple-presence-07.txt
Section : 8. Example message flow
Page : 18

=======================================================
When the value of the Content-Length header is "..." this means that
the value should be whatever the computed length of the body is.
=======================================================

In the first reading, this statement indicates that the string
"..." (thre dots) is a valid Content-Length header field value.
Co-incidentally, the examples that follow in that section also
seems to be supporting this interpretation :)

Please let me know, if this interpretation is correct.

thanks,
= Kedar =

------_=_NextPart_001_01C22DF0.0B573220
Content-Type: text/html;
	charset="iso-8859-1"






Presence : Content-Length header field value




Hi,




I need some clarification about what Content-Length header

field value can be.




Documnet : draft-ietf-simple-presence-07.txt

Section : 8. Example message flow

Page : 18




=======================================================

When the value of the Content-Length header is "..." this means that

the value should be whatever the computed length of the body is.

=======================================================




In the first reading, this statement indicates that the string

"..." (thre dots) is a valid Content-Length header field value.

Co-incidentally, the examples that follow in that section also

seems to be supporting this interpretation :)




Please let me know, if this interpretation is correct.




thanks,

= Kedar =





------_=_NextPart_001_01C22DF0.0B573220--

From hisham.khartabil@nokia.com  Mon Jul 22 10:08:22 2002
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 KAA01553
	for ; Mon, 22 Jul 2002 10:08:21 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6ME8si00879
	for ; Mon, 22 Jul 2002 17:08:54 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 22 Jul 2002 17:08:21 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 22 Jul 2002 17:08:21 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Mon, 22 Jul 2002 17:08:20 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203EF@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] -05 MESSAGE and Expires header
Thread-Index: AcIxhs9NeUFT/gDIQDWcRgiqq6iZqAAALEkw
To: , 
Cc: , , ,
        , 
X-OriginalArrivalTime: 22 Jul 2002 14:08:21.0129 (UTC) FILETIME=[3C45E790:01C23189]
Content-Length: 1456
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA01553
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: 

Well, you read my mind. I wanted to get consensus that Priority header is for user interface purposes only before I do so.

Should we do something like that or are these issues part of the ieprep work?

Regards,
Hisham

> -----Original Message-----
> From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Monday, July 22, 2002 4:51 PM
> To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach
> Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com;
> Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] -05 MESSAGE and Expires header
> 
> 
> > -----Original Message-----
> > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> > - When is a message urgent but does not require immediate delivery?
> 
> Are you proposing an "Urgency" header, or confusing priority with
> urgency? I'll see if I can accurately demonstrate their 
> orthangonality.
> 
> High Priority, Low Urgency:
>   Note to new residents: failure to file income taxes by April
>   15th can lead to substantial penalties.
> 
> Low Priority, High Urgency:
>   You have 5 minutes to come by and pick up the rest of your lunch
>   or I'm going to throw it away.
>                              
> High Priority, High Urgency:
>   There's a tornado coming your way!
> 
> Low Priority, Low Urgency:
>   Llamas can make four distinct noises: humming, clucking, 
> orgling, and
>   a high pitched, rhythmic alarm sound.
> 
> /a
> 

From hisham.khartabil@nokia.com  Mon Jul 22 10:15:34 2002
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 KAA01620
	for ; Mon, 22 Jul 2002 10:15:33 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6MEG7i04587
	for ; Mon, 22 Jul 2002 17:16:07 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 22 Jul 2002 17:15:34 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 22 Jul 2002 17:15:34 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Presence : Content-Length header field value
Date: Mon, 22 Jul 2002 17:15:33 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203F0@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Presence : Content-Length header field value
Thread-Index: AcIxiNvU9MBpBGm0S0K8cLRG97ba5gAALefA
To: , 
X-OriginalArrivalTime: 22 Jul 2002 14:15:34.0206 (UTC) FILETIME=[3E6835E0:01C2318A]
Content-Length: 1124
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA01620
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: 

"..." means the author had better things to do that count the number of bytes in the body. So to answer your question: No, its not allowed.

Regards,
Hisham


-----Original Message-----
From: ext Kedar Patil [mailto:kpatil@sta.samsung.com]
Sent: Thursday, July 18, 2002 3:14 AM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] Presence : Content-Length header field value


Hi, 
I need some clarification about what Content-Length header 
field value can be. 
Documnet : draft-ietf-simple-presence-07.txt 
Section : 8. Example message flow 
Page : 18 
======================================================= 
When the value of the Content-Length header is "..." this means that 
the value should be whatever the computed length of the body is. 
======================================================= 
In the first reading, this statement indicates that the string 
"..." (thre dots) is a valid Content-Length header field value. 
Co-incidentally, the examples that follow in that section also 
seems to be supporting this interpretation :) 
Please let me know, if this interpretation is correct. 
thanks, 
= Kedar = 

From vkg@lucent.com  Mon Jul 22 10:31:40 2002
Received: from auemail1.firewall.lucent.com ([192.11.223.161])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01775
	for ; Mon, 22 Jul 2002 10:31:39 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6MEUxH09409;
	Mon, 22 Jul 2002 10:30:59 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id JAA04158; Mon, 22 Jul 2002 09:29:37 -0500 (CDT)
Message-ID: <3D3C16A8.6060900@lucent.com>
Date: Mon, 22 Jul 2002 09:28:56 -0500
From: "Vijay K. Gurbani" 
Organization: Lucent Technologies, Inc./Bell Laboratories
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: adam@dynamicsoft.com, jdrosen@dynamicsoft.com, bcampbell@dynamicsoft.com,
        dsardana@seven.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <2038BCC78B1AD641891A0D1AE133DBB7C203EF@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 931
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: 

hisham.khartabil@nokia.com wrote:
> Well, you read my mind. I wanted to get consensus that Priority header 
> is for user interface purposes only before I do so.

RFC 2076 says this about Priority:

3.9 Quality information

    Can be "normal", "urgent" or "non-   Priority:      RFC 1327, not for
    urgent" and can influence                           general usage.
    transmission speed and delivery.

Which leads me to believe that it may *not* be for UI purposes only.

> Should we do something like that or are these issues part of the ieprep 
> work?

Good question; especially in view of the IEPREP discussion at the
SIPPING WG meeting in Yokohama...

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216


From bcampbell@dynamicsoft.com  Mon Jul 22 12:14:30 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02217
	for ; Mon, 22 Jul 2002 12:14:29 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MGEJhZ059224;
	Mon, 22 Jul 2002 11:14:20 -0500 (CDT)
Message-ID: <3D3C2F4E.5010300@dynamicsoft.com>
Date: Mon, 22 Jul 2002 11:14:06 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: jdrosen@dynamicsoft.com, adam@dynamicsoft.com, dsardana@seven.com,
        vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <2038BCC78B1AD641891A0D1AE133DBB7C203EA@esebe019.NOE.Nokia.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3024
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: 

hisham.khartabil@nokia.com wrote:
> 
>>-----Original Message-----
>>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>>Sent: Thursday, July 18, 2002 5:25 AM
>>To: Adam Roach
>>Cc: Ben Campbell; Bobby Sardana; Vijay K. Gurbani; Tan 
>>Ya-Ching ICMN PG
>>U ID A 1; simple@mailman.dynamicsoft.com
>>Subject: Re: [Simple] -05 MESSAGE and Expires header
>>
>>
>>Expires is method specific, since its precise interpretation 
>>is method 
>>specific. The general notion is that it indicates a lifetime of 
>>something; a point after which the thing is no longer valid. I think 
>>that this more genearl definition is an exact match to our need here, 
>>and the current Expires text is an appropriate instantiation 
>>of it for 
>>MESSAGE.
> 
> 
> 
> How do you interpret "the thing is no longer valid" to mean immediate delivery?

It is a bit of a stretch, but not a _big_ stretch. I interpret to mean 
that the message is highly perishable.

> 
> In 3261, it says about Priority header "For example, it may be factored into decisions about call routing and acceptance". So, if you want your message to be delivered immediately, you are playing with the routing, hence Priority header.
> 
> Message saying "Leaving for lunch now" with Expires 0 to me says that this message expires immediately (just like a SUBSCRIBE with expires 0 means this subscription expires immediately), not that it requires immediate delivery. It also means "don't bother replying, I've left already".
> 
> I think using expires for routing decisions is a hack.
> 
> The questions are: 
> 
> - Is Priority header used for user interface purposes only, or for routing decisions as well?

Priority can be used for routing decisions. But, as mentioned in the 
meeting, it should be interpreted as how high a priority the message has 
compared to _other_ messages. In the trivial case, where only one 
message is being processed, priority is meaningless.

> - When is a message urgent but does not require immediate delivery?

Let me step back and paint a broader picture: A store and forward device 
receives a message with Expires:0. It obviously wants to deliver the 
message immediately, but what if it can't? It should then treat the 
message as stale. What does it do with stale messages? That is a matter 
of local policy. But one perfectly reasonable option is to simply drop 
it on the floor.

Now, that behavior makes no sense at all for a high priority message. 
The server wants to deliver that one quickly, but if it can't do so, it 
still needs to ensure the message gets delivered. That is _not_ the 
behavior we are looking for.

For example, my boss might send me a message containing important 
information for a presentation I am to give tomorrow. It is not 
important that I get the message immediately, since the presentation is 
not until tomorrow. It is, however, important that I actuall _get_ the 
message, and that when I look at my queue of a thousand messages, I 
realize that this one is important for me to read.





From bcampbell@dynamicsoft.com  Mon Jul 22 12:16:17 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02238
	for ; Mon, 22 Jul 2002 12:16:17 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MGG9hZ059311;
	Mon, 22 Jul 2002 11:16:09 -0500 (CDT)
Message-ID: <3D3C2FBC.1090205@dynamicsoft.com>
Date: Mon, 22 Jul 2002 11:15:56 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: adam@dynamicsoft.com, jdrosen@dynamicsoft.com, dsardana@seven.com,
        vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <2038BCC78B1AD641891A0D1AE133DBB7C203EF@esebe019.NOE.Nokia.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1646
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: 

hisham.khartabil@nokia.com wrote:
> Well, you read my mind. I wanted to get consensus that Priority header is for user interface purposes only before I do so.

As I mentioned in a separate mail, priority _can_ be used for routing 
purposes. But it means something different than urgency.

> 
> Should we do something like that or are these issues part of the ieprep work?
> 
> Regards,
> Hisham
> 
> 
>>-----Original Message-----
>>From: ext Adam Roach [mailto:adam@dynamicsoft.com]
>>Sent: Monday, July 22, 2002 4:51 PM
>>To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach
>>Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com;
>>Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com
>>Subject: RE: [Simple] -05 MESSAGE and Expires header
>>
>>
>>
>>>-----Original Message-----
>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
>>>- When is a message urgent but does not require immediate delivery?
>>
>>Are you proposing an "Urgency" header, or confusing priority with
>>urgency? I'll see if I can accurately demonstrate their 
>>orthangonality.
>>
>>High Priority, Low Urgency:
>>  Note to new residents: failure to file income taxes by April
>>  15th can lead to substantial penalties.
>>
>>Low Priority, High Urgency:
>>  You have 5 minutes to come by and pick up the rest of your lunch
>>  or I'm going to throw it away.
>>                             
>>High Priority, High Urgency:
>>  There's a tornado coming your way!
>>
>>Low Priority, Low Urgency:
>>  Llamas can make four distinct noises: humming, clucking, 
>>orgling, and
>>  a high pitched, rhythmic alarm sound.
>>
>>/a
>>
> 
> 




From bcampbell@dynamicsoft.com  Mon Jul 22 12:23:32 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02318
	for ; Mon, 22 Jul 2002 12:23:31 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MGNVhZ059899;
	Mon, 22 Jul 2002 11:23:32 -0500 (CDT)
Message-ID: <3D3C3174.7050507@dynamicsoft.com>
Date: Mon, 22 Jul 2002 11:23:16 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kedar Patil 
CC: "'simple@mailman.dynamicsoft.com'" 
Subject: Re: [Simple] Presence : Content-Length header field value
References: <4B9386E83999D411997100508BAF206A061F4FC3@stamail.telecom.sna.samsung.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1209
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: 

Kedar Patil wrote:
> Hi,
> 
> I need some clarification about what Content-Length header
> field value can be.
> 
> Documnet : draft-ietf-simple-presence-07.txt
> Section : 8. Example message flow
> Page : 18
> 
> =======================================================
> When the value of the Content-Length header is "..." this means that
> the value should be whatever the computed length of the body is.
> =======================================================
> 
> In the first reading, this statement indicates that the string
> "..." (thre dots) is a valid Content-Length header field value.
> Co-incidentally, the examples that follow in that section also
> seems to be supporting this interpretation :)
> 
> Please let me know, if this interpretation is correct.
> 
> thanks,
> = Kedar =
> 

No, it is not. I believe the "..." is simply a documentation convention 
that means, "in a real message, there would be a real value here." That 
is, it is a rather tedious task to make sure the content-length headers 
are correct in example flows, and the editor chose not to do it.

A real message would be generated by a machine, which generally do not 
find counting octets to be quite so tedious :-)



From bcampbell@dynamicsoft.com  Mon Jul 22 12:30:13 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02393
	for ; Mon, 22 Jul 2002 12:30:12 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6MGUChZ060419;
	Mon, 22 Jul 2002 11:30:13 -0500 (CDT)
Message-ID: <3D3C3307.9040605@dynamicsoft.com>
Date: Mon, 22 Jul 2002 11:29:59 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian Stucker 
CC: hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Comments on PUBLISH
References: <933FADF5E673D411B8A30002A5608A0E04B470AE@zrc2c012.us.nortel.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 5315
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: 

Brian Stucker wrote:
> Comments embedded within...
> 
>  > -----Original Message-----
>  > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
>  > Sent: Monday, July 08, 2002 7:43 AM
>  > To: simple@mailman.dynamicsoft.com
>  > Subject: [Simple] Comments on PUBLISH
>  >
>  >
>  > 1. The concept of Input slots seems a bit vague. Does a slot
>  > represent entities that publish presence info of the same
>  > type, eg: geographic location? i.e. All devices that publish
>  > geographic location information fit into that slot? If so,
>  > why is a use device not a GeoLoc entity?
>  >
>  > A User device can publish geographic location information as
>  > well as the user's availability for voice and IM, for
>  > example. How do slots work in that scenario?
>  >
>  > Also, how does a Presence Compositor know which publication
>  > belongs to which slot?
>  >
>  > Perhaps I miss understood this concept completely.
> 
> I'll let Jonathan answer that one..

I'm not Jonathan, nor do I play him on TV--but I will jump in anyway: 
Isn't that what the proposed ptype header is for?


> 
>  >
>  >
>  > 2. Document assumes that all presence publication is achieved
>  > using PUBLISH. That is not true. A example, as a matter of
>  > fact, is the GeoLoc.
> 
> The idea here is that GeoLoc, if it so wished, could use the PUBLISH 
> method to update a presence server. I do not believe that the intent was 
> to provide EVERY way of publishing presence information via this draft, 
> but a single, standardizable approach that covers off as much ground as 
> possible without becoming overly complex. For instance, the compositor 
> can still use registration information to build the presence document. 
> PUBLISH is simply one tentacle feeding the octopus.

Certainly, the compositor is not limited to using PUBLISH. We are just 
not in the business of standardizing all methods a compositor can choose 
to use. The compositor might periodically query a geoloc server. Or 
maybe someone builds a geoloc server to PUBLISH adapter. As long as the 
compositor has enough information to make policy decisions on how to 
compose the input, it could be anything.

> 
>  >
>  > 3. PType header: If is described as useful for 2 things:
>  >
>  > - the document that is being published is part of a larger
>  > composite document. How does PType here help? If PType is
>  > defined to be "mobile", how does that tell the compositor
>  > that it belongs to a larger composite document? I would have
>  > thought the presentity URI would be used for that purpose.

The compositor decides whether the input should be composed or not, 
based on it's local policy for the "mobile" slot.

>  >
>  > - The document that is being published will be applied to
>  > many components of the composed document. Please give me an
>  > example of this. I fail to understand how this could be done.
>  >
>  > This is something for the PUBLISH body, not a SIP header.
> 
> The header is optional. Some compositor functions may want more 
> information about what to do with the message body,  where the contents 
> of the message body can't easily convey what is intended. You could put 
> the CPIM-PIDF tuple id here if you liked, or leave it totally off.
> 
>  >
>  > 4. PStream header: How does a header that looks like call-id
>  > guarantees correct sequencing of messages? Header like Date,
>  > and information in the message body seem like a much better
>  > way of sequencing.
> 
> Let's say I have two devices, and they faithfully put the date header 
> in, as you suggest, but there's no easy way to figure out from the 
> message content that the PUBLISH messages from these two sources are, in 
> fact, from two sources. So, the result of that is to either require the 
> clients to use the same callid/tags and keep bumping up the CSeq (ala 
> the weak/brittle solution for REGISTER), or we give them an additional 
> way to provide a token that the compositor can track against to 
> correlate that this set of PUBLISH messages came from the same place, 
> without getting into tag/callid mayhem.
> 
>  >
>  > 5. PState Header: why is it defined that way? why not
>  > PExpires or just Expires?
> 
> A'la subscription-state. Expires is confusing. Does it mean when the 
> message itself expires, or the content of the message?
> 
>  >
>  > 6. I don't think its the PA who should decide how long a
>  > PUBLISH is valid for. How is that possible? I publish from my
>  > PC that's I'm available for IM for one hour, why would a PA
>  > override that?
> 
> The PA is the repository of this information, and as such needs to 
> control how long it is responsible for such. You could apply the same 
> logic to say that a registrar shouldn't limit the amount of time that a 
> contact is registered for. If the client wants to stay registered for 
> 137 years, then so be it. Same goes for event subscriptions. A PUBLISH 
> uses finite resources at the compositor, therefore, the compositor 
> should have final word in how long it's willing to allow those resource 
> to be used at one shot.
> 
>  >
>  > Regards,
>  > Hisham
>  > _______________________________________________
>  > simple mailing list
>  > simple@mailman.dynamicsoft.com
>  > http://mailman.dynamicsoft.com/mailman/listinfo/simple
>  >
> 




From rsparks@dynamicsoft.com  Mon Jul 22 18:16:39 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03452
	for ; Mon, 22 Jul 2002 18:16:38 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6MGQO123602;
	Mon, 22 Jul 2002 11:26:26 -0500
Subject: Re: [Simple] Presence : Content-Length header field value
From: Robert Sparks 
To: Kedar Patil 
Cc: "'simple@mailman.dynamicsoft.com'" 
In-Reply-To: 
	<4B9386E83999D411997100508BAF206A061F4FC3@stamail.telecom.sna.samsung.com>
References: 
	<4B9386E83999D411997100508BAF206A061F4FC3@stamail.telecom.sna.samsung.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 23 Jul 2002 07:10:12 +0900
Message-Id: <1027375815.10985.26.camel@dhcp26.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 1111
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: 

No. "..." is only an editorial convention used in the document.
A message on the wire must have an integer value equal to
the number of octets in the body. The body starts after the
null line at the end of the headers. See rfc3261 if you need
more detail.

RjS

On Thu, 2002-07-18 at 09:14, Kedar Patil wrote:
> Hi, 
> 
> I need some clarification about what Content-Length header 
> field value can be. 
> 
> Documnet : draft-ietf-simple-presence-07.txt 
> Section : 8. Example message flow 
> Page : 18 
> 
> ======================================================= 
> When the value of the Content-Length header is "..." this means that 
> the value should be whatever the computed length of the body is. 
> ======================================================= 
> 
> In the first reading, this statement indicates that the string 
> "..." (thre dots) is a valid Content-Length header field value. 
> Co-incidentally, the examples that follow in that section also 
> seems to be supporting this interpretation :) 
> 
> Please let me know, if this interpretation is correct. 
> 
> thanks, 
> = Kedar = 
> 



From jundery@ubiquity.net  Tue Jul 23 03:52:12 2002
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id DAA05010
	for ; Tue, 23 Jul 2002 03:52:11 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 23 Jul 2002 07:52:33 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 23 Jul 2002 08:52:54 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE018C23D4@GBNEWP0758M.eu.ubiquity.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Message Transport Protocol (SIP vs IMTP)
Thread-Index: AcIyHfPFtloBi+BNRIOOsdn4jKRWpA==
From: "James Undery" 
To: "SIMPLE (E-mail)" 
Content-Length: 797
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA05010
Subject: [Simple] Message Transport Protocol (SIP vs IMTP)
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: 

Hi,

At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree with) was to take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft.

James

From hisham.khartabil@nokia.com  Tue Jul 23 04:43:29 2002
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 EAA05235
	for ; Tue, 23 Jul 2002 04:43:28 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6N8i2i13195
	for ; Tue, 23 Jul 2002 11:44:02 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 23 Jul 2002 11:43:29 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 23 Jul 2002 11:43:28 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Tue, 23 Jul 2002 11:43:27 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C203F7@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Message Transport Protocol (SIP vs IMTP)
Thread-Index: AcIyHfPFtloBi+BNRIOOsdn4jKRWpAABvFsA
To: , 
X-OriginalArrivalTime: 23 Jul 2002 08:43:28.0935 (UTC) FILETIME=[046EE370:01C23225]
Content-Length: 1322
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA05235
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: 

And how many of those RFC2543 complaint proxies will you see deployed in a year's time?

/Hisham

> -----Original Message-----
> From: ext James Undery [mailto:jundery@ubiquity.net]
> Sent: Tuesday, July 23, 2002 10:53 AM
> To: SIMPLE (E-mail)
> Subject: [Simple] Message Transport Protocol (SIP vs IMTP)
> 
> 
> Hi,
> 
> At the SIMPLE meeting I believe the consensus was to go with 
> a SIP based message transport, however, it was unclear if 
> this should be SIP or IMTP. The argument for SIP is because 
> of rfc3261 we can now use SIP as is, IMTP was complicated due 
> to all the requirements of messaging that couldn't be 
> addressed easily; I'd definitely agree with that, however, I 
> believe that won't work, rfc2543 proxies may still do all the 
> bad things IMTP was designed to avoid. The suggestion made by 
> Rohan (that I strongly agree with) was to take  rfc3261 and 
> just swap SIP/2.0 for IMTP/1.0 every time the protocol is 
> mentioned in the spec. This has the advantage that you know 
> older proxies aren't going to misbehave and the draft 
> specifying it should be trivial modification to Jonathan's 
> latest draft.
> 
> James
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jundery@ubiquity.net  Tue Jul 23 05:30:14 2002
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA05432
	for ; Tue, 23 Jul 2002 05:30:14 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 23 Jul 2002 09:30:36 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Tue, 23 Jul 2002 10:30:58 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE018C23D6@GBNEWP0758M.eu.ubiquity.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Message Transport Protocol (SIP vs IMTP)
Thread-Index: AcIyHfPFtloBi+BNRIOOsdn4jKRWpAABvFsAAAE/+xA=
From: "James Undery" 
To: , 
Content-Length: 2070
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA05432
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: 

There are also other advantages. If it is clear that IMTP is different from SIP this allows more targeted filtering just like SOAP RPC calls over HTTP don't ;-) (Note the much touted firewall avoidance power of SOAP over HTTP is considered a bad thing by the security community, IM is less of a concern but helping administrative policies to be enforced surely is good)

James

P.S. More than one which is all that matters.

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: 23 July 2002 09:43
> To: James Undery; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
> 
> 
> And how many of those RFC2543 complaint proxies will you see 
> deployed in a year's time?
> 
> /Hisham
> 
> > -----Original Message-----
> > From: ext James Undery [mailto:jundery@ubiquity.net]
> > Sent: Tuesday, July 23, 2002 10:53 AM
> > To: SIMPLE (E-mail)
> > Subject: [Simple] Message Transport Protocol (SIP vs IMTP)
> > 
> > 
> > Hi,
> > 
> > At the SIMPLE meeting I believe the consensus was to go with 
> > a SIP based message transport, however, it was unclear if 
> > this should be SIP or IMTP. The argument for SIP is because 
> > of rfc3261 we can now use SIP as is, IMTP was complicated due 
> > to all the requirements of messaging that couldn't be 
> > addressed easily; I'd definitely agree with that, however, I 
> > believe that won't work, rfc2543 proxies may still do all the 
> > bad things IMTP was designed to avoid. The suggestion made by 
> > Rohan (that I strongly agree with) was to take  rfc3261 and 
> > just swap SIP/2.0 for IMTP/1.0 every time the protocol is 
> > mentioned in the spec. This has the advantage that you know 
> > older proxies aren't going to misbehave and the draft 
> > specifying it should be trivial modification to Jonathan's 
> > latest draft.
> > 
> > James
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 

From pkyzivat@cisco.com  Tue Jul 23 09:09:11 2002
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 JAA06172
	for ; Tue, 23 Jul 2002 09:09:11 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6ND9jA9004560;
	Tue, 23 Jul 2002 09:09:46 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN69924;
	Tue, 23 Jul 2002 09:13:52 -0400 (EDT)
Message-ID: <3D3D5576.B3229C5D@cisco.com>
Date: Tue, 23 Jul 2002 09:09:10 -0400
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: James Undery 
CC: "SIMPLE (E-mail)" 
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
References: <45730E094814E44488F789C1CDED27AE018C23D4@GBNEWP0758M.eu.ubiquity.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1032
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: 


James Undery wrote:
> 
> Hi,
> 
> At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree with) was to take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft.

To avoid misbehaving proxies, shouldn't it be sufficient to do something like

	Proxy-Require: message_session

or something to that effect? Changing the version requires much more mucking in the stack.

	Paul

From jundery@ubiquity.net  Tue Jul 23 09:28:03 2002
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA06267
	for ; Tue, 23 Jul 2002 09:28:02 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 23 Jul 2002 13:28:26 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Tue, 23 Jul 2002 14:28:47 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE018C23D9@GBNEWP0758M.eu.ubiquity.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message Transport Protocol (SIP vs IMTP)
Thread-Index: AcIySj8sS3kZ06lIQaiAkXCKTJvFewAAXHtg
From: "James Undery" 
To: "Paul Kyzivat" 
Cc: "SIMPLE (E-mail)" 
Content-Length: 1469
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA06267
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: 


> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]

> James Undery wrote:
> > 
> > Hi,
> > 
> > At the SIMPLE meeting I believe the consensus was to go 
> with a SIP based message transport, however, it was unclear 
> if this should be SIP or IMTP. The argument for SIP is 
> because of rfc3261 we can now use SIP as is, IMTP was 
> complicated due to all the requirements of messaging that 
> couldn't be addressed easily; I'd definitely agree with that, 
> however, I believe that won't work, rfc2543 proxies may still 
> do all the bad things IMTP was designed to avoid. The 
> suggestion made by Rohan (that I strongly agree with) was to 
> take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time 
> the protocol is mentioned in the spec. This has the advantage 
> that you know older proxies aren't going to misbehave and the 
> draft specifying it should be trivial modification to 
> Jonathan's latest draft.
> 
> To avoid misbehaving proxies, shouldn't it be sufficient to 
> do something like
> 
> 	Proxy-Require: message_session
> 
> or something to that effect? Changing the version requires 
> much more mucking in the stack.

This is really an implementation's flexibility issue. In soem implementations changing the Protocol can allow for greater efficiency in application servers where modules handle headers like Proxy-Requires. I wouldn't have a problem with Proxy-Require it'd just be nice to think it through.

James

From sriramp@nortelnetworks.com  Tue Jul 23 10:55:08 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06640
	for ; Tue, 23 Jul 2002 10:55:07 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6NEt0d01362;
	Tue, 23 Jul 2002 09:55:00 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 23 Jul 2002 09:54:46 -0500
Message-ID: 
From: "Sriram Parameswar" 
To: "'Paul Kyzivat'" ,
        James Undery
	 
Cc: "SIMPLE (E-mail)" 
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Tue, 23 Jul 2002 09:54:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C23258.DDCE2260"
Content-Length: 5451
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: 

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_01C23258.DDCE2260
Content-Type: text/plain;
	charset="iso-8859-1"

Wouldn't a 'Proxy-Require: message_session' cause the proxy to send back a
420 Bad Extension? Is this the behavior we want? After all we want the IM
Session to succeed in most cases.

Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Tuesday, July 23, 2002 8:09 AM
To: James Undery
Cc: SIMPLE (E-mail)
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)




James Undery wrote:
> 
> Hi,
> 
> At the SIMPLE meeting I believe the consensus was to go with a SIP based
message transport, however, it was unclear if this should be SIP or IMTP.
The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP
was complicated due to all the requirements of messaging that couldn't be
addressed easily; I'd definitely agree with that, however, I believe that
won't work, rfc2543 proxies may still do all the bad things IMTP was
designed to avoid. The suggestion made by Rohan (that I strongly agree with)
was to take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the
protocol is mentioned in the spec. This has the advantage that you know
older proxies aren't going to misbehave and the draft specifying it should
be trivial modification to Jonathan's latest draft.

To avoid misbehaving proxies, shouldn't it be sufficient to do something
like

	Proxy-Require: message_session

or something to that effect? Changing the version requires much more mucking
in the stack.

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

------_=_NextPart_001_01C23258.DDCE2260
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Message Transport Protocol (SIP vs IMTP)




Wouldn't a 'Proxy-Require: message_session' cause the =
proxy to send back a 420 Bad Extension? Is this the behavior we want? =
After all we want the IM Session to succeed in most cases.



Regards,




Sriram




__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-684-3986

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com






-----Original Message-----

From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=


Sent: Tuesday, July 23, 2002 8:09 AM

To: James Undery

Cc: SIMPLE (E-mail)

Subject: Re: [Simple] Message Transport Protocol =
(SIP vs IMTP)










James Undery wrote:

> 

> Hi,

> 

> At the SIMPLE meeting I believe the consensus =
was to go with a SIP based message transport, however, it was unclear =
if this should be SIP or IMTP. The argument for SIP is because of =
rfc3261 we can now use SIP as is, IMTP was complicated due to all the =
requirements of messaging that couldn't be addressed easily; I'd =
definitely agree with that, however, I believe that won't work, rfc2543 =
proxies may still do all the bad things IMTP was designed to avoid. The =
suggestion made by Rohan (that I strongly agree with) was to take  =
rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is =
mentioned in the spec. This has the advantage that you know older =
proxies aren't going to misbehave and the draft specifying it should be =
trivial modification to Jonathan's latest draft.



To avoid misbehaving proxies, shouldn't it be =
sufficient to do something like




        Proxy-Require: message_session




or something to that effect? Changing the version =
requires much more mucking in the stack.




        Paul

_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple=






------_=_NextPart_001_01C23258.DDCE2260--

From pkyzivat@cisco.com  Tue Jul 23 11:18:01 2002
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 LAA06743
	for ; Tue, 23 Jul 2002 11:18:00 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6NFIX2T020434;
	Tue, 23 Jul 2002 11:18:33 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN71211;
	Tue, 23 Jul 2002 11:22:41 -0400 (EDT)
Message-ID: <3D3D73A7.F250C48E@cisco.com>
Date: Tue, 23 Jul 2002 11:17:59 -0400
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: Sriram Parameswar 
CC: James Undery ,
        "SIMPLE (E-mail)" 
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2363
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: 

This would require use of proxies that support my hypothetical "message_session" extension. That extension would require use of the rfc 3261 features, and could otherwise
be empty. If you like, we could make it "Proxy-Require: rfc3261".

Any proxy supporting 3261 should be able to comply, and the whole point is to exclude those that don't. If you get a 420 back, then the message stream path was incorrectly
defined.

	Paul

> Sriram Parameswar wrote:
> 
> Wouldn't a 'Proxy-Require: message_session' cause the proxy to send back a 420 Bad Extension? Is this the behavior we want? After all we want the IM Session to succeed in
> most cases.
> 
> Regards,
> 
> Sriram
> 
> __________________________________________
> Sriram Parameswar              Phone: 972-685-8540
> Interactive Multimedia Server (IMS) Fax: 972-684-3986
> Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, July 23, 2002 8:09 AM
> To: James Undery
> Cc: SIMPLE (E-mail)
> Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
> 
> James Undery wrote:
> >
> > Hi,
> >
> > At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP
> is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with
> that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree
> with) was to take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't
> going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft.
> 
> To avoid misbehaving proxies, shouldn't it be sufficient to do something like
> 
>         Proxy-Require: message_session
> 
> or something to that effect? Changing the version requires much more mucking in the stack.
> 
>         Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From seancolson@yahoo.com  Tue Jul 23 11:32:45 2002
Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA06832
	for ; Tue, 23 Jul 2002 11:32:44 -0400 (EDT)
Received: from 12-235-154-217.client.attbi.com (HELO BOB) (seancolson@12.235.154.217 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Jul 2002 15:32:44 -0000
Reply-To: 
From: "Sean Olson" 
To: "'Sriram Parameswar'" ,
        "'Paul Kyzivat'" ,
        "'James Undery'" 
Cc: "'SIMPLE \(E-mail\)'" 
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Tue, 23 Jul 2002 08:32:45 -0700
Message-ID: <003601c2325e$31fdb3a0$6401a8c0@BOB>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0037_01C23223.85A06240"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: 
Content-Length: 8636
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0037_01C23223.85A06240
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I don't see the benefits of using IMTP as a protocol identifier in this
case. In fact, I think it negates
some of the benefits of using SIP as the underlying protocol altogether.
What you really want in this case
is MESSAGE-specific behavior. Or did people have the notion of sending
something other than MESSAGE
in this "IMTP" transport? I really dislike the notion of receiving a 420
in this situation. Because a session
was explicitly established with a policy to route MESSAGEs through some
set of intermediaries, it seems
a bit odd that these intermediaries wouldn't be able to handle MESSAGE
(or for that matter, loose routing
if needed)
 
/sean

-----Original Message-----
From: simple-admin@mailman.dynamicsoft.com
[mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Sriram
Parameswar
Sent: Tuesday, July 23, 2002 7:55 AM
To: 'Paul Kyzivat'; James Undery
Cc: SIMPLE (E-mail)
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)



Wouldn't a 'Proxy-Require: message_session' cause the proxy to send back
a 420 Bad Extension? Is this the behavior we want? After all we want the
IM Session to succeed in most cases.

Regards, 

Sriram 

__________________________________________ 
Sriram Parameswar              Phone: 972-685-8540 
Interactive Multimedia Server (IMS) Fax: 972-684-3986 
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com 


-----Original Message----- 
From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
Sent: Tuesday, July 23, 2002 8:09 AM 
To: James Undery 
Cc: SIMPLE (E-mail) 
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) 




James Undery wrote: 
> 
> Hi, 
> 
> At the SIMPLE meeting I believe the consensus was to go with a SIP
based message transport, however, it was unclear if this should be SIP
or IMTP. The argument for SIP is because of rfc3261 we can now use SIP
as is, IMTP was complicated due to all the requirements of messaging
that couldn't be addressed easily; I'd definitely agree with that,
however, I believe that won't work, rfc2543 proxies may still do all the
bad things IMTP was designed to avoid. The suggestion made by Rohan
(that I strongly agree with) was to take  rfc3261 and just swap SIP/2.0
for IMTP/1.0 every time the protocol is mentioned in the spec. This has
the advantage that you know older proxies aren't going to misbehave and
the draft specifying it should be trivial modification to Jonathan's
latest draft.

To avoid misbehaving proxies, shouldn't it be sufficient to do something
like 

        Proxy-Require: message_session 

or something to that effect? Changing the version requires much more
mucking in the stack. 

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


------=_NextPart_000_0037_01C23223.85A06240
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




Message




I =
don't see the=20
benefits of using IMTP as a protocol identifier in this case. In =
fact, I=20
think it negates


some of the=20
benefits of using SIP as the underlying protocol altogether. What you =
really=20
want in this case


is=20
MESSAGE-specific behavior. Or did people have the notion of sending =
something=20
other than MESSAGE


in =
this "IMTP"=20
transport? I really dislike the notion of receiving a 420 in this =
situation.=20
Because a session


was =
explicitly=20
established with a policy to route MESSAGEs through some set of =
intermediaries,=20
it seems


a =
bit odd that=20
these intermediaries wouldn't be able to handle MESSAGE (or for that =
matter,=20
loose routing


if=20
needed)


 


/sean



  

  
-----Original Message-----
From:=20
  simple-admin@mailman.dynamicsoft.com=20
  [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of =
Sriram=20
  Parameswar
Sent: Tuesday, July 23, 2002 7:55 =
AM
To: 'Paul=20
  Kyzivat'; James Undery
Cc: SIMPLE =
(E-mail)
Subject: RE:=20
  [Simple] Message Transport Protocol (SIP vs IMTP)


  
Wouldn't a 'Proxy-Require: message_session' cause =
the proxy to=20
  send back a 420 Bad Extension? Is this the behavior we want? After all =
we want=20
  the IM Session to succeed in most cases.

  
Regards, 

  
Sriram 

  
__________________________________________ =

Sriram=20
  =
Parameswar          &nb=
sp;  =20
  Phone: 972-685-8540 
Interactive Multimedia =
Server=20
  (IMS) Fax: 972-684-3986 
Nortel Networks, =
Richardson=20
  USA  Email: sriramp@nortelnetworks.com 


  
-----Original Message----- 
From: Paul=20
  Kyzivat [mailto:pkyzivat@cisco.com] =

  
Sent: Tuesday, July 23, 2002 8:09 AM =

To: James Undery 
Cc: SIMPLE =
(E-mail)=20
  
Subject: Re: [Simple] Message Transport Protocol =
(SIP vs=20
  IMTP) 




  
James Undery wrote: 
>=20
  
> Hi, 
> =

> At the SIMPLE meeting I believe the consensus was to go =
with a SIP=20
  based message transport, however, it was unclear if this should be SIP =
or=20
  IMTP. The argument for SIP is because of rfc3261 we can now use SIP as =
is,=20
  IMTP was complicated due to all the requirements of messaging that =
couldn't be=20
  addressed easily; I'd definitely agree with that, however, I believe =
that=20
  won't work, rfc2543 proxies may still do all the bad things IMTP was =
designed=20
  to avoid. The suggestion made by Rohan (that I strongly agree with) =
was to=20
  take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the =
protocol=20
  is mentioned in the spec. This has the advantage that you know older =
proxies=20
  aren't going to misbehave and the draft specifying it should be =
trivial=20
  modification to Jonathan's latest draft.

  
To avoid misbehaving proxies, shouldn't it be =
sufficient to do=20
  something like 

  
        Proxy-Require:=20
  message_session 

  
or something to that effect? Changing the version =
requires=20
  much more mucking in the stack. 

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


------=_NextPart_000_0037_01C23223.85A06240--


From jundery@ubiquity.net  Tue Jul 23 11:46:53 2002
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA06906
	for ; Tue, 23 Jul 2002 11:46:52 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 23 Jul 2002 15:47:14 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Tue, 23 Jul 2002 16:47:36 +0100
Message-ID: <45730E094814E44488F789C1CDED27AE018C23DC@GBNEWP0758M.eu.ubiquity.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message Transport Protocol (SIP vs IMTP)
Thread-Index: AcIyXkwY1rPdpyapSN2UFPJKA7luPwAAec3g
From: "James Undery" 
To: 
Cc: "SIMPLE (E-mail)" 
Content-Length: 3682
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA06906
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: 

I think you may be missing the point of this. The reason for not using SIP originally was the worry IM would be used to transfer huge files such as mp3s. To counter this Jonathan created a cut down version of SIP called IMTP, once loose routing and TCP requirements were introduced into the bis spec this cut down version wasn't required. The crunch is it's obviously still required for non 3261 entities to prevent UDP and old Record Route nastiness occurring. Proxy-Require, new Protocol or some other solution something needs to be done.

James

P.S. If rfc2543 proxies are a non-issue can't we just deprecate UDP while we're at it ;-)


-----Original Message-----
From: Sean Olson [mailto:seancolson@yahoo.com]
Sent: 23 July 2002 16:33
To: 'Sriram Parameswar'; 'Paul Kyzivat'; James Undery
Cc: 'SIMPLE (E-mail)'
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)


I don't see the benefits of using IMTP as a protocol identifier in this case. In fact, I think it negates
some of the benefits of using SIP as the underlying protocol altogether. What you really want in this case
is MESSAGE-specific behavior. Or did people have the notion of sending something other than MESSAGE
in this "IMTP" transport? I really dislike the notion of receiving a 420 in this situation. Because a session
was explicitly established with a policy to route MESSAGEs through some set of intermediaries, it seems
a bit odd that these intermediaries wouldn't be able to handle MESSAGE (or for that matter, loose routing
if needed)

/sean
-----Original Message-----
From: simple-admin@mailman.dynamicsoft.com [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Sriram Parameswar
Sent: Tuesday, July 23, 2002 7:55 AM
To: 'Paul Kyzivat'; James Undery
Cc: SIMPLE (E-mail)
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)


Wouldn't a 'Proxy-Require: message_session' cause the proxy to send back a 420 Bad Extension? Is this the behavior we want? After all we want the IM Session to succeed in most cases.
Regards, 
Sriram 
__________________________________________ 
Sriram Parameswar              Phone: 972-685-8540 
Interactive Multimedia Server (IMS) Fax: 972-684-3986 
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com 


-----Original Message----- 
From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
Sent: Tuesday, July 23, 2002 8:09 AM 
To: James Undery 
Cc: SIMPLE (E-mail) 
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) 




James Undery wrote: 
> 
> Hi, 
> 
> At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree with) was to take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft.
To avoid misbehaving proxies, shouldn't it be sufficient to do something like 
        Proxy-Require: message_session 
or something to that effect? Changing the version requires much more mucking in the stack. 
        Paul 
_______________________________________________ 
simple mailing list 
simple@mailman.dynamicsoft.com 
http://mailman.dynamicsoft.com/mailman/listinfo/simple 

From seancolson@yahoo.com  Tue Jul 23 12:39:08 2002
Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA07149
	for ; Tue, 23 Jul 2002 12:39:08 -0400 (EDT)
Message-ID: <20020723163908.50599.qmail@web11607.mail.yahoo.com>
Received: from [131.107.3.79] by web11607.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 09:39:08 PDT
Date: Tue, 23 Jul 2002 09:39:08 -0700 (PDT)
From: Sean Olson 
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
To: James Undery 
Cc: "SIMPLE \(E-mail\)" 
In-Reply-To: <45730E094814E44488F789C1CDED27AE018C23DC@GBNEWP0758M.eu.ubiquity.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 5326
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: 

Actually, I completely understand the point
of the original IMTP proposal :) And BTW,
calling it IMTP does *NOTHING* to fix these problems.
(By this, I mean changing the protocol identifier to
IMTP)

Sure, you can define a new profile for SIP, label
it IMTP and assume everything goes well. 
But let's be honest. Calling it IMTP will NOT 
stop people from sending large files via IM. It
will NOT solve the congestion control problem.
It will NOT allow you to magically work with non-3261
entities. 

I'm not claiming that 2543 proxies are a non-issue.
I am claiming that you can't take a 2543 proxy out
of the box and run IMTP or any other new profile of
SIP through it. If you want to support "IMTP"
(or whatever we label it), you are going to have to
do some work. I don't think it's unreasonable to 
make 3261 compliance part of that work. You can
still route the INVITE for the message session through
the older 2543 proxies, you will just need something
new for the "media". 

/sean

P.S. While I'm the last person to admit, I think UDP
for SIP is on its deathbed ;-)

--- James Undery  wrote:
> 
> I think you may be missing the point of this. The
> reason for not using SIP originally was the worry IM
> would be used to transfer huge files such as mp3s.
> To counter this Jonathan created a cut down version
> of SIP called IMTP, once loose routing and TCP
> requirements were introduced into the bis spec this
> cut down version wasn't required. The crunch is it's
> obviously still required for non 3261 entities to
> prevent UDP and old Record Route nastiness
> occurring. Proxy-Require, new Protocol or some other
> solution something needs to be done.
> 
> James
> 
> P.S. If rfc2543 proxies are a non-issue can't we
> just deprecate UDP while we're at it ;-)
> 
> 
> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> Sent: 23 July 2002 16:33
> To: 'Sriram Parameswar'; 'Paul Kyzivat'; James
> Undery
> Cc: 'SIMPLE (E-mail)'
> Subject: RE: [Simple] Message Transport Protocol
> (SIP vs IMTP)
> 
> 
> I don't see the benefits of using IMTP as a protocol
> identifier in this case. In fact, I think it negates
> some of the benefits of using SIP as the underlying
> protocol altogether. What you really want in this
> case
> is MESSAGE-specific behavior. Or did people have the
> notion of sending something other than MESSAGE
> in this "IMTP" transport? I really dislike the
> notion of receiving a 420 in this situation. Because
> a session
> was explicitly established with a policy to route
> MESSAGEs through some set of intermediaries, it
> seems
> a bit odd that these intermediaries wouldn't be able
> to handle MESSAGE (or for that matter, loose routing
> if needed)
> 
> /sean
> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com] On
> Behalf Of Sriram Parameswar
> Sent: Tuesday, July 23, 2002 7:55 AM
> To: 'Paul Kyzivat'; James Undery
> Cc: SIMPLE (E-mail)
> Subject: RE: [Simple] Message Transport Protocol
> (SIP vs IMTP)
> 
> 
> Wouldn't a 'Proxy-Require: message_session' cause
> the proxy to send back a 420 Bad Extension? Is this
> the behavior we want? After all we want the IM
> Session to succeed in most cases.
> Regards, 
> Sriram 
> __________________________________________ 
> Sriram Parameswar              Phone: 972-685-8540 
> Interactive Multimedia Server (IMS) Fax:
> 972-684-3986 
> Nortel Networks, Richardson USA  Email:
> sriramp@nortelnetworks.com 
> 
> 
> -----Original Message----- 
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: Tuesday, July 23, 2002 8:09 AM 
> To: James Undery 
> Cc: SIMPLE (E-mail) 
> Subject: Re: [Simple] Message Transport Protocol
> (SIP vs IMTP) 
> 
> 
> 
> 
> James Undery wrote: 
> > 
> > Hi, 
> > 
> > At the SIMPLE meeting I believe the consensus was
> to go with a SIP based message transport, however,
> it was unclear if this should be SIP or IMTP. The
> argument for SIP is because of rfc3261 we can now
> use SIP as is, IMTP was complicated due to all the
> requirements of messaging that couldn't be addressed
> easily; I'd definitely agree with that, however, I
> believe that won't work, rfc2543 proxies may still
> do all the bad things IMTP was designed to avoid.
> The suggestion made by Rohan (that I strongly agree
> with) was to take  rfc3261 and just swap SIP/2.0 for
> IMTP/1.0 every time the protocol is mentioned in the
> spec. This has the advantage that you know older
> proxies aren't going to misbehave and the draft
> specifying it should be trivial modification to
> Jonathan's latest draft.
> To avoid misbehaving proxies, shouldn't it be
> sufficient to do something like 
>         Proxy-Require: message_session 
> or something to that effect? Changing the version
> requires much more mucking in the stack. 
>         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


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

From pkyzivat@cisco.com  Tue Jul 23 13:20:34 2002
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 NAA07307
	for ; Tue, 23 Jul 2002 13:20:34 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6NHL7qR010021;
	Tue, 23 Jul 2002 13:21:08 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN72351;
	Tue, 23 Jul 2002 13:25:14 -0400 (EDT)
Message-ID: <3D3D9060.381B578D@cisco.com>
Date: Tue, 23 Jul 2002 13:20:32 -0400
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: Sean Olson 
CC: James Undery ,
        "SIMPLE (E-mail)" 
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
References: <20020723163908.50599.qmail@web11607.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 836
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: 

Sean Olson wrote:
> 
> I'm not claiming that 2543 proxies are a non-issue.
> I am claiming that you can't take a 2543 proxy out
> of the box and run IMTP or any other new profile of
> SIP through it. If you want to support "IMTP"
> (or whatever we label it), you are going to have to
> do some work. I don't think it's unreasonable to
> make 3261 compliance part of that work. You can
> still route the INVITE for the message session through
> the older 2543 proxies, you will just need something
> new for the "media".

I'm not sure I get your point - I suspect we are in violent agreement.

Is anyone arguing that you don't need something new for message sessions? If all you currently have is 2543 based, then of course you do. But it would be nice if the only
new thing you needed was a path through 3261 compatible proxies.

	Paul

From seancolson@yahoo.com  Tue Jul 23 13:35:01 2002
Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA07390
	for ; Tue, 23 Jul 2002 13:35:01 -0400 (EDT)
Message-ID: <20020723173500.65101.qmail@web11608.mail.yahoo.com>
Received: from [207.46.225.252] by web11608.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 10:35:00 PDT
Date: Tue, 23 Jul 2002 10:35:00 -0700 (PDT)
From: Sean Olson 
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
To: Paul Kyzivat 
Cc: James Undery ,
        "SIMPLE \(E-mail\)" 
In-Reply-To: <3D3D9060.381B578D@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1450
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: 

I think we are saying the same thing then.
The one (I believe small) difference of opinion
I have with Rohan's proposal is that I don't
think we should call this IMTP. I think it should
be labelled "SIP/2.0"

/sean

--- Paul Kyzivat  wrote:
> Sean Olson wrote:
> > 
> > I'm not claiming that 2543 proxies are a
> non-issue.
> > I am claiming that you can't take a 2543 proxy out
> > of the box and run IMTP or any other new profile
> of
> > SIP through it. If you want to support "IMTP"
> > (or whatever we label it), you are going to have
> to
> > do some work. I don't think it's unreasonable to
> > make 3261 compliance part of that work. You can
> > still route the INVITE for the message session
> through
> > the older 2543 proxies, you will just need
> something
> > new for the "media".
> 
> I'm not sure I get your point - I suspect we are in
> violent agreement.
> 
> Is anyone arguing that you don't need something new
> for message sessions? If all you currently have is
> 2543 based, then of course you do. But it would be
> nice if the only
> new thing you needed was a path through 3261
> compatible proxies.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

From pkyzivat@cisco.com  Tue Jul 23 13:58:35 2002
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 NAA07505
	for ; Tue, 23 Jul 2002 13:58:35 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6NHx9ZP014319;
	Tue, 23 Jul 2002 13:59:09 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN72708;
	Tue, 23 Jul 2002 14:03:17 -0400 (EDT)
Message-ID: <3D3D994B.17125D4F@cisco.com>
Date: Tue, 23 Jul 2002 13:58:35 -0400
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: Sean Olson 
CC: James Undery ,
        "SIMPLE (E-mail)" 
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
References: <20020723173500.65101.qmail@web11608.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2357
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: 

Sean Olson wrote:
> 
> I think we are saying the same thing then.
> The one (I believe small) difference of opinion
> I have with Rohan's proposal is that I don't
> think we should call this IMTP. I think it should
> be labelled "SIP/2.0"

Well (sorry Rohan) I don't like that much either. To support it I have to hack every proxy to accept either "SIP/2.0" or "IMTP/1.0", remember it, and put it into responses.
This is a pretty invasive change to the stack. If I have a 3261 compatible stack, it ought to be easier than that. Hence my suggestion for Proxy-Require - it has exactly
the right semantics: proxies that don't support it are supposed to complain. And the hooks to handle it should be easy in most stacks.

(Of course non-compliant stacks could ignore it. But they could ignore the version too. You can't protect against all forms of stupidity.)

	Paul


> 
> /sean
> 
> --- Paul Kyzivat  wrote:
> > Sean Olson wrote:
> > >
> > > I'm not claiming that 2543 proxies are a
> > non-issue.
> > > I am claiming that you can't take a 2543 proxy out
> > > of the box and run IMTP or any other new profile
> > of
> > > SIP through it. If you want to support "IMTP"
> > > (or whatever we label it), you are going to have
> > to
> > > do some work. I don't think it's unreasonable to
> > > make 3261 compliance part of that work. You can
> > > still route the INVITE for the message session
> > through
> > > the older 2543 proxies, you will just need
> > something
> > > new for the "media".
> >
> > I'm not sure I get your point - I suspect we are in
> > violent agreement.
> >
> > Is anyone arguing that you don't need something new
> > for message sessions? If all you currently have is
> > 2543 based, then of course you do. But it would be
> > nice if the only
> > new thing you needed was a path through 3261
> > compatible proxies.
> >
> >       Paul
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From rsparks@dynamicsoft.com  Tue Jul 23 15:47:32 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07844
	for ; Tue, 23 Jul 2002 15:47:32 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6NDvG123994;
	Tue, 23 Jul 2002 08:57:16 -0500
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
From: Robert Sparks 
To: Paul Kyzivat 
Cc: Sean Olson , James Undery ,
        "SIMPLE (E-mail)" 
In-Reply-To: <3D3D994B.17125D4F@cisco.com>
References: <20020723173500.65101.qmail@web11608.mail.yahoo.com> 
	<3D3D994B.17125D4F@cisco.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 23 Jul 2002 14:47:11 -0500
Message-Id: <1027453632.1314.42.camel@dhcp26.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 3399
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: 


I'm a little confused about this whole discussion.

The mechanism described in
draft-rosenberg-simple-message-sessions-00.txt
uses information collected in the INVITE to build
a route set that is used as as preloaded route in
each message in the session.

This preloaded route is going to contain only
elements that will process these MESSAGE requests
in a congestion-safe fashion. (Otherwise, somebody
violated the protocol).

So, why is it we're wringing our hands over one of
these hitting a 2543 proxy?

IMHO, this is a non-issue and our time would be 
better spent inspecting and improving on the mechanism
in the draft for collecting that preloaded route.

RjS


On Tue, 2002-07-23 at 12:58, Paul Kyzivat wrote:
> Sean Olson wrote:
> > 
> > I think we are saying the same thing then.
> > The one (I believe small) difference of opinion
> > I have with Rohan's proposal is that I don't
> > think we should call this IMTP. I think it should
> > be labelled "SIP/2.0"
> 
> Well (sorry Rohan) I don't like that much either. To support it I have to hack every proxy to accept either "SIP/2.0" or "IMTP/1.0", remember it, and put it into responses.
> This is a pretty invasive change to the stack. If I have a 3261 compatible stack, it ought to be easier than that. Hence my suggestion for Proxy-Require - it has exactly
> the right semantics: proxies that don't support it are supposed to complain. And the hooks to handle it should be easy in most stacks.
> 
> (Of course non-compliant stacks could ignore it. But they could ignore the version too. You can't protect against all forms of stupidity.)
> 
> 	Paul
> 
> 
> > 
> > /sean
> > 
> > --- Paul Kyzivat  wrote:
> > > Sean Olson wrote:
> > > >
> > > > I'm not claiming that 2543 proxies are a
> > > non-issue.
> > > > I am claiming that you can't take a 2543 proxy out
> > > > of the box and run IMTP or any other new profile
> > > of
> > > > SIP through it. If you want to support "IMTP"
> > > > (or whatever we label it), you are going to have
> > > to
> > > > do some work. I don't think it's unreasonable to
> > > > make 3261 compliance part of that work. You can
> > > > still route the INVITE for the message session
> > > through
> > > > the older 2543 proxies, you will just need
> > > something
> > > > new for the "media".
> > >
> > > I'm not sure I get your point - I suspect we are in
> > > violent agreement.
> > >
> > > Is anyone arguing that you don't need something new
> > > for message sessions? If all you currently have is
> > > 2543 based, then of course you do. But it would be
> > > nice if the only
> > > new thing you needed was a path through 3261
> > > compatible proxies.
> > >
> > >       Paul
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > >
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Health - Feel better, live better
> > http://health.yahoo.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 adam@dynamicsoft.com  Tue Jul 23 15:49:44 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07863
	for ; Tue, 23 Jul 2002 15:49:44 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NJnHCU012901;
	Tue, 23 Jul 2002 15:49:25 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <306APZ72>; Tue, 23 Jul 2002 14:49:36 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A307@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Paul Kyzivat'" ,
        James Undery
	 
Cc: "SIMPLE (E-mail)" 
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Tue, 23 Jul 2002 14:49:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2515
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: 

In the immortal words of Dave Oran: I'm confused.

It seems to me that there have been a couple of proposals
floated here that amount to: "RFC2543 proxies will break
if you send message sessions through them. Therefore, we
must come up with a mechanism to break RFC2543 proxies if
you send message sessions through them."

What?

If they're broken, why take extra steps to break them?

However, all of that seems like a completely moot point
to me. Consider: how would a message session be routed
through a proxy? If we use the mechanism in
draft-rosenberg-simple-message-session-00.txt (which is
the only proposal right now, to my knowledge), the *only*
way a proxy can end up in the route of a message session
is if it (a) knows about message sessions, and
(b) explicitly inserts itself IN THE SDP. Can anyone
point to a deployed RFC2543 proxy that does this? Then
why are we spinning our wheels on this issue?

It seems to me that a number of great minds are wasting
a lot of time solving a non-problem here.

/a

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Tuesday, July 23, 2002 8:09
> To: James Undery
> Cc: SIMPLE (E-mail)
> Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
> 
> 
> 
> 
> James Undery wrote:
> > 
> > Hi,
> > 
> > At the SIMPLE meeting I believe the consensus was to go 
> with a SIP based message transport, however, it was unclear 
> if this should be SIP or IMTP. The argument for SIP is 
> because of rfc3261 we can now use SIP as is, IMTP was 
> complicated due to all the requirements of messaging that 
> couldn't be addressed easily; I'd definitely agree with that, 
> however, I believe that won't work, rfc2543 proxies may still 
> do all the bad things IMTP was designed to avoid. The 
> suggestion made by Rohan (that I strongly agree with) was to 
> take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time 
> the protocol is mentioned in the spec. This has the advantage 
> that you know older proxies aren't going to misbehave and the 
> draft specifying it should be trivial modification to 
> Jonathan's latest draft.
> 
> To avoid misbehaving proxies, shouldn't it be sufficient to 
> do something like
> 
> 	Proxy-Require: message_session
> 
> or something to that effect? Changing the version requires 
> much more mucking in the stack.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jdrosen@dynamicsoft.com  Tue Jul 23 16:40:35 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08056
	for ; Tue, 23 Jul 2002 16:40:35 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.235])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6NKeXYH017330;
	Tue, 23 Jul 2002 16:40:33 -0400 (EDT)
Message-ID: <3D3DBF40.1020605@dynamicsoft.com>
Date: Tue, 23 Jul 2002 16:40:32 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Sparks 
CC: Paul Kyzivat , Sean Olson ,
        James Undery ,
        "SIMPLE (E-mail)"
 
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
References: <1027453632.1314.42.camel@dhcp26.dfw.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2915
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: 

inline.

Robert Sparks wrote:
> 
> I'm a little confused about this whole discussion.
> 
> The mechanism described in
> draft-rosenberg-simple-message-sessions-00.txt
> uses information collected in the INVITE to build
> a route set that is used as as preloaded route in
> each message in the session.
> 
> This preloaded route is going to contain only
> elements that will process these MESSAGE requests
> in a congestion-safe fashion. (Otherwise, somebody
> violated the protocol).
> 
> So, why is it we're wringing our hands over one of
> these hitting a 2543 proxy?

I am collecting my thoughts on this issue; I think there is more here in 
this IMTP vs. SIP/2.0 debate than whether the proxies are 3261 compliant 
or not.

> 
> IMHO, this is a non-issue and our time would be 
> better spent inspecting and improving on the mechanism
> in the draft for collecting that preloaded route.

Well, while we are on that subject, let me make a radical proposal.

I would propose that, if we truly believe that IM sessions are NO 
different than voice sessions, we should have the same explicit support 
here for intermediaries as we do for RTP - which is NONE.

That leaves several options for routing through intermediaries:

1. Proxies modify the SDP, as they do today for VoIP, replacing the URI 
in there with the URI that points to an intermediary which contains a 
mapping to the next hop. In this case, there is no preloaded route. What 
about congestion control? Well, we would mandate that message sessions 
MUST be sent over a congestion controlled transport, enforced with 
Proxy-Require: congestion-safe in the MESSAGE, used in all cases. 
Forking/redirection can still be avoided, but becomes an issue of proper 
implementation of the intermediaries. I suspect it would never happen in 
practice, since the URI inserted into the SDP would be some random 
string that is created for this mapping (i.e., 
sip:asd88d8as9dasd-asd9askk@intermediary33.foo.com).

2. If there is a mechanism for discovering loose routes for media, it be 
applicable for all media types, not just messaging, and not require 
proxies to muck with SDP. My session policy proposal:
http://search.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt
provides one such mechanism. However, it would be a mistake to more or 
less invent that mechanism for each media type and hack it into the SDP 
for that type. If we believe in the concept of loose routing of media, 
and I do, we should solve the problem generally.

Flame away....

-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


From adam@dynamicsoft.com  Tue Jul 23 17:09:47 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08167
	for ; Tue, 23 Jul 2002 17:09:47 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NL9SCU013625;
	Tue, 23 Jul 2002 17:09:28 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <306APZ8F>; Tue, 23 Jul 2002 16:09:46 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A30C@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: Jonathan Rosenberg ,
        Robert Sparks
	 
Cc: Paul Kyzivat , Sean Olson ,
        James Undery ,
        "SIMPLE (E-mail)"
	 
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Tue, 23 Jul 2002 16:09:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1730
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: 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>
> I would propose that, if we truly believe that IM sessions are NO 
> different than voice sessions, we should have the same 
> explicit support 
> here for intermediaries as we do for RTP - which is NONE.

Okay. I like consistency. Sounds good to me.

>1. Proxies modify the SDP, as they do today for VoIP,
>   replacing the URI in there with the URI that points
>   to an intermediary which contains a mapping to the
>   next hop.

And, as has been demonstrated by our experience in VoIP,
people are going to do this. There's nothing we can do
to stop them. I don't think it deserves any more endorsement
than we've done for the same technique WRT voice. (That is,
none).

> 2. If there is a mechanism for discovering loose routes
>    for media, it be applicable for all media types, not
>    just messaging, and not require proxies to muck with SDP.

And I think that solving this problem only once makes a whole
lot more sense.

Is there a *requirement* that message sessions can go through
intermediaries? Basically, as you've pointed out, they're
just media. We have SIP with voice and video media deployed
just fine without such a mechanism, so I can't imagine that
this would be a legitimate *requirement* of a messaging solution.

That said, it's certainly a "nice to have", and the session-policy
draft makes a good start at defining requirements and mechanisms
for a solution.

So, would it be possible to pull the routing attribute out of
the message session draft altogether, get it out the door
(it's extremely important!), and then work on a general media
routing technique after we have it in the RFC editor's queue?

/a

From seancolson@yahoo.com  Tue Jul 23 17:42:50 2002
Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA08303
	for ; Tue, 23 Jul 2002 17:42:49 -0400 (EDT)
Message-ID: <20020723214249.25359.qmail@web11604.mail.yahoo.com>
Received: from [131.107.3.84] by web11604.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 14:42:49 PDT
Date: Tue, 23 Jul 2002 14:42:49 -0700 (PDT)
From: Sean Olson 
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
To: Adam Roach ,
        Jonathan Rosenberg ,
        Robert Sparks 
Cc: Paul Kyzivat , Sean Olson ,
        James Undery ,
        "SIMPLE \(E-mail\)" 
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F377A30C@DYN-TX-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1430
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: 


> > 2. If there is a mechanism for discovering loose
> routes
> >    for media, it be applicable for all media
> types, not
> >    just messaging, and not require proxies to muck
> with SDP.
> 
> And I think that solving this problem only once
> makes a whole
> lot more sense.
> 
> Is there a *requirement* that message sessions can
> go through
> intermediaries? Basically, as you've pointed out,
> they're
> just media. We have SIP with voice and video media
> deployed
> just fine without such a mechanism, so I can't
> imagine that
> this would be a legitimate *requirement* of a
> messaging solution.
> 
> That said, it's certainly a "nice to have", and the
> session-policy
> draft makes a good start at defining requirements
> and mechanisms
> for a solution.
> 
> So, would it be possible to pull the routing
> attribute out of
> the message session draft altogether, get it out the
> door
> (it's extremely important!), and then work on a
> general media
> routing technique after we have it in the RFC
> editor's queue?
> 
> /a

I'm all for having the message session work completed
as quickly as possible. But I think the routing
aspects need to be fleshed out before this can be
a really useful mechanism. In particular, NAT/firewall
traversal can be a bit thorny otherwise.

/sean


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

From jdrosen@dynamicsoft.com  Tue Jul 23 17:44:28 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08355
	for ; Tue, 23 Jul 2002 17:44:28 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.235])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6NLiMYH017418;
	Tue, 23 Jul 2002 17:44:23 -0400 (EDT)
Message-ID: <3D3DCE35.3000708@dynamicsoft.com>
Date: Tue, 23 Jul 2002 17:44:21 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de,
        bcampbell@dynamicsoft.com, mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <3D3C0DFD.CC504B1@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2838
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: 


Paul Kyzivat wrote:
> 

>>However, I would like to provide sequencing for
>>them, and so CSeq is natural for that. In order to use CSeq, you must
>>have a well defined scope in which they exist. I had merely indicated
>>that this was a "dialog ID" - meaning the To-tag, From-tag, and
>> call-id,
>>which does not imply the existence of a dialog.
> 
> 
> I'm unconfortable with using "dialog ID" without there being a dialog. I
> can't at the moment give a solid reason why this is wrong, but it feels
> like an abuse.

OK, let me know be very explicit.

Message sessions would be a sequence of pages. As per 3261, each of 
those will have a call-id, a from tag, and no to tag. The 200 OK 
response to each of those has a to tag filled in, different for each 
message. The CSeq refers to the sequencing within the URI seen by the 
UAS, as I have indicated in a previous mail, so I have fully backed off 
that notion.

So, there is a dialog ID, but its different for each message, as it 
would be for page mode.


> 
> 
>>However, it occurs to me that if the URI is the point of demux at the
>>UAS, then the scope of the sequence numbers can be within that URI. In
>>other words, each MESSAGE in the message media stream could (and
>>probably should, thinking about this more) have a unique call-id. The
>>cseq increment by one for each message sent by the originating UA. The
>>UAS will provide a URI of sufficient uniqueness that it won't receive
>>any messages at the URI except for ones sent by the originator. Thus,
>>the cseq can provide ordering within the scope of the r-uri as seen by
>>the UAS.
> 
> 
> If we continue the analogy with RTP streams, then this seems like a bad
> assumption. In the case of RTP, we never assume that all the packets
> arrive from the same source.
> This can be violated in many cases, such as when transferring a call,
> where one sender is replaced by another, but the receiver remains
> invariant.

Yes, thats a good point. Its the combination of SSRC and port which 
define a sequence number space. In that case, we would need to do a 
similar thing.

> 
> Why can't we rely on the message content to provide ordering, and the
> reliablility of the transport to guarantee delivery? Of course text
> content won't provide ordering,
> but that will provide more encouragement to use CPIM. 

Sequencing is an existing sip functionality; it hardly seems worth it to 
use content provided ordering when the transport can already do 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


From jdrosen@dynamicsoft.com  Tue Jul 23 17:54:18 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08431
	for ; Tue, 23 Jul 2002 17:54:18 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.235])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6NLsGYH017425;
	Tue, 23 Jul 2002 17:54:16 -0400 (EDT)
Message-ID: <3D3DD086.3070903@dynamicsoft.com>
Date: Tue, 23 Jul 2002 17:54:14 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell 
CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, dsardana@seven.com,
        vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <3D3C2FBC.1090205@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2804
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: 

I still believe that we should follow Robert's advice as offered in the 
SIMPLE session. We are now down to arguing the interpretation of the 
terms priority, urgency, and expiration. This is an argument for which 
there is no right answer. Since 3261 allows each method to define a 
method-specific meaning for Expires, we are well within the scope of the 
specifications. No one has found a technical flaw in this approach. At 
least several people (myself included) feel its reasonable if not 
perfect. Robert's advice was to leave it be unless people found it to be 
broken. I would rather finish this specification finally, rather than 
debating the relative interpretations of the terms in play here.

-Jonathan R.

Ben Campbell wrote:
> hisham.khartabil@nokia.com wrote:
> 
>>Well, you read my mind. I wanted to get consensus that Priority header
> 
> is for user interface purposes only before I do so.
> 
> As I mentioned in a separate mail, priority _can_ be used for routing 
> purposes. But it means something different than urgency.
> 
> 
>>Should we do something like that or are these issues part of the
> 
> ieprep work?
> 
>>Regards,
>>Hisham
>>
>>
>>
>>>-----Original Message-----
>>>From: ext Adam Roach [mailto:adam@dynamicsoft.com]
>>>Sent: Monday, July 22, 2002 4:51 PM
>>>To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach
>>>Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com;
>>>Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com
>>>Subject: RE: [Simple] -05 MESSAGE and Expires header
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
>>>>- When is a message urgent but does not require immediate delivery?
>>>
>>>Are you proposing an "Urgency" header, or confusing priority with
>>>urgency? I'll see if I can accurately demonstrate their 
>>>orthangonality.
>>>
>>>High Priority, Low Urgency:
>>> Note to new residents: failure to file income taxes by April
>>> 15th can lead to substantial penalties.
>>>
>>>Low Priority, High Urgency:
>>> You have 5 minutes to come by and pick up the rest of your lunch
>>> or I'm going to throw it away.
>>>                            
>>>High Priority, High Urgency:
>>> There's a tornado coming your way!
>>>
>>>Low Priority, Low Urgency:
>>> Llamas can make four distinct noises: humming, clucking, 
>>>orgling, and
>>> a high pitched, rhythmic alarm sound.
>>>
>>>/a
>>>
>>
>>
> 
> 
> 


-- 
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


From bcampbell@dynamicsoft.com  Tue Jul 23 18:08:13 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08487
	for ; Tue, 23 Jul 2002 18:08:12 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6NM7shZ082134;
	Tue, 23 Jul 2002 17:07:55 -0500 (CDT)
Message-ID: <3D3DD3A3.8070309@dynamicsoft.com>
Date: Tue, 23 Jul 2002 17:07:31 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg , SIP LIST 
CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, dsardana@seven.com,
        vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <3D3C2FBC.1090205@dynamicsoft.com> <3D3DD086.3070903@dynamicsoft.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3316
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: 

I concur. I have had many responses suggesting we leave it alone, and 
only a couple of people arguing for a change.

The draft currently leaves most of the handling of Expires as a matter 
of local policy. I think that is the appropriate level of detail for the 
MESSAGE specification. Since the majority of the controversy concerns 
store and forward relays, I will echo Sean's statement that if we choose 
to standardize such relays, that specification if free to further 
constrain relay behavior.

Also, as mentioned in the wg meeting, this discussion belongs on the SIP 
list, as it concerns a SIP work item. I have tried moving it there, but 
it doesn't seem to stick. Please direct any future discussion to the SIP 
list.

Jonathan Rosenberg wrote:
> I still believe that we should follow Robert's advice as offered in the 
> SIMPLE session. We are now down to arguing the interpretation of the 
> terms priority, urgency, and expiration. This is an argument for which 
> there is no right answer. Since 3261 allows each method to define a 
> method-specific meaning for Expires, we are well within the scope of the 
> specifications. No one has found a technical flaw in this approach. At 
> least several people (myself included) feel its reasonable if not 
> perfect. Robert's advice was to leave it be unless people found it to be 
> broken. I would rather finish this specification finally, rather than 
> debating the relative interpretations of the terms in play here.
> 
> -Jonathan R.
> 
> Ben Campbell wrote:
> 
>> hisham.khartabil@nokia.com wrote:
>>
>>> Well, you read my mind. I wanted to get consensus that Priority header
>>
>>
>> is for user interface purposes only before I do so.
>>
>> As I mentioned in a separate mail, priority _can_ be used for routing 
>> purposes. But it means something different than urgency.
>>
>>
>>> Should we do something like that or are these issues part of the
>>
>>
>> ieprep work?
>>
>>> Regards,
>>> Hisham
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: ext Adam Roach [mailto:adam@dynamicsoft.com]
>>>> Sent: Monday, July 22, 2002 4:51 PM
>>>> To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach
>>>> Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com;
>>>> Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com
>>>> Subject: RE: [Simple] -05 MESSAGE and Expires header
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
>>>>> - When is a message urgent but does not require immediate delivery?
>>>>
>>>>
>>>> Are you proposing an "Urgency" header, or confusing priority with
>>>> urgency? I'll see if I can accurately demonstrate their orthangonality.
>>>>
>>>> High Priority, Low Urgency:
>>>> Note to new residents: failure to file income taxes by April
>>>> 15th can lead to substantial penalties.
>>>>
>>>> Low Priority, High Urgency:
>>>> You have 5 minutes to come by and pick up the rest of your lunch
>>>> or I'm going to throw it away.
>>>>                            High Priority, High Urgency:
>>>> There's a tornado coming your way!
>>>>
>>>> Low Priority, Low Urgency:
>>>> Llamas can make four distinct noises: humming, clucking, orgling, and
>>>> a high pitched, rhythmic alarm sound.
>>>>
>>>> /a
>>>>
>>>
>>>
>>
>>
>>
> 
> 




From bcampbell@dynamicsoft.com  Tue Jul 23 18:09:06 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08494
	for ; Tue, 23 Jul 2002 18:09:03 -0400 (EDT)
Received: from dynamicsoft.com (ben@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g6NM8mhZ082208;
	Tue, 23 Jul 2002 17:08:49 -0500 (CDT)
Message-ID: <3D3DD3D9.5020706@dynamicsoft.com>
Date: Tue, 23 Jul 2002 17:08:25 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg , SIP LIST 
CC: hisham.khartabil@nokia.com, adam@dynamicsoft.com, dsardana@seven.com,
        vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <3D3C2FBC.1090205@dynamicsoft.com> <3D3DD086.3070903@dynamicsoft.com>
X-Enigmail-Version: 0.61.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3372
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: 

I concur. I have had many responses suggesting we leave it alone, and
only a couple of people arguing for a change.

The draft currently leaves most of the handling of Expires as a matter
of local policy. I think that is the appropriate level of detail for the
MESSAGE specification. Since the majority of the controversy concerns
store and forward relays, I will echo Sean's statement that if we choose
to standardize such relays, that specification if free to further
constrain relay behavior.

Also, as mentioned in the wg meeting, this discussion belongs on the SIP
list, as it concerns a SIP work item. I have tried moving it there, but
it doesn't seem to stick. Please direct any future discussion to the SIP
list.

Jonathan Rosenberg wrote:
 > I still believe that we should follow Robert's advice as offered in the
 > SIMPLE session. We are now down to arguing the interpretation of the
 > terms priority, urgency, and expiration. This is an argument for which
 > there is no right answer. Since 3261 allows each method to define a
 > method-specific meaning for Expires, we are well within the scope of the
 > specifications. No one has found a technical flaw in this approach. At
 > least several people (myself included) feel its reasonable if not
 > perfect. Robert's advice was to leave it be unless people found it to be
 > broken. I would rather finish this specification finally, rather than
 > debating the relative interpretations of the terms in play here.
 >
 > -Jonathan R.
 >
 > Ben Campbell wrote:
 >
 >> hisham.khartabil@nokia.com wrote:
 >>
 >>> Well, you read my mind. I wanted to get consensus that Priority header
 >>
 >>
 >> is for user interface purposes only before I do so.
 >>
 >> As I mentioned in a separate mail, priority _can_ be used for routing
 >> purposes. But it means something different than urgency.
 >>
 >>
 >>> Should we do something like that or are these issues part of the
 >>
 >>
 >> ieprep work?
 >>
 >>> Regards,
 >>> Hisham
 >>>
 >>>
 >>>
 >>>> -----Original Message-----
 >>>> From: ext Adam Roach [mailto:adam@dynamicsoft.com]
 >>>> Sent: Monday, July 22, 2002 4:51 PM
 >>>> To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach
 >>>> Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com;
 >>>> Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com
 >>>> Subject: RE: [Simple] -05 MESSAGE and Expires header
 >>>>
 >>>>
 >>>>
 >>>>
 >>>>> -----Original Message-----
 >>>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
 >>>>> - When is a message urgent but does not require immediate delivery?
 >>>>
 >>>>
 >>>> Are you proposing an "Urgency" header, or confusing priority with
 >>>> urgency? I'll see if I can accurately demonstrate their 
orthangonality.
 >>>>
 >>>> High Priority, Low Urgency:
 >>>> Note to new residents: failure to file income taxes by April
 >>>> 15th can lead to substantial penalties.
 >>>>
 >>>> Low Priority, High Urgency:
 >>>> You have 5 minutes to come by and pick up the rest of your lunch
 >>>> or I'm going to throw it away.
 >>>>                            High Priority, High Urgency:
 >>>> There's a tornado coming your way!
 >>>>
 >>>> Low Priority, Low Urgency:
 >>>> Llamas can make four distinct noises: humming, clucking, orgling, and
 >>>> a high pitched, rhythmic alarm sound.
 >>>>
 >>>> /a
 >>>>
 >>>
 >>>
 >>
 >>
 >>
 >
 >





From seancolson@yahoo.com  Tue Jul 23 18:11:43 2002
Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA08539
	for ; Tue, 23 Jul 2002 18:11:42 -0400 (EDT)
Message-ID: <20020723221143.57917.qmail@web11606.mail.yahoo.com>
Received: from [131.107.3.79] by web11606.mail.yahoo.com via HTTP; Tue, 23 Jul 2002 15:11:43 PDT
Date: Tue, 23 Jul 2002 15:11:43 -0700 (PDT)
From: Sean Olson 
Subject: Re: [Simple] Message session & associated dialog
To: Jonathan Rosenberg ,
        Paul Kyzivat 
Cc: aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de,
        bcampbell@dynamicsoft.com, mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3D3DCE35.3000708@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1023
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: 

> OK, let me know be very explicit.
> 
> Message sessions would be a sequence of pages. As
> per 3261, each of 
> those will have a call-id, a from tag, and no to
> tag. The 200 OK 
> response to each of those has a to tag filled in,
> different for each 
> message. The CSeq refers to the sequencing within
> the URI seen by the 
> UAS, as I have indicated in a previous mail, so I
> have fully backed off 
> that notion.
> 
> So, there is a dialog ID, but its different for each
> message, as it 
> would be for page mode.

If the dialog ID is different for each page, then
how would the CSeq be used across these pages to
do sequencing? Wouldn't there necessarily be a
unique numbering space for each dialog ID? And if
there is a possibility that these pages come from
different sources, then we can't count on CSeq 
ordering. I think I may be misunderstanding your
proposal.

/sean





__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

From dsardana@seven.com  Tue Jul 23 18:12:38 2002
Received: from rwc-ex0.corp.seven.com ([209.19.68.212])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08562
	for ; Tue, 23 Jul 2002 18:12:38 -0400 (EDT)
Received: from seven.com ([10.0.36.36]) by rwc-ex0.corp.seven.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 23 Jul 2002 15:14:57 -0700
Message-ID: <3D3DD4A7.81D1635B@seven.com>
Date: Tue, 23 Jul 2002 15:11:51 -0700
From: Bobby Sardana 
Organization: Seven Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: Ben Campbell , hisham.khartabil@nokia.com,
        adam@dynamicsoft.com, vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <3D3C2FBC.1090205@dynamicsoft.com> <3D3DD086.3070903@dynamicsoft.com>
Content-Type: multipart/alternative;
 boundary="------------39FC5F0FDFE35EA0217AF65C"
X-OriginalArrivalTime: 23 Jul 2002 22:14:57.0021 (UTC) FILETIME=[60CB3AD0:01C23296]
Content-Length: 9185
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: 

--------------39FC5F0FDFE35EA0217AF65C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Comments inline.

Jonathan Rosenberg wrote:

> I still believe that we should follow Robert's advice as offered in the
> SIMPLE session. We are now down to arguing the interpretation of the
> terms priority, urgency, and expiration. This is an argument for which
> there is no right answer. Since 3261 allows each method to define a
> method-specific meaning for Expires, we are well within the scope of the
> specifications. No one has found a technical flaw in this approach. At
> least several people (myself included) feel its reasonable if not
> perfect. Robert's advice was to leave it be unless people found it to be
> broken. I would rather finish this specification finally, rather than
> debating the relative interpretations of the terms in play here.

I agree that it is important to finish the specification than to debate
about the merits of "Expire" and "Priority". The comment I want to make is
that allowing "Expire" to be method specific allows it to be mis-used,
maybe not in case of MESSAGE, but in still-to-be-articulated methods. We
have the opportunity to fix it now by picking a header, like Priority,
which is more verbose. Also, as an implementor, I would not have to pick
the spec to figure out what specific meaning does "Expire" have and in what
method context. If there are self-descriptive headers, then their use would
be of help -- both from an implementation & understanding purposes.

with regards,

Bobby Sardana.
dsardana@seven.com

>
>
> -Jonathan R.
>
> Ben Campbell wrote:
> > hisham.khartabil@nokia.com wrote:
> >
> >>Well, you read my mind. I wanted to get consensus that Priority header
> >
> > is for user interface purposes only before I do so.
> >
> > As I mentioned in a separate mail, priority _can_ be used for routing
> > purposes. But it means something different than urgency.
> >
> >
> >>Should we do something like that or are these issues part of the
> >
> > ieprep work?
> >
> >>Regards,
> >>Hisham
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> >>>Sent: Monday, July 22, 2002 4:51 PM
> >>>To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach
> >>>Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com;
> >>>Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com
> >>>Subject: RE: [Simple] -05 MESSAGE and Expires header
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> >>>>- When is a message urgent but does not require immediate delivery?
> >>>
> >>>Are you proposing an "Urgency" header, or confusing priority with
> >>>urgency? I'll see if I can accurately demonstrate their
> >>>orthangonality.
> >>>
> >>>High Priority, Low Urgency:
> >>> Note to new residents: failure to file income taxes by April
> >>> 15th can lead to substantial penalties.
> >>>
> >>>Low Priority, High Urgency:
> >>> You have 5 minutes to come by and pick up the rest of your lunch
> >>> or I'm going to throw it away.
> >>>
> >>>High Priority, High Urgency:
> >>> There's a tornado coming your way!
> >>>
> >>>Low Priority, Low Urgency:
> >>> Llamas can make four distinct noises: humming, clucking,
> >>>orgling, and
> >>> a high pitched, rhythmic alarm sound.
> >>>
> >>>/a
> >>>
> >>
> >>
> >
> >
> >
>
> --
> 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

--
___________________________

Bobby Sardana |  SEVEN
Software Engineer, Engineering
___________________________

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
dsardana@seven.com
www.seven.com



--------------39FC5F0FDFE35EA0217AF65C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Comments inline.

Jonathan Rosenberg wrote:

I still believe that we should follow Robert's advice
as offered in the

SIMPLE session. We are now down to arguing the interpretation of the

terms priority, urgency, and expiration. This is an argument for which

there is no right answer. Since 3261 allows each method to define a

method-specific meaning for Expires, we are well within the scope of
the

specifications. No one has found a technical flaw in this approach.
At

least several people (myself included) feel its reasonable if not

perfect. Robert's advice was to leave it be unless people found it
to be

broken. I would rather finish this specification finally, rather than

debating the relative interpretations of the terms in play here.

I agree that it is important to finish the specification than to debate
about the merits of "Expire" and "Priority". The comment I want to make
is that allowing "Expire" to be method specific allows it to be mis-used,
maybe not in case of MESSAGE, but in still-to-be-articulated methods. We
have the opportunity to fix it now by picking a header, like Priority,
which is more verbose. Also, as an implementor, I would not have to pick
the spec to figure out what specific meaning does "Expire" have and in
what method context. If there are self-descriptive headers, then their
use would be of help -- both from an implementation & understanding
purposes.

with regards,

Bobby Sardana.

dsardana@seven.com

 

-Jonathan R.

Ben Campbell wrote:

> hisham.khartabil@nokia.com wrote:

>

>>Well, you read my mind. I wanted to get consensus that Priority header

>

> is for user interface purposes only before I do so.

>

> As I mentioned in a separate mail, priority _can_ be used for routing

> purposes. But it means something different than urgency.

>

>

>>Should we do something like that or are these issues part of the

>

> ieprep work?

>

>>Regards,

>>Hisham

>>

>>

>>

>>>-----Original Message-----

>>>From: ext Adam Roach [mailto:adam@dynamicsoft.com]

>>>Sent: Monday, July 22, 2002 4:51 PM

>>>To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach

>>>Cc: Ben Campbell; dsardana@seven.com; vkg@lucent.com;

>>>Ya-Ching.Tan@icn.siemens.de; simple@mailman.dynamicsoft.com

>>>Subject: RE: [Simple] -05 MESSAGE and Expires header

>>>

>>>

>>>

>>>

>>>>-----Original Message-----

>>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]

>>>>- When is a message urgent but does not require immediate delivery?

>>>

>>>Are you proposing an "Urgency" header, or confusing priority with

>>>urgency? I'll see if I can accurately demonstrate their

>>>orthangonality.

>>>

>>>High Priority, Low Urgency:

>>> Note to new residents: failure to file income taxes by April

>>> 15th can lead to substantial penalties.

>>>

>>>Low Priority, High Urgency:

>>> You have 5 minutes to come by and pick up the rest of your lunch

>>> or I'm going to throw it away.

>>>

>>>High Priority, High Urgency:

>>> There's a tornado coming your way!

>>>

>>>Low Priority, Low Urgency:

>>> Llamas can make four distinct noises: humming, clucking,

>>>orgling, and

>>> a high pitched, rhythmic alarm sound.

>>>

>>>/a

>>>

>>

>>

>

>

>

--

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



-- 
___________________________ 

Bobby Sardana |  SEVEN 
Software Engineer, Engineering  
___________________________ 

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
dsardana@seven.com
www.seven.com

 

--------------39FC5F0FDFE35EA0217AF65C--


From adam@dynamicsoft.com  Tue Jul 23 19:19:47 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08805
	for ; Tue, 23 Jul 2002 19:19:47 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6NNJOCU014399;
	Tue, 23 Jul 2002 19:19:24 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <306APZ89>; Tue, 23 Jul 2002 18:19:39 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A30E@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Bobby Sardana'" ,
        Jonathan Rosenberg
	 
Cc: Ben Campbell , hisham.khartabil@nokia.com,
        Adam Roach , vkg@lucent.com,
        Ya-Ching.Tan@icn.siemens.de, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Tue, 23 Jul 2002 18:19:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1254
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: 

Please don't use HTML or Rich Text in your mail to the list.
It makes your messages difficult to reply to.

Comments below.

-----Original Message-----
From: Bobby Sardana [mailto:dsardana@seven.com]
 
> ...as an implementor, I would not have to pick the spec
> to figure out what specific meaning does "Expire" have
> and in what method context. If there are self-descriptive
> headers, then their use would be of help -- both from an
> implementation & understanding purposes.

I'm not sure that's possible.

What does "Expire" *currently* mean? It might mean the duration
of validity for an invitation. It might mean the duration of
softstate for a registration or a subscription. In terms of
handling, these are radically different things.

So, to say that it could also be a user-interface indication
for staleness of IMs that may or may not also be used in making
store-and-forward decisions doesn't seem to be a stretch. Above
all, I can't formulate a consistent handling that can be assigned
to the existing methods (i.e. published in RFCs) to unify
them.

Or, perhaps I'm just missing something obvious. I would
be interested in hearing you put forth a propasal that
describes a handling for "Expires" that applies uniformly
to all methods.

/a

From dsardana@seven.com  Tue Jul 23 20:07:47 2002
Received: from rwc-ex0.corp.seven.com ([209.19.68.212])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08980
	for ; Tue, 23 Jul 2002 20:07:46 -0400 (EDT)
Received: from seven.com ([10.0.36.36]) by rwc-ex0.corp.seven.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 23 Jul 2002 17:10:04 -0700
Message-ID: <3D3DEFA2.F1926D2B@seven.com>
Date: Tue, 23 Jul 2002 17:06:58 -0700
From: Bobby Sardana 
Organization: Seven Networks
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Adam Roach 
CC: Jonathan Rosenberg ,
        Ben Campbell , hisham.khartabil@nokia.com,
        vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] -05 MESSAGE and Expires header
References: <9BF66EBF6BEFD942915B4D4D45C051F377A30E@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 24 Jul 2002 00:10:04.0237 (UTC) FILETIME=[75D0BFD0:01C232A6]
Content-Length: 1054
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: 

Comments towards the end.

-----Original Message-----

> From: Bobby Sardana [mailto:dsardana@seven.com]
>
> > ...as an implementor, I would not have to pick the spec
> > to figure out what specific meaning does "Expire" have
> > and in what method context. If there are self-descriptive
> > headers, then their use would be of help -- both from an
> > implementation & understanding purposes.
>
> I'm not sure that's possible.
>
> ...
>
> Or, perhaps I'm just missing something obvious. I would
> be interested in hearing you put forth a propasal that
> describes a handling for "Expires" that applies uniformly
> to all methods.

The proposal is simple: (not sure from a complete applicability point of
view, but here it is)

a. Expire signifies a unit of time
b. For methods that have the Expire header, the unit of time determines
the method validitity. The only exception here is 0, which can mean
"expired" or "infinite".

I know the above is not a formal proposal but it's the only one I am
thinking.

regards,

Bobby Sardana.
dsardana@seven.com


From adam@dynamicsoft.com  Tue Jul 23 21:08:42 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09175
	for ; Tue, 23 Jul 2002 21:08:42 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6O18JCU014776;
	Tue, 23 Jul 2002 21:08:19 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <306APZ9R>; Tue, 23 Jul 2002 20:08:38 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A315@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Bobby Sardana'" ,
        Adam Roach
	 
Cc: Jonathan Rosenberg ,
        Ben Campbell
	 , hisham.khartabil@nokia.com,
        vkg@lucent.com, Ya-Ching.Tan@icn.siemens.de,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] -05 MESSAGE and Expires header
Date: Tue, 23 Jul 2002 20:08:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1581
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: 

> -----Original Message-----
> From: Bobby Sardana [mailto:dsardana@seven.com]
>
> The proposal is simple: (not sure from a complete 
> applicability point of
> view, but here it is)
> 
> a. Expire signifies a unit of time

Agreed.

> b. For methods that have the Expire header, the unit of time 
> determines
> the method validitity.

There's a problem with that approach. For SUBSCRIBE and REGISTER,
the "Expires" header doesn't indicate the period of validity of
the request (which is presumably what you mean by "method validity");
it indicates the period of validity for what is *created* by the
request. The analog for INVITE would be "Session-Expires".

> The only exception here is 0, which can mean
> "expired" or "infinite".

There are actually three problems here. 

1. Historically, "0" has never been treated 
   as a special case in SIP expirations. (More
   on this below).

2. "Expires: 0" does not mean "expired" (that
   would, in theory, be represented by a negative
   number -- but we don't do that); it means that
   expiration occurs in zero seconds (i.e.
   instantaneously). For the purposes of instant
   messages, that's exactly what we want to convey:
   "this mesage expires instantaneously -- so, send
   it on or consider it stale" (where handling of
   stale messages is a matter of local policy).

3. Zero has *never* meant infinity in a SIP
   "Expires" context. The convention for "infinity"
   is to use 4294967295 (2^32-1), which ends up being
   over 136 years -- long enough to mean "infinity" for
   the purposes of a computer protocol.

/a

From hisham.khartabil@nokia.com  Wed Jul 24 04:30:19 2002
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 EAA10414
	for ; Wed, 24 Jul 2002 04:30:18 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6O8Uoi29716
	for ; Wed, 24 Jul 2002 11:30:50 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 24 Jul 2002 11:30:17 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 24 Jul 2002 11:30:17 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Wed, 24 Jul 2002 11:30:16 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20401@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message Transport Protocol (SIP vs IMTP)
Thread-Index: AcIyirtcYQ3ZC3q0SGi0xLsqd4JiTAAYUqGg
To: , 
Cc: , , ,
        
X-OriginalArrivalTime: 24 Jul 2002 08:30:17.0065 (UTC) FILETIME=[56DADD90:01C232EC]
Content-Length: 3747
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA10414
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: 

I agree in removing the proxy modifying the SDP part in the spec. But we need session-policy and message-session to complete in parallel.

There is a requirement for messages to do through intermediaries and session-policy should fix that.

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, July 23, 2002 11:41 PM
> To: Robert Sparks
> Cc: Paul Kyzivat; Sean Olson; James Undery; SIMPLE (E-mail)
> Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
> 
> 
> inline.
> 
> Robert Sparks wrote:
> > 
> > I'm a little confused about this whole discussion.
> > 
> > The mechanism described in
> > draft-rosenberg-simple-message-sessions-00.txt
> > uses information collected in the INVITE to build
> > a route set that is used as as preloaded route in
> > each message in the session.
> > 
> > This preloaded route is going to contain only
> > elements that will process these MESSAGE requests
> > in a congestion-safe fashion. (Otherwise, somebody
> > violated the protocol).
> > 
> > So, why is it we're wringing our hands over one of
> > these hitting a 2543 proxy?
> 
> I am collecting my thoughts on this issue; I think there is 
> more here in 
> this IMTP vs. SIP/2.0 debate than whether the proxies are 
> 3261 compliant 
> or not.
> 
> > 
> > IMHO, this is a non-issue and our time would be 
> > better spent inspecting and improving on the mechanism
> > in the draft for collecting that preloaded route.
> 
> Well, while we are on that subject, let me make a radical proposal.
> 
> I would propose that, if we truly believe that IM sessions are NO 
> different than voice sessions, we should have the same 
> explicit support 
> here for intermediaries as we do for RTP - which is NONE.
> 
> That leaves several options for routing through intermediaries:
> 
> 1. Proxies modify the SDP, as they do today for VoIP, 
> replacing the URI 
> in there with the URI that points to an intermediary which contains a 
> mapping to the next hop. In this case, there is no preloaded 
> route. What 
> about congestion control? Well, we would mandate that message 
> sessions 
> MUST be sent over a congestion controlled transport, enforced with 
> Proxy-Require: congestion-safe in the MESSAGE, used in all cases. 
> Forking/redirection can still be avoided, but becomes an 
> issue of proper 
> implementation of the intermediaries. I suspect it would 
> never happen in 
> practice, since the URI inserted into the SDP would be some random 
> string that is created for this mapping (i.e., 
> sip:asd88d8as9dasd-asd9askk@intermediary33.foo.com).
> 
> 2. If there is a mechanism for discovering loose routes for 
> media, it be 
> applicable for all media types, not just messaging, and not require 
> proxies to muck with SDP. My session policy proposal:
> http://search.ietf.org/internet-drafts/draft-rosenberg-sipping
-session-policy-00.txt
provides one such mechanism. However, it would be a mistake to more or 
less invent that mechanism for each media type and hack it into the SDP 
for that type. If we believe in the concept of loose routing of media, 
and I do, we should solve the problem generally.

Flame away....

-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 hisham.khartabil@nokia.com  Wed Jul 24 04:37:27 2002
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 EAA10452
	for ; Wed, 24 Jul 2002 04:37:26 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6O8Zmd01950
	for ; Wed, 24 Jul 2002 11:35:49 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 24 Jul 2002 11:37:20 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 24 Jul 2002 11:37:21 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 24 Jul 2002 11:37:20 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message session & associated dialog
Date: Wed, 24 Jul 2002 11:37:19 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20402@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message session & associated dialog
Thread-Index: AcIyl2sE4n3mVllhQRu8N5qu4BHYJQAVW8BA
To: , , 
Cc: , ,
        , ,
        
X-OriginalArrivalTime: 24 Jul 2002 08:37:20.0147 (UTC) FILETIME=[53080E30:01C232ED]
Content-Length: 1979
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA10452
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: 


> -----Original Message-----
> From: ext Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Wednesday, July 24, 2002 1:12 AM
> To: Jonathan Rosenberg; Paul Kyzivat
> Cc: Niemi Aki (NET/Espoo); peter.paeppinghaus@icn.siemens.de;
> bcampbell@dynamicsoft.com; mhammer@cisco.com;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Message session & associated dialog
> 
> 
> 
> > OK, let me know be very explicit.
> > 
> > Message sessions would be a sequence of pages. As
> > per 3261, each of 
> > those will have a call-id, a from tag, and no to
> > tag. The 200 OK 
> > response to each of those has a to tag filled in,
> > different for each 
> > message. The CSeq refers to the sequencing within
> > the URI seen by the 
> > UAS, as I have indicated in a previous mail, so I
> > have fully backed off 
> > that notion.
> > 
> > So, there is a dialog ID, but its different for each
> > message, as it 
> > would be for page mode.
> 
> If the dialog ID is different for each page, then
> how would the CSeq be used across these pages to
> do sequencing? Wouldn't there necessarily be a
> unique numbering space for each dialog ID? And if
> there is a possibility that these pages come from
> different sources, then we can't count on CSeq 
> ordering. I think I may be misunderstanding your
> proposal.


In an earlier I proposed using the local port and CSeq, but now there is the other dimension of receiving media from different sources. In this case, can we use local port, remote port and ip address, and CSeq (or whatever sequencing is supported by the media protocol) to identify groupings of media packets (MESSAGE)?

Regards,
Hisham

> 
> /sean
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jdrosen@dynamicsoft.com  Wed Jul 24 08:56:08 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11291
	for ; Wed, 24 Jul 2002 08:56:08 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.194])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OCu7YH017749;
	Wed, 24 Jul 2002 08:56:07 -0400 (EDT)
Message-ID: <3D3EA3E6.1040709@dynamicsoft.com>
Date: Wed, 24 Jul 2002 08:56:06 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: rsparks@dynamicsoft.com, pkyzivat@cisco.com, seancolson@yahoo.com,
        jundery@ubiquity.net, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
References: <2038BCC78B1AD641891A0D1AE133DBB7C20401@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 917
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: 


hisham.khartabil@nokia.com wrote:
> I agree in removing the proxy modifying the SDP part in the spec. But we
> need session-policy and message-session to complete in parallel.

Not really. Message sessions will work without session policy, and you 
will be able to use intermediaries too. You will just need to muck with 
SDP, as we have always been doing (and will continue to be done, I 
suspect).

> 
> There is a requirement for messages to do through intermediaries and
> session-policy should fix that.

Session-policy is one way to fix that.

-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


From jdrosen@dynamicsoft.com  Wed Jul 24 08:58:39 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11310
	for ; Wed, 24 Jul 2002 08:58:39 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.194])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6OCweYH017752;
	Wed, 24 Jul 2002 08:58:40 -0400 (EDT)
Message-ID: <3D3EA47F.2000406@dynamicsoft.com>
Date: Wed, 24 Jul 2002 08:58:39 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: seancolson@yahoo.com, pkyzivat@cisco.com, aki.niemi@nokia.com,
        peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com,
        mhammer@cisco.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <2038BCC78B1AD641891A0D1AE133DBB7C20402@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2515
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: 

inline.

hisham.khartabil@nokia.com wrote:
> 
>>-----Original Message-----
>>From: ext Sean Olson [mailto:seancolson@yahoo.com]
>>Sent: Wednesday, July 24, 2002 1:12 AM
>>To: Jonathan Rosenberg; Paul Kyzivat
>>Cc: Niemi Aki (NET/Espoo); peter.paeppinghaus@icn.siemens.de;
>>bcampbell@dynamicsoft.com; mhammer@cisco.com;
>>simple@mailman.dynamicsoft.com
>>Subject: Re: [Simple] Message session & associated dialog
>>
>>
>>
>>
>>>OK, let me know be very explicit.
>>>
>>>Message sessions would be a sequence of pages. As
>>>per 3261, each of 
>>>those will have a call-id, a from tag, and no to
>>>tag. The 200 OK 
>>>response to each of those has a to tag filled in,
>>>different for each 
>>>message. The CSeq refers to the sequencing within
>>>the URI seen by the 
>>>UAS, as I have indicated in a previous mail, so I
>>>have fully backed off 
>>>that notion.
>>>
>>>So, there is a dialog ID, but its different for each
>>>message, as it 
>>>would be for page mode.
>>
>>If the dialog ID is different for each page, then
>>how would the CSeq be used across these pages to
>>do sequencing? Wouldn't there necessarily be a
>>unique numbering space for each dialog ID? And if
>>there is a possibility that these pages come from
>>different sources, then we can't count on CSeq 
>>ordering. I think I may be misunderstanding your
>>proposal.
> 
> 
> 
> In an earlier I proposed using the local port and CSeq, but now there is
> the other dimension of receiving media from different sources. In this
> case, can we use local port, remote port and ip address, and CSeq (or
> whatever sequencing is supported by the media protocol) to identify
> groupings of media packets (MESSAGE)?

Using a remote IP address or port is always a bad idea, for NAT reasons.

I believe the CSeq numbering space is identified by the local request 
URI (i.e., the value in the r-uri seen by the UAS that receives the 
message) combined with the From field, which would then identify the 
sender. Since there is no dialog here, there is no requirement that the 
 From field be the same for each message, and it can actually reflect 
the originator of that specific message.

-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


From sriramp@nortelnetworks.com  Wed Jul 24 11:30:49 2002
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11757
	for ; Wed, 24 Jul 2002 11:30:48 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6OFUth08277;
	Wed, 24 Jul 2002 10:30:55 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 24 Jul 2002 10:30:41 -0500
Message-ID: 
From: "Sriram Parameswar" 
To: "'Jonathan Rosenberg'" ,
        hisham.khartabil@nokia.com
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)
Date: Wed, 24 Jul 2002 10:30:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C23327.0F980F80"
Content-Length: 6937
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: 

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_01C23327.0F980F80
Content-Type: text/plain;
	charset="iso-8859-1"

I am a little confused by this talk of proxies messing around with the SDP
*without* using session-policy. I distinctly remember that such proxies were
labelled BBUA's and BBUA's were  considered evil.

Next question - this business of introducing intermediaries only for IM; we
should re-visit it. As has been noted in preceding conversations - in the
standards we do no such thing for other media like voice and video.

Thanks,

Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, July 24, 2002 7:56 AM
To: hisham.khartabil@nokia.com
Cc: rsparks@dynamicsoft.com; pkyzivat@cisco.com; seancolson@yahoo.com;
jundery@ubiquity.net; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)




hisham.khartabil@nokia.com wrote:
> I agree in removing the proxy modifying the SDP part in the spec. But we
> need session-policy and message-session to complete in parallel.

Not really. Message sessions will work without session policy, and you 
will be able to use intermediaries too. You will just need to muck with 
SDP, as we have always been doing (and will continue to be done, I 
suspect).

> 
> There is a requirement for messages to do through intermediaries and
> session-policy should fix that.

Session-policy is one way to fix that.

-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_01C23327.0F980F80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Simple] Message Transport Protocol (SIP vs IMTP)




I am a little confused by this talk of proxies =
messing around with the SDP *without* using session-policy. I =
distinctly remember that such proxies were labelled BBUA's and BBUA's =
were  considered evil.



Next question - this business of introducing =
intermediaries only for IM; we should re-visit it. As has been noted in =
preceding conversations - in the standards we do no such thing for =
other media like voice and video.



Thanks,




Sriram

__________________________________________

Sriram =
Parameswar          &n=
bsp;   Phone: 972-685-8540

Interactive Multimedia Server (IMS) Fax: =
972-684-3986

Nortel Networks, Richardson USA  Email: =
sriramp@nortelnetworks.com






-----Original Message-----

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Wednesday, July 24, 2002 7:56 AM

To: hisham.khartabil@nokia.com

Cc: rsparks@dynamicsoft.com; pkyzivat@cisco.com; =
seancolson@yahoo.com;

jundery@ubiquity.net; =
simple@mailman.dynamicsoft.com

Subject: Re: [Simple] Message Transport Protocol =
(SIP vs IMTP)










hisham.khartabil@nokia.com wrote:

> I agree in removing the proxy modifying the SDP =
part in the spec. But we

> need session-policy and message-session to =
complete in parallel.




Not really. Message sessions will work without =
session policy, and you 

will be able to use intermediaries too. You will =
just need to muck with 

SDP, as we have always been doing (and will continue =
to be done, I 

suspect).




> 

> There is a requirement for messages to do =
through intermediaries and

> session-policy should fix that.




Session-policy is one way to fix that.




-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_01C23327.0F980F80--

From pkyzivat@cisco.com  Wed Jul 24 13:18:07 2002
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 NAA12110
	for ; Wed, 24 Jul 2002 13:18:07 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OHIWp8022807;
	Wed, 24 Jul 2002 13:18:32 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN79266;
	Wed, 24 Jul 2002 13:22:39 -0400 (EDT)
Message-ID: <3D3EE145.55D5A373@cisco.com>
Date: Wed, 24 Jul 2002 13:17:57 -0400
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: hisham.khartabil@nokia.com
CC: seancolson@yahoo.com, jdrosen@dynamicsoft.com, aki.niemi@nokia.com,
        peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com,
        mhammer@cisco.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <2038BCC78B1AD641891A0D1AE133DBB7C20402@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 932
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: 


hisham.khartabil@nokia.com wrote:
> 
> In an earlier I proposed using the local port and CSeq, but now there is the other dimension of receiving media from different sources. In this case, can we use local port, remote port and ip address, and CSeq (or whatever sequencing is supported by the media protocol) to identify groupings of media packets (MESSAGE)?

This only provides partial ordering - the recipient is still responsible for taking partially ordered sequences of messages and turning them into a total ordering for
display. So the ordering is only approximately "correct" in any case. 

How much improvement in accuracy do we get from ordering one of those sequences using CSeq vs just using the order in which they are received? If ordering is done this way,
what is the recipient to do if it receives a message with a CSeq value that is too large? Must it buffer it until the "missing" messages are received?

	Paul

From pkyzivat@cisco.com  Wed Jul 24 13:29:21 2002
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 NAA12164
	for ; Wed, 24 Jul 2002 13:29:20 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6OHTkC6024109;
	Wed, 24 Jul 2002 13:29:46 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN79382;
	Wed, 24 Jul 2002 13:33:53 -0400 (EDT)
Message-ID: <3D3EE3E7.6192F83@cisco.com>
Date: Wed, 24 Jul 2002 13:29:11 -0400
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: hisham.khartabil@nokia.com, seancolson@yahoo.com, aki.niemi@nokia.com,
        peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com,
        mhammer@cisco.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <2038BCC78B1AD641891A0D1AE133DBB7C20402@esebe019.NOE.Nokia.com> <3D3EA47F.2000406@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1017
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: 


Jonathan Rosenberg wrote:
> 
> I believe the CSeq numbering space is identified by the local request
> URI (i.e., the value in the r-uri seen by the UAS that receives the
> message) combined with the From field, which would then identify the
> sender. Since there is no dialog here, there is no requirement that the
>  From field be the same for each message, and it can actually reflect
> the originator of that specific message.

I don't think the From is necessarily unique here.

Suppose I initially made a call to you from my desktop pc here, setting up a message session. Once we get chatting, I have to go to a meeting, so I transfer my end of the
call to my laptop pc.

Both pcs are registered as separate Contacts for my same address of record, and typically the AoR is what would be placed in the from address.

During the reinvite transition, you may be getting messages from both pcs, using same From address.

As an alternative, the address in the first Via header might be sufficiently unique.

	Paul

From jdrosen@dynamicsoft.com  Thu Jul 25 02:08:03 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14309
	for ; Thu, 25 Jul 2002 02:08:03 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.194])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g6P67xYH018298;
	Thu, 25 Jul 2002 02:08:00 -0400 (EDT)
Message-ID: <3D3F95BC.7010003@dynamicsoft.com>
Date: Thu, 25 Jul 2002 02:07:56 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sriram Parameswar 
CC: hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1137
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: 


Sriram Parameswar wrote:
> I am a little confused by this talk of proxies messing around with the
> SDP *without* using session-policy. I distinctly remember that such
> proxies were labelled BBUA's and BBUA's were  considered evil.

Sure, that hasn't changed. My point is only that we ought not special 
case messaging here. If people in deployments need intermediaries, they 
will do what they have already been doing for voice, mucking with sdp, 
despite the lack of blessing from ietf.



> 
> Next question - this business of introducing intermediaries only for IM;
> we should re-visit it. As has been noted in preceding conversations - in
> the standards we do no such thing for other media like voice and video.

I was proposing not to special case messaging.

-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


From hisham.khartabil@nokia.com  Thu Jul 25 03:14:41 2002
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 DAA14542
	for ; Thu, 25 Jul 2002 03:14:40 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6P7FCi02166
	for ; Thu, 25 Jul 2002 10:15:12 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 25 Jul 2002 10:14:39 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 25 Jul 2002 10:14:39 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message session & associated dialog
Date: Thu, 25 Jul 2002 10:14:38 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2040C@esebe019.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message session & associated dialog
Thread-Index: AcIzN6dalLEkFPIgTyGm7fGXI8yfMwAcuIMQ
To: , 
Cc: , ,
        , ,
        , 
X-OriginalArrivalTime: 25 Jul 2002 07:14:39.0619 (UTC) FILETIME=[F0BD4D30:01C233AA]
Content-Length: 1630
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA14542
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: 


> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Wednesday, July 24, 2002 8:29 PM
> To: Jonathan Rosenberg
> Cc: Khartabil Hisham (NMP/Helsinki); seancolson@yahoo.com; Niemi Aki
> (NET/Espoo); peter.paeppinghaus@icn.siemens.de;
> bcampbell@dynamicsoft.com; mhammer@cisco.com;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Message session & associated dialog
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > I believe the CSeq numbering space is identified by the 
> local request
> > URI (i.e., the value in the r-uri seen by the UAS that receives the
> > message) combined with the From field, which would then identify the
> > sender. Since there is no dialog here, there is no 
> requirement that the
> >  From field be the same for each message, and it can 
> actually reflect
> > the originator of that specific message.
> 
> I don't think the From is necessarily unique here.
> 
> Suppose I initially made a call to you from my desktop pc 
> here, setting up a message session. Once we get chatting, I 
> have to go to a meeting, so I transfer my end of the
> call to my laptop pc.
> 
> Both pcs are registered as separate Contacts for my same 
> address of record, and typically the AoR is what would be 
> placed in the from address.
> 
> During the reinvite transition, you may be getting messages 
> from both pcs, using same From address.
> 
> As an alternative, the address in the first Via header might 
> be sufficiently unique.


I think Jonathan was talking about the From-header in the media (MESSAGE) and not the signalling (INVITE).

Hisham


> 
> 	Paul
> 

From pkyzivat@cisco.com  Thu Jul 25 12:50:24 2002
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 MAA16226
	for ; Thu, 25 Jul 2002 12:50:23 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6PGooGZ001305;
	Thu, 25 Jul 2002 12:50:50 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN86095;
	Thu, 25 Jul 2002 12:54:53 -0400 (EDT)
Message-ID: <3D402C43.2B9F5A8D@cisco.com>
Date: Thu, 25 Jul 2002 12:50:11 -0400
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: hisham.khartabil@nokia.com
CC: jdrosen@dynamicsoft.com, seancolson@yahoo.com, aki.niemi@nokia.com,
        peter.paeppinghaus@icn.siemens.de, bcampbell@dynamicsoft.com,
        mhammer@cisco.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <2038BCC78B1AD641891A0D1AE133DBB7C2040C@esebe019.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1377
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: 


hisham.khartabil@nokia.com wrote:
> 
> > I don't think the From is necessarily unique here.
> >
> > Suppose I initially made a call to you from my desktop pc
> > here, setting up a message session. Once we get chatting, I
> > have to go to a meeting, so I transfer my end of the
> > call to my laptop pc.
> >
> > Both pcs are registered as separate Contacts for my same
> > address of record, and typically the AoR is what would be
> > placed in the from address.
> >
> > During the reinvite transition, you may be getting messages
> > from both pcs, using same From address.
> >
> > As an alternative, the address in the first Via header might
> > be sufficiently unique.
> 
> I think Jonathan was talking about the From-header in the media (MESSAGE) and not the signalling (INVITE).

So was I. The scenario is moving both the call leg and the media termination from on pc to the other. I would expect (but this is subject to discussion) that the MESSAGEs
sent in the media session would still list the Address of Record of the pc as the From address, rather than the pc-specific Contact address. To do otherwise could mess up
the UI for the IM session. It may be using the From address to identify the sender of each message. (If the messages are text rather than CPIM format.)

I don't think it is safe to assume that the From will be unique from source to source.

	Paul

From nsyracus@cnri.reston.va.us  Fri Jul 26 08:11:57 2002
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 IAA19279
	for ; Fri, 26 Jul 2002 08:11:57 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16056;
	Fri, 26 Jul 2002 08:10:50 -0400 (EDT)
Message-Id: <200207261210.IAA16056@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 26 Jul 2002 08:10:50 -0400
Content-Length: 3309
Subject: [Simple] I-D ACTION:draft-ietf-sip-message-06.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-sip-message-06.txt
	Pages		: 22
	Date		: 25-Jul-02
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-message-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-message-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020725151406.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-message-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-message-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020725151406.I-D@ietf.org>

--OtherAccess--

--NextPart--



From adam@dynamicsoft.com  Fri Jul 26 14:34:30 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20345
	for ; Fri, 26 Jul 2002 14:34:30 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QIY8CU003732;
	Fri, 26 Jul 2002 14:34:09 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <306AP5SM>; Fri, 26 Jul 2002 13:34:28 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A32C@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Paul Kyzivat'" , hisham.khartabil@nokia.com
Cc: Jonathan Rosenberg , seancolson@yahoo.com,
        aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de,
        Ben Campbell
	 , mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Message session & associated dialog
Date: Fri, 26 Jul 2002 13:34:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 242
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: 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> 
> I don't think it is safe to assume that the From will be 
> unique from source to source.

Isn't this the exact reason the "tag" parameter was introduced?

/a

From seancolson@yahoo.com  Fri Jul 26 15:17:02 2002
Received: from web11606.mail.yahoo.com (web11606.mail.yahoo.com [216.136.172.58])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id PAA20483
	for ; Fri, 26 Jul 2002 15:17:01 -0400 (EDT)
Message-ID: <20020726191701.90905.qmail@web11606.mail.yahoo.com>
Received: from [131.107.3.75] by web11606.mail.yahoo.com via HTTP; Fri, 26 Jul 2002 12:17:01 PDT
Date: Fri, 26 Jul 2002 12:17:01 -0700 (PDT)
From: Sean Olson 
Subject: RE: [Simple] Message session & associated dialog
To: Adam Roach , "'Paul Kyzivat'" ,
        hisham.khartabil@nokia.com
Cc: Jonathan Rosenberg , seancolson@yahoo.com,
        aki.niemi@nokia.com, peter.paeppinghaus@icn.siemens.de,
        Ben Campbell , mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F377A32C@DYN-TX-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 681
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: 

Hmmm. Tag will work in this case (within a dialog),
but the tag doesn't really differentiate a source
outside of a dialog. Kinda ugly unless we have a
single dialog ID for this message session (at
the MESSAGE level)

Sean Olson
Microsoft

--- Adam Roach  wrote:
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > 
> > I don't think it is safe to assume that the From
> will be 
> > unique from source to source.
> 
> Isn't this the exact reason the "tag" parameter was
> introduced?
> 
> /a


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

From adam@dynamicsoft.com  Fri Jul 26 16:00:09 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20646
	for ; Fri, 26 Jul 2002 16:00:09 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QJxkCU004510;
	Fri, 26 Jul 2002 15:59:46 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <306AP54Q>; Fri, 26 Jul 2002 15:00:06 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A32F@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Sean Olson'" , Adam Roach ,
        "'Paul Kyzivat'" , hisham.khartabil@nokia.com
Cc: Jonathan Rosenberg , aki.niemi@nokia.com,
        peter.paeppinghaus@icn.siemens.de,
        Ben Campbell
	 , mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Message session & associated dialog
Date: Fri, 26 Jul 2002 15:00:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1068
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: 

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
> 
> Hmmm. Tag will work in this case (within a dialog),
> but the tag doesn't really differentiate a source
> outside of a dialog. 

  "When a tag is generated by a UA for insertion into a request or
   response, it MUST be globally unique and cryptographically random
   with at least 32 bits of randomness." [RFC3261]

Working through the math, this gives about a 0.00000000069849%
chance of collision between two sources, and 0.00000001280569% 
chance of any collision amongst 10 sources.

Heck, even with 1000 contributors, your chances of collision
are still around 0.0001%.

I suspect these numbers are good enough for demultiplexing
sources in an IM session -- especially when you consider that the
consequences of failure are close to negligible.

If anyone considers this unacceptable, perhaps we can suggest a
syntax of "tag=32-bits-of-randomness!host.domain" for session-mode
messages.

/a

P.S. Can you tell that I've been working with birthday-paradox
     problems recently?

From pkyzivat@cisco.com  Fri Jul 26 18:30:38 2002
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 SAA21110
	for ; Fri, 26 Jul 2002 18:30:33 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6QMUqDN017392;
	Fri, 26 Jul 2002 18:30:53 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAN95331;
	Fri, 26 Jul 2002 18:35:00 -0400 (EDT)
Message-ID: <3D41CD79.D094D694@cisco.com>
Date: Fri, 26 Jul 2002 18:30:17 -0400
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 
CC: hisham.khartabil@nokia.com, Jonathan Rosenberg ,
        seancolson@yahoo.com, aki.niemi@nokia.com,
        peter.paeppinghaus@icn.siemens.de,
        Ben Campbell , mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Message session & associated dialog
References: <9BF66EBF6BEFD942915B4D4D45C051F377A32C@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 885
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: 


Adam Roach wrote:
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >
> > I don't think it is safe to assume that the From will be
> > unique from source to source.
> 
> Isn't this the exact reason the "tag" parameter was introduced?
> 
> /a

I don't think so. For purposes of sip signalling, the MESSAGEs in a message session aren't part of the dialog of the INVITE that established the session. They aren't part
of any dialog. So either each MESSAGE gets a new tag in its From header, or else it gets no tag at all. It would definitely be wrong for them to get the tag from the dialog
of the INVITE.

(Do messages get a tag on the From if they don't establish a dialog and aren't part of a dialog?)

So the from tag is useless for this purpose.

	Paul

BTW - I'm going to be gone for a week or so, so you can finish this discussion without me.

From adam@dynamicsoft.com  Fri Jul 26 18:36:32 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21146
	for ; Fri, 26 Jul 2002 18:36:32 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g6QMaBCU005483;
	Fri, 26 Jul 2002 18:36:12 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <306AP5V7>; Fri, 26 Jul 2002 17:36:27 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F377A331@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Paul Kyzivat'" , Adam Roach 
Cc: hisham.khartabil@nokia.com, Jonathan Rosenberg
	 ,
        seancolson@yahoo.com, aki.niemi@nokia.com,
        peter.paeppinghaus@icn.siemens.de,
        Ben Campbell
	 , mhammer@cisco.com,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Message session & associated dialog
Date: Fri, 26 Jul 2002 17:36:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 838
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: 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> 
> Adam Roach wrote:
> > 
> > > -----Original Message-----
> > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > >
> > > I don't think it is safe to assume that the From will be
> > > unique from source to source.
> > 
> > Isn't this the exact reason the "tag" parameter was introduced?
> > 
> > /a
> 
> I don't think so. For purposes of sip signalling, the 
> MESSAGEs in a message session aren't part of the dialog of 
> the INVITE that established the session. They aren't part
> of any dialog. So either each MESSAGE gets a new tag in its 
> From header, or else it gets no tag at all.

You're right. Since there is no dialog, they won't match.
Mea culpa.

So, I'd agree, then, that we need something equivalent to
SSRC for session-mode messages.

/a

From bindignavile.srinivas@nokia.com  Sat Jul 27 16:22:05 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24880
	for ; Sat, 27 Jul 2002 16:22:04 -0400 (EDT)
From: bindignavile.srinivas@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6RKXlf24713
	for ; Sat, 27 Jul 2002 23:33:47 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Sat, 27 Jul 2002 01:35:32 +0300
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Sat, 27 Jul 2002 01:35:32 +0300
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 26 Jul 2002 17:35:25 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 26 Jul 2002 18:35:24 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question about SIP-CGI
Thread-Index: AcI09LkBpAbJuy7MSUWOSPyLMJGO3w==
To: 
X-OriginalArrivalTime: 26 Jul 2002 22:35:25.0675 (UTC) FILETIME=[BC5E33B0:01C234F4]
Content-Length: 796
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id QAA24880
Subject: [Simple] Question about SIP-CGI
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: 

Hi,
I wasnt sure if this was the WG to which I should direct this question. But here goes!

We have been creating a CGI script in PERL with the script called by a proxy server. We have been able to clarify the use of environment variables for inputting data to the script. However, for the data output from the script to the proxy server, that is where we were confused. The references we looked at state that CGI communicates output to the server through stdout. In the case of a web server where the output data has to be in the form of HTML code, we were clear about the issues. However, when the script communicates with a SIP server, how exactly does one convey the output (of the script) to the proxy server? Some clarification about this issue will be greatly appreciated.

Thanks,
-Srini

From rohan@cisco.com  Mon Jul 29 13:03:51 2002
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01614
	for ; Mon, 29 Jul 2002 13:03:50 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g6TH3ihI014035;
	Mon, 29 Jul 2002 10:03:44 -0700 (PDT)
Received: from open-131-161-248-91.cliq.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with ESMTP id AAO89579;
	Mon, 29 Jul 2002 10:02:38 -0700 (PDT)
Date: Mon, 29 Jul 2002 10:03:49 -0700
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v482)
Cc: Sriram Parameswar , hisham.khartabil@nokia.com,
        simple@mailman.dynamicsoft.com
To: Jonathan Rosenberg 
From: Rohan Mahy 
In-Reply-To: <3D3F95BC.7010003@dynamicsoft.com>
Message-Id: <271534BD-A315-11D6-B41F-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.482)
Content-Length: 1883
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: 

On Wednesday, July 24, 2002, at 11:07 PM, Jonathan Rosenberg wrote:

>
>
> Sriram Parameswar wrote:
>> I am a little confused by this talk of proxies messing around with the
>> SDP *without* using session-policy. I distinctly remember that such
>> proxies were labelled BBUA's and BBUA's were  considered evil.
>
> Sure, that hasn't changed. My point is only that we ought not special 
> case messaging here. If people in deployments need intermediaries, they 
> will do what they have already been doing for voice, mucking with sdp, 
> despite the lack of blessing from ietf.

Well, alternatively we could take a similar approach to the identity 
draft.  intermediaries can reject offers and answers for a variety of 
reasons (can't see the SDP to open pinholes (firewall controller), or 
the SDP violates some local administrative policy (not authorized to use 
as much bandwidth), or the controller suggests a new SDP in the 
rejection (ex: a NAT-style middlebox controller).  all of this is 
totally in the purview of a proxy.

thx,
-r

>> Next question - this business of introducing intermediaries only for 
>> IM;
>> we should re-visit it. As has been noted in preceding conversations - 
>> in
>> the standards we do no such thing for other media like voice and video.
>
> I was proposing not to special case messaging.
agreed!

> -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 rsparks@dynamicsoft.com  Mon Jul 29 16:25:08 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02159
	for ; Mon, 29 Jul 2002 16:25:07 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6TEZA129168
	for ; Mon, 29 Jul 2002 09:35:10 -0500
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) 
Date: 29 Jul 2002 15:20:53 -0500
Message-Id: <1027974053.7113.2.camel@dhcp112.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 283
Subject: [Simple] Supplemental website
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: 

At the request of many, I've put together a supplemental
weblet for SIMPLE similar to those for SIP and SIPPING.

See

http://www.softarmor.com/simple

Send errors and omissions to rsparks@dynamicsoft.com.

Many thanks to Dean Willis for maintaining the server this
runs on.

RjS




From rsparks@dynamicsoft.com  Wed Jul 31 10:01:43 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09045
	for ; Wed, 31 Jul 2002 10:01:43 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g6V8Bm129649
	for ; Wed, 31 Jul 2002 03:11:48 -0500
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) 
Date: 31 Jul 2002 09:01:11 -0500
Message-Id: <1028124071.2826.2.camel@dhcp242.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 239
Subject: [Simple] comments on notes needed for minutes
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: 

If you participated in the SIMPLE meeting
at IETF54, please take a few minutes to
look through the rough notes at

http://www.softarmor.com/simple/meets/ietf54/notes/notes.html

and send corrections/amendments to me ASAP.

Thanks!

RjS




From rsparks@dynamicsoft.com  Fri Aug  2 10:17:03 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20727
	for ; Fri, 2 Aug 2002 10:17:03 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g728R8130444;
	Fri, 2 Aug 2002 03:27:08 -0500
Subject: Re: [Simple] comments on notes needed for minutes
From: Robert Sparks 
To: Robert Sparks 
Cc: simple@mailman.dynamicsoft.com
In-Reply-To: <1028124071.2826.2.camel@dhcp242.dfw.dynamicsoft.com>
References: <1028124071.2826.2.camel@dhcp242.dfw.dynamicsoft.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) 
Date: 02 Aug 2002 09:16:26 -0500
Message-Id: <1028297786.2593.1.camel@dhcp151.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 572
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: 

Minutes are now at
http://www.softarmor.com/simple/meets/ietf54/notes/minutes.html

RjS

On Wed, 2002-07-31 at 09:01, Robert Sparks wrote:
> If you participated in the SIMPLE meeting
> at IETF54, please take a few minutes to
> look through the rough notes at
> 
> http://www.softarmor.com/simple/meets/ietf54/notes/notes.html
> 
> and send corrections/amendments to me ASAP.
> 
> Thanks!
> 
> RjS
> 
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple





From jpc@snt.BellSouth.com  Mon Aug  5 08:53:40 2002
Received: from blsmsgims03.bls.com (connectandcreate2.bls.com [139.76.64.29])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00966
	for ; Mon, 5 Aug 2002 08:53:39 -0400 (EDT)
From: jpc@snt.BellSouth.com
Received: from blsmsgnav03 ([139.76.86.161]) by blsmsgims03.bls.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id PZLNZDAA; Mon, 5 Aug 2002 08:53:37 -0400
Received: from snt.bellsouth.com ([90.30.215.1])
 by blsmsgnav03 (NAVIEG 2.1 bld 75) with SMTP id M2002080508533628442
 ; Mon, 05 Aug 2002 08:53:36 -0400
Received: from PCJPC (pcjpc [90.30.214.205])
	by snt.bellsouth.com (8.9.3+Sun/8.9.1) with ESMTP id IAA20449;
	Mon, 5 Aug 2002 08:53:37 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15694.29568.844000.652799@gargle.gargle.HOWL>
Date: Mon, 5 Aug 2002 08:45:52 -0400
To: sip-implementors@cs.columbia.edu, simple@mailman.dynamicsoft.com
X-Mailer: VM 7.04 under Emacs 21.2.1
Content-Length: 3022
Subject: [Simple] Presence support in Microsoft Messenger
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: 

Anybody have any information regarding what drafts Microsoft Messenger is
following with regard to Presence and Instant Messaging ?  I saw a post 

http://mailman.dynamicsoft.com/pipermail/simple/2002-April/001513.html

stating that it extends XPIDF.  So I am assuming it embraces the following two
drafts: draft-ietf-simple-presence-01, draft-rosenberg-impp-pidf-00. Am I
correct ?

I tried my own test with MSN Messenger, and I got a "488 Not Acceptable Here"
back from Messenger.  Any ideas ?  I have included the flow below.

Also, when I tried to capture some packet traces when I go to the .Net
service and not to a communication service, I do not get SIP messages. So Microsoft
only uses SIP when you are talking to a "Communication Service" as defined under
their "Tools...Options...Accounts" menu ??  Is it some proprietary protocol to
.Net ?  I am using MSN Messenger 4.6.0082.

Thanks,
  Jeff

------------------------------------------------------
> PresenceServer Received
SUBSCRIBE sip:90.30.214.202 SIP/2.0
Via: SIP/2.0/UDP 90.30.214.202:5060;branch=e037c25e293b413671df40be3716e038.cc66b4b80af2f8cc73a3f86b492f52de
Via: SIP/2.0/UDP 90.30.214.205:8460
From: "4043351643" ;tag=884a1ddc-5170-4482-864d-c6785d3f1d72
To: 
Call-ID: 10285492125821@90.30.214.202
CSeq: 1 SUBSCRIBE
Contact:
User-Agent:Windows RTC/1.0
Expires:1800
Content-Length: 0
Record-Route:

< PresenceServer sent out
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 90.30.214.202:5060;branch=e037c25e293b413671df40be3716e038.cc66b4b80af2f8cc73a3f86b492f52de
Via: SIP/2.0/UDP 90.30.214.205:8460
From: "4043351643" ;tag=884a1ddc-5170-4482-864d-c6785d3f1d72
To: ;tag=540769738
Call-ID: 10285492125821@90.30.214.202
CSeq: 1 SUBSCRIBE
Record-Route: 
Content-Length: 0
Expires: 360


< PreseneceServer sent out
NOTIFY sip:90.30.214.202:5060 SIP/2.0
From: ;tag=540769738
To: ;tag=884a1ddc-5170-4482-864d-c6785d3f1d72
Contact: sip:90.30.214.205:8460
Call-ID: 10285492125821@90.30.214.202
CSeq: 1 NOTIFY
Content-Length: 359
Event: presence
Subscription-State: active;expires="359"
Content-Type: application/xpidf+xml
















> PresenceServer received
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 90.30.214.202:5050
From: ;tag=540769738
To: "4043351643" ;tag=884a1ddc-5170-4482-864d-c6785d3f1d72
Call-ID: 10285492125821@90.30.214.202
CSeq: 1 NOTIFY
User-Agent:Windows RTC/1.0
Content-Length: 0


From pphilip@npd.hcltech.com  Mon Aug  5 09:13:47 2002
Received: from hclnpd.hclt.co.in ([202.54.64.7])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01047
	for ; Mon, 5 Aug 2002 09:13:46 -0400 (EDT)
Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id QJR5XXD5; Mon, 5 Aug 2002 18:43:24 +0530
Received: from pphilippc (pphilip-pc.hclt-ntl.co.in [192.168.19.93])
	by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with SMTP id g75D64M31599;
	Mon, 5 Aug 2002 18:36:05 +0530
Message-ID: <003301c23c81$79335450$5d13a8c0@hcltntl.co.in>
From: "Prince A.P." 
To: , ,
        
References: <15694.29568.844000.652799@gargle.gargle.HOWL>
Subject: Re: [Simple] Presence support in Microsoft Messenger
Date: Mon, 5 Aug 2002 18:40:25 +0530
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
Content-Length: 3902
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: 

MSN Messenger is using SIP only when we select "communication service" in
accounts tab.For .net passport account it is not using SIP.
some links..
http://www.microsoft.com/windowsxp/pro/techinfo/planning/networking/windowsm
essenger.asp
http://www.microsoft.com/presspass/Features/2001/Jun01/06-04messenger.asp

thanks,
prince

----- Original Message -----
From: 
To: ; 
Sent: Monday, August 05, 2002 6:15 PM
Subject: [Simple] Presence support in Microsoft Messenger


> Anybody have any information regarding what drafts Microsoft Messenger is
> following with regard to Presence and Instant Messaging ?  I saw a post
>
> http://mailman.dynamicsoft.com/pipermail/simple/2002-April/001513.html
>
> stating that it extends XPIDF.  So I am assuming it embraces the following
two
> drafts: draft-ietf-simple-presence-01, draft-rosenberg-impp-pidf-00. Am I
> correct ?
>
> I tried my own test with MSN Messenger, and I got a "488 Not Acceptable
Here"
> back from Messenger.  Any ideas ?  I have included the flow below.
>
> Also, when I tried to capture some packet traces when I go to the .Net
> service and not to a communication service, I do not get SIP messages. So
Microsoft
> only uses SIP when you are talking to a "Communication Service" as defined
under
> their "Tools...Options...Accounts" menu ??  Is it some proprietary
protocol to
> .Net ?  I am using MSN Messenger 4.6.0082.
>
> Thanks,
>   Jeff
>
> ------------------------------------------------------
> > PresenceServer Received
> SUBSCRIBE sip:90.30.214.202 SIP/2.0
> Via: SIP/2.0/UDP
90.30.214.202:5060;branch=e037c25e293b413671df40be3716e038.cc66b4b80af2f8cc7
3a3f86b492f52de
> Via: SIP/2.0/UDP 90.30.214.205:8460
> From: "4043351643"
;tag=884a1ddc-5170-4482-864d-c6785d3f1d72
> To: 
> Call-ID: 10285492125821@90.30.214.202
> CSeq: 1 SUBSCRIBE
> Contact:
> User-Agent:Windows RTC/1.0
> Expires:1800
> Content-Length: 0
> Record-Route:
>
> < PresenceServer sent out
> SIP/2.0 200 Ok
> Via: SIP/2.0/UDP
90.30.214.202:5060;branch=e037c25e293b413671df40be3716e038.cc66b4b80af2f8cc7
3a3f86b492f52de
> Via: SIP/2.0/UDP 90.30.214.205:8460
> From: "4043351643"
;tag=884a1ddc-5170-4482-864d-c6785d3f1d72
> To: ;tag=540769738
> Call-ID: 10285492125821@90.30.214.202
> CSeq: 1 SUBSCRIBE
> Record-Route: 
> Content-Length: 0
> Expires: 360
>
>
> < PreseneceServer sent out
> NOTIFY sip:90.30.214.202:5060 SIP/2.0
> From: ;tag=540769738
> To: ;tag=884a1ddc-5170-4482-864d-c6785d3f1d72
> Contact: sip:90.30.214.205:8460
> Call-ID: 10285492125821@90.30.214.202
> CSeq: 1 NOTIFY
> Content-Length: 359
> Event: presence
> Subscription-State: active;expires="359"
> Content-Type: application/xpidf+xml
>
> 
>  PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd">
> 
> 
> 
> 

> 
> 
> 

> 
> 
>
>
> > PresenceServer received
> SIP/2.0 488 Not Acceptable Here
> Via: SIP/2.0/UDP 90.30.214.202:5050
> From: ;tag=540769738
> To: "4043351643" ;tag=884a1ddc-5170-4482-864d-c6785d3f1d72
> Call-ID: 10285492125821@90.30.214.202
> CSeq: 1 NOTIFY
> User-Agent:Windows RTC/1.0
> Content-Length: 0
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From krisztian.kiss@nokia.com  Tue Aug 13 08:22:57 2002
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 IAA04720
	for ; Tue, 13 Aug 2002 08:22:56 -0400 (EDT)
From: krisztian.kiss@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7DCMvV10904
	for ; Tue, 13 Aug 2002 15:22:57 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Tue, 13 Aug 2002 15:22:56 +0300
Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 13 Aug 2002 15:22:55 +0300
Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 13 Aug 2002 15:22:55 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 13 Aug 2002 15:22:55 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 3GPP Presence requirements I-D to IETF, review #1
Thread-Index: AcIMp1PMcnPotniUEdaaOwAQpJJIjwAhPmOgAAC+VQAAAXqwAAAJsGAwAA5rKRAAqycPkAA87SoQAATVl7AAAL6L8AAAQzMwAADBslAAAXJfEAApv49AC297ayAAAKBaEACoy/hgAAwndVAACd9DAA==
To: 
X-OriginalArrivalTime: 13 Aug 2002 12:22:55.0587 (UTC) FILETIME=[270B4B30:01C242C4]
Content-Length: 1762
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA04720
Subject: [Simple] 3GPP Presence requirements I-D: how the requirements are handled
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: 

Hi,

IETF54 made a consensus about integrating the 3GPP Presence requirements (http://www.softarmor.com/simple/drafts/draft-kiss-simple-presence-wireless-reqs-00.txt) into the chartered requirements document. I assume the integration could be done for most of the requirements, however we might need further discussions for some of the "tricky" requirements. Hereby I have tried collecting these:

1. Filtering. The minutes of the SIMPLE session states: "there are requirements for filtering in a lot of our discussions, we should add to charter." I guess there is consensus here, so filtering should be added to SIMPLE charter.
2. Partial publication/notification: during the SIMPLE session it was commented that CPIM and partial notification are conflicting requirements. This requirement is considered an important feature for wireless environment, however I am not sure how to resolve the conflict with CPIM. See also related mail in http://mailman.dynamicsoft.com/pipermail/simple/2002-July/001691.html
3. Anonymous subscription: I guess this requirement can be fulfilled by defining authorization rules for anonymous subscribers.
4. "Keep all PUAs aware of each other's publishing": this requirement might be fulfilled with the solution when every PUA subscribes to its own presence. Using filtering mechanisms, the PUA could filter out its own publication when receiving notifications in order to save bandwidth. 
5. Location information: during the SIMPLE session this was found problematic because of authorization issues around who can update and/or see geoloc information.

I assume for the other requirements that those are found valid and will be mirrored in the chartered requirements I-D. Please comment if you think otherwise.

Thanks,
Krisztian

From seancolson@yahoo.com  Tue Aug 13 11:39:23 2002
Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA05299
	for ; Tue, 13 Aug 2002 11:39:23 -0400 (EDT)
Received: from 12-235-146-159.client.attbi.com (HELO BOB) (seancolson@12.235.146.159 with login)
  by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Aug 2002 15:39:23 -0000
Reply-To: 
From: "Sean Olson" 
To: , 
Subject: RE: [Simple] 3GPP Presence requirements I-D: how the requirements are handled
Date: Tue, 13 Aug 2002 08:39:35 -0700
Message-ID: <006d01c242df$a11b5b20$6401a8c0@BOB>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081
Importance: Normal
Content-Length: 2409
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: 

Partial notification can also be solved through filtering.
Partial publication makes no sense to me. Could you elaborate
on what you need for partial publication?

Thanks,
Sean

-----Original Message-----
From: simple-admin@mailman.dynamicsoft.com
[mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of
krisztian.kiss@nokia.com
Sent: Tuesday, August 13, 2002 5:23 AM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] 3GPP Presence requirements I-D: how the requirements
are handled


Hi,

IETF54 made a consensus about integrating the 3GPP Presence requirements
(http://www.softarmor.com/simple/drafts/draft-kiss-simple-presence-wirel
ess-reqs-00.txt) into the chartered requirements document. I assume the
integration could be done for most of the requirements, however we might
need further discussions for some of the "tricky" requirements. Hereby I
have tried collecting these:

1. Filtering. The minutes of the SIMPLE session states: "there are
requirements for filtering in a lot of our discussions, we should add to
charter." I guess there is consensus here, so filtering should be added
to SIMPLE charter. 2. Partial publication/notification: during the
SIMPLE session it was commented that CPIM and partial notification are
conflicting requirements. This requirement is considered an important
feature for wireless environment, however I am not sure how to resolve
the conflict with CPIM. See also related mail in
http://mailman.dynamicsoft.com/pipermail/simple/2002-July/001691.html
3. Anonymous subscription: I guess this requirement can be fulfilled by
defining authorization rules for anonymous subscribers. 4. "Keep all
PUAs aware of each other's publishing": this requirement might be
fulfilled with the solution when every PUA subscribes to its own
presence. Using filtering mechanisms, the PUA could filter out its own
publication when receiving notifications in order to save bandwidth. 
5. Location information: during the SIMPLE session this was found
problematic because of authorization issues around who can update and/or
see geoloc information.

I assume for the other requirements that those are found valid and will
be mirrored in the chartered requirements I-D. Please comment if you
think otherwise.

Thanks,
Krisztian
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From jdrosen@dynamicsoft.com  Wed Aug 14 03:14:07 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08142
	for ; Wed, 14 Aug 2002 03:14:07 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.83])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7E7E9YH001950;
	Wed, 14 Aug 2002 03:14:10 -0400 (EDT)
Message-ID: <3D5A033F.4070208@dynamicsoft.com>
Date: Wed, 14 Aug 2002 03:14:07 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: krisztian.kiss@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] 3GPP Presence requirements I-D: how the requirements
 are	 handled
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3156
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: 

inline:

krisztian.kiss@nokia.com wrote:
> Hi,
> 
> IETF54 made a consensus about integrating the 3GPP Presence requirements
> (http://www.softarmor.com/simple/drafts/draft-kiss-simple-presence-wirel
> ess-reqs-00.txt) into the chartered requirements document. I assume the
> integration could be done for most of the requirements, however we might
> need further discussions for some of the "tricky" requirements. Hereby I
> have tried collecting these:
> 
> 1. Filtering. The minutes of the SIMPLE session states: "there are
> requirements for filtering in a lot of our discussions, we should add to
> charter." I guess there is consensus here, so filtering should be added
> to SIMPLE charter.

I agree filtering is important. What is not clear is whether we should 
start with requirements, and where those should be done, and then where 
the filtering work should occur. I suppose that, since its not a sip 
extension per se, SIMPLE would be OK. However, I would hope that the 
work is not presence specific, and would be generally useful for sip events.


> 2. Partial publication/notification: during the SIMPLE session it was
> commented that CPIM and partial notification are conflicting
> requirements. This requirement is considered an important feature for
> wireless environment, however I am not sure how to resolve the conflict
> with CPIM. See also related mail in
> http://mailman.dynamicsoft.com/pipermail/simple/2002-July/001691.html

It is not at all clear to me that this will actually save you anything. 
I suspect that SIGCOMP would, right now, give you much better overall 
bandwidth utilization than partial notifications. There is simply not a 
sufficient amount of data in the presence for a single user to warrant 
partial updates, IMHO.



> 3. Anonymous subscription: I guess this requirement can be fulfilled by
> defining authorization rules for anonymous subscribers.

Yes.


> 4. "Keep all PUAs aware of each other's publishing": this requirement
> might be fulfilled with the solution when every PUA subscribes to its
> own presence. Using filtering mechanisms, the PUA could filter out its
> own publication when receiving notifications in order to save bandwidth.

I asked this during the meeting, and I will ask again - why?

The whole model of presence is that each PUA is independent. They don't 
need, and in fact, don't want, to know the details of the other PUA 
publishing for the presentity. Indeed, I can imagine cases where a PUA 
is authorized to publish for a presentity, but not authorized to see its 
presence! Consider the case of a web server that publishes information 
on the web page I am currently browsing; I might not want that site to 
know anything about me; but its OK for it to publish that I am currently 
browsing their site.


-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


From krisztian.kiss@nokia.com  Wed Aug 14 09:17:11 2002
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 JAA09284
	for ; Wed, 14 Aug 2002 09:17:10 -0400 (EDT)
From: krisztian.kiss@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7EDFOl20832
	for ; Wed, 14 Aug 2002 16:15:24 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 14 Aug 2002 16:17:09 +0300
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 14 Aug 2002 16:17:09 +0300
Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 14 Aug 2002 16:17:09 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] 3GPP Presence requirements I-D: how the requirementsare	 handled
Date: Wed, 14 Aug 2002 16:17:08 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] 3GPP Presence requirements I-D: how the requirementsare	 handled
Thread-Index: AcJDYjEmIhFFYVr7Ts+ESmTKLeUVlgAMKggw
To: 
Cc: 
X-OriginalArrivalTime: 14 Aug 2002 13:17:09.0021 (UTC) FILETIME=[E4A7ACD0:01C24394]
Content-Length: 4551
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA09284
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: 

Hi,

> > IETF54 made a consensus about integrating the 3GPP Presence 
> requirements
> > 
> (http://www.softarmor.com/simple/drafts/draft-kiss-simple-pres
> ence-wirel
> > ess-reqs-00.txt) into the chartered requirements document. 
> I assume the
> > integration could be done for most of the requirements, 
> however we might
> > need further discussions for some of the "tricky" 
> requirements. Hereby I
> > have tried collecting these:
> > 
> > 1. Filtering. The minutes of the SIMPLE session states: "there are
> > requirements for filtering in a lot of our discussions, we 
> should add to
> > charter." I guess there is consensus here, so filtering 
> should be added
> > to SIMPLE charter.
> 
> I agree filtering is important. What is not clear is whether 
> we should 
> start with requirements, and where those should be done, and 
> then where 
> the filtering work should occur. I suppose that, since its not a sip 
> extension per se, SIMPLE would be OK. However, I would hope that the 
> work is not presence specific, and would be generally useful 
> for sip events.

I agree that we should go for a general "sip-events" filtering. Probably SIMPLE would be the best place for this.
I guess quick requirements I-D would be useful, we could even come up with one if there is consensus on it.
 
> > 2. Partial publication/notification: during the SIMPLE 
> session it was
> > commented that CPIM and partial notification are conflicting
> > requirements. This requirement is considered an important 
> feature for
> > wireless environment, however I am not sure how to resolve 
> the conflict
> > with CPIM. See also related mail in
> > 
> http://mailman.dynamicsoft.com/pipermail/simple/2002-July/001691.html
> 
> It is not at all clear to me that this will actually save you 
> anything. 
> I suspect that SIGCOMP would, right now, give you much better overall 
> bandwidth utilization than partial notifications. There is 
> simply not a 
> sufficient amount of data in the presence for a single user 
> to warrant 
> partial updates, IMHO.

I try to make a simple example: let's assume that a JPEG picture is part of my presence information. I usually do not want to update the picture, however from time to time I want to change my picture in order to keep my watchers up-to-date. If I don't need to send my unchanged picture in every PUBLISH and my watchers don't receive it in every NOTIFY (only when it has changed), then I think we manage to save a lot of bandwidth. Certainly in this case the PUBLISH/NOTIFY is always dependent on the previous one. 
I guess pictures/logos/tones can be considered as soft state, if always one of them is associated with one profile in the phone. SIGCOMP only saves bandwidth in the air interface (in 3GPP environment), while with partial publication/notification we could also save bandwidth in the whole network.
I hope this also answers Sean's concerns.

> > 4. "Keep all PUAs aware of each other's publishing": this 
> requirement
> > might be fulfilled with the solution when every PUA 
> subscribes to its
> > own presence. Using filtering mechanisms, the PUA could 
> filter out its
> > own publication when receiving notifications in order to 
> save bandwidth.
> 
> I asked this during the meeting, and I will ask again - why?
> 
> The whole model of presence is that each PUA is independent. 
> They don't 
> need, and in fact, don't want, to know the details of the other PUA 
> publishing for the presentity. Indeed, I can imagine cases 
> where a PUA 
> is authorized to publish for a presentity, but not authorized 
> to see its 
> presence! Consider the case of a web server that publishes 
> information 
> on the web page I am currently browsing; I might not want 
> that site to 
> know anything about me; but its OK for it to publish that I 
> am currently 
> browsing their site.

Perhaps it is not clear for me what the PUBLISH draft says about this, but what happens if the same information (i.e. the same tuple) can be updated from multiple PUAs? (e.g. I am logged on to the same IM application from two devices)
It might be so that the PUAs should not care about each others publishing, so the compositor should be responsible to realize that the different publishers publish the same information and it should always notify the watchers about the latest published information.
It would be also useful for the PUA to know what happened with its publication. E.g. if it publishes status=closed, but the presence document says status=open for some reason.

Thanks,
Krisztian

From Fred.Oleary@sylantro.com  Fri Aug 16 17:30:50 2002
Received: from mailserver.sylantro.com ([65.200.90.207])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA18510
	for ; Fri, 16 Aug 2002 17:30:49 -0400 (EDT)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7);); Fri, 16 Aug 2002 14:29:57 -0700
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <1Y4A9AL2>; Fri, 16 Aug 2002 14:29:56 -0700
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD01A7785C@mailserver.sylantro.com>
From: "Fred O'Leary" 
To: simple@mailman.dynamicsoft.com
Date: Fri, 16 Aug 2002 14:29:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 1143B15F438015-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Length: 609
Subject: [Simple] draft-ietf-sipping-dialog-package-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: 

Hi,
draft-ietf-sipping-dialog-package-00.txt outlines SIP events regards to call
dialogs. Does it make sense to include other call states such as:
HOLD - Call is being held
CONFERENCING - Call is being conferenced
CONFERENCED - Call is now conferenced
PARKED - Call has been parked.

Additionally would anyone know if any drafts cover non-call related phone
states such as Feature key requests, Do-No-Disturb, Off-hook etc? 

The reason I ask is that we have applications that wish to monitor end-point
state as well as call state.
Thanks in advance.



Fred O'Leary
MTS Sylantro Systems Corp.
(408)626-3040


From seancolson@yahoo.com  Fri Aug 16 18:10:03 2002
Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id SAA18661
	for ; Fri, 16 Aug 2002 18:10:02 -0400 (EDT)
Message-ID: <20020816221001.71618.qmail@web11603.mail.yahoo.com>
Received: from [131.107.3.83] by web11603.mail.yahoo.com via HTTP; Fri, 16 Aug 2002 15:10:01 PDT
Date: Fri, 16 Aug 2002 15:10:01 -0700 (PDT)
From: Sean Olson 
Subject: Re: [Simple] draft-ietf-sipping-dialog-package-00.txt
To: "Fred O'Leary" , simple@mailman.dynamicsoft.com
In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD01A7785C@mailserver.sylantro.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1613
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: 

It sounds like there are at least three types
of things you might be interested in:

1) The signaling state of SIP dialogs at an endpoint
   (the dialog package)

2) The signaling state of a conference composed of
these
   dialogs (the conference package)

3) The state of the media associated with a 
   particular session at a particular endpoint
   (also the conference package?)

The last thing is the least defined of the three.

You might also be interested in the draft on
markup (wrt feature keys):

http://search.ietf.org/internet-drafts/draft-rosenberg-sipping-markup-00.txt

Sean Olson
Microsoft


--- Fred O'Leary  wrote:
> Hi,
> draft-ietf-sipping-dialog-package-00.txt outlines
> SIP events regards to call
> dialogs. Does it make sense to include other call
> states such as:
> HOLD - Call is being held
> CONFERENCING - Call is being conferenced
> CONFERENCED - Call is now conferenced
> PARKED - Call has been parked.
> 
> Additionally would anyone know if any drafts cover
> non-call related phone
> states such as Feature key requests, Do-No-Disturb,
> Off-hook etc? 
> 
> The reason I ask is that we have applications that
> wish to monitor end-point
> state as well as call state.
> Thanks in advance.
> 
> 
> 
> Fred O'Leary
> MTS Sylantro Systems Corp.
> (408)626-3040
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

From JackLix@attbi.com  Thu Aug 15 19:25:28 2002
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15012
	for ; Thu, 15 Aug 2002 19:25:27 -0400 (EDT)
Received: from aslan ([12.224.107.17]) by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020815232527.MBOW1746.rwcrmhc51.attbi.com@aslan>;
          Thu, 15 Aug 2002 23:25:27 +0000
Reply-To: 
From: "Jack W. Lix" 
To: 
Cc: 
Date: Thu, 15 Aug 2002 16:27:59 -0700
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
In-Reply-To: 
Content-Length: 242
Subject: [Simple] RE: [Sip] draft-ietf-sip-message-06 NIT
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: 

Hi, 

Not sure if this belongs here or on sipping or simple list.  Please advise.

Section 3, 1st paragraph, 2nd sentence
IS: but if may be
SHOULD BE: but it may be

Cheers,

Jack

Jack W. Lix
WindRiver Systems, INC
Jack.Lix@windriver.com




From jdrosen@dynamicsoft.com  Tue Aug 20 14:10:33 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05992
	for ; Tue, 20 Aug 2002 14:10:33 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7KIAYYH006232;
	Tue, 20 Aug 2002 14:10:35 -0400 (EDT)
Message-ID: <3D628619.2090809@dynamicsoft.com>
Date: Tue, 20 Aug 2002 14:10:33 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: krisztian.kiss@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] 3GPP Presence requirements I-D: how the requirements
 are	 handled
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 4013
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: 

inline.

krisztian.kiss@nokia.com wrote:

>>>2. Partial publication/notification: during the SIMPLE 
>>
>>session it was
>>
>>>commented that CPIM and partial notification are conflicting
>>>requirements. This requirement is considered an important 
>>
>>feature for
>>
>>>wireless environment, however I am not sure how to resolve 
>>
>>the conflict
>>
>>>with CPIM. See also related mail in
>>>
>>
>>http://mailman.dynamicsoft.com/pipermail/simple/2002-July/001691.html
>>
>>It is not at all clear to me that this will actually save you 
>>anything. 
>>I suspect that SIGCOMP would, right now, give you much better overall 
>>bandwidth utilization than partial notifications. There is 
>>simply not a 
>>sufficient amount of data in the presence for a single user 
>>to warrant 
>>partial updates, IMHO.
> 
> 
> I try to make a simple example: let's assume that a JPEG picture is part
> of my presence information. I usually do not want to update the picture,
> however from time to time I want to change my picture in order to keep
> my watchers up-to-date.

Including the jpeg in the presence doc is a bad idea, for many reasons. 
You are much better off passing an http reference to it. If it changes, 
send a new reference.  IMPP went through a long debate about whether to 
include this kind of static contact information (vcard style things) and 
concluded not to even do it.

With a reference, it can be put into the sigcomp dictionary the first 
time, and each subsequent notification will use the value from the 
dictionary. Seems like the same performance as partial notifications.

> I guess pictures/logos/tones can be considered as soft state, if always
> one of them is associated with one profile in the phone. SIGCOMP only
> saves bandwidth in the air interface (in 3GPP environment), while with
> partial publication/notification we could also save bandwidth in the
> whole network.

Using a URI to reference it saves bandwidth in the whole network, and 
won't break interop with regular CPIM/PIDF compliant endpoints.



>>I asked this during the meeting, and I will ask again - why?
>>
>>The whole model of presence is that each PUA is independent. 
>>They don't 
>>need, and in fact, don't want, to know the details of the other PUA 
>>publishing for the presentity. Indeed, I can imagine cases 
>>where a PUA 
>>is authorized to publish for a presentity, but not authorized 
>>to see its 
>>presence! Consider the case of a web server that publishes 
>>information 
>>on the web page I am currently browsing; I might not want 
>>that site to 
>>know anything about me; but its OK for it to publish that I 
>>am currently 
>>browsing their site.
> 
> 
> Perhaps it is not clear for me what the PUBLISH draft says about this,
> but what happens if the same information (i.e. the same tuple) can be
> updated from multiple PUAs? (e.g. I am logged on to the same IM
> application from two devices)

I would argue that this is actually two contact addresses.


> It might be so that the PUAs should not care about each others
> publishing, so the compositor should be responsible to realize that the
> different publishers publish the same information and it should always
> notify the watchers about the latest published information.

Well, in the case above, the compositor would see publication of 
presence state for two separate IM applications. How it combines those 
is policy specific.


> It would be also useful for the PUA to know what happened with its
> publication. E.g. if it publishes status=closed, but the presence
> document says status=open for some reason.

Well, that it can obtain through presence itself.

-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


From griffj@gordano.com  Thu Aug 22 03:21:30 2002
Received: from pd.dev.ntmail.co.uk (id191.gordano.com [62.172.232.191])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12326
	for ; Thu, 22 Aug 2002 03:21:30 -0400 (EDT)
Received: from [127.0.0.1] by pd.dev.ntmail.co.uk (GMS 8.00.3068/SQ2499.01.1aec5043) with ESMTP id sufsaaaa for simple@mailman.dynamicsoft.com; Thu, 22 Aug 2002 08:16:50 +0100
Received: from [62.172.232.188] by pd.dev.ntmail.co.uk (GMS 8.00.3068/SQ2499.01.1aec5043) with ESMTP id rufsaaaa for simple@mailman.dynamicsoft.com; Thu, 22 Aug 2002 08:16:50 +0100
Date: Thu, 22 Aug 2002 08:16:50 +0100
From: "Griff James" 
To: 
Message-Id: <07165001500228@pd.gordano.com>
X-Mailer: Gordano Messaging Suite v8.00.3068
X-Sender: griffj-webmail@dev.ntmail.co.uk
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="==_07165003100229@pd.gordano.com==_"
X-AntiVirus: Checked for viruses by Gordano's AntiVirus Software
X-AntiSpam: Checked for UCE by Gordano's AntiSpam Software
Content-Length: 1358
Subject: [Simple] Basic authentication
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: 

This is a MIME-encapsulated message

--==_07165003100229@pd.gordano.com==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I am new to the mailing list, so please excuse me if I have missed=
 something obvious.

RFC3261 removed the use of basic authentication and only allows digest=
 authentication.

Many messaging systems such as the Gordano Messaging Server, Exchange etc=
 allow users to be authenticated via external databases e.g. NTSAM.
This means that a plain text password is not available to perform digest=
 authentication at the server side.

The SIP RFC does not seem provide a means of user authentication when the=
 plain text password is not available.

Is there another method which can be used for user level authentication=
 without breaking the standard ?


Griff




--==_07165003100229@pd.gordano.com==_
Content-Type: text/directory; charset="iso-8859-1"; profile="vcard"; name="Griff James.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="Griff James.vcf"

BEGIN:VCARD
VERSION:3.0
PRODID:-//Gordano//NONSGML GMS WebMail 8.00.3068//EN
FN:Griff James
N:;;;;
EMAIL;TYPE=3DINTERNET:griffj@gordano.com
TEL;TYPE=3DWORK,VOICE:01275 345100
TEL;TYPE=3DHOME,VOICE:01275 345100
END:VCARD


--==_07165003100229@pd.gordano.com==_--

From griffj@gordano.com  Wed Aug 21 10:51:10 2002
Received: from pd.dev.ntmail.co.uk (id191.gordano.com [62.172.232.191])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09474
	for ; Wed, 21 Aug 2002 10:51:09 -0400 (EDT)
Received: from [127.0.0.1] by pd.dev.ntmail.co.uk (GMS 8.00.3068/SQ2499.01.1aec5043) with ESMTP id cpfsaaaa for simple@mailman.dynamicsoft.com; Wed, 21 Aug 2002 15:46:35 +0100
Received: from [62.172.232.188] by pd.dev.ntmail.co.uk (GMS 8.00.3068/SQ2499.01.1aec5043) with ESMTP id bpfsaaaa for simple@mailman.dynamicsoft.com; Wed, 21 Aug 2002 15:46:35 +0100
Date: Wed, 21 Aug 2002 15:46:35 +0100
From: "Griff James" 
To: 
Message-Id: <14463526500190@pd.gordano.com>
X-Mailer: Gordano Messaging Suite v8.00.3068
X-Sender: griffj-webmail@dev.ntmail.co.uk
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="==_14463528100191@pd.gordano.com==_"
X-AntiVirus: Checked for viruses by Gordano's AntiVirus Software
X-AntiSpam: Checked for UCE by Gordano's AntiSpam Software
Content-Length: 1286
Subject: [Simple] RFC3261 Basic Authentication
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: 

This is a MIME-encapsulated message

--==_14463528100191@pd.gordano.com==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I am new to the mailing list, so please excuse me if I have missed=
 something obvious.

RFC3261 has made changes to remove basic authentication.

Perhaps it should not allow basic authentication for non-TLS connections.

Many messaging systems such as the Gordano Messaging Server, Exchange etc=
 allow users to be authenticated via external databases e.g. NTSAM.
This means that a plain text password is not available to perform digest=
 authentication at the server side.

Performing user level authentication would not be possible where a plain=
 text password is not available.

Griff




--==_14463528100191@pd.gordano.com==_
Content-Type: text/directory; charset="iso-8859-1"; profile="vcard"; name="Griff James.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="Griff James.vcf"

BEGIN:VCARD
VERSION:3.0
PRODID:-//Gordano//NONSGML GMS WebMail 8.00.3068//EN
FN:Griff James
N:;;;;
EMAIL;TYPE=3DINTERNET:griffj@gordano.com
TEL;TYPE=3DWORK,VOICE:01275 345100
TEL;TYPE=3DHOME,VOICE:01275 345100
END:VCARD


--==_14463528100191@pd.gordano.com==_--

From Markus.Isomaki@nokia.com  Fri Aug 23 07:53:46 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16993
	for ; Fri, 23 Aug 2002 07:53:45 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7NC63f29098
	for ; Fri, 23 Aug 2002 15:06:03 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 23 Aug 2002 14:53:43 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 23 Aug 2002 14:53:42 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 23 Aug 2002 14:53:42 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] 3GPP Presence requirements I-D: how the requirements are	 handled
Date: Fri, 23 Aug 2002 14:53:42 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] 3GPP Presence requirements I-D: how the requirements are	 handled
Thread-Index: AcJIdWOdOKYA1jEHRZe6g1lADuMZPQCI0J2Q
To: , 
Cc: 
X-OriginalArrivalTime: 23 Aug 2002 11:53:42.0709 (UTC) FILETIME=[BA60D650:01C24A9B]
Content-Length: 5676
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id HAA16993
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: 

Hi,

Some further thoughts about partial publication and notification:

Is there a good enough security solution for using content indirection and HTTP for the purpose described below? I think doing it inter-domain will be difficult in the general case. Also, partial notifications with SIP would be easier in an environment where charging of "signaling" is somehow special.

I understand that this stuff will not be interesting or needed for the whole SIMPLE deployment base (due to complexity reasons), and that interoperability is of extreme importance. But if 3GPP specifically wants this feature, can THEY do it if it meets the following requirements:
- Everyone must also support normal operation (i.e. no partial updates)
- Capability for partial updates is always negotiated when setting up the dialog, and if the other end does not have it, normal operation is assumed.

I guess this could work by defining and registering a new content-type in addition to PIDF, which has the partial update capability. Support for this could be negotiated with Accept: header.

I don't see any harm in this. Any objections? Of course the best way would be to have SIMPLE WG do it completely.

Markus 

Jonathan Rosenberg wrote:
> 
> inline.
> 
> krisztian.kiss@nokia.com wrote:
> 
> >>>2. Partial publication/notification: during the SIMPLE 
> >>
> >>session it was
> >>
> >>>commented that CPIM and partial notification are conflicting
> >>>requirements. This requirement is considered an important 
> >>
> >>feature for
> >>
> >>>wireless environment, however I am not sure how to resolve 
> >>
> >>the conflict
> >>
> >>>with CPIM. See also related mail in
> >>>
> >>
> >>http://mailman.dynamicsoft.com/pipermail/simple/2002-July/00
> 1691.html
> >>
> >>It is not at all clear to me that this will actually save you 
> >>anything. 
> >>I suspect that SIGCOMP would, right now, give you much 
> better overall 
> >>bandwidth utilization than partial notifications. There is 
> >>simply not a 
> >>sufficient amount of data in the presence for a single user 
> >>to warrant 
> >>partial updates, IMHO.
> > 
> > 
> > I try to make a simple example: let's assume that a JPEG 
> picture is part
> > of my presence information. I usually do not want to update 
> the picture,
> > however from time to time I want to change my picture in 
> order to keep
> > my watchers up-to-date.
> 
> Including the jpeg in the presence doc is a bad idea, for 
> many reasons. 
> You are much better off passing an http reference to it. If 
> it changes, 
> send a new reference.  IMPP went through a long debate about 
> whether to 
> include this kind of static contact information (vcard style 
> things) and 
> concluded not to even do it.
> 
> With a reference, it can be put into the sigcomp dictionary the first 
> time, and each subsequent notification will use the value from the 
> dictionary. Seems like the same performance as partial notifications.
> 
> > I guess pictures/logos/tones can be considered as soft 
> state, if always
> > one of them is associated with one profile in the phone. 
> SIGCOMP only
> > saves bandwidth in the air interface (in 3GPP environment), 
> while with
> > partial publication/notification we could also save bandwidth in the
> > whole network.
> 
> Using a URI to reference it saves bandwidth in the whole network, and 
> won't break interop with regular CPIM/PIDF compliant endpoints.
> 
> 
> 
> >>I asked this during the meeting, and I will ask again - why?
> >>
> >>The whole model of presence is that each PUA is independent. 
> >>They don't 
> >>need, and in fact, don't want, to know the details of the other PUA 
> >>publishing for the presentity. Indeed, I can imagine cases 
> >>where a PUA 
> >>is authorized to publish for a presentity, but not authorized 
> >>to see its 
> >>presence! Consider the case of a web server that publishes 
> >>information 
> >>on the web page I am currently browsing; I might not want 
> >>that site to 
> >>know anything about me; but its OK for it to publish that I 
> >>am currently 
> >>browsing their site.
> > 
> > 
> > Perhaps it is not clear for me what the PUBLISH draft says 
> about this,
> > but what happens if the same information (i.e. the same 
> tuple) can be
> > updated from multiple PUAs? (e.g. I am logged on to the same IM
> > application from two devices)
> 
> I would argue that this is actually two contact addresses.
> 
> 
> > It might be so that the PUAs should not care about each others
> > publishing, so the compositor should be responsible to 
> realize that the
> > different publishers publish the same information and it 
> should always
> > notify the watchers about the latest published information.
> 
> Well, in the case above, the compositor would see publication of 
> presence state for two separate IM applications. How it 
> combines those 
> is policy specific.
> 
> 
> > It would be also useful for the PUA to know what happened with its
> > publication. E.g. if it publishes status=closed, but the presence
> > document says status=open for some reason.
> 
> Well, that it can obtain through presence itself.
> 
> -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 rainer.janssen@de.ibm.com  Sun Aug 25 19:12:11 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26816
	for ; Sun, 25 Aug 2002 19:12:10 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g7PNC9A9021914
	for ; Mon, 26 Aug 2002 01:12:09 +0200
Received: from d12ml013.de.ibm.com (d12ml013_cs0 [9.165.223.39])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7PNC7lG105082
	for ; Mon, 26 Aug 2002 01:12:09 +0200
From: "Rainer R Janssen" 
To: "simple" 
Message-ID: 
Date: Mon, 26 Aug 2002 01:12:06 +0200
X-MIMETrack: Serialize by Router on D12ML013/12/M/IBM(Release 5.0.9a |January 7, 2002) at
 26/08/2002 01:12:08
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 101
Subject: [Simple] Rainer R Janssen/Germany/IBM is out of the office.
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: 

I will be out of the office starting August 23, 2002 and will not return
until September 9, 2002.




From dean.willis@softarmor.com  Mon Aug 26 13:49:13 2002
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 NAA01843
	for ; Mon, 26 Aug 2002 13:49:11 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g7QHnF328358;
	Mon, 26 Aug 2002 12:49:17 -0500
From: "Dean Willis" 
To: "'Griff James'" , 
Subject: RE: [Simple] RFC3261 Basic Authentication
Date: Mon, 26 Aug 2002 12:48:48 -0500
Message-ID: <004101c24d28$d6e22290$a6036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-reply-to: <14463526500190@pd.gordano.com>
Content-Length: 2458
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: 

That's right. Plain text passwords being transmitted around the net are
generally dangerous and scary things and should be approached with
extreme caution. Actually, many people feel that plain text passwords
are inherently dangerous, even if never accessed outside of a given
system. This has led to the development of one-way hash function
passwords such as used in most UNIX systems. Someone once said that "the
insecurity of a password decreases with the exponent of the number of
places it is stored", which is probably a variation on "a secret is
something known to only one person". Though questionably provable, these
expressions convey the sentiment nicely.

The same basic issue occurred in the dial-up Internet world when
Challenge-Handshake Authentication Protocol (CHAP) replaced Password
Authentication Protocol (PAP) in common use. Since the client wasn't
sending the plaintext password anymore, either the back-end server had
to cough up the password OR implement the same handshake calculation
algorithm and execute it on behalf of the terminal server.

We should be able to learn something from all the RADIUS and DIAMETER
work done to support this model.

What appears to be needed here is for the back-end-database to be able
to perform the digest authentication step on behalf of the server. The
call becomes something like "Here, please digest this message as griffj
would digest it and get back to me" or "Here, please check this message
that griffj claims to have digested and tell me if it's from him".

--
Dean


> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com 
> [mailto:simple-admin@mailman.dynamicsoft.com] On Behalf Of Griff James
> Sent: Wednesday, August 21, 2002 9:47 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] RFC3261 Basic Authentication
> 
> 
> I am new to the mailing list, so please excuse me if I have 
> missed something obvious.
> 
> RFC3261 has made changes to remove basic authentication.
> 
> Perhaps it should not allow basic authentication for non-TLS 
> connections.
> 
> Many messaging systems such as the Gordano Messaging Server, 
> Exchange etc allow users to be authenticated via external 
> databases e.g. NTSAM. This means that a plain text password 
> is not available to perform digest authentication at the server side.
> 
> Performing user level authentication would not be possible 
> where a plain text password is not available.
> 
> Griff
> 
> 
> 
> 


From jdrosen@dynamicsoft.com  Wed Aug 28 01:41:37 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08001
	for ; Wed, 28 Aug 2002 01:41:37 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g7S5fdYH011341;
	Wed, 28 Aug 2002 01:41:39 -0400 (EDT)
Message-ID: <3D6C3515.4010507@dynamicsoft.com>
Date: Tue, 27 Aug 2002 22:27:33 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
CC: krisztian.kiss@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] 3GPP Presence requirements I-D: how the requirements
 are	 handled
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2903
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: 


Markus.Isomaki@nokia.com wrote:
 > Hi,
 >
 > Some further thoughts about partial publication and notification:
 >
 > Is there a good enough security solution for using content
 > indirection and HTTP for the purpose described below? I think doing
 > it inter-domain will be difficult in the general case.

I think security can be exactly the same.

If you assume that there is no S/MIME, including the content inline is 
only "secure" in the sense that the only way someone else can see the 
content is eavesdropping/interception/MITM. If you can eavesdrop, you 
have the content. The content can also be "leaked" if the recipient 
sends it to someone else; there is no protection against that. For 
content indirection, the URI in the indirection needs to be sufficiently 
randomized, so that is unguessable. In that case, the only way to obtain 
the content is to know the URI. The only way to know the URI is to 
eavesdrop/intercept/MITM. If can also be leaked in the same way, if the 
URI is emailed.

Of course, within the same domain, security is a bit better. The content 
indirection server can authenticate the recipient with digest, so even 
if a user eavesdrop the URI they can't get the content.

If you assume S/MIME, well, then you S/MIME the content before uploading 
it to the indirection server, and security is just as good as including 
it as an attachment.



 > Also, partial
 > notifications with SIP would be easier in an environment where
 > charging of "signaling" is somehow special.

Well, the perils of that are obvious. Anyway I don't see how compression 
would still achieve the same (if not better) impact for clients.

 >
 > I understand that this stuff will not be interesting or needed for
 > the whole SIMPLE deployment base (due to complexity reasons), and
 > that interoperability is of extreme importance. But if 3GPP
 > specifically wants this feature, can THEY do it if it meets the
 > following requirements: - Everyone must also support normal operation
 > (i.e. no partial updates) - Capability for partial updates is always
 > negotiated when setting up the dialog, and if the other end does not
 > have it, normal operation is assumed.

I would rather protocol work be done in IETF.

I have no problem doing partial notification if the case can be made 
that it really is needed. However, it is my sense that this is one of 
these things that appears essential at first glance, but when you 
examine it, becomes less clear that it buys you all that much, and it 
comes with many headaches.


-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



From jose@tct.hut.fi  Wed Aug 28 07:19:39 2002
Received: from keskus.tct.hut.fi (keskus.tct.hut.fi [130.233.154.176])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08927
	for ; Wed, 28 Aug 2002 07:19:38 -0400 (EDT)
Received: (from www@localhost)
	by keskus.tct.hut.fi (8.10.0/8.10.0) id g7SBKDT26369;
	Wed, 28 Aug 2002 14:20:13 +0300 (EET DST)
From: Costa Requena 
X-Authentication-Warning: keskus.tct.hut.fi: www set sender to jose@tct.hut.fi using -f
To: simple@mailman.dynamicsoft.com
Subject: [Simple] addressing scheme in Request-URI
Message-ID: <1030533613.3d6cb1ed50276@keskus.tct.hut.fi>
Date: Wed, 28 Aug 2002 14:20:13 +0300 (EET DST)
Cc: jose 
References: <200206261920.PAA23241@dynasty.cs.columbia.edu>
In-Reply-To: <200206261920.PAA23241@dynasty.cs.columbia.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.8
X-Originating-IP: 192.100.124.220
Content-Length: 387
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: 

Hi,


Just quick question!
I read in previous specs that SIP Request-URI SHOULD have sip: as address 
scheme while To: header MAY have others than sip: schemes.In recent specs 
it says that the content of To: header is copied in Request-URI.
Could someone ensure that the Request-URI MAY have other schemes than sip: or 
sips: let's say im: pres: http:, etc.

Thanks in advance!
BR
Jose

From scoya@cnri.reston.va.us  Tue Aug 27 14:58:13 2002
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 OAA06179
	for ; Tue, 27 Aug 2002 14:58:13 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06546
	for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT)
Message-Id: <200208271844.OAA06546@ietf.org>
From: Phil Roberts 
To: IETF WG Participants: ;
Date: Tue, 27 Aug 2002 14:44:44 -0400
Content-Length: 396
Subject: [Simple] Nomcom call for volunteers
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: 

The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering 
to be on the nominations committee.

From aki.niemi@nokia.com  Fri Aug 30 04:37:38 2002
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 EAA16555
	for ; Fri, 30 Aug 2002 04:37:36 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7U8ZfA28411
	for ; Fri, 30 Aug 2002 11:35:42 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Fri, 30 Aug 2002 11:37:35 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 30 Aug 2002 11:37:35 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 30 Aug 2002 11:37:35 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE3F7@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PUBLISH and expires
Thread-Index: AcJQAHzXqaldqT4CQa6TSG/KpPYu8A==
To: 
X-OriginalArrivalTime: 30 Aug 2002 08:37:35.0433 (UTC) FILETIME=[7D6D4390:01C25000]
Content-Length: 344
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA16555
Subject: [Simple] PUBLISH and expires
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: 

Hi,

Reading draft-olson-simple-publish-00.txt, it says that a PUBLISH may have an expiration for the event state data. What is the behavior of the composer once this expiration is met?

More specifically, in a stream of publications each arriving before the last one has expired, what will be the fallback state for the composer?

Cheers,
Aki

From kawasaki.ayako@lab.ntt.co.jp  Mon Sep  2 04:17:40 2002
Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00242
	for ; Mon, 2 Sep 2002 04:17:39 -0400 (EDT)
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/07/30/02) with ESMTP id RAA08542
	for ; Mon, 2 Sep 2002 17:17:37 +0900 (JST)
	(envelope-from kawasaki.ayako@lab.ntt.co.jp)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g828HbRp015483
	for ; Mon, 2 Sep 2002 17:17:37 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g828HaxH014414
	for ; Mon, 2 Sep 2002 17:17:36 +0900 (JST)
Received: from imh.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA26685
	for ; Mon, 2 Sep 2002 17:17:36 +0900 (JST)
Received: from kawasaki
	by imh.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA13774
	for ; Mon, 2 Sep 2002 17:17:35 +0900 (JST)
Date: Mon, 02 Sep 2002 17:17:34 +0900
From: Ayako Kawasaki 
To: simple@mailman.dynamicsoft.com
Reply-To: kawasaki.ayako@lab.ntt.co.jp
Message-Id: <20020902171020.6C2C.KAWASAKI.AYAKO@lab.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.11
Content-Length: 423
Subject: [Simple] question on winfo-package draft
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: 

Hi,

I am now reading simple-winfo-package-02.txt draft.

I have one very little question.
On section 4.7, there is an abbreviation word "FSM".
I couldn't figure out what this "FSM" stands for.

Would anyone give me some comments on this?


Thanks in advance.
Ayako

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ayako Kawasaki
NTT Network Service Systems Laboratories
e-mail: kawasaki.ayako@lab.ntt.co.jp
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


From hisham.khartabil@nokia.com  Mon Sep  2 04:31:14 2002
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 EAA00308
	for ; Mon, 2 Sep 2002 04:31:13 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g828THA23151
	for ; Mon, 2 Sep 2002 11:29:17 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 2 Sep 2002 11:30:02 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 2 Sep 2002 11:30:01 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] question on winfo-package draft
Date: Mon, 2 Sep 2002 11:29:57 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2056F@esebe019.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] question on winfo-package draft
Thread-Index: AcJSWblZgKUXZkKLR0GEFjx01ElSXQAAScuQ
To: , 
X-OriginalArrivalTime: 02 Sep 2002 08:30:01.0374 (UTC) FILETIME=[EE069BE0:01C2525A]
Content-Length: 883
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id EAA00308
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: 

Finite State Machine

> -----Original Message-----
> From: ext Ayako Kawasaki [mailto:kawasaki.ayako@lab.ntt.co.jp]
> Sent: Monday, September 02, 2002 11:18 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] question on winfo-package draft
> 
> 
> Hi,
> 
> I am now reading simple-winfo-package-02.txt draft.
> 
> I have one very little question.
> On section 4.7, there is an abbreviation word "FSM".
> I couldn't figure out what this "FSM" stands for.
> 
> Would anyone give me some comments on this?
> 
> 
> Thanks in advance.
> Ayako
> 
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Ayako Kawasaki
> NTT Network Service Systems Laboratories
> e-mail: kawasaki.ayako@lab.ntt.co.jp
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From kawasaki.ayako@lab.ntt.co.jp  Mon Sep  2 04:53:08 2002
Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00402
	for ; Mon, 2 Sep 2002 04:53:07 -0400 (EDT)
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/07/30/02) with ESMTP id RAA15064
	for ; Mon, 2 Sep 2002 17:53:06 +0900 (JST)
	(envelope-from kawasaki.ayako@lab.ntt.co.jp)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g828r5Rp017970
	for ; Mon, 2 Sep 2002 17:53:05 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g828r5xH020312
	for ; Mon, 2 Sep 2002 17:53:05 +0900 (JST)
Received: from imh.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA29400
	for ; Mon, 2 Sep 2002 17:53:04 +0900 (JST)
Received: from kawasaki
	by imh.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id RAA17040
	for ; Mon, 2 Sep 2002 17:53:04 +0900 (JST)
Date: Mon, 02 Sep 2002 17:53:02 +0900
From: Ayako Kawasaki 
To: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] question on winfo-package draft
Reply-To: kawasaki.ayako@lab.ntt.co.jp
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7C2056F@esebe019.ntc.nokia.com>
References: <2038BCC78B1AD641891A0D1AE133DBB7C2056F@esebe019.ntc.nokia.com>
Message-Id: <20020902175231.6C32.KAWASAKI.AYAKO@lab.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.11
Content-Length: 834
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: 

Thanks :-)

On Mon, 2 Sep 2002 11:29:57 +0300
hisham.khartabil@nokia.com wrote:

> Finite State Machine
> 
> > -----Original Message-----
> > From: ext Ayako Kawasaki [mailto:kawasaki.ayako@lab.ntt.co.jp]
> > Sent: Monday, September 02, 2002 11:18 AM
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] question on winfo-package draft
> > 
> > 
> > Hi,
> > 
> > I am now reading simple-winfo-package-02.txt draft.
> > 
> > I have one very little question.
> > On section 4.7, there is an abbreviation word "FSM".
> > I couldn't figure out what this "FSM" stands for.
> > 
> > Would anyone give me some comments on this?
> > 
> > 
> > Thanks in advance.
> > Ayako
> > 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ayako Kawasaki
NTT Network Service Systems Laboratories
e-mail: kawasaki.ayako@lab.ntt.co.jp
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


From kokjeng.loh@siemens.com  Thu Sep  5 08:48:23 2002
Received: from david.sae.siemens.com.sg (david.sae.siemens.com.sg [194.138.243.252])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13351
	for ; Thu, 5 Sep 2002 08:48:21 -0400 (EDT)
X-Envelope-Sender-Is: kokjeng.loh@siemens.com (at relayer david.sae.siemens.com.sg)
Received: from mail.sae.siemens.com.sg (mail.sae.siemens.com.sg [194.138.237.14])
	by david.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g85Cjvl07340
	for ; Thu, 5 Sep 2002 20:45:57 +0800 (SGT)
Received: from sgpk001a.sae.siemens.com.sg (sgpk001a.sae.siemens.com.sg [140.231.107.1])
	by mail.sae.siemens.com.sg (8.11.6/8.11.6) with ESMTP id g85ClAX01696
	for ; Thu, 5 Sep 2002 20:47:10 +0800 (SGT)
Received: by sgpk001a.sae.siemens.com.sg with Internet Mail Service (5.5.2655.55)
	id ; Thu, 5 Sep 2002 20:43:59 +0800
Message-ID: <7319EDDDE0CD7C458023FF64886CB17701DEFD82@sgpk001a.sae.siemens.com.sg>
From: Loh Kok Jeng 
To: simple@mailman.dynamicsoft.com
Date: Thu, 5 Sep 2002 20:43:58 +0800 
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Length: 1814
Subject: [Simple] Overlapped MESSAGE transactions in chatting
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: 

Dear all,

In a chatting scenario where the UA sends MESSAGEs with the same Call-ID but
with increasing CSeq in quick succession, how should a stateful proxy handle
these MESSAGEs?  

The diagram below is an illustration of the scenario mentioned above: 

  +----+            +-------+
  | UA |            | Proxy |
  +----+            +-------+
    |                   |
    |  MESSAGE 1        |
    |------------------>|
    |  MESSAGE 2        |
    |------------------>|
    |  MESSAGE 3        |
    |------------------>|
    |                   |

In draft-ietf-sip-message-06.txt, Section 9., it is stated that:

   A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a
   given URI if there is a previous out-of-dialog transaction pending
   for the same URI.  Similarly, A UAC SHOULD NOT initiate overlapping
   MESSAGE transactions inside a dialog, and MUST NOT do so unless the
   route set for that dialog uses a congestion-controlled transport at
   every hop.  UACs SHOULD NOT set the T1 timer value to less than 500
   ms for MESSAGE transactions.  UACs may use smaller T1 values if they
   know that that the next hop latency warrants it.

      The prohibition againt overlapping MESSAGE request provides some
      degree of congestion-safe behavior.  A request and its associated
      response must each cross the full path between the UAC and the
      UAS.  The time required for this will increase as networks become
      congested.  This provides an adaptive mechanism to slow the
      introduction of new MESSAGE requests to the same destination.

Does it mean that the UA must wait for a final response before sending the
next MESSAGE?  If so, should a stateful proxy drop the subsequent MESSAGEs
before it receives a final response for the first MESSAGE?


regards,
KJ

From jdrosen@dynamicsoft.com  Thu Sep  5 10:43:43 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13726
	for ; Thu, 5 Sep 2002 10:43:43 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.52])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g85EhcYH016703;
	Thu, 5 Sep 2002 10:43:38 -0400 (EDT)
Message-ID: <3D776D99.9060709@dynamicsoft.com>
Date: Thu, 05 Sep 2002 10:43:37 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Loh Kok Jeng 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Overlapped MESSAGE transactions in chatting
References: <7319EDDDE0CD7C458023FF64886CB17701DEFD82@sgpk001a.sae.siemens.com.sg>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 888
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: 

inline.

Loh Kok Jeng wrote:
> Dear all,
> 
> In a chatting scenario where the UA sends MESSAGEs with the same Call-ID but
> with increasing CSeq in quick succession, how should a stateful proxy handle
> these MESSAGEs?  

The proxy shouldn't provide any special handling. It should properly 
proxy all messages. This is the case for stateless and stateful proxies 
alike. It is not the role of the proxy to police the client to ensure 
they are consistent with the congestion control requirements in the 
specification.

-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


From pkyzivat@cisco.com  Thu Sep  5 10:56:53 2002
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 KAA13790
	for ; Thu, 5 Sep 2002 10:56:52 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g85EulS5024031;
	Thu, 5 Sep 2002 10:56:47 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAQ29531;
	Thu, 5 Sep 2002 11:01:21 -0400 (EDT)
Message-ID: <3D7770A3.73F04FEB@cisco.com>
Date: Thu, 05 Sep 2002 10:56:35 -0400
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: "Peterson, Jon" ,
        "'hisham.khartabil@nokia.com'" ,
        bateman@acm.org, simple@mailman.dynamicsoft.com
References: <15A2739B7DAA624D8091C65981D7DA815EB151@stntexch2.va.neustar.com> <3D771E79.4010809@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1360
Subject: [Simple] Re: Communication means in draft-ietf-impp-cpim-pidf-05
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: 

Moving discussion to the simple list...

Jonathan Rosenberg wrote:
> 
> I agree that, in the case of
> SIP (although it really is more general), having extension attributes
> that convey the information gleaned from things like caller preferences
> (media types supported, for example) is a worthwhile goal. Indeed, such
> an item is ALREADY on the charter of SIMPLE, and appears to be due this
> month....

Hmm - is it:

  Goals and Milestones:
  ...
  SEP 02  Submission of SIMPLE PIDF profile to IESG for 
          publication as Proposed Standard 

that you are referring to? Its good if the SIMPLE charter already covers this work. But as far as I know there hasn't yet been any work on this has there?

Considering the amount of heat this subject has generated on the impp list, do we need to first develop a set of requirements for PIDF extensions in SIMPLE?

My feeling is that a good start (and maybe finish) would be to reflect the callee capabilities, as defined in callerprefs, in PIDF. It has been discussed ad nauseum on impp why at least media capabilities are important. I don't know if we need to repeat that discussion here, or if we need to do it for each pref type in callerprefs. One advantage to agreeing on callerprefs is that maybe we can make a decision on the whole thing rather than considering each piece separately.

	Paul

	Paul

From bateman@acm.org  Thu Sep  5 11:42:47 2002
Received: from cmailm3.svr.pol.co.uk (cmailm3.svr.pol.co.uk [195.92.193.19])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13942
	for ; Thu, 5 Sep 2002 11:42:46 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by cmailm3.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17mym5-0006P3-00; Thu, 05 Sep 2002 16:42:29 +0100
Received: from modem-2314.wolf.dialup.pol.co.uk ([81.76.137.10] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17mylz-0001Ke-00; Thu, 05 Sep 2002 16:42:24 +0100
Reply-To: 
From: "Adrian Bateman" 
To: "'Paul Kyzivat'" ,
        "'Jonathan Rosenberg'" 
Cc: "'Peterson, Jon'" , ,
        
Date: Thu, 5 Sep 2002 16:42:03 +0100
Organization: VisionTech Limited
MIME-Version: 1.0
Message-ID: <003d01c254f2$cbbee7a0$6405010a@ADRIANXP>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0038_01C254FB.29943B20"
Importance: Normal
In-Reply-To: <3D7770A3.73F04FEB@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 8606
Subject: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0038_01C254FB.29943B20
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

On 05 September 2002 15:56, Paul Kyzivat wrote:
> Moving discussion to the simple list...
> 
> Jonathan Rosenberg wrote:
> > 
> > I agree that, in the case of
> > SIP (although it really is more general), having extension 
> > attributes
> > that convey the information gleaned from things like caller 
> > preferences (media types supported, for example) is a worthwhile
goal. 
> > Indeed, such an item is ALREADY on the charter of SIMPLE, and
appears 
> > to be due this month....
> 
> Hmm - is it:
> 
>   Goals and Milestones:
>   ...
>   SEP 02  Submission of SIMPLE PIDF profile to IESG for 
>           publication as Proposed Standard
> 
> that you are referring to? Its good if the SIMPLE charter already 
> covers this work. But as far as I know there hasn't yet been any work 
> on this has there?
> 
> Considering the amount of heat this subject has generated on the impp 
> list, do we need to first develop a set of requirements for PIDF 
> extensions in SIMPLE?

I seem to remember it having been discussed at length without conclusion
here too, but for different reasons. In the past (and as result of
passing on it for now in IMPP), there has been a desire to have a set of
'IM' status values beyond OPEN and CLOSED for things that people have
been used to such as away, busy, etc.

To my mind, the debate in the past always degenerated into a general
discussion where people either tried to argue about the openness or
closedness of particular states or they expanded the scope to start
talking about SIP media types too. 'Degenerated' may be a bit harsh
since some of those arguments are valid but didn't, I think, contribute
to the particular discussion at hand: IM status values. I've tried to
move that discussion along in the past by trying to talk about why IM
status values are important and what purpose they will serve so now
might be a good time to try to raise that again.

For interop, PIDF says that for status value ranges that extend 
(i.e. they imply some OPEN or CLOSED value), the  value must also
be present. My suggestion for IM status values is to have a dictionary
of values without necessitating an inherent OPEN/CLOSED property to
avoid endless debate. As far as possible, values with the same semantics
should be reduced to one word (e.g. if there is a consensus that 'away'
and 'idle' are the same, then we only need one). But if there are
objections, I see no major disadvantage with having a larger dictionary
within reason (e.g. if there is no consensus that 'dnd' and 'busy' are
the same, say, then they could both be included and some people will
interpret them as the same and others as different).

My reasoning for this is as follows. I believe that:
* People will largely use the values for presentational purposes. 
* It is unlikely that there will be consensus about precise semantics
for certain values and so people building automata to interpret the
values will have to use some local policy logic anyway.
* The ultimate fallback is the OPEN/CLOSED  value that MUST be
present.

> My feeling is that a good start (and maybe finish) would be to reflect

> the callee capabilities, as defined in callerprefs, in PIDF. It has 
> been discussed ad nauseum on impp why at least media capabilities are 
> important. I don't know if we need to repeat that discussion here, or 
> if we need to do it for each pref type in callerprefs. One advantage 
> to agreeing on callerprefs is that maybe we can make a decision on the

> whole thing rather than considering each piece separately.

I'm afraid I don't know enough to contribute meaningfully to the
discussion regarding capabilities. However, I think these two cases can
be done in parallel, and I hope that part of this work may help towards
the documentation we'd like in IMPP for defining an extension to PIDF.

Adrian.

------=_NextPart_000_0038_01C254FB.29943B20
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAngw
ggHhoAMCAQICAwfOcTANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAyMDcwMTIwMTI0M1oXDTAzMDcwMTIwMTI0M1owQTEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEeMBwGCSqGSIb3DQEJARYPYmF0ZW1hbkBhY20ub3JnMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDCBKe8lwUCrhtKabcZh1lrG7ZSeNf3JXcVr6kLZtkNmYUfLouB
/sz5RaLkoiLaKXGMj0bXaPDo5XKJG+RydduRwvMvDl9CeU8IRRfCM68ECOTcFMQdf3JMxXtujXf9
Pkq5otwVpjIePufMkNqvT257Z+w2S9WisYxIkwXteyc4dwIDAQABoywwKjAaBgNVHREEEzARgQ9i
YXRlbWFuQGFjbS5vcmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCw9gtsDshcl4Hb
vu5P7VhTSsLpofXY3oyyDKYMynjM9RMWr250Cz3X38Y+5e3idgNvvfaQgvVEotdM5WCX9DqXO7VF
TQHFXlDE1K0ZNtpTw954jWYOYX3WLkJjg/SNCO0WBdZYu4hSsMsgQwj7atYWmdjGILk4iJ7M3Hds
8M0tjDCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV
BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt
ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY
BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz
IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG
9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj
3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11uenwMpUtVfwYZKX+emibV
ars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcN
AQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umSc
F6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLm
nC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM4MIICoaADAgECAhBmRXK3zHT1z2N2RYTQLpEBMA0G
CSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD
VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0
aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN
MDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKX
DuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu
2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04w
TDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgw
BgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAMbFLR135AXHl9VNsXXnWPZjA
JhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQVahs9w2tTBu8A/S166JHn2yiDFiNMUIJ
EWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggNp
MIIDZQIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE
BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHznEwCQYFKw4D
AhoFAKCCAiQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwOTA1
MTU0MjAzWjAjBgkqhkiG9w0BCQQxFgQURWNMg4k2tTHXNicIegG3rDUgaicwZwYJKoZIhvcNAQkP
MVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwgasGCSsGAQQBgjcQBDGBnTCBmjCB
kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD
Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHznEwga0GCyqGSIb3DQEJEAILMYGd
oIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl
IFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAm
BgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwfOcTANBgkqhkiG9w0BAQEF
AASBgEOA8Yq6zBGKRR610Kev7Z1oRXHu4sFZYxNXYQFJonk29+GVQwDBKV/e0eKpkblV4dW8jHnT
biy6tOr93MMfz6nbdEJ2xc6tEOTqlloplvBSrIpvqOFxb6M6qJ8CvRg9i14ZJQ2/jd7xQYWEJ7fg
DTMzB1NvhT5V9g4iXUjkTq5uAAAAAAAA

------=_NextPart_000_0038_01C254FB.29943B20--



From krisztian.kiss@nokia.com  Thu Sep  5 12:32:56 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14162
	for ; Thu, 5 Sep 2002 12:32:55 -0400 (EDT)
From: krisztian.kiss@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g85GWu702207
	for ; Thu, 5 Sep 2002 19:32:56 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 5 Sep 2002 19:31:12 +0300
Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 5 Sep 2002 19:31:12 +0300
Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 5 Sep 2002 19:31:12 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05
Date: Thu, 5 Sep 2002 19:31:11 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05
Thread-Index: AcJU9DP3Aff9iBBKT/+4C5kZxh52PAAAM1Xg
To: , , 
Cc: , ,
        
X-OriginalArrivalTime: 05 Sep 2002 16:31:12.0122 (UTC) FILETIME=[A59265A0:01C254F9]
Content-Length: 2719
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA14162
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: 

Hi,

> For interop, PIDF says that for status value ranges that 
> extend 
> (i.e. they imply some OPEN or CLOSED value), the  
> value must also
> be present. My suggestion for IM status values is to have a dictionary
> of values without necessitating an inherent OPEN/CLOSED property to
> avoid endless debate. As far as possible, values with the 
> same semantics
> should be reduced to one word (e.g. if there is a consensus 
> that 'away'
> and 'idle' are the same, then we only need one). But if there are
> objections, I see no major disadvantage with having a larger 
> dictionary
> within reason (e.g. if there is no consensus that 'dnd' and 'busy' are
> the same, say, then they could both be included and some people will
> interpret them as the same and others as different).

The reason why I initiated this thread on IMPP list was not to define
'away', 'idle', 'busy', etc. It was rather adding exact communication
means to tuples (like 'voice', 'video', 'game', etc.), which goes beyond
the contact's URI scheme. Currently if a tuple contains a contact, like:
sip:someone@example.com
its communication mean is 'sip:' which does not tell too much about the
presentity's capabilities & willingness whether he/she wants to use this
sip: contact for voice, video or chat. This might be a specific issue of
SIP URIs, therefore it was proposed to move the discussion to this list.

Paul also wrote a good summary about the issue on IMPP:

> The sip uri explicitly does not say anything about the media 
> it supports. That is negotiated via the exchange of SDP.
> 
> There is an ability when registering a contact address with a 
> sip registrar to specify capabilities of the addressed 
> endpoint, including the types of media it supports. But this 
> is represented as header parameters on the contact header 
> rather than as parameters of the sip url itself.
> 
> In pidf, the equivalent functionality could be achieved by 
> either adding extra parameters to the  element, or 
> by adding new values to the  element.
> 
> Of course one possibility is to simply say it is up to the 
> presence client to use the sip address from the contact, 
> together with some sip messaging to discover the current 
> capabilities of the endpoint. But that sounds like a very bad 
> idea to me - you are essentially back to polling all buddies 
> for presence information. I think it is important for the 
> presence document to be able to represent what media the 
> contact is prepared to use, so that can be displayed for the 
> end user. (I want to be able to see at a glance whether you 
> are present for IM or Voice, or both.

Regards,
Krisztian

From bateman@acm.org  Thu Sep  5 13:30:54 2002
Received: from cmailm4.svr.pol.co.uk (cmailm4.svr.pol.co.uk [195.92.193.211])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14366
	for ; Thu, 5 Sep 2002 13:30:54 -0400 (EDT)
Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk)
	by cmailm4.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17n0Sr-0003ek-00; Thu, 05 Sep 2002 18:30:45 +0100
Received: from modem-1554.zebra.dialup.pol.co.uk ([81.76.150.18] helo=ADRIANXP)
	by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1)
	id 17n0Sn-0000zp-00; Thu, 05 Sep 2002 18:30:42 +0100
Reply-To: 
From: "Adrian Bateman" 
To: , ,
        
Cc: 
Subject: RE: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05
Date: Thu, 5 Sep 2002 18:30:20 +0100
Organization: VisionTech Limited
MIME-Version: 1.0
Message-ID: <005001c25501$ec399480$6405010a@ADRIANXP>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_004B_01C2550A.4A59D3B0"
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 5891
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_004B_01C2550A.4A59D3B0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

On 05 September 2002 17:31, krisztian.kiss@nokia.com wrote:
> The reason why I initiated this thread on IMPP list was not to define
> 'away', 'idle', 'busy', etc. It was rather adding exact communication
> means to tuples (like 'voice', 'video', 'game', etc.), which goes
beyond
> the contact's URI scheme. Currently if a tuple contains a contact,
like:
> sip:someone@example.com
> its communication mean is 'sip:' which does not tell too much about
the
> presentity's capabilities & willingness whether he/she wants to use
this
> sip: contact for voice, video or chat. This might be a specific issue
of
> SIP URIs, therefore it was proposed to move the discussion to this
list.

I appreciate that but my interpretation of 

  SEP 02  Submission of SIMPLE PIDF profile to IESG for 
          publication as Proposed Standard 

from past discussions was with the application of PIDF to IM (SIMPLE is
also about IM over SIP is it not?). If media type is also a SIMPLE work
item then I see no reason why the two very similar efforts can't be
handled at the same time to help us move along.

Adrian.

------=_NextPart_000_004B_01C2550A.4A59D3B0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCCAngw
ggHhoAMCAQICAwfOcTANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAyMDcwMTIwMTI0M1oXDTAzMDcwMTIwMTI0M1owQTEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEeMBwGCSqGSIb3DQEJARYPYmF0ZW1hbkBhY20ub3JnMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDCBKe8lwUCrhtKabcZh1lrG7ZSeNf3JXcVr6kLZtkNmYUfLouB
/sz5RaLkoiLaKXGMj0bXaPDo5XKJG+RydduRwvMvDl9CeU8IRRfCM68ECOTcFMQdf3JMxXtujXf9
Pkq5otwVpjIePufMkNqvT257Z+w2S9WisYxIkwXteyc4dwIDAQABoywwKjAaBgNVHREEEzARgQ9i
YXRlbWFuQGFjbS5vcmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCw9gtsDshcl4Hb
vu5P7VhTSsLpofXY3oyyDKYMynjM9RMWr250Cz3X38Y+5e3idgNvvfaQgvVEotdM5WCX9DqXO7VF
TQHFXlDE1K0ZNtpTw954jWYOYX3WLkJjg/SNCO0WBdZYu4hSsMsgQwj7atYWmdjGILk4iJ7M3Hds
8M0tjDCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYD
VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV
BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt
ZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQsw
CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY
BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2Vz
IERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG
9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0tDY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj
3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSGXq3qwF5269kUo11uenwMpUtVfwYZKX+emibV
ars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcN
AQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41gWGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umSc
F6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3kmv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLm
nC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM4MIICoaADAgECAhBmRXK3zHT1z2N2RYTQLpEBMA0G
CSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD
VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0
aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcN
MDAwODMwMDAwMDAwWhcNMDQwODI3MjM1OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKX
DuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu
2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04w
TDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgw
BgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAMbFLR135AXHl9VNsXXnWPZjA
JhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQVahs9w2tTBu8A/S166JHn2yiDFiNMUIJ
EWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKtBcYxggNp
MIIDZQIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE
BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHznEwCQYFKw4D
AhoFAKCCAiQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwOTA1
MTczMDIwWjAjBgkqhkiG9w0BCQQxFgQU2V+uYYOkQFRZqtGirOyUdQbHwvowZwYJKoZIhvcNAQkP
MVowWDAKBggqhkiG9w0DBzAHBgUrDgMCGjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIhvcNAgUwgasGCSsGAQQBgjcQBDGBnTCBmjCB
kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD
Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMHznEwga0GCyqGSIb3DQEJEAILMYGd
oIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBl
IFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAm
BgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwfOcTANBgkqhkiG9w0BAQEF
AASBgE7LcK86Im4FHxNDl5cNrP9rhiRHrGs61ZppqXNEmrYOCIeIzP3Hex4fHPlPkdZ9FqhuVFzD
Co8oi0SuagKcOrhET/7BcK9sgkMIqJcochCyu5qp3tPjTKbwLe32TCCPQLLoKLhA9R0xemsbcSYa
h4Ou7tkKmcsNdReU4ALYFhPPAAAAAAAA

------=_NextPart_000_004B_01C2550A.4A59D3B0--



From pkyzivat@cisco.com  Thu Sep  5 14:06:05 2002
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 OAA14525
	for ; Thu, 5 Sep 2002 14:06:05 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g85I5sip000630;
	Thu, 5 Sep 2002 14:05:55 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAQ31660;
	Thu, 5 Sep 2002 14:10:12 -0400 (EDT)
Message-ID: <3D779CE5.AC475583@cisco.com>
Date: Thu, 05 Sep 2002 14:05:25 -0400
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: bateman@acm.org
CC: krisztian.kiss@nokia.com, jdrosen@dynamicsoft.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05
References: <005001c25501$ec399480$6405010a@ADRIANXP>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 833
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: 


Adrian Bateman wrote:
> 
> I appreciate that but my interpretation of
> 
>   SEP 02  Submission of SIMPLE PIDF profile to IESG for
>           publication as Proposed Standard
> 
> from past discussions was with the application of PIDF to IM (SIMPLE is
> also about IM over SIP is it not?). If media type is also a SIMPLE work
> item then I see no reason why the two very similar efforts can't be
> handled at the same time to help us move along.

I don't know if addressing media type, or perhaps more generally addressing the application of PIDF to SIP in all its glory, is covered by this or any other work item of SIMPLE. Based on the feedback in impp, this is deemed the appropriate place to address it. 

I defer a decision on whether this requires a new work item to those with more understanding of IETF procedures.

	Paul

From jdrosen@dynamicsoft.com  Thu Sep  5 14:20:50 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14596
	for ; Thu, 5 Sep 2002 14:20:49 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.52])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g85IKnYH016922;
	Thu, 5 Sep 2002 14:20:49 -0400 (EDT)
Message-ID: <3D77A080.4020906@dynamicsoft.com>
Date: Thu, 05 Sep 2002 14:20:48 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: bateman@acm.org, krisztian.kiss@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05
References: <005001c25501$ec399480$6405010a@ADRIANXP> <3D779CE5.AC475583@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1205
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: 


Paul Kyzivat wrote:
 >
 > Adrian Bateman wrote:
 >
 >> I appreciate that but my interpretation of
 >>
 >> SEP 02  Submission of SIMPLE PIDF profile to IESG for publication
 >> as Proposed Standard
 >>
 >> from past discussions was with the application of PIDF to IM
 >> (SIMPLE is also about IM over SIP is it not?). If media type is
 >> also a SIMPLE work item then I see no reason why the two very
 >> similar efforts can't be handled at the same time to help us move
 >> along.
 >
 >
 > I don't know if addressing media type, or perhaps more generally
 > addressing the application of PIDF to SIP in all its glory, is
 > covered by this or any other work item of SIMPLE. Based on the
 > feedback in impp, this is deemed the appropriate place to address it.

I think its reasonable to include it in the scope of the current work item.

-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


From Venkatesh.Venkataramanan@sylantro.com  Thu Sep  5 20:36:10 2002
Received: from mailserver.sylantro.com ([65.200.90.207])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id UAA15667
	for ; Thu, 5 Sep 2002 20:36:09 -0400 (EDT)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7);); Thu, 05 Sep 2002 17:34:59 -0700
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <1Y4A01XV>; Thu, 5 Sep 2002 17:34:59 -0700
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD014B477D@mailserver.sylantro.com>
From: "Venkatesh Venkataramanan" 
To: "'Sean Olson'" ,
        "Fred O'Leary" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] draft-ietf-sipping-dialog-package-00.txt
Date: Thu, 5 Sep 2002 17:34:58 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 116927B950846-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Length: 2205
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: 

Wouldn't it be appropriate to add the "media" states to the dialog package
as well? It could be thought of as the state of the dialog after all? 

For starters adding states like "Held", "Parked" ? 

Venkatesh

-----Original Message-----
From: Sean Olson [mailto:seancolson@yahoo.com]
Sent: Friday, August 16, 2002 3:10 PM
To: Fred O'Leary; simple@mailman.dynamicsoft.com
Subject: Re: [Simple] draft-ietf-sipping-dialog-package-00.txt


It sounds like there are at least three types
of things you might be interested in:

1) The signaling state of SIP dialogs at an endpoint
   (the dialog package)

2) The signaling state of a conference composed of
these
   dialogs (the conference package)

3) The state of the media associated with a 
   particular session at a particular endpoint
   (also the conference package?)

The last thing is the least defined of the three.

You might also be interested in the draft on
markup (wrt feature keys):

http://search.ietf.org/internet-drafts/draft-rosenberg-sipping-markup-00.txt

Sean Olson
Microsoft


--- Fred O'Leary  wrote:
> Hi,
> draft-ietf-sipping-dialog-package-00.txt outlines
> SIP events regards to call
> dialogs. Does it make sense to include other call
> states such as:
> HOLD - Call is being held
> CONFERENCING - Call is being conferenced
> CONFERENCED - Call is now conferenced
> PARKED - Call has been parked.
> 
> Additionally would anyone know if any drafts cover
> non-call related phone
> states such as Feature key requests, Do-No-Disturb,
> Off-hook etc? 
> 
> The reason I ask is that we have applications that
> wish to monitor end-point
> state as well as call state.
> Thanks in advance.
> 
> 
> 
> Fred O'Leary
> MTS Sylantro Systems Corp.
> (408)626-3040
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple


From himanshooks@huawei.com  Thu Sep  5 22:20:47 2002
Received: from mta0 ([61.144.161.2])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15997
	for ; Thu, 5 Sep 2002 22:20:45 -0400 (EDT)
Received: from himanshoo (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H1Z00IWNVRHTZ@mta0.huawei.com> for
 simple@mailman.dynamicsoft.com; Fri, 06 Sep 2002 10:18:55 +0800 (CST)
Date: Fri, 06 Sep 2002 10:22:36 +0800
From: Himanshoo Kumar Saxena 
To: Jonathan Rosenberg ,
        Paul Kyzivat 
Cc: simple@mailman.dynamicsoft.com
Reply-to: Himanshoo Kumar Saxena 
Message-id: <000c01c2554c$444a7140$7f984c0a@himanshoo>
Organization: Hua Wei, LongGang , China
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_iD+O2+y+JzyOzd/GMoK5Ew)"
X-Priority: 3
X-MSMail-priority: Normal
References: <005001c25501$ec399480$6405010a@ADRIANXP>
 <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com>
Content-Length: 2750
Subject: [Simple] ungraceful shutdwon of presence clients
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: 

This is a multi-part message in MIME format.

--Boundary_(ID_iD+O2+y+JzyOzd/GMoK5Ew)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi,

A simple question to confirm my understanding...

Consider subscriber A having REGISTERED via. REGISTER.. Now another subscriber B subscribes for A's presence information.
Based on the duration in expires header field of A's subscription, till that time, A is considered online. In the meantime, A goes down ( I mean ungraceful shutdwon e.g. machine shutdown) But for presence server A is still online since the expires period hasn't yet ended. So if B tries to send a message to A , then presence server will send a SIP MESSAGE to A . Only upon expiry of response timeout to this MESSAGE request , the presence server will know that A is offline....
Is this understanding correct ?

Regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Shenzhen - 518000
P.R.China

--Boundary_(ID_iD+O2+y+JzyOzd/GMoK5Ew)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT









Hi,


 


A simple question to 
confirm my understanding...


 


Consider subscriber A having REGISTERED via. 
REGISTER.. Now another subscriber B subscribes for A's presence 
information.


Based on the duration in expires header field of 
A's subscription, till that time, A is considered online. In the meantime, A 
goes down ( I mean ungraceful shutdwon e.g. machine shutdown) But for 
presence server A is still online since the expires period hasn't yet ended. So 
if B tries to send a message to A , then presence server will send a SIP MESSAGE 
to A . Only upon expiry of response timeout to this MESSAGE request , the 
presence server will know that A is offline....


Is this understanding correct ?


 


Regards


----------------------------------------------------------
Himanshoo 
Kumar Saxena
IN service department
Huawei Technologies Company 
Limited
Shenzhen - 518000
P.R.China


--Boundary_(ID_iD+O2+y+JzyOzd/GMoK5Ew)--

From himanshooks@huawei.com  Thu Sep  5 22:37:00 2002
Received: from mta0 ([61.144.161.2])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16072
	for ; Thu, 5 Sep 2002 22:36:59 -0400 (EDT)
Received: from himanshoo (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H1Z00JJWWIP65@mta0.huawei.com> for
 simple@mailman.dynamicsoft.com; Fri, 06 Sep 2002 10:35:14 +0800 (CST)
Date: Fri, 06 Sep 2002 10:38:55 +0800
From: Himanshoo Kumar Saxena 
To: Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
Reply-to: Himanshoo Kumar Saxena 
Message-id: <001301c2554e$8be2c5a0$7f984c0a@himanshoo>
Organization: Hua Wei, LongGang , China
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_K0ogOK+byE1u8yVmm2y+EA)"
X-Priority: 3
X-MSMail-priority: Normal
References: <005001c25501$ec399480$6405010a@ADRIANXP>
 <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com>
Content-Length: 7122
Subject: [Simple] draft-rosenberg-impp-qauth-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: 

This is a multi-part message in MIME format.

--Boundary_(ID_K0ogOK+byE1u8yVmm2y+EA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi,

THis draft was supposed to expire on December 2000. Has it been updated or included in soem RFC. Is somebody updating this draft ?

regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Hua Dian R&D Center
4th floor,
Long Gang District
Shenzhen - 518000
P.R.China
Ph: +86-755-28788478(Off)
       +86-755-28767187(Res)
  ----- Original Message ----- 
  From: Jonathan Rosenberg 
  To: Paul Kyzivat 
  Cc: bateman@acm.org ; krisztian.kiss@nokia.com ; simple@mailman.dynamicsoft.com 
  Sent: Friday, September 06, 2002 2:20 AM
  Subject: Re: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05




  Paul Kyzivat wrote:
   >
   > Adrian Bateman wrote:
   >
   >> I appreciate that but my interpretation of
   >>
   >> SEP 02  Submission of SIMPLE PIDF profile to IESG for publication
   >> as Proposed Standard
   >>
   >> from past discussions was with the application of PIDF to IM
   >> (SIMPLE is also about IM over SIP is it not?). If media type is
   >> also a SIMPLE work item then I see no reason why the two very
   >> similar efforts can't be handled at the same time to help us move
   >> along.
   >
   >
   > I don't know if addressing media type, or perhaps more generally
   > addressing the application of PIDF to SIP in all its glory, is
   > covered by this or any other work item of SIMPLE. Based on the
   > feedback in impp, this is deemed the appropriate place to address it.

  I think its reasonable to include it in the scope of the current work item.

  -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

--Boundary_(ID_K0ogOK+byE1u8yVmm2y+EA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT









Hi,


 


THis draft was supposed to expire on December 2000. 
Has it been updated or included in soem RFC. Is somebody updating this draft 
?


 


regards


----------------------------------------------------------
Himanshoo 
Kumar Saxena
IN service department
Huawei Technologies Company 
Limited
Hua Dian R&D Center
4th floor,
Long Gang 
District
Shenzhen - 518000
P.R.China
Ph: 
+86-755-28788478(Off)
       
+86-755-28767187(Res)



  
----- Original Message ----- 

  
  
  
  
Sent: Friday, September 06, 2002 2:20 
  AM

  
Subject: Re: [Simple] RE: Communication 
  means in draft-ietf-impp-cpim-pidf-05

  



Paul Kyzivat wrote:
 >
 > Adrian 
  Bateman wrote:
 >
 >> I appreciate that but my 
  interpretation of
 >>
 >> SEP 02  Submission 
  of SIMPLE PIDF profile to IESG for publication
 >> as Proposed 
  Standard
 >>
 >> from past discussions was with 
  the application of PIDF to IM
 >> (SIMPLE is also about IM over 
  SIP is it not?). If media type is
 >> also a SIMPLE work item 
  then I see no reason why the two very
 >> similar efforts can't 
  be handled at the same time to help us move
 >> 
  along.
 >
 >
 > I don't know if addressing 
  media type, or perhaps more generally
 > addressing the application 
  of PIDF to SIP in all its glory, is
 > covered by this or any other 
  work item of SIMPLE. Based on the
 > feedback in impp, this is 
  deemed the appropriate place to address it.

I think its reasonable to 
  include it in the scope of the current work item.

-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


--Boundary_(ID_K0ogOK+byE1u8yVmm2y+EA)--

From himanshooks@huawei.com  Thu Sep  5 23:15:53 2002
Received: from mta0 ([61.144.161.2])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16230
	for ; Thu, 5 Sep 2002 23:15:49 -0400 (EDT)
Received: from himanshoo (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H1Z00JN0YBE65@mta0.huawei.com> for
 simple@mailman.dynamicsoft.com; Fri, 06 Sep 2002 11:14:04 +0800 (CST)
Date: Fri, 06 Sep 2002 11:17:45 +0800
From: Himanshoo Kumar Saxena 
To: Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
Reply-to: Himanshoo Kumar Saxena 
Message-id: <001f01c25553$f8a080b0$7f984c0a@himanshoo>
Organization: Hua Wei, LongGang , China
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_CYijeDd4YhDR2zrIBHlb8g)"
X-Priority: 3
X-MSMail-priority: Normal
References: <005001c25501$ec399480$6405010a@ADRIANXP>
 <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com>
 <001301c2554e$8be2c5a0$7f984c0a@himanshoo>
Content-Length: 1420
Subject: [Simple] (no subject)
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: 

This is a multi-part message in MIME format.

--Boundary_(ID_CYijeDd4YhDR2zrIBHlb8g)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi,

If a user client wants to REGISTER but also wants to provide some additional information like user Nick Name etc. then how can it be done ?

regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Shenzhen - 518000
P.R.China


--Boundary_(ID_CYijeDd4YhDR2zrIBHlb8g)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT









Hi,


 


If a user client wants to REGISTER but also wants 
to provide some additional information like user Nick Name etc. then how can it 
be done ?


 


regards


----------------------------------------------------------
Himanshoo 
Kumar Saxena
IN service department
Huawei Technologies Company 
Limited
Shenzhen - 518000
P.R.China


--Boundary_(ID_CYijeDd4YhDR2zrIBHlb8g)--

From jdrosen@dynamicsoft.com  Fri Sep  6 02:40:22 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16840
	for ; Fri, 6 Sep 2002 02:40:22 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.47])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g866eEYH017382;
	Fri, 6 Sep 2002 02:40:17 -0400 (EDT)
Message-ID: <3D784DCC.5030106@dynamicsoft.com>
Date: Fri, 06 Sep 2002 02:40:12 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Himanshoo Kumar Saxena 
CC: simple@mailman.dynamicsoft.com
References: <005001c25501$ec399480$6405010a@ADRIANXP> <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com> <001301c2554e$8be2c5a0$7f984c0a@himanshoo>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3638
Subject: [Simple] Re: draft-rosenberg-impp-qauth-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: 

This draft was abandoned long ago. The process of handling interactive 
authorization is through the watcherinfo specifications to inform the 
user that they need to make a decision:

http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-02.txt

followed by a setting of authorization policy for them. That can be done 
through wap/web. An explicit protocol for manipulating authorization is 
now on our charter; the requirements for it are documented in:

http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt

-Jonathan R.


Himanshoo Kumar Saxena wrote:
> Hi,
>  
> THis draft was supposed to expire on December 2000. Has it been updated 
> or included in soem RFC. Is somebody updating this draft ?
>  
> regards
> ----------------------------------------------------------
> Himanshoo Kumar Saxena
> IN service department
> Huawei Technologies Company Limited
> Hua Dian R&D Center
> 4th floor,
> Long Gang District
> Shenzhen - 518000
> P.R.China
> Ph: +86-755-28788478(Off)
>        +86-755-28767187(Res)
> 
>     ----- Original Message -----
>     *From:* Jonathan Rosenberg 
>     *To:* Paul Kyzivat 
>     *Cc:* bateman@acm.org  ;
>     krisztian.kiss@nokia.com  ;
>     simple@mailman.dynamicsoft.com 
>     *Sent:* Friday, September 06, 2002 2:20 AM
>     *Subject:* Re: [Simple] RE: Communication means in
>     draft-ietf-impp-cpim-pidf-05
> 
> 
> 
>     Paul Kyzivat wrote:
>      >
>      > Adrian Bateman wrote:
>      >
>      >> I appreciate that but my interpretation of
>      >>
>      >> SEP 02  Submission of SIMPLE PIDF profile to IESG for publication
>      >> as Proposed Standard
>      >>
>      >> from past discussions was with the application of PIDF to IM
>      >> (SIMPLE is also about IM over SIP is it not?). If media type is
>      >> also a SIMPLE work item then I see no reason why the two very
>      >> similar efforts can't be handled at the same time to help us move
>      >> along.
>      >
>      >
>      > I don't know if addressing media type, or perhaps more generally
>      > addressing the application of PIDF to SIP in all its glory, is
>      > covered by this or any other work item of SIMPLE. Based on the
>      > feedback in impp, this is deemed the appropriate place to address it.
> 
>     I think its reasonable to include it in the scope of the current
>     work item.
> 
>     -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
> 


-- 
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


From mikko.lonnfors@nokia.com  Fri Sep  6 03:27:04 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17017
	for ; Fri, 6 Sep 2002 03:27:03 -0400 (EDT)
From: mikko.lonnfors@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g867R5714770
	for ; Fri, 6 Sep 2002 10:27:06 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 6 Sep 2002 10:27:01 +0300
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 6 Sep 2002 10:27:01 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] ungraceful shutdwon of presence clients
Date: Fri, 6 Sep 2002 10:25:50 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF10410E@esebe004.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] ungraceful shutdwon of presence clients
Thread-Index: AcJVTDtgEUuVC0amSI6RARHgSQu98wAJC8AA
To: , , 
Cc: 
X-OriginalArrivalTime: 06 Sep 2002 07:27:01.0519 (UTC) FILETIME=[CAB581F0:01C25576]
Content-Length: 1659
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA17017
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: 

Hi,

Inline:

-----Original Message-----
From: ext Himanshoo Kumar Saxena [mailto:himanshooks@huawei.com]
Sent: 06 September, 2002 05:23
To: Jonathan Rosenberg; Paul Kyzivat
Cc: simple@mailman.dynamicsoft.com
Subject: [Simple] ungraceful shutdwon of presence clients


Hi,

A simple question to confirm my understanding...

Consider subscriber A having REGISTERED via. REGISTER.. Now another subscriber B subscribes for A's presence information.
Based on the duration in expires header field of A's subscription, till that time, A is considered online.

Yes, this can be done but it is presence system implementation issue.

 In the meantime, A goes down ( I mean ungraceful shutdwon e.g. machine shutdown) But for presence server A is still online since the expires period hasn't yet ended.

SIP or SIMPLE do not in this case provide PS any means to detect that A has shutdown. You system might  for example use some layer 2 mechanisms to detect that user A's device is not  active anymore but that is again implementation issue.

 So if B tries to send a message to A , then presence server will send a SIP MESSAGE to A . Only upon expiry of response timeout to this MESSAGE request , the presence server will know that A is offline....

Probably the PS has nothing to do with the MESSAGE request (request is not routed through it). User B would send message straight to user A and would then notice that request times out. 

best regards
- Mikko

Is this understanding correct ?

Regards
----------------------------------------------------------
Himanshoo Kumar Saxena
IN service department
Huawei Technologies Company Limited
Shenzhen - 518000
P.R.China

From adam@dynamicsoft.com  Fri Sep  6 10:05:06 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18189
	for ; Fri, 6 Sep 2002 10:05:06 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g86E4J7p023385;
	Fri, 6 Sep 2002 10:04:21 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 6 Sep 2002 09:04:53 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A640EC@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Himanshoo Kumar Saxena'" ,
        Jonathan Rosenberg
	 ,
        Paul Kyzivat 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] ungraceful shutdwon of presence clients
Date: Fri, 6 Sep 2002 09:04:50 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 728
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: 

Yes.

-----Original Message-----
From: Himanshoo Kumar Saxena [mailto:himanshooks@huawei.com]

Consider subscriber A having REGISTERED via. REGISTER.. Now another
subscriber B subscribes for A's presence information.
Based on the duration in expires header field of A's subscription, till that
time, A is considered online. In the meantime, A goes down ( I mean
ungraceful shutdwon e.g. machine shutdown) But for presence server A is
still online since the expires period hasn't yet ended. So if B tries to
send a message to A , then presence server will send a SIP MESSAGE to A .
Only upon expiry of response timeout to this MESSAGE request , the presence
server will know that A is offline....
Is this understanding correct ?

From jdrosen@dynamicsoft.com  Fri Sep  6 10:41:09 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18325
	for ; Fri, 6 Sep 2002 10:41:08 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.47])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g86Ef1YH017537;
	Fri, 6 Sep 2002 10:41:02 -0400 (EDT)
Message-ID: <3D78BE7C.5020305@dynamicsoft.com>
Date: Fri, 06 Sep 2002 10:41:00 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mikko.lonnfors@nokia.com
CC: himanshooks@huawei.com, pkyzivat@cisco.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] ungraceful shutdwon of presence clients
References: <0C1353ABB1DEB74DB067ADFF749C4EEF10410E@esebe004.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2006
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: 

comments inline.

mikko.lonnfors@nokia.com wrote:
 > Hi,
 >
 > Inline:
 >
 > -----Original Message----- From: ext Himanshoo Kumar Saxena
 > [mailto:himanshooks@huawei.com] Sent: 06 September, 2002 05:23 To:
 > Jonathan Rosenberg; Paul Kyzivat Cc: simple@mailman.dynamicsoft.com
 > Subject: [Simple] ungraceful shutdwon of presence clients
 >
 >
 >
 > In the meantime, A goes down ( I mean ungraceful shutdwon e.g.
 > machine shutdown) But for presence server A is still online since the
 > expires period hasn't yet ended.
 >
 > SIP or SIMPLE do not in this case provide PS any means to detect that
 > A has shutdown. You system might  for example use some layer 2
 > mechanisms to detect that user A's device is not  active anymore but
 > that is again implementation issue.

There are several answers here.

The first, and most important statement, is that the presence server can 
use any techniques at its disposal to determine the presence state of 
the users it represents.

So, what can a presence server do to handle failures of the hosts the 
users are connected to?

1. Use a lower registration refresh interval, so that the failure is 
detected faster (this is possible when the presence server and registrar 
are colocated)

2. The presence server can "ping" the client with periodic OPTIONS 
requests to check for liveness.

3. The presence server, if its also the proxy, can look for timeouts in 
messages which are sent to that client, as you suggest below.

I am sure there are other possibilities. The spec doesn't say what you 
can or cannot do. Any of the above three will interoperate with any 
SIMPLE compliant endpoint.

-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


From jdrosen@dynamicsoft.com  Fri Sep  6 10:43:11 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18360
	for ; Fri, 6 Sep 2002 10:43:11 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.47])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g86Eh6YH017546;
	Fri, 6 Sep 2002 10:43:08 -0400 (EDT)
Message-ID: <3D78BEF5.4060809@dynamicsoft.com>
Date: Fri, 06 Sep 2002 10:43:01 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Himanshoo Kumar Saxena 
CC: simple@mailman.dynamicsoft.com
References: <005001c25501$ec399480$6405010a@ADRIANXP> <3D779CE5.AC475583@cisco.com> <3D77A080.4020906@dynamicsoft.com> <001301c2554e$8be2c5a0$7f984c0a@himanshoo> <001f01c25553$f8a080b0$7f984c0a@himanshoo>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1025
Subject: [Simple] Re:
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: 

REGISTER is for establishing an address binding so that a client can be 
reached for incoming requests. It is not a tool for provisioning 
information like name, nickname, street address, and so on. You will 
need to use provisioning techniques for that (web page, for example).

-Jonathan R.

Himanshoo Kumar Saxena wrote:
> Hi,
>  
> If a user client wants to REGISTER but also wants to provide some 
> additional information like user Nick Name etc. then how can it be done ?
>  
> regards
> ----------------------------------------------------------
> Himanshoo Kumar Saxena
> IN service department
> Huawei Technologies Company Limited
> Shenzhen - 518000
> P.R.China


-- 
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


From rsparks@dynamicsoft.com  Tue Sep 10 16:20:21 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06393
	for ; Tue, 10 Sep 2002 16:20:20 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g8AEV7115730
	for ; Tue, 10 Sep 2002 09:31:07 -0500
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) 
Date: 10 Sep 2002 15:15:29 -0500
Message-Id: <1031688929.2674.92.camel@dhcp151.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Length: 73
Subject: [Simple] list keepalive test 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: 

4 days with no traffic - making sure the reflector is not broken.
RjS




From skadiyala@unboundtech.com  Tue Sep 10 17:38:53 2002
Received: from mta.azera.net ([207.8.113.141])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06635
	for ; Tue, 10 Sep 2002 17:38:53 -0400 (EDT)
Received: from mail.unboundtech.com (lvs-1.azera.net [207.8.113.133])
	by mta.azera.net (Postfix) with ESMTP id 69C8C33D02
	for ; Tue, 10 Sep 2002 17:33:14 -0400 (EDT)
Received: from chimobile2 (ool-18bfa1e3.dyn.optonline.net [24.191.161.227])
	by mail.unboundtech.com (Postfix) with SMTP id AD2C15E69C
	for ; Tue, 10 Sep 2002 16:46:48 -0500 (CDT)
Message-ID: <00f801c25912$717e9640$e3a1bf18@chimobile2>
From: "shanti" 
To: 
References: <1031688929.2674.92.camel@dhcp151.dfw.dynamicsoft.com>
Subject: Re: [Simple] list keepalive test message
Date: Tue, 10 Sep 2002 17:38:44 -0400
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.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Length: 998
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: 

This is a question regarding CPIM-SIMPLE gateway.

I do agree that when  CPIM-SIMPLE gateway receives SIP Presence or IM, It
should not involve itself converting  the SIP content body  to the CPIM
complaint protocol's payload , for many obvious reasons.

But before there is a independent standard for presence and IM exchange that
all the CPIM complaint end points understand ,  is it a good idea for the
gateway to convert the SIP body to that of the CPIM complaint protocol ? or
should it be left to the endpoints to do so ?

-viswashanti






----- Original Message -----
From: "Robert Sparks" 
To: 
Sent: Tuesday, September 10, 2002 4:15 PM
Subject: [Simple] list keepalive test message


> 4 days with no traffic - making sure the reflector is not broken.
> RjS
>
>
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From lauri.niskanen@nokia.com  Thu Sep 12 02:17:26 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12014
	for ; Thu, 12 Sep 2002 02:17:25 -0400 (EDT)
From: lauri.niskanen@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8C6Hb725353
	for ; Thu, 12 Sep 2002 09:17:37 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Thu, 12 Sep 2002 09:17:25 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 12 Sep 2002 09:17:25 +0300
Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 12 Sep 2002 09:17:24 +0300
Received: from ouebe010.NOE.Nokia.com ([172.23.70.43]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 12 Sep 2002 09:17:23 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 12 Sep 2002 09:17:22 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: simple digest, Vol 1 #518 - 2 msgs
Thread-Index: AcJZrJTJkrsFRQrRSJSLdTLjdywpoAAdzeMw
To: 
X-OriginalArrivalTime: 12 Sep 2002 06:17:23.0198 (UTC) FILETIME=[0EB6D1E0:01C25A24]
Content-Length: 2571
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id CAA12014
Subject: [Simple] Help to Unsubscribe
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: 

UNSUBSCRIBE 

Hi, I'd like to unsubscribe this mailing list.
Thanks in advance.

Cheers,
-Lauri

-----Original Message-----
From: ext simple-request@mailman.dynamicsoft.com
[mailto:simple-request@mailman.dynamicsoft.com]
Sent: 11 September, 2002 19:01
To: simple@mailman.dynamicsoft.com
Subject: simple digest, Vol 1 #518 - 2 msgs


Send simple mailing list submissions to
	simple@mailman.dynamicsoft.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.dynamicsoft.com/mailman/listinfo/simple
or, via email, send a message with subject or body 'help' to
	simple-request@mailman.dynamicsoft.com

You can reach the person managing the list at
	simple-admin@mailman.dynamicsoft.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of simple digest..."


Today's Topics:

   1. list keepalive test message (Robert Sparks)
   2. Re: list keepalive test message (shanti)

--__--__--

Message: 1
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Date: 10 Sep 2002 15:15:29 -0500
Subject: [Simple] list keepalive test message

4 days with no traffic - making sure the reflector is not broken.
RjS




--__--__--

Message: 2
From: "shanti" 
To: 
Subject: Re: [Simple] list keepalive test message
Date: Tue, 10 Sep 2002 17:38:44 -0400


This is a question regarding CPIM-SIMPLE gateway.

I do agree that when  CPIM-SIMPLE gateway receives SIP Presence or IM, It
should not involve itself converting  the SIP content body  to the CPIM
complaint protocol's payload , for many obvious reasons.

But before there is a independent standard for presence and IM exchange that
all the CPIM complaint end points understand ,  is it a good idea for the
gateway to convert the SIP body to that of the CPIM complaint protocol ? or
should it be left to the endpoints to do so ?

-viswashanti






----- Original Message -----
From: "Robert Sparks" 
To: 
Sent: Tuesday, September 10, 2002 4:15 PM
Subject: [Simple] list keepalive test message


> 4 days with no traffic - making sure the reflector is not broken.
> 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


End of simple Digest

From Markus.Isomaki@nokia.com  Thu Sep 12 05:44:25 2002
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 FAA12685
	for ; Thu, 12 Sep 2002 05:44:24 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8C9iSU21149
	for ; Thu, 12 Sep 2002 12:44:28 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 12 Sep 2002 12:44:23 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 12 Sep 2002 12:44:22 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05
Date: Thu, 12 Sep 2002 12:44:21 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] RE: Communication means in draft-ietf-impp-cpim-pidf-05
Thread-Index: AcJVCUKxblcMAuD1Ss+Ew5VsQCsGowFNhTmA
To: , 
Cc: , ,
        
X-OriginalArrivalTime: 12 Sep 2002 09:44:22.0219 (UTC) FILETIME=[F90709B0:01C25A40]
Content-Length: 3181
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA12685
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: 

Hi,

I think SIP caller preferences and callee capabilities has many nice and useful features, and that's why that draft was very interesting when it first came out.

Since then there has been very little happening around that draft. The reason is that many people, including myself, have understood that SIMPLE Presence is going to address many of those issues in an even better way. For example you can see what communication means the other person is willing to use right now by subscribing to her presence. At least for me that is one of the key things as I understand what "presence" should contain in communication networks.

In recent IMPP discussions I noticed that some people think that this kind of information should not be part of presence, which made me quite confused.

My proposal is to design the SIMPLE PIDF profile in such a way that  most of the callee capabilities information can be represented in the presence document in a standard and unambiguous way. Otherwise I don't see this work very useful.

That of course leads me to the question that if SIMPLE does an own profile for PIDF, what that means for interoperability with other systems, and what it means for the feasibility of PIDF for that purpose in the first place... Personally I would't worry about this, but I would still like to hear the motivation from someone who knows the origins and goals of PIDF better than me. 

Markus

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 05 September, 2002 21:21
> To: Paul Kyzivat
> Cc: bateman@acm.org; Kiss Krisztian (NRC/Tampere);
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] RE: Communication means in
> draft-ietf-impp-cpim-pidf-05
> 
> 
> 
> 
> Paul Kyzivat wrote:
>  >
>  > Adrian Bateman wrote:
>  >
>  >> I appreciate that but my interpretation of
>  >>
>  >> SEP 02  Submission of SIMPLE PIDF profile to IESG for publication
>  >> as Proposed Standard
>  >>
>  >> from past discussions was with the application of PIDF to IM
>  >> (SIMPLE is also about IM over SIP is it not?). If media type is
>  >> also a SIMPLE work item then I see no reason why the two very
>  >> similar efforts can't be handled at the same time to help us move
>  >> along.
>  >
>  >
>  > I don't know if addressing media type, or perhaps more generally
>  > addressing the application of PIDF to SIP in all its glory, is
>  > covered by this or any other work item of SIMPLE. Based on the
>  > feedback in impp, this is deemed the appropriate place to 
> address it.
> 
> I think its reasonable to include it in the scope of the 
> current work item.
> 
> -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 jdrosen@dynamicsoft.com  Thu Sep 12 16:59:59 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14806
	for ; Thu, 12 Sep 2002 16:59:59 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8CKxxYH022042
	for ; Thu, 12 Sep 2002 17:00:00 -0400 (EDT)
Message-ID: <3D81004C.70606@dynamicsoft.com>
Date: Thu, 12 Sep 2002 16:59:56 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2007
Subject: [Simple] moving forward on data requirements draft
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: 

Folks,

I am working on an update to the data-requirements draft:
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt

I'd like to make a proposal for a change in direction.

Right now, the draft discusses requirements for buddy list manipulation, 
and more or less states that the requirements for authorizations are 
similar. It spends the rest of the doc motivating a framework where 
there is a generic data manipulation requirement, and it tries to 
enumerate those requirements generally.

In Yokohama, this discussion of generalized data manipulation led us to 
a discussion on the relationship to protocols in this area, such as 
SyncML, acap, XPath (for naming components of a data object), and so on.

Having thought about this some more, I think that this discussion of 
generic data manipulation confuses requirements with solution. The use 
of a general data manipulation protocol, like acap or syncml, is a 
potential solution. We are best spending our time enumerating 
requirements for the specific problems we have to solve. Thus, I would 
propose dropping the entire generic data manipulation section, and go 
into much more detail on the specifics of the operations we need for 
buddy list manipulation and, more importantly, authorization. Then, when 
evaluating solutions, we can decide on a protocol that does more generic 
data manipulation.

Are people OK with this? I think this will help us quickly wrap up this 
effort so we can get to the protocol selection/design work, which is 
really needed badly.

I will send a separate note on some proposed additions to the 
authorization functions.

-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


From jdrosen@dynamicsoft.com  Thu Sep 12 17:11:31 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14869
	for ; Thu, 12 Sep 2002 17:11:31 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8CLBQYH022079
	for ; Thu, 12 Sep 2002 17:11:31 -0400 (EDT)
Message-ID: <3D8102FA.9020706@dynamicsoft.com>
Date: Thu, 12 Sep 2002 17:11:22 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1919
Subject: [Simple] some additions to the authorization requirements
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: 

Folks,

I'd like to seriously beef up the authorization requirements section of 
http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt 
to discuss a lot more of the specifics we want to accomplish.

The key thing is details on the level of permissions that are being 
granted by the presentity. Some additional requirements to consider:

* the user should be able to specify that the subscriber will only 
receive notifications containing a specific contact address (i.e., only 
my work phone)

* the user should be able to specify that the subscriber will only 
receive notifications containing a specific status type (basic, for 
example, which is the only status type defined so far).

* the user should be able to specify that the subscriber will only 
receive notifications containing specific values of a specific status 
type (for example, only report when my status goes to OPEN, not CLOSED)

* the user should be able to specify that the subscriber will or will 
not receive a contact address in the notifications.


Effectively, the above rules all specify filters or triggers on the 
presence documents that should be sent to a particular presentity.

We could specify rate-based filters (i.e., specify that a subscriber 
cannot receive documents more frequently than X per minute), but this 
doesn't seem awfully useful.


Related to that, if the SUBSCRIBE contained a filter of some sort, the 
authorization should allow the user to approve or reject their filter, 
and possibly impose further filtering as above.

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


From jdrosen@dynamicsoft.com  Thu Sep 12 17:25:45 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14925
	for ; Thu, 12 Sep 2002 17:25:45 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8CLPkYH022095
	for ; Thu, 12 Sep 2002 17:25:46 -0400 (EDT)
Message-ID: <3D810652.2090805@dynamicsoft.com>
Date: Thu, 12 Sep 2002 17:25:38 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2776
Subject: [Simple] collection template
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: 

Folks,

The current version of the old "buddy list" package now defines a 
collection template that can allow a user to subscribe to a list of URIs 
for a particular package, such as presence.

It has occurred to me since the meeting that we can take this one step 
farther for a really generally useful tool.

The idea is to make this a collection PACKAGE, not a template. The URI 
that you subscribe to represents a list of URIs, each of which can be 
for a different package. The list would also include information on the 
package that URI is associated with.

The idea here is that a UA could send a single subscribe to a server 
which would, in turn, fan out subscriptions to each of the events/URIs 
the user was interested in.

Heres an example. Lets say a UA is interested in a subscription to two 
message waiting indicators and two buddy lists:

sip:mwi1@serviceprovider1.com, mwi package
sip:mwi2@serviceprovider2.com, mwi package
sip:buddylist1@serviceprovider1.com, collection package
sip:buddylist2@serviceprovider2.com, collection package

the two buddy lists are themselves lists, each of which is a URI that 
represents a presentity. We could assign a single URI to the two MWIs 
and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would 
then do this:

SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0
Event: collection
Accept: text/collection-info, application/cpim-pidf+xml,
   application/simple-message-summary


The server would fan out a subscription to each element in the list 
within the package for that element, copying the Accept headers from the 
collection SUBSCRIBE. The collection server would be responsible for 
refreshing those fanned out subscriptions, and passing the content of 
notifications towards the UAC. The collection server could be ignorant 
of the detailed operation of any of the packages, and could generate 
subscriptions for packages it doesnt even understand.

If we envision that UAs will frequently have lots of long-lived 
subscriptions to a number of things, this mechanism can save a lot of 
overhead for wireless or other access constrained devices. It increases 
the administrative burden overall, since each collection URI needs to 
specify a modereately complex data structure - a list of elements, each 
of which is a URI/event pair. But, I think this is a worthwhile tradeoff.

Do people think this is a worthwhile approach?

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


From bcampbell@dynamicsoft.com  Thu Sep 12 17:44:35 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14991
	for ; Thu, 12 Sep 2002 17:44:34 -0400 (EDT)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g8CLiVpA062988;
	Thu, 12 Sep 2002 16:44:31 -0500 (CDT)
Message-ID: <3D810A83.80303@dynamicsoft.com>
Date: Thu, 12 Sep 2002 16:43:31 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <3D810652.2090805@dynamicsoft.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3000
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: 

Interesting. I am concerned, however, that the event negotiation part 
would now get lost. The event is now "collection" rather than 
"presence.collection" or whatever. By subscribing to .collection, 
I am asserting that I care about and can do something useful with 
notifies with an event header of . If I susbscrbe to "collection" 
without an event scope, I now have to expect NOTIFY requests for 
arbitrary events.


Jonathan Rosenberg wrote:
> Folks,
> 
> The current version of the old "buddy list" package now defines a 
> collection template that can allow a user to subscribe to a list of URIs 
> for a particular package, such as presence.
> 
> It has occurred to me since the meeting that we can take this one step 
> farther for a really generally useful tool.
> 
> The idea is to make this a collection PACKAGE, not a template. The URI 
> that you subscribe to represents a list of URIs, each of which can be 
> for a different package. The list would also include information on the 
> package that URI is associated with.
> 
> The idea here is that a UA could send a single subscribe to a server 
> which would, in turn, fan out subscriptions to each of the events/URIs 
> the user was interested in.
> 
> Heres an example. Lets say a UA is interested in a subscription to two 
> message waiting indicators and two buddy lists:
> 
> sip:mwi1@serviceprovider1.com, mwi package
> sip:mwi2@serviceprovider2.com, mwi package
> sip:buddylist1@serviceprovider1.com, collection package
> sip:buddylist2@serviceprovider2.com, collection package
> 
> the two buddy lists are themselves lists, each of which is a URI that 
> represents a presentity. We could assign a single URI to the two MWIs 
> and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would 
> then do this:
> 
> SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0
> Event: collection
> Accept: text/collection-info, application/cpim-pidf+xml,
>   application/simple-message-summary
> 
> 
> The server would fan out a subscription to each element in the list 
> within the package for that element, copying the Accept headers from the 
> collection SUBSCRIBE. The collection server would be responsible for 
> refreshing those fanned out subscriptions, and passing the content of 
> notifications towards the UAC. The collection server could be ignorant 
> of the detailed operation of any of the packages, and could generate 
> subscriptions for packages it doesnt even understand.
> 
> If we envision that UAs will frequently have lots of long-lived 
> subscriptions to a number of things, this mechanism can save a lot of 
> overhead for wireless or other access constrained devices. It increases 
> the administrative burden overall, since each collection URI needs to 
> specify a modereately complex data structure - a list of elements, each 
> of which is a URI/event pair. But, I think this is a worthwhile tradeoff.
> 
> Do people think this is a worthwhile approach?
> 
> Thanks,
> Jonathan R.



From pkyzivat@cisco.com  Thu Sep 12 19:15:11 2002
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 TAA15239
	for ; Thu, 12 Sep 2002 19:15:10 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8CNFAl7002179;
	Thu, 12 Sep 2002 19:15:11 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAQ77322;
	Thu, 12 Sep 2002 19:19:42 -0400 (EDT)
Message-ID: <3D811FEE.FFAA9102@cisco.com>
Date: Thu, 12 Sep 2002 19:14:54 -0400
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] some additions to the authorization requirements
References: <3D8102FA.9020706@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3431
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: 

below...

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> I'd like to seriously beef up the authorization requirements section of
> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-data-req-00.txt
> to discuss a lot more of the specifics we want to accomplish.
> 
> The key thing is details on the level of permissions that are being
> granted by the presentity. Some additional requirements to consider:

Seems like a good direction in general.

> 
> * the user should be able to specify that the subscriber will only
> receive notifications containing a specific contact address (i.e., only
> my work phone)

Good, but may be hard to define. My work phone may not always have the same contact address (because of DHCP and lack of an assigned DNS name.) May need to identify in some other way - e.g. via the credential used to register it. (I don't like that alternative much, but I'm grasping for something other than the contact address itself.)

(Unfortunately devices without DNS names are not especially unusual. Not just phones, but Microsoft devices that use WINS rather than DNS.) 

> 
> * the user should be able to specify that the subscriber will only
> receive notifications containing a specific status type (basic, for
> example, which is the only status type defined so far).

fine.

> 
> * the user should be able to specify that the subscriber will only
> receive notifications containing specific values of a specific status
> type (for example, only report when my status goes to OPEN, not CLOSED)

This might be troublesome. What happens if, when I first subscribe, the status only contains values I am not permitted to receive? I have to receive a notification of some sort, and every tuple is required to carry some status. So I think the entire tuple must be suppressed if there are no status values that can be returned. When the status changes, I should get a notification again if the value I had previously received is different than what I would receive if I polled now. 

Perhaps this requirement could be reworded to solve this problem:

 * the user should be able to specify the specific values of a
   specific status type that the subscribe IS, or IS NOT, permitted
   to receive. Values not permitted must be omitted from the status
   in notifications. If all status is omitted, the tuple must be 
   omitted as well. (for example, include tuples with OPEN status,
   but suppress those with only CLOSED status.)

> 
> * the user should be able to specify that the subscriber will or will
> not receive a contact address in the notifications.

yes - good.

> 
> Effectively, the above rules all specify filters or triggers on the
> presence documents that should be sent to a particular presentity.
> 
> We could specify rate-based filters (i.e., specify that a subscriber
> cannot receive documents more frequently than X per minute), but this
> doesn't seem awfully useful.
> 
> Related to that, if the SUBSCRIBE contained a filter of some sort, the
> authorization should allow the user to approve or reject their filter,
> and possibly impose further filtering as above.

Is there any reason to forbid filtering requests from the subscriber?

Would make more sense to me to just require that if both sides supply filters than they must be composed - the document must be passed through both. As long as a filter only removes things it doesn't matter what order they are applied.

	Paul

From jdrosen@dynamicsoft.com  Thu Sep 12 23:15:10 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA15870
	for ; Thu, 12 Sep 2002 23:15:10 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.49])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8D3FAYH022284;
	Thu, 12 Sep 2002 23:15:10 -0400 (EDT)
Message-ID: <3D81583D.2000904@dynamicsoft.com>
Date: Thu, 12 Sep 2002 23:15:09 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <3D810652.2090805@dynamicsoft.com> <3D810A83.80303@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3775
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: 

We could do something similar to what I had suggested for the Accept 
header. The SUBSCRIBE has Allow-Events which lists the event types 
supported. If one of the URI in the list is of a type not indicated in 
Allow-Events, the subscription is rejected.

Not quite the intended use of Allow-Events, for sure....

-Jonathan R.

Ben Campbell wrote:
> Interesting. I am concerned, however, that the event negotiation part 
> would now get lost. The event is now "collection" rather than 
> "presence.collection" or whatever. By subscribing to .collection, 
> I am asserting that I care about and can do something useful with 
> notifies with an event header of . If I susbscrbe to "collection" 
> without an event scope, I now have to expect NOTIFY requests for 
> arbitrary events.
> 
> 
> Jonathan Rosenberg wrote:
> 
>> Folks,
>>
>> The current version of the old "buddy list" package now defines a 
>> collection template that can allow a user to subscribe to a list of 
>> URIs for a particular package, such as presence.
>>
>> It has occurred to me since the meeting that we can take this one step 
>> farther for a really generally useful tool.
>>
>> The idea is to make this a collection PACKAGE, not a template. The URI 
>> that you subscribe to represents a list of URIs, each of which can be 
>> for a different package. The list would also include information on 
>> the package that URI is associated with.
>>
>> The idea here is that a UA could send a single subscribe to a server 
>> which would, in turn, fan out subscriptions to each of the events/URIs 
>> the user was interested in.
>>
>> Heres an example. Lets say a UA is interested in a subscription to two 
>> message waiting indicators and two buddy lists:
>>
>> sip:mwi1@serviceprovider1.com, mwi package
>> sip:mwi2@serviceprovider2.com, mwi package
>> sip:buddylist1@serviceprovider1.com, collection package
>> sip:buddylist2@serviceprovider2.com, collection package
>>
>> the two buddy lists are themselves lists, each of which is a URI that 
>> represents a presentity. We could assign a single URI to the two MWIs 
>> and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would 
>> then do this:
>>
>> SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0
>> Event: collection
>> Accept: text/collection-info, application/cpim-pidf+xml,
>>   application/simple-message-summary
>>
>>
>> The server would fan out a subscription to each element in the list 
>> within the package for that element, copying the Accept headers from 
>> the collection SUBSCRIBE. The collection server would be responsible 
>> for refreshing those fanned out subscriptions, and passing the content 
>> of notifications towards the UAC. The collection server could be 
>> ignorant of the detailed operation of any of the packages, and could 
>> generate subscriptions for packages it doesnt even understand.
>>
>> If we envision that UAs will frequently have lots of long-lived 
>> subscriptions to a number of things, this mechanism can save a lot of 
>> overhead for wireless or other access constrained devices. It 
>> increases the administrative burden overall, since each collection URI 
>> needs to specify a modereately complex data structure - a list of 
>> elements, each of which is a URI/event pair. But, I think this is a 
>> worthwhile tradeoff.
>>
>> Do people think this is a worthwhile approach?
>>
>> 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


From Gonzalo.Camarillo@lmf.ericsson.se  Fri Sep 13 07:30:38 2002
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17207
	for ; Fri, 13 Sep 2002 07:30:37 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8DBUTrU004657;
	Fri, 13 Sep 2002 13:30:29 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.18])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g8DBUTG3008313;
	Fri, 13 Sep 2002 14:30:29 +0300 (EET DST)
Message-ID: <3D81CC54.C9773ACB@lmf.ericsson.se>
Date: Fri, 13 Sep 2002 14:30:28 +0300
From: Gonzalo Camarillo 
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Costa Requena 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] addressing scheme in Request-URI
References: <200206261920.PAA23241@dynasty.cs.columbia.edu> <1030533613.3d6cb1ed50276@keskus.tct.hut.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1244
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: 

Jose,

The request-URI can have other URI schemes, such as im: or pres:.
However, it is recommended that they are converted to SIP or SIPS URIs
as soon as possible. That is, if the UA could not do it by itself, the
outbound proxy is the best place to do it. This ensures that SIP proxies
that are not im or pres aware can route messages correctly.

Regards,

Gonzalo

Costa Requena wrote:
> 
> Hi,
> 
> Just quick question!
> I read in previous specs that SIP Request-URI SHOULD have sip: as address
> scheme while To: header MAY have others than sip: schemes.In recent specs
> it says that the content of To: header is copied in Request-URI.
> Could someone ensure that the Request-URI MAY have other schemes than sip: or
> sips: let's say im: pres: http:, etc.
> 
> Thanks in advance!
> BR
> Jose
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

From hisham.khartabil@nokia.com  Fri Sep 13 10:54:23 2002
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 KAA17859
	for ; Fri, 13 Sep 2002 10:54:22 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8DEsJT29459
	for ; Fri, 13 Sep 2002 17:54:19 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 13 Sep 2002 17:54:21 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 13 Sep 2002 17:54:21 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 13 Sep 2002 17:54:21 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] collection template
Date: Fri, 13 Sep 2002 17:54:20 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2061C@esebe019.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] collection template
Thread-Index: AcJa1DHqZhFtQi+IS5m1eri8/33PUwAXw3nQ
To: , 
Cc: 
X-OriginalArrivalTime: 13 Sep 2002 14:54:21.0572 (UTC) FILETIME=[7184D440:01C25B35]
Content-Length: 4617
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA17859
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: 

I think its much simpler if we have .collection. 

Can the subscriber rely on the content-type of NOTIFY to decide if this NOTIFY contains payload for mwi or buddylist?

/Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, September 13, 2002 6:15 AM
> To: Ben Campbell
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] collection template
> 
> 
> We could do something similar to what I had suggested for the Accept 
> header. The SUBSCRIBE has Allow-Events which lists the event types 
> supported. If one of the URI in the list is of a type not 
> indicated in 
> Allow-Events, the subscription is rejected.
> 
> Not quite the intended use of Allow-Events, for sure....
> 
> -Jonathan R.
> 
> Ben Campbell wrote:
> > Interesting. I am concerned, however, that the event 
> negotiation part 
> > would now get lost. The event is now "collection" rather than 
> > "presence.collection" or whatever. By subscribing to 
> .collection, 
> > I am asserting that I care about and can do something useful with 
> > notifies with an event header of . If I susbscrbe to 
> "collection" 
> > without an event scope, I now have to expect NOTIFY requests for 
> > arbitrary events.
> > 
> > 
> > Jonathan Rosenberg wrote:
> > 
> >> Folks,
> >>
> >> The current version of the old "buddy list" package now defines a 
> >> collection template that can allow a user to subscribe to 
> a list of 
> >> URIs for a particular package, such as presence.
> >>
> >> It has occurred to me since the meeting that we can take 
> this one step 
> >> farther for a really generally useful tool.
> >>
> >> The idea is to make this a collection PACKAGE, not a 
> template. The URI 
> >> that you subscribe to represents a list of URIs, each of 
> which can be 
> >> for a different package. The list would also include 
> information on 
> >> the package that URI is associated with.
> >>
> >> The idea here is that a UA could send a single subscribe 
> to a server 
> >> which would, in turn, fan out subscriptions to each of the 
> events/URIs 
> >> the user was interested in.
> >>
> >> Heres an example. Lets say a UA is interested in a 
> subscription to two 
> >> message waiting indicators and two buddy lists:
> >>
> >> sip:mwi1@serviceprovider1.com, mwi package
> >> sip:mwi2@serviceprovider2.com, mwi package
> >> sip:buddylist1@serviceprovider1.com, collection package
> >> sip:buddylist2@serviceprovider2.com, collection package
> >>
> >> the two buddy lists are themselves lists, each of which is 
> a URI that 
> >> represents a presentity. We could assign a single URI to 
> the two MWIs 
> >> and two buddy lists - sip:mystuff@serviceprovider1.com. 
> The UA would 
> >> then do this:
> >>
> >> SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0
> >> Event: collection
> >> Accept: text/collection-info, application/cpim-pidf+xml,
> >>   application/simple-message-summary
> >>
> >>
> >> The server would fan out a subscription to each element in 
> the list 
> >> within the package for that element, copying the Accept 
> headers from 
> >> the collection SUBSCRIBE. The collection server would be 
> responsible 
> >> for refreshing those fanned out subscriptions, and passing 
> the content 
> >> of notifications towards the UAC. The collection server could be 
> >> ignorant of the detailed operation of any of the packages, 
> and could 
> >> generate subscriptions for packages it doesnt even understand.
> >>
> >> If we envision that UAs will frequently have lots of long-lived 
> >> subscriptions to a number of things, this mechanism can 
> save a lot of 
> >> overhead for wireless or other access constrained devices. It 
> >> increases the administrative burden overall, since each 
> collection URI 
> >> needs to specify a modereately complex data structure - a list of 
> >> elements, each of which is a URI/event pair. But, I think 
> this is a 
> >> worthwhile tradeoff.
> >>
> >> Do people think this is a worthwhile approach?
> >>
> >> 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 aki.niemi@nokia.com  Mon Sep 16 08:52:01 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00988
	for ; Mon, 16 Sep 2002 08:52:01 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8GCqFZ04322
	for ; Mon, 16 Sep 2002 15:52:15 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 16 Sep 2002 15:51:58 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 16 Sep 2002 15:51:58 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] collection template
Date: Mon, 16 Sep 2002 15:51:57 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901944FC3@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] collection template
Thread-Index: AcJaoyEVv3rrRmJVTGqQGuTk59K+1gC2qs8g
To: , 
X-OriginalArrivalTime: 16 Sep 2002 12:51:58.0579 (UTC) FILETIME=[D7FE4430:01C25D7F]
Content-Length: 3754
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA00988
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: 

Hi Jonathan,

It seems that this approach also makes the recursion of presence-list subscriptions easier. I had some doubts about the previous template package based proposal (especially the part about defaulting to presence from presence.collection), because of the fact that one could potentially have both presence *and* presence-collection events in the same SIP URI. 

So, I like this approach. Let's go for it.

Cheers,
Aki


> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, September 13, 2002 12:26 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] collection template
> 
> 
> Folks,
> 
> The current version of the old "buddy list" package now defines a 
> collection template that can allow a user to subscribe to a 
> list of URIs 
> for a particular package, such as presence.
> 
> It has occurred to me since the meeting that we can take this 
> one step 
> farther for a really generally useful tool.
> 
> The idea is to make this a collection PACKAGE, not a 
> template. The URI 
> that you subscribe to represents a list of URIs, each of which can be 
> for a different package. The list would also include 
> information on the 
> package that URI is associated with.
> 
> The idea here is that a UA could send a single subscribe to a server 
> which would, in turn, fan out subscriptions to each of the 
> events/URIs 
> the user was interested in.
> 
> Heres an example. Lets say a UA is interested in a 
> subscription to two 
> message waiting indicators and two buddy lists:
> 
> sip:mwi1@serviceprovider1.com, mwi package
> sip:mwi2@serviceprovider2.com, mwi package
> sip:buddylist1@serviceprovider1.com, collection package
> sip:buddylist2@serviceprovider2.com, collection package
> 
> the two buddy lists are themselves lists, each of which is a URI that 
> represents a presentity. We could assign a single URI to the two MWIs 
> and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would 
> then do this:
> 
> SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0
> Event: collection
> Accept: text/collection-info, application/cpim-pidf+xml,
>    application/simple-message-summary
> 
> 
> The server would fan out a subscription to each element in the list 
> within the package for that element, copying the Accept 
> headers from the 
> collection SUBSCRIBE. The collection server would be responsible for 
> refreshing those fanned out subscriptions, and passing the content of 
> notifications towards the UAC. The collection server could be 
> ignorant 
> of the detailed operation of any of the packages, and could generate 
> subscriptions for packages it doesnt even understand.
> 
> If we envision that UAs will frequently have lots of long-lived 
> subscriptions to a number of things, this mechanism can save a lot of 
> overhead for wireless or other access constrained devices. It 
> increases 
> the administrative burden overall, since each collection URI needs to 
> specify a modereately complex data structure - a list of 
> elements, each 
> of which is a URI/event pair. But, I think this is a 
> worthwhile tradeoff.
> 
> Do people think this is a worthwhile approach?
> 
> 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 seancolson@yahoo.com  Mon Sep 16 10:52:50 2002
Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA01393
	for ; Mon, 16 Sep 2002 10:52:49 -0400 (EDT)
Message-ID: <20020916145236.1705.qmail@web11604.mail.yahoo.com>
Received: from [207.46.137.250] by web11604.mail.yahoo.com via HTTP; Mon, 16 Sep 2002 07:52:36 PDT
Date: Mon, 16 Sep 2002 07:52:36 -0700 (PDT)
From: Sean Olson 
Subject: RE: [Simple] collection template
To: aki.niemi@nokia.com, jdrosen@dynamicsoft.com,
        simple@mailman.dynamicsoft.com
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901944FC3@esebe013.ntc.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 5062
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: 

I would like to reiterate Ben's concerns over
negotiation of supported Event packages. I think
turning the collection template into a package
would go against the basic design of the SUB/NOT
mechanism. Having a collection template would still
be a big win in terms of bandwidth. Having to send
multiple .collection SUBs is still a lot
better than having to do the individual SUBs.
 
At the very least, I would not rely on the Accept
headers for a pseudo-negotiation. Instead, I would
turn to an appropriate "filter" for the body of 
the SUBSCRIBE to create a meta-level of negotiation.
This is already feeling too complex to me, but we
should make this as clean a design as possible.

Sean Olson
Microsoft


--- aki.niemi@nokia.com wrote:
> Hi Jonathan,
> 
> It seems that this approach also makes the recursion
> of presence-list subscriptions easier. I had some
> doubts about the previous template package based
> proposal (especially the part about defaulting to
> presence from presence.collection), because of the
> fact that one could potentially have both presence
> *and* presence-collection events in the same SIP
> URI. 
> 
> So, I like this approach. Let's go for it.
> 
> Cheers,
> Aki
> 
> 
> > -----Original Message-----
> > From: ext Jonathan Rosenberg
> [mailto:jdrosen@dynamicsoft.com]
> > Sent: Friday, September 13, 2002 12:26 AM
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] collection template
> > 
> > 
> > Folks,
> > 
> > The current version of the old "buddy list"
> package now defines a 
> > collection template that can allow a user to
> subscribe to a 
> > list of URIs 
> > for a particular package, such as presence.
> > 
> > It has occurred to me since the meeting that we
> can take this 
> > one step 
> > farther for a really generally useful tool.
> > 
> > The idea is to make this a collection PACKAGE, not
> a 
> > template. The URI 
> > that you subscribe to represents a list of URIs,
> each of which can be 
> > for a different package. The list would also
> include 
> > information on the 
> > package that URI is associated with.
> > 
> > The idea here is that a UA could send a single
> subscribe to a server 
> > which would, in turn, fan out subscriptions to
> each of the 
> > events/URIs 
> > the user was interested in.
> > 
> > Heres an example. Lets say a UA is interested in a
> 
> > subscription to two 
> > message waiting indicators and two buddy lists:
> > 
> > sip:mwi1@serviceprovider1.com, mwi package
> > sip:mwi2@serviceprovider2.com, mwi package
> > sip:buddylist1@serviceprovider1.com, collection
> package
> > sip:buddylist2@serviceprovider2.com, collection
> package
> > 
> > the two buddy lists are themselves lists, each of
> which is a URI that 
> > represents a presentity. We could assign a single
> URI to the two MWIs 
> > and two buddy lists -
> sip:mystuff@serviceprovider1.com. The UA would 
> > then do this:
> > 
> > SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0
> > Event: collection
> > Accept: text/collection-info,
> application/cpim-pidf+xml,
> >    application/simple-message-summary
> > 
> > 
> > The server would fan out a subscription to each
> element in the list 
> > within the package for that element, copying the
> Accept 
> > headers from the 
> > collection SUBSCRIBE. The collection server would
> be responsible for 
> > refreshing those fanned out subscriptions, and
> passing the content of 
> > notifications towards the UAC. The collection
> server could be 
> > ignorant 
> > of the detailed operation of any of the packages,
> and could generate 
> > subscriptions for packages it doesnt even
> understand.
> > 
> > If we envision that UAs will frequently have lots
> of long-lived 
> > subscriptions to a number of things, this
> mechanism can save a lot of 
> > overhead for wireless or other access constrained
> devices. It 
> > increases 
> > the administrative burden overall, since each
> collection URI needs to 
> > specify a modereately complex data structure - a
> list of 
> > elements, each 
> > of which is a URI/event pair. But, I think this is
> a 
> > worthwhile tradeoff.
> > 
> > Do people think this is a worthwhile approach?
> > 
> > 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


__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com

From adam@dynamicsoft.com  Mon Sep 16 14:02:50 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01979
	for ; Mon, 16 Sep 2002 14:02:49 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GI2ANo003189
	for ; Mon, 16 Sep 2002 14:02:11 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 16 Sep 2002 13:02:44 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64150@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: Ben Campbell ,
        Jonathan Rosenberg
	 
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Mon, 16 Sep 2002 13:02:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 447
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: 

> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
>
> If I susbscrbe to "collection" 
> without an event scope, I now have to expect NOTIFY requests for 
> arbitrary events.

Unless the proposal is something of an overhaul of event processing
(which I advise against), your NOTIFY messages would be NOTIFY for
the event "collection" under Jonathan's proposal.

I've got to admit, I share Ben and Sean's reservations about this
approach.

/a

From adam@dynamicsoft.com  Mon Sep 16 14:14:37 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02034
	for ; Mon, 16 Sep 2002 14:14:37 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GIE0No003264
	for ; Mon, 16 Sep 2002 14:14:01 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 16 Sep 2002 13:14:37 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64151@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Mon, 16 Sep 2002 13:14:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 2207
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: 

Inline.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>
> The idea here is that a UA could send a single subscribe to a server 
> which would, in turn, fan out subscriptions to each of the 
> events/URIs 
> the user was interested in.

I had imagined that the template approach could do the same thing.

> Heres an example. Lets say a UA is interested in a 
> subscription to two 
> message waiting indicators and two buddy lists:
> 
> sip:mwi1@serviceprovider1.com, mwi package
> sip:mwi2@serviceprovider2.com, mwi package
> sip:buddylist1@serviceprovider1.com, collection package
> sip:buddylist2@serviceprovider2.com, collection package
> 
> the two buddy lists are themselves lists, each of which is a URI that 
> represents a presentity. We could assign a single URI to the two MWIs 
> and two buddy lists - sip:mystuff@serviceprovider1.com. The UA would 
> then do this:
> 
> SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0
> Event: collection
> Accept: text/collection-info, application/cpim-pidf+xml,
>    application/simple-message-summary
> 
> 
> The server would fan out a subscription to each element in the list 
> within the package for that element, copying the Accept 
> headers from the 
> collection SUBSCRIBE. The collection server would be responsible for 
> refreshing those fanned out subscriptions, and passing the content of 
> notifications towards the UAC. The collection server could be 
> ignorant 
> of the detailed operation of any of the packages, and could generate 
> subscriptions for packages it doesnt even understand.

The template approach seems to have the same properties, except for the
heterogeneity of event types. So, for example, you could send the following
two messages:

SUBSCRIBE sip:mymwis@serviceprovider1.com SIP/2.0
Event: mwi.collection
Accept: text/collection-info

SUBSCRIBE sip:mybuddylists@serviceprovider1.com SIP/2.0
Event: presence.collection.collection
Accept: text/collection-info

For both of these, the node processing the collection templates does not
need to know anything about the underlying package (we defined templates
this way on purpose!) and can still operate in a useful fashion.

/a

From adam@dynamicsoft.com  Mon Sep 16 14:26:51 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02091
	for ; Mon, 16 Sep 2002 14:26:51 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GIQENo003320;
	Mon, 16 Sep 2002 14:26:15 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 16 Sep 2002 13:26:51 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64152@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'aki.niemi@nokia.com'" ,
        Jonathan Rosenberg
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Mon, 16 Sep 2002 13:26:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4945
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: 

I appear to have missed the proposal you're referring to, and
I can't find it in the i-d archives.

The way 3265 is defined, if you subscribe to "presence.collection",
you get notifies for "presence.collection". You *never* get
notifies for "presence" because you did not subscribe to "presence".

This is an important property of templates. It allows for generic
implementation of them. For example, you can easily see how
it might be useful to subscribe to "foo.winfo" without even
necessarily knowing the semantics behind the "foo" package.

/a

> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Monday, September 16, 2002 7:52
> To: jdrosen@dynamicsoft.com; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] collection template
> 
> 
> Hi Jonathan,
> 
> It seems that this approach also makes the recursion of 
> presence-list subscriptions easier. I had some doubts about 
> the previous template package based proposal (especially the 
> part about defaulting to presence from presence.collection), 
> because of the fact that one could potentially have both 
> presence *and* presence-collection events in the same SIP URI. 
> 
> So, I like this approach. Let's go for it.
> 
> Cheers,
> Aki
> 
> 
> > -----Original Message-----
> > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Friday, September 13, 2002 12:26 AM
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] collection template
> > 
> > 
> > Folks,
> > 
> > The current version of the old "buddy list" package now defines a 
> > collection template that can allow a user to subscribe to a 
> > list of URIs 
> > for a particular package, such as presence.
> > 
> > It has occurred to me since the meeting that we can take this 
> > one step 
> > farther for a really generally useful tool.
> > 
> > The idea is to make this a collection PACKAGE, not a 
> > template. The URI 
> > that you subscribe to represents a list of URIs, each of 
> which can be 
> > for a different package. The list would also include 
> > information on the 
> > package that URI is associated with.
> > 
> > The idea here is that a UA could send a single subscribe to 
> a server 
> > which would, in turn, fan out subscriptions to each of the 
> > events/URIs 
> > the user was interested in.
> > 
> > Heres an example. Lets say a UA is interested in a 
> > subscription to two 
> > message waiting indicators and two buddy lists:
> > 
> > sip:mwi1@serviceprovider1.com, mwi package
> > sip:mwi2@serviceprovider2.com, mwi package
> > sip:buddylist1@serviceprovider1.com, collection package
> > sip:buddylist2@serviceprovider2.com, collection package
> > 
> > the two buddy lists are themselves lists, each of which is 
> a URI that 
> > represents a presentity. We could assign a single URI to 
> the two MWIs 
> > and two buddy lists - sip:mystuff@serviceprovider1.com. The 
> UA would 
> > then do this:
> > 
> > SUBSCRIBE sip:mystuff@serviceprovider1.com SIP/2.0
> > Event: collection
> > Accept: text/collection-info, application/cpim-pidf+xml,
> >    application/simple-message-summary
> > 
> > 
> > The server would fan out a subscription to each element in the list 
> > within the package for that element, copying the Accept 
> > headers from the 
> > collection SUBSCRIBE. The collection server would be 
> responsible for 
> > refreshing those fanned out subscriptions, and passing the 
> content of 
> > notifications towards the UAC. The collection server could be 
> > ignorant 
> > of the detailed operation of any of the packages, and could 
> generate 
> > subscriptions for packages it doesnt even understand.
> > 
> > If we envision that UAs will frequently have lots of long-lived 
> > subscriptions to a number of things, this mechanism can 
> save a lot of 
> > overhead for wireless or other access constrained devices. It 
> > increases 
> > the administrative burden overall, since each collection 
> URI needs to 
> > specify a modereately complex data structure - a list of 
> > elements, each 
> > of which is a URI/event pair. But, I think this is a 
> > worthwhile tradeoff.
> > 
> > Do people think this is a worthwhile approach?
> > 
> > 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 adam@dynamicsoft.com  Mon Sep 16 14:36:45 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02142
	for ; Mon, 16 Sep 2002 14:36:45 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GIa8No003378;
	Mon, 16 Sep 2002 14:36:08 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 16 Sep 2002 13:36:45 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64153@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Sean Olson'" , aki.niemi@nokia.com,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Mon, 16 Sep 2002 13:36:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1094
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: 

> -----Original Message-----
> From: Sean Olson [mailto:seancolson@yahoo.com]
>  
> At the very least, I would not rely on the Accept
> headers for a pseudo-negotiation. Instead, I would
> turn to an appropriate "filter" for the body of 
> the SUBSCRIBE to create a meta-level of negotiation.
> This is already feeling too complex to me, but we
> should make this as clean a design as possible.

I think Sean's hit on the thing that's bothering me
here: we're overloading the semantics of headers
here. We've made this mistake in the past, and should
now recognize it as such.

I agree that if we're to go down the path of making
this a package, we need to define clean semantics for
this negotiation, and that they need to be separate
from the normal event negotiation.

It appears to me that the cleanest approach will still
be to use the template approach. This allows us to reduce
the number of subscribes to match the number of event
packages supported by the UA. This is still much smaller
than the number of URIs being subscribed to, and appears
to require far less standardization.

/a

From adam@dynamicsoft.com  Mon Sep 16 14:48:47 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02191
	for ; Mon, 16 Sep 2002 14:48:47 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GImANo003462
	for ; Mon, 16 Sep 2002 14:48:11 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 16 Sep 2002 13:48:48 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64154@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template: client vs server
Date: Mon, 16 Sep 2002 13:48:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1082
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: 

While on the topic of the collection package, it has recently
occured to me that there are two useful modes of collection
that we might want to specify.

1) The UA sends a collection SUBSCRIBE to a server. The server
   uses the request URI to look up the list of resources that
   the collection contains.

2) The UA sends a collection SUBSCRIBE to a server. The
   SUBSCRIBE message itself contains sufficient information
   to identify the resources that the collection will
   represent (e.g. as a list of URIs).

Mode 1 is very useful for, for example, requesting a subscription
to the presence of everyone on a network-stored buddy list.

However, there are times when the application will want to
subscribe a collection of events based on some sort of list
that is far more ephemeral than the sort of information stored
in the network -- such as "the list of users in the current
conference call," or "the group of people who are in the same
city as I am right now."

Does the group see enough value in the second mode of operation
that we should make provisions for it?

/a

From pkyzivat@cisco.com  Mon Sep 16 16:16:37 2002
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 QAA02442
	for ; Mon, 16 Sep 2002 16:16:37 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8GKGghf013053;
	Mon, 16 Sep 2002 16:16:42 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAQ93989;
	Mon, 16 Sep 2002 16:21:12 -0400 (EDT)
Message-ID: <3D863C19.7925A42@cisco.com>
Date: Mon, 16 Sep 2002 16:16:25 -0400
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 
CC: "'Sean Olson'" , aki.niemi@nokia.com,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A64153@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1713
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: 


Adam Roach wrote:
> 
> It appears to me that the cleanest approach will still
> be to use the template approach. This allows us to reduce
> the number of subscribes to match the number of event
> packages supported by the UA. This is still much smaller
> than the number of URIs being subscribed to, and appears
> to require far less standardization.

This reduces the number of subscriptions issued by UACs. But it doesn't reduce the number of total subscriptions - it increases it. And it doesn't reduce the number of notifications received by the UAC (well, its actually a UAS for the notify, but you know what I mean.)

It might even increase the number of notifications further - if the collection refreshes its subscription to each member of the collection before it expires, and also refreshes each subscription when the UAC refreshes its subscription to the collection.

This situation could be improved if the collection can be set, via filters or whatever, to normally return only changes.

It could be improved vastly in some cases if many collections have elements in common, and the server is permitted to multiplex one subscription to a collection element across many containing collections. Moreso if the lifetime of the subscriptions the collection server makes are independent of those to the collections it serves.

Of course there is a problem with this. If you and I both subscribe to X, we may get different results based on who we are. If we both subscribe to collection CX, is the data delivered to the collection server on our behalf the same as we would have gotten directly? Or is the data delivered to the collection server by X based on the identity of the collection server?

	Paul

From adam@dynamicsoft.com  Mon Sep 16 19:05:21 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02930
	for ; Mon, 16 Sep 2002 19:05:21 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8GN4fNo005051;
	Mon, 16 Sep 2002 19:04:42 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 16 Sep 2002 18:05:20 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64158@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Paul Kyzivat'" , Adam Roach 
Cc: "'Sean Olson'" , aki.niemi@nokia.com,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Mon, 16 Sep 2002 18:05:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4226
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: 

> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> 
> Adam Roach wrote:
> > 
> > It appears to me that the cleanest approach will still
> > be to use the template approach. This allows us to reduce
> > the number of subscribes to match the number of event
> > packages supported by the UA. This is still much smaller
> > than the number of URIs being subscribed to, and appears
> > to require far less standardization.
> 
> This reduces the number of subscriptions issued by UACs. But 
> it doesn't reduce the number of total subscriptions - it 
> increases it. And it doesn't reduce the number of 
> notifications received by the UAC (well, its actually a UAS 
> for the notify, but you know what I mean.)

This is true for both the collection package and the collection
template-package approach.

This is a known architectural result of the approach being
pursued. If operators don't want to support this, they can
disable whatever collection mechanisms are available on their
servers; this would force the clients to either not subscribe
or to fall back to sending individual subscriptions instead
of subscriptions to collections.

> It might even increase the number of notifications further - 
> if the collection refreshes its subscription to each member 
> of the collection before it expires, and also refreshes each 
> subscription when the UAC refreshes its subscription to the 
> collection.

This is true for both the collection package and the collection
template-package approach.

I would expect reasonable implementations of servers that aggregate
these subscription collections to not pass along information unless
it has actually been updated. This means that if it is using
SUBSCRIBE on the back-end to learn about state, it won't send the
resulting NOTIFY messages to the collection subscriber unless the
NOTIFY actually represented a change in state.

I would NOT expect the server that agregates these subscriptions
to automatically refresh their subscription to the members of
the subscription every time the the UAC refreshes its subscription
to the collection.

> This situation could be improved if the collection can be 
> set, via filters or whatever, to normally return only changes.

This is true for both the collection package and the collection
template-package approach.

I would expect this to be the normal mode of operation, in fact.

What I *would* hope to be able to do via filters is say something
like "when you get a state change, hold off 30 seconds before
sending it to me, in case you get additional changes that you
might be able to send in the same message" or something like that.
 
> It could be improved vastly in some cases if many collections 
> have elements in common, and the server is permitted to 
> multiplex one subscription to a collection element across 
> many containing collections. Moreso if the lifetime of the 
> subscriptions the collection server makes are independent of 
> those to the collections it serves.

This is true for both the collection package and the collection
template-package approach.

> Of course there is a problem with this. If you and I both 
> subscribe to X, we may get different results based on who we 
> are. If we both subscribe to collection CX, is the data 
> delivered to the collection server on our behalf the same as 
> we would have gotten directly? Or is the data delivered to 
> the collection server by X based on the identity of the 
> collection server?

This is true for both the collection package and the collection
template-package approach.

After studying this problem for an extended period of time, I
have reached the conclusion that this sort of aggregation doesn't
generally work. The permissions problems that arise from doing
this are pretty much intractible unless you make some walled-
garden type assumptions about how servers are going to protect
the data they receive in this way.

Was your letter trying to differentiate the package approach from
the template-package approach? That is what context would imply,
but the content doesn't seem to live up to that expectation. Or
were you just trying to raise issues with the idea of subscription
collections regardless of which approach is taken?

/a

From Gonzalo.Camarillo@lmf.ericsson.se  Tue Sep 17 02:32:52 2002
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04084
	for ; Tue, 17 Sep 2002 02:32:51 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8H6WgRb012870;
	Tue, 17 Sep 2002 08:32:46 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.51])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g8H6WgG3023329;
	Tue, 17 Sep 2002 09:32:42 +0300 (EET DST)
Message-ID: <3D86CC89.D1D6FFE8@lmf.ericsson.se>
Date: Tue, 17 Sep 2002 09:32:41 +0300
From: Gonzalo Camarillo 
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Adam Roach 
CC: "'Paul Kyzivat'" ,
        "'Sean Olson'" , aki.niemi@nokia.com,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A64158@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5168
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: 

I believe the collection template-package approach is a cleaner and
simpler solution.

Having a server fan out heterogeneous (i.e., different events)
subscriptions seems to me like streeching too much the concept of a
collention of events.

Let's handle different events with different SUBSCRIBES.

Gonzalo

Adam Roach wrote:
> 
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >
> > Adam Roach wrote:
> > >
> > > It appears to me that the cleanest approach will still
> > > be to use the template approach. This allows us to reduce
> > > the number of subscribes to match the number of event
> > > packages supported by the UA. This is still much smaller
> > > than the number of URIs being subscribed to, and appears
> > > to require far less standardization.
> >
> > This reduces the number of subscriptions issued by UACs. But
> > it doesn't reduce the number of total subscriptions - it
> > increases it. And it doesn't reduce the number of
> > notifications received by the UAC (well, its actually a UAS
> > for the notify, but you know what I mean.)
> 
> This is true for both the collection package and the collection
> template-package approach.
> 
> This is a known architectural result of the approach being
> pursued. If operators don't want to support this, they can
> disable whatever collection mechanisms are available on their
> servers; this would force the clients to either not subscribe
> or to fall back to sending individual subscriptions instead
> of subscriptions to collections.
> 
> > It might even increase the number of notifications further -
> > if the collection refreshes its subscription to each member
> > of the collection before it expires, and also refreshes each
> > subscription when the UAC refreshes its subscription to the
> > collection.
> 
> This is true for both the collection package and the collection
> template-package approach.
> 
> I would expect reasonable implementations of servers that aggregate
> these subscription collections to not pass along information unless
> it has actually been updated. This means that if it is using
> SUBSCRIBE on the back-end to learn about state, it won't send the
> resulting NOTIFY messages to the collection subscriber unless the
> NOTIFY actually represented a change in state.
> 
> I would NOT expect the server that agregates these subscriptions
> to automatically refresh their subscription to the members of
> the subscription every time the the UAC refreshes its subscription
> to the collection.
> 
> > This situation could be improved if the collection can be
> > set, via filters or whatever, to normally return only changes.
> 
> This is true for both the collection package and the collection
> template-package approach.
> 
> I would expect this to be the normal mode of operation, in fact.
> 
> What I *would* hope to be able to do via filters is say something
> like "when you get a state change, hold off 30 seconds before
> sending it to me, in case you get additional changes that you
> might be able to send in the same message" or something like that.
> 
> > It could be improved vastly in some cases if many collections
> > have elements in common, and the server is permitted to
> > multiplex one subscription to a collection element across
> > many containing collections. Moreso if the lifetime of the
> > subscriptions the collection server makes are independent of
> > those to the collections it serves.
> 
> This is true for both the collection package and the collection
> template-package approach.
> 
> > Of course there is a problem with this. If you and I both
> > subscribe to X, we may get different results based on who we
> > are. If we both subscribe to collection CX, is the data
> > delivered to the collection server on our behalf the same as
> > we would have gotten directly? Or is the data delivered to
> > the collection server by X based on the identity of the
> > collection server?
> 
> This is true for both the collection package and the collection
> template-package approach.
> 
> After studying this problem for an extended period of time, I
> have reached the conclusion that this sort of aggregation doesn't
> generally work. The permissions problems that arise from doing
> this are pretty much intractible unless you make some walled-
> garden type assumptions about how servers are going to protect
> the data they receive in this way.
> 
> Was your letter trying to differentiate the package approach from
> the template-package approach? That is what context would imply,
> but the content doesn't seem to live up to that expectation. Or
> were you just trying to raise issues with the idea of subscription
> collections regardless of which approach is taken?
> 
> /a
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

From aki.niemi@nokia.com  Tue Sep 17 02:54:26 2002
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 CAA04170
	for ; Tue, 17 Sep 2002 02:54:25 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8H6sLT18493
	for ; Tue, 17 Sep 2002 09:54:21 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 17 Sep 2002 09:54:09 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 17 Sep 2002 09:54:09 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] collection template
Date: Tue, 17 Sep 2002 09:54:08 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901944FC8@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] collection template
Thread-Index: AcJdrqTQ3BxmWQmmRGqyXer4Ua2CeAAZwHQg
To: , ,
        
X-OriginalArrivalTime: 17 Sep 2002 06:54:09.0389 (UTC) FILETIME=[05C599D0:01C25E17]
Content-Length: 1099
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id CAA04170
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: 

Hi Adam,

> I appear to have missed the proposal you're referring to, and
> I can't find it in the i-d archives.

Yes, it's not in the draft, but the issue was discussed in Yokohama. 

> The way 3265 is defined, if you subscribe to "presence.collection",
> you get notifies for "presence.collection". You *never* get
> notifies for "presence" because you did not subscribe to "presence".

The issue was with recursing of presence.collection subscriptions, i.e., if a URI in the buddy-list was itself a list of URIs, you could potentially recurse the subscription until it reached the "leaf" and defaulted to the presence event of that URI.

However, the above looks like something destined not to work. Now I forget the other option that was presented as possible solution for this recursing problem...
 
> This is an important property of templates. It allows for generic
> implementation of them. For example, you can easily see how
> it might be useful to subscribe to "foo.winfo" without even
> necessarily knowing the semantics behind the "foo" package.

Yes, this is very clear.
 
Cheers,
Aki

From jdrosen@dynamicsoft.com  Tue Sep 17 04:27:03 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04531
	for ; Tue, 17 Sep 2002 04:27:03 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8H8R4YH024723;
	Tue, 17 Sep 2002 04:27:04 -0400 (EDT)
Message-ID: <3D86E757.4060208@dynamicsoft.com>
Date: Tue, 17 Sep 2002 04:27:03 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Adam Roach 
CC: "'Sean Olson'" , aki.niemi@nokia.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A64153@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3670
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: 


Adam Roach wrote:
 >> -----Original Message----- From: Sean Olson
 >> [mailto:seancolson@yahoo.com]
 >>
 >> At the very least, I would not rely on the Accept headers for a
 >> pseudo-negotiation. Instead, I would turn to an appropriate
 >> "filter" for the body of the SUBSCRIBE to create a meta-level of
 >> negotiation. This is already feeling too complex to me, but we
 >> should make this as clean a design as possible.
 >
 >
 > I think Sean's hit on the thing that's bothering me here: we're
 > overloading the semantics of headers here. We've made this mistake in
 > the past, and should now recognize it as such.

I agree that we should not overload these things.

I am really trying to flesh this idea out some more to see how much 
merit it does or doesn't have. It does have a clear benefit in reducing 
client to server traffic, as the only one advantage over the template 
approach.

The right way to think about the collection package is to forget about 
fanout. The fanout of subscriptions represents one, but not the only, 
way in which the server can find out about the state of the thing thats 
being subscribed to. In this case, the thing is a list of resources, 
which is itself a resource, called a collection. What differentiates a 
collection as a resource from other resources is that its state is 
described by a variety of different document formats, rather than a 
small number that is bound to the package itself. Event package 
negotiation is per the spec; this resource could potentially support a 
variety of event packages beyond the collection package.

Now, like any other resource, if you SUBSCRIBE to it, but don't list a 
document format in the Accept header thats needed to understand events 
generated by that resource, the subscription fails. Same here. If I list 
a set of document formats in my SUBSCRIBE that doesn't cover the full 
set of formats I need to understand events generated by that resource, 
the subscription fails. How the server determines whether that list is 
correct, is its own choice. It could copy the Accept header into 
fanned-out subscriptions as I suggested. Or, it could know the types for 
each package and reject the subscription outright if it finds one missing.

So, in this way of thinking about a collection package, there is no such 
thing as negotiating packages for the fanned out subscriptions between 
the the UAC and the actual notifiers. Each leg negotiates its packages 
independently.

A collection does appear to represent a well-defined package. It would 
define its own default subscription duration. It has a well-defined 
treatment for forked requests (not allowed). It would have its own 
notification rates; the entire point of the package is to buffer 
package-specific notification rates and have one independent one. State 
agents would make no sense in this package.

Filters would allow you to specify what aspect of the resource you do or 
don't want to know about; this would provide the mechanism, for example, 
to request more frequent presence updates and less frequent MWI updates.

So, I think its a reasonable package definition. However, there is no 
doubt that its somewhat of a hack. I would welcome thoughts on other 
specific problems that arise with it, to determine if it makes sense or not.

-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


From nsyracus@cnri.reston.va.us  Tue Sep 17 08:02:17 2002
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 IAA05127
	for ; Tue, 17 Sep 2002 08:02:15 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11334;
	Tue, 17 Sep 2002 08:00:31 -0400 (EDT)
Message-Id: <200209171200.IAA11334@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 17 Sep 2002 08:00:31 -0400
Content-Length: 3311
Subject: [Simple] I-D ACTION:draft-ietf-sip-message-07.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-sip-message-07.txt
	Pages		: 22
	Date		: 2002-9-16
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-message-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-message-07.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:	<2002-9-16152033.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-message-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-sip-message-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-9-16152033.I-D@ietf.org>

--OtherAccess--

--NextPart--



From pkyzivat@cisco.com  Tue Sep 17 09:33:00 2002
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 JAA05421
	for ; Tue, 17 Sep 2002 09:33:00 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HDX5fW008097;
	Tue, 17 Sep 2002 09:33:06 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAQ97827;
	Tue, 17 Sep 2002 09:37:37 -0400 (EDT)
Message-ID: <3D872F01.1E3CF514@cisco.com>
Date: Tue, 17 Sep 2002 09:32:49 -0400
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 
CC: "'Sean Olson'" , aki.niemi@nokia.com,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A64158@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1933
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: 

below...

	Paul

Adam Roach wrote:
> 
> Was your letter trying to differentiate the package approach from
> the template-package approach? That is what context would imply,
> but the content doesn't seem to live up to that expectation. Or
> were you just trying to raise issues with the idea of subscription
> collections regardless of which approach is taken?

The latter.

> > It could be improved vastly in some cases if many collections
> > have elements in common, and the server is permitted to
> > multiplex one subscription to a collection element across
> > many containing collections. Moreso if the lifetime of the
> > subscriptions the collection server makes are independent of
> > those to the collections it serves.
> 
> This is true for both the collection package and the collection
> template-package approach.
> 
> After studying this problem for an extended period of time, I
> have reached the conclusion that this sort of aggregation doesn't
> generally work. The permissions problems that arise from doing
> this are pretty much intractible unless you make some walled-
> garden type assumptions about how servers are going to protect
> the data they receive in this way.

I'm inclined to agree, but I keep looking for a way to make it work, because otherwise there are significant scaling problems with highly interconnected collections of users - its something like O(n^2).

There is a permissions problem even if you don't aggregate this way. In order for the permissions to be evaluated in a straightforward way, the server for a collection will need to represent itself as the user who subscribed to the collection, or as an agent that has been explicitly authorized to act on behalf of that user. I don't see an obvious way to do that other than for each user to provide the collection server with one of his secret keys, or else to have the end user sign a certificate for the collection server.

	Paul

From pkyzivat@cisco.com  Tue Sep 17 10:06:48 2002
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 KAA05541
	for ; Tue, 17 Sep 2002 10:06:48 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HE6s38014850;
	Tue, 17 Sep 2002 10:06:55 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAQ98277;
	Tue, 17 Sep 2002 10:11:26 -0400 (EDT)
Message-ID: <3D8736EE.B4FA33FE@cisco.com>
Date: Tue, 17 Sep 2002 10:06:38 -0400
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: Adam Roach , "'Sean Olson'" ,
        aki.niemi@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A64153@DYN-TX-EXCH-001.dynamicsoft.com> <3D86E757.4060208@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1379
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: 

Jonathan Rosenberg wrote:
> 
> A collection does appear to represent a well-defined package. It would
> define its own default subscription duration. It has a well-defined
> treatment for forked requests (not allowed). It would have its own
> notification rates; the entire point of the package is to buffer
> package-specific notification rates and have one independent one. State
> agents would make no sense in this package.

There is one way that it is not like a well-defined package:

With a normal event package, when you send a subscription you get back an initial notification that is supposed to represent the full state of the subscribed resource, and if your subscription is a poll (Expires:0), then you expect to get only the one notification.

With the collection package as I think you are proposing it (or even the collection template) this isn't really the case. The initial subscription might result in a bunch of notifications, each carrying part of the state of the collection as a whole.

This could be fixed in various ways:

- the collection server could buffer the responses from all the members of the collection and return everything in a single multipart response.

- we could change rfc 3265 so that the first notify in response to a subscribe isn't necessarily obligated to report the full current resource state.

- (are there other ways???)

	Paul

From pkyzivat@cisco.com  Tue Sep 17 10:24:18 2002
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 KAA05615
	for ; Tue, 17 Sep 2002 10:24:18 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HEOT7l018811
	for ; Tue, 17 Sep 2002 10:24:29 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAQ98540;
	Tue, 17 Sep 2002 10:29:00 -0400 (EDT)
Message-ID: <3D873B0C.48F6DD00@cisco.com>
Date: Tue, 17 Sep 2002 10:24:12 -0400
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
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] I-D ACTION:draft-ietf-sip-message-07.txt
References: <200209171200.IAA11334@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 398
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: 

From Section 13.1 (Changes introduced in draft-ietf-sip-message-07):

   Prohibition against creating dialogs primarily to carry MESSAGE
   requests reduced to SHOULD strength.

Why was this change made? This seems to be opening a can of worms. After lengthly discussion about IM sessions, it seems that IM sessions using SIP as a transport won't create a dialog for conveying the MESSAGEs.

	Paul

From Markus.Isomaki@nokia.com  Tue Sep 17 10:33:58 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05668
	for ; Tue, 17 Sep 2002 10:33:58 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8HEYGZ28177
	for ; Tue, 17 Sep 2002 17:34:16 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 17 Sep 2002 17:33:57 +0300
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 17 Sep 2002 17:33:56 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 17 Sep 2002 17:33:56 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] some additions to the authorization requirements
Date: Tue, 17 Sep 2002 17:33:55 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] some additions to the authorization requirements
Thread-Index: AcJaoU01necLEIpxQSCxMhXqHY9FSQDshkEQ
To: , 
X-OriginalArrivalTime: 17 Sep 2002 14:33:56.0237 (UTC) FILETIME=[40D08BD0:01C25E57]
Content-Length: 3571
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA05668
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: 

Hi,

I think the concrete authorization requirements also depend on the structure of the content being authorized.

In my opinion it should be possible to decide which tuples the subscriber would be allowed to receive. (For example I don't want to show everybody that I'm right now available for voice calls.) The differentiation would need to happen based on contact address and in addition based on COMMUNICATION MEANS. As the SIMPLE PIDF profile is not yet defined, it is a bit difficult to give the exact wording but I would suggest something like this:

* the user should be able to specify that the subscriber will only receive notifications containing a combination of a specific contact address and a specific related communication mean. (i.e. only instant messaging but not voice related information.)

Regarding filtering, I think the end result that is delivered to the subscriber should be the combination of subscriber filter and the authorization decision. I'm not sure if accept/reject type of decision is needed for the filter at all, but the  authorization could just set further filters/restrictions.

Regards,
	Markus

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 13 September, 2002 0:11
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] some additions to the authorization requirements
> 
> 
> Folks,
> 
> I'd like to seriously beef up the authorization requirements 
> section of 
> http://www.ietf.org/internet-drafts/draft-rosenberg-simple-dat
> a-req-00.txt 
> to discuss a lot more of the specifics we want to accomplish.
> 
> The key thing is details on the level of permissions that are being 
> granted by the presentity. Some additional requirements to consider:
> 
> * the user should be able to specify that the subscriber will only 
> receive notifications containing a specific contact address 
> (i.e., only 
> my work phone)
> 
> * the user should be able to specify that the subscriber will only 
> receive notifications containing a specific status type (basic, for 
> example, which is the only status type defined so far).
> 
> * the user should be able to specify that the subscriber will only 
> receive notifications containing specific values of a specific status 
> type (for example, only report when my status goes to OPEN, 
> not CLOSED)
> 
> * the user should be able to specify that the subscriber will or will 
> not receive a contact address in the notifications.
> 
> 
> Effectively, the above rules all specify filters or triggers on the 
> presence documents that should be sent to a particular presentity.
> 
> We could specify rate-based filters (i.e., specify that a subscriber 
> cannot receive documents more frequently than X per minute), but this 
> doesn't seem awfully useful.
> 
> 
> Related to that, if the SUBSCRIBE contained a filter of some 
> sort, the 
> authorization should allow the user to approve or reject 
> their filter, 
> and possibly impose further filtering as above.
> 
> 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 laurent.schweizer@eivd.ch  Tue Sep 17 11:36:09 2002
Received: from smtp-relay (mail1.eivd.ch [193.134.216.148])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05900
	for ; Tue, 17 Sep 2002 11:36:08 -0400 (EDT)
Received: from edupc043 ([10.192.73.43])
	by smtp-relay (1.0/YCOM SA SMTPGateway 1.31) with SMTP id g8HFa4k0017813
	for ; Tue, 17 Sep 2002 17:36:05 +0200
Reply-To: 
From: "Schweizer" 
To: 
Date: Tue, 17 Sep 2002 17:39:58 +0200
Message-ID: <000601c25e60$7ae5ff40$2b49c00a@edupc043>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0007_01C25E71.3E711930"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MS-TNEF-Correlator: 000000000B71C6C953B3F04CA29F422101B1C5AD644E6A00
Importance: Normal
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Content-Length: 2706
Subject: [Simple] state of user in cpim ?
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C25E71.3E711930
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hello,

How can i indicate in CPIM the state of a user ? 

I see in the example 4.3.1 ( CPIM draft 05 ) in the "status" element 
 busy , but this element "im" is not from this draft. 

Schweizer Laurent



------=_NextPart_000_0007_01C25E71.3E711930
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+IjsPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHCQARABEAJwAAAAIALQEB
A5AGAIQFAAAmAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAGAAAAHN0YXRlIG9mIHVzZXIgaW4gY3BpbSA/AAIBcQABAAAAFgAAAAHCXmB6SEjo+6ixhUCl
p0whisX1MUAAAAIBHQwBAAAAHwAAAFNNVFA6TEFVUkVOVC5TQ0hXRUlaRVJARUlWRC5DSAAACwAB
DgAAAABAAAYOAIKjV2BewgECAQoOAQAAABgAAAAAAAAAC3HGyVOz8Eyin0IhAbHFrcKAAAADABQO
AQAAAAsAHw4BAAAAAgEJEAEAAAAhAQAAHQEAAIABAABMWkZ1drXi/gMACgByY3BnMTI1FjIA+Atg
bg4QMDMzTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0DGAOYwBQCwMLtSBIZWyd
CQAsCqIKhAqASG8H4DpjA5FpFWASgA3gYXQCZRWBIENQSU0gNHRoFgBzAZAV8W9msCBhIHURIAXA
PwrjPRR2SRbQCeAWEhaiZXgMYW0LUBYANC4zLogxICgWRGRyYQGAoCAwNSApGRYiFuJ9F5AiGYAZ
4AeAAjAX9TxFB3A6B3A+IGIXkHnoIDwvHYQsHeEFQBagOwQAHIciB3AccB9Bbm+vBUADUh8UGuMu
F/tTEOCQd2VpehexTGEIcC8c0RQ6FDQR4QAk8AAAAAMACVkDAAAACwAAgAggBgAAAAAAwAAAAAAA
AEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMAB4AIIAYAAAAA
AMAAAAAAAABGAAAAAFKFAAAnagEAHgAJgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAA
OS4wAB4ACoAIIAYAAAAAAMAAAAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAAuACCAGAAAAAADA
AAAAAAAARgAAAAA3hQAAAQAAAAEAAAAAAAAAHgAMgAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEA
AAABAAAAAAAAAAsAEYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwASgAggBgAAAAAAwAAA
AAAAAEYAAAAAAYUAAAAAAAALABuACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAHIAIIAYA
AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAegAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAC
AfgPAQAAABAAAAALccbJU7PwTKKfQiEBscWtAgH6DwEAAAAQAAAAC3HGyVOz8Eyin0IhAbHFrQIB
+w8BAAAAmwAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoA
N9luAAAAQzpcRG9jdW1lbnRzIGFuZCBTZXR0aW5nc1xBZG1pbmlzdHJhdG9yXExvY2FsIFNldHRp
bmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcbWFpbGJveC5wc3QAAAMA/g8F
AAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDBCNzFDNkM5NTNCM0YwNENBMjlGNDIyMTAx
QjFDNUFENjQ0RTZBMDAAAAAAAwAGEMPz8S4DAAcQpQAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAA
AGUAAABIRUxMTyxIT1dDQU5JSU5ESUNBVEVJTkNQSU1USEVTVEFURU9GQVVTRVI/SVNFRUlOVEhF
RVhBTVBMRTQzMShDUElNRFJBRlQwNSlJTlRIRSJTVEFUVVMiRUxFTUVOVDxJTTpJAAAAAKkY

------=_NextPart_000_0007_01C25E71.3E711930--


From EXT-Hemish.Parikh@nokia.com  Tue Sep 17 11:46:07 2002
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05985
	for ; Tue, 17 Sep 2002 11:46:05 -0400 (EDT)
From: EXT-Hemish.Parikh@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8HFkTM07195
	for ; Tue, 17 Sep 2002 10:46:29 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Tue, 17 Sep 2002 10:46:02 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 17 Sep 2002 10:45:11 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 17 Sep 2002 11:45:10 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Index: AcJeYTR0ykVEW/UIRLqhM6Mbq+l0VA==
To: 
X-OriginalArrivalTime: 17 Sep 2002 15:45:11.0400 (UTC) FILETIME=[3502A680:01C25E61]
Content-Length: 443
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA05985
Subject: [Simple] (no subject)
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: 

Hi

I have a scenario here as described: SIP is being used in Tunneling mode for Instant messaging in a 3G system. As I understand form TS24.229 of 3GPP, SGSN/GGSN acting as SIP proxies change the outer header fields like 'Content Type'. If yes then, now the outer header fields are different from the inner header fields. How the receiving UAS deal with this.

Appreciate suggestions.

Hemish Parikh
Nokia Research Center
Tel: 781-993 5752 


From adam@dynamicsoft.com  Tue Sep 17 11:58:32 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06059
	for ; Tue, 17 Sep 2002 11:58:32 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8HFvoNo008496;
	Tue, 17 Sep 2002 11:57:50 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 17 Sep 2002 10:58:27 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64160@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Paul Kyzivat'" , Adam Roach 
Cc: "'Sean Olson'" , aki.niemi@nokia.com,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Tue, 17 Sep 2002 10:58:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 5130
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: 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> 
> > > It could be improved vastly in some cases if many collections
> > > have elements in common, and the server is permitted to
> > > multiplex one subscription to a collection element across
> > > many containing collections. Moreso if the lifetime of the
> > > subscriptions the collection server makes are independent of
> > > those to the collections it serves.
> > 
> > After studying this problem for an extended period of time, I
> > have reached the conclusion that this sort of aggregation doesn't
> > generally work. The permissions problems that arise from doing
> > this are pretty much intractible unless you make some walled-
> > garden type assumptions about how servers are going to protect
> > the data they receive in this way.
> 
> I'm inclined to agree, but I keep looking for a way to make 
> it work, because otherwise there are significant scaling 
> problems with highly interconnected collections of users - 
> its something like O(n^2).

That's true. It's a general truth that comes with any model of
presence that allows users to set policy that is different
for different sets of watchers, regardless of whether you
use collections. Let's consider a system of two servers,
each of which has three clients. Each client has a subscription
to all five other clients.

With collections, the number of subscriptions between each
node is as follows:

        +----+        18        +----+
        | S1 |------------------| S2 |
        +----+                  +----+
     2 / 2|  2\               2/ 2|  2\
      /   |    \              /   |    \
+----+  +----+  +----+  +----+  +----+  +----+
| C1 |  | C2 |  | C3 |  | C4 |  | C5 |  | C6 |
+----+  +----+  +----+  +----+  +----+  +----+

Each client has a collection subscription to its server; each
server has either a non-collection subscription to each of its
clients or a publication relationship. I'm going to consider them
to be about as heavy as each other. I'm making an assumption that
clients trust their own server to honor their privacy policies,
instead of implementing all privacy at the peer level.

Given these assumptions, we have a total of 30 subscriptions
in the system. It should also be obvious, as you state, that
the number of subscriptions in the system increases at the rate
of about O(n^2).

Now, let's look at the same system without collection subscriptions.
(Sorry; the limitations of ASCII art show up here).

                 ----------------------
                /3                     \
               /        +----+  +----+  +----+
              /  -------| C4 |  | C5 |  | C6 |
             /  /3      +----+  +----+  +----+
            /  /             3\/ 3|   3/
           /  /            3  /\  |   /
        +----+----------------  +----+
        | S1 |   ---------------| S2 |
        +----+  /3      --------+----+
      3/ 3|  3\/       /3      /
      /   |   /\      /       /
+----+  +----+  +----+       /
| C1 |  | C2 |  | C3 |      /
+----+  +----+  +----+     /
      \                  3/
       -------------------

Here, each client has two subscriptions to its local server
(one for each other client attached to that server), and the
server has either a subscription to or a publication relationship
with each of its clients. Each client additionally has three
subscriptions to the remote server (one for each of its clients),
leading to 18 interdomain subscriptions (exactly like before).
In total, then, this system -- the one without collections --
has 36 total subscriptions. It should also be obvious that this
system will increase the total number of subscriptions at the
rate of approximately O(n^2).

So, yes, you've hit on the fundamental scaling problem inherent
in presence systems. Collections neither worsen nor significantly
improve this. What collections *do* accomplish is reduction of
the traffic from the client to the server. If you go through
the excercise of increasing the size of the systems I've diagrammed
above, you'll notice that the system with collections keeps the
relationship between the client and the server(s) to 2
subscriptions (or one subscription and one publication relationship),
while the system without collections increases this realationship
linearly as you add users.

> There is a permissions problem even if you don't aggregate 
> this way. In order for the permissions to be evaluated in a 
> straightforward way, the server for a collection will need to 
> represent itself as the user who subscribed to the 
> collection, or as an agent that has been explicitly 
> authorized to act on behalf of that user. I don't see an 
> obvious way to do that other than for each user to provide 
> the collection server with one of his secret keys, or else to 
> have the end user sign a certificate for the collection server.

Now this *is* an interesting problem. If this problem is
tractible (and it feels like it should be), then we're home
free. I'll leave it to the security guys to comment on whether
this sort of limited delegation is something that's feasible.

/a

From pkyzivat@cisco.com  Tue Sep 17 14:29:54 2002
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 OAA06583
	for ; Tue, 17 Sep 2002 14:29:54 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8HITffJ010631;
	Tue, 17 Sep 2002 14:29:43 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAR01391;
	Tue, 17 Sep 2002 14:33:55 -0400 (EDT)
Message-ID: <3D877473.FD1779B5@cisco.com>
Date: Tue, 17 Sep 2002 14:29:07 -0400
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 
CC: "'Sean Olson'" , aki.niemi@nokia.com,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A64160@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5240
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: 

Adam,

Nice ascii art! (It's too much work, so I avoid it when I can.)

I've extracted portions of your message and commented on them below.

	Paul

Adam Roach wrote:
> 
> > There is a permissions problem even if you don't aggregate
> > this way. In order for the permissions to be evaluated in a
> > straightforward way, the server for a collection will need to
> > represent itself as the user who subscribed to the
> > collection, or as an agent that has been explicitly
> > authorized to act on behalf of that user. I don't see an
> > obvious way to do that other than for each user to provide
> > the collection server with one of his secret keys, or else to
> > have the end user sign a certificate for the collection server.
> 
> Now this *is* an interesting problem. If this problem is
> tractible (and it feels like it should be), then we're home
> free. I'll leave it to the security guys to comment on whether
> this sort of limited delegation is something that's feasible.

I think you partially misunderstood me, or else I misunderstand you. I think there is a problem getting the setup from your first picture to work at all.

> Let's consider a system of two servers,
> each of which has three clients. Each client has a subscription
> to all five other clients.
> 
> With collections, the number of subscriptions between each
> node is as follows:
> 
>         +----+        18        +----+
>         | S1 |------------------| S2 |
>         +----+                  +----+
>      2 / 2|  2\               2/ 2|  2\
>       /   |    \              /   |    \
> +----+  +----+  +----+  +----+  +----+  +----+
> | C1 |  | C2 |  | C3 |  | C4 |  | C5 |  | C6 |
> +----+  +----+  +----+  +----+  +----+  +----+

If I understand your intent, S1 is both a presence server for C1..C3 and a server for the collections that C1..C3 use, and similarly for S2 and C4..C6.

So lets pick one case out of this. C1 has a subscription to a collection hosted by S1 that references the presence of C2...C6. To honor this one of the things S1 does is make a subscription to S2 regarding C4.

Now S2 is acting on behalf of C4 in this case, and needs to identify who the subscriber is in order to decide whether to accept it and what information to divulge. S1, acting on behalf of C1, needs to identify who is making the request, presumably using the From header and some credentials.

So, what does S1 put in the From header, and what credentials does it use? 

For the From header there are two obvious possibilities: the URI of C1 or the URI of S1. The credentials could be unique to C1, or might only identify S1. There are then four possible combinations of these:

	From	Credentials
	----	-----------
1)	C1	C1
2)	C1	S1
3)	S1	C1
4)	S1	S1

At least one of the two needs to identify C1, so the proper access decision can be made, which excludes (4).

Case (2) is appealing because it doesn't require S1 to hold separate credentials for every client it serves. But it is pretty dicey too because it is difficult for S2 to know whether to accept it as a valid credential for C1.

For either (1) or (3) S1 must hold credentials and the corresponding secret for each client serves. (This starts to get into the area that John Ramsdell has been concerned with.) If C1 is going to let S1 have such credentials, there probably must be limitations on them. C1 isn't going to want to let S1 do anything and everything on its behalf. It is going to want to restrict S1 to doing certain things - in this case simply subscribing to presence, possibly with further restrictions.

Then of course S1 must obtain the credential it uses to act on behalf of C1 somewhow, and S2 must know how to recognize such a credential and decide whether to honor it. This all adds complexity to the use of collections. (Whether they are templates or not.)

Do you see a reasonable way to approach this problem of credentials? 

An alternative is to simple have collection servers act on their own behalf. The server could use its own identity to subscribe to the members of a collection, and could make its own decisions about who to accept collection subscriptions from. Done this way, the members of all the collections it serves can be pooled, with a single subscription to each regardless of how many clients it serves. The major limitation of this approach is that all clients of the same collection server don't have their own identity exposed to and taken into account by the specific collection members. The main advantages are a simplification in the security model and possibly a large reduction in the total number of subscriptions and notifications in the system.

Clearly this model wouldn't work for all applications. But it might work in some important cases. Whether these cases are important enough to pursue is questionable.

Repeating your comment:

> Now this *is* an interesting problem. If this problem is
> tractible (and it feels like it should be), then we're home
> free. I'll leave it to the security guys to comment on whether
> this sort of limited delegation is something that's feasible.

I'd like to hear from them too, because I am pretty naive about security.

But I don't see what your plan of attack is if this *isn't* tractible.

	Paul

From bcampbell@dynamicsoft.com  Tue Sep 17 14:38:35 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06632
	for ; Tue, 17 Sep 2002 14:38:35 -0400 (EDT)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g8HIcEpA058813;
	Tue, 17 Sep 2002 13:38:15 -0500 (CDT)
Message-ID: <3D877652.2050601@dynamicsoft.com>
Date: Tue, 17 Sep 2002 13:37:06 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] I-D ACTION:draft-ietf-sip-message-07.txt
References: <200209171200.IAA11334@ietf.org> <3D873B0C.48F6DD00@cisco.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 616
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: 

Paul Kyzivat wrote:
>>From Section 13.1 (Changes introduced in draft-ietf-sip-message-07):
> 
>    Prohibition against creating dialogs primarily to carry MESSAGE
>    requests reduced to SHOULD strength.
> 
> Why was this change made? This seems to be opening a can of worms. After lengthly discussion about IM sessions, it seems that IM sessions using SIP as a transport won't create a dialog for conveying the MESSAGEs.
> 

Well, it still says you SHOULD NOT do it. People brought up possible 
legitimate applications of the concept for some very specific 
circumstances. Changing the language was a compromise.


From hisham.khartabil@nokia.com  Wed Sep 18 03:14:46 2002
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 DAA08789
	for ; Wed, 18 Sep 2002 03:14:45 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8I7EeT04751
	for ; Wed, 18 Sep 2002 10:14:40 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 18 Sep 2002 10:12:19 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 18 Sep 2002 10:12:19 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] collection template
Date: Wed, 18 Sep 2002 10:12:18 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C20640@esebe019.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] collection template
Thread-Index: AcJeZGAiWDnZxfQ8Tz2OEUXDdece0QAee5OQ
To: , 
Cc: , , ,
        
X-OriginalArrivalTime: 18 Sep 2002 07:12:19.0587 (UTC) FILETIME=[B9FE5D30:01C25EE2]
Content-Length: 6853
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA08789
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: 

You left out one scenario (the one we should really be comparing to collection as a package), which is the one that uses collection as a template. It very much looks like your first diagram, if its for one type of package like presence. The numbers increase slightly if there is more than one base package that need to use the collection template.

Besides the security issues and who authenticates/authorises who, there is the issue of filtering. Each package like presence, mwi, winfo or whatever might have its own filtering that needs to be apply. A collection package does not help is this situation.

Subscription duration: What is the behaviour when a SUBSCRIBE for collection package is used and the fanned out subsriptions resulted in lower expiration intervals than the interval sent in the original SUBSCRIBE to the collection package? This is probably a case for both types of collection packages, but I see much more complicated when the subscription is for 2 or more different types of services.

Regards,
Hisham 

> -----Original Message-----
> From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Tuesday, September 17, 2002 6:58 PM
> To: 'Paul Kyzivat'; Adam Roach
> Cc: 'Sean Olson'; Niemi Aki (NET/Espoo); Jonathan Rosenberg;
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] collection template
> 
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > 
> > > > It could be improved vastly in some cases if many collections
> > > > have elements in common, and the server is permitted to
> > > > multiplex one subscription to a collection element across
> > > > many containing collections. Moreso if the lifetime of the
> > > > subscriptions the collection server makes are independent of
> > > > those to the collections it serves.
> > > 
> > > After studying this problem for an extended period of time, I
> > > have reached the conclusion that this sort of aggregation doesn't
> > > generally work. The permissions problems that arise from doing
> > > this are pretty much intractible unless you make some walled-
> > > garden type assumptions about how servers are going to protect
> > > the data they receive in this way.
> > 
> > I'm inclined to agree, but I keep looking for a way to make 
> > it work, because otherwise there are significant scaling 
> > problems with highly interconnected collections of users - 
> > its something like O(n^2).
> 
> That's true. It's a general truth that comes with any model of
> presence that allows users to set policy that is different
> for different sets of watchers, regardless of whether you
> use collections. Let's consider a system of two servers,
> each of which has three clients. Each client has a subscription
> to all five other clients.
> 
> With collections, the number of subscriptions between each
> node is as follows:
> 
>         +----+        18        +----+
>         | S1 |------------------| S2 |
>         +----+                  +----+
>      2 / 2|  2\               2/ 2|  2\
>       /   |    \              /   |    \
> +----+  +----+  +----+  +----+  +----+  +----+
> | C1 |  | C2 |  | C3 |  | C4 |  | C5 |  | C6 |
> +----+  +----+  +----+  +----+  +----+  +----+
> 
> Each client has a collection subscription to its server; each
> server has either a non-collection subscription to each of its
> clients or a publication relationship. I'm going to consider them
> to be about as heavy as each other. I'm making an assumption that
> clients trust their own server to honor their privacy policies,
> instead of implementing all privacy at the peer level.
> 
> Given these assumptions, we have a total of 30 subscriptions
> in the system. It should also be obvious, as you state, that
> the number of subscriptions in the system increases at the rate
> of about O(n^2).
> 
> Now, let's look at the same system without collection subscriptions.
> (Sorry; the limitations of ASCII art show up here).
> 
>                  ----------------------
>                 /3                     \
>                /        +----+  +----+  +----+
>               /  -------| C4 |  | C5 |  | C6 |
>              /  /3      +----+  +----+  +----+
>             /  /             3\/ 3|   3/
>            /  /            3  /\  |   /
>         +----+----------------  +----+
>         | S1 |   ---------------| S2 |
>         +----+  /3      --------+----+
>       3/ 3|  3\/       /3      /
>       /   |   /\      /       /
> +----+  +----+  +----+       /
> | C1 |  | C2 |  | C3 |      /
> +----+  +----+  +----+     /
>       \                  3/
>        -------------------
> 
> Here, each client has two subscriptions to its local server
> (one for each other client attached to that server), and the
> server has either a subscription to or a publication relationship
> with each of its clients. Each client additionally has three
> subscriptions to the remote server (one for each of its clients),
> leading to 18 interdomain subscriptions (exactly like before).
> In total, then, this system -- the one without collections --
> has 36 total subscriptions. It should also be obvious that this
> system will increase the total number of subscriptions at the
> rate of approximately O(n^2).
> 
> So, yes, you've hit on the fundamental scaling problem inherent
> in presence systems. Collections neither worsen nor significantly
> improve this. What collections *do* accomplish is reduction of
> the traffic from the client to the server. If you go through
> the excercise of increasing the size of the systems I've diagrammed
> above, you'll notice that the system with collections keeps the
> relationship between the client and the server(s) to 2
> subscriptions (or one subscription and one publication relationship),
> while the system without collections increases this realationship
> linearly as you add users.
> 
> > There is a permissions problem even if you don't aggregate 
> > this way. In order for the permissions to be evaluated in a 
> > straightforward way, the server for a collection will need to 
> > represent itself as the user who subscribed to the 
> > collection, or as an agent that has been explicitly 
> > authorized to act on behalf of that user. I don't see an 
> > obvious way to do that other than for each user to provide 
> > the collection server with one of his secret keys, or else to 
> > have the end user sign a certificate for the collection server.
> 
> Now this *is* an interesting problem. If this problem is
> tractible (and it feels like it should be), then we're home
> free. I'll leave it to the security guys to comment on whether
> this sort of limited delegation is something that's feasible.
> 
> /a
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From tsearle@indigosw.com  Wed Sep 18 06:23:10 2002
Received: from m3102.hostcentric.net (m3102.hostcentric.net [216.157.79.140])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id GAA09362
	for ; Wed, 18 Sep 2002 06:23:10 -0400 (EDT)
Received: (qmail 7838 invoked by alias); 18 Sep 2002 10:23:11 -0000
Received: from unknown (HELO m3001.hostcentric.net) (216.157.79.237)
  by 0 with SMTP; 18 Sep 2002 10:23:11 -0000
Received: (qmail 27901 invoked by alias); 18 Sep 2002 10:23:11 -0000
Received: from unknown (HELO indigosw.com) (217.136.220.14)
  by 0 with SMTP; 18 Sep 2002 10:23:11 -0000
Message-ID: <3D8853BD.2080604@indigosw.com>
Date: Wed, 18 Sep 2002 12:21:49 +0200
From: Torrey Searle 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.0) Gecko/20020529
X-Accept-Language: en-us
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 365
Subject: [Simple] collection template
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: 

For the inital subscribe to a Template, would it be possible to just 
send the list of people in the collection w/o the actuall state?  IE a 
presence-list of presence elements w/o tuples.  It would seem like an 
appropriate time to get the "collection list" from the server, w/o 
having to guess it from subsquent partial notifies.

Torrey Searle
Indigo Software


From EXT-Hemish.Parikh@nokia.com  Wed Sep 18 13:47:38 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10628
	for ; Wed, 18 Sep 2002 13:47:37 -0400 (EDT)
From: EXT-Hemish.Parikh@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8IHlvZ10568
	for ; Wed, 18 Sep 2002 20:47:58 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Wed, 18 Sep 2002 20:47:35 +0300
Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 18 Sep 2002 20:47:35 +0300
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 18 Sep 2002 12:47:33 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 18 Sep 2002 13:47:32 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Index: AcJeYTR0ykVEW/UIRLqhM6Mbq+l0VAA2c8Nw
To: 
X-OriginalArrivalTime: 18 Sep 2002 17:47:33.0418 (UTC) FILETIME=[779B70A0:01C25F3B]
Content-Length: 707
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA10628
Subject: [Simple] FW:
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: 

Please disregard the email below - the scenario was flawed.  
- Hemish


>  -----Original Message-----
> From: 	Parikh Hemish (EXT-NRC/Boston)  
> Sent:	Tuesday, September 17, 2002 11:45 AM
> To:	'simple@mailman.dynamicsoft.com'
> Subject:	
> 
> Hi
> 
> I have a scenario here as described: SIP is being used in Tunneling mode for Instant messaging in a 3G system. As I understand form TS24.229 of 3GPP, SGSN/GGSN acting as SIP proxies change the outer header fields like 'Content Type'. If yes then, now the outer header fields are different from the inner header fields. How the receiving UAS deal with this.
> 
> Appreciate suggestions.
> 
> Hemish Parikh
> Nokia Research Center
> Tel: 781-993 5752 
> 

From adam@dynamicsoft.com  Wed Sep 18 13:50:09 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10655
	for ; Wed, 18 Sep 2002 13:50:09 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8IHnTNo015198;
	Wed, 18 Sep 2002 13:49:29 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 18 Sep 2002 12:50:07 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64171@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'hisham.khartabil@nokia.com'" ,
        Adam Roach , pkyzivat@cisco.com
Cc: seancolson@yahoo.com, aki.niemi@nokia.com,
        Jonathan Rosenberg
	 ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Wed, 18 Sep 2002 12:49:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1148
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: 

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> 
> You left out one scenario (the one we should really be 
> comparing to collection as a package), which is the one that 
> uses collection as a template.

No, my first scenario is covering "collection." It doesn't matter
if it's "collection as a package" or "collection as a template."

The purpose of the message to which you replied was to refute
the implied assertion that collections (of any kind) increase
the overall number subscriptions in a system. My message was
*not* attempting to contrast the package approach with the
template approach. Paul is addressing the more general question
about whether collections (of any kind) are worth pursuing, and
I'm trying to make the case that they are.

I should have included the assumption that I was talking about
only one kind of state (e.g. presence). The point I was attempting
to demonstrate does not change as you vary this assumption, though:
the number of subscriptions in the system still increases at
approximately O(n^2) regardless of whether you use collections
(of any kind).

/a

From adam@dynamicsoft.com  Wed Sep 18 13:53:30 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10720
	for ; Wed, 18 Sep 2002 13:53:30 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8IHqnNo015213;
	Wed, 18 Sep 2002 13:52:49 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 18 Sep 2002 12:53:27 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64172@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Torrey Searle'" , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Wed, 18 Sep 2002 12:53:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 672
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: 

I think that's a really good suggestion. Thanks.

/a

(nit: s/people/resources/)

> -----Original Message-----
> From: Torrey Searle [mailto:tsearle@indigosw.com]
> Sent: Wednesday, September 18, 2002 5:22
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] collection template
> 
> 
> For the inital subscribe to a Template, would it be possible to just 
> send the list of people in the collection w/o the actuall 
> state?  IE a 
> presence-list of presence elements w/o tuples.  It would seem like an 
> appropriate time to get the "collection list" from the server, w/o 
> having to guess it from subsquent partial notifies.
> 
> Torrey Searle
> Indigo Software

From pkyzivat@cisco.com  Wed Sep 18 20:50:54 2002
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 UAA11885
	for ; Wed, 18 Sep 2002 20:50:54 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8J0ourn021489;
	Wed, 18 Sep 2002 20:50:57 -0400 (EDT)
Received: from cisco.com (rtp-vpn2-659.cisco.com [10.82.242.147])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAR12228;
	Wed, 18 Sep 2002 20:55:28 -0400 (EDT)
Message-ID: <3D891F60.FDCBB2B1@cisco.com>
Date: Wed, 18 Sep 2002 20:50:40 -0400
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 
CC: "'Torrey Searle'" , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A64172@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2236
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: 

This suggestion might also address one issue I had. When you first establish the subscription, or refresh it, or do a one-time poll for status, the event mechanism requires that a single notification be returned immediately, containing the current state of the resource (in this case the contact list). This is hard to do if the only notifications are relays of notifications from individual members of the collection.

This idea would begin to solve that problem. But other problems remain. For instance there is then still no way to poll for the current state of everything in the collection.

Also, the kind of response you are describing doesn't seem to fit within the current definition of PIDF. PIDF only permits you to mention one presentity. You could get creative, and make a pidf document that uses the address of the collection as the presentity, and describes all of the collection members as separate tuples, with the address of the member as a contact address. Or you could consider extending pidf to permit inclusion of multiple presentities. I had some discussions about those kinds of approaches a few months ago, with Jonathan or Adam I think. But since then things seem to have gone a different direction.

Without some kind of change I don't see how to make a collection conform to all the rules of an event package.

	Paul

Adam Roach wrote:
> 
> I think that's a really good suggestion. Thanks.
> 
> /a
> 
> (nit: s/people/resources/)
> 
> > -----Original Message-----
> > From: Torrey Searle [mailto:tsearle@indigosw.com]
> > Sent: Wednesday, September 18, 2002 5:22
> > To: simple@mailman.dynamicsoft.com
> > Subject: [Simple] collection template
> >
> >
> > For the inital subscribe to a Template, would it be possible to just
> > send the list of people in the collection w/o the actuall
> > state?  IE a
> > presence-list of presence elements w/o tuples.  It would seem like an
> > appropriate time to get the "collection list" from the server, w/o
> > having to guess it from subsquent partial notifies.
> >
> > Torrey Searle
> > Indigo Software
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

From tsearle@indigosw.com  Thu Sep 19 04:20:58 2002
Received: from m3102.hostcentric.net (m3102.hostcentric.net [216.157.79.140])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id EAA13199
	for ; Thu, 19 Sep 2002 04:20:57 -0400 (EDT)
Received: (qmail 25365 invoked by alias); 19 Sep 2002 08:17:59 -0000
Received: from unknown (HELO m3001.hostcentric.net) (216.157.79.237)
  by 0 with SMTP; 19 Sep 2002 08:17:59 -0000
Received: (qmail 4856 invoked by alias); 19 Sep 2002 08:17:55 -0000
Received: from unknown (HELO indigosw.com) (217.136.220.14)
  by 0 with SMTP; 19 Sep 2002 08:17:55 -0000
Message-ID: <3D8987DD.2050100@indigosw.com>
Date: Thu, 19 Sep 2002 10:16:29 +0200
From: Torrey Searle 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.0) Gecko/20020529
X-Accept-Language: en-us
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Adam Roach , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A64172@DYN-TX-EXCH-001.dynamicsoft.com> <3D891F60.FDCBB2B1@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1054
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: 

>
>
>Also, the kind of response you are describing doesn't seem to fit within the current definition of PIDF. PIDF only permits you to mention one presentity. You could get creative, and make a pidf document that uses the address of the collection as the presentity, and describes all of the collection members as separate tuples, with the address of the member as a contact address. Or you could consider extending pidf to permit inclusion of multiple presentities. I had some discussions about those kinds of approaches a few months ago, with Jonathan or Adam I think. But since then things seem to have gone a different direction.
>  
>
Section 4 of draft-ieft-simple-presencelist-package-00 describes a 
document format called PLIDF, which essentially is a list of PIDF 
documents.  So using that format, it should be possible to list all the 
contact addresses without problems.

Torrey Searle
Indigo Software

>Without some kind of change I don't see how to make a collection conform to all the rules of an event package.
>
>	Paul
>
>  
>
>  
>




From pkyzivat@cisco.com  Thu Sep 19 08:05:49 2002
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 IAA13888
	for ; Thu, 19 Sep 2002 08:05:48 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8JC5trE015198;
	Thu, 19 Sep 2002 08:05:55 -0400 (EDT)
Received: from cisco.com (rtp-vpn2-659.cisco.com [10.82.242.147])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAR13881;
	Thu, 19 Sep 2002 08:10:26 -0400 (EDT)
Message-ID: <3D89BD92.30D4A885@cisco.com>
Date: Thu, 19 Sep 2002 08:05:38 -0400
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: Torrey Searle 
CC: Adam Roach , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A64172@DYN-TX-EXCH-001.dynamicsoft.com> <3D891F60.FDCBB2B1@cisco.com> <3D8987DD.2050100@indigosw.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1784
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: 


Torrey Searle wrote:
> 
> >
> >
> >Also, the kind of response you are describing doesn't seem to fit within the current definition of PIDF. PIDF only permits you to mention one presentity. You could get creative, and make a pidf document that uses the address of the collection as the presentity, and describes all of the collection members as separate tuples, with the address of the member as a contact address. Or you could consider extending pidf to permit inclusion of multiple presentities. I had some discussions about those kinds of approaches a few months ago, with Jonathan or Adam I think. But since then things seem to have gone a different direction.
> >
> >
> Section 4 of draft-ieft-simple-presencelist-package-00 describes a
> document format called PLIDF, which essentially is a list of PIDF
> documents.  So using that format, it should be possible to list all the
> contact addresses without problems.

That draft is what started this discussion. The current discussion has drifted away from that proposal. 

That defined a new event package, different than presence, but related to presence. With that approach, every time you want to define a collection of some event type, you need to define another document format to go with it. People didn't seem very happy with that.

So the talk has moved to more generalized ways of defining collections. But what I think has been lost in that discussion is the need to have some format that permits returning the immediate response to a subscription.

One way to achieve that would be to define a document format for collections. Then subscribers to collections could expect to receive both that format, and the formats for elements of the collection. But the PLIDF format wouldn't be the right format for that.

	Paul

From aki.niemi@nokia.com  Thu Sep 19 08:35:07 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13992
	for ; Thu, 19 Sep 2002 08:35:06 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8JCZTZ26602
	for ; Thu, 19 Sep 2002 15:35:29 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 19 Sep 2002 15:35:02 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 19 Sep 2002 15:35:04 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] collection template
Date: Thu, 19 Sep 2002 15:35:03 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE481@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] collection template
Thread-Index: AcJfduyMFSSNZl3iQyKaiJQvOAz2tgAYZhDQ
To: , 
Cc: , 
X-OriginalArrivalTime: 19 Sep 2002 12:35:04.0505 (UTC) FILETIME=[FACC1A90:01C25FD8]
Content-Length: 3055
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA13992
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: 

Hi,

I still feel uneasy with the template package approach. It should be possible to subscribe to presence.collection.collection and get some sort of notification back. It doesn't seem obvious to me that the collection can work as a template package. 

Cheers,
Aki

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, September 19, 2002 3:51 AM
> To: Adam Roach
> Cc: 'Torrey Searle'; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] collection template
> 
> 
> This suggestion might also address one issue I had. When you 
> first establish the subscription, or refresh it, or do a 
> one-time poll for status, the event mechanism requires that a 
> single notification be returned immediately, containing the 
> current state of the resource (in this case the contact 
> list). This is hard to do if the only notifications are 
> relays of notifications from individual members of the collection.
> 
> This idea would begin to solve that problem. But other 
> problems remain. For instance there is then still no way to 
> poll for the current state of everything in the collection.
> 
> Also, the kind of response you are describing doesn't seem to 
> fit within the current definition of PIDF. PIDF only permits 
> you to mention one presentity. You could get creative, and 
> make a pidf document that uses the address of the collection 
> as the presentity, and describes all of the collection 
> members as separate tuples, with the address of the member as 
> a contact address. Or you could consider extending pidf to 
> permit inclusion of multiple presentities. I had some 
> discussions about those kinds of approaches a few months ago, 
> with Jonathan or Adam I think. But since then things seem to 
> have gone a different direction.
> 
> Without some kind of change I don't see how to make a 
> collection conform to all the rules of an event package.
> 
> 	Paul
> 
> Adam Roach wrote:
> > 
> > I think that's a really good suggestion. Thanks.
> > 
> > /a
> > 
> > (nit: s/people/resources/)
> > 
> > > -----Original Message-----
> > > From: Torrey Searle [mailto:tsearle@indigosw.com]
> > > Sent: Wednesday, September 18, 2002 5:22
> > > To: simple@mailman.dynamicsoft.com
> > > Subject: [Simple] collection template
> > >
> > >
> > > For the inital subscribe to a Template, would it be 
> possible to just
> > > send the list of people in the collection w/o the actuall
> > > state?  IE a
> > > presence-list of presence elements w/o tuples.  It would 
> seem like an
> > > appropriate time to get the "collection list" from the server, w/o
> > > having to guess it from subsquent partial notifies.
> > >
> > > Torrey Searle
> > > Indigo Software
> > _______________________________________________
> > 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 aki.niemi@nokia.com  Thu Sep 19 08:42:46 2002
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 IAA14035
	for ; Thu, 19 Sep 2002 08:42:45 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8JCgdT03994
	for ; Thu, 19 Sep 2002 15:42:39 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 19 Sep 2002 15:41:46 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 19 Sep 2002 15:41:45 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] collection template
Date: Thu, 19 Sep 2002 15:41:45 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE482@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] collection template
Thread-Index: AcJfduyMFSSNZl3iQyKaiJQvOAz2tgAYZhDQAABE7TA=
To: , , 
Cc: , 
X-OriginalArrivalTime: 19 Sep 2002 12:41:45.0746 (UTC) FILETIME=[E9F49F20:01C25FD9]
Content-Length: 3970
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA14035
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: 

...Unless of course the fan out treats all events alike, i.e., subscription for presence.collection.collection results in a SUBSCRIBE for event presence.collection -- the initial notify could still have the same information regardless of the "depth" of the collection.

Thanks,
Aki ;)

> -----Original Message-----
> From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Thursday, September 19, 2002 3:35 PM
> To: pkyzivat@cisco.com; adam@dynamicsoft.com
> Cc: tsearle@indigosw.com; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] collection template
> 
> 
> Hi,
> 
> I still feel uneasy with the template package approach. It 
> should be possible to subscribe to 
> presence.collection.collection and get some sort of 
> notification back. It doesn't seem obvious to me that the 
> collection can work as a template package. 
> 
> Cheers,
> Aki
> 
> > -----Original Message-----
> > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > Sent: Thursday, September 19, 2002 3:51 AM
> > To: Adam Roach
> > Cc: 'Torrey Searle'; simple@mailman.dynamicsoft.com
> > Subject: Re: [Simple] collection template
> > 
> > 
> > This suggestion might also address one issue I had. When you 
> > first establish the subscription, or refresh it, or do a 
> > one-time poll for status, the event mechanism requires that a 
> > single notification be returned immediately, containing the 
> > current state of the resource (in this case the contact 
> > list). This is hard to do if the only notifications are 
> > relays of notifications from individual members of the collection.
> > 
> > This idea would begin to solve that problem. But other 
> > problems remain. For instance there is then still no way to 
> > poll for the current state of everything in the collection.
> > 
> > Also, the kind of response you are describing doesn't seem to 
> > fit within the current definition of PIDF. PIDF only permits 
> > you to mention one presentity. You could get creative, and 
> > make a pidf document that uses the address of the collection 
> > as the presentity, and describes all of the collection 
> > members as separate tuples, with the address of the member as 
> > a contact address. Or you could consider extending pidf to 
> > permit inclusion of multiple presentities. I had some 
> > discussions about those kinds of approaches a few months ago, 
> > with Jonathan or Adam I think. But since then things seem to 
> > have gone a different direction.
> > 
> > Without some kind of change I don't see how to make a 
> > collection conform to all the rules of an event package.
> > 
> > 	Paul
> > 
> > Adam Roach wrote:
> > > 
> > > I think that's a really good suggestion. Thanks.
> > > 
> > > /a
> > > 
> > > (nit: s/people/resources/)
> > > 
> > > > -----Original Message-----
> > > > From: Torrey Searle [mailto:tsearle@indigosw.com]
> > > > Sent: Wednesday, September 18, 2002 5:22
> > > > To: simple@mailman.dynamicsoft.com
> > > > Subject: [Simple] collection template
> > > >
> > > >
> > > > For the inital subscribe to a Template, would it be 
> > possible to just
> > > > send the list of people in the collection w/o the actuall
> > > > state?  IE a
> > > > presence-list of presence elements w/o tuples.  It would 
> > seem like an
> > > > appropriate time to get the "collection list" from the 
> server, w/o
> > > > having to guess it from subsquent partial notifies.
> > > >
> > > > Torrey Searle
> > > > Indigo Software
> > > _______________________________________________
> > > 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 tsearle@indigosw.com  Thu Sep 19 08:58:19 2002
Received: from m3102.hostcentric.net (m3102.hostcentric.net [216.157.79.140])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id IAA14133
	for ; Thu, 19 Sep 2002 08:58:18 -0400 (EDT)
Received: (qmail 14577 invoked by alias); 19 Sep 2002 12:58:18 -0000
Received: from unknown (HELO m3001.hostcentric.net) (216.157.79.237)
  by 0 with SMTP; 19 Sep 2002 12:58:18 -0000
Received: (qmail 21213 invoked by alias); 19 Sep 2002 12:58:17 -0000
Received: from unknown (HELO indigosw.com) (217.136.220.14)
  by 0 with SMTP; 19 Sep 2002 12:58:17 -0000
Message-ID: <3D89C98A.2000009@indigosw.com>
Date: Thu, 19 Sep 2002 14:56:42 +0200
From: Torrey Searle 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.0) Gecko/20020529
X-Accept-Language: en-us
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: pkyzivat@cisco.com, adam@dynamicsoft.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE481@esebe013.ntc.nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 862
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: 

Couldn't presence.collection.collection still be interesting? Suppose 
that I want to have a "presence list" organized into groups, I.E. so I 
have a collection that subscribse to the Collection of all the people 
who work at my company (with that list being maintained by the system 
administrator of the company) and a Family group, and maybe a Group for 
the members of Community Service I am a member of.  Each collection 
could be updated w/o me needing to modifiy my collection.

Any thoughts on this?

Torrey Searle
Indigo Software

aki.niemi@nokia.com a écrit:

>Hi,
>
>I still feel uneasy with the template package approach. It should be possible to subscribe to presence.collection.collection and get some sort of notification back. It doesn't seem obvious to me that the collection can work as a template package. 
>
>Cheers,
>Aki
>
>  
>
>>    
>>



From adam@dynamicsoft.com  Fri Sep 20 15:10:54 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19261
	for ; Fri, 20 Sep 2002 15:10:54 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KJABNo027104;
	Fri, 20 Sep 2002 15:10:12 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 20 Sep 2002 14:10:48 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6418D@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Paul Kyzivat'" , Adam Roach 
Cc: "'Torrey Searle'" , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Fri, 20 Sep 2002 14:10:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1280
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: 

> This suggestion might also address one issue I had. When you 
> first establish the subscription, or refresh it, or do a 
> one-time poll for status, the event mechanism requires that a 
> single notification be returned immediately, containing the 
> current state of the resource (in this case the contact 
> list). This is hard to do if the only notifications are 
> relays of notifications from individual members of the collection.

RFC 3265 requires a NOTIFY. That NOTIFY isn't required to contain
correct state information, just well-formatted state information.

> This idea would begin to solve that problem. But other 
> problems remain. For instance there is then still no way to 
> poll for the current state of everything in the collection.

I'm willing to accept that as a limitation of the mechanism. Polling
is usually too heavy on network resources to warrant deployment.

> Also, the kind of response you are describing doesn't seem to 
> fit within the current definition of PIDF.

It wouldn't *be* PIDF. It would be whatever the collection
{package,template} defines. My vote would be for mime multipart.

> Without some kind of change I don't see how to make a 
> collection conform to all the rules of an event package.

Odd. I don't see any barriers.

/a

From adam@dynamicsoft.com  Fri Sep 20 15:17:03 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19303
	for ; Fri, 20 Sep 2002 15:17:03 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KJGINo027126;
	Fri, 20 Sep 2002 15:16:19 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 20 Sep 2002 14:16:58 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6418E@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'aki.niemi@nokia.com'" , pkyzivat@cisco.com,
        Adam Roach 
Cc: tsearle@indigosw.com, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Fri, 20 Sep 2002 14:16:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4679
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: 

And that was precisely my intention. In fact, I implied as much
very early in this discussion, with an example message that shows
a subscription to presence.collection.collection.

/a

> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Thursday, September 19, 2002 7:42
> To: aki.niemi@nokia.com; pkyzivat@cisco.com; adam@dynamicsoft.com
> Cc: tsearle@indigosw.com; simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] collection template
> 
> 
> ...Unless of course the fan out treats all events alike, 
> i.e., subscription for presence.collection.collection results 
> in a SUBSCRIBE for event presence.collection -- the initial 
> notify could still have the same information regardless of 
> the "depth" of the collection.
> 
> Thanks,
> Aki ;)
> 
> > -----Original Message-----
> > From: ext aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> > Sent: Thursday, September 19, 2002 3:35 PM
> > To: pkyzivat@cisco.com; adam@dynamicsoft.com
> > Cc: tsearle@indigosw.com; simple@mailman.dynamicsoft.com
> > Subject: RE: [Simple] collection template
> > 
> > 
> > Hi,
> > 
> > I still feel uneasy with the template package approach. It 
> > should be possible to subscribe to 
> > presence.collection.collection and get some sort of 
> > notification back. It doesn't seem obvious to me that the 
> > collection can work as a template package. 
> > 
> > Cheers,
> > Aki
> > 
> > > -----Original Message-----
> > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > Sent: Thursday, September 19, 2002 3:51 AM
> > > To: Adam Roach
> > > Cc: 'Torrey Searle'; simple@mailman.dynamicsoft.com
> > > Subject: Re: [Simple] collection template
> > > 
> > > 
> > > This suggestion might also address one issue I had. When you 
> > > first establish the subscription, or refresh it, or do a 
> > > one-time poll for status, the event mechanism requires that a 
> > > single notification be returned immediately, containing the 
> > > current state of the resource (in this case the contact 
> > > list). This is hard to do if the only notifications are 
> > > relays of notifications from individual members of the collection.
> > > 
> > > This idea would begin to solve that problem. But other 
> > > problems remain. For instance there is then still no way to 
> > > poll for the current state of everything in the collection.
> > > 
> > > Also, the kind of response you are describing doesn't seem to 
> > > fit within the current definition of PIDF. PIDF only permits 
> > > you to mention one presentity. You could get creative, and 
> > > make a pidf document that uses the address of the collection 
> > > as the presentity, and describes all of the collection 
> > > members as separate tuples, with the address of the member as 
> > > a contact address. Or you could consider extending pidf to 
> > > permit inclusion of multiple presentities. I had some 
> > > discussions about those kinds of approaches a few months ago, 
> > > with Jonathan or Adam I think. But since then things seem to 
> > > have gone a different direction.
> > > 
> > > Without some kind of change I don't see how to make a 
> > > collection conform to all the rules of an event package.
> > > 
> > > 	Paul
> > > 
> > > Adam Roach wrote:
> > > > 
> > > > I think that's a really good suggestion. Thanks.
> > > > 
> > > > /a
> > > > 
> > > > (nit: s/people/resources/)
> > > > 
> > > > > -----Original Message-----
> > > > > From: Torrey Searle [mailto:tsearle@indigosw.com]
> > > > > Sent: Wednesday, September 18, 2002 5:22
> > > > > To: simple@mailman.dynamicsoft.com
> > > > > Subject: [Simple] collection template
> > > > >
> > > > >
> > > > > For the inital subscribe to a Template, would it be 
> > > possible to just
> > > > > send the list of people in the collection w/o the actuall
> > > > > state?  IE a
> > > > > presence-list of presence elements w/o tuples.  It would 
> > > seem like an
> > > > > appropriate time to get the "collection list" from the 
> > server, w/o
> > > > > having to guess it from subsquent partial notifies.
> > > > >
> > > > > Torrey Searle
> > > > > Indigo Software
> > > > _______________________________________________
> > > > 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 adam@dynamicsoft.com  Fri Sep 20 15:20:31 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19337
	for ; Fri, 20 Sep 2002 15:20:31 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KJJlNo027178;
	Fri, 20 Sep 2002 15:19:47 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 20 Sep 2002 14:20:27 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6418F@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Torrey Searle'" , aki.niemi@nokia.com
Cc: pkyzivat@cisco.com, Adam Roach ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Fri, 20 Sep 2002 14:20:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1756
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA19337
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: 

Of *course* it's interesting. In fact, I included it as an example
in my very first response to this thread, based on the scenario that
Jonathan laid out.

It's a template. It works like a template. "presence.collection"
and "presence.winfo.collection" and "presence.collection.collection"
and "presence.collection.winfo" and "presence.winfo.collection.winfo"
and "presence.collection.collection.winfo" and any other combination
you can think of will all have well-defined semantics. Many of them will
even be useful in some contexts.

/a

> -----Original Message-----
> From: Torrey Searle [mailto:tsearle@indigosw.com]
> Sent: Thursday, September 19, 2002 7:57
> To: aki.niemi@nokia.com
> Cc: pkyzivat@cisco.com; adam@dynamicsoft.com;
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] collection template
> 
> 
> Couldn't presence.collection.collection still be interesting? Suppose 
> that I want to have a "presence list" organized into groups, 
> I.E. so I 
> have a collection that subscribse to the Collection of all the people 
> who work at my company (with that list being maintained by the system 
> administrator of the company) and a Family group, and maybe a 
> Group for 
> the members of Community Service I am a member of.  Each collection 
> could be updated w/o me needing to modifiy my collection.
> 
> Any thoughts on this?
> 
> Torrey Searle
> Indigo Software
> 
> aki.niemi@nokia.com a écrit:
> 
> >Hi,
> >
> >I still feel uneasy with the template package approach. It 
> should be possible to subscribe to 
> presence.collection.collection and get some sort of 
> notification back. It doesn't seem obvious to me that the 
> collection can work as a template package. 
> >
> >Cheers,
> >Aki
> >
> >  
> >
> >>    
> >>
> 
> 

From jhargest@cnri.reston.va.us  Thu Sep 19 15:40:36 2002
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 PAA15445
	for ; Thu, 19 Sep 2002 15:40:36 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20338;
	Thu, 19 Sep 2002 15:38:49 -0400 (EDT)
Message-Id: <200209191938.PAA20338@ietf.org>
To: IETF-Announce: ;
Cc: simple@mailman.dynamicsoft.com
From: The IESG 
Reply-to: iesg@ietf.org
Date: Thu, 19 Sep 2002 15:38:48 -0400
Content-Length: 991
Subject: [Simple] Last Call: A Session Initiation Protocol (SIP)Event
 Template-Package for Watcher Information to Proposed Standard
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: 

The IESG has received a request from the SIP for Instant Messaging and
Presence Leveraging Extensions Working Group to consider publishing
each of the following internet drafts as Proposed Standards:

o A Session Initiation Protocol (SIP)Event Template-Package for Watcher 
  Information
	
o An Extensible Markup Language (XML) Based Format for Watcher Information
	
o Session Initiation Protocol (SIP) Extensions for Presence
	


The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg@ietf.org or ietf@ietf.org mailing lists by 2002-10-3.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-02.txt 
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-07.txt




From adam@dynamicsoft.com  Fri Sep 20 19:23:48 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20077
	for ; Fri, 20 Sep 2002 19:23:48 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g8KNN7No028319;
	Fri, 20 Sep 2002 19:23:07 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 20 Sep 2002 18:23:46 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64195@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'Paul Kyzivat'" , Adam Roach 
Cc: "'Sean Olson'" , aki.niemi@nokia.com,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Fri, 20 Sep 2002 18:23:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 824
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: 

From: Paul Kyzivat [mailto:pkyzivat@cisco.com]

> Then of course S1 must obtain the credential it uses to act 
> on behalf of C1 somewhow, and S2 must know how to recognize 
> such a credential and decide whether to honor it. This all 
> adds complexity to the use of collections. (Whether they are 
> templates or not.)

The issue of S2 knowing which credentials to trust isn't
inherent in the collections problem. It's something that
arises whenever you use event agents. For presence, it's
the norm.

> Do you see a reasonable way to approach this problem of credentials? 

The permissions problems are congruent to the "Referred-By"
problem -- and we already have people working on that. I expect
to see some output on this topic -- that is, delegation of
credentials for specific tasks -- sometime relatively soon.

/a

From peter.lewis@upperside.fr  Mon Sep 23 05:13:08 2002
Received: from relay2.clb.oleane.net (relay2.clb.oleane.net [213.56.31.22])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00410
	for ; Mon, 23 Sep 2002 05:13:07 -0400 (EDT)
Received: from chantal (upper-side.rain.fr [194.250.212.114]) 
	by relay2.clb.oleane.net with SMTP id g8N9D63u031681
	for ; Mon, 23 Sep 2002 11:13:06 +0200
Message-ID: <00ad01c262e1$dfc6b320$0701a8c0@upperside>
From: "Peter Lewis" 
To: 
Date: Mon, 23 Sep 2002 11:16:17 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A9_01C262F2.A2F26F00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Content-Length: 1583
Subject: [Simple] International SIP
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_00A9_01C262F2.A2F26F00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The fourth edition of International SIP will take place January 14 to 17,
2003 in Paris. The most eminent specialists in this technology will be on
hand to discuss technological and implementation issues. Indeed, a greater
importance is given this year to PSTN and wireless operators deployment
scenarios.

All details at : http://www.upperside.fr/intersip03/sip03intro.htm



------=_NextPart_000_00A9_01C262F2.A2F26F00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









The fourth edition of International SIP will take =
place=20
January 14 to 17, 2003 in Paris. The most eminent =
specialists=20
in this technology will be on hand to discuss technological and =
implementation=20
issues. Indeed, a greater importance is given this year to PSTN and =
wireless=20
operators deployment scenarios.


All details at : http://www.upp=
erside.fr/intersip03/sip03intro.htm


 


 


------=_NextPart_000_00A9_01C262F2.A2F26F00--


From nsyracus@cnri.reston.va.us  Mon Sep 23 08:05:48 2002
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 IAA00899
	for ; Mon, 23 Sep 2002 08:05:48 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05308;
	Mon, 23 Sep 2002 08:03:58 -0400 (EDT)
Message-Id: <200209231203.IAA05308@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
Date: Mon, 23 Sep 2002 08:03:58 -0400
Content-Length: 3180
Subject: [Simple] I-D ACTION:draft-niemi-simple-publish-framework-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIP Specific Data Publication Framework
	Author(s)	: A. Niemi
	Filename	: draft-niemi-simple-publish-framework-00.txt
	Pages		: 11
	Date		: 2002-9-20
	
This document describes an extension to the Session Initiation
Protocol (SIP).  The purpose of this extension is to provide an
extensible framework for publication of SIP specific data.  This
extension derives from the recent Internet Draft defining the PUBLISH
method, but instead of using the SIP events framework, it introduces
a specific publication framework for the publish mechanism.  The main
motivations for decoupling publications from events are that the
event framework is not overloaded, and the applicability of the
PUBLISH method to problem sets similar to those surfacing in the
publication of event state is improved.  The SIP publication
framework is neither intended for general data manipulation, nor is
it intended to foster any discussion on the issue of using SIP for
everything.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framework-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-niemi-simple-publish-framework-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-niemi-simple-publish-framework-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:	<2002-9-20142546.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-niemi-simple-publish-framework-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-niemi-simple-publish-framework-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-9-20142546.I-D@ietf.org>

--OtherAccess--

--NextPart--



From aki.niemi@nokia.com  Mon Sep 23 08:47:34 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01064
	for ; Mon, 23 Sep 2002 08:47:33 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8NCm1Z11753
	for ; Mon, 23 Sep 2002 15:48:01 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Mon, 23 Sep 2002 15:47:33 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 23 Sep 2002 15:47:33 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] I-D ACTION:draft-niemi-simple-publish-framework-00.txt
Date: Mon, 23 Sep 2002 15:47:33 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901944FD9@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] I-D ACTION:draft-niemi-simple-publish-framework-00.txt
Thread-Index: AcJi+jTS8mY+9f2gTO+J53bEpRZRgAAArcIA
To: 
X-OriginalArrivalTime: 23 Sep 2002 12:47:33.0341 (UTC) FILETIME=[62CA68D0:01C262FF]
Content-Length: 3490
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA01064
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: 

Hi All,

This I-D proposes a slight change of direction for the PUBLISH work, draft-olson-simple-publish-00. It describes a publication framework, which is similar to the SIP events framework in many ways. 

Especially the overloading of events with PUBLISH is addressed by this draft, as well as the possiblity of widening the applicability of PUBLISH in a way that still preserves its currently defined properties.

The intention was to present these ideas in a concrete way, and if deemed worthwhile, incorporate the contents of the draft to draft-olson-simple-publish-00.

Comments are most welcome.

Cheers,
Aki

> -----Original Message-----
> From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Monday, September 23, 2002 3:04 PM
> Cc: simple@mailman.dynamicsoft.com
> Subject: [Simple] I-D 
> ACTION:draft-niemi-simple-publish-framework-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: SIP Specific Data Publication Framework
> 	Author(s)	: A. Niemi
> 	Filename	: draft-niemi-simple-publish-framework-00.txt
> 	Pages		: 11
> 	Date		: 2002-9-20
> 	
> This document describes an extension to the Session Initiation
> Protocol (SIP).  The purpose of this extension is to provide an
> extensible framework for publication of SIP specific data.  This
> extension derives from the recent Internet Draft defining the PUBLISH
> method, but instead of using the SIP events framework, it introduces
> a specific publication framework for the publish mechanism.  The main
> motivations for decoupling publications from events are that the
> event framework is not overloaded, and the applicability of the
> PUBLISH method to problem sets similar to those surfacing in the
> publication of event state is improved.  The SIP publication
> framework is neither intended for general data manipulation, nor is
> it intended to foster any discussion on the issue of using SIP for
> everything.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framework-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-niemi-simple-publish-framework-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-niemi-simple-publish-framework-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.

From paf@cisco.com  Tue Sep 24 09:48:00 2002
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05282
	for ; Tue, 24 Sep 2002 09:48:00 -0400 (EDT)
Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1])
	by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8ODkrnc027056
	for ; Tue, 24 Sep 2002 15:46:54 +0200 (MET DST)
Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 24 Sep 2002 15:47:35 +0200
Received: from cisco.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453);
	 Tue, 24 Sep 2002 15:47:35 +0200
Date: Tue, 24 Sep 2002 15:47:34 +0200
Mime-Version: 1.0 (Apple Message framework v546)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: Fwd: [Simple] Last Call: A Session Initiation Protocol (SIP)Event  presence Package  to Proposed Standard
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
To: simple@mailman.dynamicsoft.com
Content-Transfer-Encoding: 7bit
Message-Id: <2DB0F479-CFC4-11D6-B5A3-0003934B2128@cisco.com>
X-Mailer: Apple Mail (2.546)
X-OriginalArrivalTime: 24 Sep 2002 13:47:35.0123 (UTC) FILETIME=[F0087A30:01C263D0]
Content-Length: 2888
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: 


Begin forwarded message:

> From: Tan Ya-Ching  ICM N PG U ID A 1 
> Date: Tue Sep 24, 2002  1:21:17 PM Europe/Stockholm
> To: "'iesg@ietf.org'" 
> Subject: RE: [Simple] Last Call: A Session Initiation Protocol 
> (SIP)Event  presence Package  to Proposed Standard
>
> Comments on draft-ietf-simple-presence-07.txt :
>
> Section 4   2nd paragraph
>
> o "The subcription is carried along SIP proxies as any other
>     request would be".
>
>    "subscription" => "SUBSCRIBE request"
>
> o "...it eventually arrives at a presence server, which can
>    either terminate the subscription..."
>
>    "terminate the subscription" => "serves as  the
>    terminating point for the SUBSCRIBE request and
>    handles the subscription"
>
> Section 4  6th paragraph
>
> o "This (refresh) SUBSCRIBE is nearly identical to the
>     initial one, but contains the dialog identifier, different
>     sequence numbers, and a set of Route headers..."
>     =>
>     "...but contains the To tag, a higher sequence number,
>     and possibly a set of Route headers..."
>
> Section 8
>
>    o The mandatory Contact header is missing in the NOTIFY messages in 
> the
> example message flow of section 8.
>
>    o 2nd paragraph of section 8 : "... th(r)ough some non-SIP means"
>
>
> - Ya-Ching Tan
>
>
> | -----Original Message-----
> | From: The IESG [mailto:iesg-secretary@ietf.org]
> | Sent: 19 September 2002 21:39
> | Cc: simple@mailman.dynamicsoft.com
> | Subject: [Simple] Last Call: A Session Initiation Protocol (SIP)Event
> | Template-Package for Watcher Information to Proposed Standard
> |
> |
> |
> | The IESG has received a request from the SIP for Instant Messaging 
> and
> | Presence Leveraging Extensions Working Group to consider publishing
> | each of the following internet drafts as Proposed Standards:
> |
> | o A Session Initiation Protocol (SIP)Event Template-Package
> | for Watcher
> |   Information
> | 	
> | o An Extensible Markup Language (XML) Based Format for
> | Watcher Information
> | 	
> | o Session Initiation Protocol (SIP) Extensions for Presence
> | 	
> |
> |
> | The IESG plans to make a decision in the next few weeks, and solicits
> | final comments on this action.  Please send any comments to the
> | iesg@ietf.org or ietf@ietf.org mailing lists by 2002-10-3.
> |
> | Files can be obtained via
> | http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-pa
> | ckage-02.txt
> | http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-fo
> rmat-02.txt
> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-07.txt
>
>
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From Markus.Isomaki@nokia.com  Wed Sep 25 09:52:35 2002
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 JAA09364
	for ; Wed, 25 Sep 2002 09:52:34 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8PDqK520954
	for ; Wed, 25 Sep 2002 16:52:20 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Wed, 25 Sep 2002 16:49:59 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 25 Sep 2002 16:49:57 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 25 Sep 2002 16:49:56 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Last Call: A Session Initiation Protocol (SIP)Event  presence Package  to Proposed Standard
Thread-Index: AcJj0YzSxKGbfEEmSPSxSBM6Tc+15wArf8Xw
To: 
X-OriginalArrivalTime: 25 Sep 2002 13:49:57.0147 (UTC) FILETIME=[6F195EB0:01C2649A]
Content-Length: 2678
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA09364
Subject: [Simple] The way forward in data manipulation work
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 

Hi,

I think this would be a good time to see how to go forward with the charter items related to data manipulation. 

I believe Jonathan is planning to update the Data Manipulation Requirements draft  focusing on two issues: 1. List management, and 2. Authrozation policy management. In Yokohama the concensus was to take this draft as basis for WG requirements, so maybe the next version could be taken as a WG draft. It is also a good proposal to limit that draft to purely requirements, leaving the "model" in Chapter 4 out of scope. Maybe then it would be easiear to agree on the draft.

However, some kind of model/framework draft (similar to what is being done in conferencing) is also needed, and eventually it is essential to agree on what protocols to use. Based on usage guidelines SIP does not seem to meet the requirements. The current PUBLISH proposal is too simplistic to be useful in many cases. Instead, some kind of more flexible RPC mechanism with some support to synchronization seems to be the best choise.

My proposal is thus:
1. Use SOAP/WSDL for data manipulation. In the first phase a definition is needed only for list and auth. policy management, but the framework does not need to limit to this.
2. Use SIP Events in a same fashion as "Message Waiting Indicator" draft to convey notifications about state changes in the managed objects. A collection package could be used for optimization purposes. This spec could still leave the actual synchronization update mechanism open, but I can imagine SyncML and others could potentially be usable there.
3. Take SIP BIND as a default mechanism to make binding between sip: URIs and SOAP http: URIs.

In my opinion the framework doc. should define the terminology, have a few nice ascii-drawings and describe the model and the actors within points 1-3 above. Also, it should tell how to specify management interfaces for specific objects, and how to achieve the synchronization. In addition more specific documents would be needed for "list management", "authorization policy management" and "synchronization event package".

I think we could have the first version of such framework draft could be ready for the next IETF Atlanta meeting, and discussed there. Then it could be updated and work on more specific drafts could start. 

But before starting anything like this, I would like to get people's opinion about the technical part, and of course chairs' opinion about the process. I'm sure there are plenty of other approaches, but I haven't heard any proposals so far. In any case, some kind of design team around this matter might be a good idea.

Regards,
	Markus 

From seonman@funtv.com  Wed Sep 25 18:47:47 2002
Received: from hop.funtv.com (hop.funtv.com [206.19.100.98])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10885
	for ; Wed, 25 Sep 2002 18:47:47 -0400 (EDT)
Received: from skim (sns.funtv.com [206.19.96.100])
	by hop.funtv.com (8.8.8+Sun/8.8.8) with SMTP id PAA11021;
	Wed, 25 Sep 2002 15:47:46 -0700 (PDT)
Message-ID: <01eb01c264e5$aba9b730$400015ac@skim>
From: "Seonman Kim" 
To: 
Cc: "Seonman Kim" 
Date: Wed, 25 Sep 2002 15:48:30 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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
Content-Length: 2214
Subject: [Simple] Error when sending NOTIFY to MSN messenger (RTC)
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: 

Hi,
I am implementing SIMPLE protocol and testing with MSN messenger (Windows
RTC).
I successfully subscribed to a buddy (named "temin") with SUBSCRIBE request
to our presence server.
But when our presence servere notifies to the watcher using NOTIFY message,
I got a "415 Unsupported Media Type" error. I guess I have wrong information
in PIDF document in NOTIFY message, but I could not figure out the problem.
Will anyone of you teach me what the problem is?
I attached the SUBSCRIBE and NOTIFY message, and 415 error returned by MSN
Messenger.

And if someone knows the format of  content body for NOTIFY message used
Windows RTC, please let me know.

----
SUBSCRIBE sip:temin@206.xxx.xxx.203 SIP/2.0
Via: SIP/2.0/TCP 172.xxx.xxx.64:12559
From: "seonman"
;tag=85842f8e-b074-487f-a3d5-a6da1abdc648
To: 
Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64
CSeq: 1 SUBSCRIBE
Contact: 
User-Agent: Windows RTC/1.0
Expires: 1800
Content-Length: 0


NOTIFY sip:seonman@206.xxx.xxx.203 SIP/2.0
Via: SIP/2.0/UDP 206.xxx.xxx.205:5070
To: ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648
From: ;tag=90693859
Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64
CSeq: 1 NOTIFY
Max-Forwards: 70
Route: 
Subscription-State: active;expires=1800
Content-Type: application/cpim-pidf+xml
Content-Length: 273





open

sip:temin@206.xxx.xxx.203



----------------
SIP/2.0 415 Unsupported Media Type
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bKdba1f899bbbec7f2d301db4f58404563.2
Via: SIP/2.0/UDP 206.xxx.xxx.205:5070
From: ;tag=90693859
To: ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648
Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64
CSeq: 1 NOTIFY
User-Agent: Windows RTC/1.0
Content-Length: 0


Thanks,
Seonman


From tanglih@cn.ibm.com  Wed Sep 25 21:17:08 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11308
	for ; Wed, 25 Sep 2002 21:17:07 -0400 (EDT)
Received: from d23rh902.au.ibm.com (d23rh902.au.ibm.com [9.185.167.101])
	by ausmtp01.au.ibm.com (8.12.1/8.12.1) with ESMTP id g8Q18hhh135900;
	Thu, 26 Sep 2002 11:08:43 +1000
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.181.2.75])
	by d23rh902.au.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8Q1C8rd018174;
	Thu, 26 Sep 2002 11:12:09 +1000
Subject: Re: [Simple] Error when sending NOTIFY to MSN messenger (RTC)
To: "Seonman Kim" 
Cc: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Thu, 26 Sep 2002 09:17:22 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.9a |January 7, 2002) at
 26/09/2002 09:17:25
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 3817
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: 

AFAIK, they use application/cpim-xpidf.
It's not a mandatory format but several vendors support this.


Best regards,
Tang Lihua



                                                                                                                      
                      "Seonman Kim"                                                                                   
                                    To:                            
                      Sent by:                         cc:       "Seonman Kim"                     
                      simple-admin@mailman.dyna        Subject:  [Simple] Error when sending NOTIFY to MSN messenger  
                      micsoft.com                       (RTC)                                                         
                                                                                                                      
                                                                                                                      
                      2002-09-26 06:48                                                                                
                                                                                                                      
                                                                                                                      



Hi,
I am implementing SIMPLE protocol and testing with MSN messenger (Windows
RTC).
I successfully subscribed to a buddy (named "temin") with SUBSCRIBE request
to our presence server.
But when our presence servere notifies to the watcher using NOTIFY message,
I got a "415 Unsupported Media Type" error. I guess I have wrong
information
in PIDF document in NOTIFY message, but I could not figure out the problem.
Will anyone of you teach me what the problem is?
I attached the SUBSCRIBE and NOTIFY message, and 415 error returned by MSN
Messenger.

And if someone knows the format of  content body for NOTIFY message used
Windows RTC, please let me know.

----
SUBSCRIBE sip:temin@206.xxx.xxx.203 SIP/2.0
Via: SIP/2.0/TCP 172.xxx.xxx.64:12559
From: "seonman"
;tag=85842f8e-b074-487f-a3d5-a6da1abdc648
To: 
Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64
CSeq: 1 SUBSCRIBE
Contact: 
User-Agent: Windows RTC/1.0
Expires: 1800
Content-Length: 0


NOTIFY sip:seonman@206.xxx.xxx.203 SIP/2.0
Via: SIP/2.0/UDP 206.xxx.xxx.205:5070
To: ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648
From: ;tag=90693859
Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64
CSeq: 1 NOTIFY
Max-Forwards: 70
Route: 
Subscription-State: active;expires=1800
Content-Type: application/cpim-pidf+xml
Content-Length: 273





open

sip:temin@206.xxx.xxx.203



----------------
SIP/2.0 415 Unsupported Media Type
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bKdba1f899bbbec7f2d301db4f58404563.2
Via: SIP/2.0/UDP 206.xxx.xxx.205:5070
From: ;tag=90693859
To: ;tag=85842f8e-b074-487f-a3d5-a6da1abdc648
Call-ID: c59f8f61-503f-4cfa-be85-54cf7494aa46@172.xxx.xxx.64
CSeq: 1 NOTIFY
User-Agent: Windows RTC/1.0
Content-Length: 0


Thanks,
Seonman

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





From jdrosen@dynamicsoft.com  Thu Sep 26 14:11:18 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14183
	for ; Thu, 26 Sep 2002 14:11:18 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.47])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g8QIBIYH000398;
	Thu, 26 Sep 2002 14:11:18 -0400 (EDT)
Message-ID: <3D934DC5.9050101@dynamicsoft.com>
Date: Thu, 26 Sep 2002 14:11:17 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 
CC: simple@mailman.dynamicsoft.com
Subject: Re: Fwd: [Simple] Last Call: A Session Initiation Protocol (SIP)Event
  presence Package  to Proposed Standard
References: <2DB0F479-CFC4-11D6-B5A3-0003934B2128@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 2077
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: 

responses inline.

Patrik Fältström wrote:
> 
> 
> Begin forwarded message:
> 
>> From: Tan Ya-Ching  ICM N PG U ID A 1 
>> Date: Tue Sep 24, 2002  1:21:17 PM Europe/Stockholm
>> To: "'iesg@ietf.org'" 
>> Subject: RE: [Simple] Last Call: A Session Initiation Protocol 
>> (SIP)Event  presence Package  to Proposed Standard
>>
>> Comments on draft-ietf-simple-presence-07.txt :
>>
>> Section 4   2nd paragraph
>>
>> o "The subcription is carried along SIP proxies as any other
>>     request would be".
>>
>>    "subscription" => "SUBSCRIBE request"

Fixed.

>>
>> o "...it eventually arrives at a presence server, which can
>>    either terminate the subscription..."
>>
>>    "terminate the subscription" => "serves as  the
>>    terminating point for the SUBSCRIBE request and
>>    handles the subscription"

I think its even better worded as:

In most cases, it eventually
arrives at a presence server, which can either generate a response to
the request (in which case it acts as the presence agent for the
presentity), or proxy it on to an edge presence server.


>>
>> Section 4  6th paragraph
>>
>> o "This (refresh) SUBSCRIBE is nearly identical to the
>>     initial one, but contains the dialog identifier, different
>>     sequence numbers, and a set of Route headers..."
>>     =>
>>     "...but contains the To tag, a higher sequence number,
>>     and possibly a set of Route headers..."

Fixed.

>>
>> Section 8
>>
>>    o The mandatory Contact header is missing in the NOTIFY messages in 
>> the
>> example message flow of section 8.

Fixed.

>>
>>    o 2nd paragraph of section 8 : "... th(r)ough some non-SIP means"

Fixed.

Thanks for your comments,
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


From pkyzivat@cisco.com  Thu Sep 26 19:08:25 2002
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 TAA15166
	for ; Thu, 26 Sep 2002 19:08:20 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8QN89ei000416;
	Thu, 26 Sep 2002 19:08:13 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAR61872;
	Thu, 26 Sep 2002 19:12:56 -0400 (EDT)
Message-ID: <3D939357.FD5E0FA7@cisco.com>
Date: Thu, 26 Sep 2002 19:08:07 -0400
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 
CC: "'Torrey Searle'" , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A6418D@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 6220
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: 

Adam,

I appologize - I have allowed a bit of confusion to creep into this discussion between collections in general, and presence collections. Torrey seems to be interested in presence collections, and so he is proposing a modification to PIDF, or a special use of PIDF, to represent the collection as a whole in the initial response to a subscription.

But as currently being discussed, the collection needs to work for any kind of event. (But only one type of event at a time with templates.) This puts different constraints on the problem. There must be a way to define a valid form of initial response without knowing anything about the content type for the members of the collection.

More below.

	Paul

Adam Roach wrote:
> 
> > This suggestion might also address one issue I had. When you
> > first establish the subscription, or refresh it, or do a
> > one-time poll for status, the event mechanism requires that a
> > single notification be returned immediately, containing the
> > current state of the resource (in this case the contact
> > list). This is hard to do if the only notifications are
> > relays of notifications from individual members of the collection.
> 
> RFC 3265 requires a NOTIFY. That NOTIFY isn't required to contain
> correct state information, just well-formatted state information.

I read the requirement as a bit stronger than that. From 3.1.6.2:

   Upon successfully accepting or refreshing a subscription, notifiers
   MUST send a NOTIFY message immediately to communicate the current
   resource state to the subscriber.  This NOTIFY message is sent on the
   same dialog as created by the SUBSCRIBE response.  If the resource
   has no meaningful state at the time that the SUBSCRIBE message is
   processed, this NOTIFY message MAY contain an empty or neutral body.

Here I think we have to assume the "resource" is the collection, and that "communicate the current resource state" means "communicate the FULL resource state". Sending the state of one, or a subset, of the members of the collection is not the same thing as communicating the current resource state. Nor is it an empty or neutral body. So far there isn't any neutral body that would apply to a collection, except an empty body.

The above assumes that the subscribe is immediately accepted. It would also be possible to treat this case as falling under the following from 3.1.6.1:

   If the notifier cannot immediately create the subscription (e.g., it
   needs to wait for user input for authorization, or is acting for
   another node which is not currently reachable), or wishes to mask
   authorization policy, it will return a "202 Accepted" response.  This
   response indicates that the request has been received and understood,
   but does not necessarily imply that the subscription has been
   authorized yet.

This could be without a body I think, so it would technically comply. Subsequently, notifications with the state of individual members might be delivered. But this wouldn't be useful in a polling mode.

So, the way I read the current proposal and 3256, the only real option for the initial response is an empty body.

> 
> > This idea would begin to solve that problem. But other
> > problems remain. For instance there is then still no way to
> > poll for the current state of everything in the collection.
> 
> I'm willing to accept that as a limitation of the mechanism. Polling
> is usually too heavy on network resources to warrant deployment.

Yes, if it is done repeatedly. But certainly there are cases where it is appropriate, such as single-shot use. Maybe this is an acceptable limitation for collections. I'm not sure.

> 
> > Also, the kind of response you are describing doesn't seem to
> > fit within the current definition of PIDF.
> 
> It wouldn't *be* PIDF. It would be whatever the collection
> {package,template} defines. My vote would be for mime multipart.

That comment only made sense in the context of Torrey's message, which is specific to presence collections.

In general, I thought the proposal under discussion used the same content type collection.foo at is used for foo. The trouble with that is that it can in general only represent the status of a single foo, not a collection of foo, and so doesn't fulfill the requirements of 3265.

> 
> > Without some kind of change I don't see how to make a
> > collection conform to all the rules of an event package.
> 
> Odd. I don't see any barriers.

Well, maybe only small barriers. Or maybe I misunderstand what the current proposal is. I think you can make this work in one of the following ways:

1) content type for collection.foo is same as for foo. The initial response for a subscription to content.foo is always without any body. (Assuming that is the same as an empty body.) Subsequently, status for members of the collection is returned in distinct notifications when it becomes available.

2) content type for collection.foo is always mime multipart plus the content type for foo. The initial response can be a multipart with exactly one part for every member if that can be returned promptly. If not it would have to be an empty body rather than returning state for a subset of members. If there happens to only be one member in the collection, it could be returned without the multipart wrapper. Subsequently, status for members of the collection can be returned independently, or grouped in a multipart wrapper.

3) Instead of returning empty bodies as above, return a body containing the definition of the collection. (This will probably need to be defined as a mime type so it can be defined anyway.) Subsequent notifications could conform to 1 or 2 depending on whether subscriber supports multipart.

4) change 3265, relaxing the requirement that the initial notification in response to a subscribe communicate the (full) current state of the resource. This could possibly take the form of a parameter to the subscription indicating that it is ok to omit the initial full status in favor of some kind of partial status.

I personally have a preference for (4), because I see other cases where requiring full status (for instance in refreshes) is burdensome. But (3) is also appealing.

	Paul

From Amihay_Fuxbruner@icomverse.com  Mon Sep 30 08:47:31 2002
Received: from il-tlv-smtpout2.icomverse.com (ns4.comverse.com [192.118.49.3])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00981
	for ; Mon, 30 Sep 2002 08:47:26 -0400 (EDT)
Received: from il-tlv-mbdg1.comverse.com (il-tlv-mbdg1.comverse.com [10.116.200.32])
	by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g8UCnjt30402
	for ; Mon, 30 Sep 2002 15:49:45 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55)
	id ; Mon, 30 Sep 2002 15:47:21 +0300
Message-ID: <32B823C1CD4FD5119C0D0002A560F78E079BC413@ismail3.comverse.com>
From: Fuxbruner Amihay 
To: simple@mailman.dynamicsoft.com
Cc: Isaac Dudy 
Date: Mon, 30 Sep 2002 15:47:20 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2687F.83E0D862"
Content-Length: 1091
Subject: [Simple] PUBLISH headers
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: 

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_01C2687F.83E0D862
Content-Type: text/plain;
	charset="windows-1255"

Hi all,

Is there any BNF for PUBLISH headers: PType, PStream & PState ?

Thanks

Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse

------_=_NextPart_001_01C2687F.83E0D862
Content-Type: text/html;
	charset="windows-1255"






PUBLISH headers




Hi all,




Is there any BNF for PUBLISH headers: PType, PStream & PState ?




Thanks




Amihay Fuxbruner

System Engineering - Signaling R&D

Comverse





------_=_NextPart_001_01C2687F.83E0D862--

From rohan@cisco.com  Mon Sep 30 12:23:23 2002
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01670
	for ; Mon, 30 Sep 2002 12:23:22 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8UGNGaW029625;
	Mon, 30 Sep 2002 09:23:17 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with ESMTP id ABA10122;
	Mon, 30 Sep 2002 09:21:19 -0700 (PDT)
Date: Mon, 30 Sep 2002 09:24:46 -0700
Subject: Re: [Simple] The way forward in data manipulation work
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: 
To: Markus.Isomaki@nokia.com
From: Rohan Mahy 
In-Reply-To: 
Message-Id: <22997942-D491-11D6-8705-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Length: 3691
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: 

Hi Markus,

Not everyone is going to immediately have the same conclusion about 
SOAP.  In order to avoid the syntax wars, I suggest that we focus on 
the semantics of the kind of RPC mechanism we will need. Once we have 
debated the semantics, we can then have the syntax discussion.  Folks 
can then propose alternate SOAP and non-SOAP syntax that conveys the 
agreed-upon semantics.

Also, as I said at the mic in Yokohama, I'm not convinced that we need 
a SIP BIND method. Let's make sure we have a good semantic description 
of the binding relationship between SIP and data before we cast a 
mechanism on stone.

thanks,
-rohan


On Wednesday, September 25, 2002, at 06:49 AM, Markus.Isomaki@nokia.com 
wrote:

> Hi,
>
> I think this would be a good time to see how to go forward with the 
> charter items related to data manipulation.
>
> I believe Jonathan is planning to update the Data Manipulation 
> Requirements draft  focusing on two 
> issues: 1. List management, and 2. Authrozation policy management. In 
> Yokohama the concensus was to take this draft as basis for WG 
> requirements, so maybe the next version could be taken as a WG draft. 
> It is also a good proposal to limit that draft to purely requirements, 
> leaving the "model" in Chapter 4 out of scope. Maybe then it would be 
> easiear to agree on the draft.
>
> However, some kind of model/framework draft (similar to what is being 
> done in conferencing) is also needed, and eventually it is essential 
> to agree on what protocols to use. Based on usage guidelines SIP does 
> not seem to meet the requirements. The current PUBLISH proposal is too 
> simplistic to be useful in many cases. Instead, some kind of more 
> flexible RPC mechanism with some support to synchronization seems to 
> be the best choise.
>
> My proposal is thus:
> 1. Use SOAP/WSDL for data manipulation. In the first phase a 
> definition is needed only for list and auth. policy management, but 
> the framework does not need to limit to this.
> 2. Use SIP Events in a same fashion as "Message Waiting Indicator" 
> draft to convey notifications about state changes in the managed 
> objects. A collection package could be used for optimization purposes. 
> This spec could still leave the actual synchronization update 
> mechanism open, but I can imagine SyncML and others could potentially 
> be usable there.
> 3. Take SIP BIND as a default mechanism to make binding between sip: 
> URIs and SOAP http: URIs.
>
> In my opinion the framework doc. should define the terminology, have a 
> few nice ascii-drawings and describe the model and the actors within 
> points 1-3 above. Also, it should tell how to specify management 
> interfaces for specific objects, and how to achieve the 
> synchronization. In addition more specific documents would be needed 
> for "list management", "authorization policy management" and 
> "synchronization event package".
>
> I think we could have the first version of such framework draft could 
> be ready for the next IETF Atlanta meeting, and discussed there. Then 
> it could be updated and work on more specific drafts could start.
>
> But before starting anything like this, I would like to get people's 
> opinion about the technical part, and of course chairs' opinion about 
> the process. I'm sure there are plenty of other approaches, but I 
> haven't heard any proposals so far. In any case, some kind of design 
> team around this matter might be a good idea.
>
> Regards,
> 	Markus
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple


From seancolson@yahoo.com  Mon Sep 30 13:43:15 2002
Received: from web20702.mail.yahoo.com (web20702.mail.yahoo.com [216.136.226.175])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA01913
	for ; Mon, 30 Sep 2002 13:43:14 -0400 (EDT)
Message-ID: <20020930174312.46005.qmail@web20702.mail.yahoo.com>
Received: from [207.46.137.9] by web20702.mail.yahoo.com via HTTP; Mon, 30 Sep 2002 10:43:12 PDT
Date: Mon, 30 Sep 2002 10:43:12 -0700 (PDT)
From: Sean Olson 
Subject: Re: [Simple] The way forward in data manipulation work
To: Rohan Mahy , Markus.Isomaki@nokia.com
Cc: simple@mailman.dynamicsoft.com
In-Reply-To: <22997942-D491-11D6-8705-0003938AF740@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 4632
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: 

I would also like to see some consideration
of the impacts of binding SIP to HTTP. I'm not
at all convinced that BIND is the way to go
for this. 

Assuming we want an RPC mechanism
for this task (a big assumption), what is the
requirement for correlating the data manipulation
mechanism with SIP? Is this not implied by the
data being manipulated?

/sean

--- Rohan Mahy  wrote:
> Hi Markus,
> 
> Not everyone is going to immediately have the same
> conclusion about 
> SOAP.  In order to avoid the syntax wars, I suggest
> that we focus on 
> the semantics of the kind of RPC mechanism we will
> need. Once we have 
> debated the semantics, we can then have the syntax
> discussion.  Folks 
> can then propose alternate SOAP and non-SOAP syntax
> that conveys the 
> agreed-upon semantics.
> 
> Also, as I said at the mic in Yokohama, I'm not
> convinced that we need 
> a SIP BIND method. Let's make sure we have a good
> semantic description 
> of the binding relationship between SIP and data
> before we cast a 
> mechanism on stone.
> 
> thanks,
> -rohan
> 
> 
> On Wednesday, September 25, 2002, at 06:49 AM,
> Markus.Isomaki@nokia.com 
> wrote:
> 
> > Hi,
> >
> > I think this would be a good time to see how to go
> forward with the 
> > charter items related to data manipulation.
> >
> > I believe Jonathan is planning to update the Data
> Manipulation 
> > Requirements draft
>  focusing on two 
> > issues: 1. List management, and 2. Authrozation
> policy management. In 
> > Yokohama the concensus was to take this draft as
> basis for WG 
> > requirements, so maybe the next version could be
> taken as a WG draft. 
> > It is also a good proposal to limit that draft to
> purely requirements, 
> > leaving the "model" in Chapter 4 out of scope.
> Maybe then it would be 
> > easiear to agree on the draft.
> >
> > However, some kind of model/framework draft
> (similar to what is being 
> > done in conferencing) is also needed, and
> eventually it is essential 
> > to agree on what protocols to use. Based on usage
> guidelines SIP does 
> > not seem to meet the requirements. The current
> PUBLISH proposal is too 
> > simplistic to be useful in many cases. Instead,
> some kind of more 
> > flexible RPC mechanism with some support to
> synchronization seems to 
> > be the best choise.
> >
> > My proposal is thus:
> > 1. Use SOAP/WSDL for data manipulation. In the
> first phase a 
> > definition is needed only for list and auth.
> policy management, but 
> > the framework does not need to limit to this.
> > 2. Use SIP Events in a same fashion as "Message
> Waiting Indicator" 
> > draft to convey notifications about state changes
> in the managed 
> > objects. A collection package could be used for
> optimization purposes. 
> > This spec could still leave the actual
> synchronization update 
> > mechanism open, but I can imagine SyncML and
> others could potentially 
> > be usable there.
> > 3. Take SIP BIND as a default mechanism to make
> binding between sip: 
> > URIs and SOAP http: URIs.
> >
> > In my opinion the framework doc. should define the
> terminology, have a 
> > few nice ascii-drawings and describe the model and
> the actors within 
> > points 1-3 above. Also, it should tell how to
> specify management 
> > interfaces for specific objects, and how to
> achieve the 
> > synchronization. In addition more specific
> documents would be needed 
> > for "list management", "authorization policy
> management" and 
> > "synchronization event package".
> >
> > I think we could have the first version of such
> framework draft could 
> > be ready for the next IETF Atlanta meeting, and
> discussed there. Then 
> > it could be updated and work on more specific
> drafts could start.
> >
> > But before starting anything like this, I would
> like to get people's 
> > opinion about the technical part, and of course
> chairs' opinion about 
> > the process. I'm sure there are plenty of other
> approaches, but I 
> > haven't heard any proposals so far. In any case,
> some kind of design 
> > team around this matter might be a good idea.
> >
> > Regards,
> > 	Markus
> > _______________________________________________
> > 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


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

From hgs@cs.columbia.edu  Mon Sep 30 14:04:11 2002
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 OAA01985
	for ; Mon, 30 Sep 2002 14:04:11 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g8UI3wBf022190;
	Mon, 30 Sep 2002 14:03:58 -0400 (EDT)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g8UI3uWV027302
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Mon, 30 Sep 2002 14:03:57 -0400 (EDT)
Message-ID: <3D9891EC.4070908@cs.columbia.edu>
Date: Mon, 30 Sep 2002 14:03:24 -0400
From: Henning Schulzrinne 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2a) Gecko/20020910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sean Olson 
CC: Rohan Mahy , Markus.Isomaki@nokia.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] The way forward in data manipulation work
References: <20020930174312.46005.qmail@web20702.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 767
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: 

We have discussed this before, but I still fail to see how you can, in 
general, deduce from a SIP URL what the corresponding non-SIP URL is. In 
many cases, you will have other means to establish the binding (e.g., 
one could consider the various *-Info headers an example of such a 
binding), but these means tend to be within a dialog or for a particular 
request.

Sean Olson wrote:
> I would also like to see some consideration
> of the impacts of binding SIP to HTTP. I'm not
> at all convinced that BIND is the way to go
> for this. 
> 
> Assuming we want an RPC mechanism
> for this task (a big assumption), what is the
> requirement for correlating the data manipulation
> mechanism with SIP? Is this not implied by the
> data being manipulated?
> 
> /sean


From Pekka.Pessi@nokia.com  Mon Sep 30 14:26:59 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02085
	for ; Mon, 30 Sep 2002 14:26:58 -0400 (EDT)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g8UIRZF01699
	for ; Mon, 30 Sep 2002 21:27:35 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 30 Sep 2002 21:17:59 +0300
Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 30 Sep 2002 21:17:59 +0300
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 VAA02255;
	Mon, 30 Sep 2002 21:17:58 +0300 (EETDST)
Received: (from ppessi@localhost)
	by agni.research.nokia.com (8.11.6/8.11.2) id g8UIHLB08436;
	Mon, 30 Sep 2002 21:17:22 +0300
To: Seonman Kim 
Cc: 
Subject: Re: [Simple] Error when sending NOTIFY to MSN messenger (RTC)
References: <01eb01c264e5$aba9b730$400015ac@skim>
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: <01eb01c264e5$aba9b730$400015ac@skim>
Date: 30 Sep 2002 21:17:20 +0300
Message-ID: 
Lines: 13
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 30 Sep 2002 18:17:59.0218 (UTC) FILETIME=[B4D36920:01C268AD]
Content-Length: 403
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: 

Seonman Kim  writes:
>And if someone knows the format of  content body for NOTIFY message used
>Windows RTC, please let me know.

	They use a malformed (or embraced & extended, if you like it
	that way) version of xpidf.

	You can easily find out their presence format by sending a
	SUBSCRIBE to a Windows Messenger, then using same shstuff when
	sending to Messenger.

					Pekka


From rohan@cisco.com  Mon Sep 30 15:30:41 2002
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02282
	for ; Mon, 30 Sep 2002 15:30:40 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8UJUTaW007985;
	Mon, 30 Sep 2002 12:30:29 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with ESMTP id ABA13994;
	Mon, 30 Sep 2002 12:28:31 -0700 (PDT)
Date: Mon, 30 Sep 2002 12:31:58 -0700
Subject: Re: [Simple] The way forward in data manipulation work
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: Sean Olson , Markus.Isomaki@nokia.com,
        simple@mailman.dynamicsoft.com
To: Henning Schulzrinne 
From: Rohan Mahy 
In-Reply-To: <3D9891EC.4070908@cs.columbia.edu>
Message-Id: <492739AA-D4AB-11D6-8705-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Length: 1161
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: 

On Monday, September 30, 2002, at 11:03 AM, Henning Schulzrinne wrote:

> We have discussed this before, but I still fail to see how you can, in 
> general,

"in general"

well, that's the disagreement. In all the specific motivating scenarios 
for SIP BIND, there has been another very reasonable way to map between 
the SIP and non-SIP URIs. I'm not convinced that a general solution is 
needed (the requirements don't bear that out IMO).

thanks,
-rohan


> deduce from a SIP URL what the corresponding non-SIP URL is. In many 
> cases, you will have other means to establish the binding (e.g., one 
> could consider the various *-Info headers an example of such a 
> binding), but these means tend to be within a dialog or for a 
> particular request.
>
> Sean Olson wrote:
>> I would also like to see some consideration
>> of the impacts of binding SIP to HTTP. I'm not
>> at all convinced that BIND is the way to go
>> for this. Assuming we want an RPC mechanism
>> for this task (a big assumption), what is the
>> requirement for correlating the data manipulation
>> mechanism with SIP? Is this not implied by the
>> data being manipulated?
>> /sean
>


From Markus.Isomaki@nokia.com  Tue Oct  1 05:36:59 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08511
	for ; Tue, 1 Oct 2002 05:36:58 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g919baF23261
	for ; Tue, 1 Oct 2002 12:37:36 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 1 Oct 2002 12:21:08 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 1 Oct 2002 12:21:08 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] The way forward in data manipulation work
Date: Tue, 1 Oct 2002 12:21:07 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] The way forward in data manipulation work
Thread-Index: AcJonfp0VDXcYwNMRG+hjg2v3eABFQAid3nQ
To: 
Cc: 
X-OriginalArrivalTime: 01 Oct 2002 09:21:08.0335 (UTC) FILETIME=[E00E77F0:01C2692B]
Content-Length: 6478
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA08511
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: 

Hi Rohan,

I completely agree with you. My proposals about SOAP and BIND were there mainly to start the discussion and to show that in fact solutions already exist.

There seems to be agreement that initially we need some kind of simple list management protocol (ADD member, REMOVE member, MODIFY member), so that different lists associated to SIP services could be manipulated. I think the requirements for this are pretty well covered in the existing Data Manipulation Requirements draft. This could be built on top of whatever RPC mechanism.

Also, authorization management is chartered. In that case the scoping is more problematic. I think we could split the problem into two parts: general and service-specific. In the general part we should be able to define things like matching for list memberships or checking the day-of-time. These kind of IF-THEN-ELSE chains would lead to actual decisions, for which yes/no could be the general baseline. Services such as presence however need further service-specific semantics, for example the decision should describe what parts of the presence info to give to the requestor. Also, for conferences the decision may need to contain information about the granted rights. So, we should probably develop separate rules for presence and conferencing in addition to the general part.

Current Data Manipulation Requirements draft proposes to use a CPL-like scripting language for this, and the only manipulation operation would be a complete REWRITE. This is OK, but if possible I would like to see if it is possible to update only part of the information to save bandwidth.

So, what could we do before Atlanta? I guess the aim should be to finish the requirements draft and have a first version of "RPC-mechanism-independent" description of list management and authorization management protocols and their semantics. I understand this so that we define the commands/methods and their parameters, so that it is straightforward to map them to e.g. SOAP.

If this seems a reasonable idea, I can volunteer to write a first version of this kind of description for people to comment. 

Markus

> -----Original Message-----
> From: ext Rohan Mahy [mailto:rohan@cisco.com]
> Sent: 30 September, 2002 19:25
> To: Isomaki Markus (NRC/Helsinki)
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] The way forward in data manipulation work
> 
> 
> Hi Markus,
> 
> Not everyone is going to immediately have the same conclusion about 
> SOAP.  In order to avoid the syntax wars, I suggest that we focus on 
> the semantics of the kind of RPC mechanism we will need. Once we have 
> debated the semantics, we can then have the syntax discussion.  Folks 
> can then propose alternate SOAP and non-SOAP syntax that conveys the 
> agreed-upon semantics.
> 
> Also, as I said at the mic in Yokohama, I'm not convinced 
> that we need 
> a SIP BIND method. Let's make sure we have a good semantic 
> description 
> of the binding relationship between SIP and data before we cast a 
> mechanism on stone.
> 
> thanks,
> -rohan
> 
> 
> On Wednesday, September 25, 2002, at 06:49 AM, 
> Markus.Isomaki@nokia.com 
> wrote:
> 
> > Hi,
> >
> > I think this would be a good time to see how to go forward with the 
> > charter items related to data manipulation.
> >
> > I believe Jonathan is planning to update the Data Manipulation 
> > Requirements draft  
> focusing on two 
> > issues: 1. List management, and 2. Authrozation policy 
> management. In 
> > Yokohama the concensus was to take this draft as basis for WG 
> > requirements, so maybe the next version could be taken as a 
> WG draft. 
> > It is also a good proposal to limit that draft to purely 
> requirements, 
> > leaving the "model" in Chapter 4 out of scope. Maybe then 
> it would be 
> > easiear to agree on the draft.
> >
> > However, some kind of model/framework draft (similar to 
> what is being 
> > done in conferencing) is also needed, and eventually it is 
> essential 
> > to agree on what protocols to use. Based on usage 
> guidelines SIP does 
> > not seem to meet the requirements. The current PUBLISH 
> proposal is too 
> > simplistic to be useful in many cases. Instead, some kind of more 
> > flexible RPC mechanism with some support to synchronization 
> seems to 
> > be the best choise.
> >
> > My proposal is thus:
> > 1. Use SOAP/WSDL for data manipulation. In the first phase a 
> > definition is needed only for list and auth. policy management, but 
> > the framework does not need to limit to this.
> > 2. Use SIP Events in a same fashion as "Message Waiting Indicator" 
> > draft to convey notifications about state changes in the managed 
> > objects. A collection package could be used for 
> optimization purposes. 
> > This spec could still leave the actual synchronization update 
> > mechanism open, but I can imagine SyncML and others could 
> potentially 
> > be usable there.
> > 3. Take SIP BIND as a default mechanism to make binding 
> between sip: 
> > URIs and SOAP http: URIs.
> >
> > In my opinion the framework doc. should define the 
> terminology, have a 
> > few nice ascii-drawings and describe the model and the 
> actors within 
> > points 1-3 above. Also, it should tell how to specify management 
> > interfaces for specific objects, and how to achieve the 
> > synchronization. In addition more specific documents would 
> be needed 
> > for "list management", "authorization policy management" and 
> > "synchronization event package".
> >
> > I think we could have the first version of such framework 
> draft could 
> > be ready for the next IETF Atlanta meeting, and discussed 
> there. Then 
> > it could be updated and work on more specific drafts could start.
> >
> > But before starting anything like this, I would like to get 
> people's 
> > opinion about the technical part, and of course chairs' 
> opinion about 
> > the process. I'm sure there are plenty of other approaches, but I 
> > haven't heard any proposals so far. In any case, some kind 
> of design 
> > team around this matter might be a good idea.
> >
> > Regards,
> > 	Markus
> > _______________________________________________
> > 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 Markus.Isomaki@nokia.com  Tue Oct  1 05:38:19 2002
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 FAA08546
	for ; Tue, 1 Oct 2002 05:38:18 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g919c8503045
	for ; Tue, 1 Oct 2002 12:38:09 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 1 Oct 2002 12:36:35 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 1 Oct 2002 12:36:35 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] The way forward in data manipulation work
Date: Tue, 1 Oct 2002 12:36:34 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] The way forward in data manipulation work
Thread-Index: AcJot+IlmtAcBOSfSgqzYQmkjm49zQAdBpbQ
To: , 
Cc: , 
X-OriginalArrivalTime: 01 Oct 2002 09:36:35.0005 (UTC) FILETIME=[086516D0:01C2692E]
Content-Length: 2910
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA08546
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: 

Hi,

Here are some use cases (i.e. requirements) I have for the SIP URI - generic URI binding solution:

- A user must be able to create dynamically new service/AoR instances. These include conferences, presence lists, IM delivery lists and any other SIP services. I assume some RPC-mechanism instead of SIP will be used for the CREATE operation. So, the user must be able to discover the (generic) URI where to send such commands. I'm not sure if this is in the scope of BIND at all, since neither SIP nor the generic URI exist yet. But, I would be happy with the solution where user could query such generic URIs using her own AoR or the domain name as the starting point. (I.e. give me the addresses of the interfaces related to this AoR or this domain.). Local service discovery mechanisms won't work for this, since the user might not be (in IP-topology) in her "home" network.

- A user must be able to bind and manage objects (lists, authorization policies) related to any SIP AoR hosting an appropriate service. These services include presence (auth. policy, using matching against list memberships), presence lists (the list itself), IM delivery lists (the list itself), conferences (whatever conf. or media policies or even foor control) and any other similar ones. Binding header in BIND or OPTIONS (or INVITE) would be a sufficient solution.  

Markus
  

> -----Original Message-----
> From: ext Rohan Mahy [mailto:rohan@cisco.com]
> Sent: 30 September, 2002 22:32
> To: Henning Schulzrinne
> Cc: Sean Olson; Isomaki Markus (NRC/Helsinki);
> simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] The way forward in data manipulation work
> 
> 
> 
> On Monday, September 30, 2002, at 11:03 AM, Henning Schulzrinne wrote:
> 
> > We have discussed this before, but I still fail to see how 
> you can, in 
> > general,
> 
> "in general"
> 
> well, that's the disagreement. In all the specific motivating 
> scenarios 
> for SIP BIND, there has been another very reasonable way to 
> map between 
> the SIP and non-SIP URIs. I'm not convinced that a general 
> solution is 
> needed (the requirements don't bear that out IMO).
> 
> thanks,
> -rohan
> 
> 
> > deduce from a SIP URL what the corresponding non-SIP URL 
> is. In many 
> > cases, you will have other means to establish the binding 
> (e.g., one 
> > could consider the various *-Info headers an example of such a 
> > binding), but these means tend to be within a dialog or for a 
> > particular request.
> >
> > Sean Olson wrote:
> >> I would also like to see some consideration
> >> of the impacts of binding SIP to HTTP. I'm not
> >> at all convinced that BIND is the way to go
> >> for this. Assuming we want an RPC mechanism
> >> for this task (a big assumption), what is the
> >> requirement for correlating the data manipulation
> >> mechanism with SIP? Is this not implied by the
> >> data being manipulated?
> >> /sean
> >
> 
> 

From rohan@cisco.com  Tue Oct  1 11:06:32 2002
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09622
	for ; Tue, 1 Oct 2002 11:06:31 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g91F6VIm029562;
	Tue, 1 Oct 2002 08:06:32 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with ESMTP id ABA27658;
	Tue, 1 Oct 2002 08:04:27 -0700 (PDT)
Date: Tue, 1 Oct 2002 08:07:56 -0700
Subject: Re: [Simple] The way forward in data manipulation work
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: 
To: Markus.Isomaki@nokia.com
From: Rohan Mahy 
In-Reply-To: 
Message-Id: <90F9E6DF-D54F-11D6-8705-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Length: 7002
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: 

On Tuesday, October 1, 2002, at 02:21 AM, Markus.Isomaki@nokia.com 
wrote:

> Hi Rohan,
>
> I completely agree with you. My proposals about SOAP and BIND were 
> there mainly to start the discussion and to show that in fact 
> solutions already exist.
>
> There seems to be agreement that initially we need some kind of simple 
> list management protocol (ADD member, REMOVE member, MODIFY member), 
> so that different lists associated to SIP services could be 
> manipulated. I think the requirements for this are pretty well covered 
> in the existing Data Manipulation Requirements draft. This could be 
> built on top of whatever RPC mechanism.
>
> Also, authorization management is chartered. In that case the scoping 
> is more problematic. I think we could split the problem into two 
> parts: general and service-specific. In the general part we should be 
> able to define things like matching for list memberships or checking 
> the day-of-time. These kind of IF-THEN-ELSE chains would lead to 
> actual decisions, for which yes/no could be the general baseline. 
> Services such as presence however need further service-specific 
> semantics, for example the decision should describe what parts of the 
> presence info to give to the requestor. Also, for conferences the 
> decision may need to contain information about the granted rights. So, 
> we should probably develop separate rules for presence and 
> conferencing in addition to the general part.
>
> Current Data Manipulation Requirements draft proposes to use a 
> CPL-like scripting language for this, and the only manipulation 
> operation would be a complete REWRITE. This is OK, but if possible I 
> would like to see if it is possible to update only part of the 
> information to save bandwidth.
>
> So, what could we do before Atlanta? I guess the aim should be to 
> finish the requirements draft and have a first version of 
> "RPC-mechanism-independent" description of list management and 
> authorization management protocols and their semantics. I understand 
> this so that we define the commands/methods and their parameters, so 
> that it is straightforward to map them to e.g. SOAP.

if you want to look at another document for an example of the 
semantics-only document, check out:

draft-taylor-midcom-semantics-00.txt

> If this seems a reasonable idea, I can volunteer to write a first 
> version of this kind of description for people to comment.

fantastic.  i look forward to reading it.

thanks,
-rohan

> Markus
>
>> -----Original Message-----
>> From: ext Rohan Mahy [mailto:rohan@cisco.com]
>> Sent: 30 September, 2002 19:25
>> To: Isomaki Markus (NRC/Helsinki)
>> Cc: simple@mailman.dynamicsoft.com
>> Subject: Re: [Simple] The way forward in data manipulation work
>>
>>
>> Hi Markus,
>>
>> Not everyone is going to immediately have the same conclusion about
>> SOAP.  In order to avoid the syntax wars, I suggest that we focus on
>> the semantics of the kind of RPC mechanism we will need. Once we have
>> debated the semantics, we can then have the syntax discussion.  Folks
>> can then propose alternate SOAP and non-SOAP syntax that conveys the
>> agreed-upon semantics.
>>
>> Also, as I said at the mic in Yokohama, I'm not convinced
>> that we need
>> a SIP BIND method. Let's make sure we have a good semantic
>> description
>> of the binding relationship between SIP and data before we cast a
>> mechanism on stone.
>>
>> thanks,
>> -rohan
>>
>>
>> On Wednesday, September 25, 2002, at 06:49 AM,
>> Markus.Isomaki@nokia.com
>> wrote:
>>
>>> Hi,
>>>
>>> I think this would be a good time to see how to go forward with the
>>> charter items related to data manipulation.
>>>
>>> I believe Jonathan is planning to update the Data Manipulation
>>> Requirements draft 
>> focusing on two
>>> issues: 1. List management, and 2. Authrozation policy
>> management. In
>>> Yokohama the concensus was to take this draft as basis for WG
>>> requirements, so maybe the next version could be taken as a
>> WG draft.
>>> It is also a good proposal to limit that draft to purely
>> requirements,
>>> leaving the "model" in Chapter 4 out of scope. Maybe then
>> it would be
>>> easiear to agree on the draft.
>>>
>>> However, some kind of model/framework draft (similar to
>> what is being
>>> done in conferencing) is also needed, and eventually it is
>> essential
>>> to agree on what protocols to use. Based on usage
>> guidelines SIP does
>>> not seem to meet the requirements. The current PUBLISH
>> proposal is too
>>> simplistic to be useful in many cases. Instead, some kind of more
>>> flexible RPC mechanism with some support to synchronization
>> seems to
>>> be the best choise.
>>>
>>> My proposal is thus:
>>> 1. Use SOAP/WSDL for data manipulation. In the first phase a
>>> definition is needed only for list and auth. policy management, but
>>> the framework does not need to limit to this.
>>> 2. Use SIP Events in a same fashion as "Message Waiting Indicator"
>>> draft to convey notifications about state changes in the managed
>>> objects. A collection package could be used for
>> optimization purposes.
>>> This spec could still leave the actual synchronization update
>>> mechanism open, but I can imagine SyncML and others could
>> potentially
>>> be usable there.
>>> 3. Take SIP BIND as a default mechanism to make binding
>> between sip:
>>> URIs and SOAP http: URIs.
>>>
>>> In my opinion the framework doc. should define the
>> terminology, have a
>>> few nice ascii-drawings and describe the model and the
>> actors within
>>> points 1-3 above. Also, it should tell how to specify management
>>> interfaces for specific objects, and how to achieve the
>>> synchronization. In addition more specific documents would
>> be needed
>>> for "list management", "authorization policy management" and
>>> "synchronization event package".
>>>
>>> I think we could have the first version of such framework
>> draft could
>>> be ready for the next IETF Atlanta meeting, and discussed
>> there. Then
>>> it could be updated and work on more specific drafts could start.
>>>
>>> But before starting anything like this, I would like to get
>> people's
>>> opinion about the technical part, and of course chairs'
>> opinion about
>>> the process. I'm sure there are plenty of other approaches, but I
>>> haven't heard any proposals so far. In any case, some kind
>> of design
>>> team around this matter might be a good idea.
>>>
>>> Regards,
>>> 	Markus
>>> _______________________________________________
>>> 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 seonman@funtv.com  Tue Oct  1 17:30:22 2002
Received: from hop.funtv.com (hop.funtv.com [206.19.100.98])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10723
	for ; Tue, 1 Oct 2002 17:30:21 -0400 (EDT)
Received: from skim (sns.funtv.com [206.19.96.100])
	by hop.funtv.com (8.8.8+Sun/8.8.8) with SMTP id OAA10018;
	Tue, 1 Oct 2002 14:30:22 -0700 (PDT)
Message-ID: <008601c26991$e0196410$400015ac@skim>
From: "Seonman Kim" 
To: 
Cc: "Seonman Kim" 
Date: Tue, 1 Oct 2002 14:31:16 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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
Content-Length: 12297
Subject: [Simple] MESSAGE with MSN Messenger
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: 

Hi,
First of all, I would like to thank you all who replied to my former
question on NOTIFY with MSN messenger.
With your helps, I could successfully use Messenger using SUBSCRIBE and
NOTIFY.

Now, I have another problem, and it is MESSAGE request with MSN messenger.
I tested to send IM messages using the messenger, and I found the IM in
Messenger behaves differently from SIMPLE specification.
The followings are what I found with MSN messenger when sending IM.

- The first MESSAGE request creates a dialog with Record-Route header. The
subsequent MESSAGE request uses Route header field within the same dialog
and incremented CSeq number.
- When a user typing characters, a INFO request message is sent within the
same dialog. INFO message contains XML body that indicates the user is
typing.
- When a user close the window, BYE message is sent to the counterpart
within the same dialog.

I attach the SIP messages generated during the IM session.

Even with these messages traffic, the callee (recipient) messenger did not
show anything (did not show IM notification, windows, at all.), even if it
answered 200 OK responses for every MESSAGE, INFO, and BYE message. It was
really weird.
I have no idea why the messenger didn't show anything, and I am just
suspicious that MSN messenger's Communication Services Options was not
properly implemented as designed.

If anyone knows about this problem, please let me know. It would be a great
help.

One more question: does anybody know what "msgr" tag means in Content-Type
header field in MESSAGE request?

Thanks,
Seonman
--- SIP messages ---------
[Messenger A (seonman) to Proxy at 206.xxx.xxx.203]
MESSAGE sip:smkim320@206.xxx.xxx.203 SIP/2.0
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967
From: "seonman"
;tag=4f21c593-6bbf-494d-bbf4-b689f25d1edb
To: 
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 1 MESSAGE
Contact: 
User-Agent: Windows RTC/1.0
Content-Type: text/plain;
charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQ
BhAHQAOgAgAEYATgA9AE0AaQBjAHIAbwBzAG8AZgB0ACUAMgAwAFMAYQBuAHMAJQAyADAAUwBlAH
IAa
QBmADsAIABFAEYAPQA7ACAAQwBPAD0AMAA7ACAAQwBTAD0AMAA7ACAAUABGAD0AMgAyAA0ACgANA
AoA
Content-Length: 2

Hi
------------
[Proxy to Messenger B (smkim320) at 192.168.1.12]
MESSAGE sip:192.168.1.12:13085;transport=tcp SIP/2.0
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bK15c8f59bcda0cd8b4d357144186e027e.4
Via: SIP/2.0/UDP
206.xxx.xxx.203:5060;branch=z9hG4bK9248414244a5bb33e17ab36fbe55da12.2
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
To: 
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 1 MESSAGE
Max-Forwards: 69
Record-Route:
,
Contact: 
User-Agent: Windows RTC/1.0
Content-Type:
text/plain;charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQB
hAHQAOgAgAEYATgA9AE0AaQBjAHIAbwBzAG8AZgB0ACUAMgAwAFMAYQBuAHMAJQAyADAAUwBlAHI
AaQ
BmADsAIABFAEYAPQA7ACAAQwBPAD0AMAA7ACAAQwBTAD0AMAA7ACAAUABGAD0AMgAyAA0ACgANAA
oA
Content-Length: 2

Hi
----------
[Messenger B to Proxy]
SIP/2.0 200 OK
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bK15c8f59bcda0cd8b4d357144186e027e.4
Via: SIP/2.0/UDP
206.xxx.xxx.203:5060;branch=z9hG4bK9248414244a5bb33e17ab36fbe55da12.2
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 1 MESSAGE
Record-Route: 
Record-Route: 
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0
------
[Proxy to Messenger A]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 1 MESSAGE
Record-Route:
,
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0
----
[Messenger A to Proxy]
INFO sip:smkim320@206.xxx.xxx.203:5060 SIP/2.0
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967
From: "seonman"
;tag=4f21c593-6bbf-494d-bbf4-b689f25d1edb
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 2 INFO
Route: 
Route: 
Contact: 
User-Agent: Windows RTC/1.0
Content-Type: application/xml
Content-Length: 96

  

-----
[Proxy to Message B]
INFO sip:192.168.1.12:13085;transport=tcp SIP/2.0
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bK358edf072c6ede295aec9bd448769303.4
Via: SIP/2.0/UDP
206.xxx.xxx.203:5060;branch=z9hG4bK179906ba2110173b588bb618634708c2.2
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 2 INFO
Max-Forwards: 69
Contact: 
User-Agent: Windows RTC/1.0
Content-Type: application/xml
Content-Length: 96

  

--------------------
[Messenger B to Proxy]
SIP/2.0 200 OK
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bK358edf072c6ede295aec9bd448769303.4
Via: SIP/2.0/UDP
206.xxx.xxx.203:5060;branch=z9hG4bK179906ba2110173b588bb618634708c2.2
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 2 INFO
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0
--------------
[Proxy to Messenger A]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 2 INFO
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0
-----
[Messenger A to Proxy]
MESSAGE sip:smkim320@206.xxx.xxx.203:5060 SIP/2.0
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967
From: "seonman"
;tag=4f21c593-6bbf-494d-bbf4-b689f25d1edb
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 4 MESSAGE
Route: 
Route: 
Contact: 
User-Agent: Windows RTC/1.0
Content-Type: text/plain;
charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQ
BhAHQAOgAgAEYATgA9AE0AaQBjAHIAbwBzAG8AZgB0ACUAMgAwAFMAYQBuAHMAJQAyADAAUwBlAH
IAa
QBmADsAIABFAEYAPQA7ACAAQwBPAD0AMAA7ACAAQwBTAD0AMAA7ACAAUABGAD0AMgAyAA0ACgANA
AoA
Content-Length: 4

Hi2.
----
[Proxy to Messenger B]
MESSAGE sip:192.168.1.12:13085;transport=tcp SIP/2.0^M
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bKb7fede42ac653625717eadd49859075e.4
Via: SIP/2.0/UDP
206.xxx.xxx.203:5060;branch=z9hG4bKd43a1aaa4b390cbf1e47f6f867ed6b10.2
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 4 MESSAGE
Max-Forwards: 69
Contact: 
User-Agent: Windows RTC/1.0
Content-Type:
text/plain;charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQB
hAHQAOgAgAEYATgA9AE0AaQBjAHIAbwBzAG8AZgB0ACUAMgAwAFMAYQBuAHMAJQAyADAAUwBlAHI
AaQ
BmADsAIABFAEYAPQA7ACAAQwBPAD0AMAA7ACAAQwBTAD0AMAA7ACAAUABGAD0AMgAyAA0ACgANAA
oA
Content-Length: 4

Hi2.
----------
[Messenger B to Proxy]
SIP/2.0 200 OK
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bKb7fede42ac653625717eadd49859075e.4
Via: SIP/2.0/UDP
206.xxx.xxx.203:5060;branch=z9hG4bKd43a1aaa4b390cbf1e47f6f867ed6b10.2
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 4 MESSAGE
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0
---------
[Proxy to Messenger A]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 4 MESSAGE
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0
----
[Messenger A to Proxy]
BYE sip:smkim320@206.xxx.xxx.203:5060 SIP/2.0
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967
From: "seonman"
;tag=4f21c593-6bbf-494d-bbf4-b689f25d1edb
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 5 BYE
Route: 
Route: 
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0
----
[Proxy to Messenger B]
BYE sip:192.168.1.12:13085;transport=tcp SIP/2.0
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bK731a0b999804a0b32c65648301642612.4
Via: SIP/2.0/UDP
206.xxx.xxx.203:5060;branch=z9hG4bK45d61c916a23a7d209ce7d9f0148af6a.2
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 5 BYE
Max-Forwards: 69
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0
-----
[Messenger B to Proxy]
SIP/2.0 200 OK
Via: SIP/2.0/TCP
206.xxx.xxx.203:5060;branch=z9hG4bK731a0b999804a0b32c6564830162612.4
Via: SIP/2.0/UDP
206.xxx.xxx.203:5060;branch=z9hG4bK45d61c916a23a7d209ce7d9f0148af6a.2
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 5 BYE
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0
----
[Proxy to Messenger A]
SIP/2.0 200 OK
Via: SIP/2.0/TCP 172.xxx.xxx.64:6967;rport;received=206.xxx.xxx.100
To: ;tag=e860ba65-60e3-436b-8f2f-787a657e4ddd
From:
"seonman";tag=4f21c593-6bbf-494d-bbf4-b689f25d1
edb
Call-ID: da2ee193-6da0-4d01-8a8f-76be52a0e3fe@172.xxx.xxx.64
CSeq: 5 BYE
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0



From rohan@cisco.com  Fri Oct  4 20:21:30 2002
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23372
	for ; Fri, 4 Oct 2002 20:21:30 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g950LNIm006744;
	Fri, 4 Oct 2002 17:21:23 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with ESMTP id ABB06256;
	Fri, 4 Oct 2002 17:19:18 -0700 (PDT)
Date: Fri, 4 Oct 2002 17:22:51 -0700
Subject: Re: [Simple] collection template
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: Ben Campbell ,
        Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
To: Adam Roach 
From: Rohan Mahy 
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64150@DYN-TX-EXCH-001.dynamicsoft.com>
Message-Id: <95624906-D7F8-11D6-B998-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Length: 1291
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: 

I found this culling through half-finished replies....


On Monday, September 16, 2002, at 11:02 AM, Adam Roach wrote:

>> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
>>
>> If I susbscrbe to "collection"
>> without an event scope, I now have to expect NOTIFY requests for
>> arbitrary events.
>
> Unless the proposal is something of an overhaul of event processing
> (which I advise against), your NOTIFY messages would be NOTIFY for
> the event "collection" under Jonathan's proposal.
>
> I've got to admit, I share Ben and Sean's reservations about this
> approach.

I am likewise concerned by treating collections as a package.  The 
multiple-event type especially bothers me.  I'm with Adam and Sean.  A 
collection template would clearly work and give us the semantics we 
need.  The package approach is dancing on a slippery slope.  As I add 
to this 2 weeks later I will compare this to the combined 
REGISTER/SUBSCRIBE discussion in SIP.  The arguments for doing a 
package instead of a template are sort of vague and squishy.  Let's 
please just do the template instead.  It will work.

thanks,
-rohan


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


From jdrosen@dynamicsoft.com  Wed Oct  9 16:13:08 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10144
	for ; Wed, 9 Oct 2002 16:13:08 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.47.242])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g99KD9YH007873;
	Wed, 9 Oct 2002 16:13:09 -0400 (EDT)
Message-ID: <3DA48DD4.6010904@dynamicsoft.com>
Date: Wed, 09 Oct 2002 16:13:08 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] The way forward in data manipulation work
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3131
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: 

inline.

Markus.Isomaki@nokia.com wrote:
  > Hi,
  >
  > I think this would be a good time to see how to go forward with the
  > charter items related to data manipulation.
  >
  > I believe Jonathan is planning to update the Data Manipulation
  > Requirements draft  focusing on two
  > issues: 1. List management, and 2. Authrozation policy management. In
  > Yokohama the concensus was to take this draft as basis for WG
  > requirements, so maybe the next version could be taken as a WG draft.

Yes, that is the plan.

  > It is also a good proposal to limit that draft to purely
  > requirements, leaving the "model" in Chapter 4 out of scope. Maybe
  > then it would be easiear to agree on the draft.

Agreed.

  >
  > However, some kind of model/framework draft (similar to what is being
  > done in conferencing) is also needed, and eventually it is essential
  > to agree on what protocols to use.

Definitely. Requirements only make sense in the context of a framework.
The data manipulations draft has some frameworks in there. I have turned
it into a single framework, put up front, followed by a section for
requirements on each of the two components (buddy list manipulation and
authorization manipulation). I also added a terminology section.

  > My proposal is thus: 1. Use SOAP/WSDL for data manipulation. In the
  > first phase a definition is needed only for list and auth. policy
  > management, but the framework does not need to limit to this. 2. Use
  > SIP Events in a same fashion as "Message Waiting Indicator" draft to
  > convey notifications about state changes in the managed objects. A
  > collection package could be used for optimization purposes. This spec
  > could still leave the actual synchronization update mechanism open,
  > but I can imagine SyncML and others could potentially be usable
  > there. 3. Take SIP BIND as a default mechanism to make binding
  > between sip: URIs and SOAP http: URIs.

I agree completely on points 1 and 2, although as others have pointed
out, the scope of the document would not include making statements on
the specific protocol. Rather, it should defined the requiremetns for
the protocols.


  > I think we could have the first version of such framework draft could
  > be ready for the next IETF Atlanta meeting, and discussed there. Then
  > it could be updated and work on more specific drafts could start.

In fact, I have just submitted an updated version of the requirements 
document, as a SIMPLE work item. Until it appears in the archives, you 
can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-data-req-00.txt

there is now much more details on authorization requirements, based on 
comments and suggestions made on the 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



From nsyracus@cnri.reston.va.us  Fri Oct 11 07:30:29 2002
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 HAA16895
	for ; Fri, 11 Oct 2002 07:30:29 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16833;
	Fri, 11 Oct 2002 07:28:21 -0400 (EDT)
Message-Id: <200210111128.HAA16833@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
Date: Fri, 11 Oct 2002 07:28:21 -0400
Content-Length: 2931
Subject: [Simple] I-D ACTION:draft-ietf-simple-data-req-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: Requirements for Manipulation of Data Elements in 
                          SIMPLE Systems
	Author(s)	: J. Rosenberg, M. Isomaki
	Filename	: draft-ietf-simple-data-req-00.txt
	Pages		: 16
	Date		: 2002-10-10
	
In an instant messaging and presence application, it is frequently
necessary for the user to configure a number of pieces of
information. Users will need to manipulate their presentity list,
adding and removing presentities, and manipulate their authorization
lists, which specify the set of users that can subscribe to their
presence. In this document, we provide a framework and requirements
for such data manipulations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-data-req-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-data-req-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:	<2002-10-10140905.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-data-req-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-data-req-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-10-10140905.I-D@ietf.org>

--OtherAccess--

--NextPart--



From rainer.janssen@de.ibm.com  Fri Oct 11 14:57:10 2002
Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18328
	for ; Fri, 11 Oct 2002 14:57:10 -0400 (EDT)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g9BIv41u033954
	for ; Fri, 11 Oct 2002 20:57:08 +0200
Received: from d12ml013.de.ibm.com (d12ml013_cs0 [9.165.223.39])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9BIv3hW078586
	for ; Fri, 11 Oct 2002 20:57:03 +0200
From: "Rainer R Janssen" 
To: "simple" 
Message-ID: 
Date: Fri, 11 Oct 2002 20:57:02 +0200
X-MIMETrack: Serialize by Router on D12ML013/12/M/IBM(Release 5.0.9a |January 7, 2002) at
 11/10/2002 20:57:03
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 150
Subject: [Simple] Rainer R Janssen/Germany/IBM is out of the office.
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: 

I will be out of the office starting  11.10.2002 and will not return until
18.10.2002.

In urgent cases you can reach me on my mobil +49.172.8377043


From kns10@cs.columbia.edu  Tue Oct 15 18:17:43 2002
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 SAA06685
	for ; Tue, 15 Oct 2002 18:17:43 -0400 (EDT)
Received: from sbb.cs.columbia.edu (sbb.cs.columbia.edu [128.59.19.193])
	by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9FMHgm6001903
	for ; Tue, 15 Oct 2002 18:17:43 -0400 (EDT)
Received: from sbb.cs.columbia.edu (localhost [127.0.0.1])
	by sbb.cs.columbia.edu (8.12.6/8.12.1) with ESMTP id g9FMHg9l017786;
	Tue, 15 Oct 2002 18:17:42 -0400 (EDT)
Received: from localhost (kns10@localhost)
	by sbb.cs.columbia.edu (8.12.6/8.12.6/Submit) with ESMTP id g9FMHfnp017783;
	Tue, 15 Oct 2002 18:17:42 -0400 (EDT)
X-Authentication-Warning: sbb.cs.columbia.edu: kns10 owned process doing -bs
Date: Tue, 15 Oct 2002 18:17:41 -0400 (EDT)
From: Kundan Singh 
To: 
cc: Xiaotao Wu 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1591
Subject: [Simple] sip proxy/registrar as presence agent
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: 

Hi

I have a question on implementation of PA co-located with proxy/registrar
server.

If the server wants to support both the following kinds of scenarios:
- acts as a presence agent that sends NOTIFY to subscriber (if approved)
when user phone REGISTERs. This subscription can be managed (approved,
rejected) from the web interface, for example.
- allow end-points (colocated with presence agents) to REGISTER. This
end-point acts as a presence agent and manages its own buddy list for IM
and call.

Suppose subscriber S, SUBSCRIBEs to the server P for target user,
but the target user phone/endpoint is not yet REGISTERed.
and the subscriber is not yet approved by the target user.
P sends back "202 Pending".

Now target user's phone/endpoint R (colocated with PA) REGISTERs with P.
How can the server P inform the target endpoint R that the user S was/is
interested in subscribing to R.
(1) If the server P sends new SUBSCRIBE to R (like a UAC) then it can not
do digest authentication because P may not know the password for user S.
And R may not know how to authenticate P (not in buddy list).
(2) S will refresh SUBSCRIBE after sometime, that will get proxied to R
also, and it can work. But this will happen only once every one hour
("Expires:" header).
(3) The target user will have different identifiers: bob@server for
PA colocated with proxy, and bob@endpoint_address for PA colocated with
endpoint. And S will have to SUBSCRIBE to both independently.

What is the right approach so that R can know that S had sent SUBSCRIBE
and then R can start sending NOTIFY to S.

Thanks.


From jdrosen@dynamicsoft.com  Wed Oct 16 00:45:36 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07870
	for ; Wed, 16 Oct 2002 00:45:36 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.79])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9G4jIYH011417;
	Wed, 16 Oct 2002 00:45:21 -0400 (EDT)
Message-ID: <3DACEEDD.1090709@dynamicsoft.com>
Date: Wed, 16 Oct 2002 00:45:17 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kundan Singh 
CC: simple@mailman.dynamicsoft.com, Xiaotao Wu 
Subject: Re: [Simple] sip proxy/registrar as presence agent
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2638
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: 

The right solution is for the server to terminate the subscription, with 
a specific reason that informs the client that it should re-subscribe. 
In particular, the Subscription-State header in the NOTIFY would look like:

NOTIFY sip:subscriber@example.com SIP/2.0
Subscription-State: terminated;reason=deactivated

the client would genreate a brand new SUBSCRIBE (not on the same 
dialog), which the server can then proxy.

-Jonathan R.


Kundan Singh wrote:
> Hi
> 
> I have a question on implementation of PA co-located with proxy/registrar
> server.
> 
> If the server wants to support both the following kinds of scenarios:
> - acts as a presence agent that sends NOTIFY to subscriber (if approved)
> when user phone REGISTERs. This subscription can be managed (approved,
> rejected) from the web interface, for example.
> - allow end-points (colocated with presence agents) to REGISTER. This
> end-point acts as a presence agent and manages its own buddy list for IM
> and call.
> 
> Suppose subscriber S, SUBSCRIBEs to the server P for target user,
> but the target user phone/endpoint is not yet REGISTERed.
> and the subscriber is not yet approved by the target user.
> P sends back "202 Pending".
> 
> Now target user's phone/endpoint R (colocated with PA) REGISTERs with P.
> How can the server P inform the target endpoint R that the user S was/is
> interested in subscribing to R.
> (1) If the server P sends new SUBSCRIBE to R (like a UAC) then it can not
> do digest authentication because P may not know the password for user S.
> And R may not know how to authenticate P (not in buddy list).
> (2) S will refresh SUBSCRIBE after sometime, that will get proxied to R
> also, and it can work. But this will happen only once every one hour
> ("Expires:" header).
> (3) The target user will have different identifiers: bob@server for
> PA colocated with proxy, and bob@endpoint_address for PA colocated with
> endpoint. And S will have to SUBSCRIBE to both independently.
> 
> What is the right approach so that R can know that S had sent SUBSCRIBE
> and then R can start sending NOTIFY to S.
> 
> Thanks.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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


From pkyzivat@cisco.com  Thu Oct 17 10:19:26 2002
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 KAA13824
	for ; Thu, 17 Oct 2002 10:19:26 -0400 (EDT)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9HEJZFh007491
	for ; Thu, 17 Oct 2002 10:19:36 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAS95775;
	Thu, 17 Oct 2002 10:24:16 -0400 (EDT)
Message-ID: <3DAEC6ED.DD57CEA0@cisco.com>
Date: Thu, 17 Oct 2002 10:19:25 -0400
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: Simple 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2710
Subject: [Simple] Requirements for SIP Capabilities in PIDF
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: 

The following draft is now available on the server.

Several of us believe that when using presence with sip in general (as opposed to using it solely for IM), more information is required for the presence client to operate effectively. This is a start at defining requirements for what added information is required and how it should relate to other sip usage.

I believe this is the proper wg in which to discuss this.

	Thanks,
	Paul

-------- Original Message --------
Subject: I-D ACTION:draft-kyzivat-simple-prescaps-reqts-00.txt
Date: Thu, 17 Oct 2002 07:33:26 -0400
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
To: IETF-Announce: ;

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for SIP Capabilities in PIDF
	Author(s)	: P. Kyzivat
	Filename	: draft-kyzivat-simple-prescaps-reqts-00.txt
	Pages		: 7
	Date		: 2002-10-16
	
This document sets forth requirements for the definition of elements 
for representation of SIP specific features within the Presence 
Information Data Format (PIDF), as well as for guidelines on how to 
use these new elements with PIDF to represent the capabilities of a 
SIP User Agent Server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kyzivat-simple-prescaps-reqts-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-kyzivat-simple-prescaps-reqts-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-kyzivat-simple-prescaps-reqts-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.

From Markus.Isomaki@nokia.com  Thu Oct 17 12:18:09 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14236
	for ; Thu, 17 Oct 2002 12:18:09 -0400 (EDT)
From: Markus.Isomaki@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9HGI9H12470
	for ; Thu, 17 Oct 2002 19:18:09 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 17 Oct 2002 19:18:06 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 17 Oct 2002 19:18:05 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] The way forward in data manipulation work - list manipulation
Date: Thu, 17 Oct 2002 19:18:05 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] The way forward in data manipulation work
Thread-Index: AcJwUEImQy0sjX+ES1KlVovfQwoBDgFpPO1w
To: 
Cc: 
X-OriginalArrivalTime: 17 Oct 2002 16:18:05.0732 (UTC) FILETIME=[C6324E40:01C275F8]
Content-Length: 5673
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA14236
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: 

Hi,

I think one of the main questions about the data manipulation requirements is how to deal with lists. The choises made at this point may have a surprising impact on the usability aspects, as explained below.

In practice I think there are two scenarios:
1. Each application instance has its own dedicated list(s). For example presence lists and chat conference access lists are always separate entities in their respective servers. 
2. It is possible to share the same list stored somewhere in the "network" (i.e. represented by some URI) by multiple applications. If the list is changed, it is reflected in each application that the list is currently bound to.

These options don't change much the requirements for the list manipulation protocol. As seen in the current requirements draft, the list manipulation reqs for presence collection and presence authorization are basically identical.

From user's point of view there is a major difference. It would be nice to be able to use the same list for multiple purposes. In that case it would be better to have the list stored only once, so that there would be only one list to manipulate.

The biggest obstacle I see in this kind of generic list model is the application-specific URI schemes, in practice pres: and im:. If im: URI is added to some list and the user then wants to bind that list to a presence collection, there is a miss-match. On the other hand, lists comprising only sip: URIs would be usable accross different SIP services.  

I understand that some of this discusion is implementation related. I guess what I'm trying to say that I'd like the final solution be such that the general list concept would not be excluded. As technical requirement that should be quite easy to formulate, i.e. some form of indirection/binding between lists and SIP URIs is needed. If this is agreeable, I can propose some text to the draft.

Markus

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 09 October, 2002 23:13
> To: Isomaki Markus (NRC/Helsinki)
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] The way forward in data manipulation work
> 
> 
> inline.
> 
> Markus.Isomaki@nokia.com wrote:
>   > Hi,
>   >
>   > I think this would be a good time to see how to go 
> forward with the
>   > charter items related to data manipulation.
>   >
>   > I believe Jonathan is planning to update the Data Manipulation
>   > Requirements draft  
> focusing on two
>   > issues: 1. List management, and 2. Authrozation policy 
> management. In
>   > Yokohama the concensus was to take this draft as basis for WG
>   > requirements, so maybe the next version could be taken as 
> a WG draft.
> 
> Yes, that is the plan.
> 
>   > It is also a good proposal to limit that draft to purely
>   > requirements, leaving the "model" in Chapter 4 out of scope. Maybe
>   > then it would be easiear to agree on the draft.
> 
> Agreed.
> 
>   >
>   > However, some kind of model/framework draft (similar to 
> what is being
>   > done in conferencing) is also needed, and eventually it 
> is essential
>   > to agree on what protocols to use.
> 
> Definitely. Requirements only make sense in the context of a 
> framework.
> The data manipulations draft has some frameworks in there. I 
> have turned
> it into a single framework, put up front, followed by a section for
> requirements on each of the two components (buddy list 
> manipulation and
> authorization manipulation). I also added a terminology section.
> 
>   > My proposal is thus: 1. Use SOAP/WSDL for data 
> manipulation. In the
>   > first phase a definition is needed only for list and auth. policy
>   > management, but the framework does not need to limit to 
> this. 2. Use
>   > SIP Events in a same fashion as "Message Waiting 
> Indicator" draft to
>   > convey notifications about state changes in the managed objects. A
>   > collection package could be used for optimization 
> purposes. This spec
>   > could still leave the actual synchronization update 
> mechanism open,
>   > but I can imagine SyncML and others could potentially be usable
>   > there. 3. Take SIP BIND as a default mechanism to make binding
>   > between sip: URIs and SOAP http: URIs.
> 
> I agree completely on points 1 and 2, although as others have pointed
> out, the scope of the document would not include making statements on
> the specific protocol. Rather, it should defined the requiremetns for
> the protocols.
> 
> 
>   > I think we could have the first version of such framework 
> draft could
>   > be ready for the next IETF Atlanta meeting, and discussed 
> there. Then
>   > it could be updated and work on more specific drafts could start.
> 
> In fact, I have just submitted an updated version of the requirements 
> document, as a SIMPLE work item. Until it appears in the 
> archives, you 
> can pick it up at:
> 
> http://www.jdrosen.net/papers/draft-ietf-simple-data-req-00.txt
> 
> there is now much more details on authorization requirements, 
> based on 
> comments and suggestions made on the 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 xiaotaow@cs.columbia.edu  Thu Oct 17 14:09:48 2002
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 OAA14566
	for ; Thu, 17 Oct 2002 14:09:48 -0400 (EDT)
Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27])
	by cs.columbia.edu (8.12.6/8.12.6) with ESMTP id g9HI9Mm7027750;
	Thu, 17 Oct 2002 14:09:37 -0400 (EDT)
Date: Thu, 17 Oct 2002 14:09:22 -0400 (EDT)
From: Xiaotao Wu 
To: 
cc: Kundan Singh 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1527
Subject: [Simple] What if a PUA crashed, but the registration of the PUA still valid
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: 

Hi,

For a Presence Server (PA colocated with proxy), if the PUA which the
Presence Server proxys the SUBSCRIBE to crashed, but the registration of
the PUA is still valid (since PUA crashed, the PUA did not unregister
itself), for an incoming SUBSCRIBE, what's the status should be in the
notification from the Presence Server?

  PUA (a)     Presence Server         PUA (b)

    |               |                 |
    |               +<-- REGISTER ----+
    |               |                 |
    +--- SUBSCRIBE->+                 |
    |               |                 |
    |               +---- SUBSCRIBE -->
    |               |                 |
    |               +<---- 200 OK ----+
    |               |                 |
    +<-- 200 OK ----+                 |
    |               |               \ | /
    |               |                \|/
    |               |                 X  CRASH!!!
    | (subscription |                /|\
    |  expired)     |               / | \
    |               |                 |
    +-- SUBSCRIBE ->+                 |
    |               |                 |
    |               +--- SUBSCRIBE -->+
    |               |                 |
    |               |                 |
    |               |    (timeout)    |
    |               |                 |
    |               |                 |
    |               |                 |
    |     202???    |                 |
    +<--- ??? ------+                 |
    |     200???    |                 |


-Xiaotao





From jdrosen@dynamicsoft.com  Mon Oct 21 23:38:21 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03668
	for ; Mon, 21 Oct 2002 23:38:20 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.84])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9M3cFYH015419;
	Mon, 21 Oct 2002 23:38:16 -0400 (EDT)
Message-ID: <3DB4C826.7040603@dynamicsoft.com>
Date: Mon, 21 Oct 2002 23:38:14 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Xiaotao Wu 
CC: simple@mailman.dynamicsoft.com, Kundan Singh 
Subject: Re: [Simple] What if a PUA crashed, but the registration of the PUA
 still valid
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2597
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: 

inline.

Xiaotao Wu wrote:
> Hi,
> 
> For a Presence Server (PA colocated with proxy), if the PUA which the
> Presence Server proxys the SUBSCRIBE to crashed, but the registration of
> the PUA is still valid (since PUA crashed, the PUA did not unregister
> itself), for an incoming SUBSCRIBE, what's the status should be in the
> notification from the Presence Server?

There is no notification. The SUBSCRIBE refresh from the client will 
result in a 408 from the presence server (this is normal proxy 
behavior). That, based on 3261, will cause the client to terminate the 
dialog. So, if it still wants the subscription, it has to subscribe with 
a brand new request. This reaches the presence server, which can now 
accept the subscription, migrating it from the PUA back to the server.

-Jonathan R.

> 
>   PUA (a)     Presence Server         PUA (b)
> 
>     |               |                 |
>     |               +<-- REGISTER ----+
>     |               |                 |
>     +--- SUBSCRIBE->+                 |
>     |               |                 |
>     |               +---- SUBSCRIBE -->
>     |               |                 |
>     |               +<---- 200 OK ----+
>     |               |                 |
>     +<-- 200 OK ----+                 |
>     |               |               \ | /
>     |               |                \|/
>     |               |                 X  CRASH!!!
>     | (subscription |                /|\
>     |  expired)     |               / | \
>     |               |                 |
>     +-- SUBSCRIBE ->+                 |
>     |               |                 |
>     |               +--- SUBSCRIBE -->+
>     |               |                 |
>     |               |                 |
>     |               |    (timeout)    |
>     |               |                 |
>     |               |                 |
>     |               |                 |
>     |     202???    |                 |
>     +<--- ??? ------+                 |
>     |     200???    |                 |
> 
> 
> -Xiaotao
> 
> 
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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


From Vesa.Torvinen@lmf.ericsson.se  Thu Oct 24 02:12:04 2002
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12299
	for ; Thu, 24 Oct 2002 02:12:04 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9O6C2KV005003;
	Thu, 24 Oct 2002 08:12:02 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id ; Thu, 24 Oct 2002 08:12:02 +0200
Message-ID: 
From: "Vesa Torvinen (LMF)" 
To: "'Markus.Isomaki@nokia.com'" ,
        jdrosen@dynamicsoft.com
Cc: simple@mailman.dynamicsoft.com
Date: Thu, 24 Oct 2002 08:11:59 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1688
Subject: [Simple] Comment on draft-ietf-simple-data-req-00
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: 

Hi, 

I have been wondering if the presence authorization policy 
should include a fourth piece (in addition to acceptance, 
notification and content policies), i.e. the security policy. 
As an end-user, I could imagine setting an authorizatin 
policy saying that the confidentiality of all notifications 
should be protected, for example. The other filterin criteria, 
notification frequencies and the contents of notifications 
could still be valid, however, the notification would not be 
delivered to the watcher if encryption was not available. 

I can also imagine a scenario in which my Presence Agent has 
no trust relationship with a particular watcher, and can not 
authenticate the watcher. In this case, I as an end-user might 
be willing to set this trust relationship, e.g. by defining a 
subscription specific HTTP Digest password for that watcher, 
and by distributing the password to the watcher using some 
other communication channel (e.g. phone or face-to-face 
contact). 

Maybe the security policy could look something like this: 

---------

Security Policy: The component of presence authorization policy 
that determines the minimum security requirements for subscriptions 
and notifications. 

---------

Security Policy Requirements 

REQ 1: It MUST be possible for the user to determine the minimum 
security functions to be used with subscriptions and notifications. 

REQ 2: It SHOULD be possible for the user to bind the watcher 
authorization to a particular authentication function and credential. 

-----------

But maybe you have already discussed this issue and decided 
something else? (Checked the mail archive but did not find 
anything...) 

Vesa 

From gobbo.max@libero.it  Thu Oct 24 06:34:24 2002
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 GAA13083
	for ; Thu, 24 Oct 2002 06:34:24 -0400 (EDT)
From: gobbo.max@libero.it
Received: from libero.it (193.70.192.42) by smtp2.libero.it (6.5.028)
        id 3DA310EF0028050C for simple@mailman.dynamicsoft.com; Thu, 24 Oct 2002 12:34:23 +0200
Date: Thu, 24 Oct 2002 12:34:23 +0200
Message-Id: 
MIME-Version: 1.0
X-Sensitivity: 3
Content-Type: text/plain; charset=iso-8859-1
To: "=?iso-8859-1?Q?simple?=" 
X-XaM3-API-Version: 3.2 R24 (B46)
X-type: 0
X-SenderIP: 193.205.164.87
Content-Length: 182
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA13083
Subject: [Simple] =?iso-8859-1?Q?Question?=
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: 

 Hi,

 I'm an Italian student working on the SCTP.

 I would try to work on this argument: 

 -Instant messaging on SCTP. 

 Is there someone who is working on this arguments?



 


From rohan@cisco.com  Thu Oct 24 20:36:54 2002
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15538
	for ; Thu, 24 Oct 2002 20:36:54 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9P0agPP019762;
	Thu, 24 Oct 2002 17:36:42 -0700 (PDT)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ABE87674;
	Thu, 24 Oct 2002 17:34:12 -0700 (PDT)
Date: Thu, 24 Oct 2002 17:37:07 -0700
Subject: Re: [Simple] Comment on draft-ietf-simple-data-req-00
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: "'Markus.Isomaki@nokia.com'" ,
        jdrosen@dynamicsoft.com, simple@mailman.dynamicsoft.com
To: "Vesa Torvinen (LMF)" 
From: Rohan Mahy 
In-Reply-To: 
Message-Id: 
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Length: 2001
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: 

On Wednesday, October 23, 2002, at 11:11 PM, Vesa Torvinen (LMF) wrote:

> Hi,
>
> I have been wondering if the presence authorization policy
> should include a fourth piece (in addition to acceptance,
> notification and content policies), i.e. the security policy.
> As an end-user, I could imagine setting an authorizatin
> policy saying that the confidentiality of all notifications
> should be protected, for example. The other filterin criteria,
> notification frequencies and the contents of notifications
> could still be valid, however, the notification would not be
> delivered to the watcher if encryption was not available.
>
> I can also imagine a scenario in which my Presence Agent has
> no trust relationship with a particular watcher, and can not
> authenticate the watcher. In this case, I as an end-user might
> be willing to set this trust relationship, e.g. by defining a
> subscription specific HTTP Digest password for that watcher,
> and by distributing the password to the watcher using some
> other communication channel (e.g. phone or face-to-face
> contact).

self-signed cert?

thx,
-r

> Maybe the security policy could look something like this:
>
> ---------
>
> Security Policy: The component of presence authorization policy
> that determines the minimum security requirements for subscriptions
> and notifications.
>
> ---------
>
> Security Policy Requirements
>
> REQ 1: It MUST be possible for the user to determine the minimum
> security functions to be used with subscriptions and notifications.
>
> REQ 2: It SHOULD be possible for the user to bind the watcher
> authorization to a particular authentication function and credential.
>
> -----------
>
> But maybe you have already discussed this issue and decided
> something else? (Checked the mail archive but did not find
> anything...)
>
> Vesa
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple


From jdrosen@dynamicsoft.com  Fri Oct 25 03:25:05 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16776
	for ; Fri, 25 Oct 2002 03:25:05 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.60])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9P7P5YH017970;
	Fri, 25 Oct 2002 03:25:06 -0400 (EDT)
Message-ID: <3DB8F1D0.7050906@dynamicsoft.com>
Date: Fri, 25 Oct 2002 03:25:04 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: gobbo.max@libero.it
CC: simple 
Subject: Re: [Simple] Question
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1084
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: 

None of the current proposals use SCTP for IM. However, I happen to 
think its a good idea. Since SCTP is message oriented, it provides 
framing for you, which is good for IM, especially when used with 
persistent connections. You could also send each IM on a separate 
stream, avoiding HOL blocking of a small IM behind a large one.

-Jonathan R.

gobbo.max@libero.it wrote:
>  Hi,
>  I'm an Italian student working on the SCTP.
>  I would try to work on this argument: 
>  -Instant messaging on SCTP. 
>  Is there someone who is working on this arguments?
> 
>  
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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


From jdrosen@dynamicsoft.com  Fri Oct 25 03:42:49 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16858
	for ; Fri, 25 Oct 2002 03:42:49 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.60])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9P7glYH017977;
	Fri, 25 Oct 2002 03:42:48 -0400 (EDT)
Message-ID: <3DB8F5F6.3010309@dynamicsoft.com>
Date: Fri, 25 Oct 2002 03:42:46 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Vesa Torvinen (LMF)" 
CC: "'Markus.Isomaki@nokia.com'" ,
        simple@mailman.dynamicsoft.com
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3420
Subject: [Simple] Re: Comment on draft-ietf-simple-data-req-00
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: 

I think that this is generally a good idea. Some comments below.


Vesa Torvinen (LMF) wrote:
> Hi, 
> 
> I have been wondering if the presence authorization policy 
> should include a fourth piece (in addition to acceptance, 
> notification and content policies), i.e. the security policy. 
> As an end-user, I could imagine setting an authorizatin 
> policy saying that the confidentiality of all notifications 
> should be protected, for example. The other filterin criteria, 
> notification frequencies and the contents of notifications 
> could still be valid, however, the notification would not be 
> delivered to the watcher if encryption was not available. 

I agree with this requirement, but think its really two additional 
requirements in the existing categories. What you are saying is that 
there is an acceptance policy that says "dont accept unless I can 
encrypt towards this used", and a content policy which says that the 
notifications are to be encrypted.

Now, determining that you can encrypt notifications towards a subscriber 
is a bit hard. I see a few ways:

   * the SUBSCRIBE was received using sips
   * the SUBSCRIBE was authenticated using S/MIME, and included a cert 
for the subscriber
   * a cert for the subscriber exists in the presence server

Similarly, encrypting notifications can occur with sips or with smime.

> 
> I can also imagine a scenario in which my Presence Agent has 
> no trust relationship with a particular watcher, and can not 
> authenticate the watcher. In this case, I as an end-user might 
> be willing to set this trust relationship, e.g. by defining a 
> subscription specific HTTP Digest password for that watcher, 
> and by distributing the password to the watcher using some 
> other communication channel (e.g. phone or face-to-face 
> contact). 

Thats possible, although its better if you act as your own CA and hand 
these folks certifications. Much more secure.


> 
> Maybe the security policy could look something like this: 
> 
> ---------
> 
> Security Policy: The component of presence authorization policy 
> that determines the minimum security requirements for subscriptions 
> and notifications. 

As I propose above, I think there are security aspects to the existing 
components, and I would rather distribute your requirements to those.

> 
> ---------
> 
> Security Policy Requirements 
> 
> REQ 1: It MUST be possible for the user to determine the minimum 
> security functions to be used with subscriptions and notifications. 

I would state as:

* it MUST be possible for a user to specify that a subscription should 
not be accepted unless the subscriber is authenticated with a specific 
mechanism (smime, digest, etc.)

* it MUST be possible for a user to specify that a subscription should 
not be accepted unless the notifications to that subscriber can be encrypted

* it must be possible for a user to specify that a notification should 
be encrypted


Now, whether you want to use this protocol to upload digest shared 
secrets, for example, I am not sure...

-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


From Vesa.Torvinen@lmf.ericsson.se  Fri Oct 25 05:23:57 2002
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17165
	for ; Fri, 25 Oct 2002 05:23:57 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9P9NqQ2017604;
	Fri, 25 Oct 2002 11:23:55 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id ; Fri, 25 Oct 2002 11:23:52 +0200
Message-ID: 
From: "Vesa Torvinen (LMF)" 
To: "'Jonathan Rosenberg'" 
Cc: "'Markus.Isomaki@nokia.com'" ,
        simple@mailman.dynamicsoft.com
Date: Fri, 25 Oct 2002 11:23:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 4960
Subject: [Simple] RE: Comment on draft-ietf-simple-data-req-00
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: 

Jonathan, 

In general, I like your version of requirements. Some further comments (with 3GPP'ish hat on): 

1) About the digest passwords: 

There are system architectures in which it is not very likely that Watcher and Presence Server will have direct trust relationship. It is not very likely either that S/MIME is available. My opinion is, that in this kind of context, the procedure for letting the presentity to upload digest passwords would be efficient and cheap solution. 

I am not sure if this issue is a general requirement for this protocol... or even if this is a good idea at all. I would love to hear more opinions about it! 

2) About the encryption: 

Again, there are architectures which may follow some kind of 'transitive trust model', and in which S/MIME or SIPS are not necessarily available. Still, the trust model assumes that it can guarantee confidentiality if requested. In practice, this can be done using IPsec security gateways within the network, and IPsec over the more vulnerable part of the network (i.e. the air interface). In other words, there might be other ways (in addition to sips or certificates) to know that confidentiality can be guaranteed. 

I would talk about 'confidentiality' instead of 'encryption' in the requirements. 

Vesa  

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: 25. lokakuuta 2002 10:43
To: Vesa Torvinen (LMF)
Cc: 'Markus.Isomaki@nokia.com'; simple@mailman.dynamicsoft.com
Subject: Re: Comment on draft-ietf-simple-data-req-00


I think that this is generally a good idea. Some comments below.


Vesa Torvinen (LMF) wrote:
> Hi, 
> 
> I have been wondering if the presence authorization policy 
> should include a fourth piece (in addition to acceptance, 
> notification and content policies), i.e. the security policy. 
> As an end-user, I could imagine setting an authorizatin 
> policy saying that the confidentiality of all notifications 
> should be protected, for example. The other filterin criteria, 
> notification frequencies and the contents of notifications 
> could still be valid, however, the notification would not be 
> delivered to the watcher if encryption was not available. 

I agree with this requirement, but think its really two additional 
requirements in the existing categories. What you are saying is that 
there is an acceptance policy that says "dont accept unless I can 
encrypt towards this used", and a content policy which says that the 
notifications are to be encrypted.

Now, determining that you can encrypt notifications towards a subscriber 
is a bit hard. I see a few ways:

   * the SUBSCRIBE was received using sips
   * the SUBSCRIBE was authenticated using S/MIME, and included a cert 
for the subscriber
   * a cert for the subscriber exists in the presence server

Similarly, encrypting notifications can occur with sips or with smime.

> 
> I can also imagine a scenario in which my Presence Agent has 
> no trust relationship with a particular watcher, and can not 
> authenticate the watcher. In this case, I as an end-user might 
> be willing to set this trust relationship, e.g. by defining a 
> subscription specific HTTP Digest password for that watcher, 
> and by distributing the password to the watcher using some 
> other communication channel (e.g. phone or face-to-face 
> contact). 

Thats possible, although its better if you act as your own CA and hand 
these folks certifications. Much more secure.


> 
> Maybe the security policy could look something like this: 
> 
> ---------
> 
> Security Policy: The component of presence authorization policy 
> that determines the minimum security requirements for subscriptions 
> and notifications. 

As I propose above, I think there are security aspects to the existing 
components, and I would rather distribute your requirements to those.

> 
> ---------
> 
> Security Policy Requirements 
> 
> REQ 1: It MUST be possible for the user to determine the minimum 
> security functions to be used with subscriptions and notifications. 

I would state as:

* it MUST be possible for a user to specify that a subscription should 
not be accepted unless the subscriber is authenticated with a specific 
mechanism (smime, digest, etc.)

* it MUST be possible for a user to specify that a subscription should 
not be accepted unless the notifications to that subscriber can be encrypted

* it must be possible for a user to specify that a notification should 
be encrypted


Now, whether you want to use this protocol to upload digest shared 
secrets, for example, I am not sure...

-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

From nsyracus@cnri.reston.va.us  Fri Oct 25 07:30:49 2002
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 HAA17542
	for ; Fri, 25 Oct 2002 07:30:49 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20076;
	Fri, 25 Oct 2002 07:28:29 -0400 (EDT)
Message-Id: <200210251128.HAA20076@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
Date: Fri, 25 Oct 2002 07:28:28 -0400
Content-Length: 2510
Subject: [Simple] I-D ACTION:draft-niemi-simple-im-wireless-reqs-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for Instant Messaging in 3GPP Wireless 
                          Systems
	Author(s)	: A. Niemi
	Filename	: draft-niemi-simple-im-wireless-reqs-00.txt
	Pages		: 9
	Date		: 2002-10-24
	
This document lists the requirements specific to 3GPP wireless
Instant Messaging systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-niemi-simple-im-wireless-reqs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-niemi-simple-im-wireless-reqs-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-10-24142231.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-niemi-simple-im-wireless-reqs-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-niemi-simple-im-wireless-reqs-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-10-24142231.I-D@ietf.org>

--OtherAccess--

--NextPart--



From mhammer@cisco.com  Fri Oct 25 10:31:41 2002
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 KAA18081
	for ; Fri, 25 Oct 2002 10:31:41 -0400 (EDT)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9PEVfo0003160;
	Fri, 25 Oct 2002 10:31:41 -0400 (EDT)
Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-91.cisco.com [161.44.87.91])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ABG97559;
	Fri, 25 Oct 2002 10:21:17 -0400 (EDT)
Message-Id: <4.3.2.7.2.20021025102623.00b3def0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 25 Oct 2002 10:31:25 -0400
To: "Vesa Torvinen (LMF)" 
From: Michael Hammer 
Subject: Re: [Simple] RE: Comment on draft-ietf-simple-data-req-00
Cc: "'Jonathan Rosenberg'" ,
        "'Markus.Isomaki@nokia.com'" ,
        simple@mailman.dynamicsoft.com
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Length: 5599
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: 

Inline.

At 11:23 AM 10/25/2002 +0200, Vesa Torvinen (LMF) wrote:
>Jonathan,
>
>In general, I like your version of requirements. Some further comments 
>(with 3GPP'ish hat on):
>
>1) About the digest passwords:
>
>There are system architectures in which it is not very likely that Watcher 
>and Presence Server will have direct trust relationship. It is not very 
>likely either that S/MIME is available. My opinion is, that in this kind 
>of context, the procedure for letting the presentity to upload digest 
>passwords would be efficient and cheap solution.

By solution, do you mean to say that this will establish a chain of trust 
between the two?  Is the goal here to assure that notifications are 
integrity or confidentiality protected, or is there any intent to be 
assured that you really know to whom notifications are being sent?

MH


>I am not sure if this issue is a general requirement for this protocol... 
>or even if this is a good idea at all. I would love to hear more opinions 
>about it!
>
>2) About the encryption:
>
>Again, there are architectures which may follow some kind of 'transitive 
>trust model', and in which S/MIME or SIPS are not necessarily available. 
>Still, the trust model assumes that it can guarantee confidentiality if 
>requested. In practice, this can be done using IPsec security gateways 
>within the network, and IPsec over the more vulnerable part of the network 
>(i.e. the air interface). In other words, there might be other ways (in 
>addition to sips or certificates) to know that confidentiality can be 
>guaranteed.
>
>I would talk about 'confidentiality' instead of 'encryption' in the 
>requirements.
>
>Vesa
>
>-----Original Message-----
>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>Sent: 25. lokakuuta 2002 10:43
>To: Vesa Torvinen (LMF)
>Cc: 'Markus.Isomaki@nokia.com'; simple@mailman.dynamicsoft.com
>Subject: Re: Comment on draft-ietf-simple-data-req-00
>
>
>I think that this is generally a good idea. Some comments below.
>
>
>Vesa Torvinen (LMF) wrote:
> > Hi,
> >
> > I have been wondering if the presence authorization policy
> > should include a fourth piece (in addition to acceptance,
> > notification and content policies), i.e. the security policy.
> > As an end-user, I could imagine setting an authorizatin
> > policy saying that the confidentiality of all notifications
> > should be protected, for example. The other filterin criteria,
> > notification frequencies and the contents of notifications
> > could still be valid, however, the notification would not be
> > delivered to the watcher if encryption was not available.
>
>I agree with this requirement, but think its really two additional
>requirements in the existing categories. What you are saying is that
>there is an acceptance policy that says "dont accept unless I can
>encrypt towards this used", and a content policy which says that the
>notifications are to be encrypted.
>
>Now, determining that you can encrypt notifications towards a subscriber
>is a bit hard. I see a few ways:
>
>    * the SUBSCRIBE was received using sips
>    * the SUBSCRIBE was authenticated using S/MIME, and included a cert
>for the subscriber
>    * a cert for the subscriber exists in the presence server
>
>Similarly, encrypting notifications can occur with sips or with smime.
>
> >
> > I can also imagine a scenario in which my Presence Agent has
> > no trust relationship with a particular watcher, and can not
> > authenticate the watcher. In this case, I as an end-user might
> > be willing to set this trust relationship, e.g. by defining a
> > subscription specific HTTP Digest password for that watcher,
> > and by distributing the password to the watcher using some
> > other communication channel (e.g. phone or face-to-face
> > contact).
>
>Thats possible, although its better if you act as your own CA and hand
>these folks certifications. Much more secure.
>
>
> >
> > Maybe the security policy could look something like this:
> >
> > ---------
> >
> > Security Policy: The component of presence authorization policy
> > that determines the minimum security requirements for subscriptions
> > and notifications.
>
>As I propose above, I think there are security aspects to the existing
>components, and I would rather distribute your requirements to those.
>
> >
> > ---------
> >
> > Security Policy Requirements
> >
> > REQ 1: It MUST be possible for the user to determine the minimum
> > security functions to be used with subscriptions and notifications.
>
>I would state as:
>
>* it MUST be possible for a user to specify that a subscription should
>not be accepted unless the subscriber is authenticated with a specific
>mechanism (smime, digest, etc.)
>
>* it MUST be possible for a user to specify that a subscription should
>not be accepted unless the notifications to that subscriber can be encrypted
>
>* it must be possible for a user to specify that a notification should
>be encrypted
>
>
>Now, whether you want to use this protocol to upload digest shared
>secrets, for example, I am not sure...
>
>-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 lachlan.brazier@siemens.com  Fri Oct 25 06:36:11 2002
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 GAA17390
	for ; Fri, 25 Oct 2002 06:36:10 -0400 (EDT)
Received: from scesie13.sie.siemens.at (forix [10.1.140.2])
	by eins.siemens.at  with ESMTP id g9PAa9U07349
	for ; Fri, 25 Oct 2002 12:36:09 +0200
Received: from vies141a.sie.siemens.at (atws15tc.sie.siemens.at [158.226.135.41])
	by scesie13.sie.siemens.at (8.12.1/8.12.1) with ESMTP id g9PAa82T005772
	for ; Fri, 25 Oct 2002 12:36:08 +0200 (MET DST)
Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19)
	id ; Fri, 25 Oct 2002 12:36:51 +0200
Message-ID: 
From: Brazier Lachlan 
To: simple@mailman.dynamicsoft.com
Date: Fri, 25 Oct 2002 12:36:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C27C12.6B068480"
Content-Length: 4782
Subject: [Simple] Accept header
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: 

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_01C27C12.6B068480
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,
sorry if this question was awnsered before. I have a question concerning the
Accept header.

RFC3261 states:

20.1 Accept

   The Accept header field follows the syntax defined in [H14.1].  The
   semantics are also identical, with the exception that if no Accept
   header field is present, the server SHOULD assume a default value of
   application/sdp.

   An empty Accept header field means that no formats are acceptable.


whereas RFC2616 (HTTP1.1) states in chapter "14.1 Accept"

....If no Accept header field is present, then it is assumed that the
   client accepts all media types. ......


Here I asume that RFC3261 counts concerning the Accept header. Is this
correct?
What's the difference between "no Accept header field" and "empty Accept
header field" ?

Which behaviour is defined in SIMPLE, as draft-ietf-simple-presence-07.txt
says, that

...All subscribers MUST support the "application/cpim-pidf+xml" presence
data format described in [5].....

Does this mean, that even when the Accept header field is empty, the
Subscriber MUST support the media type "application/cpim-pidf+xml"?
Actually I believe, a PA should send an error response containing an Accept
header field with "application/cpim-pidf+xml".
Is this correct?


Thanks
Lachlan Brazier

------_=_NextPart_001_01C27C12.6B068480
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+QWNjZXB0
IGhlYWRlcjwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPkhlbGxv
LDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+c29ycnkgaWYgdGhpcyBxdWVzdGlvbiB3YXMgYXdu
c2VyZWQgYmVmb3JlLiBJIGhhdmUgYSBxdWVzdGlvbiBjb25jZXJuaW5nIHRoZSBBY2NlcHQgaGVh
ZGVyLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPlJGQzMyNjEgc3RhdGVzOjwvRk9O
VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPjIwLjEgQWNjZXB0PC9GT05UPg0KPC9QPg0KDQo8
UD48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IFRoZSBBY2NlcHQgaGVhZGVyIGZpZWxkIGZvbGxv
d3MgdGhlIHN5bnRheCBkZWZpbmVkIGluIFtIMTQuMV0uJm5ic3A7IFRoZTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IHNlbWFudGljcyBhcmUgYWxzbyBpZGVudGljYWwsIHdp
dGggdGhlIGV4Y2VwdGlvbiB0aGF0IGlmIG5vIEFjY2VwdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jm5ic3A7Jm5ic3A7IGhlYWRlciBmaWVsZCBpcyBwcmVzZW50LCB0aGUgc2VydmVyIFNIT1VM
RCBhc3N1bWUgYSBkZWZhdWx0IHZhbHVlIG9mPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJz
cDsmbmJzcDsgYXBwbGljYXRpb24vc2RwLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y
PiZuYnNwOyZuYnNwOyBBbiBlbXB0eSBBY2NlcHQgaGVhZGVyIGZpZWxkIG1lYW5zIHRoYXQgbm8g
Zm9ybWF0cyBhcmUgYWNjZXB0YWJsZS48L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJ
WkU9Mj53aGVyZWFzIFJGQzI2MTYgKEhUVFAxLjEpIHN0YXRlcyBpbiBjaGFwdGVyICZxdW90OzE0
LjEgQWNjZXB0JnF1b3Q7PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Li4uLklmIG5v
IEFjY2VwdCBoZWFkZXIgZmllbGQgaXMgcHJlc2VudCwgdGhlbiBpdCBpcyBhc3N1bWVkIHRoYXQg
dGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgY2xpZW50IGFjY2VwdHMg
YWxsIG1lZGlhIHR5cGVzLiAuLi4uLi48L0ZPTlQ+DQo8L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJ
WkU9Mj5IZXJlIEkgYXN1bWUgdGhhdCBSRkMzMjYxIGNvdW50cyBjb25jZXJuaW5nIHRoZSBBY2Nl
cHQgaGVhZGVyLiBJcyB0aGlzIGNvcnJlY3Q/PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5XaGF0
J3MgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAmcXVvdDtubyBBY2NlcHQgaGVhZGVyIGZpZWxkJnF1
b3Q7IGFuZCAmcXVvdDtlbXB0eSBBY2NlcHQgaGVhZGVyIGZpZWxkJnF1b3Q7ID88L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5XaGljaCBiZWhhdmlvdXIgaXMgZGVmaW5lZCBpbiBTSU1Q
TEUsIGFzIGRyYWZ0LWlldGYtc2ltcGxlLXByZXNlbmNlLTA3LnR4dCBzYXlzLCB0aGF0PC9GT05U
Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Li4uQWxsIHN1YnNjcmliZXJzIE1VU1Qgc3VwcG9y
dCB0aGUgJnF1b3Q7YXBwbGljYXRpb24vY3BpbS1waWRmK3htbCZxdW90OyBwcmVzZW5jZSBkYXRh
IGZvcm1hdCBkZXNjcmliZWQgaW4gWzVdLi4uLi48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ
WkU9Mj5Eb2VzIHRoaXMgbWVhbiwgdGhhdCBldmVuIHdoZW4gdGhlIEFjY2VwdCBoZWFkZXIgZmll
bGQgaXMgZW1wdHksIHRoZSBTdWJzY3JpYmVyIE1VU1Qgc3VwcG9ydCB0aGUgbWVkaWEgdHlwZSAm
cXVvdDthcHBsaWNhdGlvbi9jcGltLXBpZGYreG1sJnF1b3Q7PzwvRk9OVD48L1A+DQoNCjxQPjxG
T05UIFNJWkU9Mj5BY3R1YWxseSBJIGJlbGlldmUsIGEgUEEgc2hvdWxkIHNlbmQgYW4gZXJyb3Ig
cmVzcG9uc2UgY29udGFpbmluZyBhbiBBY2NlcHQgaGVhZGVyIGZpZWxkIHdpdGggJnF1b3Q7YXBw
bGljYXRpb24vY3BpbS1waWRmK3htbCZxdW90Oy48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpF
PTI+SXMgdGhpcyBjb3JyZWN0PzwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0y
PlRoYW5rczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+TGFjaGxhbiBCcmF6aWVyPC9GT05UPg0K
PC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+

------_=_NextPart_001_01C27C12.6B068480--

From adam@dynamicsoft.com  Fri Oct 25 18:04:35 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19528
	for ; Fri, 25 Oct 2002 18:04:35 -0400 (EDT)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9PM3gFu027771
	for ; Fri, 25 Oct 2002 18:03:43 -0400 (EDT)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 25 Oct 2002 17:04:32 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A642A6@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Fri, 25 Oct 2002 17:04:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 519
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: 

[Sliding in under the wire for the -00 deadline]

An i-d describing a template event package for collections has been
submitted to the drafts editor. Until a copy appears in the archives,
you can download a copy from:

http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.txt

HTML version also available:
http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.htm
l

This work is still rather rough around the edges, but I think it gives a
good starting point for discussion.

/a

From jdrosen@dynamicsoft.com  Sun Oct 27 22:12:11 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28219
	for ; Sun, 27 Oct 2002 22:12:11 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9S3BuYH019238;
	Sun, 27 Oct 2002 22:11:56 -0500 (EST)
Message-ID: <3DBCAAFA.6070806@dynamicsoft.com>
Date: Sun, 27 Oct 2002 22:11:54 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brazier Lachlan 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Accept header
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2476
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: 


Brazier Lachlan wrote:
> Hello,
> sorry if this question was awnsered before. I have a question concerning 
> the Accept header.
> 
> RFC3261 states:
> 
> 20.1 Accept
> 
>    The Accept header field follows the syntax defined in [H14.1].  The
>    semantics are also identical, with the exception that if no Accept
>    header field is present, the server SHOULD assume a default value of
>    application/sdp.
> 
>    An empty Accept header field means that no formats are acceptable.
> 
> 
> whereas RFC2616 (HTTP1.1) states in chapter "14.1 Accept"
> 
> ....If no Accept header field is present, then it is assumed that the
>    client accepts all media types. ......
> 
> 
> Here I asume that RFC3261 counts concerning the Accept header.

Yes.

  Is this
> correct?
> What's the difference between "no Accept header field" and "empty Accept 
> header field" ?

Empty means it looks  like:

SUBSCRIBE sip:presentity@domain.com SIP/2.0
Accept:
From: sip:subscriber@domain.com
......

this means, "I don't support ANY document formats".

no accept field looks like:

SUBSCRIBE sip:presentity@domain.com SIP/2.0
From: sip:subscriber@domain.com

which means, "The accept header has a default value".

> 
> Which behaviour is defined in SIMPLE, as 
> draft-ietf-simple-presence-07.txt says, that
> 
> ...All subscribers MUST support the "application/cpim-pidf+xml" presence 
> data format described in [5].....

Now, this brings an interesting point. Since the default accept header 
field value is SDP, as bis says, it would seem that a subscriber has to 
include application/cpim-pidf+xml in an Accept header in every 
subscriber request. That needs to be corrected in the presence doc.

> 
> Does this mean, that even when the Accept header field is empty, the 
> Subscriber MUST support the media type "application/cpim-pidf+xml"?

An empty Accept header field in a SUBSCRIBE would be illegal, in 
violation of the presence spec, since it means you don't support pidf.

> 
> Actually I believe, a PA should send an error response containing an 
> Accept header field with "application/cpim-pidf+xml".

yup.

-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


From Vesa.Torvinen@lmf.ericsson.se  Mon Oct 28 04:47:32 2002
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00298
	for ; Mon, 28 Oct 2002 04:47:26 -0500 (EST)
Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9S9l6Q2028308;
	Mon, 28 Oct 2002 10:47:06 +0100 (MET)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id ; Mon, 28 Oct 2002 10:47:06 +0100
Message-ID: 
From: "Vesa Torvinen (LMF)" 
To: "'Michael Hammer'" 
Cc: "'Jonathan Rosenberg'" ,
        "'Markus.Isomaki@nokia.com'" ,
        simple@mailman.dynamicsoft.com
Subject: RE: [Simple] RE: Comment on draft-ietf-simple-data-req-00
Date: Mon, 28 Oct 2002 10:46:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 7114
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: 

Michael, 

You seem to ask me how Digest is useful in this context. 

I am thinking a model in which the authentication would take 
place with subscriptions. Integrity protection would probably 
be required to do this securely. If you can re-use the 
authenticated & integrity protected "security tunnel" (e.g. TLS) 
with notifications, you are quite safe in assuming that they 
are sent to the intended recipient. Right? 

If you have to initiate security every time you send 
notification, you may still trust on some SIP headers that 
were authenticated & protected during subscription (e.g. Contact). 
However, Digest would not server the Presence Server to know that 
the recipient is the correct one. Instead, Digest could be used by 
the Watcher to know that the messages really originate from an 
entity that knows the same passwords that was used during 
subscription. 

The confidentiality part is a different story and not really 
related to Digest. The presentity may have an interest to require 
confidentiality protection for all notifications. 

But maybe you were concerned on the semantics of these 'security 
policies' to the end-user? That the end-user would assume better 
security than it actually is? 

Vesa 

-----Original Message-----
From: Michael Hammer [mailto:mhammer@cisco.com]
Sent: 25. lokakuuta 2002 17:31
To: Vesa Torvinen (LMF)
Cc: 'Jonathan Rosenberg'; 'Markus.Isomaki@nokia.com';
simple@mailman.dynamicsoft.com
Subject: Re: [Simple] RE: Comment on draft-ietf-simple-data-req-00


Inline.

At 11:23 AM 10/25/2002 +0200, Vesa Torvinen (LMF) wrote:
>Jonathan,
>
>In general, I like your version of requirements. Some further comments 
>(with 3GPP'ish hat on):
>
>1) About the digest passwords:
>
>There are system architectures in which it is not very likely that Watcher 
>and Presence Server will have direct trust relationship. It is not very 
>likely either that S/MIME is available. My opinion is, that in this kind 
>of context, the procedure for letting the presentity to upload digest 
>passwords would be efficient and cheap solution.

By solution, do you mean to say that this will establish a chain of trust 
between the two?  Is the goal here to assure that notifications are 
integrity or confidentiality protected, or is there any intent to be 
assured that you really know to whom notifications are being sent?

MH


>I am not sure if this issue is a general requirement for this protocol... 
>or even if this is a good idea at all. I would love to hear more opinions 
>about it!
>
>2) About the encryption:
>
>Again, there are architectures which may follow some kind of 'transitive 
>trust model', and in which S/MIME or SIPS are not necessarily available. 
>Still, the trust model assumes that it can guarantee confidentiality if 
>requested. In practice, this can be done using IPsec security gateways 
>within the network, and IPsec over the more vulnerable part of the network 
>(i.e. the air interface). In other words, there might be other ways (in 
>addition to sips or certificates) to know that confidentiality can be 
>guaranteed.
>
>I would talk about 'confidentiality' instead of 'encryption' in the 
>requirements.
>
>Vesa
>
>-----Original Message-----
>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>Sent: 25. lokakuuta 2002 10:43
>To: Vesa Torvinen (LMF)
>Cc: 'Markus.Isomaki@nokia.com'; simple@mailman.dynamicsoft.com
>Subject: Re: Comment on draft-ietf-simple-data-req-00
>
>
>I think that this is generally a good idea. Some comments below.
>
>
>Vesa Torvinen (LMF) wrote:
> > Hi,
> >
> > I have been wondering if the presence authorization policy
> > should include a fourth piece (in addition to acceptance,
> > notification and content policies), i.e. the security policy.
> > As an end-user, I could imagine setting an authorizatin
> > policy saying that the confidentiality of all notifications
> > should be protected, for example. The other filterin criteria,
> > notification frequencies and the contents of notifications
> > could still be valid, however, the notification would not be
> > delivered to the watcher if encryption was not available.
>
>I agree with this requirement, but think its really two additional
>requirements in the existing categories. What you are saying is that
>there is an acceptance policy that says "dont accept unless I can
>encrypt towards this used", and a content policy which says that the
>notifications are to be encrypted.
>
>Now, determining that you can encrypt notifications towards a subscriber
>is a bit hard. I see a few ways:
>
>    * the SUBSCRIBE was received using sips
>    * the SUBSCRIBE was authenticated using S/MIME, and included a cert
>for the subscriber
>    * a cert for the subscriber exists in the presence server
>
>Similarly, encrypting notifications can occur with sips or with smime.
>
> >
> > I can also imagine a scenario in which my Presence Agent has
> > no trust relationship with a particular watcher, and can not
> > authenticate the watcher. In this case, I as an end-user might
> > be willing to set this trust relationship, e.g. by defining a
> > subscription specific HTTP Digest password for that watcher,
> > and by distributing the password to the watcher using some
> > other communication channel (e.g. phone or face-to-face
> > contact).
>
>Thats possible, although its better if you act as your own CA and hand
>these folks certifications. Much more secure.
>
>
> >
> > Maybe the security policy could look something like this:
> >
> > ---------
> >
> > Security Policy: The component of presence authorization policy
> > that determines the minimum security requirements for subscriptions
> > and notifications.
>
>As I propose above, I think there are security aspects to the existing
>components, and I would rather distribute your requirements to those.
>
> >
> > ---------
> >
> > Security Policy Requirements
> >
> > REQ 1: It MUST be possible for the user to determine the minimum
> > security functions to be used with subscriptions and notifications.
>
>I would state as:
>
>* it MUST be possible for a user to specify that a subscription should
>not be accepted unless the subscriber is authenticated with a specific
>mechanism (smime, digest, etc.)
>
>* it MUST be possible for a user to specify that a subscription should
>not be accepted unless the notifications to that subscriber can be encrypted
>
>* it must be possible for a user to specify that a notification should
>be encrypted
>
>
>Now, whether you want to use this protocol to upload digest shared
>secrets, for example, I am not sure...
>
>-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 pkyzivat@cisco.com  Mon Oct 28 11:07:24 2002
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 LAA01344
	for ; Mon, 28 Oct 2002 11:07:19 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9SG7Ii2029660
	for ; Mon, 28 Oct 2002 11:07:19 -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 AAT67537;
	Mon, 28 Oct 2002 11:11:57 -0500 (EST)
Message-ID: <3DBD60A8.B4A616F5@cisco.com>
Date: Mon, 28 Oct 2002 11:07:04 -0500
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: Simple 
References: <200210281127.GAA03058@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 239
Subject: [Simple] Re: draft-olson-simple-publish-01.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: 

I question the need for the Stream header. Its use seems entirely analogous to the use of a common Callid header in REGISTER requests. Why is it necessary to introduce a new header for PUBLISH when it wasn't necessary for REGISTER?

	Paul

From mhammer@cisco.com  Mon Oct 28 11:22:50 2002
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 LAA01396
	for ; Mon, 28 Oct 2002 11:22:45 -0500 (EST)
Received: from cia.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9SGMaPe001938;
	Mon, 28 Oct 2002 11:22:37 -0500 (EST)
Received: from mhammer-w2k01.cisco.com (hrn2-dhcp-161-44-87-91.cisco.com [161.44.87.91])
	by cia.cisco.com (Mirapoint)
	with ESMTP id ABH11651;
	Mon, 28 Oct 2002 11:12:08 -0500 (EST)
Message-Id: <4.3.2.7.2.20021028110517.03f19450@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 28 Oct 2002 11:22:17 -0500
To: "Vesa Torvinen (LMF)" 
From: Michael Hammer 
Subject: RE: [Simple] RE: Comment on draft-ietf-simple-data-req-00
Cc: "'Jonathan Rosenberg'" ,
        "'Markus.Isomaki@nokia.com'" ,
        simple@mailman.dynamicsoft.com
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Length: 10383
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: 


Vesa,



Just doing a "reality check."  From your 3rd paragraph
below, this seems to sum up what is really being
"authenticated":



You "know that the messages really originate from an 

entity that knows the same passwords that was used during 

subscription."



Most of the schemes I have seen thus far seem to provide little true
authentication of the identity asserted, unless this involves some
infrastructure and security policies that provide some confidence that
such identities correspond with the real world, i.e. could support a
contract in a court of law.  Not that this is always
necessary.  Just wanted to be precise about what is actually
occurring.



Mike Hammer







At 10:46 AM 10/28/2002 +0100, Vesa Torvinen (LMF) wrote:


Michael, 



You seem to ask me how Digest is useful in this context. 



I am thinking a model in which the authentication would take 

place with subscriptions. Integrity protection would probably 

be required to do this securely. If you can re-use the 

authenticated & integrity protected "security tunnel" (e.g.
TLS) 

with notifications, you are quite safe in assuming that they 

are sent to the intended recipient. Right? 



If you have to initiate security every time you send 

notification, you may still trust on some SIP headers that 

were authenticated & protected during subscription (e.g. Contact).


However, Digest would not server the Presence Server to know that 

the recipient is the correct one. Instead, Digest could be used by 

the Watcher to know that the messages really originate from an 

entity that knows the same passwords that was used during 

subscription. 



The confidentiality part is a different story and not really 

related to Digest. The presentity may have an interest to require 

confidentiality protection for all notifications. 



But maybe you were concerned on the semantics of these 'security 

policies' to the end-user? That the end-user would assume better 

security than it actually is? 



Vesa 



-----Original Message-----

From: Michael Hammer
[mailto:mhammer@cisco.com]

Sent: 25. lokakuuta 2002 17:31

To: Vesa Torvinen (LMF)

Cc: 'Jonathan Rosenberg'; 'Markus.Isomaki@nokia.com';

simple@mailman.dynamicsoft.com

Subject: Re: [Simple] RE: Comment on draft-ietf-simple-data-req-00





Inline.



At 11:23 AM 10/25/2002 +0200, Vesa Torvinen (LMF) wrote:

>Jonathan,

>

>In general, I like your version of requirements. Some further
comments 

>(with 3GPP'ish hat on):

>

>1) About the digest passwords:

>

>There are system architectures in which it is not very likely that
Watcher 

>and Presence Server will have direct trust relationship. It is not
very 

>likely either that S/MIME is available. My opinion is, that in this
kind 

>of context, the procedure for letting the presentity to upload digest


>passwords would be efficient and cheap solution.



By solution, do you mean to say that this will establish a chain of trust


between the two?  Is the goal here to assure that notifications are


integrity or confidentiality protected, or is there any intent to be


assured that you really know to whom notifications are being sent?



MH





>I am not sure if this issue is a general requirement for this
protocol... 

>or even if this is a good idea at all. I would love to hear more
opinions 

>about it!

>

>2) About the encryption:

>

>Again, there are architectures which may follow some kind of
'transitive 

>trust model', and in which S/MIME or SIPS are not necessarily
available. 

>Still, the trust model assumes that it can guarantee confidentiality
if 

>requested. In practice, this can be done using IPsec security
gateways 

>within the network, and IPsec over the more vulnerable part of the
network 

>(i.e. the air interface). In other words, there might be other ways
(in 

>addition to sips or certificates) to know that confidentiality can be


>guaranteed.

>

>I would talk about 'confidentiality' instead of 'encryption' in the


>requirements.

>

>Vesa

>

>-----Original Message-----

>From: Jonathan Rosenberg
[mailto:jdrosen@dynamicsoft.com]

>Sent: 25. lokakuuta 2002 10:43

>To: Vesa Torvinen (LMF)

>Cc: 'Markus.Isomaki@nokia.com'; simple@mailman.dynamicsoft.com

>Subject: Re: Comment on draft-ietf-simple-data-req-00

>

>

>I think that this is generally a good idea. Some comments=20
below.

>

>

>Vesa Torvinen (LMF) wrote:

> > Hi,

> >

> > I have been wondering if the presence authorization=20
policy

> > should include a fourth piece (in addition to acceptance,

> > notification and content policies), i.e. the security
policy.

> > As an end-user, I could imagine setting an authorizatin

> > policy saying that the confidentiality of all
notifications

> > should be protected, for example. The other filterin
criteria,

> > notification frequencies and the contents of=20
notifications

> > could still be valid, however, the notification would not
be

> > delivered to the watcher if encryption was not available.

>

>I agree with this requirement, but think its really two
additional

>requirements in the existing categories. What you are saying is
that

>there is an acceptance policy that says "dont accept unless I
can

>encrypt towards this used", and a content policy which says that
the

>notifications are to be encrypted.

>

>Now, determining that you can encrypt notifications towards a
subscriber

>is a bit hard. I see a few ways:

>

>    * the SUBSCRIBE was received using sips

>    * the SUBSCRIBE was authenticated using S/MIME,
and included a cert

>for the subscriber

>    * a cert for the subscriber exists in the presence
server

>

>Similarly, encrypting notifications can occur with sips or with
smime.

>

> >

> > I can also imagine a scenario in which my Presence Agent
has

> > no trust relationship with a particular watcher, and can
not

> > authenticate the watcher. In this case, I as an end-user
might

> > be willing to set this trust relationship, e.g. by defining
a

> > subscription specific HTTP Digest password for that
watcher,

> > and by distributing the password to the watcher using=20
some

> > other communication channel (e.g. phone or face-to-face

> > contact).

>

>Thats possible, although its better if you act as your own CA and
hand

>these folks certifications. Much more secure.

>

>

> >

> > Maybe the security policy could look something like this:

> >

> > ---------

> >

> > Security Policy: The component of presence authorization
policy

> > that determines the minimum security requirements for
subscriptions

> > and notifications.

>

>As I propose above, I think there are security aspects to the
existing

>components, and I would rather distribute your requirements to
those.

>

> >

> > ---------

> >

> > Security Policy Requirements

> >

> > REQ 1: It MUST be possible for the user to determine the
minimum

> > security functions to be used with subscriptions and
notifications.

>

>I would state as:

>

>* it MUST be possible for a user to specify that a subscription
should

>not be accepted unless the subscriber is authenticated with a
specific

>mechanism (smime, digest, etc.)

>

>* it MUST be possible for a user to specify that a subscription
should

>not be accepted unless the notifications to that subscriber can be
encrypted

>

>* it must be possible for a user to specify that a notification
should

>be encrypted

>

>

>Now, whether you want to use this protocol to upload digest
shared

>secrets, for example, I am not sure...

>

>-Jonathan R.

>

>--

>Jonathan D. Rosenberg,
Ph.D.            =
;   
72 Eagle Rock Ave.

>Chief
Scientist           &=
nbsp;            =
;    
First Floor

>dynamicsoft          &=
nbsp;            =
;         
East Hanover, NJ 07936

>jdrosen@dynamicsoft.com        &=
nbsp;           
FAX:   (973) 952-5050

>http://www.jdrosen.net &n=
bsp;            =
      
 PHONE: (973) 952-5000

>http://www.dynamicsoft.com

>_______________________________________________

>simple mailing list

>simple@mailman.dynamicsoft.com

>http://mailman.dynamicsoft.com/mailman/listinfo/simple




From seancolson@yahoo.com  Mon Oct 28 12:00:24 2002
Received: from web20709.mail.yahoo.com (web20709.mail.yahoo.com [216.136.226.182])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id MAA01581
	for ; Mon, 28 Oct 2002 12:00:24 -0500 (EST)
Message-ID: <20021028170024.84188.qmail@web20709.mail.yahoo.com>
Received: from [207.46.137.250] by web20709.mail.yahoo.com via HTTP; Mon, 28 Oct 2002 09:00:24 PST
Date: Mon, 28 Oct 2002 09:00:24 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt
To: Paul Kyzivat , Simple 
In-Reply-To: <3DBD60A8.B4A616F5@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1035
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: 

The analogy breaks down in situations that need
more persistence of the stream identifier. If Call-ID
where to persist across all requests, across reboots,
and potentially across devices, then it would be a
perfect fit :) It may be that we find a better way
to accomplish this. The "Stream" header is a first
shot at satisfying the need for a compositor to
identify the source of a publication.

Thanks,
Sean Olson
Microsoft


--- Paul Kyzivat  wrote:
> I question the need for the Stream header. Its use
> seems entirely analogous to the use of a common
> Callid header in REGISTER requests. Why is it
> necessary to introduce a new header for PUBLISH when
> it wasn't necessary for REGISTER?
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

From pkyzivat@cisco.com  Mon Oct 28 14:18:44 2002
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01977
	for ; Mon, 28 Oct 2002 14:18:44 -0500 (EST)
Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.243.26])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g9SJIggM012426;
	Mon, 28 Oct 2002 11:18:42 -0800 (PST)
Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAT69642;
	Mon, 28 Oct 2002 14:22:22 -0500 (EST)
Message-ID: <3DBD8D49.AABAE379@cisco.com>
Date: Mon, 28 Oct 2002 14:17:29 -0500
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: Sean Olson 
CC: Simple 
Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt
References: <20021028170024.84188.qmail@web20709.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1387
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: 


Sean Olson wrote:
> 
> The analogy breaks down in situations that need
> more persistence of the stream identifier. If Call-ID
> where to persist across all requests, across reboots,
> and potentially across devices, then it would be a
> perfect fit :)

Hmm. If that analogy doesn't hold then it would be helpful to have a more complete description of the semantics of a stream. I guess the discussion of section 1.1.4 Publisher Instance is intended to provide this. But it doesn't line up especially well with the definition of Stream in 3.3. Section 3.3 focuses on providing a context within which to process messages in order, while 1.1.4 focuses on distinct publishing instances. From your comments, you suggest that a distinct instance might not always reside on the same device. Once you say that, the possibility arises that you might have two physical devices simultaneously claiming to have the same logical identity. And that messes up the suggested means of ordering messages within a stream. Actually, even moving a stream from one device to another might cause ordering to be messed up if there is significant clock skew.

Based on the available descriptions, I don't yet understand what I might want to use this feature for. You authors obviously have something in mind that motivates the exact options you have selected. Maybe a more specific example would help.

	Paul

From adam@dynamicsoft.com  Mon Oct 28 14:43:30 2002
Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [192.168.4.31])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02106
	for ; Mon, 28 Oct 2002 14:43:29 -0500 (EST)
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g9SJgbpR003517;
	Mon, 28 Oct 2002 14:42:37 -0500 (EST)
Received: by DYN-TX-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 28 Oct 2002 13:43:29 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A642B2@DYN-TX-EXCH-001.dynamicsoft.com>
From: Adam Roach 
To: "'George Foti (LMC)'" ,
        Adam Roach
	 , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Mon, 28 Oct 2002 13:43:28 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1026
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: 

> -----Original Message-----
> From: George Foti (LMC) [mailto:George.Foti@ericsson.ca]
>
> is it correct
> to assume that either of the following is correct:
> 
> a) The RLS will send *individual* SUBSCRIBE to all members of 
> all sub-lists
> included in the main resource list created by the user when 
> he SUBSCRIBEs to
> that list.

That would be valid. Of course, the RLS has to know the membership
of all of the sublists to do so.

> b) The RLS can do procedure (a) for 1 or more sub-lists (in 
> the original
> list) but can also send a SUBSCRIBE to another RLS for some 
> sub-lists (in
> the original list). The later RLS can be responsbile for 
> maintaining some
> lists, and in turn will implement procedure (a).   

That would also be valid. The only revision I would make to your
assertion is: "can do procedure (a) for _zero_ or more sublists..."

Finally, the RLS might have complete information about all of
the states involved, in which case it would generate *no*
subscribes to any other node at all.

/a

From mikko.lonnfors@nokia.com  Tue Oct 29 01:43:29 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04107
	for ; Tue, 29 Oct 2002 01:43:28 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9T6hjB06287
	for ; Tue, 29 Oct 2002 08:43:45 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Tue, 29 Oct 2002 08:43:27 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 29 Oct 2002 08:43:27 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C27F16.7BD29B35"
Date: Tue, 29 Oct 2002 08:43:26 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD01@esebe004.ntc.nokia.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
Thread-Index: AcJ+eRDfLWn0kqBcTMCacCs21pA+EwAnNK3w
To: 
X-OriginalArrivalTime: 29 Oct 2002 06:43:27.0236 (UTC) FILETIME=[7C5E5440:01C27F16]
Content-Length: 4001
Subject: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-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: 

This is a multi-part message in MIME format.

------_=_NextPart_001_01C27F16.7BD29B35
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

New draft is now available. Basically draft presents a solution for the =
requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt.=20
All comments are welcome.

- Mikko

> -----Original Message-----
> From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: 28 October, 2002 13:27
> Subject: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
>=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
>=20
>=20
> 	Title		: SIMPLE PIDF presence capabilities extension
> 	Author(s)	: M. Lonnfors, K. Kiss
> 	Filename	: draft-lonnfors-simple-prescaps-ext-00.txt
> 	Pages		: 14
> 	Date		: 2002-10-25
> =09
> Interoperation of Instant Messaging and Presence systems has been
> defined in IMPP Working Group.  IMPP WG has come up with baseline
> interoperable operations and formats for Presence and Instant
> Messaging systems.  However, these base formats might need
> standardized extensions in order to enable building rational
> applications using Presence and Instant Messaging.  This memo
> proposes an extension to PIDF presence document format to be used in
> SIMPLE based Presence systems [1] but may also be applied to other
> protocols as well.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres
caps-ext-00.txt

To remove yourself from the IETF Announcement list, send a message to=20
ietf-announce-request with the word unsubscribe in the body of the =
message.

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-lonnfors-simple-prescaps-ext-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-lonnfors-simple-prescaps-ext-00.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C27F16.7BD29B35
Content-Type: application/octet-stream;
	name="ATT48751.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT48751.TXT
Content-Disposition: attachment;
	filename="ATT48751.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt
c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl
eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyLTEwLTI1MTEyNTI3LkktREBpZXRmLm9yZz4NCg0K
RU5DT0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxvbm5mb3JzLXNpbXBs
ZS1wcmVzY2Fwcy1leHQtMDAudHh0DQo=

------_=_NextPart_001_01C27F16.7BD29B35
Content-Type: application/octet-stream;
	name="draft-lonnfors-simple-prescaps-ext-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-lonnfors-simple-prescaps-ext-00.URL
Content-Disposition: attachment;
	filename="draft-lonnfors-simple-prescaps-ext-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1sb25uZm9ycy1zaW1wbGUtcHJlc2NhcHMtZXh0LTAwLnR4dA0K

------_=_NextPart_001_01C27F16.7BD29B35--

From mikko.lonnfors@nokia.com  Tue Oct 29 03:11:51 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04438
	for ; Tue, 29 Oct 2002 03:11:51 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9T8C8B18273
	for ; Tue, 29 Oct 2002 10:12:08 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Tue, 29 Oct 2002 10:11:50 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 29 Oct 2002 10:11:49 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 29 Oct 2002 10:11:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD02@esebe004.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comment to draft-olson-simple-publish-01.txt
Thread-Index: AcJ/ItSFNOFThJd3TZGWj22LKYTYqQ==
To: 
X-OriginalArrivalTime: 29 Oct 2002 08:11:49.0726 (UTC) FILETIME=[D4E617E0:01C27F22]
Content-Length: 1752
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA04438
Subject: [Simple] Comment to draft-olson-simple-publish-01.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: 

Hi,

Thanks for the new version. Here are some concerns/comments:

- Sections 1.1.5 and 3.4: Facet header
I am bit confused how this is indented to work. If each PUA always publishes full state then how is it really possible to use facet header to indicate to which watcher instances published information is targeted to? As it is currently defined one PUA could only publish all its information to one or multiple facets i.e. it is not possible to give some part of that info so some facets and some other parts to other facet. In current case it is all or nothing. I would see that better approach would be to include this kind of information into published content and to authorization rules but not to publish protocol itself.
Also it is completely unspecified what should happen if PA does not support the requested facet. Should it report an error or should there be some default behavior. Building interoperable system in my mind requires that these procedures are defined.

- Document does not specify any error handling mechanism for publish. I think there can be cases where either PA or compositor does not for some reason understand what PUA has published or that compositor for some reason cannot add published data into some existing data. Without any error reporting mechanism is might very hard for PUAs to know what went wrong and what PUA could do to correct its actions.

- Section 1.1.3 and examples
Document states that it is possible to associate Class to tuple-ids. This is also used in examples. As draft-ietf-impp-cpim-pidf-05.txt currently stands this is not allowed. I don't know if this is going to change in future versions of PIDF but at a moment associating any semantics to tuple-ids is forbidden.

Best Regards
- Mikko

From aki.niemi@nokia.com  Tue Oct 29 05:22:35 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04860
	for ; Tue, 29 Oct 2002 05:22:34 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9TAMqB19927
	for ; Tue, 29 Oct 2002 12:22:52 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Tue, 29 Oct 2002 12:22:35 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 29 Oct 2002 12:22:34 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 29 Oct 2002 12:22:34 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194504F@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: A omment to draft-olson-simple-publish-01
Thread-Index: AcJ/NRipidRp8W5eRkaRzKbK9qZ2Bw==
To: 
X-OriginalArrivalTime: 29 Oct 2002 10:22:34.0925 (UTC) FILETIME=[190075D0:01C27F35]
Content-Length: 831
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA04860
Subject: [Simple] A omment to draft-olson-simple-publish-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: 

Hi,

Thanks for the much improved -01. One comment though:

Although the draft says that 489 (Bad Event) should be sent in case the composer doesn't understand the published event state, there is no mention of Allow-Events used in that case. Allow-Events is mandatory in 489 according to RFC 3265. If it is also mandatory for 489 to a PUBLISH, it would seem logical that it is also (optionally) used with OPTIONS (for one). Would then Allow-Events in a 2xx to OPTIONS indicate support for SUBSCRIBE/NOTIFY, or PUBLISH, or both?

Why not a new pair of headers, which share the event-type (for packages) namespace with Event/Allow-Events, something like what's described in

	http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framework-00.txt

AFAIK, we are not running out of space with header names ;)

Cheers,
Aki  


From nsyracus@cnri.reston.va.us  Tue Oct 29 06:20:03 2002
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 GAA05029
	for ; Tue, 29 Oct 2002 06:20:03 -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 GAA27754;
	Tue, 29 Oct 2002 06:17:42 -0500 (EST)
Message-Id: <200210291117.GAA27754@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
Date: Tue, 29 Oct 2002 06:17:42 -0500
Content-Length: 2984
Subject: [Simple] I-D ACTION:draft-campbell-simple-im-sessions-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Instant Message Sessions in SIMPLE
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-campbell-simple-im-sessions-00.txt
	Pages		: 11
	Date		: 2002-10-28
	
The SIP MESSAGE method is used to send instant messages, where each
message is independent of any other message.  This is often called
pager-mode messaging, due to the fact that this model is similar to
that of most two-way pager devices.  Another model is called session-
mode.  In session-mode, the instant messages are part of a media
session that provides ordering, a security context, and other
functions.  This media session is established using a SIP INVITE,
just as an audio or video session would be established.
This document describes a method of initiating and managing message
sessions using SIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-campbell-simple-im-sessions-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-campbell-simple-im-sessions-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-campbell-simple-im-sessions-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:	<2002-10-28163248.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-campbell-simple-im-sessions-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-campbell-simple-im-sessions-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-10-28163248.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Tue Oct 29 06:20:08 2002
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 GAA05035
	for ; Tue, 29 Oct 2002 06:20:08 -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 GAA27770;
	Tue, 29 Oct 2002 06:17:47 -0500 (EST)
Message-Id: <200210291117.GAA27770@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
Date: Tue, 29 Oct 2002 06:17:47 -0500
Content-Length: 3256
Subject: [Simple] I-D ACTION:draft-campbell-simple-cpimmsg-sessions-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Instant Message Transport Sessions using the CPIM 
                          Message Format
	Author(s)	: B. Campbell et al.
	Filename	: draft-campbell-simple-cpimmsg-sessions-00.txt
	Pages		: 12
	Date		: 2002-10-28
	
Instant Messaging (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.  Each message
can be sent independently using the SIP MESSAGE method, or messages
can be associated into sessions that are initiated using SIP.  The
first approach is often referred to as pager-mode messaging, due to
its similarity to the behavior of two way pager devices.  The second
approach is often called session-mode messaging, or simply message
sessions.  This document describes a message session mechanism based
on the Common Presence and Instant Messaging message format.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-campbell-simple-cpimmsg-sessions-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-campbell-simple-cpimmsg-sessions-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-campbell-simple-cpimmsg-sessions-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:	<2002-10-28163257.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-campbell-simple-cpimmsg-sessions-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-campbell-simple-cpimmsg-sessions-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-10-28163257.I-D@ietf.org>

--OtherAccess--

--NextPart--



From pkyzivat@cisco.com  Tue Oct 29 10:05:59 2002
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 KAA05677
	for ; Tue, 29 Oct 2002 10:05:58 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9TF6CQt010998
	for ; Tue, 29 Oct 2002 10:06:12 -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 AAT75090;
	Tue, 29 Oct 2002 10:10:49 -0500 (EST)
Message-ID: <3DBEA3D4.A0FBA6FB@cisco.com>
Date: Tue, 29 Oct 2002 10:05:56 -0500
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: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD01@esebe004.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1776
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: 

mikko.lonnfors@nokia.com wrote:
> 
> Hi,
> 
> New draft is now available. Basically draft presents a solution for the requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt.
> All comments are welcome.

Obviously Mikko and I have been cooperating on this. We were both interested in the subject. I thought it would be helpful to be clear about the requirements rather than jumping directly to a proposed solution, so I posted a requirements draft last week. Since then I have been waiting for Mikko to submit this in order to have more fodder for discussion.

There is already a work item to produce a SIP-specific profile for PIDF. I consider these drafts to be a *partial* response to that work item. I realize there is a desire for some addition generalized status values beyond open/closed, such as busy. That is a minefield, and we have chosen not to address it. Instead, we are focusing on some attributes that should be less controversial because they are drawn from the callerprefs draft, whose basic concepts have been accepted for a long time. (I am open to discussion about whether these specific drafts should be expanded to cover the more general requirement, or whether that should be left separate.)

The assertion of these drafts is that capabilities a UAS can specify when registering are information that is equally important in a presence document. I believe Mikko is most concerned with supported media. I also consider that to be of major importance, but I also believe all the others are of potential value in a presence document.

The callerprefs draft is still itself in a state of flux. The work here should remain dependent on the outcome of that work. But I believe it would be helpful to begin progressing these documents now.

	Paul

From rsparks@dynamicsoft.com  Tue Oct 29 11:09:01 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05929
	for ; Tue, 29 Oct 2002 11:09:01 -0500 (EST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g9TG91106880
	for ; Tue, 29 Oct 2002 10:09:01 -0600
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) 
Date: 29 Oct 2002 10:05:12 -0600
Message-Id: <1035907512.1691.35.camel@RjS.localdomain>
Mime-Version: 1.0
Content-Length: 79
Subject: [Simple] IETF55 Agenda Requests
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: 

Please send me requests for agenda time at the Atlanta SIMPLE meeting.

RjS




From Rchapman@seancesoft.com  Tue Oct 29 13:08:37 2002
Received: from flash.Vancouver.com ([209.53.210.16])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06411
	for ; Tue, 29 Oct 2002 13:08:37 -0500 (EST)
Received: from thunder.Vancouver.com ([192.168.200.99]) by flash.Vancouver.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 29 Oct 2002 10:12:51 -0800
content-class: urn:content-classes:message
Date: Tue, 29 Oct 2002 10:12:51 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <0FD1B48D522C08408A3CFD737CD35B5512037A@thunder.vancouver.com>
X-MS-Has-Attach: 
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-TNEF-Correlator: 
Thread-Topic: Presence & SRV - Problem solved?
Thread-Index: AcJ/dig+yxzJ7+40Sp6jeR1ytZbRgQ==
From: "Ryan Chapman" 
To: 
X-OriginalArrivalTime: 29 Oct 2002 18:12:51.0680 (UTC) FILETIME=[CB7F9600:01C27F76]
Content-Length: 1476
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA06411
Subject: [Simple] Presence & SRV - Problem solved?
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: 

Hello all,

I'm writing a SIMPLE-based presence infrastructure, but I'm having some difficulty determining exactly how to deal with a presence URI (e.g., pres:somebody@somewhere.com).

In the CPIM draft, we are told to query _im._sip.example.com for im:fred@example.com, and then that the "choice of IM transfer protocol is a local configuration option for each system."  Given this, which SRV RR should my SIP layer query?  If I translate my presence URI to a SIP URI as specified (somewhere!) in the mailing archive by simply replacing "pres" with "sip", then what good was my first SRV lookup?  In other words, my SIP layer would simply lookup _sip._udp.example.com, ignoring whatever results my previous query returned.

One way that I can see to solve this problem is to use the first lookup as a mechanism for determining the domain name associated with the URI.  In other words, pres:somebody@somewhere.com would generate a lookup for _pres._sip.somewhere.com, which would give me an RR for the presence service.  Using this result, I would generate a SIP URI that would look something like sip:somebody@sippresenceserver.somewhere.com.  At this point, the SIP layer would query _sip._udp.sippresenceserver.somewhere.com, yielding the desired results.

My primary goal is to have my presence server be decoupled from our proxy/registrar, so the presence URI should send the message to a different location than a normal SIP URI would.

Thanks in advance,

Ryan Chapman

From bcampbell@dynamicsoft.com  Tue Oct 29 16:18:52 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06950
	for ; Tue, 29 Oct 2002 16:18:52 -0500 (EST)
Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g9TLIr107922
	for ; Tue, 29 Oct 2002 15:18:53 -0600
Message-ID: <3DBEFB35.1040908@dynamicsoft.com>
Date: Tue, 29 Oct 2002 15:18:45 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simple 
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 976
Subject: [Simple] Message Session IDs
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: 

You have probably noticed 2 new IDs on message sessions that hit the 
repository this morning. These drafts, while listing a small number of 
authors, are actually the result of a great deal of discussion among 
several people, including myself, Jonathan, Rohan, Jon, Robert, Dean, 
Brian, and Allison. (Please do not take this to mean that every person 
listed necessarily agree with every point in the drafts ;-) )

draft-campbell-simple-im-sessions-00 discusses the use of the SDP 
offer/answer model for initiating message sessions, without talking much 
about the message sessions themselves.

draft-campbell-simple-cpimmsg-sessions-00 proposes a message session 
transport that involves transporting messages over TCP or TLS using the 
message/cpim format. This draft depends on the signaling methods 
described in the im-sessions draft.

Neither of these drafts are complete, but we hope they can generate some 
discussion prior to the Atlanta meeting.

Thanks!

Ben.


From jdrosen@dynamicsoft.com  Tue Oct 29 16:35:59 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07020
	for ; Tue, 29 Oct 2002 16:35:58 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9TLZxYH021051;
	Tue, 29 Oct 2002 16:36:00 -0500 (EST)
Message-ID: <3DBEFF3C.3090006@dynamicsoft.com>
Date: Tue, 29 Oct 2002 16:35:56 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell 
CC: Simple 
Subject: Re: [Simple] Message Session IDs
References: <3DBEFB35.1040908@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3050
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: 

let me add some more to what Ben has said here.

Ben Campbell wrote:
> You have probably noticed 2 new IDs on message sessions that hit the 
> repository this morning. These drafts, while listing a small number of 
> authors, are actually the result of a great deal of discussion among 
> several people, including myself, Jonathan, Rohan, Jon, Robert, Dean, 
> Brian, and Allison. (Please do not take this to mean that every person 
> listed necessarily agree with every point in the drafts ;-) )
> 
> draft-campbell-simple-im-sessions-00 discusses the use of the SDP 
> offer/answer model for initiating message sessions, without talking much 
> about the message sessions themselves.
> 
> draft-campbell-simple-cpimmsg-sessions-00 proposes a message session 
> transport that involves transporting messages over TCP or TLS using the 
> message/cpim format. This draft depends on the signaling methods 
> described in the im-sessions draft.

This is the evolution of a long chain of drafts, starting with the IMTP 
proposal 
(http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transport-00.txt), 
followed by the session-of-MESSAGE proposal 
(http://www.jdrosen.net/papers/draft-rosenberg-simple-message-session-00.txt).

At Yokohama, there was some support for the simple-message-session 
approach, but there were still concerns that this was not-quite-right. 
The essence of the problem is that SIP is not a session protocol. So, a 
group of folks got together, and we came to agree on some important 
points. First, SIPs strength is that it can set up all different kinds 
of sessions. There is no constraint that there be only ONE session 
transport protocol. However, we do need a baseline protocol that 
everyone agrees to implement. SIP can be used to signal something else 
if others are developed. Given that this is a baseline, the criteria we 
developed was minimalism. What is the minimal IM session transport we 
can develop which meets our requirements? Our conclusion was a 
CPIM-over-TCP approach. This is a really lightweight transport, its 
amenable to intermediaries [indeed, its intermediaries are much simpler 
than a sip proxy], and it suffers from none of the problems we had with 
trying to use SIP MESSAGE for this (congestion control, overlapping 
transactions, etc.).

As the simple-im-sessions draft discusses, there are many many benefits 
to the session model. As such, I consider it really important to FINALLY 
close on this contentious issue, and have a solution that we can start 
to deploy.

I personally hope that over the next few weeks, we can get consensus on 
these drafts as the basis for mesaging sessions. Please share your thoughts.

-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


From hdhunter@hotmail.com  Tue Oct 29 16:56:39 2002
Received: from hotmail.com (oe63.law3.hotmail.com [209.185.240.79])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07100
	for ; Tue, 29 Oct 2002 16:56:38 -0500 (EST)
From: hdhunter@hotmail.com
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 29 Oct 2002 13:56:39 -0800
X-Originating-IP: [63.229.217.250]
Reply-To: "Mike Peterson" 
Wrom: LBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWW
To: 
References: <200210291701.MAA06174@mailman.dynamicsoft.com>
Date: Tue, 29 Oct 2002 15:54:52 -0600
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.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: 
X-OriginalArrivalTime: 29 Oct 2002 21:56:39.0559 (UTC) FILETIME=[0F235170:01C27F96]
Content-Length: 22849
Subject: [Simple] unsubscribe
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: 

----- Original Message -----
Wrom: CUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRK
To: 
Sent: Tuesday, October 29, 2002 11:01 AM
Subject: simple digest, Vol 1 #547 - 10 msgs


> Send simple mailing list submissions to
> simple@mailman.dynamicsoft.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> or, via email, send a message with subject or body 'help' to
> simple-request@mailman.dynamicsoft.com
>
> You can reach the person managing the list at
> simple-admin@mailman.dynamicsoft.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of simple digest..."
>
>
> Today's Topics:
>
>    1. Re: Re: draft-olson-simple-publish-01.txt (Sean Olson)
>    2. Re: Re: draft-olson-simple-publish-01.txt (Paul Kyzivat)
>    3. RE: collection template (Adam Roach)
>    4. FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
(mikko.lonnfors@nokia.com)
>    5. Comment to draft-olson-simple-publish-01.txt
(mikko.lonnfors@nokia.com)
>    6. A omment to draft-olson-simple-publish-01 (aki.niemi@nokia.com)
>    7. I-D ACTION:draft-campbell-simple-im-sessions-00.txt
(Internet-Drafts@ietf.org)
>    8. I-D ACTION:draft-campbell-simple-cpimmsg-sessions-00.txt
(Internet-Drafts@ietf.org)
>    9. Re: FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt (Paul
Kyzivat)
>   10. IETF55 Agenda Requests (Robert Sparks)
>
> --__--__--
>
> Message: 1
> Date: Mon, 28 Oct 2002 09:00:24 -0800 (PST)
> Wrom: JVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAA
> Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt
> To: Paul Kyzivat , Simple

>
> The analogy breaks down in situations that need
> more persistence of the stream identifier. If Call-ID
> where to persist across all requests, across reboots,
> and potentially across devices, then it would be a
> perfect fit :) It may be that we find a better way
> to accomplish this. The "Stream" header is a first
> shot at satisfying the need for a compositor to
> identify the source of a publication.
>
> Thanks,
> Sean Olson
> Microsoft
>
>
> --- Paul Kyzivat  wrote:
> > I question the need for the Stream header. Its use
> > seems entirely analogous to the use of a common
> > Callid header in REGISTER requests. Why is it
> > necessary to introduce a new header for PUBLISH when
> > it wasn't necessary for REGISTER?
> >
> > Paul
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
>
> --__--__--
>
> Message: 2
> Date: Mon, 28 Oct 2002 14:17:29 -0500
> Wrom: LPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQB
> To: Sean Olson 
> CC: Simple 
> Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt
>
>
>
> Sean Olson wrote:
> >
> > The analogy breaks down in situations that need
> > more persistence of the stream identifier. If Call-ID
> > where to persist across all requests, across reboots,
> > and potentially across devices, then it would be a
> > perfect fit :)
>
> Hmm. If that analogy doesn't hold then it would be helpful to have a more
complete description of the semantics of a stream. I guess the discussion of
section 1.1.4 Publisher Instance is intended to provide this. But it doesn't
line up especially well with the definition of Stream in 3.3. Section 3.3
focuses on providing a context within which to process messages in order,
while 1.1.4 focuses on distinct publishing instances. From your comments,
you suggest that a distinct instance might not always reside on the same
device. Once you say that, the possibility arises that you might have two
physical devices simultaneously claiming to have the same logical identity.
And that messes up the suggested means of ordering messages within a stream.
Actually, even moving a stream from one device to another might cause
ordering to be messed up if there is significant clock skew.
>
> Based on the available descriptions, I don't yet understand what I might
want to use this feature for. You authors obviously have something in mind
that motivates the exact options you have selected. Maybe a more specific
example would help.
>
> Paul
>
> --__--__--
>
> Message: 3
> Wrom: GJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSW
> To: "'George Foti (LMC)'" ,
>         Adam Roach
> , simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] collection template
> Date: Mon, 28 Oct 2002 13:43:28 -0600
>
> > -----Original Message-----
> > Wrom: ZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULH
> >
> > is it correct
> > to assume that either of the following is correct:
> >
> > a) The RLS will send *individual* SUBSCRIBE to all members of
> > all sub-lists
> > included in the main resource list created by the user when
> > he SUBSCRIBEs to
> > that list.
>
> That would be valid. Of course, the RLS has to know the membership
> of all of the sublists to do so.
>
> > b) The RLS can do procedure (a) for 1 or more sub-lists (in
> > the original
> > list) but can also send a SUBSCRIBE to another RLS for some
> > sub-lists (in
> > the original list). The later RLS can be responsbile for
> > maintaining some
> > lists, and in turn will implement procedure (a).
>
> That would also be valid. The only revision I would make to your
> assertion is: "can do procedure (a) for _zero_ or more sublists..."
>
> Finally, the RLS might have complete information about all of
> the states involved, in which case it would generate *no*
> subscribes to any other node at all.
>
> /a
>
> --__--__--
>
> Message: 4
> Wrom: PQkko.lonnfors@nokia.com
> Date: Tue, 29 Oct 2002 08:43:26 +0200
> To: 
> Subject: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
>
> This is a multi-part message in MIME format.
>
> ------_=_NextPart_001_01C27F16.7BD29B35
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hi,
>
> New draft is now available. Basically draft presents a solution for the =
> requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt.=20
> All comments are welcome.
>
> - Mikko
>
> > -----Original Message-----
> > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: 28 October, 2002 13:27
> > Subject: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
> >=20
> >=20
> > A New Internet-Draft is available from the on-line=20
> > Internet-Drafts directories.
> >=20
> >=20
> > Title : SIMPLE PIDF presence capabilities extension
> > Author(s) : M. Lonnfors, K. Kiss
> > Filename : draft-lonnfors-simple-prescaps-ext-00.txt
> > Pages : 14
> > Date : 2002-10-25
> > =09
> > Interoperation of Instant Messaging and Presence systems has been
> > defined in IMPP Working Group.  IMPP WG has come up with baseline
> > interoperable operations and formats for Presence and Instant
> > Messaging systems.  However, these base formats might need
> > standardized extensions in order to enable building rational
> > applications using Presence and Instant Messaging.  This memo
> > proposes an extension to PIDF presence document format to be used in
> > SIMPLE based Presence systems [1] but may also be applied to other
> > protocols as well.
> >=20
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-lonnfors-simple-pres
> caps-ext-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to=20
> ietf-announce-request with the word unsubscribe in the body of the =
> message.
>
> 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-lonnfors-simple-prescaps-ext-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-lonnfors-simple-prescaps-ext-00.txt".
> =09
> 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.
> =09
> =09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> ------_=_NextPart_001_01C27F16.7BD29B35
> Content-Type: application/octet-stream;
> name="ATT48751.TXT"
> Content-Transfer-Encoding: base64
> Content-Description: ATT48751.TXT
> Content-Disposition: attachment;
> filename="ATT48751.TXT"
>
>
Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt
>
c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl
>
eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyLTEwLTI1MTEyNTI3LkktREBpZXRmLm9yZz4NCg0K
>
RU5DT0RJTkcgbWltZQ0KRklMRSAvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxvbm5mb3JzLXNpbXBs
> ZS1wcmVzY2Fwcy1leHQtMDAudHh0DQo=
>
> ------_=_NextPart_001_01C27F16.7BD29B35
> Content-Type: application/octet-stream;
> name="draft-lonnfors-simple-prescaps-ext-00.URL"
> Content-Transfer-Encoding: base64
> Content-Description: draft-lonnfors-simple-prescaps-ext-00.URL
> Content-Disposition: attachment;
> filename="draft-lonnfors-simple-prescaps-ext-00.URL"
>
>
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
> cy9kcmFmdC1sb25uZm9ycy1zaW1wbGUtcHJlc2NhcHMtZXh0LTAwLnR4dA0K
>
> ------_=_NextPart_001_01C27F16.7BD29B35--
>
> --__--__--
>
> Message: 5
> From: mikko.lonnfors@nokia.com
> Date: Tue, 29 Oct 2002 10:11:49 +0200
> To: 
> Subject: [Simple] Comment to draft-olson-simple-publish-01.txt
>
> Hi,
>
> Thanks for the new version. Here are some concerns/comments:
>
> - Sections 1.1.5 and 3.4: Facet header
> I am bit confused how this is indented to work. If each PUA always
publishes full state then how is it really possible to use facet header to
indicate to which watcher instances published information is targeted to? As
it is currently defined one PUA could only publish all its information to
one or multiple facets i.e. it is not possible to give some part of that
info so some facets and some other parts to other facet. In current case it
is all or nothing. I would see that better approach would be to include this
kind of information into published content and to authorization rules but
not to publish protocol itself.
> Also it is completely unspecified what should happen if PA does not
support the requested facet. Should it report an error or should there be
some default behavior. Building interoperable system in my mind requires
that these procedures are defined.
>
> - Document does not specify any error handling mechanism for publish. I
think there can be cases where either PA or compositor does not for some
reason understand what PUA has published or that compositor for some reason
cannot add published data into some existing data. Without any error
reporting mechanism is might very hard for PUAs to know what went wrong and
what PUA could do to correct its actions.
>
> - Section 1.1.3 and examples
> Document states that it is possible to associate Class to tuple-ids. This
is also used in examples. As draft-ietf-impp-cpim-pidf-05.txt currently
stands this is not allowed. I don't know if this is going to change in
future versions of PIDF but at a moment associating any semantics to
tuple-ids is forbidden.
>
> Best Regards
> - Mikko
>
> --__--__--
>
> Message: 6
> From: aki.niemi@nokia.com
> Date: Tue, 29 Oct 2002 12:22:34 +0200
> To: 
> Subject: [Simple] A omment to draft-olson-simple-publish-01
>
> Hi,
>
> Thanks for the much improved -01. One comment though:
>
> Although the draft says that 489 (Bad Event) should be sent in case the
composer doesn't understand the published event state, there is no mention
of Allow-Events used in that case. Allow-Events is mandatory in 489
according to RFC 3265. If it is also mandatory for 489 to a PUBLISH, it
would seem logical that it is also (optionally) used with OPTIONS (for one).
Would then Allow-Events in a 2xx to OPTIONS indicate support for
SUBSCRIBE/NOTIFY, or PUBLISH, or both?
>
> Why not a new pair of headers, which share the event-type (for packages)
namespace with Event/Allow-Events, something like what's described in
>
>
http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framework-00.
txt
>
> AFAIK, we are not running out of space with header names ;)
>
> Cheers,
> Aki
>
>
> --__--__--
>
> Message: 7
> To: IETF-Announce: ;
> CC: simple@mailman.dynamicsoft.com
> From: Internet-Drafts@ietf.org
> Reply-to: Internet-Drafts@ietf.org
> Date: Tue, 29 Oct 2002 06:17:42 -0500
> Subject: [Simple] I-D ACTION:draft-campbell-simple-im-sessions-00.txt
>
> --NextPart
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Instant Message Sessions in SIMPLE
> Author(s) : B. Campbell, J. Rosenberg
> Filename : draft-campbell-simple-im-sessions-00.txt
> Pages : 11
> Date : 2002-10-28
>
> The SIP MESSAGE method is used to send instant messages, where each
> message is independent of any other message.  This is often called
> pager-mode messaging, due to the fact that this model is similar to
> that of most two-way pager devices.  Another model is called session-
> mode.  In session-mode, the instant messages are part of a media
> session that provides ordering, a security context, and other
> functions.  This media session is established using a SIP INVITE,
> just as an audio or video session would be established.
> This document describes a method of initiating and managing message
> sessions using SIP.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-campbell-simple-im-sessions-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-campbell-simple-im-sessions-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-campbell-simple-im-sessions-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: <2002-10-28163248.I-D@ietf.org>
>
> ENCODING mime
> FILE /internet-drafts/draft-campbell-simple-im-sessions-00.txt
>
> --OtherAccess
> Content-Type: Message/External-body;
> name="draft-campbell-simple-im-sessions-00.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
>
> Content-Type: text/plain
> Content-ID: <2002-10-28163248.I-D@ietf.org>
>
> --OtherAccess--
>
> --NextPart--
>
>
>
> --__--__--
>
> Message: 8
> To: IETF-Announce: ;
> CC: simple@mailman.dynamicsoft.com
> From: Internet-Drafts@ietf.org
> Reply-to: Internet-Drafts@ietf.org
> Date: Tue, 29 Oct 2002 06:17:47 -0500
> Subject: [Simple] I-D ACTION:draft-campbell-simple-cpimmsg-sessions-00.txt
>
> --NextPart
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Instant Message Transport Sessions using the CPIM
>                           Message Format
> Author(s) : B. Campbell et al.
> Filename : draft-campbell-simple-cpimmsg-sessions-00.txt
> Pages : 12
> Date : 2002-10-28
>
> Instant Messaging (IM) refers to the transfer of messages between
> users in near real-time.  These messages are usually, but not
> required to be, short.  IMs are often used in a conversational mode,
> that is, the transfer of messages back and forth is fast enough for
> participants to maintain an interactive conversation.  Each message
> can be sent independently using the SIP MESSAGE method, or messages
> can be associated into sessions that are initiated using SIP.  The
> first approach is often referred to as pager-mode messaging, due to
> its similarity to the behavior of two way pager devices.  The second
> approach is often called session-mode messaging, or simply message
> sessions.  This document describes a message session mechanism based
> on the Common Presence and Instant Messaging message format.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-campbell-simple-cpimmsg-sessions-0
0.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-campbell-simple-cpimmsg-sessions-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-campbell-simple-cpimmsg-sessions-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: <2002-10-28163257.I-D@ietf.org>
>
> ENCODING mime
> FILE /internet-drafts/draft-campbell-simple-cpimmsg-sessions-00.txt
>
> --OtherAccess
> Content-Type: Message/External-body;
> name="draft-campbell-simple-cpimmsg-sessions-00.txt";
> site="ftp.ietf.org";
> access-type="anon-ftp";
> directory="internet-drafts"
>
> Content-Type: text/plain
> Content-ID: <2002-10-28163257.I-D@ietf.org>
>
> --OtherAccess--
>
> --NextPart--
>
>
>
> --__--__--
>
> Message: 9
> Date: Tue, 29 Oct 2002 10:05:56 -0500
> From: Paul Kyzivat 
> To: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] FW: I-D
ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
>
> mikko.lonnfors@nokia.com wrote:
> >
> > Hi,
> >
> > New draft is now available. Basically draft presents a solution for the
requirements presented in draft-kyzivat-simple-prescaps-reqts-00.txt.
> > All comments are welcome.
>
> Obviously Mikko and I have been cooperating on this. We were both
interested in the subject. I thought it would be helpful to be clear about
the requirements rather than jumping directly to a proposed solution, so I
posted a requirements draft last week. Since then I have been waiting for
Mikko to submit this in order to have more fodder for discussion.
>
> There is already a work item to produce a SIP-specific profile for PIDF. I
consider these drafts to be a *partial* response to that work item. I
realize there is a desire for some addition generalized status values beyond
open/closed, such as busy. That is a minefield, and we have chosen not to
address it. Instead, we are focusing on some attributes that should be less
controversial because they are drawn from the callerprefs draft, whose basic
concepts have been accepted for a long time. (I am open to discussion about
whether these specific drafts should be expanded to cover the more general
requirement, or whether that should be left separate.)
>
> The assertion of these drafts is that capabilities a UAS can specify when
registering are information that is equally important in a presence
document. I believe Mikko is most concerned with supported media. I also
consider that to be of major importance, but I also believe all the others
are of potential value in a presence document.
>
> The callerprefs draft is still itself in a state of flux. The work here
should remain dependent on the outcome of that work. But I believe it would
be helpful to begin progressing these documents now.
>
> Paul
>
> --__--__--
>
> Message: 10
> From: Robert Sparks 
> To: simple@mailman.dynamicsoft.com
> Date: 29 Oct 2002 10:05:12 -0600
> Subject: [Simple] IETF55 Agenda Requests
>
> Please send me requests for agenda time at the Atlanta SIMPLE meeting.
>
> RjS
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>
> End of simple Digest
>

From pkyzivat@cisco.com  Tue Oct 29 19:36:14 2002
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 TAA07888
	for ; Tue, 29 Oct 2002 19:36:14 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9U0aQ82007598
	for ; Tue, 29 Oct 2002 19:36:27 -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 AAT80987;
	Tue, 29 Oct 2002 19:40:53 -0500 (EST)
Message-ID: <3DBF2970.22BFCCF9@cisco.com>
Date: Tue, 29 Oct 2002 19:36:00 -0500
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: Simple 
References: <200210291117.GAA27770@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1212
Subject: [Simple] Re: comedia in draft-campbell-simple-*-sessions-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: 

Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in such a way that multiple sessions can be demultiplexed from a single connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for the use of the comedia spec to establish the connections. It also wishes to reuse a single connection for multiple sessions.

This presents a problem, because the comedia draft (ietf-mmusic-sdp-comedia-04) does not provide a way to share a connection among multiple sessions. It was constrained from doing so because it made no assumption about the protocol to be used on the connection. As a result it had to come up with a way to associate connections with sessions without regard to media content. 

Either a way must be found to change comedia to provide this capability, or else comedia must be abandoned in favor of some other arrangement for negotiating a connection. (It would be nice to make comedia work for this.)

Rohan and I talked about this, and began to think we could find an enhancement to comedia that would permit this, but then it got very ugly trying to figure out when connections should go away, especially between a pair of intermediaries. This is going to require some work.

	Paul

From pkyzivat@cisco.com  Tue Oct 29 20:08:51 2002
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 UAA07992
	for ; Tue, 29 Oct 2002 20:08:51 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9U193aP009892
	for ; Tue, 29 Oct 2002 20:09: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 AAT81079;
	Tue, 29 Oct 2002 20:13:40 -0500 (EST)
Message-ID: <3DBF311F.B8AC9254@cisco.com>
Date: Tue, 29 Oct 2002 20:08:47 -0500
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: Simple 
Subject: Re: [Simple] Message Session IDs
References: <3DBEFB35.1040908@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2158
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: 

I forgot in prior message, so first let me say that I like the direction this is going much better than the prior attempts!

I'm having difficulty understanding the purpose of the From meta-data header. 

Section 3 says:

  "When used in an instant message session, the From and To meta-data
   headers are used to identify the session.  There is no expectation
   that these headers actually identify the participants in the session-
   -they are used only as tokens to identify the session itself."

Section 5 says: 

  "This message MUST contain a ... From meta-data header value,
   which SHOULD be used to identify the sender, but MAY be set
   to some other value for purposes of anonymity."

I figure there are a few kinds of things this header could contain:

- It could always contain the same value as the From/To
  (depending on direction of message) of the sip session that
  established the media session. 

- It could carry the URI from the a:uri line of the message sender.

- It could be the sip: or im: address of the actual message source.
  In simple cases it would be the same as the To/From address of
  the invite, but would be different when conferencing.

I can't think of any other plausible alternatives. The first two are useless redundant information that can be inferred. The last would be useful. So I will assume that is the intent even though it conflicts with section 3. Please let me know if this is a wrong assumption.

This is sensitive information that ought to have end-to-end confidentiality protection.

At the same time, this From header is a peer of the To header. The To header apparently is intended to carry the URI from the a:uri line of the SDP from the destination message. It is needed for the recipient to demux a shared connection and send the message to the proper session. Intermediaries must also do this demuxing, so they also need access to the To header. So the To header can't be confidential end-to-end.

How is confidentiality going to work so it hides the From header and not the To header?

I think these need to go into different envelopes. Why shouldn't the To go in the outer envelope?

	Paul

From jdrosen@dynamicsoft.com  Tue Oct 29 21:28:52 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08239
	for ; Tue, 29 Oct 2002 21:28:52 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.11])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g9U2SrYH021119;
	Tue, 29 Oct 2002 21:28:53 -0500 (EST)
Message-ID: <3DBF43E4.4050107@dynamicsoft.com>
Date: Tue, 29 Oct 2002 21:28:52 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Simple 
Subject: Re: [Simple] Message Session IDs
References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2981
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: 

inline.

Paul Kyzivat wrote:
 > I forgot in prior message, so first let me say that I like the
 > direction this is going much better than the prior attempts!
 >
 > I'm having difficulty understanding the purpose of the From meta-data
 > header.
 >
 > Section 3 says:
 >
 > "When used in an instant message session, the From and To meta-data
 > headers are used to identify the session.  There is no expectation
 > that these headers actually identify the participants in the session-
 >  -they are used only as tokens to identify the session itself."
 >
 > Section 5 says:
 >
 > "This message MUST contain a ... From meta-data header value, which
 > SHOULD be used to identify the sender, but MAY be set to some other
 > value for purposes of anonymity."

Oops.

This was something we changed several revs in, and it looks like it 
didn't get changed everywhere. Its supposed to be the identity of the 
sender, ie., section 5 is correct.

 >
 > I figure there are a few kinds of things this header could contain:
 >
 > - It could always contain the same value as the From/To (depending on
 > direction of message) of the sip session that established the media
 > session.
 >
 > - It could carry the URI from the a:uri line of the message sender.
 >
 > - It could be the sip: or im: address of the actual message source.
 > In simple cases it would be the same as the To/From address of the
 > invite, but would be different when conferencing.

Yes. This is exactly the intent.

 >
 > I can't think of any other plausible alternatives. The first two are
 > useless redundant information that can be inferred. The last would be
 > useful. So I will assume that is the intent even though it conflicts
 > with section 3. Please let me know if this is a wrong assumption.

You are absolutely correct.

 >
 > This is sensitive information that ought to have end-to-end
 > confidentiality protection.
 >
 > At the same time, this From header is a peer of the To header. The To
 > header apparently is intended to carry the URI from the a:uri line of
 > the SDP from the destination message. It is needed for the recipient
 > to demux a shared connection and send the message to the proper
 > session. Intermediaries must also do this demuxing, so they also need
 > access to the To header. So the To header can't be confidential
 > end-to-end.
 >
 > How is confidentiality going to work so it hides the From header and
 > not the To header?
 >
 > I think these need to go into different envelopes. Why shouldn't the
 > To go in the outer envelope?

Hmm. Sounds reasonable. Its almost more like a request URI type of thing.

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


From bcampbell@dynamicsoft.com  Tue Oct 29 23:30:22 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08589
	for ; Tue, 29 Oct 2002 23:30:22 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g9U4UEpA004739;
	Tue, 29 Oct 2002 22:30:15 -0600 (CST)
Message-ID: <3DBF6051.6020502@dynamicsoft.com>
Date: Tue, 29 Oct 2002 22:30:09 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: Paul Kyzivat , Simple 
Subject: Re: [Simple] Message Session IDs
References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com> <3DBF43E4.4050107@dynamicsoft.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3355
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: 

Jonathan Rosenberg wrote:
> inline.
> 
> Paul Kyzivat wrote:
>  > I forgot in prior message, so first let me say that I like the
>  > direction this is going much better than the prior attempts!
>  >
>  > I'm having difficulty understanding the purpose of the From meta-data
>  > header.
>  >
>  > Section 3 says:
>  >
>  > "When used in an instant message session, the From and To meta-data
>  > headers are used to identify the session.  There is no expectation
>  > that these headers actually identify the participants in the session-
>  >  -they are used only as tokens to identify the session itself."
>  >
>  > Section 5 says:
>  >
>  > "This message MUST contain a ... From meta-data header value, which
>  > SHOULD be used to identify the sender, but MAY be set to some other
>  > value for purposes of anonymity."
> 
> Oops.
> 
> This was something we changed several revs in, and it looks like it 
> didn't get changed everywhere. Its supposed to be the identity of the 
> sender, ie., section 5 is correct.
> 
>  >
>  > I figure there are a few kinds of things this header could contain:
>  >
>  > - It could always contain the same value as the From/To (depending on
>  > direction of message) of the sip session that established the media
>  > session.
>  >
>  > - It could carry the URI from the a:uri line of the message sender.
>  >
>  > - It could be the sip: or im: address of the actual message source.
>  > In simple cases it would be the same as the To/From address of the
>  > invite, but would be different when conferencing.
> 
> Yes. This is exactly the intent.
> 
>  >
>  > I can't think of any other plausible alternatives. The first two are
>  > useless redundant information that can be inferred. The last would be
>  > useful. So I will assume that is the intent even though it conflicts
>  > with section 3. Please let me know if this is a wrong assumption.
> 
> You are absolutely correct.
> 
>  >
>  > This is sensitive information that ought to have end-to-end
>  > confidentiality protection.
>  >
>  > At the same time, this From header is a peer of the To header. The To
>  > header apparently is intended to carry the URI from the a:uri line of
>  > the SDP from the destination message. It is needed for the recipient
>  > to demux a shared connection and send the message to the proper
>  > session. Intermediaries must also do this demuxing, so they also need
>  > access to the To header. So the To header can't be confidential
>  > end-to-end.
>  >
>  > How is confidentiality going to work so it hides the From header and
>  > not the To header?
>  >
>  > I think these need to go into different envelopes. Why shouldn't the
>  > To go in the outer envelope?
> 
> Hmm. Sounds reasonable. Its almost more like a request URI type of thing.

I also agree it sounds reasonable--although if we were to do that we 
might want to call it something other than To. That way, we could keep a 
more symetric use of To and From in the message/cpim headers. The main 
reason we chose To in the first place is it already existed in 
cpim-msgfmt--that is, it did not require an extension. It seems to me 
that putting an additional header in the outer envelope _does_ require 
an extension, so we might as well name it whatever we wish.

If we were to do this, does it also make sense to move MsgID to the 
outer envelope?



From deepankarb@huawei.com  Wed Oct 30 01:19:37 2002
Received: from mta0 ([61.144.161.10])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08941
	for ; Wed, 30 Oct 2002 01:19:32 -0500 (EST)
Received: from D70286 (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H4S00AVM6TO1X@mta0.huawei.com> for
 simple@mailman.dynamicsoft.com; Wed, 30 Oct 2002 14:17:49 +0800 (CST)
Date: Wed, 30 Oct 2002 14:19:16 +0800
From: Deepankar 
To: simple@mailman.dynamicsoft.com
Message-id: <00bb01c27fdc$46074750$ac064d0a@D70286>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_hT7/T8oGakTuQcbHNRhxrw)"
X-Priority: 3
X-MSMail-priority: Normal
Content-Length: 1904
Subject: [Simple] uploading of Presence docs to PA
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: 

This is a multi-part message in MIME format.

--Boundary_(ID_hT7/T8oGakTuQcbHNRhxrw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

To upload a presence document form a PUA to the PA, presence-07 says, there could be two methods. one is, constructing a presence doc using registrations, and the other is, to explicitly upload the document. This is implementation choice, I believe. 
If I manipulate REGISTER to carry a body with a presence doc, then backward compatibility will be a problem, and in the other case, an explicit out of band connection is needed to achieve it. The spec says , manipulation of REGISTER's is not recommended. 

Any thoughts worked on lately !!

Deeps


--Boundary_(ID_hT7/T8oGakTuQcbHNRhxrw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT









To upload a presence document form a PUA to the PA, 
presence-07 says, there could be two methods. one is, constructing a presence 
doc using registrations, and the other is, to explicitly upload the document. 
This is implementation choice, I believe. 


If I manipulate REGISTER to carry a body with a 
presence doc, then backward compatibility will be a problem, and in the other 
case, an explicit out of band connection is needed to achieve it. The spec says 
, manipulation of REGISTER's is not recommended. 


 


Any thoughts worked on lately !!


 


Deeps


 


--Boundary_(ID_hT7/T8oGakTuQcbHNRhxrw)--

From aki.niemi@nokia.com  Wed Oct 30 03:45:57 2002
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 DAA09442
	for ; Wed, 30 Oct 2002 03:45:56 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9U8jWb25390
	for ; Wed, 30 Oct 2002 10:45:32 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 30 Oct 2002 10:45:55 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 30 Oct 2002 10:45:55 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Message Session IDs
Date: Wed, 30 Oct 2002 10:45:54 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945053@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Message Session IDs
Thread-Index: AcJ/zclJxQZw4cxxT4qnE6f859ZEFAAIgUAw
To: , 
Cc: , 
X-OriginalArrivalTime: 30 Oct 2002 08:45:55.0194 (UTC) FILETIME=[C2817DA0:01C27FF0]
Content-Length: 989
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA09442
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: 

Hi,

First off, I also think this current approach does look cleaner and better than the previous ones.

More inline:

> >  > I think these need to go into different envelopes. Why 
> shouldn't the
> >  > To go in the outer envelope?
> > 
> > Hmm. Sounds reasonable. Its almost more like a request URI 
> type of thing.
> 
> I also agree it sounds reasonable--although if we were to do that we 
> might want to call it something other than To. That way, we 
> could keep a 
> more symetric use of To and From in the message/cpim headers. 
> The main 
> reason we chose To in the first place is it already existed in 
> cpim-msgfmt--that is, it did not require an extension. It seems to me 
> that putting an additional header in the outer envelope 
> _does_ require 
> an extension, so we might as well name it whatever we wish.

I also agree. This looks much more like a SessionID than a To. Also, since cpim-msgfmt allows multiple Tos, it might have been a problem anyway.
 
Cheers,
Aki

From aki.niemi@nokia.com  Wed Oct 30 05:36:50 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09748
	for ; Wed, 30 Oct 2002 05:36:49 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9UAb8B12628
	for ; Wed, 30 Oct 2002 12:37:08 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Wed, 30 Oct 2002 12:36:48 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 30 Oct 2002 12:36:48 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 30 Oct 2002 12:36:48 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945054@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-niemi-simple-im-wireless-reqs-00.txt
Thread-Index: AcJ8OMFIQ2GhKS6/QFKk1YgsjrXSBQDxp5CQ
To: 
X-OriginalArrivalTime: 30 Oct 2002 10:36:48.0926 (UTC) FILETIME=[40706BE0:01C28000]
Content-Length: 713
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA09748
Subject: [Simple] 3GPP Messaging requirements
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: 

Hi All,

Like promised in Yokohama, there is now a document available describing the 3GPP requirements to Instant Messaging. It lists requirements for both pager mode and session mode IM. Here's a link for your convenience:

http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-00.txt

I'd especially like to draw your attention to the requirements for session mode IM, as well as the requirements for data manipulation.

Note also, that when 3GPP talks about session based messaging, there is a strong flavor of multiparty sessions to it. The conferencing aspects, and the chat-room type aspects of this document should be considered already in the current message session work.

Cheers,
Aki


From pkyzivat@cisco.com  Wed Oct 30 09:08:26 2002
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 JAA10388
	for ; Wed, 30 Oct 2002 09:08:26 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g9UE8fW2016040
	for ; Wed, 30 Oct 2002 09:08:42 -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 AAT83224;
	Wed, 30 Oct 2002 09:13:19 -0500 (EST)
Message-ID: <3DBFE7D9.CE57E118@cisco.com>
Date: Wed, 30 Oct 2002 09:08:25 -0500
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: Simple 
Subject: Re: [Simple] Message Session IDs
References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com> <3DBF43E4.4050107@dynamicsoft.com> <3DBF6051.6020502@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1080
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: 


Ben Campbell wrote:
> 
> > Hmm. Sounds reasonable. Its almost more like a request URI type of thing.
> 
> I also agree it sounds reasonable--although if we were to do that we
> might want to call it something other than To. That way, we could keep a
> more symetric use of To and From in the message/cpim headers. The main
> reason we chose To in the first place is it already existed in
> cpim-msgfmt--that is, it did not require an extension. It seems to me
> that putting an additional header in the outer envelope _does_ require
> an extension, so we might as well name it whatever we wish.

Yes. I was going to complain about the name "To" in my earlier message but didn't want to appear petty. (I *am* petty, but didn't want to appear that way. :-)

I don't think "To" has the right connotation.

> 
> If we were to do this, does it also make sense to move MsgID to the
> outer envelope?

I don't know about this. If it is only needed by the endpoints then it might as well be in the inner envelope. Protecting it should help protect against some kinds of attacks.

	Paul

From bcampbell@dynamicsoft.com  Wed Oct 30 09:38:10 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10488
	for ; Wed, 30 Oct 2002 09:38:10 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g9UEc3pA046745;
	Wed, 30 Oct 2002 08:38:04 -0600 (CST)
Message-ID: <3DBFEEC2.8010109@dynamicsoft.com>
Date: Wed, 30 Oct 2002 08:37:54 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Deepankar 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] uploading of Presence docs to PA
References: <00bb01c27fdc$46074750$ac064d0a@D70286>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 684
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: 

Deepankar wrote:
> To upload a presence document form a PUA to the PA, presence-07 says, 
> there could be two methods. one is, constructing a presence doc using 
> registrations, and the other is, to explicitly upload the document. This 
> is implementation choice, I believe.
> If I manipulate REGISTER to carry a body with a presence doc, then 
> backward compatibility will be a problem, and in the other case, an 
> explicit out of band connection is needed to achieve it. The spec says , 
> manipulation of REGISTER's is not recommended.
>  
> Any thoughts worked on lately !!
>  
> Deeps
>  

Look at draft-olson-simple-publish-01 that was published last week.

Thanks!

Ben.


From bcampbell@dynamicsoft.com  Wed Oct 30 09:40:58 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10520
	for ; Wed, 30 Oct 2002 09:40:57 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id g9UEeTpA046874;
	Wed, 30 Oct 2002 08:40:29 -0600 (CST)
Message-ID: <3DBFEF54.1020907@dynamicsoft.com>
Date: Wed, 30 Oct 2002 08:40:20 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Simple 
Subject: Re: [Simple] Message Session IDs
References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com> <3DBF43E4.4050107@dynamicsoft.com> <3DBF6051.6020502@dynamicsoft.com> <3DBFE7D9.CE57E118@cisco.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 511
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: 

Paul Kyzivat wrote:
> 
> Ben Campbell wrote:

[...]

> 
>>If we were to do this, does it also make sense to move MsgID to the
>>outer envelope?
> 
> 
> I don't know about this. If it is only needed by the endpoints then it might as well be in the inner envelope. Protecting it should help protect against some kinds of attacks.
> 

On reflection, I agree with you. I had it in my head that an 
intermediary might use it for ordering purposes, but now that I am more 
awake I realize there is no need for that.


From George.Foti@ericsson.ca  Mon Oct 28 14:18:56 2002
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01982
	for ; Mon, 28 Oct 2002 14:18:56 -0500 (EST)
Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g9SJInW18015;
	Mon, 28 Oct 2002 13:18:49 -0600 (CST)
Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1])
	by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9SJInN22250;
	Mon, 28 Oct 2002 13:18:49 -0600 (CST)
Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134])
	by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g9SJImh13626;
	Mon, 28 Oct 2002 14:18:48 -0500 (EST)
Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2655.55)
	id ; Mon, 28 Oct 2002 14:18:48 -0500
Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037B1E@lmc37.lmc.ericsson.se>
From: "George Foti (LMC)" 
To: "'Adam Roach'" , simple@mailman.dynamicsoft.com
Subject: RE: [Simple] collection template
Date: Mon, 28 Oct 2002 14:18:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 1569
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: 

Some clarification Adam:

When a user creates a resource list, I assume that he can refer to other
lists there in, so basically we have a case of recursion. Now is it correct
to assume that either of the following is correct:

a) The RLS will send *individual* SUBSCRIBE to all members of all sub-lists
included in the main resource list created by the user when he SUBSCRIBEs to
that list.

b) The RLS can do procedure (a) for 1 or more sub-lists (in the original
list) but can also send a SUBSCRIBE to another RLS for some sub-lists (in
the original list). The later RLS can be responsbile for maintaining some
lists, and in turn will implement procedure (a).   

Thnx/gf

> -----Original Message-----
> From: Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Friday, October 25, 2002 6:04 PM
> To: simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] collection template
> 
> 
> [Sliding in under the wire for the -00 deadline]
> 
> An i-d describing a template event package for collections has been
> submitted to the drafts editor. Until a copy appears in the archives,
> you can download a copy from:
> 
> http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-t
emplate-00.txt

HTML version also available:
http://pages.sbcglobal.net/roaches/ietf/draft-roach-sip-list-template-00.htm
l

This work is still rather rough around the edges, but I think it gives a
good starting point for discussion.

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

From George.Foti@ericsson.ca  Tue Oct 29 14:22:34 2002
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06624
	for ; Tue, 29 Oct 2002 14:22:34 -0500 (EST)
Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g9TJMHW01040;
	Tue, 29 Oct 2002 13:22:17 -0600 (CST)
Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1])
	by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g9TJMG718607;
	Tue, 29 Oct 2002 13:22:16 -0600 (CST)
Received: from eammlex033.lmc.ericsson.se (eammlex033.lmc.ericsson.se [142.133.1.133])
	by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g9TJMGh02577;
	Tue, 29 Oct 2002 14:22:16 -0500 (EST)
Received: by eammlex033.lmc.ericsson.se with Internet Mail Service (5.5.2655.55)
	id ; Tue, 29 Oct 2002 14:21:51 -0500
Message-ID: <32CD630F6CBED411AE180008C7894CBC0C037B26@lmc37.lmc.ericsson.se>
From: "George Foti (LMC)" 
To: "'Paul Kyzivat'" , Sean Olson 
Cc: Simple 
Subject: RE: [Simple] Re: draft-olson-simple-publish-01.txt
Date: Tue, 29 Oct 2002 14:22:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
Content-Length: 2208
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: 

I have the same concern. Sections 1.1.4 & 3.3 are not well aligned with
respect to the real intent for Stream header. Is it meant to be used as :
1) A unique correlation identifier
2) A way for sequencing for data from the *same* source
3) Both 1) & 2)

If it is case 3 than I am not sure how will that really work if the
semantics is not defined.

Rgds/gf

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, October 28, 2002 2:17 PM
> To: Sean Olson
> Cc: Simple
> Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt
> 
> 
> 
> 
> Sean Olson wrote:
> > 
> > The analogy breaks down in situations that need
> > more persistence of the stream identifier. If Call-ID
> > where to persist across all requests, across reboots,
> > and potentially across devices, then it would be a
> > perfect fit :)
> 
> Hmm. If that analogy doesn't hold then it would be helpful to 
> have a more complete description of the semantics of a 
> stream. I guess the discussion of section 1.1.4 Publisher 
> Instance is intended to provide this. But it doesn't line up 
> especially well with the definition of Stream in 3.3. Section 
> 3.3 focuses on providing a context within which to process 
> messages in order, while 1.1.4 focuses on distinct publishing 
> instances. From your comments, you suggest that a distinct 
> instance might not always reside on the same device. Once you 
> say that, the possibility arises that you might have two 
> physical devices simultaneously claiming to have the same 
> logical identity. And that messes up the suggested means of 
> ordering messages within a stream. Actually, even moving a 
> stream from one device to another might cause ordering to be 
> messed up if there is significant clock skew.
> 
> Based on the available descriptions, I don't yet understand 
> what I might want to use this feature for. You authors 
> obviously have something in mind that motivates the exact 
> options you have selected. Maybe a more specific example would help.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From krishna_kamaraju@yahoo.com  Wed Oct 30 02:25:31 2002
Received: from web13308.mail.yahoo.com (web13308.mail.yahoo.com [216.136.175.44])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id CAA09182
	for ; Wed, 30 Oct 2002 02:25:31 -0500 (EST)
Message-ID: <20021030072532.20510.qmail@web13308.mail.yahoo.com>
Received: from [61.11.48.130] by web13308.mail.yahoo.com via HTTP; Tue, 29 Oct 2002 23:25:32 PST
Date: Tue, 29 Oct 2002 23:25:32 -0800 (PST)
From: kamaraju krishna 
To: simple@mailman.dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 865
Subject: [Simple] need help
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: 


  Hello sirs

i am new to sip protocol development & we are
developing sip protocols 
for controller based product. we are already developed
tcp/ip stack for 
controller based product.


i need information about how to build packet and how
to encode data 
in to BNF format and where this BNF information is
available,
pl give above information. 

is  there any proxy server service providers are
avilable for 
SIP protocol testing ?

please send any SIP related information like sip
design, development,
source code sites and any  other sites related to sip
protocols.



	Regards
	
        K.V.N.krishna 
        P.L . LINKWELL TELESYSTEMS, 
        HYDERABAD. INDIA      
	
        krishna_kamaraju@yahoo.com
           



  
  



__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

From deepankarb@huawei.com  Wed Oct 30 19:36:17 2002
Received: from mta0 ([61.144.161.10])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12414
	for ; Wed, 30 Oct 2002 19:36:09 -0500 (EST)
Received: from D70286 (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H4T003TSLL5M2@mta0.huawei.com> for
 simple@mailman.dynamicsoft.com; Thu, 31 Oct 2002 08:34:19 +0800 (CST)
Date: Thu, 31 Oct 2002 08:35:44 +0800
From: Deepankar 
Subject: Re: [Simple] uploading of Presence docs to PA
To: Ben Campbell 
Cc: simple@mailman.dynamicsoft.com
Message-id: <002801c28075$7339ec20$ac064d0a@D70286>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <00bb01c27fdc$46074750$ac064d0a@D70286>
 <3DBFEEC2.8010109@dynamicsoft.com>
Content-Length: 1291
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: 

Hey thanks Ben ! I was dying to look at some work done on this. Somehow, I
was out of context on this one.

Thanks again, and would be in loop for the 01.

Deeps

----- Original Message -----
From: "Ben Campbell" 
To: "Deepankar" 
Cc: 
Sent: Wednesday, October 30, 2002 10:37 PM
Subject: Re: [Simple] uploading of Presence docs to PA


> Deepankar wrote:
> > To upload a presence document form a PUA to the PA, presence-07 says,
> > there could be two methods. one is, constructing a presence doc using
> > registrations, and the other is, to explicitly upload the document. This
> > is implementation choice, I believe.
> > If I manipulate REGISTER to carry a body with a presence doc, then
> > backward compatibility will be a problem, and in the other case, an
> > explicit out of band connection is needed to achieve it. The spec says ,
> > manipulation of REGISTER's is not recommended.
> >
> > Any thoughts worked on lately !!
> >
> > Deeps
> >
>
> Look at draft-olson-simple-publish-01 that was published last week.
>
> Thanks!
>
> Ben.
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple


From nsyracus@cnri.reston.va.us  Thu Oct 31 06:15:00 2002
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 GAA14225
	for ; Thu, 31 Oct 2002 06:14:45 -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 GAA12649;
	Thu, 31 Oct 2002 06:12:06 -0500 (EST)
Message-Id: <200210311112.GAA12649@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
Date: Thu, 31 Oct 2002 06:12:05 -0500
Content-Length: 2703
Subject: [Simple] I-D ACTION:draft-sparks-simple-jabber-sessions-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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Establishing jabber Messaging Sessions with the 
                          Session Initiation Protocol
	Author(s)	: R. Sparks
	Filename	: draft-sparks-simple-jabber-sessions-00.txt
	Pages		: 10
	Date		: 2002-10-30
	
This document explores modeling jabber message streams as media
sessions, and how they  can be initiated with the Session Initiation
Protocol.  It also explores how these sessions can be integrated into
existing session-based multimedia communication applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sparks-simple-jabber-sessions-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-sparks-simple-jabber-sessions-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-sparks-simple-jabber-sessions-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:	<2002-10-30155227.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-sparks-simple-jabber-sessions-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-sparks-simple-jabber-sessions-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-10-30155227.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Thu Oct 31 06:17:23 2002
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 GAA14240
	for ; Thu, 31 Oct 2002 06:17:18 -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 GAA13107;
	Thu, 31 Oct 2002 06:14:39 -0500 (EST)
Message-Id: <200210311114.GAA13107@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
Date: Thu, 31 Oct 2002 06:14:39 -0500
Content-Length: 2665
Subject: [Simple] I-D ACTION:draft-kiss-simple-presence-wireless-reqs-01.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for Presence Service based on 3GPP 
                          specifications and wireless environment 
                          characteristics
	Author(s)	: K. Kiss, G. Bajko
	Filename	: draft-kiss-simple-presence-wireless-reqs-01.txt
	Pages		: 13
	Date		: 2002-10-30
	
This Internet-Draft defines requirements for Presence Service based 
on 3GPP specifications and wireless environment characteristics.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kiss-simple-presence-wireless-reqs-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kiss-simple-presence-wireless-reqs-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-kiss-simple-presence-wireless-reqs-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-10-30162645.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-kiss-simple-presence-wireless-reqs-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-kiss-simple-presence-wireless-reqs-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-10-30162645.I-D@ietf.org>

--OtherAccess--

--NextPart--



From deepankarb@huawei.com  Fri Nov  1 02:00:14 2002
Received: from mta0 ([61.144.161.10])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17753
	for ; Fri, 1 Nov 2002 02:00:09 -0500 (EST)
Received: from D70286 (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H4V001OFY136Y@mta0.huawei.com> for
 simple@mailman.dynamicsoft.com; Fri, 01 Nov 2002 14:58:16 +0800 (CST)
Date: Fri, 01 Nov 2002 14:59:42 +0800
From: Deepankar 
To: simple@mailman.dynamicsoft.com
Message-id: <007201c28174$417807d0$ac064d0a@D70286>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_a9vvxkheUlOa3fgJMBRtNA)"
X-Priority: 3
X-MSMail-priority: Normal
Content-Length: 1222
Subject: [Simple] Interdomain 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: 

This is a multi-part message in MIME format.

--Boundary_(ID_a9vvxkheUlOa3fgJMBRtNA)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Folks,

In case of a softswitch based presence solution, If the PA is co-located with the Proxy/Registrar with the Softswitch, then what mechanisms are there for it, to know of the presence of users homed in a different Softswitch.

Deeps

--Boundary_(ID_a9vvxkheUlOa3fgJMBRtNA)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT









Folks,


 


In case of a softswitch based presence solution, If 
the PA is co-located with the Proxy/Registrar with the Softswitch, then what 
mechanisms are there for it, to know of the presence of users homed in a 
different Softswitch.


 


Deeps


--Boundary_(ID_a9vvxkheUlOa3fgJMBRtNA)--

From mikko.lonnfors@nokia.com  Sat Nov  2 08:08:27 2002
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 IAA26610
	for ; Sat, 2 Nov 2002 08:08:26 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA2D7wO12415
	for ; Sat, 2 Nov 2002 15:08:02 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Sat, 2 Nov 2002 15:08:22 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sat, 2 Nov 2002 15:08:21 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
Date: Sat, 2 Nov 2002 15:08:20 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
Thread-Index: AcJ/XXBzy3S2SSvqRVSFa8QkW/NGiAAmZrYg
To: , 
X-OriginalArrivalTime: 02 Nov 2002 13:08:21.0928 (UTC) FILETIME=[EB87AA80:01C28270]
Content-Length: 4085
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA26610
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: 

Hi,

inline

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: 29 October, 2002 17:06
> To: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] FW: I-D
> ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
> 
> 
> mikko.lonnfors@nokia.com wrote:
> > 
> > Hi,
> > 
> > New draft is now available. Basically draft presents a 
> solution for the requirements presented in 
> draft-kyzivat-simple-prescaps-reqts-00.txt.
> > All comments are welcome.
> 
> Obviously Mikko and I have been cooperating on this. We were 
> both interested in the subject. I thought it would be helpful 
> to be clear about the requirements rather than jumping 
> directly to a proposed solution, so I posted a requirements 
> draft last week. Since then I have been waiting for Mikko to 
> submit this in order to have more fodder for discussion.
> 
> There is already a work item to produce a SIP-specific 
> profile for PIDF. I consider these drafts to be a *partial* 
> response to that work item. I realize there is a desire for 
> some addition generalized status values beyond open/closed, 
> such as busy. That is a minefield, and we have chosen not to 
> address it. Instead, we are focusing on some attributes that 
> should be less controversial because they are drawn from the 
> callerprefs draft, whose basic concepts have been accepted 
> for a long time. (I am open to discussion about whether these 
> specific drafts should be expanded to cover the more general 
> requirement, or whether that should be left separate.)
> The assertion of these drafts is that capabilities a UAS can 
> specify when registering are information that is equally 
> important in a presence document. I believe Mikko is most 
> concerned with supported media. I also consider that to be of 
> major importance, but I also believe all the others are of 
> potential value in a presence document.

This topic was first discussed in IMPP mailing list related to PIDF communication means. After some discussion it was concluded that this work might fit better to SIMPLE WG agenda. 
I would also like to see some comments to the requirements draft. A small problem in writing that was that there were no requirements for callerpreferences and because of that we have tried to put quite a lot motivational and explanative text into requirements. It would be very helpful to hear also other people comments to this. If the overall idea is acceptable then the exact requirements should be quite clear. At least requirements 1, 2, and 3 should be quite self-evident (I hope). Requirement 4 is now marked with SHOULD level and I would like to hear if it would be good idea to move it to MUST level. Also I am not sure we have been able to collect all relevant requirements so if something seems to be missing please let us know.  

> The callerprefs draft is still itself in a state of flux. The 
> work here should remain dependent on the outcome of that 
> work. But I believe it would be helpful to begin progressing 
> these documents now.

We have tried to keep this draft as independent of callerprefs as possible but there is of course quite heavy dependency between these two. 

Here are some open items for solution draft:
- At a moment draft allows use of extension in two places inside PIDF document (inside  and . Should we specify the exact location where this extension can be used within PIDF document.
- We went through 2 or 3 different XML schemas before ending up with current one. Obviously there is lot of different options and if someone thinks there exists better alternatives then this can be discussed.
- We ended up using negated attribute inside  elements to indicate whether value is supporter or not supported. There are also other alternatives to represent this. One alternative would be to replace  with either  or  element.

- Mikko

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

From jdrosen@dynamicsoft.com  Sat Nov  2 16:33:36 2002
Received: from IPOfCard1.guest-tek.com ([141.154.107.194])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28086
	for ; Sat, 2 Nov 2002 16:33:35 -0500 (EST)
Received: from dynamicsoft.com ([141.154.107.210])
	by IPOfCard1.guest-tek.com (8.11.6/8.8.7) with ESMTP id gA2LW9r13239;
	Sat, 2 Nov 2002 16:32:10 -0500
Message-ID: <3DC4057B.1060901@dynamicsoft.com>
Date: Sat, 02 Nov 2002 12:03:55 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Deepankar 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Interdomain presence
References: <007201c28174$417807d0$ac064d0a@D70286>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 884
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: 

A PUA can publish presence to any PA using the SIP PUBLISH method. You 
can find the current I-D for this at:
http://www.ietf.org/internet-drafts/draft-olson-simple-publish-01.txt

whether you call the PA a softswitch or not is irrelevant.

-Jonathan R.

Deepankar wrote:
> Folks,
>  
> In case of a softswitch based presence solution, If the PA is co-located 
> with the Proxy/Registrar with the Softswitch, then what mechanisms are 
> there for it, to know of the presence of users homed in a different 
> Softswitch.
>  
> Deeps

-- 
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



From jdrosen@dynamicsoft.com  Sat Nov  2 16:33:50 2002
Received: from IPOfCard1.guest-tek.com ([141.154.107.194])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28096
	for ; Sat, 2 Nov 2002 16:33:50 -0500 (EST)
Received: from dynamicsoft.com ([141.154.107.210])
	by IPOfCard1.guest-tek.com (8.11.6/8.8.7) with ESMTP id gA2LWPr13321;
	Sat, 2 Nov 2002 16:32:25 -0500
Message-ID: <3DC41F3C.1010301@dynamicsoft.com>
Date: Sat, 02 Nov 2002 13:53:48 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2066
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: 

Cant we solve this at the cpim-msg-sessions layer?

That draft could simply say something like "when you go to connect to 
the IP address/port that is listed there, first check if you already 
have a connection there. If so, use that again, and ignore any comedia 
stuff in the SDP."

-Jonathan R.

Paul Kyzivat wrote:
> Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in such a way that multiple sessions can be demultiplexed from a single connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for the use of the comedia spec to establish the connections. It also wishes to reuse a single connection for multiple sessions.
> 
> This presents a problem, because the comedia draft (ietf-mmusic-sdp-comedia-04) does not provide a way to share a connection among multiple sessions. It was constrained from doing so because it made no assumption about the protocol to be used on the connection. As a result it had to come up with a way to associate connections with sessions without regard to media content. 
> 
> Either a way must be found to change comedia to provide this capability, or else comedia must be abandoned in favor of some other arrangement for negotiating a connection. (It would be nice to make comedia work for this.)
> 
> Rohan and I talked about this, and began to think we could find an enhancement to comedia that would permit this, but then it got very ugly trying to figure out when connections should go away, especially between a pair of intermediaries. This is going to require some work.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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



From jdrosen@dynamicsoft.com  Sat Nov  2 16:33:50 2002
Received: from IPOfCard1.guest-tek.com ([141.154.107.194])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28091
	for ; Sat, 2 Nov 2002 16:33:50 -0500 (EST)
Received: from dynamicsoft.com ([141.154.107.210])
	by IPOfCard1.guest-tek.com (8.11.6/8.8.7) with ESMTP id gA2LWOr13316;
	Sat, 2 Nov 2002 16:32:24 -0500
Message-ID: <3DC41E11.5090306@dynamicsoft.com>
Date: Sat, 02 Nov 2002 13:48:49 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell 
CC: Paul Kyzivat , Simple 
Subject: Re: [Simple] Message Session IDs
References: <3DBEFB35.1040908@dynamicsoft.com> <3DBF311F.B8AC9254@cisco.com> <3DBF43E4.4050107@dynamicsoft.com> <3DBF6051.6020502@dynamicsoft.com> <3DBFE7D9.CE57E118@cisco.com> <3DBFEF54.1020907@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1344
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: 

Agreed that msgID belongs inside the envelope. The issue, then, is what 
MIME header are we using in the outer envelope that would be used by the 
intermediary for routing? Is there an existing one that fits the job... 
suggestions anyone?

-Jonathan R.

Ben Campbell wrote:
> Paul Kyzivat wrote:
> 
>>
>> Ben Campbell wrote:
> 
> 
> [...]
> 
>>
>>> If we were to do this, does it also make sense to move MsgID to the
>>> outer envelope?
>>
>>
>>
>> I don't know about this. If it is only needed by the endpoints then it 
>> might as well be in the inner envelope. Protecting it should help 
>> protect against some kinds of attacks.
>>
> 
> On reflection, I agree with you. I had it in my head that an 
> intermediary might use it for ordering purposes, but now that I am more 
> awake I realize there is no need for that.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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



From deepankarb@huawei.com  Sun Nov  3 10:34:26 2002
Received: from mta2 ([61.144.161.16])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01267
	for ; Sun, 3 Nov 2002 10:34:14 -0500 (EST)
Received: from mta2 (localhost [127.0.0.1])
 by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26
 2002)) with ESMTP id <0H5000HNDB9T6V@mta2.huawei.com> for
 simple@mailman.dynamicsoft.com; Sun, 03 Nov 2002 23:34:42 +0800 (CST)
Received: from huawei.com ([172.17.1.59])
 by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26
 2002)) with ESMTP id <0H5000HGJB9TI1@mta2.huawei.com> for
 simple@mailman.dynamicsoft.com; Sun, 03 Nov 2002 23:34:41 +0800 (CST)
Received: from [211.161.63.60] by mailb.huawei.com (mshttpd); Sun,
 03 Nov 2002 07:33:29 -0800
Date: Sun, 03 Nov 2002 07:33:29 -0800
From: deepankarb 70286 
Subject: Re: [Simple] Interdomain presence
To: Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
Message-id: <4b9f94bb39.4bb394b9f9@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.7 (built Jun 26 2002)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
Content-Length: 1950
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: 

Yes, thats correct, but I would try to put my query this way.

say if my PA aka softswitch is responsible for abc.com administrative domain, and there's another PA taking care of xyz.com administrative domain. Both have their set of homing subscribers (PUAs). Here, I am taking PUAs as fixed IP phones, PSTN phones. Since both belong to different administrative domains, and in case of an example of presence based voice calling, a sip caller sip:acaller@abc.com is calling sip:acallee@xyz.com, and abc.com needs to find the presence first, and then route the call. In this case, how would xyz.com indicate the presence status/document of acallee to abc.com? 

Deeps

----- Original Message -----
From: Jonathan Rosenberg 
Date: Saturday, November 2, 2002 9:03 am
Subject: Re: [Simple] Interdomain presence

> A PUA can publish presence to any PA using the SIP PUBLISH method. 
> You 
> can find the current I-D for this at:
> http://www.ietf.org/internet-drafts/draft-olson-simple-publish-01.txt
> 
> whether you call the PA a softswitch or not is irrelevant.
> 
> -Jonathan R.
> 
> Deepankar wrote:
> > Folks,
> >  
> > In case of a softswitch based presence solution, If the PA is co-
> located 
> > with the Proxy/Registrar with the Softswitch, then what 
> mechanisms are 
> > there for it, to know of the presence of users homed in a 
> different 
> > Softswitch.
> >  
> > Deeps
> 
> -- 
> 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 bcampbell@dynamicsoft.com  Sun Nov  3 11:29:45 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01440
	for ; Sun, 3 Nov 2002 11:29:45 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gA3GTFU1081249;
	Sun, 3 Nov 2002 10:29:16 -0600 (CST)
Message-ID: <3DC54ECF.4040507@dynamicsoft.com>
Date: Sun, 03 Nov 2002 10:29:03 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: Paul Kyzivat , Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2092
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: 

I agree we should do that, and avoid a dependency on getting the issue 
fixed in comedia.

It does, however, seem like a generalized issue that _should_ be handled 
in the comedia specification as well, but that does not seem to be in 
scope for this wg.

Jonathan Rosenberg wrote:
> Cant we solve this at the cpim-msg-sessions layer?
> 
> That draft could simply say something like "when you go to connect to 
> the IP address/port that is listed there, first check if you already 
> have a connection there. If so, use that again, and ignore any comedia 
> stuff in the SDP."
> 
> -Jonathan R.
> 
> Paul Kyzivat wrote:
> 
>> Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in such 
>> a way that multiple sessions can be demultiplexed from a single 
>> connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for 
>> the use of the comedia spec to establish the connections. It also 
>> wishes to reuse a single connection for multiple sessions.
>>
>> This presents a problem, because the comedia draft 
>> (ietf-mmusic-sdp-comedia-04) does not provide a way to share a 
>> connection among multiple sessions. It was constrained from doing so 
>> because it made no assumption about the protocol to be used on the 
>> connection. As a result it had to come up with a way to associate 
>> connections with sessions without regard to media content.
>> Either a way must be found to change comedia to provide this 
>> capability, or else comedia must be abandoned in favor of some other 
>> arrangement for negotiating a connection. (It would be nice to make 
>> comedia work for this.)
>>
>> Rohan and I talked about this, and began to think we could find an 
>> enhancement to comedia that would permit this, but then it got very 
>> ugly trying to figure out when connections should go away, especially 
>> between a pair of intermediaries. This is going to require some work.
>>
>>     Paul
>> _______________________________________________
>> simple mailing list
>> simple@mailman.dynamicsoft.com
>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>
> 



From jdrosen@dynamicsoft.com  Sun Nov  3 22:05:48 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03408
	for ; Sun, 3 Nov 2002 22:05:48 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.26])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA435XYH023593;
	Sun, 3 Nov 2002 22:05:37 -0500 (EST)
Message-ID: <3DC5E3FD.7030506@dynamicsoft.com>
Date: Sun, 03 Nov 2002 22:05:33 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: deepankarb 70286 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Interdomain presence
References: <4b9f94bb39.4bb394b9f9@huawei.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1193
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: 


deepankarb 70286 wrote:
 > Yes, thats correct, but I would try to put my query this way.
 >
 > say if my PA aka softswitch is responsible for abc.com administrative
 > domain, and there's another PA taking care of xyz.com administrative
 > domain. Both have their set of homing subscribers (PUAs). Here, I am
 > taking PUAs as fixed IP phones, PSTN phones. Since both belong to
 > different administrative domains, and in case of an example of
 > presence based voice calling, a sip caller sip:acaller@abc.com is
 > calling sip:acallee@xyz.com, and abc.com needs to find the presence
 > first, and then route the call. In this case, how would xyz.com
 > indicate the presence status/document of acallee to abc.com?

Thats what draft-ietf-simple-presence is for. The abc.com would 
SUBSCRIBE to the presence state at xyz.com.

-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


From rohan@cisco.com  Mon Nov  4 01:05:21 2002
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03952
	for ; Mon, 4 Nov 2002 01:05:20 -0500 (EST)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA4654xF000620;
	Sun, 3 Nov 2002 22:05:04 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ABF97048;
	Sun, 3 Nov 2002 22:02:44 -0800 (PST)
Date: Sun, 3 Nov 2002 22:05:09 -0800
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: Jonathan Rosenberg ,
        Paul Kyzivat ,
        Simple 
To: Ben Campbell 
From: Rohan Mahy 
In-Reply-To: <3DC54ECF.4040507@dynamicsoft.com>
Message-Id: <5FAFE972-EFBB-11D6-ACCB-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Length: 2636
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: 

Ben,

I think the right question to ask is:  how do a pair of intermediaries 
decide when they can terminate a connection?  this could be reference 
counting, or idle timeouts, or something else, but I think a lot of 
stuff will fall out from that decision.

thanks,
-rohan



On Sunday, November 3, 2002, at 08:29 AM, Ben Campbell wrote:

> I agree we should do that, and avoid a dependency on getting the issue 
> fixed in comedia.
>
> It does, however, seem like a generalized issue that _should_ be 
> handled in the comedia specification as well, but that does not seem 
> to be in scope for this wg.
>
> Jonathan Rosenberg wrote:
>> Cant we solve this at the cpim-msg-sessions layer?
>> That draft could simply say something like "when you go to connect to 
>> the IP address/port that is listed there, first check if you already 
>> have a connection there. If so, use that again, and ignore any 
>> comedia stuff in the SDP."
>> -Jonathan R.
>> Paul Kyzivat wrote:
>>> Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in 
>>> such a way that multiple sessions can be demultiplexed from a single 
>>> connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for 
>>> the use of the comedia spec to establish the connections. It also 
>>> wishes to reuse a single connection for multiple sessions.
>>>
>>> This presents a problem, because the comedia draft 
>>> (ietf-mmusic-sdp-comedia-04) does not provide a way to share a 
>>> connection among multiple sessions. It was constrained from doing so 
>>> because it made no assumption about the protocol to be used on the 
>>> connection. As a result it had to come up with a way to associate 
>>> connections with sessions without regard to media content.
>>> Either a way must be found to change comedia to provide this 
>>> capability, or else comedia must be abandoned in favor of some other 
>>> arrangement for negotiating a connection. (It would be nice to make 
>>> comedia work for this.)
>>>
>>> Rohan and I talked about this, and began to think we could find an 
>>> enhancement to comedia that would permit this, but then it got very 
>>> ugly trying to figure out when connections should go away, 
>>> especially between a pair of intermediaries. This is going to 
>>> require some work.
>>>
>>>     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 deepankarb@huawei.com  Mon Nov  4 03:11:58 2002
Received: from mta2 ([61.144.161.16])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04316
	for ; Mon, 4 Nov 2002 03:11:52 -0500 (EST)
Received: from mta2 (localhost [127.0.0.1])
 by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26
 2002)) with ESMTP id <0H5100MEGLGMJT@mta2.huawei.com> for
 simple@mailman.dynamicsoft.com; Mon, 04 Nov 2002 16:12:22 +0800 (CST)
Received: from huawei.com ([172.17.1.59])
 by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26
 2002)) with ESMTP id <0H5100H3BLGMI1@mta2.huawei.com> for
 simple@mailman.dynamicsoft.com; Mon, 04 Nov 2002 16:12:22 +0800 (CST)
Received: from [211.161.63.60] by mailb.huawei.com (mshttpd); Mon,
 04 Nov 2002 00:11:10 -0800
Date: Mon, 04 Nov 2002 00:11:10 -0800
From: deepankarb 70286 
Subject: Re: [Simple] Interdomain presence
To: Jonathan Rosenberg 
Cc: simple@mailman.dynamicsoft.com
Message-id: <54bbc5284b.5284b54bbc@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.7 (built Jun 26 2002)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal
Content-Length: 1636
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: 

Bingo !  But, would'nt it increase the call setup time ? 


----- Original Message -----
From: Jonathan Rosenberg 
Date: Sunday, November 3, 2002 7:05 pm
Subject: Re: [Simple] Interdomain presence

> 
> 
> deepankarb 70286 wrote:
> > Yes, thats correct, but I would try to put my query this way.
> >
> > say if my PA aka softswitch is responsible for abc.com 
> administrative > domain, and there's another PA taking care of 
> xyz.com administrative
> > domain. Both have their set of homing subscribers (PUAs). Here, 
> I am
> > taking PUAs as fixed IP phones, PSTN phones. Since both belong to
> > different administrative domains, and in case of an example of
> > presence based voice calling, a sip caller sip:acaller@abc.com is
> > calling sip:acallee@xyz.com, and abc.com needs to find the presence
> > first, and then route the call. In this case, how would xyz.com
> > indicate the presence status/document of acallee to abc.com?
> 
> Thats what draft-ietf-simple-presence is for. The abc.com would 
> SUBSCRIBE to the presence state at xyz.com.
> 
> -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 bcampbell@dynamicsoft.com  Mon Nov  4 09:19:28 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01193
	for ; Mon, 4 Nov 2002 09:19:27 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gA4EJMU1070316;
	Mon, 4 Nov 2002 08:19:23 -0600 (CST)
Message-ID: <3DC681DD.3040905@dynamicsoft.com>
Date: Mon, 04 Nov 2002 08:19:09 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: deepankarb 70286 
CC: Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Interdomain presence
References: <54bbc5284b.5284b54bbc@huawei.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2580
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: 

Certainly it will, if you need it for call routing and you don't have it 
prior to call setup. If you cannot have a delay in call setup, you must 
subscribe to the information in advance.

But submit that the application you describe is very much a classic SIP 
application, and does not gain much from a presence subscription. 
Abc.com does not need to subscribe to presence information, unless 
abc.com (or the user) expects to be notified of a presence change and 
take some action as a result of that change.

In your example, why would you not simply have abc.com proxy the call to 
xyz.com, then let xyz.com route the call based on the registered 
contacts? What routing decision is abc.com making based on presence?



deepankarb 70286 wrote:
> Bingo !  But, would'nt it increase the call setup time ? 
> 
> 
> ----- Original Message -----
> From: Jonathan Rosenberg 
> Date: Sunday, November 3, 2002 7:05 pm
> Subject: Re: [Simple] Interdomain presence
> 
> 
>>
>>deepankarb 70286 wrote:
>>
>>>Yes, thats correct, but I would try to put my query this way.
>>>
>>>say if my PA aka softswitch is responsible for abc.com 
>>
>>administrative > domain, and there's another PA taking care of 
>>xyz.com administrative
>>
>>>domain. Both have their set of homing subscribers (PUAs). Here, 
>>
>>I am
>>
>>>taking PUAs as fixed IP phones, PSTN phones. Since both belong to
>>>different administrative domains, and in case of an example of
>>>presence based voice calling, a sip caller sip:acaller@abc.com is
>>>calling sip:acallee@xyz.com, and abc.com needs to find the presence
>>>first, and then route the call. In this case, how would xyz.com
>>>indicate the presence status/document of acallee to abc.com?
>>
>>Thats what draft-ietf-simple-presence is for. The abc.com would 
>>SUBSCRIBE to the presence state at xyz.com.
>>
>>-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 pkyzivat@cisco.com  Mon Nov  4 11:03:34 2002
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 LAA01578
	for ; Mon, 4 Nov 2002 11:03:34 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA4G3ja8001045;
	Mon, 4 Nov 2002 11:03: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 AAU14201;
	Mon, 4 Nov 2002 11:08:21 -0500 (EST)
Message-ID: <3DC69A4F.245BB284@cisco.com>
Date: Mon, 04 Nov 2002 11:03:27 -0500
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: Ben Campbell 
CC: Jonathan Rosenberg ,
        Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5461
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: 

Jonathan, Ben,

I would be pleased if we can find a way to finesse this. The problem is that comedia requires some way to infer, from the sip signaling and SDP content, when connections should be made/dropped. Both sides must make the same inference, or else the connection establishment will fail. As soon as we start to pool connections there starts to be the potential for race conditions. 

This is especially a problem with connections between two intermediaries. The hard question is: when can you ever drop a connection between two intermediaries? Of course an intermediary never knows if its peer in the connection is also an intermediary or not, so it must act as if the peer is a UA following the comedia spec plus whatever additional rules we can come up with for simple. We can't drop a connection until we know that there are no sessions using it. A corollary to that is that we can't reuse a connection that has no sessions using it, because it might be dropped. And so we should drop a connection as soon as there are no sessions using it, because it is then worthless.

That already starts looking suboptimal, because we must drop connections between pairs of high traffic intermediaries any time there doesn't happen to be some session traversing them.

But I'm not sure this is workable even with that limitation. I have a hunch there is still a race condition when one end will think there is a connection and attempt to reuse it, while the other end has decided there is no session using the connection and tries to drop it or establish a new one. This is tricky, and probably impossible to decide in general except with respect to a precise rule for reuse. But here is one case that seems simpler than some others:

Suppose we are in the process of establishing a call between

	A-----I1-----I2-----B

and there was no connection between I1 and I2. A includes an offer in the invite, so I1 and I2 will each rewrite the SDP as the invite goes by. But neither I1 nor I2 yet knows if the invite will succeed, so don't know if this will result in establishing a connection.

Meanwhile, we start to establish a new call

	C-----I1-----I2-----D

C includes an offer in the invite. I1 needs to rewrite the SDP in the offer, and would like to reuse the connection it has proposed establishing with I2. But it doesn't yet know if that call will succeed and so doesn't know if the connection will be established. Hence I believe it must assume there will be no connection to reuse, and so must arrange things to establish a separate connection. Yet it is possible that both calls will succeed, so it must be prepared to establish both connections, and to discriminate them from one another. So I think it must offer a separate port in this invite.

This scenario doesn't fail, but again it is suboptimal because it may require intermediaries to listen for connections on multiple ports, and may result in redundant connections between a pair of intermediaries.

It will take more work to demonstrate a case that actually fails, or to demonstrate a reuse rule that can be proved does not fail.

	Paul


Ben Campbell wrote:
> 
> I agree we should do that, and avoid a dependency on getting the issue
> fixed in comedia.
> 
> It does, however, seem like a generalized issue that _should_ be handled
> in the comedia specification as well, but that does not seem to be in
> scope for this wg.
> 
> Jonathan Rosenberg wrote:
> > Cant we solve this at the cpim-msg-sessions layer?
> >
> > That draft could simply say something like "when you go to connect to
> > the IP address/port that is listed there, first check if you already
> > have a connection there. If so, use that again, and ignore any comedia
> > stuff in the SDP."
> >
> > -Jonathan R.
> >
> > Paul Kyzivat wrote:
> >
> >> Draft-campbell-simple-cpimmsg-sessions-00 defines the protocol in such
> >> a way that multiple sessions can be demultiplexed from a single
> >> connection. Meanwhile draft-campbell-simple-im-sessions-00 calls for
> >> the use of the comedia spec to establish the connections. It also
> >> wishes to reuse a single connection for multiple sessions.
> >>
> >> This presents a problem, because the comedia draft
> >> (ietf-mmusic-sdp-comedia-04) does not provide a way to share a
> >> connection among multiple sessions. It was constrained from doing so
> >> because it made no assumption about the protocol to be used on the
> >> connection. As a result it had to come up with a way to associate
> >> connections with sessions without regard to media content.
> >> Either a way must be found to change comedia to provide this
> >> capability, or else comedia must be abandoned in favor of some other
> >> arrangement for negotiating a connection. (It would be nice to make
> >> comedia work for this.)
> >>
> >> Rohan and I talked about this, and began to think we could find an
> >> enhancement to comedia that would permit this, but then it got very
> >> ugly trying to figure out when connections should go away, especially
> >> between a pair of intermediaries. This is going to require some work.
> >>
> >>     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 deepankarb@huawei.com  Mon Nov  4 19:54:02 2002
Received: from mta0 ([61.144.161.10])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03193
	for ; Mon, 4 Nov 2002 19:53:59 -0500 (EST)
Received: from D70286 (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H5200L2CVQYAJ@mta0.huawei.com> for
 simple@mailman.dynamicsoft.com; Tue, 05 Nov 2002 08:52:12 +0800 (CST)
Date: Tue, 05 Nov 2002 08:53:39 +0800
From: Deepankar 
Subject: Re: [Simple] Interdomain presence
To: Ben Campbell 
Cc: Jonathan Rosenberg ,
        simple@mailman.dynamicsoft.com
Message-id: <002901c28465$c79a80b0$ac064d0a@D70286>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <54bbc5284b.5284b54bbc@huawei.com>
 <3DC681DD.3040905@dynamicsoft.com>
Content-Length: 4153
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: 

Inline
----- Original Message -----
From: "Ben Campbell" 
To: "deepankarb 70286" 
Cc: "Jonathan Rosenberg" ;

Sent: Monday, November 04, 2002 10:19 PM
Subject: Re: [Simple] Interdomain presence


> Certainly it will, if you need it for call routing and you don't have it
> prior to call setup. If you cannot have a delay in call setup, you must
> subscribe to the information in advance.
[Deeps] OK. Now, when we are talking of softswitches, it means a whole bunch
of subscribers, which would be heavy, specially, when presence gets extended
to H.323 endpoints and MGCP phones. Would presencelist package work here ?
>
> But submit that the application you describe is very much a classic SIP
> application, and does not gain much from a presence subscription.
> Abc.com does not need to subscribe to presence information, unless
> abc.com (or the user) expects to be notified of a presence change and
> take some action as a result of that change.

> [Deeps] The objective is to do a fetch on the presence information, and
route the call. Subsequent notifications might not be necessary for presence
based voice calling. As above, they might be required only if say, the
presence servers/PAs on both the ends maintain a separate secure channel for
SUBSCRIBE/NOTIFY.

> In your example, why would you not simply have abc.com proxy the call to
> xyz.com, then let xyz.com route the call based on the registered
> contacts? What routing decision is abc.com making based on presence?
>
[Deeps] Then in case of a callee busy everywhere, but with some preferences
like, the incoming calls should holler him after the lunch, or call the
following delegates at these numbers, .. the call appears to be terminated
normally to abc.com, and it does'nt gain from presence information. If
abc.com would have got the updated presence information/document, before
routing the call, it would had prompted the caller for further actions.
>
>
> deepankarb 70286 wrote:
> > Bingo !  But, would'nt it increase the call setup time ?
> >
> >
> > ----- Original Message -----
> > From: Jonathan Rosenberg 
> > Date: Sunday, November 3, 2002 7:05 pm
> > Subject: Re: [Simple] Interdomain presence
> >
> >
> >>
> >>deepankarb 70286 wrote:
> >>
> >>>Yes, thats correct, but I would try to put my query this way.
> >>>
> >>>say if my PA aka softswitch is responsible for abc.com
> >>
> >>administrative > domain, and there's another PA taking care of
> >>xyz.com administrative
> >>
> >>>domain. Both have their set of homing subscribers (PUAs). Here,
> >>
> >>I am
> >>
> >>>taking PUAs as fixed IP phones, PSTN phones. Since both belong to
> >>>different administrative domains, and in case of an example of
> >>>presence based voice calling, a sip caller sip:acaller@abc.com is
> >>>calling sip:acallee@xyz.com, and abc.com needs to find the presence
> >>>first, and then route the call. In this case, how would xyz.com
> >>>indicate the presence status/document of acallee to abc.com?
> >>
> >>Thats what draft-ietf-simple-presence is for. The abc.com would
> >>SUBSCRIBE to the presence state at xyz.com.
> >>
> >>-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 Tim.Moran@nokia.com  Tue Nov  5 17:15:18 2002
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06766
	for ; Tue, 5 Nov 2002 17:15:17 -0500 (EST)
From: Tim.Moran@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA5MGCX09957
	for ; Tue, 5 Nov 2002 16:16:16 -0600 (CST)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 5 Nov 2002 16:15:15 -0600
Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 5 Nov 2002 16:15:14 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C28518.D0331702"
Date: Tue, 5 Nov 2002 16:15:13 -0600
Message-ID: <278B6B0D76698D45BBA872CD23DD496A6743CD@daebe004.americas.nokia.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Sipping digest, Vol 1 #692 - 8 msgs
Thread-Index: AcKEJKsrjJjQhyPTQjKgoqyIqFOsZAA7qWtg
To: , 
X-OriginalArrivalTime: 05 Nov 2002 22:15:14.0639 (UTC) FILETIME=[D0AB45F0:01C28518]
Content-Length: 2130
Subject: [Simple] 2 drafts on SIP Notification Filtering
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: 

This is a multi-part message in MIME format.

------_=_NextPart_001_01C28518.D0331702
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Greetings,

There are two drafts available in the ietf drafts directory related to =
the filtering of SIP notifications for clients and networks with limited =
resources.=20

The goal is to allow clients (e.g. mobile clients) to specify the rules =
whereby the sending of notifications may be restricted to when and what =
the client wishes to be notified of.

The first draft defines a set of requirements for filtering.
 <>=20
The second defines an architecture (framework) from which an =
application, e.g. presence, can define application specific filtering =
capabilities.
 <>=20

Regards,

Tim Moran

------_=_NextPart_001_01C28518.D0331702
Content-Type: application/octet-stream;
	name="draft-moran-sipping-filter-reqs-00.url"
Content-Transfer-Encoding: base64
Content-Description: draft-moran-sipping-filter-reqs-00.url
Content-Disposition: attachment;
	filename="draft-moran-sipping-filter-reqs-00.url"

W0RFRkFVTFRdDQpCQVNFVVJMPWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry
YWZ0LW1vcmFuLXNpcHBpbmctZmlsdGVyLXJlcXMtMDAudHh0DQpbSW50ZXJuZXRTaG9ydGN1dF0N
ClVSTD1odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tb3Jhbi1zaXBw
aW5nLWZpbHRlci1yZXFzLTAwLnR4dA0KTW9kaWZpZWQ9QzBFREJDM0IxNTg1QzIwMTAxDQo=

------_=_NextPart_001_01C28518.D0331702
Content-Type: application/octet-stream;
	name="draft-moran-sipping-filter-arch-01.url"
Content-Transfer-Encoding: base64
Content-Description: draft-moran-sipping-filter-arch-01.url
Content-Disposition: attachment;
	filename="draft-moran-sipping-filter-arch-01.url"

W0RFRkFVTFRdDQpCQVNFVVJMPWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry
YWZ0LW1vcmFuLXNpcHBpbmctZmlsdGVyLWFyY2gtMDEudHh0DQpbSW50ZXJuZXRTaG9ydGN1dF0N
ClVSTD1odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tb3Jhbi1zaXBw
aW5nLWZpbHRlci1hcmNoLTAxLnR4dA0KTW9kaWZpZWQ9MDBCQzdDRkYxNDg1QzIwMTkzDQo=

------_=_NextPart_001_01C28518.D0331702--

From deepankarb@huawei.com  Tue Nov  5 20:30:15 2002
Received: from mta0 ([61.144.161.10])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07430
	for ; Tue, 5 Nov 2002 20:30:13 -0500 (EST)
Received: from D70286 (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H54003GSS3IBU@mta0.huawei.com> for
 simple@mailman.dynamicsoft.com; Wed, 06 Nov 2002 09:28:31 +0800 (CST)
Date: Wed, 06 Nov 2002 09:29:58 +0800
From: Deepankar 
To: simple@mailman.dynamicsoft.com
Message-id: <007701c28534$05174580$ac064d0a@D70286>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_mjaDetrOrOcRq8nV/KBIcg)"
X-Priority: 3
X-MSMail-priority: Normal
Content-Length: 896
Subject: [Simple] Message Waiting
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: 

This is a multi-part message in MIME format.

--Boundary_(ID_mjaDetrOrOcRq8nV/KBIcg)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Folks,

Could I get directions for message waiting indicators draft.?

Deeps

--Boundary_(ID_mjaDetrOrOcRq8nV/KBIcg)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT









Folks,


 


Could I get directions for message waiting 
indicators draft.?


 


Deeps


--Boundary_(ID_mjaDetrOrOcRq8nV/KBIcg)--

From sunayak@hss.hns.com  Tue Nov  5 23:14:20 2002
Received: from hss.hns.com ([164.164.94.118])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08004
	for ; Tue, 5 Nov 2002 23:14:13 -0500 (EST)
From: sunayak@hss.hns.com
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hss.hns.com (8.11.6/8.11.2) with SMTP id gA63tbi29064;
	Wed, 6 Nov 2002 09:25:41 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256C69.0016F58F ; Wed, 6 Nov 2002 09:40:46 +0530
X-Lotus-FromDomain: HSSBLR
To: Deepankar 
cc: simple@mailman.dynamicsoft.com
Message-ID: <65256C69.0016F3AC.00@sampark.hss.hns.com>
Date: Wed, 6 Nov 2002 09:40:40 +0530
Subject: Re: [Simple] Message Waiting
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=kgiVYlESbWTXP2VwOQSi78qZBfi63BFqSi6DMqYeAhzz43YhAJvbeeno"
Content-Disposition: inline
Content-Length: 1467
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: 

--0__=kgiVYlESbWTXP2VwOQSi78qZBfi63BFqSi6DMqYeAhzz43YhAJvbeeno
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




http://www.ietf.org/internet-drafts/draft-ietf-sipping-mwi-01.txt

Subhash.




Deepankar  on 11/06/2002 06:59:58 AM

To:   simple@mailman.dynamicsoft.com
cc:    (bcc: Subhash Ullal Nayak/HSSBLR)

Subject:  [Simple] Message Waiting




Folks,

Could I get directions for message waiting indicators draft.?

Deeps


--0__=kgiVYlESbWTXP2VwOQSi78qZBfi63BFqSi6DMqYeAhzz43YhAJvbeeno
Content-type: text/html; 
	name="att-1.htm"
Content-Disposition: attachment; filename="att-1.htm"
Content-transfer-encoding: base64
Content-Description: Internet HTML

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz
by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M
IDUuMDAuMjkyMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K
PEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Gb2xr
cyw8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs
IHNpemU9Mj5Db3VsZCBJIGdldCBkaXJlY3Rpb25zIGZvciBtZXNzYWdlIHdhaXRpbmcgDQppbmRp
Y2F0b3JzIGRyYWZ0Lj88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O
VCBmYWNlPUFyaWFsIHNpemU9Mj5EZWVwczwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0KDQo=

--0__=kgiVYlESbWTXP2VwOQSi78qZBfi63BFqSi6DMqYeAhzz43YhAJvbeeno--


From Markus.Isomaki@nokia.com  Wed Nov  6 11:22:29 2002
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 LAA10094
	for ; Wed, 6 Nov 2002 11:22:28 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6GM1O20738
	for ; Wed, 6 Nov 2002 18:22:01 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Wed, 6 Nov 2002 18:21:32 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 6 Nov 2002 18:21:31 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C285B0.90BA66D6"
Date: Wed, 6 Nov 2002 18:21:30 +0200
Message-ID: 
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt
Thread-Index: AcKESzsqh/72XbQPT+2WaTbqz2HG2gBY7nGA
To: 
X-OriginalArrivalTime: 06 Nov 2002 16:21:31.0249 (UTC) FILETIME=[90F4B610:01C285B0]
Content-Length: 4966
Subject: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-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: 

This is a multi-part message in MIME format.

------_=_NextPart_001_01C285B0.90BA66D6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

The following draft is now available in the I-D directories. It is an =
initial attempt to specify a list management protocol on an abstract =
level (only semantics, no syntax). The proposal is made based on the =
requirements stated in "draft-ietf-simple-data-req-00". The draft is =
still quite drafty, but the main points should be visible.=20

The main idea is that many applications (for instance presence and =
conferencing) require lists that should be configurable by a client =
terminal. It would be useful to define a standard protocol to handle =
list manipulation (for SIP-applications), so that it could be "plugged =
in" to any application needing it.

I hope comments to the approach and to the actual abstract protocol. If =
this is a good enough start, it could be used as a basis for a WG =
document. After that would be reasonably stable, a mapping to some real =
syntax could be made and that specifation should be in standards track.

Markus =20

> -----Original Message-----
> From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
> Sent: 04 November, 2002 17:05
> Subject: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt
>=20
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
>=20
>=20
> 	Title		: Semantic Description of SIMPLE List=20
> Manipulation=20
>                           Operations
> 	Author(s)	: M. Isomaki et al.
> 	Filename	: draft-isomaki-simple-list-man-sem-00.txt
> 	Pages		: 13
> 	Date		: 2002-11-1
> =09
> In SIMPLE based presence and messaging applications, it is necessary=20
> for  the user to be able to configure a number of pieces of=20
> information.=20
> One of the most common types of information is a list of URIs. List=20
> management is useful outside the scope of SIMPLE as well, for=20
> instance=20
> in conferencing. There are many reasons why it would be beneficial to=20
> manage the lists in a similar fashion regardless of the application.=20
> Before the selection of the actual protocol(s) to manage the=20
> lists there=20
> is a need to describe their semantics on an abstract level. This=20
> document proposes the semantics for SIMPLE list manipulation protocol.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-isomaki-simple-list-
man-sem-00.txt

To remove yourself from the IETF Announcement list, send a message to=20
ietf-announce-request with the word unsubscribe in the body of the =
message.

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-isomaki-simple-list-man-sem-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-isomaki-simple-list-man-sem-00.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_001_01C285B0.90BA66D6
Content-Type: application/octet-stream;
	name="ATT840765.TXT"
Content-Transfer-Encoding: base64
Content-Description: ATT840765.TXT
Content-Disposition: attachment;
	filename="ATT840765.TXT"

Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7DQoJYWNjZXNzLXR5cGU9Im1haWwt
c2VydmVyIjsNCglzZXJ2ZXI9Im1haWxzZXJ2QGlldGYub3JnIg0KDQpDb250ZW50LVR5cGU6IHRl
eHQvcGxhaW4NCkNvbnRlbnQtSUQ6CTwyMDAyLTExLTExNDMzMzkuSS1EQGlldGYub3JnPg0KDQpF
TkNPRElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaXNvbWFraS1zaW1wbGUt
bGlzdC1tYW4tc2VtLTAwLnR4dA0K

------_=_NextPart_001_01C285B0.90BA66D6
Content-Type: application/octet-stream;
	name="draft-isomaki-simple-list-man-sem-00.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-isomaki-simple-list-man-sem-00.URL
Content-Disposition: attachment;
	filename="draft-isomaki-simple-list-man-sem-00.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pc29tYWtpLXNpbXBsZS1saXN0LW1hbi1zZW0tMDAudHh0DQo=

------_=_NextPart_001_01C285B0.90BA66D6--

From jdrosen@dynamicsoft.com  Wed Nov  6 11:58:59 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10306
	for ; Wed, 6 Nov 2002 11:58:59 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.7])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gA6Gx0YH025553;
	Wed, 6 Nov 2002 11:59:00 -0500 (EST)
Message-ID: <3DC94A52.4060505@dynamicsoft.com>
Date: Wed, 06 Nov 2002 11:58:58 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Ben Campbell ,
        Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 9618
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: 

inline.

Paul Kyzivat wrote:
 > Jonathan, Ben,
 >
 > I would be pleased if we can find a way to finesse this. The problem
 > is that comedia requires some way to infer, from the sip signaling
 > and SDP content, when connections should be made/dropped. Both sides
 > must make the same inference, or else the connection establishment
 > will fail. As soon as we start to pool connections there starts to be
 > the potential for race conditions.
 >
 > This is especially a problem with connections between two
 > intermediaries. The hard question is: when can you ever drop a
 > connection between two intermediaries?

I don't see this as that critical. I would guess that the passive side 
of a connection can always close, and the active side would just reopen 
if the session isn't terminated. No? I think comedia says you shouldnt 
close the connection before the session ends, but sometimes that happens 
for a variety of reasons. It should say something about retrying.


f course an intermediary
 > never knows if its peer in the connection is also an intermediary or
 > not, so it must act as if the peer is a UA following the comedia spec
 > plus whatever additional rules we can come up with for simple.

Right.

 > We
 > can't drop a connection until we know that there are no sessions
 > using it. A corollary to that is that we can't reuse a connection
 > that has no sessions using it, because it might be dropped. And so we
 > should drop a connection as soon as there are no sessions using it,
 > because it is then worthless.
 >
 > That already starts looking suboptimal, because we must drop
 > connections between pairs of high traffic intermediaries any time
 > there doesn't happen to be some session traversing them.

I think you want to decouple the connection lifetimes from the session 
lifetimes.

 >
 > But I'm not sure this is workable even with that limitation. I have a
 > hunch there is still a race condition when one end will think there
 > is a connection and attempt to reuse it, while the other end has
 > decided there is no session using the connection and tries to drop it
 > or establish a new one. This is tricky, and probably impossible to
 > decide in general except with respect to a precise rule for reuse.
 > But here is one case that seems simpler than some others:
 >
 > Suppose we are in the process of establishing a call between
 >
 > A-----I1-----I2-----B
 >
 > and there was no connection between I1 and I2. A includes an offer in
 > the invite, so I1 and I2 will each rewrite the SDP as the invite goes
 > by. But neither I1 nor I2 yet knows if the invite will succeed, so
 > don't know if this will result in establishing a connection.
 >
 > Meanwhile, we start to establish a new call
 >
 > C-----I1-----I2-----D
 >
 > C includes an offer in the invite. I1 needs to rewrite the SDP in the
 > offer, and would like to reuse the connection it has proposed
 > establishing with I2. But it doesn't yet know if that call will
 > succeed and so doesn't know if the connection will be established.
 > Hence I believe it must assume there will be no connection to reuse,

This is an artifact of a very bad design choice made by comedia.

What you REALLY want is that whenever I1 modifies an INVITE, it *always* 
puts the same port number/IP into the SDP. Multiple connections can be 
established onto that IP/port. Thus, both the INVITE from A and from C, 
I1 would place the same IP/port into the SDP.

Now, if either of those should succeed, I1 will try to open a connection 
to that IP/port. If it already has one there, that gets reused.

So, whats the problem? Well, all intermediaries need to maintain a 
routing table, which tells them what to do with incoming messages. That 
table tells them that if an IM arrives on some specific connection, with 
a specific URI/identifier in the outer envelope, to forward to a 
different connection with a different URI/identifier in the outer 
envelope. THis means that the intermediary has to associate each 
connection with a specific dialog used to set it up (since the dialog is 
used to exchange the SDP that contains the URI/identifiers). How is this 
association done?

Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out 
by A in your example contains the source IP/port it will make the 
connection from. So, when I1 receives the connection request, it can 
determine the source, and then match it to the dialog. The problem is, 
this doesn't work at all through NAT. If you don't want to use the 
source to demux, the intermediary can arrange for each connection to 
occur on a different port, and that means no reuse. So, we have a real 
problem.

I registered this complaint about comedia/NAT to mmusic some time back, 
but it was ignored. IMHO its still a show stopper. Its especially 
heinous when you want to add intermediaries, which wasn't considered at 
the time.

My proposal would be to use connection identifiers separate from 
addresses. The SDP contains some kind of parameter that identifies the 
connection. Its just a random token. Whenever the connection is opened, 
the active side sends, as the first bytes, this identifier. THis way, 
the passive side knows which dialog its associated with, without needing 
to rely on source IP.

So, lets go through an example of how this works with a single 
intermediary. We've got A----I-----B:

* A sends an INVITE. SDP has a connection identifier of CID-A1 and a URI 
of sip:A1. Through comedia it says it can be both active or passive. Of 
course we want it to be active in case its natted. This goes to I.

* I rewrites the SDP. It places a different IP/port (some common one 
used in all requests), and a new connection ID, CID-I1. It rewrites the 
address to sip:I1. It also indicates passive only. Note that, since its 
passive, the connection ID isn't important. This goes to B.

* B sends a 200 OK. It indicates active in its SDP. It includes a 
connection ID of CID-B1 and URI of sip:B1.

* I rewrites the SDP in the 200 OK. It includes the same common IP/port, 
but yet another connection ID, CID-I2 and URI sip:I2. Forwards to A. 
Now, I knows that messages from sip:A1 on either connection CID-I2 or 
CID-A1 go to sip:B1, on either connection CID-I1 or CID-B1. Which 
connection depends on which direction establishes.

* A opens a connection to I. Once opened, it passes CID-A1 on the 
connection. Now, I knows that this connection corresponds to the dialog 
it established with A. Similarly, B opens a connection to I, passes 
CID-B1, and I knows that this connection is associated with the dialog 
opened to B. Forwarding happens.


Now, consider the more complex case, of two intermediaries. So its 
A---I---IJ---B. Lets say there is already a connection opened between I 
and J. I had indicated a connection ID of CID-I1, and J had indicated 
CID-J1.

* A sends an INVITE. connection ID is new, CID-A1. URI is sip:A1. It 
indicates direction:both. Includes some IP/port for receiving connections.

* I gets the INVITE. Rewrites the SDP to CID-I2 (a new ID - since it 
doesn't know who will get this, whether a connection is there already). 
Rewrites the URI to sip:I2. Direction passive. Includes its common 
IP/port. Sends to J.

* J gets the INVITE. Rewrites the SDP to CID-J2, also a new ID. Rewrites 
the URI to sip:J2. Direction, passive. Includes its common IP/port. 
Sends to B.

* B gets the INVITE. Sends a 200 OK. B notices it doesn't have a 
connection to the IP/port indicated by J in the SDP. So, it creates a 
new CID, CID-B1, and places that in its SDP, along with direction:active.

* J gets the 200 OK. J notices that it does have a connection to the 
IP/port in the INVITE it received. So, it decides it can reuse that 
connection. So, it rewrites the SDP in the 200 OK with CID-J1 (the ID it 
had formerly exchanged with I), and indicates a direction of active. 
FOrwards to I.

* I gets the 200 OK. I sees that it DOESNT have a connection to the 
IP/port that A provided, so it creates a new connection ID, CID-I3, and 
places that in the 200 OK. It indicates a direction of passive. Places 
its common IP/port in the SDP, sends to A.

* Now, the SDP that A got indicated passive. So, it opens a connection 
to the IP/port provided by I. It sends its proposed connection ID, 
CID-A1 once the connection is opened.

* The SDP that B got indicated passive. So, it opens a connection to the 
IP/port that J provided. It sends its proposed connection ID, CID-B1, 
once the connection is opened.

* I and J realize that the connection IDs exchanged betwen them relate 
to an existing connection, so they don't open a new one.


If the connection between I and J should close, either side would 
re-initiate, and it would reuse the connection ID it had stored and 
remembered as associated with the destiation IP/port it needs to open a 
connection to.


Now, I *think* this works. I'm a bit hazy on the precise rules of usage 
and reuse of these connection IDs. THe aim is to do something that 
doesnt require a re-INVITE when a new connection is opened. Again - we 
want to separate connection lifetime from session lifetime.

This solution allows for connection reuse and also works smoothly 
through NAT without any pains.

Thoughts?

-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


From Pekka.Pessi@nokia.com  Wed Nov  6 13:16:12 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10586
	for ; Wed, 6 Nov 2002 13:16:11 -0500 (EST)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6IGeB03392
	for ; Wed, 6 Nov 2002 20:16:40 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 6 Nov 2002 20:16:09 +0200
Received: from agni.research.nokia.com ([172.21.40.24]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 6 Nov 2002 20:16:09 +0200
Received: from agni.research.nokia.com (localhost [127.0.0.1])
	by agni.research.nokia.com (8.12.5/8.12.5) with ESMTP id gA6IG7hP026161;
	Wed, 6 Nov 2002 20:16:07 +0200
Received: (from ppessi@localhost)
	by agni.research.nokia.com (8.12.5/8.12.5/Submit) id gA6IG7Gt026160;
	Wed, 6 Nov 2002 20:16:07 +0200
X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f
To: , 
Cc: Stephane.Coulombe@nokia.com, Pekka.Pessi@nokia.com,
        Jose.Costa-Requena@nokia.com
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 
Date: 06 Nov 2002 20:16:07 +0200
In-Reply-To: <278B6B0D76698D45BBA872CD23DD496A6743CD@daebe004.americas.nokia.com>
Message-ID: 
Lines: 28
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 06 Nov 2002 18:16:09.0919 (UTC) FILETIME=[94F674F0:01C285C0]
Content-Length: 1127
Subject: [Simple] Re: [Sipping] 2 drafts on SIP Notification Filtering
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: 

Hello all,

We have submitted two drafts regarding multimedia message
adaptation. A multimedia message is typically a message
containing images, audio or video clips and their presentation
information, e.g., smil. Also, even XML-formatted text may
require adaptation in some cases.

Our goal is to have a framework using SIP, HTTP and MIME that
allows a person sending multimedia message to adapt the message
contents suitable to all the recipients. In some cases the
adaptation can be done by the sending terminal, but we also see
that an adaptation service would be very useful in many cases. 
Such an adaptation mechanism is used by MMS service provided by
cellular networks nowadays.

The message adaptation work concerns both SIPPING and SIMPLE,
the requirements I-D lists use cases and requirements for
multimedia messaging and message adaptation solutions and the
framework I-D tries to explore possible solutions.

Best regards,
				Pekka


http://www.ietf.org/internet-drafts/draft-coulombe-message-adaptation-framework-00.txt

http://www.ietf.org/internet-drafts/draft-coulombe-message-adaptation-requirements-00.txt

From Pekka.Pessi@nokia.com  Wed Nov  6 13:24:23 2002
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 NAA10631
	for ; Wed, 6 Nov 2002 13:24:22 -0500 (EST)
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA6INtO22922
	for ; Wed, 6 Nov 2002 20:23:55 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 6 Nov 2002 20:24:15 +0200
Received: from agni.research.nokia.com ([172.21.40.24]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 6 Nov 2002 20:24:15 +0200
Received: from agni.research.nokia.com (localhost [127.0.0.1])
	by agni.research.nokia.com (8.12.5/8.12.5) with ESMTP id gA6IODhP026209;
	Wed, 6 Nov 2002 20:24:13 +0200
Received: (from ppessi@localhost)
	by agni.research.nokia.com (8.12.5/8.12.5/Submit) id gA6IODGQ026208;
	Wed, 6 Nov 2002 20:24:13 +0200
X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f
To: , 
References: 
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: 
Date: 06 Nov 2002 20:24:13 +0200
Message-ID: 
Lines: 29
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 06 Nov 2002 18:24:15.0713 (UTC) FILETIME=[B684BD10:01C285C1]
Content-Length: 1295
Subject: [Simple] Multimedia message adaptation Internet-Drafts
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: 

	While these drafts concern event filtering, too, the subject was
	a bit misleading because I lazily just followed up Tim's e-mail.

					Pekka

http://www.ietf.org/internet-drafts/draft-coulombe-message-adaptation-framework-00.txt

http://www.ietf.org/internet-drafts/draft-coulombe-message-adaptation-requirements-00.txt

Pekka Pessi  writes:
>We have submitted two drafts regarding multimedia message
>adaptation. A multimedia message is typically a message
>containing images, audio or video clips and their presentation
>information, e.g., smil. Also, even XML-formatted text may
>require adaptation in some cases.

>Our goal is to have a framework using SIP, HTTP and MIME that
>allows a person sending multimedia message to adapt the message
>contents suitable to all the recipients. In some cases the
>adaptation can be done by the sending terminal, but we also see
>that an adaptation service would be very useful in many cases. 
>Such an adaptation mechanism is used by MMS service provided by
>cellular networks nowadays.

>The message adaptation work concerns both SIPPING and SIMPLE,
>the requirements I-D lists use cases and requirements for
>multimedia messaging and message adaptation solutions and the
>framework I-D tries to explore possible solutions.


From drage@lucent.com  Wed Nov  6 13:51:50 2002
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10760
	for ; Wed, 6 Nov 2002 13:51:50 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gA6IpmF19806
	for ; Wed, 6 Nov 2002 13:51:48 -0500 (EST)
Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 6 Nov 2002 18:51:47 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" 
To: sipping@ietf.org, simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Multimedia message adaptation Internet-Drafts
Date: Wed, 6 Nov 2002 18:51:46 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Content-Length: 2262
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: 

I am getting a bit confused as to which group should be discussing these filtering issues.

Could we have a statement from the WG chairs of SIPPING or SIMPLE as to whether this, and the moran drafts, are part of the scope of SIPPING or SIMPLE.

And before you say these are both author drafts, I think we do need to charter one of the WGs to do some work in this area - I am just not sure of the exact scope yet.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 

> -----Original Message-----
> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> Sent: 06 November 2002 18:24
> To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: [Simple] Multimedia message adaptation Internet-Drafts
> 
> 
> 	While these drafts concern event filtering, too, the subject was
> 	a bit misleading because I lazily just followed up Tim's e-mail.
> 
> 					Pekka
> 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> ptation-framework-00.txt
> 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> ptation-requirements-00.txt
> 
> Pekka Pessi  writes:
> >We have submitted two drafts regarding multimedia message
> >adaptation. A multimedia message is typically a message
> >containing images, audio or video clips and their presentation
> >information, e.g., smil. Also, even XML-formatted text may
> >require adaptation in some cases.
> 
> >Our goal is to have a framework using SIP, HTTP and MIME that
> >allows a person sending multimedia message to adapt the message
> >contents suitable to all the recipients. In some cases the
> >adaptation can be done by the sending terminal, but we also see
> >that an adaptation service would be very useful in many cases. 
> >Such an adaptation mechanism is used by MMS service provided by
> >cellular networks nowadays.
> 
> >The message adaptation work concerns both SIPPING and SIMPLE,
> >the requirements I-D lists use cases and requirements for
> >multimedia messaging and message adaptation solutions and the
> >framework I-D tries to explore possible solutions.
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From pkyzivat@cisco.com  Wed Nov  6 13:54:30 2002
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 NAA10792
	for ; Wed, 6 Nov 2002 13:54:30 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA6IsfOH012378;
	Wed, 6 Nov 2002 13:54:42 -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 AAU32850;
	Wed, 6 Nov 2002 13:59:16 -0500 (EST)
Message-ID: <3DC9655E.1C8CBDA1@cisco.com>
Date: Wed, 06 Nov 2002 13:54:22 -0500
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 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 5763
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: 

Jonathan - comments inline.

	Paul

Jonathan Rosenberg wrote:
> 
>  > This is especially a problem with connections between two
>  > intermediaries. The hard question is: when can you ever drop a
>  > connection between two intermediaries?
> 
> I don't see this as that critical. I would guess that the passive side
> of a connection can always close, and the active side would just reopen
> if the session isn't terminated. No? I think comedia says you shouldnt
> close the connection before the session ends, but sometimes that happens
> for a variety of reasons. It should say something about retrying.

I should have been clearer - I meant that this is a hard question given the current specification of comedia. There may well be modifications to comedia or alternatives to comedia where this isn't hard.

But comedia is the way it is because of assumptions made around its requirements. Those assumptions will need to be changed to get to a different solution.

> I think you want to decouple the connection lifetimes from the session
> lifetimes.

This is one of those assumtions. *If* you decouple these, then it is necessary to retain a listener for connections on the advertised port even after a connection is established. This gets to be a problem when it is also necessary to dedicate a port for each distinct session in progress. Its all a house of cards.

> 
>  >
>  > But I'm not sure this is workable even with that limitation. I have a
>  > hunch there is still a race condition when one end will think there
>  > is a connection and attempt to reuse it, while the other end has
>  > decided there is no session using the connection and tries to drop it
>  > or establish a new one. This is tricky, and probably impossible to
>  > decide in general except with respect to a precise rule for reuse.
>  > But here is one case that seems simpler than some others:
>  >
>  > Suppose we are in the process of establishing a call between
>  >
>  > A-----I1-----I2-----B
>  >
>  > and there was no connection between I1 and I2. A includes an offer in
>  > the invite, so I1 and I2 will each rewrite the SDP as the invite goes
>  > by. But neither I1 nor I2 yet knows if the invite will succeed, so
>  > don't know if this will result in establishing a connection.
>  >
>  > Meanwhile, we start to establish a new call
>  >
>  > C-----I1-----I2-----D
>  >
>  > C includes an offer in the invite. I1 needs to rewrite the SDP in the
>  > offer, and would like to reuse the connection it has proposed
>  > establishing with I2. But it doesn't yet know if that call will
>  > succeed and so doesn't know if the connection will be established.
>  > Hence I believe it must assume there will be no connection to reuse,
> 
> This is an artifact of a very bad design choice made by comedia.
> 
> What you REALLY want is that whenever I1 modifies an INVITE, it *always*
> puts the same port number/IP into the SDP. Multiple connections can be
> established onto that IP/port. Thus, both the INVITE from A and from C,
> I1 would place the same IP/port into the SDP.
> 
> Now, if either of those should succeed, I1 will try to open a connection
> to that IP/port. If it already has one there, that gets reused.
> 
> So, whats the problem? Well, all intermediaries need to maintain a
> routing table, which tells them what to do with incoming messages. That
> table tells them that if an IM arrives on some specific connection, with
> a specific URI/identifier in the outer envelope, to forward to a
> different connection with a different URI/identifier in the outer
> envelope. THis means that the intermediary has to associate each
> connection with a specific dialog used to set it up (since the dialog is
> used to exchange the SDP that contains the URI/identifiers). How is this
> association done?
> 
> Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out
> by A in your example contains the source IP/port it will make the
> connection from. So, when I1 receives the connection request, it can
> determine the source, and then match it to the dialog. The problem is,
> this doesn't work at all through NAT. If you don't want to use the
> source to demux, the intermediary can arrange for each connection to
> occur on a different port, and that means no reuse. So, we have a real
> problem.
> 
> I registered this complaint about comedia/NAT to mmusic some time back,
> but it was ignored. IMHO its still a show stopper. Its especially
> heinous when you want to add intermediaries, which wasn't considered at
> the time.

Once again, this is a matter of conflicting assumptions/requirements.

Sharing of a connection by different sessions, or even sharing of the port to which connections are made, requires that you be able to correlate some unique session identifier passed in the SDP session description with something passed through the resulting connection. But that places a constraint on the kind of protocol that is used over the connection.

The comedia work was already in progress when I discovered it. It was my perception that placing requirements on the protocol to be used over the connection was out of scope. I tried to get some revisions into comedia that would make it more palatable within those constraints. But I must agree with you that the result is pretty ugly - nothing that I would prefer to use.

I think it would be a good thing to revisit the assumptions behind comedia and then come up with something better that satisfies them. I don't know if this should be viewed as a revision to comedia or simply something new. 

My point in bringing this up wrt draft-campbell-simple-*-sessions-00 is that the existing comedia draft (draft-ietf-mmusic-sdp-comedia-04) doesn't provide the needed functionality.

	Paul

From Pekka.Pessi@nokia.com  Thu Nov  7 08:41:14 2002
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 IAA14114
	for ; Thu, 7 Nov 2002 08:41:13 -0500 (EST)
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA7DekO03087
	for ; Thu, 7 Nov 2002 15:40:46 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 7 Nov 2002 15:41:12 +0200
Received: from agni.research.nokia.com ([172.21.40.24]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 7 Nov 2002 15:41:12 +0200
Received: from agni.research.nokia.com (localhost [127.0.0.1])
	by agni.research.nokia.com (8.12.5/8.12.5) with ESMTP id gA7Df9hP028341;
	Thu, 7 Nov 2002 15:41:09 +0200
Received: (from ppessi@localhost)
	by agni.research.nokia.com (8.12.5/8.12.5/Submit) id gA7Df8IN028340;
	Thu, 7 Nov 2002 15:41:08 +0200
X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f
To: 
Cc: Ben Campbell 
Subject: Re: [Simple] Message Session IDs
References: <3DBEFB35.1040908@dynamicsoft.com>
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: <3DBEFB35.1040908@dynamicsoft.com>
Date: 07 Nov 2002 15:41:08 +0200
Message-ID: 
Lines: 35
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 07 Nov 2002 13:41:12.0830 (UTC) FILETIME=[565831E0:01C28663]
Content-Length: 1266
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: 

Ben Campbell  writes:
>draft-campbell-simple-im-sessions-00 discusses the use of the SDP
>offer/answer model for initiating message sessions, without talking much
>about the message sessions themselves.

	There are some things with SDP that might require modifications. 
	I would use the default mapping from SDP spec, according to it
	the message/cpim would be presented like m=message (port)
	(tport) cpim. I would also list the inner MIME types in fmtp or
	similar attribute line.

	So, instead of

m=message 8937 cpim/tls text/plain text/html

	I would write it like this:

m=message 8937 tls cpim
a=fmtp:cpim accept:text/plain,text/html

	As an added bonus, this would also work:

m=message 8937 tls/sctp cpim sip sipfrag
	
>draft-campbell-simple-cpimmsg-sessions-00 proposes a message session
>transport that involves transporting messages over TCP or TLS using the
>message/cpim format. This draft depends on the signaling methods described
>in the im-sessions draft.

	The comedia draft does not define how the application should
	behave when a connection is closed (except with direction:both,
	which states that the endpoint SHOULD close an idle connection). 
	An explicit message like RTCP BYE might be useful here.

					Pekka

From rsparks@dynamicsoft.com  Thu Nov  7 15:01:18 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15216
	for ; Thu, 7 Nov 2002 15:01:18 -0500 (EST)
Received: from RjS.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gA7K1H124640;
	Thu, 7 Nov 2002 14:01:17 -0600
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Cc: "jon.peterson@neustar.biz" 
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 07 Nov 2002 13:54:29 -0600
Message-Id: <1036698869.12174.51.camel@RjS.localdomain>
Mime-Version: 1.0
Content-Length: 1701
Subject: [Simple] SIMPLE IETF55 agenda requests
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: 

Folks -

The following represents (in no particular order) the requests I've
received for agenda time at the Atlanta meeting. If you think you've
asked for time not represented here, let me know ASAP.

I'll turn this into an actual agenda over the next couple of days.
There's a lot to cover here, and we have only a two hour meeting.

Remember that the meeting time needs to focus on resolving open issues,
not presenting drafts. We will be focusing on those drafts that are
receiving attention on the list.

RjS
--------------------------------------------------------------------------------------

Jonathan Rosenberg - Data Requirements
http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-00.txt

Aki Niemi - 3GPP messaging and presence requirements
http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-reqs-00.txt
http://www.ietf.org/internet-drafts/draft-kiss-simple-presence-wireless-reqs-01.txt

Paul Kyzivat - SIP Presence extensions
http://www.ietf.org/internet-drafts/draft-kyzivat-simple-prescaps-reqts-00.txt

Markus Isomaki - Semantic Description of SIMPLE List Manipulation
Operations
http://www.ietf.org/internet-drafts/draft-isomaki-simple-list-man-sem-00.txt

Robert Sparks - XMPP sessions
http://www.ietf.org/internet-drafts/draft-sparks-simple-jabber-sessions-00.txt

Adam Roach - List Templates
http://www.ietf.org/internet-drafts/draft-roach-sip-list-template-00.txt

Ben Campbell - Message Sessions
http://www.ietf.org/internet-drafts/draft-campbell-simple-im-sessions-00.txt
http://www.ietf.org/internet-drafts/draft-campbell-simple-cpimmsg-sessions-00.txt

Sean Olson - Publish
http://www.ietf.org/internet-drafts/draft-olson-simple-publish-01.txt




From scoya@cnri.reston.va.us  Thu Nov  7 15:16:28 2002
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 PAA15291
	for ; Thu, 7 Nov 2002 15:16:28 -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 PAA08965
	for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST)
Message-Id: <200211072011.PAA08965@ietf.org>
From: The IESG 
To: All IETF Working Groups: ;
x-msg: NoteWell
Date: Thu, 07 Nov 2002 15:11:40 -0500
Content-Length: 1229
Subject: [Simple] Note Well Statement
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: 

From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.

From dean.willis@softarmor.com  Thu Nov  7 22:07:43 2002
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16543
	for ; Thu, 7 Nov 2002 22:07:42 -0500 (EST)
Received: from kevlar.softarmor.com (kevlar.softarmor.com [127.0.0.1])
	by kevlar.softarmor.com (8.12.5/8.12.5) with ESMTP id gA83AsHF020532;
	Thu, 7 Nov 2002 21:10:54 -0600
Received: (from dwillis@localhost)
	by kevlar.softarmor.com (8.12.5/8.12.5/Submit) id gA83Ap4f020530;
	Thu, 7 Nov 2002 21:10:51 -0600
X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptation
	Internet-Drafts
From: Dean Willis 
To: "Drage, Keith (Keith)" 
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
In-Reply-To: 
	<475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com>
References: 
	<475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 07 Nov 2002 21:10:50 -0600
Message-Id: <1036725050.20411.2.camel@kevlar.softarmor.com>
Mime-Version: 1.0
Content-Length: 3122
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: 

Well, I'd like to hear opinions from the participants here . . .

Clearly they aren't explicitly on the charter for either group. Do we as
yet have a consensus that we need to work on these problems? If so, we
can consider WHERE to work on them. I suspect SIPPING is closer to a
matching scope than is SIMPLE, but the relevant ADs may have suggestions
to make there as well.

--
Dean

On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> I am getting a bit confused as to which group should be discussing these filtering issues.
> 
> Could we have a statement from the WG chairs of SIPPING or SIMPLE as to whether this, and the moran drafts, are part of the scope of SIPPING or SIMPLE.
> 
> And before you say these are both author drafts, I think we do need to charter one of the WGs to do some work in this area - I am just not sure of the exact scope yet.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com 
> 
> > -----Original Message-----
> > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > Sent: 06 November 2002 18:24
> > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: [Simple] Multimedia message adaptation Internet-Drafts
> > 
> > 
> > 	While these drafts concern event filtering, too, the subject was
> > 	a bit misleading because I lazily just followed up Tim's e-mail.
> > 
> > 					Pekka
> > 
> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > ptation-framework-00.txt
> > 
> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > ptation-requirements-00.txt
> > 
> > Pekka Pessi  writes:
> > >We have submitted two drafts regarding multimedia message
> > >adaptation. A multimedia message is typically a message
> > >containing images, audio or video clips and their presentation
> > >information, e.g., smil. Also, even XML-formatted text may
> > >require adaptation in some cases.
> > 
> > >Our goal is to have a framework using SIP, HTTP and MIME that
> > >allows a person sending multimedia message to adapt the message
> > >contents suitable to all the recipients. In some cases the
> > >adaptation can be done by the sending terminal, but we also see
> > >that an adaptation service would be very useful in many cases. 
> > >Such an adaptation mechanism is used by MMS service provided by
> > >cellular networks nowadays.
> > 
> > >The message adaptation work concerns both SIPPING and SIMPLE,
> > >the requirements I-D lists use cases and requirements for
> > >multimedia messaging and message adaptation solutions and the
> > >framework I-D tries to explore possible solutions.
> > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 


From Markus.Isomaki@nokia.com  Fri Nov  8 06:46:42 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18176
	for ; Fri, 8 Nov 2002 06:46:41 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8BlCB04414
	for ; Fri, 8 Nov 2002 13:47:12 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 8 Nov 2002 13:46:34 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 8 Nov 2002 13:46:37 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Date: Fri, 8 Nov 2002 13:46:36 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKG1KTa2SE/J0KdTJCVUzzcD3eDCAARX8MA
To: , , ,
        
Cc: , 
X-OriginalArrivalTime: 08 Nov 2002 11:46:37.0845 (UTC) FILETIME=[7EF27C50:01C2871C]
Content-Length: 4831
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA18176
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: 

Hi,

Actually this thread is about two separate things:
- Event filtering
- Multimedia message adaptation

Neither of them appears currently on any sippish WG charter currently. 

Event filtering has been discussed several times and it is even mentioned in (but out of scope of) SIP Events RFC. My impression has been that people think that it is needed, but there has been debate about scope and feasibility. I hope the requirements draft will help in that discussion. My own opinion is that what is concretely needed in short term is some simple filtering definitions for Presence event package. More wide-scoped and complex things could be worked upon as the understanding accumulates.

Multimedia message adaptation hasn't been yet discussed much. I think it is in general a desirable feature, especially for relatively small and dumb terminals, which are not easily upgradable and may not understand all media formats.

So I propose the WG chairs think where these items would be appropriate, and if there is enough interest for them, let's put them on the charters.

Markus

> -----Original Message-----
> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 08 November, 2002 5:11
> To: Drage, Keith (Keith)
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: Re: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> Well, I'd like to hear opinions from the participants here . . .
> 
> Clearly they aren't explicitly on the charter for either 
> group. Do we as
> yet have a consensus that we need to work on these problems? If so, we
> can consider WHERE to work on them. I suspect SIPPING is closer to a
> matching scope than is SIMPLE, but the relevant ADs may have 
> suggestions
> to make there as well.
> 
> --
> Dean
> 
> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > I am getting a bit confused as to which group should be 
> discussing these filtering issues.
> > 
> > Could we have a statement from the WG chairs of SIPPING or 
> SIMPLE as to whether this, and the moran drafts, are part of 
> the scope of SIPPING or SIMPLE.
> > 
> > And before you say these are both author drafts, I think we 
> do need to charter one of the WGs to do some work in this 
> area - I am just not sure of the exact scope yet.
> > 
> > Keith
> > 
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: drage@lucent.com 
> > 
> > > -----Original Message-----
> > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > Sent: 06 November 2002 18:24
> > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: [Simple] Multimedia message adaptation Internet-Drafts
> > > 
> > > 
> > > 	While these drafts concern event filtering, too, the subject was
> > > 	a bit misleading because I lazily just followed up Tim's e-mail.
> > > 
> > > 					Pekka
> > > 
> > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > ptation-framework-00.txt
> > > 
> > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > ptation-requirements-00.txt
> > > 
> > > Pekka Pessi  writes:
> > > >We have submitted two drafts regarding multimedia message
> > > >adaptation. A multimedia message is typically a message
> > > >containing images, audio or video clips and their presentation
> > > >information, e.g., smil. Also, even XML-formatted text may
> > > >require adaptation in some cases.
> > > 
> > > >Our goal is to have a framework using SIP, HTTP and MIME that
> > > >allows a person sending multimedia message to adapt the message
> > > >contents suitable to all the recipients. In some cases the
> > > >adaptation can be done by the sending terminal, but we also see
> > > >that an adaptation service would be very useful in many cases. 
> > > >Such an adaptation mechanism is used by MMS service provided by
> > > >cellular networks nowadays.
> > > 
> > > >The message adaptation work concerns both SIPPING and SIMPLE,
> > > >the requirements I-D lists use cases and requirements for
> > > >multimedia messaging and message adaptation solutions and the
> > > >framework I-D tries to explore possible solutions.
> > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jon.peterson@neustar.biz  Fri Nov  8 07:57:42 2002
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18395
	for ; Fri, 8 Nov 2002 07:57:41 -0500 (EST)
Received: from cypress.neustar.com (stih650a-eth-s1p2c0.va.neustar.com [209.173.53.81])
	by willow.neustar.com (8.11.6/8.11.6) with ESMTP id gA8Cvei15184;
	Fri, 8 Nov 2002 12:57:40 GMT
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11])
	by cypress.neustar.com (8.11.6/8.11.6) with ESMTP id gA8CvYX12331;
	Fri, 8 Nov 2002 12:57:34 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 8 Nov 2002 07:58:23 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB39A@stntexch2.va.neustar.com>
From: "Peterson, Jon" 
To: "'Markus.Isomaki@nokia.com'" ,
        dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com,
        Gonzalo.Camarillo@lmf.ericsson.se
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-
	Drafts
Date: Fri, 8 Nov 2002 07:58:21 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 6756
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: 

It seems to me that these filtering drafts concern the modification of MIME
bodies in SIP messages by intermediaries. This is not exactly an
uncontroversial topic in SIP circles, and therefore I don't think it is a
foregone conclusion that this is work that some SIP-related WG should
charter. At a high level, these drafts also argue that capability
negotiation should be administered by intermediaries rather than through an
end-to-end process; this approach may attract some similar controversy.

Provided that this is work the community would like to pursue, the
applicability and impact of this mechanism is larger than the problem of
instant messaging and presence. While clearly, from the framework, instant
messaging and presence cases are driving this work, it is applicable to the
general use of SIP events (messaging, I think, is something of a corner
case). While SIMPLE could certainly spend some time refining the framework
and requirements related to IM & presence, I imagine that at a mechanism
stage this work would need to take place in SIPPING.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> Sent: Friday, November 08, 2002 3:47 AM
> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> Hi,
> 
> Actually this thread is about two separate things:
> - Event filtering
> - Multimedia message adaptation
> 
> Neither of them appears currently on any sippish WG charter 
> currently. 
> 
> Event filtering has been discussed several times and it is 
> even mentioned in (but out of scope of) SIP Events RFC. My 
> impression has been that people think that it is needed, but 
> there has been debate about scope and feasibility. I hope the 
> requirements draft will help in that discussion. My own 
> opinion is that what is concretely needed in short term is 
> some simple filtering definitions for Presence event package. 
> More wide-scoped and complex things could be worked upon as 
> the understanding accumulates.
> 
> Multimedia message adaptation hasn't been yet discussed much. 
> I think it is in general a desirable feature, especially for 
> relatively small and dumb terminals, which are not easily 
> upgradable and may not understand all media formats.
> 
> So I propose the WG chairs think where these items would be 
> appropriate, and if there is enough interest for them, let's 
> put them on the charters.
> 
> Markus
> 
> > -----Original Message-----
> > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: 08 November, 2002 5:11
> > To: Drage, Keith (Keith)
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > Well, I'd like to hear opinions from the participants here . . .
> > 
> > Clearly they aren't explicitly on the charter for either 
> > group. Do we as
> > yet have a consensus that we need to work on these 
> problems? If so, we
> > can consider WHERE to work on them. I suspect SIPPING is closer to a
> > matching scope than is SIMPLE, but the relevant ADs may have 
> > suggestions
> > to make there as well.
> > 
> > --
> > Dean
> > 
> > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > I am getting a bit confused as to which group should be 
> > discussing these filtering issues.
> > > 
> > > Could we have a statement from the WG chairs of SIPPING or 
> > SIMPLE as to whether this, and the moran drafts, are part of 
> > the scope of SIPPING or SIMPLE.
> > > 
> > > And before you say these are both author drafts, I think we 
> > do need to charter one of the WGs to do some work in this 
> > area - I am just not sure of the exact scope yet.
> > > 
> > > Keith
> > > 
> > > Keith Drage
> > > Lucent Technologies
> > > Tel: +44 1793 776249
> > > Email: drage@lucent.com 
> > > 
> > > > -----Original Message-----
> > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > Sent: 06 November 2002 18:24
> > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts
> > > > 
> > > > 
> > > > 	While these drafts concern event filtering, 
> too, the subject was
> > > > 	a bit misleading because I lazily just followed 
> up Tim's e-mail.
> > > > 
> > > > 					Pekka
> > > > 
> > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > ptation-framework-00.txt
> > > > 
> > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > ptation-requirements-00.txt
> > > > 
> > > > Pekka Pessi  writes:
> > > > >We have submitted two drafts regarding multimedia message
> > > > >adaptation. A multimedia message is typically a message
> > > > >containing images, audio or video clips and their presentation
> > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > >require adaptation in some cases.
> > > > 
> > > > >Our goal is to have a framework using SIP, HTTP and MIME that
> > > > >allows a person sending multimedia message to adapt the message
> > > > >contents suitable to all the recipients. In some cases the
> > > > >adaptation can be done by the sending terminal, but we also see
> > > > >that an adaptation service would be very useful in many cases. 
> > > > >Such an adaptation mechanism is used by MMS service provided by
> > > > >cellular networks nowadays.
> > > > 
> > > > >The message adaptation work concerns both SIPPING and SIMPLE,
> > > > >the requirements I-D lists use cases and requirements for
> > > > >multimedia messaging and message adaptation solutions and the
> > > > >framework I-D tries to explore possible solutions.
> > > > 
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> > > 
> > 
> > _______________________________________________
> > simple mailing list
> > simple@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 Markus.Isomaki@nokia.com  Fri Nov  8 09:29:33 2002
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 JAA18733
	for ; Fri, 8 Nov 2002 09:29:32 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8ET3O21986
	for ; Fri, 8 Nov 2002 16:29:04 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 8 Nov 2002 16:29:30 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 8 Nov 2002 16:29:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Date: Fri, 8 Nov 2002 16:29:29 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKHJxfnqq4Cok0gRuuISgD/1VlMGgAChXcw
To: , ,
        , ,
        
Cc: , 
X-OriginalArrivalTime: 08 Nov 2002 14:29:30.0757 (UTC) FILETIME=[400E8350:01C28733]
Content-Length: 8914
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA18733
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: 

Hi,

Is this analogous to media transcoding within a session? Maybe these two cases should be handled somewhat similarly. The general framework is something like this:
- There is a UA supporting media type X/Y (content in SIP message bodies, media setup with SDP offer-answer) 
- There is another UA supporting media type X/Z
- There is a resource somewhere which can convert X/Y to X/Z and vice versa

The things to consider:
- Should it be a proxy or a UA who needs to detect the need for the conversion?
- If it is a UA, how can it manage to discover and use a suitable converter?
- If it is a proxy, what information can it use to do the detection?
- What about end-to-end security and trust models?
- What is the efficiency in the access network, i.e. how many times the content needs to be sent from UA to proxy or proxy to UA? (In theory only once, but in end-to-end scenarios trial and error may the way, and that may not be acceptable.)

Are there any BCP-type-of call flows somewhere how media transcoding can or should be handled using current SIP and SDP specifications, taking also into account the possible use of S/MIME? Are similar practices applicaple to SIP payload adaptation?

Markus

> -----Original Message-----
> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: 08 November, 2002 14:58
> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> 
> It seems to me that these filtering drafts concern the 
> modification of MIME
> bodies in SIP messages by intermediaries. This is not exactly an
> uncontroversial topic in SIP circles, and therefore I don't 
> think it is a
> foregone conclusion that this is work that some SIP-related WG should
> charter. At a high level, these drafts also argue that capability
> negotiation should be administered by intermediaries rather 
> than through an
> end-to-end process; this approach may attract some similar 
> controversy.
> 
> Provided that this is work the community would like to pursue, the
> applicability and impact of this mechanism is larger than the 
> problem of
> instant messaging and presence. While clearly, from the 
> framework, instant
> messaging and presence cases are driving this work, it is 
> applicable to the
> general use of SIP events (messaging, I think, is something 
> of a corner
> case). While SIMPLE could certainly spend some time refining 
> the framework
> and requirements related to IM & presence, I imagine that at 
> a mechanism
> stage this work would need to take place in SIPPING.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > Sent: Friday, November 08, 2002 3:47 AM
> > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> > Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > Hi,
> > 
> > Actually this thread is about two separate things:
> > - Event filtering
> > - Multimedia message adaptation
> > 
> > Neither of them appears currently on any sippish WG charter 
> > currently. 
> > 
> > Event filtering has been discussed several times and it is 
> > even mentioned in (but out of scope of) SIP Events RFC. My 
> > impression has been that people think that it is needed, but 
> > there has been debate about scope and feasibility. I hope the 
> > requirements draft will help in that discussion. My own 
> > opinion is that what is concretely needed in short term is 
> > some simple filtering definitions for Presence event package. 
> > More wide-scoped and complex things could be worked upon as 
> > the understanding accumulates.
> > 
> > Multimedia message adaptation hasn't been yet discussed much. 
> > I think it is in general a desirable feature, especially for 
> > relatively small and dumb terminals, which are not easily 
> > upgradable and may not understand all media formats.
> > 
> > So I propose the WG chairs think where these items would be 
> > appropriate, and if there is enough interest for them, let's 
> > put them on the charters.
> > 
> > Markus
> > 
> > > -----Original Message-----
> > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > Sent: 08 November, 2002 5:11
> > > To: Drage, Keith (Keith)
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > > adaptationInternet-Drafts
> > > 
> > > 
> > > Well, I'd like to hear opinions from the participants here . . .
> > > 
> > > Clearly they aren't explicitly on the charter for either 
> > > group. Do we as
> > > yet have a consensus that we need to work on these 
> > problems? If so, we
> > > can consider WHERE to work on them. I suspect SIPPING is 
> closer to a
> > > matching scope than is SIMPLE, but the relevant ADs may have 
> > > suggestions
> > > to make there as well.
> > > 
> > > --
> > > Dean
> > > 
> > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > I am getting a bit confused as to which group should be 
> > > discussing these filtering issues.
> > > > 
> > > > Could we have a statement from the WG chairs of SIPPING or 
> > > SIMPLE as to whether this, and the moran drafts, are part of 
> > > the scope of SIPPING or SIMPLE.
> > > > 
> > > > And before you say these are both author drafts, I think we 
> > > do need to charter one of the WGs to do some work in this 
> > > area - I am just not sure of the exact scope yet.
> > > > 
> > > > Keith
> > > > 
> > > > Keith Drage
> > > > Lucent Technologies
> > > > Tel: +44 1793 776249
> > > > Email: drage@lucent.com 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > Sent: 06 November 2002 18:24
> > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > Subject: [Simple] Multimedia message adaptation 
> Internet-Drafts
> > > > > 
> > > > > 
> > > > > 	While these drafts concern event filtering, 
> > too, the subject was
> > > > > 	a bit misleading because I lazily just followed 
> > up Tim's e-mail.
> > > > > 
> > > > > 					Pekka
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-framework-00.txt
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-requirements-00.txt
> > > > > 
> > > > > Pekka Pessi  writes:
> > > > > >We have submitted two drafts regarding multimedia message
> > > > > >adaptation. A multimedia message is typically a message
> > > > > >containing images, audio or video clips and their 
> presentation
> > > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > > >require adaptation in some cases.
> > > > > 
> > > > > >Our goal is to have a framework using SIP, HTTP and MIME that
> > > > > >allows a person sending multimedia message to adapt 
> the message
> > > > > >contents suitable to all the recipients. In some cases the
> > > > > >adaptation can be done by the sending terminal, but 
> we also see
> > > > > >that an adaptation service would be very useful in 
> many cases. 
> > > > > >Such an adaptation mechanism is used by MMS service 
> provided by
> > > > > >cellular networks nowadays.
> > > > > 
> > > > > >The message adaptation work concerns both SIPPING and SIMPLE,
> > > > > >the requirements I-D lists use cases and requirements for
> > > > > >multimedia messaging and message adaptation solutions and the
> > > > > >framework I-D tries to explore possible solutions.
> > > > > 
> > > > > _______________________________________________
> > > > > simple mailing list
> > > > > simple@mailman.dynamicsoft.com
> > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> > > > Use sip@ietf.org for new developments of core SIP
> > > > 
> > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@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 Henry.Sinnreich@wcom.com  Fri Nov  8 11:39:07 2002
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19246
	for ; Fri, 8 Nov 2002 11:39:06 -0500 (EST)
Received: from dgismtp03.wcomnet.com ([166.38.58.143])
 by firewall.wcom.com (Iplanet MTA )
 with ESMTP id <0H5900J49NFD1N@firewall.wcom.com> for
 simple@mailman.dynamicsoft.com; Fri, 08 Nov 2002 16:36:01 +0000 (GMT)
Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com
 (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002))
 with SMTP id <0H5900301NCTXP@dgismtp03.wcomnet.com>; Fri,
 08 Nov 2002 16:35:44 +0000 (GMT)
Received: from hsinnreich2 ([166.42.32.115])
 by dgismtp03.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7
 2002)) with ESMTP id <0H590036WNDHQ7@dgismtp03.wcomnet.com>; Fri,
 08 Nov 2002 16:34:30 +0000 (GMT)
Date: Fri, 08 Nov 2002 10:34:29 -0600
From: Henry Sinnreich 
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
In-reply-to: <15A2739B7DAA624D8091C65981D7DA815EB39A@stntexch2.va.neustar.com>
To: "'Peterson, Jon'" , Markus.Isomaki@nokia.com,
        dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com,
        Gonzalo.Camarillo@lmf.ericsson.se
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
Message-id: <000201c28744$b66196d0$8ea023a6@hsinnreich2>
Organization: WorldCom, Inc.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Length: 8272
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: 

I don't think it is a foregone 
> conclusion that this is work that some SIP-related WG should 
> charter.

I agree that anything that conflicts with e2e should not be ligitimized
by any IETF WG. Think of NATs and firewalls...

If folks want to implement B2BUA, it should be done on their own
responsibility and then live with the consequences. My two cents.

Thanks, Henry

> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] 
> On Behalf Of Peterson, Jon
> Sent: Friday, November 08, 2002 6:58 AM
> To: 'Markus.Isomaki@nokia.com'; dean.willis@softarmor.com; 
> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message 
> adaptationInternet-Drafts
> 
> 
> 
> It seems to me that these filtering drafts concern the 
> modification of MIME bodies in SIP messages by 
> intermediaries. This is not exactly an uncontroversial topic 
> in SIP circles, and therefore I don't think it is a foregone 
> conclusion that this is work that some SIP-related WG should 
> charter. At a high level, these drafts also argue that 
> capability negotiation should be administered by 
> intermediaries rather than through an end-to-end process; 
> this approach may attract some similar controversy.
> 
> Provided that this is work the community would like to 
> pursue, the applicability and impact of this mechanism is 
> larger than the problem of instant messaging and presence. 
> While clearly, from the framework, instant messaging and 
> presence cases are driving this work, it is applicable to the 
> general use of SIP events (messaging, I think, is something 
> of a corner case). While SIMPLE could certainly spend some 
> time refining the framework and requirements related to IM & 
> presence, I imagine that at a mechanism stage this work would 
> need to take place in SIPPING.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > Sent: Friday, November 08, 2002 3:47 AM
> > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; 
> > Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message 
> > adaptationInternet-Drafts
> > 
> > 
> > Hi,
> > 
> > Actually this thread is about two separate things:
> > - Event filtering
> > - Multimedia message adaptation
> > 
> > Neither of them appears currently on any sippish WG charter
> > currently. 
> > 
> > Event filtering has been discussed several times and it is
> > even mentioned in (but out of scope of) SIP Events RFC. My 
> > impression has been that people think that it is needed, but 
> > there has been debate about scope and feasibility. I hope the 
> > requirements draft will help in that discussion. My own 
> > opinion is that what is concretely needed in short term is 
> > some simple filtering definitions for Presence event package. 
> > More wide-scoped and complex things could be worked upon as 
> > the understanding accumulates.
> > 
> > Multimedia message adaptation hasn't been yet discussed much.
> > I think it is in general a desirable feature, especially for 
> > relatively small and dumb terminals, which are not easily 
> > upgradable and may not understand all media formats.
> > 
> > So I propose the WG chairs think where these items would be
> > appropriate, and if there is enough interest for them, let's 
> > put them on the charters.
> > 
> > Markus
> > 
> > > -----Original Message-----
> > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > Sent: 08 November, 2002 5:11
> > > To: Drage, Keith (Keith)
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: Re: [Sipping] RE: [Simple] Multimedia message 
> > > adaptationInternet-Drafts
> > > 
> > > 
> > > Well, I'd like to hear opinions from the participants here . . .
> > > 
> > > Clearly they aren't explicitly on the charter for either
> > > group. Do we as
> > > yet have a consensus that we need to work on these 
> > problems? If so, we
> > > can consider WHERE to work on them. I suspect SIPPING is 
> closer to a 
> > > matching scope than is SIMPLE, but the relevant ADs may have 
> > > suggestions to make there as well.
> > > 
> > > --
> > > Dean
> > > 
> > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > I am getting a bit confused as to which group should be
> > > discussing these filtering issues.
> > > > 
> > > > Could we have a statement from the WG chairs of SIPPING or
> > > SIMPLE as to whether this, and the moran drafts, are part of
> > > the scope of SIPPING or SIMPLE.
> > > > 
> > > > And before you say these are both author drafts, I think we
> > > do need to charter one of the WGs to do some work in this
> > > area - I am just not sure of the exact scope yet.
> > > > 
> > > > Keith
> > > > 
> > > > Keith Drage
> > > > Lucent Technologies
> > > > Tel: +44 1793 776249
> > > > Email: drage@lucent.com
> > > > 
> > > > > -----Original Message-----
> > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > Sent: 06 November 2002 18:24
> > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > Subject: [Simple] Multimedia message adaptation 
> Internet-Drafts
> > > > > 
> > > > > 
> > > > > 	While these drafts concern event filtering,
> > too, the subject was
> > > > > 	a bit misleading because I lazily just followed
> > up Tim's e-mail.
> > > > > 
> > > > > 					Pekka
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-framework-00.txt
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-requirements-00.txt
> > > > > 
> > > > > Pekka Pessi  writes:
> > > > > >We have submitted two drafts regarding multimedia message 
> > > > > >adaptation. A multimedia message is typically a message 
> > > > > >containing images, audio or video clips and their 
> presentation 
> > > > > >information, e.g., smil. Also, even XML-formatted text may 
> > > > > >require adaptation in some cases.
> > > > > 
> > > > > >Our goal is to have a framework using SIP, HTTP and 
> MIME that 
> > > > > >allows a person sending multimedia message to adapt 
> the message 
> > > > > >contents suitable to all the recipients. In some cases the 
> > > > > >adaptation can be done by the sending terminal, but 
> we also see 
> > > > > >that an adaptation service would be very useful in 
> many cases. 
> > > > > >Such an adaptation mechanism is used by MMS service 
> provided by 
> > > > > >cellular networks nowadays.
> > > > > 
> > > > > >The message adaptation work concerns both SIPPING 
> and SIMPLE, 
> > > > > >the requirements I-D lists use cases and requirements for 
> > > > > >multimedia messaging and message adaptation 
> solutions and the 
> > > > > >framework I-D tries to explore possible solutions.
> > > > > 
> > > > > _______________________________________________
> > > > > simple mailing list
> > > > > simple@mailman.dynamicsoft.com 
> > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > 
> > > > _______________________________________________
> > > > Sipping mailing list
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP Use 
> > > > sip-implementors@cs.columbia.edu for questions on 
> current sip Use 
> > > > sip@ietf.org for new developments of core SIP
> > > > 
> > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com 
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com 
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sip@ietf.org for new developments of core SIP
> 


From rohan@cisco.com  Fri Nov  8 12:12:54 2002
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19411
	for ; Fri, 8 Nov 2002 12:12:54 -0500 (EST)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA8HCZxF004360;
	Fri, 8 Nov 2002 09:12:35 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ABG61447;
	Fri, 8 Nov 2002 09:10:17 -0800 (PST)
Date: Fri, 8 Nov 2002 09:12:48 -0800
Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: "'Peterson, Jon'" , Markus.Isomaki@nokia.com,
        dean.willis@softarmor.com, drage@lucent.com,
        Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org,
        simple@mailman.dynamicsoft.com
To: Henry Sinnreich 
From: Rohan Mahy 
In-Reply-To: <000201c28744$b66196d0$8ea023a6@hsinnreich2>
Message-Id: <4E0420E8-F33D-11D6-ACCB-0003938AF740@cisco.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Length: 8328
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: 

Folks,

lets keep this on one list please....

thanks,
-rohan


On Friday, November 8, 2002, at 08:34 AM, Henry Sinnreich wrote:

> I don't think it is a foregone
>> conclusion that this is work that some SIP-related WG should
>> charter.
>
> I agree that anything that conflicts with e2e should not be ligitimized
> by any IETF WG. Think of NATs and firewalls...
>
> If folks want to implement B2BUA, it should be done on their own
> responsibility and then live with the consequences. My two cents.
>
> Thanks, Henry
>
>> -----Original Message-----
>> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]
>> On Behalf Of Peterson, Jon
>> Sent: Friday, November 08, 2002 6:58 AM
>> To: 'Markus.Isomaki@nokia.com'; dean.willis@softarmor.com;
>> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>> adaptationInternet-Drafts
>>
>>
>>
>> It seems to me that these filtering drafts concern the
>> modification of MIME bodies in SIP messages by
>> intermediaries. This is not exactly an uncontroversial topic
>> in SIP circles, and therefore I don't think it is a foregone
>> conclusion that this is work that some SIP-related WG should
>> charter. At a high level, these drafts also argue that
>> capability negotiation should be administered by
>> intermediaries rather than through an end-to-end process;
>> this approach may attract some similar controversy.
>>
>> Provided that this is work the community would like to
>> pursue, the applicability and impact of this mechanism is
>> larger than the problem of instant messaging and presence.
>> While clearly, from the framework, instant messaging and
>> presence cases are driving this work, it is applicable to the
>> general use of SIP events (messaging, I think, is something
>> of a corner case). While SIMPLE could certainly spend some
>> time refining the framework and requirements related to IM &
>> presence, I imagine that at a mechanism stage this work would
>> need to take place in SIPPING.
>>
>> Jon Peterson
>> NeuStar, Inc.
>>
>>> -----Original Message-----
>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
>>> Sent: Friday, November 08, 2002 3:47 AM
>>> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
>>> Gonzalo.Camarillo@lmf.ericsson.se
>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>>> adaptationInternet-Drafts
>>>
>>>
>>> Hi,
>>>
>>> Actually this thread is about two separate things:
>>> - Event filtering
>>> - Multimedia message adaptation
>>>
>>> Neither of them appears currently on any sippish WG charter
>>> currently.
>>>
>>> Event filtering has been discussed several times and it is
>>> even mentioned in (but out of scope of) SIP Events RFC. My
>>> impression has been that people think that it is needed, but
>>> there has been debate about scope and feasibility. I hope the
>>> requirements draft will help in that discussion. My own
>>> opinion is that what is concretely needed in short term is
>>> some simple filtering definitions for Presence event package.
>>> More wide-scoped and complex things could be worked upon as
>>> the understanding accumulates.
>>>
>>> Multimedia message adaptation hasn't been yet discussed much.
>>> I think it is in general a desirable feature, especially for
>>> relatively small and dumb terminals, which are not easily
>>> upgradable and may not understand all media formats.
>>>
>>> So I propose the WG chairs think where these items would be
>>> appropriate, and if there is enough interest for them, let's
>>> put them on the charters.
>>>
>>> Markus
>>>
>>>> -----Original Message-----
>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
>>>> Sent: 08 November, 2002 5:11
>>>> To: Drage, Keith (Keith)
>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message
>>>> adaptationInternet-Drafts
>>>>
>>>>
>>>> Well, I'd like to hear opinions from the participants here . . .
>>>>
>>>> Clearly they aren't explicitly on the charter for either
>>>> group. Do we as
>>>> yet have a consensus that we need to work on these
>>> problems? If so, we
>>>> can consider WHERE to work on them. I suspect SIPPING is
>> closer to a
>>>> matching scope than is SIMPLE, but the relevant ADs may have
>>>> suggestions to make there as well.
>>>>
>>>> --
>>>> Dean
>>>>
>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
>>>>> I am getting a bit confused as to which group should be
>>>> discussing these filtering issues.
>>>>>
>>>>> Could we have a statement from the WG chairs of SIPPING or
>>>> SIMPLE as to whether this, and the moran drafts, are part of
>>>> the scope of SIPPING or SIMPLE.
>>>>>
>>>>> And before you say these are both author drafts, I think we
>>>> do need to charter one of the WGs to do some work in this
>>>> area - I am just not sure of the exact scope yet.
>>>>>
>>>>> Keith
>>>>>
>>>>> Keith Drage
>>>>> Lucent Technologies
>>>>> Tel: +44 1793 776249
>>>>> Email: drage@lucent.com
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
>>>>>> Sent: 06 November 2002 18:24
>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>>>>> Subject: [Simple] Multimedia message adaptation
>> Internet-Drafts
>>>>>>
>>>>>>
>>>>>> 	While these drafts concern event filtering,
>>> too, the subject was
>>>>>> 	a bit misleading because I lazily just followed
>>> up Tim's e-mail.
>>>>>>
>>>>>> 					Pekka
>>>>>>
>>>>>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
>>>>>> ptation-framework-00.txt
>>>>>>
>>>>>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
>>>>>> ptation-requirements-00.txt
>>>>>>
>>>>>> Pekka Pessi  writes:
>>>>>>> We have submitted two drafts regarding multimedia message
>>>>>>> adaptation. A multimedia message is typically a message
>>>>>>> containing images, audio or video clips and their
>> presentation
>>>>>>> information, e.g., smil. Also, even XML-formatted text may
>>>>>>> require adaptation in some cases.
>>>>>>
>>>>>>> Our goal is to have a framework using SIP, HTTP and
>> MIME that
>>>>>>> allows a person sending multimedia message to adapt
>> the message
>>>>>>> contents suitable to all the recipients. In some cases the
>>>>>>> adaptation can be done by the sending terminal, but
>> we also see
>>>>>>> that an adaptation service would be very useful in
>> many cases.
>>>>>>> Such an adaptation mechanism is used by MMS service
>> provided by
>>>>>>> cellular networks nowadays.
>>>>>>
>>>>>>> The message adaptation work concerns both SIPPING
>> and SIMPLE,
>>>>>>> the requirements I-D lists use cases and requirements for
>>>>>>> multimedia messaging and message adaptation
>> solutions and the
>>>>>>> framework I-D tries to explore possible solutions.
>>>>>>
>>>>>> _______________________________________________
>>>>>> simple mailing list
>>>>>> simple@mailman.dynamicsoft.com
>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>>>>
>>>>> _______________________________________________
>>>>> Sipping mailing list
>>> https://www1.ietf.org/mailman/listinfo/sipping
>>>>> This list is for NEW development of the application of SIP Use
>>>>> sip-implementors@cs.columbia.edu for questions on
>> current sip Use
>>>>> sip@ietf.org for new developments of core SIP
>>>>>
>>>>
>>>> _______________________________________________
>>>> simple mailing list
>>>> simple@mailman.dynamicsoft.com
>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>>
>>> _______________________________________________
>>> simple mailing list
>>> simple@mailman.dynamicsoft.com
>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-implementors@cs.columbia.edu for questions on current
>> sip Use sip@ietf.org for new developments of core SIP
>>
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple


From jon.peterson@neustar.biz  Fri Nov  8 16:05:56 2002
Received: from fmis402r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged))
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA20207
	for ; Fri, 8 Nov 2002 16:05:54 -0500 (EST)
Received: from fmis440.omnitel.it by fmis402r.omnitel.it
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 21:05:53 UT
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Message-ID: <15A2739B7DAA624D8091C65981D7DA815EB39A@stntexch2.va.neustar.com>
From: "Peterson, Jon" 
To: "'Markus.Isomaki@nokia.com'" ,
        dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com,
        Gonzalo.Camarillo@lmf.ericsson.se
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-
	Drafts
Date: Fri, 8 Nov 2002 07:58:21 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
Content-Length: 7048
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 

It seems to me that these filtering drafts concern the modification of MIME
bodies in SIP messages by intermediaries. This is not exactly an
uncontroversial topic in SIP circles, and therefore I don't think it is a
foregone conclusion that this is work that some SIP-related WG should
charter. At a high level, these drafts also argue that capability
negotiation should be administered by intermediaries rather than through an
end-to-end process; this approach may attract some similar controversy.

Provided that this is work the community would like to pursue, the
applicability and impact of this mechanism is larger than the problem of
instant messaging and presence. While clearly, from the framework, instant
messaging and presence cases are driving this work, it is applicable to the
general use of SIP events (messaging, I think, is something of a corner
case). While SIMPLE could certainly spend some time refining the framework
and requirements related to IM & presence, I imagine that at a mechanism
stage this work would need to take place in SIPPING.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> Sent: Friday, November 08, 2002 3:47 AM
> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> Hi,
> 
> Actually this thread is about two separate things:
> - Event filtering
> - Multimedia message adaptation
> 
> Neither of them appears currently on any sippish WG charter 
> currently. 
> 
> Event filtering has been discussed several times and it is 
> even mentioned in (but out of scope of) SIP Events RFC. My 
> impression has been that people think that it is needed, but 
> there has been debate about scope and feasibility. I hope the 
> requirements draft will help in that discussion. My own 
> opinion is that what is concretely needed in short term is 
> some simple filtering definitions for Presence event package. 
> More wide-scoped and complex things could be worked upon as 
> the understanding accumulates.
> 
> Multimedia message adaptation hasn't been yet discussed much. 
> I think it is in general a desirable feature, especially for 
> relatively small and dumb terminals, which are not easily 
> upgradable and may not understand all media formats.
> 
> So I propose the WG chairs think where these items would be 
> appropriate, and if there is enough interest for them, let's 
> put them on the charters.
> 
> Markus
> 
> > -----Original Message-----
> > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: 08 November, 2002 5:11
> > To: Drage, Keith (Keith)
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > Well, I'd like to hear opinions from the participants here . . .
> > 
> > Clearly they aren't explicitly on the charter for either 
> > group. Do we as
> > yet have a consensus that we need to work on these 
> problems? If so, we
> > can consider WHERE to work on them. I suspect SIPPING is closer to a
> > matching scope than is SIMPLE, but the relevant ADs may have 
> > suggestions
> > to make there as well.
> > 
> > --
> > Dean
> > 
> > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > I am getting a bit confused as to which group should be 
> > discussing these filtering issues.
> > > 
> > > Could we have a statement from the WG chairs of SIPPING or 
> > SIMPLE as to whether this, and the moran drafts, are part of 
> > the scope of SIPPING or SIMPLE.
> > > 
> > > And before you say these are both author drafts, I think we 
> > do need to charter one of the WGs to do some work in this 
> > area - I am just not sure of the exact scope yet.
> > > 
> > > Keith
> > > 
> > > Keith Drage
> > > Lucent Technologies
> > > Tel: +44 1793 776249
> > > Email: drage@lucent.com 
> > > 
> > > > -----Original Message-----
> > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > Sent: 06 November 2002 18:24
> > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts
> > > > 
> > > > 
> > > > 	While these drafts concern event filtering, 
> too, the subject was
> > > > 	a bit misleading because I lazily just followed 
> up Tim's e-mail.
> > > > 
> > > > 					Pekka
> > > > 
> > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > ptation-framework-00.txt
> > > > 
> > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > ptation-requirements-00.txt
> > > > 
> > > > Pekka Pessi  writes:
> > > > >We have submitted two drafts regarding multimedia message
> > > > >adaptation. A multimedia message is typically a message
> > > > >containing images, audio or video clips and their presentation
> > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > >require adaptation in some cases.
> > > > 
> > > > >Our goal is to have a framework using SIP, HTTP and MIME that
> > > > >allows a person sending multimedia message to adapt the message
> > > > >contents suitable to all the recipients. In some cases the
> > > > >adaptation can be done by the sending terminal, but we also see
> > > > >that an adaptation service would be very useful in many cases. 
> > > > >Such an adaptation mechanism is used by MMS service provided by
> > > > >cellular networks nowadays.
> > > > 
> > > > >The message adaptation work concerns both SIPPING and SIMPLE,
> > > > >the requirements I-D lists use cases and requirements for
> > > > >multimedia messaging and message adaptation solutions and the
> > > > >framework I-D tries to explore possible solutions.
> > > > 
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> > > 
> > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

From Markus.Isomaki@nokia.com  Fri Nov  8 16:21:27 2002
Received: from fmis402r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged))
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA20619
	for ; Fri, 8 Nov 2002 16:21:27 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from fmis440.omnitel.it by fmis402r.omnitel.it
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 21:21:26 UT
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Date: Fri, 8 Nov 2002 16:29:29 +0200
Message-ID: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKHJxfnqq4Cok0gRuuISgD/1VlMGgAChXcw
To: , ,
        , ,
        
Cc: , 
X-OriginalArrivalTime: 08 Nov 2002 14:29:30.0757 (UTC) FILETIME=[400E8350:01C28733]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8ETbv28657
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
Content-Length: 9206
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 

Hi,

Is this analogous to media transcoding within a session? Maybe these two cases should be handled somewhat similarly. The general framework is something like this:
- There is a UA supporting media type X/Y (content in SIP message bodies, media setup with SDP offer-answer) 
- There is another UA supporting media type X/Z
- There is a resource somewhere which can convert X/Y to X/Z and vice versa

The things to consider:
- Should it be a proxy or a UA who needs to detect the need for the conversion?
- If it is a UA, how can it manage to discover and use a suitable converter?
- If it is a proxy, what information can it use to do the detection?
- What about end-to-end security and trust models?
- What is the efficiency in the access network, i.e. how many times the content needs to be sent from UA to proxy or proxy to UA? (In theory only once, but in end-to-end scenarios trial and error may the way, and that may not be acceptable.)

Are there any BCP-type-of call flows somewhere how media transcoding can or should be handled using current SIP and SDP specifications, taking also into account the possible use of S/MIME? Are similar practices applicaple to SIP payload adaptation?

Markus

> -----Original Message-----
> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: 08 November, 2002 14:58
> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> 
> It seems to me that these filtering drafts concern the 
> modification of MIME
> bodies in SIP messages by intermediaries. This is not exactly an
> uncontroversial topic in SIP circles, and therefore I don't 
> think it is a
> foregone conclusion that this is work that some SIP-related WG should
> charter. At a high level, these drafts also argue that capability
> negotiation should be administered by intermediaries rather 
> than through an
> end-to-end process; this approach may attract some similar 
> controversy.
> 
> Provided that this is work the community would like to pursue, the
> applicability and impact of this mechanism is larger than the 
> problem of
> instant messaging and presence. While clearly, from the 
> framework, instant
> messaging and presence cases are driving this work, it is 
> applicable to the
> general use of SIP events (messaging, I think, is something 
> of a corner
> case). While SIMPLE could certainly spend some time refining 
> the framework
> and requirements related to IM & presence, I imagine that at 
> a mechanism
> stage this work would need to take place in SIPPING.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > Sent: Friday, November 08, 2002 3:47 AM
> > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> > Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > Hi,
> > 
> > Actually this thread is about two separate things:
> > - Event filtering
> > - Multimedia message adaptation
> > 
> > Neither of them appears currently on any sippish WG charter 
> > currently. 
> > 
> > Event filtering has been discussed several times and it is 
> > even mentioned in (but out of scope of) SIP Events RFC. My 
> > impression has been that people think that it is needed, but 
> > there has been debate about scope and feasibility. I hope the 
> > requirements draft will help in that discussion. My own 
> > opinion is that what is concretely needed in short term is 
> > some simple filtering definitions for Presence event package. 
> > More wide-scoped and complex things could be worked upon as 
> > the understanding accumulates.
> > 
> > Multimedia message adaptation hasn't been yet discussed much. 
> > I think it is in general a desirable feature, especially for 
> > relatively small and dumb terminals, which are not easily 
> > upgradable and may not understand all media formats.
> > 
> > So I propose the WG chairs think where these items would be 
> > appropriate, and if there is enough interest for them, let's 
> > put them on the charters.
> > 
> > Markus
> > 
> > > -----Original Message-----
> > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > Sent: 08 November, 2002 5:11
> > > To: Drage, Keith (Keith)
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > > adaptationInternet-Drafts
> > > 
> > > 
> > > Well, I'd like to hear opinions from the participants here . . .
> > > 
> > > Clearly they aren't explicitly on the charter for either 
> > > group. Do we as
> > > yet have a consensus that we need to work on these 
> > problems? If so, we
> > > can consider WHERE to work on them. I suspect SIPPING is 
> closer to a
> > > matching scope than is SIMPLE, but the relevant ADs may have 
> > > suggestions
> > > to make there as well.
> > > 
> > > --
> > > Dean
> > > 
> > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > I am getting a bit confused as to which group should be 
> > > discussing these filtering issues.
> > > > 
> > > > Could we have a statement from the WG chairs of SIPPING or 
> > > SIMPLE as to whether this, and the moran drafts, are part of 
> > > the scope of SIPPING or SIMPLE.
> > > > 
> > > > And before you say these are both author drafts, I think we 
> > > do need to charter one of the WGs to do some work in this 
> > > area - I am just not sure of the exact scope yet.
> > > > 
> > > > Keith
> > > > 
> > > > Keith Drage
> > > > Lucent Technologies
> > > > Tel: +44 1793 776249
> > > > Email: drage@lucent.com 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > Sent: 06 November 2002 18:24
> > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > Subject: [Simple] Multimedia message adaptation 
> Internet-Drafts
> > > > > 
> > > > > 
> > > > > 	While these drafts concern event filtering, 
> > too, the subject was
> > > > > 	a bit misleading because I lazily just followed 
> > up Tim's e-mail.
> > > > > 
> > > > > 					Pekka
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-framework-00.txt
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-requirements-00.txt
> > > > > 
> > > > > Pekka Pessi  writes:
> > > > > >We have submitted two drafts regarding multimedia message
> > > > > >adaptation. A multimedia message is typically a message
> > > > > >containing images, audio or video clips and their 
> presentation
> > > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > > >require adaptation in some cases.
> > > > > 
> > > > > >Our goal is to have a framework using SIP, HTTP and MIME that
> > > > > >allows a person sending multimedia message to adapt 
> the message
> > > > > >contents suitable to all the recipients. In some cases the
> > > > > >adaptation can be done by the sending terminal, but 
> we also see
> > > > > >that an adaptation service would be very useful in 
> many cases. 
> > > > > >Such an adaptation mechanism is used by MMS service 
> provided by
> > > > > >cellular networks nowadays.
> > > > > 
> > > > > >The message adaptation work concerns both SIPPING and SIMPLE,
> > > > > >the requirements I-D lists use cases and requirements for
> > > > > >multimedia messaging and message adaptation solutions and the
> > > > > >framework I-D tries to explore possible solutions.
> > > > > 
> > > > > _______________________________________________
> > > > > simple mailing list
> > > > > simple@mailman.dynamicsoft.com
> > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> > > > Use sip@ietf.org for new developments of core SIP
> > > > 
> > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@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
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

From dean.willis@softarmor.com  Fri Nov  8 16:33:06 2002
Received: from fmis401r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged))
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA21024
	for ; Fri, 8 Nov 2002 16:33:05 -0500 (EST)
Received: from fmis440.omnitel.it by fmis401r.omnitel.it
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 21:33:04 UT
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
X-Authentication-Warning: kevlar.softarmor.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptation
	Internet-Drafts
From: Dean Willis 
To: "Drage"@vodafoneomnitel.it
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
In-Reply-To: 
	<475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com>
References: 
	<475FF955A05DD411980D00508B6D5FB00696E509@en0033exch001u.uk.lucent.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 07 Nov 2002 21:10:50 -0600
Message-Id: <1036725050.20411.2.camel@kevlar.softarmor.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
Content-Length: 3414
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 

Well, I'd like to hear opinions from the participants here . . .

Clearly they aren't explicitly on the charter for either group. Do we as
yet have a consensus that we need to work on these problems? If so, we
can consider WHERE to work on them. I suspect SIPPING is closer to a
matching scope than is SIMPLE, but the relevant ADs may have suggestions
to make there as well.

--
Dean

On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> I am getting a bit confused as to which group should be discussing these filtering issues.
> 
> Could we have a statement from the WG chairs of SIPPING or SIMPLE as to whether this, and the moran drafts, are part of the scope of SIPPING or SIMPLE.
> 
> And before you say these are both author drafts, I think we do need to charter one of the WGs to do some work in this area - I am just not sure of the exact scope yet.
> 
> Keith
> 
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com 
> 
> > -----Original Message-----
> > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > Sent: 06 November 2002 18:24
> > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: [Simple] Multimedia message adaptation Internet-Drafts
> > 
> > 
> > 	While these drafts concern event filtering, too, the subject was
> > 	a bit misleading because I lazily just followed up Tim's e-mail.
> > 
> > 					Pekka
> > 
> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > ptation-framework-00.txt
> > 
> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > ptation-requirements-00.txt
> > 
> > Pekka Pessi  writes:
> > >We have submitted two drafts regarding multimedia message
> > >adaptation. A multimedia message is typically a message
> > >containing images, audio or video clips and their presentation
> > >information, e.g., smil. Also, even XML-formatted text may
> > >require adaptation in some cases.
> > 
> > >Our goal is to have a framework using SIP, HTTP and MIME that
> > >allows a person sending multimedia message to adapt the message
> > >contents suitable to all the recipients. In some cases the
> > >adaptation can be done by the sending terminal, but we also see
> > >that an adaptation service would be very useful in many cases. 
> > >Such an adaptation mechanism is used by MMS service provided by
> > >cellular networks nowadays.
> > 
> > >The message adaptation work concerns both SIPPING and SIMPLE,
> > >the requirements I-D lists use cases and requirements for
> > >multimedia messaging and message adaptation solutions and the
> > >framework I-D tries to explore possible solutions.
> > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

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

From Henry.Sinnreich@wcom.com  Fri Nov  8 17:00:41 2002
Received: from fmis402r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged))
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA21430
	for ; Fri, 8 Nov 2002 17:00:40 -0500 (EST)
Received: from fmis439.omnitel.it by fmis402r.omnitel.it
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 22:00:40 UT
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Date: Fri, 08 Nov 2002 10:34:29 -0600
From: Henry Sinnreich 
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
In-reply-to: <15A2739B7DAA624D8091C65981D7DA815EB39A@stntexch2.va.neustar.com>
To: "'Peterson"@vodafoneomnitel.it
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com
Message-id: <000201c28744$b66196d0$8ea023a6@hsinnreich2>
Organization: WorldCom, Inc.
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1097
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Content-Transfer-Encoding: 7bit
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
Content-Length: 8564
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 

I don't think it is a foregone 
> conclusion that this is work that some SIP-related WG should 
> charter.

I agree that anything that conflicts with e2e should not be ligitimized
by any IETF WG. Think of NATs and firewalls...

If folks want to implement B2BUA, it should be done on their own
responsibility and then live with the consequences. My two cents.

Thanks, Henry

> -----Original Message-----
> From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] 
> On Behalf Of Peterson, Jon
> Sent: Friday, November 08, 2002 6:58 AM
> To: 'Markus.Isomaki@nokia.com'; dean.willis@softarmor.com; 
> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message 
> adaptationInternet-Drafts
> 
> 
> 
> It seems to me that these filtering drafts concern the 
> modification of MIME bodies in SIP messages by 
> intermediaries. This is not exactly an uncontroversial topic 
> in SIP circles, and therefore I don't think it is a foregone 
> conclusion that this is work that some SIP-related WG should 
> charter. At a high level, these drafts also argue that 
> capability negotiation should be administered by 
> intermediaries rather than through an end-to-end process; 
> this approach may attract some similar controversy.
> 
> Provided that this is work the community would like to 
> pursue, the applicability and impact of this mechanism is 
> larger than the problem of instant messaging and presence. 
> While clearly, from the framework, instant messaging and 
> presence cases are driving this work, it is applicable to the 
> general use of SIP events (messaging, I think, is something 
> of a corner case). While SIMPLE could certainly spend some 
> time refining the framework and requirements related to IM & 
> presence, I imagine that at a mechanism stage this work would 
> need to take place in SIPPING.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > Sent: Friday, November 08, 2002 3:47 AM
> > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; 
> > Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message 
> > adaptationInternet-Drafts
> > 
> > 
> > Hi,
> > 
> > Actually this thread is about two separate things:
> > - Event filtering
> > - Multimedia message adaptation
> > 
> > Neither of them appears currently on any sippish WG charter
> > currently. 
> > 
> > Event filtering has been discussed several times and it is
> > even mentioned in (but out of scope of) SIP Events RFC. My 
> > impression has been that people think that it is needed, but 
> > there has been debate about scope and feasibility. I hope the 
> > requirements draft will help in that discussion. My own 
> > opinion is that what is concretely needed in short term is 
> > some simple filtering definitions for Presence event package. 
> > More wide-scoped and complex things could be worked upon as 
> > the understanding accumulates.
> > 
> > Multimedia message adaptation hasn't been yet discussed much.
> > I think it is in general a desirable feature, especially for 
> > relatively small and dumb terminals, which are not easily 
> > upgradable and may not understand all media formats.
> > 
> > So I propose the WG chairs think where these items would be
> > appropriate, and if there is enough interest for them, let's 
> > put them on the charters.
> > 
> > Markus
> > 
> > > -----Original Message-----
> > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > Sent: 08 November, 2002 5:11
> > > To: Drage, Keith (Keith)
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: Re: [Sipping] RE: [Simple] Multimedia message 
> > > adaptationInternet-Drafts
> > > 
> > > 
> > > Well, I'd like to hear opinions from the participants here . . .
> > > 
> > > Clearly they aren't explicitly on the charter for either
> > > group. Do we as
> > > yet have a consensus that we need to work on these 
> > problems? If so, we
> > > can consider WHERE to work on them. I suspect SIPPING is 
> closer to a 
> > > matching scope than is SIMPLE, but the relevant ADs may have 
> > > suggestions to make there as well.
> > > 
> > > --
> > > Dean
> > > 
> > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > I am getting a bit confused as to which group should be
> > > discussing these filtering issues.
> > > > 
> > > > Could we have a statement from the WG chairs of SIPPING or
> > > SIMPLE as to whether this, and the moran drafts, are part of
> > > the scope of SIPPING or SIMPLE.
> > > > 
> > > > And before you say these are both author drafts, I think we
> > > do need to charter one of the WGs to do some work in this
> > > area - I am just not sure of the exact scope yet.
> > > > 
> > > > Keith
> > > > 
> > > > Keith Drage
> > > > Lucent Technologies
> > > > Tel: +44 1793 776249
> > > > Email: drage@lucent.com
> > > > 
> > > > > -----Original Message-----
> > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > Sent: 06 November 2002 18:24
> > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > Subject: [Simple] Multimedia message adaptation 
> Internet-Drafts
> > > > > 
> > > > > 
> > > > > 	While these drafts concern event filtering,
> > too, the subject was
> > > > > 	a bit misleading because I lazily just followed
> > up Tim's e-mail.
> > > > > 
> > > > > 					Pekka
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-framework-00.txt
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-requirements-00.txt
> > > > > 
> > > > > Pekka Pessi  writes:
> > > > > >We have submitted two drafts regarding multimedia message 
> > > > > >adaptation. A multimedia message is typically a message 
> > > > > >containing images, audio or video clips and their 
> presentation 
> > > > > >information, e.g., smil. Also, even XML-formatted text may 
> > > > > >require adaptation in some cases.
> > > > > 
> > > > > >Our goal is to have a framework using SIP, HTTP and 
> MIME that 
> > > > > >allows a person sending multimedia message to adapt 
> the message 
> > > > > >contents suitable to all the recipients. In some cases the 
> > > > > >adaptation can be done by the sending terminal, but 
> we also see 
> > > > > >that an adaptation service would be very useful in 
> many cases. 
> > > > > >Such an adaptation mechanism is used by MMS service 
> provided by 
> > > > > >cellular networks nowadays.
> > > > > 
> > > > > >The message adaptation work concerns both SIPPING 
> and SIMPLE, 
> > > > > >the requirements I-D lists use cases and requirements for 
> > > > > >multimedia messaging and message adaptation 
> solutions and the 
> > > > > >framework I-D tries to explore possible solutions.
> > > > > 
> > > > > _______________________________________________
> > > > > simple mailing list
> > > > > simple@mailman.dynamicsoft.com 
> > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > 
> > > > _______________________________________________
> > > > Sipping mailing list
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP Use 
> > > > sip-implementors@cs.columbia.edu for questions on 
> current sip Use 
> > > > sip@ietf.org for new developments of core SIP
> > > > 
> > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com 
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com 
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sip@ietf.org for new developments of core SIP
> 

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

From Markus.Isomaki@nokia.com  Fri Nov  8 17:57:14 2002
Received: from fmis402r.omnitel.it (srvcw29.omnitelvodafone.it [194.185.48.252] (may be forged))
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id RAA21949
	for ; Fri, 8 Nov 2002 17:57:13 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from fmis439.omnitel.it by fmis402r.omnitel.it
          via smtpd (for mailman.dynamicsoft.com [63.113.40.50]) with SMTP; 8 Nov 2002 22:57:13 UT
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
Received: (private information removed)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Date: Fri, 8 Nov 2002 13:46:36 +0200
Message-ID: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKG1KTa2SE/J0KdTJCVUzzcD3eDCAARX8MA
To: , , ,
        
Cc: , 
X-OriginalArrivalTime: 08 Nov 2002 11:46:37.0845 (UTC) FILETIME=[7EF27C50:01C2871C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gA8Bkiv17070
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
Content-Length: 5123
Sender: simple-admin@mailman.dynamicsoft.com
Errors-To: simple-admin@mailman.dynamicsoft.com
X-BeenThere: simple@mailman.dynamicsoft.com
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: SIP for Presence 
List-Unsubscribe: ,
	
List-Archive: 

Hi,

Actually this thread is about two separate things:
- Event filtering
- Multimedia message adaptation

Neither of them appears currently on any sippish WG charter currently. 

Event filtering has been discussed several times and it is even mentioned in (but out of scope of) SIP Events RFC. My impression has been that people think that it is needed, but there has been debate about scope and feasibility. I hope the requirements draft will help in that discussion. My own opinion is that what is concretely needed in short term is some simple filtering definitions for Presence event package. More wide-scoped and complex things could be worked upon as the understanding accumulates.

Multimedia message adaptation hasn't been yet discussed much. I think it is in general a desirable feature, especially for relatively small and dumb terminals, which are not easily upgradable and may not understand all media formats.

So I propose the WG chairs think where these items would be appropriate, and if there is enough interest for them, let's put them on the charters.

Markus

> -----Original Message-----
> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 08 November, 2002 5:11
> To: Drage, Keith (Keith)
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: Re: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> Well, I'd like to hear opinions from the participants here . . .
> 
> Clearly they aren't explicitly on the charter for either 
> group. Do we as
> yet have a consensus that we need to work on these problems? If so, we
> can consider WHERE to work on them. I suspect SIPPING is closer to a
> matching scope than is SIMPLE, but the relevant ADs may have 
> suggestions
> to make there as well.
> 
> --
> Dean
> 
> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > I am getting a bit confused as to which group should be 
> discussing these filtering issues.
> > 
> > Could we have a statement from the WG chairs of SIPPING or 
> SIMPLE as to whether this, and the moran drafts, are part of 
> the scope of SIPPING or SIMPLE.
> > 
> > And before you say these are both author drafts, I think we 
> do need to charter one of the WGs to do some work in this 
> area - I am just not sure of the exact scope yet.
> > 
> > Keith
> > 
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: drage@lucent.com 
> > 
> > > -----Original Message-----
> > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > Sent: 06 November 2002 18:24
> > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: [Simple] Multimedia message adaptation Internet-Drafts
> > > 
> > > 
> > > 	While these drafts concern event filtering, too, the subject was
> > > 	a bit misleading because I lazily just followed up Tim's e-mail.
> > > 
> > > 					Pekka
> > > 
> > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > ptation-framework-00.txt
> > > 
> > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > ptation-requirements-00.txt
> > > 
> > > Pekka Pessi  writes:
> > > >We have submitted two drafts regarding multimedia message
> > > >adaptation. A multimedia message is typically a message
> > > >containing images, audio or video clips and their presentation
> > > >information, e.g., smil. Also, even XML-formatted text may
> > > >require adaptation in some cases.
> > > 
> > > >Our goal is to have a framework using SIP, HTTP and MIME that
> > > >allows a person sending multimedia message to adapt the message
> > > >contents suitable to all the recipients. In some cases the
> > > >adaptation can be done by the sending terminal, but we also see
> > > >that an adaptation service would be very useful in many cases. 
> > > >Such an adaptation mechanism is used by MMS service provided by
> > > >cellular networks nowadays.
> > > 
> > > >The message adaptation work concerns both SIPPING and SIMPLE,
> > > >the requirements I-D lists use cases and requirements for
> > > >multimedia messaging and message adaptation solutions and the
> > > >framework I-D tries to explore possible solutions.
> > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

From Stephane.Coulombe@nokia.com  Fri Nov  8 18:50:12 2002
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22519
	for ; Fri, 8 Nov 2002 18:50:11 -0500 (EST)
From: Stephane.Coulombe@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA8Np9X18053
	for ; Fri, 8 Nov 2002 17:51:09 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Fri, 8 Nov 2002 17:50:10 -0600
Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Fri, 8 Nov 2002 15:50:09 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Date: Fri, 8 Nov 2002 17:50:08 -0600
Message-ID: <97C16120D52CD249ADE310B69842D5B9796982@daebe004.americas.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2A
To: , ,
        , , ,
        
Cc: , ,
        , 
X-OriginalArrivalTime: 08 Nov 2002 23:50:09.0871 (UTC) FILETIME=[9287F5F0:01C28781]
Content-Length: 10623
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA22519
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: 

Hi,

> At a high level, these drafts also argue that capability
> negotiation should be administered by intermediaries rather than through an
> end-to-end process; this approach may attract some similar controversy.

Proposed capability negotiation can be used both ways (end-to-end or
administered by intermediaries).
1) end-to-end: Someone who wants to send an Instant Message to another user
	can send an OPTION query to learn about its terminal capabilities and
	then create a message within its capabilities.
	
	I guess this is not controversial. However how realistic and usable is it in practice?
	When composing a message, would a user really want to take into consideration 
	the image formats to use, message size limitation, etc? 

	For instance, you want to send a PNG image to a friend and his terminal only supports 
	GIF format. What are you supposed to do? Find an image conversion tool to convert to GIF?
	This is annoying if you are using a PC, imagine with a mobile phone or handheld?
	
	For usability reasons, the user wants to send a message without caring "too much" about 
	what the other end is supporting.
 
2)administered by intermediaries: this is discussed in detail in one of the drafts. 

	Performing adaptation in the network is controversial but this is the only way to support
	interoperability and good user experience. 

> the applicability and impact of this mechanism is larger than the problem of
> instant messaging and presence. While clearly, from the framework, instant
> messaging and presence cases are driving this work, it is applicable to the
> general use of SIP events (messaging, I think, is something of a corner case). 

Yes, applicability and impact is larger than IM and presence. It applies to many other
applications including the case of audio/video conferencing (for instance when there is 
no common audio or video codec between two ends).  

The drafts use the "corner case" of SIP IM for a few reasons:
1) In SIP IM, there is no concept of capability negotiation (unlike the case of sessions using SDP).
	A user sends a message without knowing anything about the recipient's terminal capabilities.
2) In SIP IM, it easier to argue that there will be interoperability problems because of the variety of content types that could be sent (in audio/video session codecs are typically more agreed on). Right now text is mostly used but richer content will soon be used as is the case in Multimedia Messaging Service (MMS). By the way, message adaptation is a serious issue in MMS because of fast product capability evolution. It's hard to keep interoperability while not restricting new phones to send just "low-end" content.
3) It is easier to explain the problem and propose a solution with a smaller well-defined problem.

Once we agree that SIP message adaptation is required, the requirements and solutions should be established from global perspective; not just SIP IM. For that reason, SIPPING may be the most appropriate place to initiate this activity.

Stephane

-----Original Message-----
From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: Friday, November 08, 2002 6:58 AM
To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
Subject: RE: [Sipping] RE: [Simple] Multimedia message
adaptationInternet-Drafts



It seems to me that these filtering drafts concern the modification of MIME
bodies in SIP messages by intermediaries. This is not exactly an
uncontroversial topic in SIP circles, and therefore I don't think it is a
foregone conclusion that this is work that some SIP-related WG should
charter. At a high level, these drafts also argue that capability
negotiation should be administered by intermediaries rather than through an
end-to-end process; this approach may attract some similar controversy.

Provided that this is work the community would like to pursue, the
applicability and impact of this mechanism is larger than the problem of
instant messaging and presence. While clearly, from the framework, instant
messaging and presence cases are driving this work, it is applicable to the
general use of SIP events (messaging, I think, is something of a corner
case). While SIMPLE could certainly spend some time refining the framework
and requirements related to IM & presence, I imagine that at a mechanism
stage this work would need to take place in SIPPING.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> Sent: Friday, November 08, 2002 3:47 AM
> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> Hi,
> 
> Actually this thread is about two separate things:
> - Event filtering
> - Multimedia message adaptation
> 
> Neither of them appears currently on any sippish WG charter 
> currently. 
> 
> Event filtering has been discussed several times and it is 
> even mentioned in (but out of scope of) SIP Events RFC. My 
> impression has been that people think that it is needed, but 
> there has been debate about scope and feasibility. I hope the 
> requirements draft will help in that discussion. My own 
> opinion is that what is concretely needed in short term is 
> some simple filtering definitions for Presence event package. 
> More wide-scoped and complex things could be worked upon as 
> the understanding accumulates.
> 
> Multimedia message adaptation hasn't been yet discussed much. 
> I think it is in general a desirable feature, especially for 
> relatively small and dumb terminals, which are not easily 
> upgradable and may not understand all media formats.
> 
> So I propose the WG chairs think where these items would be 
> appropriate, and if there is enough interest for them, let's 
> put them on the charters.
> 
> Markus
> 
> > -----Original Message-----
> > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: 08 November, 2002 5:11
> > To: Drage, Keith (Keith)
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > Well, I'd like to hear opinions from the participants here . . .
> > 
> > Clearly they aren't explicitly on the charter for either 
> > group. Do we as
> > yet have a consensus that we need to work on these 
> problems? If so, we
> > can consider WHERE to work on them. I suspect SIPPING is closer to a
> > matching scope than is SIMPLE, but the relevant ADs may have 
> > suggestions
> > to make there as well.
> > 
> > --
> > Dean
> > 
> > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > I am getting a bit confused as to which group should be 
> > discussing these filtering issues.
> > > 
> > > Could we have a statement from the WG chairs of SIPPING or 
> > SIMPLE as to whether this, and the moran drafts, are part of 
> > the scope of SIPPING or SIMPLE.
> > > 
> > > And before you say these are both author drafts, I think we 
> > do need to charter one of the WGs to do some work in this 
> > area - I am just not sure of the exact scope yet.
> > > 
> > > Keith
> > > 
> > > Keith Drage
> > > Lucent Technologies
> > > Tel: +44 1793 776249
> > > Email: drage@lucent.com 
> > > 
> > > > -----Original Message-----
> > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > Sent: 06 November 2002 18:24
> > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts
> > > > 
> > > > 
> > > > 	While these drafts concern event filtering, 
> too, the subject was
> > > > 	a bit misleading because I lazily just followed 
> up Tim's e-mail.
> > > > 
> > > > 					Pekka
> > > > 
> > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > ptation-framework-00.txt
> > > > 
> > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > ptation-requirements-00.txt
> > > > 
> > > > Pekka Pessi  writes:
> > > > >We have submitted two drafts regarding multimedia message
> > > > >adaptation. A multimedia message is typically a message
> > > > >containing images, audio or video clips and their presentation
> > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > >require adaptation in some cases.
> > > > 
> > > > >Our goal is to have a framework using SIP, HTTP and MIME that
> > > > >allows a person sending multimedia message to adapt the message
> > > > >contents suitable to all the recipients. In some cases the
> > > > >adaptation can be done by the sending terminal, but we also see
> > > > >that an adaptation service would be very useful in many cases. 
> > > > >Such an adaptation mechanism is used by MMS service provided by
> > > > >cellular networks nowadays.
> > > > 
> > > > >The message adaptation work concerns both SIPPING and SIMPLE,
> > > > >the requirements I-D lists use cases and requirements for
> > > > >multimedia messaging and message adaptation solutions and the
> > > > >framework I-D tries to explore possible solutions.
> > > > 
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> > > 
> > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

From Jose.Costa-Requena@nokia.com  Sat Nov  9 12:21:08 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25624
	for ; Sat, 9 Nov 2002 12:21:07 -0500 (EST)
From: Jose.Costa-Requena@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gA9HLeB00006
	for ; Sat, 9 Nov 2002 19:21:41 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Sat, 9 Nov 2002 19:21:05 +0200
Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sat, 9 Nov 2002 19:21:05 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Date: Sat, 9 Nov 2002 19:21:04 +0200
Message-ID: <07A6D72550C5E0459DE676439EE53846CC49C8@esebe012.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkA=
To: , ,
        , ,
        , ,
        
Cc: , ,
        
X-OriginalArrivalTime: 09 Nov 2002 17:21:05.0541 (UTC) FILETIME=[62A3A350:01C28814]
Content-Length: 11757
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id MAA25624
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: 

Hi,

In addition to Stephane's clarification about the "content adaptation" I-D, I would like to remark the difference between this draft (from Coulombe et al.) and the "filtering" draft (from Tim Moran et al).
The aim of "filtering" draft is to define a framework for building the appropriate mechanism within the semantics of SUBS/NOTIF for presence information filtering.
Nevertheless, "content adaptation" I-D has a wider scope since it is considering any content-type and it is taking into account the terminal/user preferences. So I would say that  it fits into SIPPING WG while the filtering I-D is mainly dealing with presence and I think it should be handled at SIMPLE WG.
BR
Jose

-----Original Message-----
From: Coulombe Stephane (NRC/Dallas) 
Sent: 09. November 2002 1:50
To: ext Peterson, Jon; Isomaki Markus (NRC/Helsinki);
dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
Gonzalo.Camarillo@lmf.ericsson.se
Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; Pessi Pekka
(NRC/Helsinki); Costa-Requena Jose (NMP/Helsinki)
Subject: RE: [Sipping] RE: [Simple] Multimedia message
adaptationInternet-Drafts


Hi,

> At a high level, these drafts also argue that capability
> negotiation should be administered by intermediaries rather than through an
> end-to-end process; this approach may attract some similar controversy.

Proposed capability negotiation can be used both ways (end-to-end or
administered by intermediaries).
1) end-to-end: Someone who wants to send an Instant Message to another user
	can send an OPTION query to learn about its terminal capabilities and
	then create a message within its capabilities.
	
	I guess this is not controversial. However how realistic and usable is it in practice?
	When composing a message, would a user really want to take into consideration 
	the image formats to use, message size limitation, etc? 

	For instance, you want to send a PNG image to a friend and his terminal only supports 
	GIF format. What are you supposed to do? Find an image conversion tool to convert to GIF?
	This is annoying if you are using a PC, imagine with a mobile phone or handheld?
	
	For usability reasons, the user wants to send a message without caring "too much" about 
	what the other end is supporting.
 
2)administered by intermediaries: this is discussed in detail in one of the drafts. 

	Performing adaptation in the network is controversial but this is the only way to support
	interoperability and good user experience. 

> the applicability and impact of this mechanism is larger than the problem of
> instant messaging and presence. While clearly, from the framework, instant
> messaging and presence cases are driving this work, it is applicable to the
> general use of SIP events (messaging, I think, is something of a corner case). 

Yes, applicability and impact is larger than IM and presence. It applies to many other
applications including the case of audio/video conferencing (for instance when there is 
no common audio or video codec between two ends).  

The drafts use the "corner case" of SIP IM for a few reasons:
1) In SIP IM, there is no concept of capability negotiation (unlike the case of sessions using SDP).
	A user sends a message without knowing anything about the recipient's terminal capabilities.
2) In SIP IM, it easier to argue that there will be interoperability problems because of the variety of content types that could be sent (in audio/video session codecs are typically more agreed on). Right now text is mostly used but richer content will soon be used as is the case in Multimedia Messaging Service (MMS). By the way, message adaptation is a serious issue in MMS because of fast product capability evolution. It's hard to keep interoperability while not restricting new phones to send just "low-end" content.
3) It is easier to explain the problem and propose a solution with a smaller well-defined problem.

Once we agree that SIP message adaptation is required, the requirements and solutions should be established from global perspective; not just SIP IM. For that reason, SIPPING may be the most appropriate place to initiate this activity.

Stephane

-----Original Message-----
From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: Friday, November 08, 2002 6:58 AM
To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
Subject: RE: [Sipping] RE: [Simple] Multimedia message
adaptationInternet-Drafts



It seems to me that these filtering drafts concern the modification of MIME
bodies in SIP messages by intermediaries. This is not exactly an
uncontroversial topic in SIP circles, and therefore I don't think it is a
foregone conclusion that this is work that some SIP-related WG should
charter. At a high level, these drafts also argue that capability
negotiation should be administered by intermediaries rather than through an
end-to-end process; this approach may attract some similar controversy.

Provided that this is work the community would like to pursue, the
applicability and impact of this mechanism is larger than the problem of
instant messaging and presence. While clearly, from the framework, instant
messaging and presence cases are driving this work, it is applicable to the
general use of SIP events (messaging, I think, is something of a corner
case). While SIMPLE could certainly spend some time refining the framework
and requirements related to IM & presence, I imagine that at a mechanism
stage this work would need to take place in SIPPING.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> Sent: Friday, November 08, 2002 3:47 AM
> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> Hi,
> 
> Actually this thread is about two separate things:
> - Event filtering
> - Multimedia message adaptation
> 
> Neither of them appears currently on any sippish WG charter 
> currently. 
> 
> Event filtering has been discussed several times and it is 
> even mentioned in (but out of scope of) SIP Events RFC. My 
> impression has been that people think that it is needed, but 
> there has been debate about scope and feasibility. I hope the 
> requirements draft will help in that discussion. My own 
> opinion is that what is concretely needed in short term is 
> some simple filtering definitions for Presence event package. 
> More wide-scoped and complex things could be worked upon as 
> the understanding accumulates.
> 
> Multimedia message adaptation hasn't been yet discussed much. 
> I think it is in general a desirable feature, especially for 
> relatively small and dumb terminals, which are not easily 
> upgradable and may not understand all media formats.
> 
> So I propose the WG chairs think where these items would be 
> appropriate, and if there is enough interest for them, let's 
> put them on the charters.
> 
> Markus
> 
> > -----Original Message-----
> > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: 08 November, 2002 5:11
> > To: Drage, Keith (Keith)
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > Well, I'd like to hear opinions from the participants here . . .
> > 
> > Clearly they aren't explicitly on the charter for either 
> > group. Do we as
> > yet have a consensus that we need to work on these 
> problems? If so, we
> > can consider WHERE to work on them. I suspect SIPPING is closer to a
> > matching scope than is SIMPLE, but the relevant ADs may have 
> > suggestions
> > to make there as well.
> > 
> > --
> > Dean
> > 
> > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > I am getting a bit confused as to which group should be 
> > discussing these filtering issues.
> > > 
> > > Could we have a statement from the WG chairs of SIPPING or 
> > SIMPLE as to whether this, and the moran drafts, are part of 
> > the scope of SIPPING or SIMPLE.
> > > 
> > > And before you say these are both author drafts, I think we 
> > do need to charter one of the WGs to do some work in this 
> > area - I am just not sure of the exact scope yet.
> > > 
> > > Keith
> > > 
> > > Keith Drage
> > > Lucent Technologies
> > > Tel: +44 1793 776249
> > > Email: drage@lucent.com 
> > > 
> > > > -----Original Message-----
> > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > Sent: 06 November 2002 18:24
> > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > Subject: [Simple] Multimedia message adaptation Internet-Drafts
> > > > 
> > > > 
> > > > 	While these drafts concern event filtering, 
> too, the subject was
> > > > 	a bit misleading because I lazily just followed 
> up Tim's e-mail.
> > > > 
> > > > 					Pekka
> > > > 
> > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > ptation-framework-00.txt
> > > > 
> > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > ptation-requirements-00.txt
> > > > 
> > > > Pekka Pessi  writes:
> > > > >We have submitted two drafts regarding multimedia message
> > > > >adaptation. A multimedia message is typically a message
> > > > >containing images, audio or video clips and their presentation
> > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > >require adaptation in some cases.
> > > > 
> > > > >Our goal is to have a framework using SIP, HTTP and MIME that
> > > > >allows a person sending multimedia message to adapt the message
> > > > >contents suitable to all the recipients. In some cases the
> > > > >adaptation can be done by the sending terminal, but we also see
> > > > >that an adaptation service would be very useful in many cases. 
> > > > >Such an adaptation mechanism is used by MMS service provided by
> > > > >cellular networks nowadays.
> > > > 
> > > > >The message adaptation work concerns both SIPPING and SIMPLE,
> > > > >the requirements I-D lists use cases and requirements for
> > > > >multimedia messaging and message adaptation solutions and the
> > > > >framework I-D tries to explore possible solutions.
> > > > 
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sip@ietf.org for new developments of core SIP
> > > 
> > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple

From rsparks@dynamicsoft.com  Mon Nov 11 10:50:21 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01365
	for ; Mon, 11 Nov 2002 10:50:21 -0500 (EST)
Received: from RjS.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gABFoM114434
	for ; Mon, 11 Nov 2002 09:50:22 -0600
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
In-Reply-To: <1036698869.12174.51.camel@RjS.localdomain>
References: <1036698869.12174.51.camel@RjS.localdomain>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 11 Nov 2002 09:44:07 -0600
Message-Id: <1037029451.920.60.camel@RjS.localdomain>
Mime-Version: 1.0
Content-Length: 1050
Subject: [Simple] Draft agenda SIMPLE IETF55
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: 

Folks -

Here's a first cut at an agenda for next week's meeting.
If I've missed a request, let me know immediately.

RjS

------------------------------------------------------------
Monday, Nov 18 2002 1530-1730 Salon III

1530 Administrivia/Agenda Bashing - Chairs
1540 Publish - Sean Olson/Aki Niemi
  draft-olson-simple-publish-01.txt
  draft-niemi-simple-publish-framework-00.txt
1600 3GPP IM&P requirements - Aki Niemi
  draft-niemi-simple-im-wireless-reqs-00.txt
  draft-kiss-simple-presence-wireless-reqs-01.txt
1610 SIP Presence Extension requirements - Paul Kyzivat
  draft-kyzivat-simple-prescaps-reqts-00.txt
1620 List Event Templates - Adam Roach
  draft-roach-sip-list-template-00.txt
1630 Data Requirements - Jonathan Rosenberg
  draft-ietf-simple-data-req-00.txt
1640 List Manipulation Operations - Markus Isomaki
  draft-isomaki-simple-list-man-sem-00.txt
1700 Message Sessions - Ben Campbell
  draft-campbell-simple-im-sessions-00.txt
  draft-campbell-simple-cpimmsg-sessions-00.txt
  draft-sparks-simple-jabber-sessions-00.txt




From eburger@snowshore.com  Tue Nov 12 09:49:16 2002
Received: from snowshore.com (keeper.snowshore.com [216.57.133.4])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05375
	for ; Tue, 12 Nov 2002 09:49:15 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Date: Tue, 12 Nov 2002 09:49:15 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D55A7@zoe.office.snowshore.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkAAi+Nw0A==
From: "Eric Burger" 
To: , ,
        , ,
        , , ,
        
Cc: , ,
        , "IETF OPES (E-mail)" ,
        "IETF LEMONADE (E-mail)" 
Content-Length: 12344
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA05375
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: 

There are already TWO work groups that are considering EXACTLY these transcoding requirements.

They are OPES and LEMONADE.

I would offer that discussion of these capabilities happen in those groups.  If SIP is the appropriate mechanism, then those groups will submit the appropriate drafts to SIPPING, outlining the requirements.

> -----Original Message----- From: Jose.Costa-Requena@nokia.com 
[snip]
> Nevertheless, "content adaptation" I-D has a wider scope 
> since it is considering any content-type and it is taking 
> into account the terminal/user preferences. So I would say 
> that  it fits into SIPPING WG while the filtering I-D is 
> mainly dealing with presence and I think it should be handled 
> at SIMPLE WG.
> BR
> Jose
> 
> -----Original Message----- From: Coulombe Stephane (NRC/Dallas) 
> > At a high level, these drafts also argue that capability
> > negotiation should be administered by intermediaries rather 
> than through an
> > end-to-end process; this approach may attract some similar 
> controversy.
> 
> Proposed capability negotiation can be used both ways (end-to-end or
> administered by intermediaries).
> 1) end-to-end: Someone who wants to send an Instant Message 
> to another user
> 	can send an OPTION query to learn about its terminal 
> capabilities and
> 	then create a message within its capabilities.
> 	
> 	I guess this is not controversial. However how 
> realistic and usable is it in practice?
> 	When composing a message, would a user really want to 
> take into consideration 
> 	the image formats to use, message size limitation, etc? 
> 
> 	For instance, you want to send a PNG image to a friend 
> and his terminal only supports 
> 	GIF format. What are you supposed to do? Find an image 
> conversion tool to convert to GIF?
> 	This is annoying if you are using a PC, imagine with a 
> mobile phone or handheld?
> 	
> 	For usability reasons, the user wants to send a message 
> without caring "too much" about 
> 	what the other end is supporting.
>  
> 2)administered by intermediaries: this is discussed in detail 
> in one of the drafts. 
> 
> 	Performing adaptation in the network is controversial 
> but this is the only way to support
> 	interoperability and good user experience. 
> 
> > the applicability and impact of this mechanism is larger 
> than the problem of
> > instant messaging and presence. While clearly, from the 
> framework, instant
> > messaging and presence cases are driving this work, it is 
> applicable to the
> > general use of SIP events (messaging, I think, is something 
> of a corner case). 
> 
> Yes, applicability and impact is larger than IM and presence. 
> It applies to many other
> applications including the case of audio/video conferencing 
> (for instance when there is 
> no common audio or video codec between two ends).  
> 
> The drafts use the "corner case" of SIP IM for a few reasons:
> 1) In SIP IM, there is no concept of capability negotiation 
> (unlike the case of sessions using SDP).
> 	A user sends a message without knowing anything about 
> the recipient's terminal capabilities.
> 2) In SIP IM, it easier to argue that there will be 
> interoperability problems because of the variety of content 
> types that could be sent (in audio/video session codecs are 
> typically more agreed on). Right now text is mostly used but 
> richer content will soon be used as is the case in Multimedia 
> Messaging Service (MMS). By the way, message adaptation is a 
> serious issue in MMS because of fast product capability 
> evolution. It's hard to keep interoperability while not 
> restricting new phones to send just "low-end" content.
> 3) It is easier to explain the problem and propose a solution 
> with a smaller well-defined problem.
> 
> Once we agree that SIP message adaptation is required, the 
> requirements and solutions should be established from global 
> perspective; not just SIP IM. For that reason, SIPPING may be 
> the most appropriate place to initiate this activity.
> 
> Stephane
> 
> -----Original Message-----
> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: Friday, November 08, 2002 6:58 AM
> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> 
> It seems to me that these filtering drafts concern the 
> modification of MIME
> bodies in SIP messages by intermediaries. This is not exactly an
> uncontroversial topic in SIP circles, and therefore I don't 
> think it is a
> foregone conclusion that this is work that some SIP-related WG should
> charter. At a high level, these drafts also argue that capability
> negotiation should be administered by intermediaries rather 
> than through an
> end-to-end process; this approach may attract some similar 
> controversy.
> 
> Provided that this is work the community would like to pursue, the
> applicability and impact of this mechanism is larger than the 
> problem of
> instant messaging and presence. While clearly, from the 
> framework, instant
> messaging and presence cases are driving this work, it is 
> applicable to the
> general use of SIP events (messaging, I think, is something 
> of a corner
> case). While SIMPLE could certainly spend some time refining 
> the framework
> and requirements related to IM & presence, I imagine that at 
> a mechanism
> stage this work would need to take place in SIPPING.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > Sent: Friday, November 08, 2002 3:47 AM
> > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> > Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > Hi,
> > 
> > Actually this thread is about two separate things:
> > - Event filtering
> > - Multimedia message adaptation
> > 
> > Neither of them appears currently on any sippish WG charter 
> > currently. 
> > 
> > Event filtering has been discussed several times and it is 
> > even mentioned in (but out of scope of) SIP Events RFC. My 
> > impression has been that people think that it is needed, but 
> > there has been debate about scope and feasibility. I hope the 
> > requirements draft will help in that discussion. My own 
> > opinion is that what is concretely needed in short term is 
> > some simple filtering definitions for Presence event package. 
> > More wide-scoped and complex things could be worked upon as 
> > the understanding accumulates.
> > 
> > Multimedia message adaptation hasn't been yet discussed much. 
> > I think it is in general a desirable feature, especially for 
> > relatively small and dumb terminals, which are not easily 
> > upgradable and may not understand all media formats.
> > 
> > So I propose the WG chairs think where these items would be 
> > appropriate, and if there is enough interest for them, let's 
> > put them on the charters.
> > 
> > Markus
> > 
> > > -----Original Message-----
> > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > Sent: 08 November, 2002 5:11
> > > To: Drage, Keith (Keith)
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > > adaptationInternet-Drafts
> > > 
> > > 
> > > Well, I'd like to hear opinions from the participants here . . .
> > > 
> > > Clearly they aren't explicitly on the charter for either 
> > > group. Do we as
> > > yet have a consensus that we need to work on these 
> > problems? If so, we
> > > can consider WHERE to work on them. I suspect SIPPING is 
> closer to a
> > > matching scope than is SIMPLE, but the relevant ADs may have 
> > > suggestions
> > > to make there as well.
> > > 
> > > --
> > > Dean
> > > 
> > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > I am getting a bit confused as to which group should be 
> > > discussing these filtering issues.
> > > > 
> > > > Could we have a statement from the WG chairs of SIPPING or 
> > > SIMPLE as to whether this, and the moran drafts, are part of 
> > > the scope of SIPPING or SIMPLE.
> > > > 
> > > > And before you say these are both author drafts, I think we 
> > > do need to charter one of the WGs to do some work in this 
> > > area - I am just not sure of the exact scope yet.
> > > > 
> > > > Keith
> > > > 
> > > > Keith Drage
> > > > Lucent Technologies
> > > > Tel: +44 1793 776249
> > > > Email: drage@lucent.com 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > Sent: 06 November 2002 18:24
> > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > Subject: [Simple] Multimedia message adaptation 
> Internet-Drafts
> > > > > 
> > > > > 
> > > > > 	While these drafts concern event filtering, 
> > too, the subject was
> > > > > 	a bit misleading because I lazily just followed 
> > up Tim's e-mail.
> > > > > 
> > > > > 					Pekka
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-framework-00.txt
> > > > > 
> > > > > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > ptation-requirements-00.txt
> > > > > 
> > > > > Pekka Pessi  writes:
> > > > > >We have submitted two drafts regarding multimedia message
> > > > > >adaptation. A multimedia message is typically a message
> > > > > >containing images, audio or video clips and their 
> presentation
> > > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > > >require adaptation in some cases.
> > > > > 
> > > > > >Our goal is to have a framework using SIP, HTTP and MIME that
> > > > > >allows a person sending multimedia message to adapt 
> the message
> > > > > >contents suitable to all the recipients. In some cases the
> > > > > >adaptation can be done by the sending terminal, but 
> we also see
> > > > > >that an adaptation service would be very useful in 
> many cases. 
> > > > > >Such an adaptation mechanism is used by MMS service 
> provided by
> > > > > >cellular networks nowadays.
> > > > > 
> > > > > >The message adaptation work concerns both SIPPING and SIMPLE,
> > > > > >the requirements I-D lists use cases and requirements for
> > > > > >multimedia messaging and message adaptation solutions and the
> > > > > >framework I-D tries to explore possible solutions.
> > > > > 
> > > > > _______________________________________________
> > > > > simple mailing list
> > > > > simple@mailman.dynamicsoft.com
> > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > 
> > > > _______________________________________________
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development of the application of SIP
> > > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> > > > Use sip@ietf.org for new developments of core SIP
> > > > 
> > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

From rsparks@dynamicsoft.com  Tue Nov 12 10:42:07 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05593
	for ; Tue, 12 Nov 2002 10:42:07 -0500 (EST)
Received: from RjS.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gACFg7119643
	for ; Tue, 12 Nov 2002 09:42:07 -0600
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 12 Nov 2002 09:35:54 -0600
Message-Id: <1037115354.1012.19.camel@RjS.localdomain>
Mime-Version: 1.0
Content-Length: 205
Subject: [Simple] Agenda and drafts
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: 

The current agenda and links to the pertaining drafts
are posted at http://www.softarmor.com/simple

Slides will be posted there as well as I get them
(try to get slides to me before the meeting).

RjS




From bindignavile.srinivas@nokia.com  Wed Nov 13 10:23:56 2002
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09753
	for ; Wed, 13 Nov 2002 10:23:55 -0500 (EST)
From: bindignavile.srinivas@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gADFObx26262
	for ; Wed, 13 Nov 2002 09:24:37 -0600 (CST)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 13 Nov 2002 09:23:53 -0600
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 13 Nov 2002 07:23:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Date: Wed, 13 Nov 2002 10:23:51 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkAAi+Nw0AA5bELA
To: , ,
        , ,
        , ,
        , ,
        
Cc: , ,
        , , 
X-OriginalArrivalTime: 13 Nov 2002 15:23:53.0225 (UTC) FILETIME=[ACB45F90:01C28B28]
Content-Length: 13948
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA09753
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: 

Hi,

As Eric has indicated, the OPES WG is considering transcoding issues! However, presently, rather than being protocol-agnostic, it is being designed for HTTP and RTP only. SIP is not being considered here.

-Srini

> -----Original Message-----
> From: ext Eric Burger [mailto:eburger@snowshore.com]
> Sent: Tuesday, November 12, 2002 9:49 AM
> To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane (NRC/Dallas);
> jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki);
> dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; Pessi Pekka
> (NRC/Helsinki); IETF OPES (E-mail); IETF LEMONADE (E-mail)
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> 
> There are already TWO work groups that are considering 
> EXACTLY these transcoding requirements.
> 
> They are OPES and LEMONADE.
> 
> I would offer that discussion of these capabilities happen in 
> those groups.  If SIP is the appropriate mechanism, then 
> those groups will submit the appropriate drafts to SIPPING, 
> outlining the requirements.
> 
> > -----Original Message----- From: Jose.Costa-Requena@nokia.com 
> [snip]
> > Nevertheless, "content adaptation" I-D has a wider scope 
> > since it is considering any content-type and it is taking 
> > into account the terminal/user preferences. So I would say 
> > that  it fits into SIPPING WG while the filtering I-D is 
> > mainly dealing with presence and I think it should be handled 
> > at SIMPLE WG.
> > BR
> > Jose
> > 
> > -----Original Message----- From: Coulombe Stephane (NRC/Dallas) 
> > > At a high level, these drafts also argue that capability
> > > negotiation should be administered by intermediaries rather 
> > than through an
> > > end-to-end process; this approach may attract some similar 
> > controversy.
> > 
> > Proposed capability negotiation can be used both ways (end-to-end or
> > administered by intermediaries).
> > 1) end-to-end: Someone who wants to send an Instant Message 
> > to another user
> > 	can send an OPTION query to learn about its terminal 
> > capabilities and
> > 	then create a message within its capabilities.
> > 	
> > 	I guess this is not controversial. However how 
> > realistic and usable is it in practice?
> > 	When composing a message, would a user really want to 
> > take into consideration 
> > 	the image formats to use, message size limitation, etc? 
> > 
> > 	For instance, you want to send a PNG image to a friend 
> > and his terminal only supports 
> > 	GIF format. What are you supposed to do? Find an image 
> > conversion tool to convert to GIF?
> > 	This is annoying if you are using a PC, imagine with a 
> > mobile phone or handheld?
> > 	
> > 	For usability reasons, the user wants to send a message 
> > without caring "too much" about 
> > 	what the other end is supporting.
> >  
> > 2)administered by intermediaries: this is discussed in detail 
> > in one of the drafts. 
> > 
> > 	Performing adaptation in the network is controversial 
> > but this is the only way to support
> > 	interoperability and good user experience. 
> > 
> > > the applicability and impact of this mechanism is larger 
> > than the problem of
> > > instant messaging and presence. While clearly, from the 
> > framework, instant
> > > messaging and presence cases are driving this work, it is 
> > applicable to the
> > > general use of SIP events (messaging, I think, is something 
> > of a corner case). 
> > 
> > Yes, applicability and impact is larger than IM and presence. 
> > It applies to many other
> > applications including the case of audio/video conferencing 
> > (for instance when there is 
> > no common audio or video codec between two ends).  
> > 
> > The drafts use the "corner case" of SIP IM for a few reasons:
> > 1) In SIP IM, there is no concept of capability negotiation 
> > (unlike the case of sessions using SDP).
> > 	A user sends a message without knowing anything about 
> > the recipient's terminal capabilities.
> > 2) In SIP IM, it easier to argue that there will be 
> > interoperability problems because of the variety of content 
> > types that could be sent (in audio/video session codecs are 
> > typically more agreed on). Right now text is mostly used but 
> > richer content will soon be used as is the case in Multimedia 
> > Messaging Service (MMS). By the way, message adaptation is a 
> > serious issue in MMS because of fast product capability 
> > evolution. It's hard to keep interoperability while not 
> > restricting new phones to send just "low-end" content.
> > 3) It is easier to explain the problem and propose a solution 
> > with a smaller well-defined problem.
> > 
> > Once we agree that SIP message adaptation is required, the 
> > requirements and solutions should be established from global 
> > perspective; not just SIP IM. For that reason, SIPPING may be 
> > the most appropriate place to initiate this activity.
> > 
> > Stephane
> > 
> > -----Original Message-----
> > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > Sent: Friday, November 08, 2002 6:58 AM
> > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
> > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > 
> > It seems to me that these filtering drafts concern the 
> > modification of MIME
> > bodies in SIP messages by intermediaries. This is not exactly an
> > uncontroversial topic in SIP circles, and therefore I don't 
> > think it is a
> > foregone conclusion that this is work that some SIP-related 
> WG should
> > charter. At a high level, these drafts also argue that capability
> > negotiation should be administered by intermediaries rather 
> > than through an
> > end-to-end process; this approach may attract some similar 
> > controversy.
> > 
> > Provided that this is work the community would like to pursue, the
> > applicability and impact of this mechanism is larger than the 
> > problem of
> > instant messaging and presence. While clearly, from the 
> > framework, instant
> > messaging and presence cases are driving this work, it is 
> > applicable to the
> > general use of SIP events (messaging, I think, is something 
> > of a corner
> > case). While SIMPLE could certainly spend some time refining 
> > the framework
> > and requirements related to IM & presence, I imagine that at 
> > a mechanism
> > stage this work would need to take place in SIPPING.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > > Sent: Friday, November 08, 2002 3:47 AM
> > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> > > Gonzalo.Camarillo@lmf.ericsson.se
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > > adaptationInternet-Drafts
> > > 
> > > 
> > > Hi,
> > > 
> > > Actually this thread is about two separate things:
> > > - Event filtering
> > > - Multimedia message adaptation
> > > 
> > > Neither of them appears currently on any sippish WG charter 
> > > currently. 
> > > 
> > > Event filtering has been discussed several times and it is 
> > > even mentioned in (but out of scope of) SIP Events RFC. My 
> > > impression has been that people think that it is needed, but 
> > > there has been debate about scope and feasibility. I hope the 
> > > requirements draft will help in that discussion. My own 
> > > opinion is that what is concretely needed in short term is 
> > > some simple filtering definitions for Presence event package. 
> > > More wide-scoped and complex things could be worked upon as 
> > > the understanding accumulates.
> > > 
> > > Multimedia message adaptation hasn't been yet discussed much. 
> > > I think it is in general a desirable feature, especially for 
> > > relatively small and dumb terminals, which are not easily 
> > > upgradable and may not understand all media formats.
> > > 
> > > So I propose the WG chairs think where these items would be 
> > > appropriate, and if there is enough interest for them, let's 
> > > put them on the charters.
> > > 
> > > Markus
> > > 
> > > > -----Original Message-----
> > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > > Sent: 08 November, 2002 5:11
> > > > To: Drage, Keith (Keith)
> > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > > > adaptationInternet-Drafts
> > > > 
> > > > 
> > > > Well, I'd like to hear opinions from the participants here . . .
> > > > 
> > > > Clearly they aren't explicitly on the charter for either 
> > > > group. Do we as
> > > > yet have a consensus that we need to work on these 
> > > problems? If so, we
> > > > can consider WHERE to work on them. I suspect SIPPING is 
> > closer to a
> > > > matching scope than is SIMPLE, but the relevant ADs may have 
> > > > suggestions
> > > > to make there as well.
> > > > 
> > > > --
> > > > Dean
> > > > 
> > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > > I am getting a bit confused as to which group should be 
> > > > discussing these filtering issues.
> > > > > 
> > > > > Could we have a statement from the WG chairs of SIPPING or 
> > > > SIMPLE as to whether this, and the moran drafts, are part of 
> > > > the scope of SIPPING or SIMPLE.
> > > > > 
> > > > > And before you say these are both author drafts, I think we 
> > > > do need to charter one of the WGs to do some work in this 
> > > > area - I am just not sure of the exact scope yet.
> > > > > 
> > > > > Keith
> > > > > 
> > > > > Keith Drage
> > > > > Lucent Technologies
> > > > > Tel: +44 1793 776249
> > > > > Email: drage@lucent.com 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > > Sent: 06 November 2002 18:24
> > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > > Subject: [Simple] Multimedia message adaptation 
> > Internet-Drafts
> > > > > > 
> > > > > > 
> > > > > > 	While these drafts concern event filtering, 
> > > too, the subject was
> > > > > > 	a bit misleading because I lazily just followed 
> > > up Tim's e-mail.
> > > > > > 
> > > > > > 					Pekka
> > > > > > 
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > ptation-framework-00.txt
> > > > > > 
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > ptation-requirements-00.txt
> > > > > > 
> > > > > > Pekka Pessi  writes:
> > > > > > >We have submitted two drafts regarding multimedia message
> > > > > > >adaptation. A multimedia message is typically a message
> > > > > > >containing images, audio or video clips and their 
> > presentation
> > > > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > > > >require adaptation in some cases.
> > > > > > 
> > > > > > >Our goal is to have a framework using SIP, HTTP 
> and MIME that
> > > > > > >allows a person sending multimedia message to adapt 
> > the message
> > > > > > >contents suitable to all the recipients. In some cases the
> > > > > > >adaptation can be done by the sending terminal, but 
> > we also see
> > > > > > >that an adaptation service would be very useful in 
> > many cases. 
> > > > > > >Such an adaptation mechanism is used by MMS service 
> > provided by
> > > > > > >cellular networks nowadays.
> > > > > > 
> > > > > > >The message adaptation work concerns both SIPPING 
> and SIMPLE,
> > > > > > >the requirements I-D lists use cases and requirements for
> > > > > > >multimedia messaging and message adaptation 
> solutions and the
> > > > > > >framework I-D tries to explore possible solutions.
> > > > > > 
> > > > > > _______________________________________________
> > > > > > simple mailing list
> > > > > > simple@mailman.dynamicsoft.com
> > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > > 
> > > > > _______________________________________________
> > > > > Sipping mailing list  
> > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > This list is for NEW development of the application of SIP
> > > > > Use sip-implementors@cs.columbia.edu for questions on 
> > current sip
> > > > > Use sip@ietf.org for new developments of core SIP
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From Gonzalo.Camarillo@lmf.ericsson.se  Wed Nov 13 10:36:12 2002
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09841
	for ; Wed, 13 Nov 2002 10:36:12 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gADFZlKV018978;
	Wed, 13 Nov 2002 16:35:47 +0100 (MET)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.56])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id gADFZkCG000970;
	Wed, 13 Nov 2002 17:35:46 +0200 (EET)
Message-ID: <3DD27151.2D2ADEF8@lmf.ericsson.se>
Date: Wed, 13 Nov 2002 17:35:45 +0200
From: Gonzalo Camarillo 
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: bindignavile.srinivas@nokia.com
CC: eburger@snowshore.com, Jose.Costa-Requena@nokia.com,
        Stephane.Coulombe@nokia.com, jon.peterson@neustar.biz,
        Markus.Isomaki@nokia.com, dean.willis@softarmor.com, drage@lucent.com,
        rohan@cisco.com, sipping@ietf.org, simple@mailman.dynamicsoft.com,
        Pekka.Pessi@nokia.com, ietf-openproxy@imc.org, um@snowshore.com
Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 555
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: 

Hi,

http://www.ietf.org/internet-drafts/draft-camarillo-sip-deaf-01.txt
http://www.ietf.org/internet-drafts/draft-camarillo-sip-deaf-01.pdf

and

http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-source-sink-00.txt

deal with transcoding invocation in SIP and SDP.

Gonzalo

bindignavile.srinivas@nokia.com wrote:
> 
> Hi,
> 
> As Eric has indicated, the OPES WG is considering transcoding issues! However, presently, rather than being protocol-agnostic, it is being designed for HTTP and RTP only. SIP is not being considered here.
> 
> -Srini

From Jose.Costa-Requena@nokia.com  Wed Nov 13 10:35:46 2002
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 KAA09825
	for ; Wed, 13 Nov 2002 10:35:44 -0500 (EST)
From: Jose.Costa-Requena@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gADFZDO16211
	for ; Wed, 13 Nov 2002 17:35:13 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 13 Nov 2002 17:35:35 +0200
Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 13 Nov 2002 17:35:35 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Date: Wed, 13 Nov 2002 17:35:33 +0200
Message-ID: <07A6D72550C5E0459DE676439EE53846CC49E4@esebe012.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKHa5CNEMtfRz3cQRuNgd/C/YnuKwADld2AACYMJkAAi+Nw0AA5bELAAABf5yA=
To: , ,
        , ,
        , ,
        , ,
        
Cc: , ,
        , , 
X-OriginalArrivalTime: 13 Nov 2002 15:35:35.0575 (UTC) FILETIME=[4F567A70:01C28B2A]
Content-Length: 14043
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA09825
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: 

Hi,

According to LEMONADE requirements, it is considering mainly messaging systems and I agree that this proposal could fit into that context at some extent. Nevertheless, the actual proposal deals with content adaptation based on UA capabilities registered with SIP. Thus, I consider that it is within SIPPING scope, as well.
Comments?
BR
Jose

-----Original Message-----
From: Srinivas Bindignavile (NRC/Boston) 
Subject: RE: [Sipping] RE: [Simple] Multimedia message
adaptationInternet-Drafts


Hi,

As Eric has indicated, the OPES WG is considering transcoding issues! However, presently, rather than being protocol-agnostic, it is being designed for HTTP and RTP only. SIP is not being considered here.

-Srini

> -----Original Message-----
> From: ext Eric Burger [mailto:eburger@snowshore.com]
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
> 
> 
> 
> There are already TWO work groups that are considering 
> EXACTLY these transcoding requirements.
> 
> They are OPES and LEMONADE.
> 
> I would offer that discussion of these capabilities happen in 
> those groups.  If SIP is the appropriate mechanism, then 
> those groups will submit the appropriate drafts to SIPPING, 
> outlining the requirements.
> 
> > -----Original Message----- From: Jose.Costa-Requena@nokia.com 
> [snip]
> > Nevertheless, "content adaptation" I-D has a wider scope 
> > since it is considering any content-type and it is taking 
> > into account the terminal/user preferences. So I would say 
> > that  it fits into SIPPING WG while the filtering I-D is 
> > mainly dealing with presence and I think it should be handled 
> > at SIMPLE WG.
> > BR
> > Jose
> > 
> > -----Original Message----- From: Coulombe Stephane (NRC/Dallas) 
> > > At a high level, these drafts also argue that capability
> > > negotiation should be administered by intermediaries rather 
> > than through an
> > > end-to-end process; this approach may attract some similar 
> > controversy.
> > 
> > Proposed capability negotiation can be used both ways (end-to-end or
> > administered by intermediaries).
> > 1) end-to-end: Someone who wants to send an Instant Message 
> > to another user
> > 	can send an OPTION query to learn about its terminal 
> > capabilities and
> > 	then create a message within its capabilities.
> > 	
> > 	I guess this is not controversial. However how 
> > realistic and usable is it in practice?
> > 	When composing a message, would a user really want to 
> > take into consideration 
> > 	the image formats to use, message size limitation, etc? 
> > 
> > 	For instance, you want to send a PNG image to a friend 
> > and his terminal only supports 
> > 	GIF format. What are you supposed to do? Find an image 
> > conversion tool to convert to GIF?
> > 	This is annoying if you are using a PC, imagine with a 
> > mobile phone or handheld?
> > 	
> > 	For usability reasons, the user wants to send a message 
> > without caring "too much" about 
> > 	what the other end is supporting.
> >  
> > 2)administered by intermediaries: this is discussed in detail 
> > in one of the drafts. 
> > 
> > 	Performing adaptation in the network is controversial 
> > but this is the only way to support
> > 	interoperability and good user experience. 
> > 
> > > the applicability and impact of this mechanism is larger 
> > than the problem of
> > > instant messaging and presence. While clearly, from the 
> > framework, instant
> > > messaging and presence cases are driving this work, it is 
> > applicable to the
> > > general use of SIP events (messaging, I think, is something 
> > of a corner case). 
> > 
> > Yes, applicability and impact is larger than IM and presence. 
> > It applies to many other
> > applications including the case of audio/video conferencing 
> > (for instance when there is 
> > no common audio or video codec between two ends).  
> > 
> > The drafts use the "corner case" of SIP IM for a few reasons:
> > 1) In SIP IM, there is no concept of capability negotiation 
> > (unlike the case of sessions using SDP).
> > 	A user sends a message without knowing anything about 
> > the recipient's terminal capabilities.
> > 2) In SIP IM, it easier to argue that there will be 
> > interoperability problems because of the variety of content 
> > types that could be sent (in audio/video session codecs are 
> > typically more agreed on). Right now text is mostly used but 
> > richer content will soon be used as is the case in Multimedia 
> > Messaging Service (MMS). By the way, message adaptation is a 
> > serious issue in MMS because of fast product capability 
> > evolution. It's hard to keep interoperability while not 
> > restricting new phones to send just "low-end" content.
> > 3) It is easier to explain the problem and propose a solution 
> > with a smaller well-defined problem.
> > 
> > Once we agree that SIP message adaptation is required, the 
> > requirements and solutions should be established from global 
> > perspective; not just SIP IM. For that reason, SIPPING may be 
> > the most appropriate place to initiate this activity.
> > 
> > Stephane
> > 
> > -----Original Message-----
> > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > Sent: Friday, November 08, 2002 6:58 AM
> > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
> > drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > adaptationInternet-Drafts
> > 
> > 
> > 
> > It seems to me that these filtering drafts concern the 
> > modification of MIME
> > bodies in SIP messages by intermediaries. This is not exactly an
> > uncontroversial topic in SIP circles, and therefore I don't 
> > think it is a
> > foregone conclusion that this is work that some SIP-related 
> WG should
> > charter. At a high level, these drafts also argue that capability
> > negotiation should be administered by intermediaries rather 
> > than through an
> > end-to-end process; this approach may attract some similar 
> > controversy.
> > 
> > Provided that this is work the community would like to pursue, the
> > applicability and impact of this mechanism is larger than the 
> > problem of
> > instant messaging and presence. While clearly, from the 
> > framework, instant
> > messaging and presence cases are driving this work, it is 
> > applicable to the
> > general use of SIP events (messaging, I think, is something 
> > of a corner
> > case). While SIMPLE could certainly spend some time refining 
> > the framework
> > and requirements related to IM & presence, I imagine that at 
> > a mechanism
> > stage this work would need to take place in SIPPING.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > -----Original Message-----
> > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > > Sent: Friday, November 08, 2002 3:47 AM
> > > To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
> > > Gonzalo.Camarillo@lmf.ericsson.se
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: RE: [Sipping] RE: [Simple] Multimedia message
> > > adaptationInternet-Drafts
> > > 
> > > 
> > > Hi,
> > > 
> > > Actually this thread is about two separate things:
> > > - Event filtering
> > > - Multimedia message adaptation
> > > 
> > > Neither of them appears currently on any sippish WG charter 
> > > currently. 
> > > 
> > > Event filtering has been discussed several times and it is 
> > > even mentioned in (but out of scope of) SIP Events RFC. My 
> > > impression has been that people think that it is needed, but 
> > > there has been debate about scope and feasibility. I hope the 
> > > requirements draft will help in that discussion. My own 
> > > opinion is that what is concretely needed in short term is 
> > > some simple filtering definitions for Presence event package. 
> > > More wide-scoped and complex things could be worked upon as 
> > > the understanding accumulates.
> > > 
> > > Multimedia message adaptation hasn't been yet discussed much. 
> > > I think it is in general a desirable feature, especially for 
> > > relatively small and dumb terminals, which are not easily 
> > > upgradable and may not understand all media formats.
> > > 
> > > So I propose the WG chairs think where these items would be 
> > > appropriate, and if there is enough interest for them, let's 
> > > put them on the charters.
> > > 
> > > Markus
> > > 
> > > > -----Original Message-----
> > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > > Sent: 08 November, 2002 5:11
> > > > To: Drage, Keith (Keith)
> > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message
> > > > adaptationInternet-Drafts
> > > > 
> > > > 
> > > > Well, I'd like to hear opinions from the participants here . . .
> > > > 
> > > > Clearly they aren't explicitly on the charter for either 
> > > > group. Do we as
> > > > yet have a consensus that we need to work on these 
> > > problems? If so, we
> > > > can consider WHERE to work on them. I suspect SIPPING is 
> > closer to a
> > > > matching scope than is SIMPLE, but the relevant ADs may have 
> > > > suggestions
> > > > to make there as well.
> > > > 
> > > > --
> > > > Dean
> > > > 
> > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > > I am getting a bit confused as to which group should be 
> > > > discussing these filtering issues.
> > > > > 
> > > > > Could we have a statement from the WG chairs of SIPPING or 
> > > > SIMPLE as to whether this, and the moran drafts, are part of 
> > > > the scope of SIPPING or SIMPLE.
> > > > > 
> > > > > And before you say these are both author drafts, I think we 
> > > > do need to charter one of the WGs to do some work in this 
> > > > area - I am just not sure of the exact scope yet.
> > > > > 
> > > > > Keith
> > > > > 
> > > > > Keith Drage
> > > > > Lucent Technologies
> > > > > Tel: +44 1793 776249
> > > > > Email: drage@lucent.com 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > > Sent: 06 November 2002 18:24
> > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > > Subject: [Simple] Multimedia message adaptation 
> > Internet-Drafts
> > > > > > 
> > > > > > 
> > > > > > 	While these drafts concern event filtering, 
> > > too, the subject was
> > > > > > 	a bit misleading because I lazily just followed 
> > > up Tim's e-mail.
> > > > > > 
> > > > > > 					Pekka
> > > > > > 
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > ptation-framework-00.txt
> > > > > > 
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > ptation-requirements-00.txt
> > > > > > 
> > > > > > Pekka Pessi  writes:
> > > > > > >We have submitted two drafts regarding multimedia message
> > > > > > >adaptation. A multimedia message is typically a message
> > > > > > >containing images, audio or video clips and their 
> > presentation
> > > > > > >information, e.g., smil. Also, even XML-formatted text may
> > > > > > >require adaptation in some cases.
> > > > > > 
> > > > > > >Our goal is to have a framework using SIP, HTTP 
> and MIME that
> > > > > > >allows a person sending multimedia message to adapt 
> > the message
> > > > > > >contents suitable to all the recipients. In some cases the
> > > > > > >adaptation can be done by the sending terminal, but 
> > we also see
> > > > > > >that an adaptation service would be very useful in 
> > many cases. 
> > > > > > >Such an adaptation mechanism is used by MMS service 
> > provided by
> > > > > > >cellular networks nowadays.
> > > > > > 
> > > > > > >The message adaptation work concerns both SIPPING 
> and SIMPLE,
> > > > > > >the requirements I-D lists use cases and requirements for
> > > > > > >multimedia messaging and message adaptation 
> solutions and the
> > > > > > >framework I-D tries to explore possible solutions.
> > > > > > 
> > > > > > _______________________________________________
> > > > > > simple mailing list
> > > > > > simple@mailman.dynamicsoft.com
> > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > > 
> > > > > _______________________________________________
> > > > > Sipping mailing list  
> > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > This list is for NEW development of the application of SIP
> > > > > Use sip-implementors@cs.columbia.edu for questions on 
> > current sip
> > > > > Use sip@ietf.org for new developments of core SIP
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sip@ietf.org for new developments of core SIP
> > 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From bcampbell@dynamicsoft.com  Wed Nov 13 17:06:04 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11099
	for ; Wed, 13 Nov 2002 17:06:04 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gADM5lU1045392;
	Wed, 13 Nov 2002 16:05:48 -0600 (CST)
Message-ID: <3DD2CCB5.7070703@dynamicsoft.com>
Date: Wed, 13 Nov 2002 16:05:41 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: Paul Kyzivat , Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 11593
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: 

Sorry for the delayed response.

My gut tells me this is all way more complicated than it appears to be. 
Perhaps I am missing something big. Specific comments inline.

Jonathan Rosenberg wrote:
> inline.
> 
> Paul Kyzivat wrote:
>  > Jonathan, Ben,
>  >
>  > I would be pleased if we can find a way to finesse this. The problem
>  > is that comedia requires some way to infer, from the sip signaling
>  > and SDP content, when connections should be made/dropped. Both sides
>  > must make the same inference, or else the connection establishment
>  > will fail. As soon as we start to pool connections there starts to be
>  > the potential for race conditions.
>  >
>  > This is especially a problem with connections between two
>  > intermediaries. The hard question is: when can you ever drop a
>  > connection between two intermediaries?
> 
> I don't see this as that critical. I would guess that the passive side 
> of a connection can always close, and the active side would just reopen 
> if the session isn't terminated. No? I think comedia says you shouldnt 
> close the connection before the session ends, but sometimes that happens 
> for a variety of reasons. It should say something about retrying.
> 
> 
> f course an intermediary
>  > never knows if its peer in the connection is also an intermediary or
>  > not, so it must act as if the peer is a UA following the comedia spec
>  > plus whatever additional rules we can come up with for simple.
> 
> Right.
> 
>  > We
>  > can't drop a connection until we know that there are no sessions
>  > using it. A corollary to that is that we can't reuse a connection
>  > that has no sessions using it, because it might be dropped. And so we
>  > should drop a connection as soon as there are no sessions using it,
>  > because it is then worthless.
>  >
>  > That already starts looking suboptimal, because we must drop
>  > connections between pairs of high traffic intermediaries any time
>  > there doesn't happen to be some session traversing them.
> 
> I think you want to decouple the connection lifetimes from the session 
> lifetimes.
> 
>  >
>  > But I'm not sure this is workable even with that limitation. I have a
>  > hunch there is still a race condition when one end will think there
>  > is a connection and attempt to reuse it, while the other end has
>  > decided there is no session using the connection and tries to drop it
>  > or establish a new one. This is tricky, and probably impossible to
>  > decide in general except with respect to a precise rule for reuse.
>  > But here is one case that seems simpler than some others:


So, what happens if you attempt to resuse a connection that is dropped? 
Won't that fact quickly become apparent? Can't we just reconnect?

There may be a complication here in that comedia says you can't just 
reconnect, you must renegotiate SDP--but scenario under discussion 
results from an SDP notification, so I am not sure if that requirement 
is constrainint here.




>  >
>  > Suppose we are in the process of establishing a call between
>  >
>  > A-----I1-----I2-----B
>  >
>  > and there was no connection between I1 and I2. A includes an offer in
>  > the invite, so I1 and I2 will each rewrite the SDP as the invite goes
>  > by. But neither I1 nor I2 yet knows if the invite will succeed, so
>  > don't know if this will result in establishing a connection.
>  >
>  > Meanwhile, we start to establish a new call
>  >
>  > C-----I1-----I2-----D
>  >
>  > C includes an offer in the invite. I1 needs to rewrite the SDP in the
>  > offer, and would like to reuse the connection it has proposed
>  > establishing with I2. But it doesn't yet know if that call will
>  > succeed and so doesn't know if the connection will be established.
>  > Hence I believe it must assume there will be no connection to reuse,
> 
> This is an artifact of a very bad design choice made by comedia.
> 
> What you REALLY want is that whenever I1 modifies an INVITE, it *always* 
> puts the same port number/IP into the SDP. Multiple connections can be 
> established onto that IP/port. Thus, both the INVITE from A and from C, 
> I1 would place the same IP/port into the SDP.
> 
> Now, if either of those should succeed, I1 will try to open a connection 
> to that IP/port. If it already has one there, that gets reused.
> 
> So, whats the problem? Well, all intermediaries need to maintain a 
> routing table, which tells them what to do with incoming messages. That 
> table tells them that if an IM arrives on some specific connection, with 
> a specific URI/identifier in the outer envelope, to forward to a 
> different connection with a different URI/identifier in the outer 
> envelope. THis means that the intermediary has to associate each 
> connection with a specific dialog used to set it up (since the dialog is 
> used to exchange the SDP that contains the URI/identifiers). How is this 
> association done?

I am not sure I understand the difficulty here. These intermediaries 
surely must be SIP aware, if they are in the business of re-writing SDP. 
Additionally, it seems to me that they must be dialog stateful devices. 
Why can't they just maintain a table that associates a dialog with a 
session, and the session with a connection, where the association 
between session and connection is many-to-one?

If we get SDP describing a new _session_, it will contain address, port, 
and direction information. A device can check the connection table to 
determine whether it currently has a connection opened to that 
particular address and port, can't it? If so, why can't it just start 
interleaving messages for the new session onto the existing connection? 
Maybe I am being dense, but I do not understand what problem the 
connection-id mechanism below is trying to solve.

> 
> Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out 
> by A in your example contains the source IP/port it will make the 
> connection from. So, when I1 receives the connection request, it can 
> determine the source, and then match it to the dialog. The problem is, 
> this doesn't work at all through NAT. If you don't want to use the 
> source to demux, the intermediary can arrange for each connection to 
> occur on a different port, and that means no reuse. So, we have a real 
> problem.
> 

I will note that comedia says you should _not_ use source address this 
way unless you are certain your network is free of the blight of NATs.

But since a connection can carry more than one session, it makes no 
sense to try to tie a connection request to a particular dialog. The 
cpim-msgfmt session draft has its own mechanism for identifying the 
session. Why can a participating device not relate that to the dialog 
that set upt he session in the first place?

> I registered this complaint about comedia/NAT to mmusic some time back, 
> but it was ignored. IMHO its still a show stopper. Its especially 
> heinous when you want to add intermediaries, which wasn't considered at 
> the time.
> 
> My proposal would be to use connection identifiers separate from 
> addresses. The SDP contains some kind of parameter that identifies the 
> connection. Its just a random token. Whenever the connection is opened, 
> the active side sends, as the first bytes, this identifier. THis way, 
> the passive side knows which dialog its associated with, without needing 
> to rely on source IP.
> 
> So, lets go through an example of how this works with a single 
> intermediary. We've got A----I-----B:
> 
> * A sends an INVITE. SDP has a connection identifier of CID-A1 and a URI 
> of sip:A1. Through comedia it says it can be both active or passive. Of 
> course we want it to be active in case its natted. This goes to I.
> 
> * I rewrites the SDP. It places a different IP/port (some common one 
> used in all requests), and a new connection ID, CID-I1. It rewrites the 
> address to sip:I1. It also indicates passive only. Note that, since its 
> passive, the connection ID isn't important. This goes to B.
> 
> * B sends a 200 OK. It indicates active in its SDP. It includes a 
> connection ID of CID-B1 and URI of sip:B1.
> 
> * I rewrites the SDP in the 200 OK. It includes the same common IP/port, 
> but yet another connection ID, CID-I2 and URI sip:I2. Forwards to A. 
> Now, I knows that messages from sip:A1 on either connection CID-I2 or 
> CID-A1 go to sip:B1, on either connection CID-I1 or CID-B1. Which 
> connection depends on which direction establishes.
> 
> * A opens a connection to I. Once opened, it passes CID-A1 on the 
> connection. Now, I knows that this connection corresponds to the dialog 
> it established with A. Similarly, B opens a connection to I, passes 
> CID-B1, and I knows that this connection is associated with the dialog 
> opened to B. Forwarding happens.
> 
> 
> Now, consider the more complex case, of two intermediaries. So its 
> A---I---IJ---B. Lets say there is already a connection opened between I 
> and J. I had indicated a connection ID of CID-I1, and J had indicated 
> CID-J1.
> 
> * A sends an INVITE. connection ID is new, CID-A1. URI is sip:A1. It 
> indicates direction:both. Includes some IP/port for receiving connections.
> 
> * I gets the INVITE. Rewrites the SDP to CID-I2 (a new ID - since it 
> doesn't know who will get this, whether a connection is there already). 
> Rewrites the URI to sip:I2. Direction passive. Includes its common 
> IP/port. Sends to J.
> 
> * J gets the INVITE. Rewrites the SDP to CID-J2, also a new ID. Rewrites 
> the URI to sip:J2. Direction, passive. Includes its common IP/port. 
> Sends to B.
> 
> * B gets the INVITE. Sends a 200 OK. B notices it doesn't have a 
> connection to the IP/port indicated by J in the SDP. So, it creates a 
> new CID, CID-B1, and places that in its SDP, along with direction:active.
> 
> * J gets the 200 OK. J notices that it does have a connection to the 
> IP/port in the INVITE it received. So, it decides it can reuse that 
> connection. So, it rewrites the SDP in the 200 OK with CID-J1 (the ID it 
> had formerly exchanged with I), and indicates a direction of active. 
> FOrwards to I.
> 
> * I gets the 200 OK. I sees that it DOESNT have a connection to the 
> IP/port that A provided, so it creates a new connection ID, CID-I3, and 
> places that in the 200 OK. It indicates a direction of passive. Places 
> its common IP/port in the SDP, sends to A.
> 
> * Now, the SDP that A got indicated passive. So, it opens a connection 
> to the IP/port provided by I. It sends its proposed connection ID, 
> CID-A1 once the connection is opened.
> 
> * The SDP that B got indicated passive. So, it opens a connection to the 
> IP/port that J provided. It sends its proposed connection ID, CID-B1, 
> once the connection is opened.
> 
> * I and J realize that the connection IDs exchanged betwen them relate 
> to an existing connection, so they don't open a new one.
> 
> 
> If the connection between I and J should close, either side would 
> re-initiate, and it would reuse the connection ID it had stored and 
> remembered as associated with the destiation IP/port it needs to open a 
> connection to.
> 
> 
> Now, I *think* this works. I'm a bit hazy on the precise rules of usage 
> and reuse of these connection IDs. THe aim is to do something that 
> doesnt require a re-INVITE when a new connection is opened. Again - we 
> want to separate connection lifetime from session lifetime.
> 
> This solution allows for connection reuse and also works smoothly 
> through NAT without any pains.
> 
> Thoughts?
> 
> -Jonathan R.
> 
> 



From rohan@cisco.com  Wed Nov 13 21:01:19 2002
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.70.145.30])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11790
	for ; Wed, 13 Nov 2002 21:01:19 -0500 (EST)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gAE20eu4015989;
	Wed, 13 Nov 2002 18:00:40 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ABH19643;
	Wed, 13 Nov 2002 17:58:20 -0800 (PST)
Date: Wed, 13 Nov 2002 18:00:46 -0800
Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: , ,
        , ,
        , ,
        , ,
        , ,
        , ,
        
To: Jose.Costa-Requena@nokia.com
From: Rohan Mahy 
In-Reply-To: <07A6D72550C5E0459DE676439EE53846CC49E4@esebe012.ntc.nokia.com>
Message-Id: 
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Length: 14160
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: 

hello,

please cease an desist cross posting when you reply.  sipping seems 
like the default wg, so please send your comments only to 
sipping@ietf.org.

thanks,
-rohan

On Wednesday, November 13, 2002, at 07:35 AM, 
Jose.Costa-Requena@nokia.com wrote:

> Hi,
>
> According to LEMONADE requirements, it is considering mainly messaging 
> systems and I agree that this proposal could fit into that context at 
> some extent. Nevertheless, the actual proposal deals with content 
> adaptation based on UA capabilities registered with SIP. Thus, I 
> consider that it is within SIPPING scope, as well.
> Comments?
> BR
> Jose
>
> -----Original Message-----
> From: Srinivas Bindignavile (NRC/Boston)
> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> adaptationInternet-Drafts
>
>
> Hi,
>
> As Eric has indicated, the OPES WG is considering transcoding issues! 
> However, presently, rather than being protocol-agnostic, it is being 
> designed for HTTP and RTP only. SIP is not being considered here.
>
> -Srini
>
>> -----Original Message-----
>> From: ext Eric Burger [mailto:eburger@snowshore.com]
>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>> adaptationInternet-Drafts
>>
>>
>>
>> There are already TWO work groups that are considering
>> EXACTLY these transcoding requirements.
>>
>> They are OPES and LEMONADE.
>>
>> I would offer that discussion of these capabilities happen in
>> those groups.  If SIP is the appropriate mechanism, then
>> those groups will submit the appropriate drafts to SIPPING,
>> outlining the requirements.
>>
>>> -----Original Message----- From: Jose.Costa-Requena@nokia.com
>> [snip]
>>> Nevertheless, "content adaptation" I-D has a wider scope
>>> since it is considering any content-type and it is taking
>>> into account the terminal/user preferences. So I would say
>>> that  it fits into SIPPING WG while the filtering I-D is
>>> mainly dealing with presence and I think it should be handled
>>> at SIMPLE WG.
>>> BR
>>> Jose
>>>
>>> -----Original Message----- From: Coulombe Stephane (NRC/Dallas)
>>>> At a high level, these drafts also argue that capability
>>>> negotiation should be administered by intermediaries rather
>>> than through an
>>>> end-to-end process; this approach may attract some similar
>>> controversy.
>>>
>>> Proposed capability negotiation can be used both ways (end-to-end or
>>> administered by intermediaries).
>>> 1) end-to-end: Someone who wants to send an Instant Message
>>> to another user
>>> 	can send an OPTION query to learn about its terminal
>>> capabilities and
>>> 	then create a message within its capabilities.
>>> 	
>>> 	I guess this is not controversial. However how
>>> realistic and usable is it in practice?
>>> 	When composing a message, would a user really want to
>>> take into consideration
>>> 	the image formats to use, message size limitation, etc?
>>>
>>> 	For instance, you want to send a PNG image to a friend
>>> and his terminal only supports
>>> 	GIF format. What are you supposed to do? Find an image
>>> conversion tool to convert to GIF?
>>> 	This is annoying if you are using a PC, imagine with a
>>> mobile phone or handheld?
>>> 	
>>> 	For usability reasons, the user wants to send a message
>>> without caring "too much" about
>>> 	what the other end is supporting.
>>>
>>> 2)administered by intermediaries: this is discussed in detail
>>> in one of the drafts.
>>>
>>> 	Performing adaptation in the network is controversial
>>> but this is the only way to support
>>> 	interoperability and good user experience.
>>>
>>>> the applicability and impact of this mechanism is larger
>>> than the problem of
>>>> instant messaging and presence. While clearly, from the
>>> framework, instant
>>>> messaging and presence cases are driving this work, it is
>>> applicable to the
>>>> general use of SIP events (messaging, I think, is something
>>> of a corner case).
>>>
>>> Yes, applicability and impact is larger than IM and presence.
>>> It applies to many other
>>> applications including the case of audio/video conferencing
>>> (for instance when there is
>>> no common audio or video codec between two ends).
>>>
>>> The drafts use the "corner case" of SIP IM for a few reasons:
>>> 1) In SIP IM, there is no concept of capability negotiation
>>> (unlike the case of sessions using SDP).
>>> 	A user sends a message without knowing anything about
>>> the recipient's terminal capabilities.
>>> 2) In SIP IM, it easier to argue that there will be
>>> interoperability problems because of the variety of content
>>> types that could be sent (in audio/video session codecs are
>>> typically more agreed on). Right now text is mostly used but
>>> richer content will soon be used as is the case in Multimedia
>>> Messaging Service (MMS). By the way, message adaptation is a
>>> serious issue in MMS because of fast product capability
>>> evolution. It's hard to keep interoperability while not
>>> restricting new phones to send just "low-end" content.
>>> 3) It is easier to explain the problem and propose a solution
>>> with a smaller well-defined problem.
>>>
>>> Once we agree that SIP message adaptation is required, the
>>> requirements and solutions should be established from global
>>> perspective; not just SIP IM. For that reason, SIPPING may be
>>> the most appropriate place to initiate this activity.
>>>
>>> Stephane
>>>
>>> -----Original Message-----
>>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
>>> Sent: Friday, November 08, 2002 6:58 AM
>>> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
>>> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>>> adaptationInternet-Drafts
>>>
>>>
>>>
>>> It seems to me that these filtering drafts concern the
>>> modification of MIME
>>> bodies in SIP messages by intermediaries. This is not exactly an
>>> uncontroversial topic in SIP circles, and therefore I don't
>>> think it is a
>>> foregone conclusion that this is work that some SIP-related
>> WG should
>>> charter. At a high level, these drafts also argue that capability
>>> negotiation should be administered by intermediaries rather
>>> than through an
>>> end-to-end process; this approach may attract some similar
>>> controversy.
>>>
>>> Provided that this is work the community would like to pursue, the
>>> applicability and impact of this mechanism is larger than the
>>> problem of
>>> instant messaging and presence. While clearly, from the
>>> framework, instant
>>> messaging and presence cases are driving this work, it is
>>> applicable to the
>>> general use of SIP events (messaging, I think, is something
>>> of a corner
>>> case). While SIMPLE could certainly spend some time refining
>>> the framework
>>> and requirements related to IM & presence, I imagine that at
>>> a mechanism
>>> stage this work would need to take place in SIPPING.
>>>
>>> Jon Peterson
>>> NeuStar, Inc.
>>>
>>>> -----Original Message-----
>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
>>>> Sent: Friday, November 08, 2002 3:47 AM
>>>> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
>>>> Gonzalo.Camarillo@lmf.ericsson.se
>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>>>> adaptationInternet-Drafts
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Actually this thread is about two separate things:
>>>> - Event filtering
>>>> - Multimedia message adaptation
>>>>
>>>> Neither of them appears currently on any sippish WG charter
>>>> currently.
>>>>
>>>> Event filtering has been discussed several times and it is
>>>> even mentioned in (but out of scope of) SIP Events RFC. My
>>>> impression has been that people think that it is needed, but
>>>> there has been debate about scope and feasibility. I hope the
>>>> requirements draft will help in that discussion. My own
>>>> opinion is that what is concretely needed in short term is
>>>> some simple filtering definitions for Presence event package.
>>>> More wide-scoped and complex things could be worked upon as
>>>> the understanding accumulates.
>>>>
>>>> Multimedia message adaptation hasn't been yet discussed much.
>>>> I think it is in general a desirable feature, especially for
>>>> relatively small and dumb terminals, which are not easily
>>>> upgradable and may not understand all media formats.
>>>>
>>>> So I propose the WG chairs think where these items would be
>>>> appropriate, and if there is enough interest for them, let's
>>>> put them on the charters.
>>>>
>>>> Markus
>>>>
>>>>> -----Original Message-----
>>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
>>>>> Sent: 08 November, 2002 5:11
>>>>> To: Drage, Keith (Keith)
>>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message
>>>>> adaptationInternet-Drafts
>>>>>
>>>>>
>>>>> Well, I'd like to hear opinions from the participants here . . .
>>>>>
>>>>> Clearly they aren't explicitly on the charter for either
>>>>> group. Do we as
>>>>> yet have a consensus that we need to work on these
>>>> problems? If so, we
>>>>> can consider WHERE to work on them. I suspect SIPPING is
>>> closer to a
>>>>> matching scope than is SIMPLE, but the relevant ADs may have
>>>>> suggestions
>>>>> to make there as well.
>>>>>
>>>>> --
>>>>> Dean
>>>>>
>>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
>>>>>> I am getting a bit confused as to which group should be
>>>>> discussing these filtering issues.
>>>>>>
>>>>>> Could we have a statement from the WG chairs of SIPPING or
>>>>> SIMPLE as to whether this, and the moran drafts, are part of
>>>>> the scope of SIPPING or SIMPLE.
>>>>>>
>>>>>> And before you say these are both author drafts, I think we
>>>>> do need to charter one of the WGs to do some work in this
>>>>> area - I am just not sure of the exact scope yet.
>>>>>>
>>>>>> Keith
>>>>>>
>>>>>> Keith Drage
>>>>>> Lucent Technologies
>>>>>> Tel: +44 1793 776249
>>>>>> Email: drage@lucent.com
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
>>>>>>> Sent: 06 November 2002 18:24
>>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>>>>>> Subject: [Simple] Multimedia message adaptation
>>> Internet-Drafts
>>>>>>>
>>>>>>>
>>>>>>> 	While these drafts concern event filtering,
>>>> too, the subject was
>>>>>>> 	a bit misleading because I lazily just followed
>>>> up Tim's e-mail.
>>>>>>>
>>>>>>> 					Pekka
>>>>>>>
>>>>>>>
>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
>>>>>>> ptation-framework-00.txt
>>>>>>>
>>>>>>>
>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
>>>>>>> ptation-requirements-00.txt
>>>>>>>
>>>>>>> Pekka Pessi  writes:
>>>>>>>> We have submitted two drafts regarding multimedia message
>>>>>>>> adaptation. A multimedia message is typically a message
>>>>>>>> containing images, audio or video clips and their
>>> presentation
>>>>>>>> information, e.g., smil. Also, even XML-formatted text may
>>>>>>>> require adaptation in some cases.
>>>>>>>
>>>>>>>> Our goal is to have a framework using SIP, HTTP
>> and MIME that
>>>>>>>> allows a person sending multimedia message to adapt
>>> the message
>>>>>>>> contents suitable to all the recipients. In some cases the
>>>>>>>> adaptation can be done by the sending terminal, but
>>> we also see
>>>>>>>> that an adaptation service would be very useful in
>>> many cases.
>>>>>>>> Such an adaptation mechanism is used by MMS service
>>> provided by
>>>>>>>> cellular networks nowadays.
>>>>>>>
>>>>>>>> The message adaptation work concerns both SIPPING
>> and SIMPLE,
>>>>>>>> the requirements I-D lists use cases and requirements for
>>>>>>>> multimedia messaging and message adaptation
>> solutions and the
>>>>>>>> framework I-D tries to explore possible solutions.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> simple mailing list
>>>>>>> simple@mailman.dynamicsoft.com
>>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Sipping mailing list
>>>> https://www1.ietf.org/mailman/listinfo/sipping
>>>>>> This list is for NEW development of the application of SIP
>>>>>> Use sip-implementors@cs.columbia.edu for questions on
>>> current sip
>>>>>> Use sip@ietf.org for new developments of core SIP
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> simple mailing list
>>>>> simple@mailman.dynamicsoft.com
>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>>>
>>>> _______________________________________________
>>>> simple mailing list
>>>> simple@mailman.dynamicsoft.com
>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>>
>>> _______________________________________________
>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>> Use sip@ietf.org for new developments of core SIP
>>> _______________________________________________
>>> simple mailing list
>>> simple@mailman.dynamicsoft.com
>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>> _______________________________________________
>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>> Use sip@ietf.org for new developments of core SIP
>>>
>> _______________________________________________
>> simple mailing list
>> simple@mailman.dynamicsoft.com
>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP


From rohan@cisco.com  Wed Nov 13 21:03:36 2002
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11813
	for ; Wed, 13 Nov 2002 21:03:35 -0500 (EST)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gAE23Y5V029878
	for ; Wed, 13 Nov 2002 18:03:34 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA)
	with ESMTP id ABH19663;
	Wed, 13 Nov 2002 18:01:09 -0800 (PST)
Date: Wed, 13 Nov 2002 18:03:35 -0800
Mime-Version: 1.0 (Apple Message framework v546)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: pls stop cross posting (was Fwd: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
From: Rohan Mahy 
To: simple@mailman.dynamicsoft.com
Content-Transfer-Encoding: 7bit
Message-Id: <4890CF3A-F775-11D6-B86C-0003938AF740@cisco.com>
X-Mailer: Apple Mail (2.546)
Content-Length: 14564
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: 


Begin forwarded message:

> hello,
>
> please cease an desist cross posting when you reply.  sipping seems 
> like the default wg, so please send your comments only to 
> sipping@ietf.org.
>
> thanks,
> -rohan
>
> On Wednesday, November 13, 2002, at 07:35 AM, 
> Jose.Costa-Requena@nokia.com wrote:
>
>> Hi,
>>
>> According to LEMONADE requirements, it is considering mainly 
>> messaging systems and I agree that this proposal could fit into that 
>> context at some extent. Nevertheless, the actual proposal deals with 
>> content adaptation based on UA capabilities registered with SIP. 
>> Thus, I consider that it is within SIPPING scope, as well.
>> Comments?
>> BR
>> Jose
>>
>> -----Original Message-----
>> From: Srinivas Bindignavile (NRC/Boston)
>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>> adaptationInternet-Drafts
>>
>>
>> Hi,
>>
>> As Eric has indicated, the OPES WG is considering transcoding issues! 
>> However, presently, rather than being protocol-agnostic, it is being 
>> designed for HTTP and RTP only. SIP is not being considered here.
>>
>> -Srini
>>
>>> -----Original Message-----
>>> From: ext Eric Burger [mailto:eburger@snowshore.com]
>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>>> adaptationInternet-Drafts
>>>
>>>
>>>
>>> There are already TWO work groups that are considering
>>> EXACTLY these transcoding requirements.
>>>
>>> They are OPES and LEMONADE.
>>>
>>> I would offer that discussion of these capabilities happen in
>>> those groups.  If SIP is the appropriate mechanism, then
>>> those groups will submit the appropriate drafts to SIPPING,
>>> outlining the requirements.
>>>
>>>> -----Original Message----- From: Jose.Costa-Requena@nokia.com
>>> [snip]
>>>> Nevertheless, "content adaptation" I-D has a wider scope
>>>> since it is considering any content-type and it is taking
>>>> into account the terminal/user preferences. So I would say
>>>> that  it fits into SIPPING WG while the filtering I-D is
>>>> mainly dealing with presence and I think it should be handled
>>>> at SIMPLE WG.
>>>> BR
>>>> Jose
>>>>
>>>> -----Original Message----- From: Coulombe Stephane (NRC/Dallas)
>>>>> At a high level, these drafts also argue that capability
>>>>> negotiation should be administered by intermediaries rather
>>>> than through an
>>>>> end-to-end process; this approach may attract some similar
>>>> controversy.
>>>>
>>>> Proposed capability negotiation can be used both ways (end-to-end or
>>>> administered by intermediaries).
>>>> 1) end-to-end: Someone who wants to send an Instant Message
>>>> to another user
>>>> 	can send an OPTION query to learn about its terminal
>>>> capabilities and
>>>> 	then create a message within its capabilities.
>>>> 	
>>>> 	I guess this is not controversial. However how
>>>> realistic and usable is it in practice?
>>>> 	When composing a message, would a user really want to
>>>> take into consideration
>>>> 	the image formats to use, message size limitation, etc?
>>>>
>>>> 	For instance, you want to send a PNG image to a friend
>>>> and his terminal only supports
>>>> 	GIF format. What are you supposed to do? Find an image
>>>> conversion tool to convert to GIF?
>>>> 	This is annoying if you are using a PC, imagine with a
>>>> mobile phone or handheld?
>>>> 	
>>>> 	For usability reasons, the user wants to send a message
>>>> without caring "too much" about
>>>> 	what the other end is supporting.
>>>>
>>>> 2)administered by intermediaries: this is discussed in detail
>>>> in one of the drafts.
>>>>
>>>> 	Performing adaptation in the network is controversial
>>>> but this is the only way to support
>>>> 	interoperability and good user experience.
>>>>
>>>>> the applicability and impact of this mechanism is larger
>>>> than the problem of
>>>>> instant messaging and presence. While clearly, from the
>>>> framework, instant
>>>>> messaging and presence cases are driving this work, it is
>>>> applicable to the
>>>>> general use of SIP events (messaging, I think, is something
>>>> of a corner case).
>>>>
>>>> Yes, applicability and impact is larger than IM and presence.
>>>> It applies to many other
>>>> applications including the case of audio/video conferencing
>>>> (for instance when there is
>>>> no common audio or video codec between two ends).
>>>>
>>>> The drafts use the "corner case" of SIP IM for a few reasons:
>>>> 1) In SIP IM, there is no concept of capability negotiation
>>>> (unlike the case of sessions using SDP).
>>>> 	A user sends a message without knowing anything about
>>>> the recipient's terminal capabilities.
>>>> 2) In SIP IM, it easier to argue that there will be
>>>> interoperability problems because of the variety of content
>>>> types that could be sent (in audio/video session codecs are
>>>> typically more agreed on). Right now text is mostly used but
>>>> richer content will soon be used as is the case in Multimedia
>>>> Messaging Service (MMS). By the way, message adaptation is a
>>>> serious issue in MMS because of fast product capability
>>>> evolution. It's hard to keep interoperability while not
>>>> restricting new phones to send just "low-end" content.
>>>> 3) It is easier to explain the problem and propose a solution
>>>> with a smaller well-defined problem.
>>>>
>>>> Once we agree that SIP message adaptation is required, the
>>>> requirements and solutions should be established from global
>>>> perspective; not just SIP IM. For that reason, SIPPING may be
>>>> the most appropriate place to initiate this activity.
>>>>
>>>> Stephane
>>>>
>>>> -----Original Message-----
>>>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
>>>> Sent: Friday, November 08, 2002 6:58 AM
>>>> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
>>>> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>>>> adaptationInternet-Drafts
>>>>
>>>>
>>>>
>>>> It seems to me that these filtering drafts concern the
>>>> modification of MIME
>>>> bodies in SIP messages by intermediaries. This is not exactly an
>>>> uncontroversial topic in SIP circles, and therefore I don't
>>>> think it is a
>>>> foregone conclusion that this is work that some SIP-related
>>> WG should
>>>> charter. At a high level, these drafts also argue that capability
>>>> negotiation should be administered by intermediaries rather
>>>> than through an
>>>> end-to-end process; this approach may attract some similar
>>>> controversy.
>>>>
>>>> Provided that this is work the community would like to pursue, the
>>>> applicability and impact of this mechanism is larger than the
>>>> problem of
>>>> instant messaging and presence. While clearly, from the
>>>> framework, instant
>>>> messaging and presence cases are driving this work, it is
>>>> applicable to the
>>>> general use of SIP events (messaging, I think, is something
>>>> of a corner
>>>> case). While SIMPLE could certainly spend some time refining
>>>> the framework
>>>> and requirements related to IM & presence, I imagine that at
>>>> a mechanism
>>>> stage this work would need to take place in SIPPING.
>>>>
>>>> Jon Peterson
>>>> NeuStar, Inc.
>>>>
>>>>> -----Original Message-----
>>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
>>>>> Sent: Friday, November 08, 2002 3:47 AM
>>>>> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
>>>>> Gonzalo.Camarillo@lmf.ericsson.se
>>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
>>>>> adaptationInternet-Drafts
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Actually this thread is about two separate things:
>>>>> - Event filtering
>>>>> - Multimedia message adaptation
>>>>>
>>>>> Neither of them appears currently on any sippish WG charter
>>>>> currently.
>>>>>
>>>>> Event filtering has been discussed several times and it is
>>>>> even mentioned in (but out of scope of) SIP Events RFC. My
>>>>> impression has been that people think that it is needed, but
>>>>> there has been debate about scope and feasibility. I hope the
>>>>> requirements draft will help in that discussion. My own
>>>>> opinion is that what is concretely needed in short term is
>>>>> some simple filtering definitions for Presence event package.
>>>>> More wide-scoped and complex things could be worked upon as
>>>>> the understanding accumulates.
>>>>>
>>>>> Multimedia message adaptation hasn't been yet discussed much.
>>>>> I think it is in general a desirable feature, especially for
>>>>> relatively small and dumb terminals, which are not easily
>>>>> upgradable and may not understand all media formats.
>>>>>
>>>>> So I propose the WG chairs think where these items would be
>>>>> appropriate, and if there is enough interest for them, let's
>>>>> put them on the charters.
>>>>>
>>>>> Markus
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
>>>>>> Sent: 08 November, 2002 5:11
>>>>>> To: Drage, Keith (Keith)
>>>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message
>>>>>> adaptationInternet-Drafts
>>>>>>
>>>>>>
>>>>>> Well, I'd like to hear opinions from the participants here . . .
>>>>>>
>>>>>> Clearly they aren't explicitly on the charter for either
>>>>>> group. Do we as
>>>>>> yet have a consensus that we need to work on these
>>>>> problems? If so, we
>>>>>> can consider WHERE to work on them. I suspect SIPPING is
>>>> closer to a
>>>>>> matching scope than is SIMPLE, but the relevant ADs may have
>>>>>> suggestions
>>>>>> to make there as well.
>>>>>>
>>>>>> --
>>>>>> Dean
>>>>>>
>>>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
>>>>>>> I am getting a bit confused as to which group should be
>>>>>> discussing these filtering issues.
>>>>>>>
>>>>>>> Could we have a statement from the WG chairs of SIPPING or
>>>>>> SIMPLE as to whether this, and the moran drafts, are part of
>>>>>> the scope of SIPPING or SIMPLE.
>>>>>>>
>>>>>>> And before you say these are both author drafts, I think we
>>>>>> do need to charter one of the WGs to do some work in this
>>>>>> area - I am just not sure of the exact scope yet.
>>>>>>>
>>>>>>> Keith
>>>>>>>
>>>>>>> Keith Drage
>>>>>>> Lucent Technologies
>>>>>>> Tel: +44 1793 776249
>>>>>>> Email: drage@lucent.com
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
>>>>>>>> Sent: 06 November 2002 18:24
>>>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com
>>>>>>>> Subject: [Simple] Multimedia message adaptation
>>>> Internet-Drafts
>>>>>>>>
>>>>>>>>
>>>>>>>> 	While these drafts concern event filtering,
>>>>> too, the subject was
>>>>>>>> 	a bit misleading because I lazily just followed
>>>>> up Tim's e-mail.
>>>>>>>>
>>>>>>>> 					Pekka
>>>>>>>>
>>>>>>>>
>>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
>>>>>>>> ptation-framework-00.txt
>>>>>>>>
>>>>>>>>
>>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
>>>>>>>> ptation-requirements-00.txt
>>>>>>>>
>>>>>>>> Pekka Pessi  writes:
>>>>>>>>> We have submitted two drafts regarding multimedia message
>>>>>>>>> adaptation. A multimedia message is typically a message
>>>>>>>>> containing images, audio or video clips and their
>>>> presentation
>>>>>>>>> information, e.g., smil. Also, even XML-formatted text may
>>>>>>>>> require adaptation in some cases.
>>>>>>>>
>>>>>>>>> Our goal is to have a framework using SIP, HTTP
>>> and MIME that
>>>>>>>>> allows a person sending multimedia message to adapt
>>>> the message
>>>>>>>>> contents suitable to all the recipients. In some cases the
>>>>>>>>> adaptation can be done by the sending terminal, but
>>>> we also see
>>>>>>>>> that an adaptation service would be very useful in
>>>> many cases.
>>>>>>>>> Such an adaptation mechanism is used by MMS service
>>>> provided by
>>>>>>>>> cellular networks nowadays.
>>>>>>>>
>>>>>>>>> The message adaptation work concerns both SIPPING
>>> and SIMPLE,
>>>>>>>>> the requirements I-D lists use cases and requirements for
>>>>>>>>> multimedia messaging and message adaptation
>>> solutions and the
>>>>>>>>> framework I-D tries to explore possible solutions.
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> simple mailing list
>>>>>>>> simple@mailman.dynamicsoft.com
>>>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Sipping mailing list
>>>>> https://www1.ietf.org/mailman/listinfo/sipping
>>>>>>> This list is for NEW development of the application of SIP
>>>>>>> Use sip-implementors@cs.columbia.edu for questions on
>>>> current sip
>>>>>>> Use sip@ietf.org for new developments of core SIP
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> simple mailing list
>>>>>> simple@mailman.dynamicsoft.com
>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>>>>
>>>>> _______________________________________________
>>>>> simple mailing list
>>>>> simple@mailman.dynamicsoft.com
>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>>>
>>>> _______________________________________________
>>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>> This list is for NEW development of the application of SIP
>>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>>> Use sip@ietf.org for new developments of core SIP
>>>> _______________________________________________
>>>> simple mailing list
>>>> simple@mailman.dynamicsoft.com
>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>> _______________________________________________
>>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>>>> This list is for NEW development of the application of SIP
>>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>>> Use sip@ietf.org for new developments of core SIP
>>>>
>>> _______________________________________________
>>> simple mailing list
>>> simple@mailman.dynamicsoft.com
>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sip@ietf.org for new developments of core SIP


From abbieb@nortelnetworks.com  Wed Nov 13 11:16:16 2002
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10120
	for ; Wed, 13 Nov 2002 11:16:16 -0500 (EST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gADGFF019940;
	Wed, 13 Nov 2002 11:15:15 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 13 Nov 2002 11:15:16 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD7540420D561@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" 
To: bindignavile.srinivas@nokia.com, eburger@snowshore.com,
        Jose.Costa-Requena@nokia.com, Stephane.Coulombe@nokia.com,
        jon.peterson@neustar.biz, Markus.Isomaki@nokia.com,
        dean.willis@softarmor.com, drage@lucent.com, rohan@cisco.com,
        Gonzalo.Camarillo@lmf.ericsson.se
Cc: sipping@ietf.org, simple@mailman.dynamicsoft.com, Pekka.Pessi@nokia.com,
        ietf-openproxy@imc.org, um@snowshore.com
Subject: RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-
	Drafts
Date: Wed, 13 Nov 2002 11:15:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28B2F.D67BD55E"
Content-Length: 45975
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: 

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_01C28B2F.D67BD55E
Content-Type: text/plain

Hi,

The current work focuses on HTTP as the default protocol for OPES services. 

thanks
abbie


> -----Original Message-----
> From: bindignavile.srinivas@nokia.com 
> [mailto:bindignavile.srinivas@nokia.com] 
> Sent: Wednesday, November 13, 2002 10:24 AM
> To: eburger@snowshore.com; Jose.Costa-Requena@nokia.com; 
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; 
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com; 
> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; 
> Pekka.Pessi@nokia.com; ietf-openproxy@imc.org; um@snowshore.com
> Subject: RE: [Sipping] RE: [Simple] Multimedia message 
> adaptationInternet-Drafts
> 
> 
> 
> Hi,
> 
> As Eric has indicated, the OPES WG is considering transcoding 
> issues! However, presently, rather than being 
> protocol-agnostic, it is being designed for HTTP and RTP 
> only. SIP is not being considered here.
> 
> -Srini
> 
> > -----Original Message-----
> > From: ext Eric Burger [mailto:eburger@snowshore.com]
> > Sent: Tuesday, November 12, 2002 9:49 AM
> > To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane 
> (NRC/Dallas); 
> > jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki); 
> > dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; 
> > Gonzalo.Camarillo@lmf.ericsson.se
> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; Pessi Pekka 
> > (NRC/Helsinki); IETF OPES (E-mail); IETF LEMONADE (E-mail)
> > Subject: RE: [Sipping] RE: [Simple] Multimedia message 
> > adaptationInternet-Drafts
> > 
> > 
> > 
> > There are already TWO work groups that are considering
> > EXACTLY these transcoding requirements.
> > 
> > They are OPES and LEMONADE.
> > 
> > I would offer that discussion of these capabilities happen in
> > those groups.  If SIP is the appropriate mechanism, then 
> > those groups will submit the appropriate drafts to SIPPING, 
> > outlining the requirements.
> > 
> > > -----Original Message----- From: Jose.Costa-Requena@nokia.com
> > [snip]
> > > Nevertheless, "content adaptation" I-D has a wider scope
> > > since it is considering any content-type and it is taking 
> > > into account the terminal/user preferences. So I would say 
> > > that  it fits into SIPPING WG while the filtering I-D is 
> > > mainly dealing with presence and I think it should be handled 
> > > at SIMPLE WG.
> > > BR
> > > Jose
> > > 
> > > -----Original Message----- From: Coulombe Stephane (NRC/Dallas)
> > > > At a high level, these drafts also argue that capability 
> > > > negotiation should be administered by intermediaries rather
> > > than through an
> > > > end-to-end process; this approach may attract some similar
> > > controversy.
> > > 
> > > Proposed capability negotiation can be used both ways 
> (end-to-end or 
> > > administered by intermediaries).
> > > 1) end-to-end: Someone who wants to send an Instant Message
> > > to another user
> > > 	can send an OPTION query to learn about its terminal 
> > > capabilities and
> > > 	then create a message within its capabilities.
> > > 	
> > > 	I guess this is not controversial. However how
> > > realistic and usable is it in practice?
> > > 	When composing a message, would a user really want to 
> > > take into consideration 
> > > 	the image formats to use, message size limitation, etc? 
> > > 
> > > 	For instance, you want to send a PNG image to a friend
> > > and his terminal only supports 
> > > 	GIF format. What are you supposed to do? Find an image 
> > > conversion tool to convert to GIF?
> > > 	This is annoying if you are using a PC, imagine with a 
> > > mobile phone or handheld?
> > > 	
> > > 	For usability reasons, the user wants to send a message
> > > without caring "too much" about 
> > > 	what the other end is supporting.
> > >  
> > > 2)administered by intermediaries: this is discussed in detail
> > > in one of the drafts. 
> > > 
> > > 	Performing adaptation in the network is controversial
> > > but this is the only way to support
> > > 	interoperability and good user experience. 
> > > 
> > > > the applicability and impact of this mechanism is larger
> > > than the problem of
> > > > instant messaging and presence. While clearly, from the
> > > framework, instant
> > > > messaging and presence cases are driving this work, it is
> > > applicable to the
> > > > general use of SIP events (messaging, I think, is something
> > > of a corner case).
> > > 
> > > Yes, applicability and impact is larger than IM and presence.
> > > It applies to many other
> > > applications including the case of audio/video conferencing 
> > > (for instance when there is 
> > > no common audio or video codec between two ends).  
> > > 
> > > The drafts use the "corner case" of SIP IM for a few reasons:
> > > 1) In SIP IM, there is no concept of capability negotiation
> > > (unlike the case of sessions using SDP).
> > > 	A user sends a message without knowing anything about 
> > > the recipient's terminal capabilities.
> > > 2) In SIP IM, it easier to argue that there will be 
> > > interoperability problems because of the variety of content 
> > > types that could be sent (in audio/video session codecs are 
> > > typically more agreed on). Right now text is mostly used but 
> > > richer content will soon be used as is the case in Multimedia 
> > > Messaging Service (MMS). By the way, message adaptation is a 
> > > serious issue in MMS because of fast product capability 
> > > evolution. It's hard to keep interoperability while not 
> > > restricting new phones to send just "low-end" content.
> > > 3) It is easier to explain the problem and propose a solution 
> > > with a smaller well-defined problem.
> > > 
> > > Once we agree that SIP message adaptation is required, the
> > > requirements and solutions should be established from global 
> > > perspective; not just SIP IM. For that reason, SIPPING may be 
> > > the most appropriate place to initiate this activity.
> > > 
> > > Stephane
> > > 
> > > -----Original Message-----
> > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > > Sent: Friday, November 08, 2002 6:58 AM
> > > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; 
> > > drage@lucent.com; rohan@cisco.com; 
> Gonzalo.Camarillo@lmf.ericsson.se
> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > Subject: RE: [Sipping] RE: [Simple] Multimedia message 
> > > adaptationInternet-Drafts
> > > 
> > > 
> > > 
> > > It seems to me that these filtering drafts concern the
> > > modification of MIME
> > > bodies in SIP messages by intermediaries. This is not exactly an
> > > uncontroversial topic in SIP circles, and therefore I don't 
> > > think it is a
> > > foregone conclusion that this is work that some SIP-related 
> > WG should
> > > charter. At a high level, these drafts also argue that capability 
> > > negotiation should be administered by intermediaries rather than 
> > > through an end-to-end process; this approach may attract some 
> > > similar controversy.
> > > 
> > > Provided that this is work the community would like to 
> pursue, the 
> > > applicability and impact of this mechanism is larger than the 
> > > problem of instant messaging and presence. While clearly, from the
> > > framework, instant
> > > messaging and presence cases are driving this work, it is 
> > > applicable to the
> > > general use of SIP events (messaging, I think, is something 
> > > of a corner
> > > case). While SIMPLE could certainly spend some time refining 
> > > the framework
> > > and requirements related to IM & presence, I imagine that at 
> > > a mechanism
> > > stage this work would need to take place in SIPPING.
> > > 
> > > Jon Peterson
> > > NeuStar, Inc.
> > > 
> > > > -----Original Message-----
> > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
> > > > Sent: Friday, November 08, 2002 3:47 AM
> > > > To: dean.willis@softarmor.com; drage@lucent.com; 
> rohan@cisco.com; 
> > > > Gonzalo.Camarillo@lmf.ericsson.se
> > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > Subject: RE: [Sipping] RE: [Simple] Multimedia message 
> > > > adaptationInternet-Drafts
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > Actually this thread is about two separate things:
> > > > - Event filtering
> > > > - Multimedia message adaptation
> > > > 
> > > > Neither of them appears currently on any sippish WG charter
> > > > currently. 
> > > > 
> > > > Event filtering has been discussed several times and it is
> > > > even mentioned in (but out of scope of) SIP Events RFC. My 
> > > > impression has been that people think that it is needed, but 
> > > > there has been debate about scope and feasibility. I hope the 
> > > > requirements draft will help in that discussion. My own 
> > > > opinion is that what is concretely needed in short term is 
> > > > some simple filtering definitions for Presence event package. 
> > > > More wide-scoped and complex things could be worked upon as 
> > > > the understanding accumulates.
> > > > 
> > > > Multimedia message adaptation hasn't been yet discussed much.
> > > > I think it is in general a desirable feature, especially for 
> > > > relatively small and dumb terminals, which are not easily 
> > > > upgradable and may not understand all media formats.
> > > > 
> > > > So I propose the WG chairs think where these items would be
> > > > appropriate, and if there is enough interest for them, let's 
> > > > put them on the charters.
> > > > 
> > > > Markus
> > > > 
> > > > > -----Original Message-----
> > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > > > Sent: 08 November, 2002 5:11
> > > > > To: Drage, Keith (Keith)
> > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message 
> > > > > adaptationInternet-Drafts
> > > > > 
> > > > > 
> > > > > Well, I'd like to hear opinions from the participants 
> here . . .
> > > > > 
> > > > > Clearly they aren't explicitly on the charter for either
> > > > > group. Do we as
> > > > > yet have a consensus that we need to work on these 
> > > > problems? If so, we
> > > > > can consider WHERE to work on them. I suspect SIPPING is
> > > closer to a
> > > > > matching scope than is SIMPLE, but the relevant ADs may have
> > > > > suggestions
> > > > > to make there as well.
> > > > > 
> > > > > --
> > > > > Dean
> > > > > 
> > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> > > > > > I am getting a bit confused as to which group should be
> > > > > discussing these filtering issues.
> > > > > > 
> > > > > > Could we have a statement from the WG chairs of SIPPING or
> > > > > SIMPLE as to whether this, and the moran drafts, are part of
> > > > > the scope of SIPPING or SIMPLE.
> > > > > > 
> > > > > > And before you say these are both author drafts, I think we
> > > > > do need to charter one of the WGs to do some work in this
> > > > > area - I am just not sure of the exact scope yet.
> > > > > > 
> > > > > > Keith
> > > > > > 
> > > > > > Keith Drage
> > > > > > Lucent Technologies
> > > > > > Tel: +44 1793 776249
> > > > > > Email: drage@lucent.com
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> > > > > > > Sent: 06 November 2002 18:24
> > > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> > > > > > > Subject: [Simple] Multimedia message adaptation
> > > Internet-Drafts
> > > > > > > 
> > > > > > > 
> > > > > > > 	While these drafts concern event filtering,
> > > > too, the subject was
> > > > > > > 	a bit misleading because I lazily just followed
> > > > up Tim's e-mail.
> > > > > > > 
> > > > > > > 					Pekka
> > > > > > > 
> > > > > > > 
> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > > ptation-framework-00.txt
> > > > > > > 
> > > > > > > 
> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> > > > > > > ptation-requirements-00.txt
> > > > > > > 
> > > > > > > Pekka Pessi  writes:
> > > > > > > >We have submitted two drafts regarding 
> multimedia message 
> > > > > > > >adaptation. A multimedia message is typically a message 
> > > > > > > >containing images, audio or video clips and their
> > > presentation
> > > > > > > >information, e.g., smil. Also, even 
> XML-formatted text may 
> > > > > > > >require adaptation in some cases.
> > > > > > > 
> > > > > > > >Our goal is to have a framework using SIP, HTTP
> > and MIME that
> > > > > > > >allows a person sending multimedia message to adapt
> > > the message
> > > > > > > >contents suitable to all the recipients. In some 
> cases the 
> > > > > > > >adaptation can be done by the sending terminal, but
> > > we also see
> > > > > > > >that an adaptation service would be very useful in
> > > many cases.
> > > > > > > >Such an adaptation mechanism is used by MMS service
> > > provided by
> > > > > > > >cellular networks nowadays.
> > > > > > > 
> > > > > > > >The message adaptation work concerns both SIPPING
> > and SIMPLE,
> > > > > > > >the requirements I-D lists use cases and 
> requirements for 
> > > > > > > >multimedia messaging and message adaptation
> > solutions and the
> > > > > > > >framework I-D tries to explore possible solutions.
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > simple mailing list
> > > > > > > simple@mailman.dynamicsoft.com 
> > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > > > 
> > > > > > _______________________________________________
> > > > > > Sipping mailing list
> > > > https://www1.ietf.org/mailman/listinfo/sipping
> > > > > > This list is for NEW development of the application 
> of SIP Use 
> > > > > > sip-implementors@cs.columbia.edu for questions on
> > > current sip
> > > > > > Use sip@ietf.org for new developments of core SIP
> > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > simple mailing list
> > > > > simple@mailman.dynamicsoft.com 
> > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > > 
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com 
> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list 
> is for NEW development of the application of SIP Use 
> > > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > > sip@ietf.org for new developments of core SIP 
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com 
> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > _______________________________________________
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list 
> is for NEW development of the application of SIP Use 
> > > sip-implementors@cs.columbia.edu for questions on current sip Use 
> > > sip@ietf.org for new developments of core SIP
> > > 
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com 
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> 

------_=_NextPart_001_01C28B2F.D67BD55E
Content-Type: text/html






RE: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts




Hi,




The current work focuses on HTTP as the default protocol for OPES services. 




thanks

abbie






> -----Original Message-----

> From: bindignavile.srinivas@nokia.com 

> [mailto:bindignavile.srinivas@nokia.com] 

> Sent: Wednesday, November 13, 2002 10:24 AM

> To: eburger@snowshore.com; Jose.Costa-Requena@nokia.com; 

> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; 

> Markus.Isomaki@nokia.com; dean.willis@softarmor.com; 

> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se

> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; 

> Pekka.Pessi@nokia.com; ietf-openproxy@imc.org; um@snowshore.com

> Subject: RE: [Sipping] RE: [Simple] Multimedia message 

> adaptationInternet-Drafts

> 

> 

> 

> Hi,

> 

> As Eric has indicated, the OPES WG is considering transcoding 

> issues! However, presently, rather than being 

> protocol-agnostic, it is being designed for HTTP and RTP 

> only. SIP is not being considered here.

> 

> -Srini

> 

> > -----Original Message-----

> > From: ext Eric Burger [mailto:eburger@snowshore.com]

> > Sent: Tuesday, November 12, 2002 9:49 AM

> > To: Costa-Requena Jose (NMP/Helsinki); Coulombe Stephane 

> (NRC/Dallas); 

> > jon.peterson@neustar.biz; Isomaki Markus (NRC/Helsinki); 

> > dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com; 

> > Gonzalo.Camarillo@lmf.ericsson.se

> > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com; Pessi Pekka 

> > (NRC/Helsinki); IETF OPES (E-mail); IETF LEMONADE (E-mail)

> > Subject: RE: [Sipping] RE: [Simple] Multimedia message 

> > adaptationInternet-Drafts

> > 

> > 

> > 

> > There are already TWO work groups that are considering

> > EXACTLY these transcoding requirements.

> > 

> > They are OPES and LEMONADE.

> > 

> > I would offer that discussion of these capabilities happen in

> > those groups.  If SIP is the appropriate mechanism, then 

> > those groups will submit the appropriate drafts to SIPPING, 

> > outlining the requirements.

> > 

> > > -----Original Message----- From: Jose.Costa-Requena@nokia.com

> > [snip]

> > > Nevertheless, "content adaptation" I-D has a wider scope

> > > since it is considering any content-type and it is taking 

> > > into account the terminal/user preferences. So I would say 

> > > that  it fits into SIPPING WG while the filtering I-D is 

> > > mainly dealing with presence and I think it should be handled 

> > > at SIMPLE WG.

> > > BR

> > > Jose

> > > 

> > > -----Original Message----- From: Coulombe Stephane (NRC/Dallas)

> > > > At a high level, these drafts also argue that capability 

> > > > negotiation should be administered by intermediaries rather

> > > than through an

> > > > end-to-end process; this approach may attract some similar

> > > controversy.

> > > 

> > > Proposed capability negotiation can be used both ways 

> (end-to-end or 

> > > administered by intermediaries).

> > > 1) end-to-end: Someone who wants to send an Instant Message

> > > to another user

> > >   can send an OPTION query to learn about its terminal 

> > > capabilities and

> > >   then create a message within its capabilities.

> > >   

> > >   I guess this is not controversial. However how

> > > realistic and usable is it in practice?

> > >   When composing a message, would a user really want to 

> > > take into consideration 

> > >   the image formats to use, message size limitation, etc? 

> > > 

> > >   For instance, you want to send a PNG image to a friend

> > > and his terminal only supports 

> > >   GIF format. What are you supposed to do? Find an image 

> > > conversion tool to convert to GIF?

> > >   This is annoying if you are using a PC, imagine with a 

> > > mobile phone or handheld?

> > >   

> > >   For usability reasons, the user wants to send a message

> > > without caring "too much" about 

> > >   what the other end is supporting.

> > >  

> > > 2)administered by intermediaries: this is discussed in detail

> > > in one of the drafts. 

> > > 

> > >   Performing adaptation in the network is controversial

> > > but this is the only way to support

> > >   interoperability and good user experience. 

> > > 

> > > > the applicability and impact of this mechanism is larger

> > > than the problem of

> > > > instant messaging and presence. While clearly, from the

> > > framework, instant

> > > > messaging and presence cases are driving this work, it is

> > > applicable to the

> > > > general use of SIP events (messaging, I think, is something

> > > of a corner case).

> > > 

> > > Yes, applicability and impact is larger than IM and presence.

> > > It applies to many other

> > > applications including the case of audio/video conferencing 

> > > (for instance when there is 

> > > no common audio or video codec between two ends).  

> > > 

> > > The drafts use the "corner case" of SIP IM for a few reasons:

> > > 1) In SIP IM, there is no concept of capability negotiation

> > > (unlike the case of sessions using SDP).

> > >   A user sends a message without knowing anything about 

> > > the recipient's terminal capabilities.

> > > 2) In SIP IM, it easier to argue that there will be 

> > > interoperability problems because of the variety of content 

> > > types that could be sent (in audio/video session codecs are 

> > > typically more agreed on). Right now text is mostly used but 

> > > richer content will soon be used as is the case in Multimedia 

> > > Messaging Service (MMS). By the way, message adaptation is a 

> > > serious issue in MMS because of fast product capability 

> > > evolution. It's hard to keep interoperability while not 

> > > restricting new phones to send just "low-end" content.

> > > 3) It is easier to explain the problem and propose a solution 

> > > with a smaller well-defined problem.

> > > 

> > > Once we agree that SIP message adaptation is required, the

> > > requirements and solutions should be established from global 

> > > perspective; not just SIP IM. For that reason, SIPPING may be 

> > > the most appropriate place to initiate this activity.

> > > 

> > > Stephane

> > > 

> > > -----Original Message-----

> > > From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]

> > > Sent: Friday, November 08, 2002 6:58 AM

> > > To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com; 

> > > drage@lucent.com; rohan@cisco.com; 

> Gonzalo.Camarillo@lmf.ericsson.se

> > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com

> > > Subject: RE: [Sipping] RE: [Simple] Multimedia message 

> > > adaptationInternet-Drafts

> > > 

> > > 

> > > 

> > > It seems to me that these filtering drafts concern the

> > > modification of MIME

> > > bodies in SIP messages by intermediaries. This is not exactly an

> > > uncontroversial topic in SIP circles, and therefore I don't 

> > > think it is a

> > > foregone conclusion that this is work that some SIP-related 

> > WG should

> > > charter. At a high level, these drafts also argue that capability 

> > > negotiation should be administered by intermediaries rather than 

> > > through an end-to-end process; this approach may attract some 

> > > similar controversy.

> > > 

> > > Provided that this is work the community would like to 

> pursue, the 

> > > applicability and impact of this mechanism is larger than the 

> > > problem of instant messaging and presence. While clearly, from the

> > > framework, instant

> > > messaging and presence cases are driving this work, it is 

> > > applicable to the

> > > general use of SIP events (messaging, I think, is something 

> > > of a corner

> > > case). While SIMPLE could certainly spend some time refining 

> > > the framework

> > > and requirements related to IM & presence, I imagine that at 

> > > a mechanism

> > > stage this work would need to take place in SIPPING.

> > > 

> > > Jon Peterson

> > > NeuStar, Inc.

> > > 

> > > > -----Original Message-----

> > > > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]

> > > > Sent: Friday, November 08, 2002 3:47 AM

> > > > To: dean.willis@softarmor.com; drage@lucent.com; 

> rohan@cisco.com; 

> > > > Gonzalo.Camarillo@lmf.ericsson.se

> > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com

> > > > Subject: RE: [Sipping] RE: [Simple] Multimedia message 

> > > > adaptationInternet-Drafts

> > > > 

> > > > 

> > > > Hi,

> > > > 

> > > > Actually this thread is about two separate things:

> > > > - Event filtering

> > > > - Multimedia message adaptation

> > > > 

> > > > Neither of them appears currently on any sippish WG charter

> > > > currently. 

> > > > 

> > > > Event filtering has been discussed several times and it is

> > > > even mentioned in (but out of scope of) SIP Events RFC. My 

> > > > impression has been that people think that it is needed, but 

> > > > there has been debate about scope and feasibility. I hope the 

> > > > requirements draft will help in that discussion. My own 

> > > > opinion is that what is concretely needed in short term is 

> > > > some simple filtering definitions for Presence event package. 

> > > > More wide-scoped and complex things could be worked upon as 

> > > > the understanding accumulates.

> > > > 

> > > > Multimedia message adaptation hasn't been yet discussed much.

> > > > I think it is in general a desirable feature, especially for 

> > > > relatively small and dumb terminals, which are not easily 

> > > > upgradable and may not understand all media formats.

> > > > 

> > > > So I propose the WG chairs think where these items would be

> > > > appropriate, and if there is enough interest for them, let's 

> > > > put them on the charters.

> > > > 

> > > > Markus

> > > > 

> > > > > -----Original Message-----

> > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]

> > > > > Sent: 08 November, 2002 5:11

> > > > > To: Drage, Keith (Keith)

> > > > > Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com

> > > > > Subject: Re: [Sipping] RE: [Simple] Multimedia message 

> > > > > adaptationInternet-Drafts

> > > > > 

> > > > > 

> > > > > Well, I'd like to hear opinions from the participants 

> here . . .

> > > > > 

> > > > > Clearly they aren't explicitly on the charter for either

> > > > > group. Do we as

> > > > > yet have a consensus that we need to work on these 

> > > > problems? If so, we

> > > > > can consider WHERE to work on them. I suspect SIPPING is

> > > closer to a

> > > > > matching scope than is SIMPLE, but the relevant ADs may have

> > > > > suggestions

> > > > > to make there as well.

> > > > > 

> > > > > --

> > > > > Dean

> > > > > 

> > > > > On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:

> > > > > > I am getting a bit confused as to which group should be

> > > > > discussing these filtering issues.

> > > > > > 

> > > > > > Could we have a statement from the WG chairs of SIPPING or

> > > > > SIMPLE as to whether this, and the moran drafts, are part of

> > > > > the scope of SIPPING or SIMPLE.

> > > > > > 

> > > > > > And before you say these are both author drafts, I think we

> > > > > do need to charter one of the WGs to do some work in this

> > > > > area - I am just not sure of the exact scope yet.

> > > > > > 

> > > > > > Keith

> > > > > > 

> > > > > > Keith Drage

> > > > > > Lucent Technologies

> > > > > > Tel: +44 1793 776249

> > > > > > Email: drage@lucent.com

> > > > > > 

> > > > > > > -----Original Message-----

> > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]

> > > > > > > Sent: 06 November 2002 18:24

> > > > > > > To: sipping@ietf.org; simple@mailman.dynamicsoft.com

> > > > > > > Subject: [Simple] Multimedia message adaptation

> > > Internet-Drafts

> > > > > > > 

> > > > > > > 

> > > > > > >   While these drafts concern event filtering,

> > > > too, the subject was

> > > > > > >   a bit misleading because I lazily just followed

> > > > up Tim's e-mail.

> > > > > > > 

> > > > > > >                                   Pekka

> > > > > > > 

> > > > > > > 

> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada

> > > > > > > ptation-framework-00.txt

> > > > > > > 

> > > > > > > 

> > http://www.ietf.org/internet-drafts/draft-coulombe-message-ada

> > > > > > > ptation-requirements-00.txt

> > > > > > > 

> > > > > > > Pekka Pessi <Pekka.Pessi@nokia.com> writes:

> > > > > > > >We have submitted two drafts regarding 

> multimedia message 

> > > > > > > >adaptation. A multimedia message is typically a message 

> > > > > > > >containing images, audio or video clips and their

> > > presentation

> > > > > > > >information, e.g., smil. Also, even 

> XML-formatted text may 

> > > > > > > >require adaptation in some cases.

> > > > > > > 

> > > > > > > >Our goal is to have a framework using SIP, HTTP

> > and MIME that

> > > > > > > >allows a person sending multimedia message to adapt

> > > the message

> > > > > > > >contents suitable to all the recipients. In some 

> cases the 

> > > > > > > >adaptation can be done by the sending terminal, but

> > > we also see

> > > > > > > >that an adaptation service would be very useful in

> > > many cases.

> > > > > > > >Such an adaptation mechanism is used by MMS service

> > > provided by

> > > > > > > >cellular networks nowadays.

> > > > > > > 

> > > > > > > >The message adaptation work concerns both SIPPING

> > and SIMPLE,

> > > > > > > >the requirements I-D lists use cases and 

> requirements for 

> > > > > > > >multimedia messaging and message adaptation

> > solutions and the

> > > > > > > >framework I-D tries to explore possible solutions.

> > > > > > > 

> > > > > > > _______________________________________________

> > > > > > > simple mailing list

> > > > > > > simple@mailman.dynamicsoft.com 

> > > > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple

> > > > > > > 

> > > > > > _______________________________________________

> > > > > > Sipping mailing list

> > > > https://www1.ietf.org/mailman/listinfo/sipping

> > > > > > This list is for NEW development of the application 

> of SIP Use 

> > > > > > sip-implementors@cs.columbia.edu for questions on

> > > current sip

> > > > > > Use sip@ietf.org for new developments of core SIP

> > > > > > 

> > > > > 

> > > > > _______________________________________________

> > > > > simple mailing list

> > > > > simple@mailman.dynamicsoft.com 

> > > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple

> > > > > 

> > > > _______________________________________________

> > > > simple mailing list

> > > > simple@mailman.dynamicsoft.com 

> > > > http://mailman.dynamicsoft.com/mailman/listinfo/simple

> > > > 

> > > _______________________________________________

> > > Sipping mailing list  

> https://www1.ietf.org/mailman/listinfo/sipping

> > > This list 

> is for NEW development of the application of SIP Use 

> > > sip-implementors@cs.columbia.edu for questions on current sip Use 

> > > sip@ietf.org for new developments of core SIP 

> > > _______________________________________________

> > > simple mailing list

> > > simple@mailman.dynamicsoft.com 

> > > http://mailman.dynamicsoft.com/mailman/listinfo/simple

> > > _______________________________________________

> > > Sipping mailing list  

> https://www1.ietf.org/mailman/listinfo/sipping

> > > This list 

> is for NEW development of the application of SIP Use 

> > > sip-implementors@cs.columbia.edu for questions on current sip Use 

> > > sip@ietf.org for new developments of core SIP

> > > 

> > _______________________________________________

> > simple mailing list

> > simple@mailman.dynamicsoft.com 

> > http://mailman.dynamicsoft.com/mailman/listinfo/simple

> > 

> 





------_=_NextPart_001_01C28B2F.D67BD55E--

From eburger@snowshore.com  Thu Nov 14 09:17:40 2002
Received: from snowshore.com (keeper.snowshore.com [216.57.133.4])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14009
	for ; Thu, 14 Nov 2002 09:17:40 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Date: Thu, 14 Nov 2002 09:17:40 -0500
Message-ID: <4A3384433CE2AB46A63468CB207E209D097B6C@zoe.office.snowshore.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
Thread-Index: AcKL2DsO6cWYXZciS8qGVAN+WtLnQQADoget
From: "Eric Burger" 
To: 
Cc: , ,
        , ,
        , ,
        , ,
        , ,
        , "UM list" ,
        
Content-Length: 16952
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id JAA14009
Subject: [Simple] RE: [Sipping] Multimedia message adaptationInternet-Drafts
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: 

I understand the sentiment.  Neither opes nor lemonade are perfect fits for the current proposals.  However, I would offer that the proper home for media adaptation is either opes or lemonade.
 
My rationale is simple.  Sipping is a transport area work group.  The experts in the group are transport experts.  The AD's are transport AD's.  Media transformation is an application.  Opes and lemonade are application work groups.  The experts in the groups are application experts.  The AD's are application AD's.
 
I agree that there may be refinement or conventions that will be needed in SIP to support real-time media transformation.  The correct place for that to happen is sipping.  However, the right people with expertise in media transformation are in the opes and lemonade groups.
 
From a charter point of view, media transformation (IMHO) is way out of scope for sipping.  We've heard from Abbie that it is sort of out of scope for opes, as opes is focusing on HTTP.  On the other hand, the mechanism being proposed is rather close to the lemonade work.
 
I think this work fits into lemonade charter items 1 (retrieval protocols) and 5 (translation services). We can refine the language to explicitly contain the real-time adaptation work items, if that would make everyone happy.
 
--
- Eric
 
 
 
 
SIPPING is for SIP. OPES and LEMONADE are specifically for media transformation.  Said differently, we have transport experts in SIPPING and application experts in OPES and LEMONADE.

	-----Original Message----- 
	From: Rohan Mahy [mailto:rohan@cisco.com] 
	Sent: Wed 11/13/2002 9:00 PM 
	To: Jose.Costa-Requena@nokia.com 
	Cc: bindignavile.srinivas@nokia.com; Eric Burger; Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; Markus.Isomaki@nokia.com; dean.willis@softarmor.com; drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; sipping@ietf.org; Pekka.Pessi@nokia.com; simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM list 
	Subject: Re: [Sipping] RE: [Simple] Multimedia message adaptationInternet-Drafts
	
	

	hello,
	
	please cease an desist cross posting when you reply.  sipping seems
	like the default wg, so please send your comments only to
	sipping@ietf.org.
	
	thanks,
	-rohan
	
	On Wednesday, November 13, 2002, at 07:35 AM,
	Jose.Costa-Requena@nokia.com wrote:
	
	> Hi,
	>
	> According to LEMONADE requirements, it is considering mainly messaging
	> systems and I agree that this proposal could fit into that context at
	> some extent. Nevertheless, the actual proposal deals with content
	> adaptation based on UA capabilities registered with SIP. Thus, I
	> consider that it is within SIPPING scope, as well.
	> Comments?
	> BR
	> Jose
	>
	> -----Original Message-----
	> From: Srinivas Bindignavile (NRC/Boston)
	> Subject: RE: [Sipping] RE: [Simple] Multimedia message
	> adaptationInternet-Drafts
	>
	>
	> Hi,
	>
	> As Eric has indicated, the OPES WG is considering transcoding issues!
	> However, presently, rather than being protocol-agnostic, it is being
	> designed for HTTP and RTP only. SIP is not being considered here.
	>
	> -Srini
	>
	>> -----Original Message-----
	>> From: ext Eric Burger [mailto:eburger@snowshore.com]
	>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
	>> adaptationInternet-Drafts
	>>
	>>
	>>
	>> There are already TWO work groups that are considering
	>> EXACTLY these transcoding requirements.
	>>
	>> They are OPES and LEMONADE.
	>>
	>> I would offer that discussion of these capabilities happen in
	>> those groups.  If SIP is the appropriate mechanism, then
	>> those groups will submit the appropriate drafts to SIPPING,
	>> outlining the requirements.
	>>
	>>> -----Original Message----- From: Jose.Costa-Requena@nokia.com
	>> [snip]
	>>> Nevertheless, "content adaptation" I-D has a wider scope
	>>> since it is considering any content-type and it is taking
	>>> into account the terminal/user preferences. So I would say
	>>> that  it fits into SIPPING WG while the filtering I-D is
	>>> mainly dealing with presence and I think it should be handled
	>>> at SIMPLE WG.
	>>> BR
	>>> Jose
	>>>
	>>> -----Original Message----- From: Coulombe Stephane (NRC/Dallas)
	>>>> At a high level, these drafts also argue that capability
	>>>> negotiation should be administered by intermediaries rather
	>>> than through an
	>>>> end-to-end process; this approach may attract some similar
	>>> controversy.
	>>>
	>>> Proposed capability negotiation can be used both ways (end-to-end or
	>>> administered by intermediaries).
	>>> 1) end-to-end: Someone who wants to send an Instant Message
	>>> to another user
	>>>     can send an OPTION query to learn about its terminal
	>>> capabilities and
	>>>     then create a message within its capabilities.
	>>>    
	>>>     I guess this is not controversial. However how
	>>> realistic and usable is it in practice?
	>>>     When composing a message, would a user really want to
	>>> take into consideration
	>>>     the image formats to use, message size limitation, etc?
	>>>
	>>>     For instance, you want to send a PNG image to a friend
	>>> and his terminal only supports
	>>>     GIF format. What are you supposed to do? Find an image
	>>> conversion tool to convert to GIF?
	>>>     This is annoying if you are using a PC, imagine with a
	>>> mobile phone or handheld?
	>>>    
	>>>     For usability reasons, the user wants to send a message
	>>> without caring "too much" about
	>>>     what the other end is supporting.
	>>>
	>>> 2)administered by intermediaries: this is discussed in detail
	>>> in one of the drafts.
	>>>
	>>>     Performing adaptation in the network is controversial
	>>> but this is the only way to support
	>>>     interoperability and good user experience.
	>>>
	>>>> the applicability and impact of this mechanism is larger
	>>> than the problem of
	>>>> instant messaging and presence. While clearly, from the
	>>> framework, instant
	>>>> messaging and presence cases are driving this work, it is
	>>> applicable to the
	>>>> general use of SIP events (messaging, I think, is something
	>>> of a corner case).
	>>>
	>>> Yes, applicability and impact is larger than IM and presence.
	>>> It applies to many other
	>>> applications including the case of audio/video conferencing
	>>> (for instance when there is
	>>> no common audio or video codec between two ends).
	>>>
	>>> The drafts use the "corner case" of SIP IM for a few reasons:
	>>> 1) In SIP IM, there is no concept of capability negotiation
	>>> (unlike the case of sessions using SDP).
	>>>     A user sends a message without knowing anything about
	>>> the recipient's terminal capabilities.
	>>> 2) In SIP IM, it easier to argue that there will be
	>>> interoperability problems because of the variety of content
	>>> types that could be sent (in audio/video session codecs are
	>>> typically more agreed on). Right now text is mostly used but
	>>> richer content will soon be used as is the case in Multimedia
	>>> Messaging Service (MMS). By the way, message adaptation is a
	>>> serious issue in MMS because of fast product capability
	>>> evolution. It's hard to keep interoperability while not
	>>> restricting new phones to send just "low-end" content.
	>>> 3) It is easier to explain the problem and propose a solution
	>>> with a smaller well-defined problem.
	>>>
	>>> Once we agree that SIP message adaptation is required, the
	>>> requirements and solutions should be established from global
	>>> perspective; not just SIP IM. For that reason, SIPPING may be
	>>> the most appropriate place to initiate this activity.
	>>>
	>>> Stephane
	>>>
	>>> -----Original Message-----
	>>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
	>>> Sent: Friday, November 08, 2002 6:58 AM
	>>> To: Isomaki Markus (NRC/Helsinki); dean.willis@softarmor.com;
	>>> drage@lucent.com; rohan@cisco.com; Gonzalo.Camarillo@lmf.ericsson.se
	>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
	>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
	>>> adaptationInternet-Drafts
	>>>
	>>>
	>>>
	>>> It seems to me that these filtering drafts concern the
	>>> modification of MIME
	>>> bodies in SIP messages by intermediaries. This is not exactly an
	>>> uncontroversial topic in SIP circles, and therefore I don't
	>>> think it is a
	>>> foregone conclusion that this is work that some SIP-related
	>> WG should
	>>> charter. At a high level, these drafts also argue that capability
	>>> negotiation should be administered by intermediaries rather
	>>> than through an
	>>> end-to-end process; this approach may attract some similar
	>>> controversy.
	>>>
	>>> Provided that this is work the community would like to pursue, the
	>>> applicability and impact of this mechanism is larger than the
	>>> problem of
	>>> instant messaging and presence. While clearly, from the
	>>> framework, instant
	>>> messaging and presence cases are driving this work, it is
	>>> applicable to the
	>>> general use of SIP events (messaging, I think, is something
	>>> of a corner
	>>> case). While SIMPLE could certainly spend some time refining
	>>> the framework
	>>> and requirements related to IM & presence, I imagine that at
	>>> a mechanism
	>>> stage this work would need to take place in SIPPING.
	>>>
	>>> Jon Peterson
	>>> NeuStar, Inc.
	>>>
	>>>> -----Original Message-----
	>>>> From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com]
	>>>> Sent: Friday, November 08, 2002 3:47 AM
	>>>> To: dean.willis@softarmor.com; drage@lucent.com; rohan@cisco.com;
	>>>> Gonzalo.Camarillo@lmf.ericsson.se
	>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
	>>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
	>>>> adaptationInternet-Drafts
	>>>>
	>>>>
	>>>> Hi,
	>>>>
	>>>> Actually this thread is about two separate things:
	>>>> - Event filtering
	>>>> - Multimedia message adaptation
	>>>>
	>>>> Neither of them appears currently on any sippish WG charter
	>>>> currently.
	>>>>
	>>>> Event filtering has been discussed several times and it is
	>>>> even mentioned in (but out of scope of) SIP Events RFC. My
	>>>> impression has been that people think that it is needed, but
	>>>> there has been debate about scope and feasibility. I hope the
	>>>> requirements draft will help in that discussion. My own
	>>>> opinion is that what is concretely needed in short term is
	>>>> some simple filtering definitions for Presence event package.
	>>>> More wide-scoped and complex things could be worked upon as
	>>>> the understanding accumulates.
	>>>>
	>>>> Multimedia message adaptation hasn't been yet discussed much.
	>>>> I think it is in general a desirable feature, especially for
	>>>> relatively small and dumb terminals, which are not easily
	>>>> upgradable and may not understand all media formats.
	>>>>
	>>>> So I propose the WG chairs think where these items would be
	>>>> appropriate, and if there is enough interest for them, let's
	>>>> put them on the charters.
	>>>>
	>>>> Markus
	>>>>
	>>>>> -----Original Message-----
	>>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
	>>>>> Sent: 08 November, 2002 5:11
	>>>>> To: Drage, Keith (Keith)
	>>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
	>>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message
	>>>>> adaptationInternet-Drafts
	>>>>>
	>>>>>
	>>>>> Well, I'd like to hear opinions from the participants here . . .
	>>>>>
	>>>>> Clearly they aren't explicitly on the charter for either
	>>>>> group. Do we as
	>>>>> yet have a consensus that we need to work on these
	>>>> problems? If so, we
	>>>>> can consider WHERE to work on them. I suspect SIPPING is
	>>> closer to a
	>>>>> matching scope than is SIMPLE, but the relevant ADs may have
	>>>>> suggestions
	>>>>> to make there as well.
	>>>>>
	>>>>> --
	>>>>> Dean
	>>>>>
	>>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
	>>>>>> I am getting a bit confused as to which group should be
	>>>>> discussing these filtering issues.
	>>>>>>
	>>>>>> Could we have a statement from the WG chairs of SIPPING or
	>>>>> SIMPLE as to whether this, and the moran drafts, are part of
	>>>>> the scope of SIPPING or SIMPLE.
	>>>>>>
	>>>>>> And before you say these are both author drafts, I think we
	>>>>> do need to charter one of the WGs to do some work in this
	>>>>> area - I am just not sure of the exact scope yet.
	>>>>>>
	>>>>>> Keith
	>>>>>>
	>>>>>> Keith Drage
	>>>>>> Lucent Technologies
	>>>>>> Tel: +44 1793 776249
	>>>>>> Email: drage@lucent.com
	>>>>>>
	>>>>>>> -----Original Message-----
	>>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
	>>>>>>> Sent: 06 November 2002 18:24
	>>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com
	>>>>>>> Subject: [Simple] Multimedia message adaptation
	>>> Internet-Drafts
	>>>>>>>
	>>>>>>>
	>>>>>>>         While these drafts concern event filtering,
	>>>> too, the subject was
	>>>>>>>         a bit misleading because I lazily just followed
	>>>> up Tim's e-mail.
	>>>>>>>
	>>>>>>>                                         Pekka
	>>>>>>>
	>>>>>>>
	>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
	>>>>>>> ptation-framework-00.txt
	>>>>>>>
	>>>>>>>
	>> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
	>>>>>>> ptation-requirements-00.txt
	>>>>>>>
	>>>>>>> Pekka Pessi  writes:
	>>>>>>>> We have submitted two drafts regarding multimedia message
	>>>>>>>> adaptation. A multimedia message is typically a message
	>>>>>>>> containing images, audio or video clips and their
	>>> presentation
	>>>>>>>> information, e.g., smil. Also, even XML-formatted text may
	>>>>>>>> require adaptation in some cases.
	>>>>>>>
	>>>>>>>> Our goal is to have a framework using SIP, HTTP
	>> and MIME that
	>>>>>>>> allows a person sending multimedia message to adapt
	>>> the message
	>>>>>>>> contents suitable to all the recipients. In some cases the
	>>>>>>>> adaptation can be done by the sending terminal, but
	>>> we also see
	>>>>>>>> that an adaptation service would be very useful in
	>>> many cases.
	>>>>>>>> Such an adaptation mechanism is used by MMS service
	>>> provided by
	>>>>>>>> cellular networks nowadays.
	>>>>>>>
	>>>>>>>> The message adaptation work concerns both SIPPING
	>> and SIMPLE,
	>>>>>>>> the requirements I-D lists use cases and requirements for
	>>>>>>>> multimedia messaging and message adaptation
	>> solutions and the
	>>>>>>>> framework I-D tries to explore possible solutions.
	>>>>>>>
	>>>>>>> _______________________________________________
	>>>>>>> simple mailing list
	>>>>>>> simple@mailman.dynamicsoft.com
	>>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
	>>>>>>>
	>>>>>> _______________________________________________
	>>>>>> Sipping mailing list
	>>>> https://www1.ietf.org/mailman/listinfo/sipping
	>>>>>> This list is for NEW development of the application of SIP
	>>>>>> Use sip-implementors@cs.columbia.edu for questions on
	>>> current sip
	>>>>>> Use sip@ietf.org for new developments of core SIP
	>>>>>>
	>>>>>
	>>>>> _______________________________________________
	>>>>> simple mailing list
	>>>>> simple@mailman.dynamicsoft.com
	>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
	>>>>>
	>>>> _______________________________________________
	>>>> simple mailing list
	>>>> simple@mailman.dynamicsoft.com
	>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
	>>>>
	>>> _______________________________________________
	>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
	>>> This list is for NEW development of the application of SIP
	>>> Use sip-implementors@cs.columbia.edu for questions on current sip
	>>> Use sip@ietf.org for new developments of core SIP
	>>> _______________________________________________
	>>> simple mailing list
	>>> simple@mailman.dynamicsoft.com
	>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
	>>> _______________________________________________
	>>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
	>>> This list is for NEW development of the application of SIP
	>>> Use sip-implementors@cs.columbia.edu for questions on current sip
	>>> Use sip@ietf.org for new developments of core SIP
	>>>
	>> _______________________________________________
	>> simple mailing list
	>> simple@mailman.dynamicsoft.com
	>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
	>>
	> _______________________________________________
	> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
	> This list is for NEW development of the application of SIP
	> Use sip-implementors@cs.columbia.edu for questions on current sip
	> Use sip@ietf.org for new developments of core SIP
	
	_______________________________________________
	Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
	This list is for NEW development of the application of SIP
	Use sip-implementors@cs.columbia.edu for questions on current sip
	Use sip@ietf.org for new developments of core SIP
	


From abbieb@nortelnetworks.com  Thu Nov 14 09:47:06 2002
Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14130
	for ; Thu, 14 Nov 2002 09:47:05 -0500 (EST)
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69])
	by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAEEkbZ11534;
	Thu, 14 Nov 2002 09:46:37 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 14 Nov 2002 09:46:37 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD7540425FFB9@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" 
To: Eric Burger , Jose.Costa-Requena@nokia.com
Cc: bindignavile.srinivas@nokia.com, Stephane.Coulombe@nokia.com,
        jon.peterson@neustar.biz, Markus.Isomaki@nokia.com,
        dean.willis@softarmor.com, drage@lucent.com,
        Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org,
        Pekka.Pessi@nokia.com, simple@mailman.dynamicsoft.com,
        ietf-openproxy@imc.org, UM list , um@snowshore.com
Date: Thu, 14 Nov 2002 09:46:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28BEC.A0ADAA16"
Content-Length: 69358
Subject: [Simple] RE: [Sipping] Multimedia message adaptationInternet-Drafts
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: 

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_01C28BEC.A0ADAA16
Content-Type: text/plain

Eric,

Thanks

We have to be careful here, since some of the work would also fit or is
being done  in W3C and other bodies. 

abbie


> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com] 
> Sent: Thursday, November 14, 2002 9:18 AM
> To: Jose.Costa-Requena@nokia.com
> Cc: bindignavile.srinivas@nokia.com; 
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; 
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com; 
> drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; 
> sipping@ietf.org; Pekka.Pessi@nokia.com; 
> simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM 
> list; um@snowshore.com
> Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts
> 
> 
> 
> I understand the sentiment.  Neither opes nor lemonade are 
> perfect fits for the current proposals.  However, I would 
> offer that the proper home for media adaptation is either 
> opes or lemonade.
>  
> My rationale is simple.  Sipping is a transport area work 
> group.  The experts in the group are transport experts.  The 
> AD's are transport AD's.  Media transformation is an 
> application.  Opes and lemonade are application work groups.  
> The experts in the groups are application experts.  The AD's 
> are application AD's.
>  
> I agree that there may be refinement or conventions that will 
> be needed in SIP to support real-time media transformation.  
> The correct place for that to happen is sipping.  However, 
> the right people with expertise in media transformation are 
> in the opes and lemonade groups.
>  
> From a charter point of view, media transformation (IMHO) is 
> way out of scope for sipping.  We've heard from Abbie that it 
> is sort of out of scope for opes, as opes is focusing on 
> HTTP.  On the other hand, the mechanism being proposed is 
> rather close to the lemonade work.
>  
> I think this work fits into lemonade charter items 1 
> (retrieval protocols) and 5 (translation services). We can 
> refine the language to explicitly contain the real-time 
> adaptation work items, if that would make everyone happy.
>  
> --
> - Eric
>  
>  
>  
>  
> SIPPING is for SIP. OPES and LEMONADE are specifically for 
> media transformation.  Said differently, we have transport 
> experts in SIPPING and application experts in OPES and LEMONADE.
> 
> 	-----Original Message----- 
> 	From: Rohan Mahy [mailto:rohan@cisco.com] 
> 	Sent: Wed 11/13/2002 9:00 PM 
> 	To: Jose.Costa-Requena@nokia.com 
> 	Cc: bindignavile.srinivas@nokia.com; Eric Burger; 
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; 
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com; 
> drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; 
> sipping@ietf.org; Pekka.Pessi@nokia.com; 
> simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM list 
> 	Subject: Re: [Sipping] RE: [Simple] Multimedia message 
> adaptationInternet-Drafts
> 	
> 	
> 
> 	hello,
> 	
> 	please cease an desist cross posting when you reply.  
> sipping seems
> 	like the default wg, so please send your comments only to
> 	sipping@ietf.org.
> 	
> 	thanks,
> 	-rohan
> 	
> 	On Wednesday, November 13, 2002, at 07:35 AM,
> 	Jose.Costa-Requena@nokia.com wrote:
> 	
> 	> Hi,
> 	>
> 	> According to LEMONADE requirements, it is considering 
> mainly messaging
> 	> systems and I agree that this proposal could fit into 
> that context at
> 	> some extent. Nevertheless, the actual proposal deals 
> with content
> 	> adaptation based on UA capabilities registered with 
> SIP. Thus, I
> 	> consider that it is within SIPPING scope, as well.
> 	> Comments?
> 	> BR
> 	> Jose
> 	>
> 	> -----Original Message-----
> 	> From: Srinivas Bindignavile (NRC/Boston)
> 	> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> 	> adaptationInternet-Drafts
> 	>
> 	>
> 	> Hi,
> 	>
> 	> As Eric has indicated, the OPES WG is considering 
> transcoding issues!
> 	> However, presently, rather than being 
> protocol-agnostic, it is being
> 	> designed for HTTP and RTP only. SIP is not being 
> considered here.
> 	>
> 	> -Srini
> 	>
> 	>> -----Original Message-----
> 	>> From: ext Eric Burger [mailto:eburger@snowshore.com]
> 	>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> 	>> adaptationInternet-Drafts
> 	>>
> 	>>
> 	>>
> 	>> There are already TWO work groups that are considering
> 	>> EXACTLY these transcoding requirements.
> 	>>
> 	>> They are OPES and LEMONADE.
> 	>>
> 	>> I would offer that discussion of these capabilities happen in
> 	>> those groups.  If SIP is the appropriate mechanism, then
> 	>> those groups will submit the appropriate drafts to SIPPING,
> 	>> outlining the requirements.
> 	>>
> 	>>> -----Original Message----- From: 
> Jose.Costa-Requena@nokia.com
> 	>> [snip]
> 	>>> Nevertheless, "content adaptation" I-D has a wider scope
> 	>>> since it is considering any content-type and it is taking
> 	>>> into account the terminal/user preferences. So I would say
> 	>>> that  it fits into SIPPING WG while the filtering I-D is
> 	>>> mainly dealing with presence and I think it should 
> be handled
> 	>>> at SIMPLE WG.
> 	>>> BR
> 	>>> Jose
> 	>>>
> 	>>> -----Original Message----- From: Coulombe Stephane 
> (NRC/Dallas)
> 	>>>> At a high level, these drafts also argue that capability
> 	>>>> negotiation should be administered by intermediaries rather
> 	>>> than through an
> 	>>>> end-to-end process; this approach may attract some similar
> 	>>> controversy.
> 	>>>
> 	>>> Proposed capability negotiation can be used both 
> ways (end-to-end or
> 	>>> administered by intermediaries).
> 	>>> 1) end-to-end: Someone who wants to send an Instant Message
> 	>>> to another user
> 	>>>     can send an OPTION query to learn about its terminal
> 	>>> capabilities and
> 	>>>     then create a message within its capabilities.
> 	>>>    
> 	>>>     I guess this is not controversial. However how
> 	>>> realistic and usable is it in practice?
> 	>>>     When composing a message, would a user really want to
> 	>>> take into consideration
> 	>>>     the image formats to use, message size limitation, etc?
> 	>>>
> 	>>>     For instance, you want to send a PNG image to a friend
> 	>>> and his terminal only supports
> 	>>>     GIF format. What are you supposed to do? Find an image
> 	>>> conversion tool to convert to GIF?
> 	>>>     This is annoying if you are using a PC, imagine with a
> 	>>> mobile phone or handheld?
> 	>>>    
> 	>>>     For usability reasons, the user wants to send a message
> 	>>> without caring "too much" about
> 	>>>     what the other end is supporting.
> 	>>>
> 	>>> 2)administered by intermediaries: this is discussed 
> in detail
> 	>>> in one of the drafts.
> 	>>>
> 	>>>     Performing adaptation in the network is controversial
> 	>>> but this is the only way to support
> 	>>>     interoperability and good user experience.
> 	>>>
> 	>>>> the applicability and impact of this mechanism is larger
> 	>>> than the problem of
> 	>>>> instant messaging and presence. While clearly, from the
> 	>>> framework, instant
> 	>>>> messaging and presence cases are driving this work, it is
> 	>>> applicable to the
> 	>>>> general use of SIP events (messaging, I think, is something
> 	>>> of a corner case).
> 	>>>
> 	>>> Yes, applicability and impact is larger than IM and 
> presence.
> 	>>> It applies to many other
> 	>>> applications including the case of audio/video conferencing
> 	>>> (for instance when there is
> 	>>> no common audio or video codec between two ends).
> 	>>>
> 	>>> The drafts use the "corner case" of SIP IM for a 
> few reasons:
> 	>>> 1) In SIP IM, there is no concept of capability negotiation
> 	>>> (unlike the case of sessions using SDP).
> 	>>>     A user sends a message without knowing anything about
> 	>>> the recipient's terminal capabilities.
> 	>>> 2) In SIP IM, it easier to argue that there will be
> 	>>> interoperability problems because of the variety of content
> 	>>> types that could be sent (in audio/video session codecs are
> 	>>> typically more agreed on). Right now text is mostly used but
> 	>>> richer content will soon be used as is the case in 
> Multimedia
> 	>>> Messaging Service (MMS). By the way, message adaptation is a
> 	>>> serious issue in MMS because of fast product capability
> 	>>> evolution. It's hard to keep interoperability while not
> 	>>> restricting new phones to send just "low-end" content.
> 	>>> 3) It is easier to explain the problem and propose 
> a solution
> 	>>> with a smaller well-defined problem.
> 	>>>
> 	>>> Once we agree that SIP message adaptation is required, the
> 	>>> requirements and solutions should be established from global
> 	>>> perspective; not just SIP IM. For that reason, 
> SIPPING may be
> 	>>> the most appropriate place to initiate this activity.
> 	>>>
> 	>>> Stephane
> 	>>>
> 	>>> -----Original Message-----
> 	>>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> 	>>> Sent: Friday, November 08, 2002 6:58 AM
> 	>>> To: Isomaki Markus (NRC/Helsinki); 
> dean.willis@softarmor.com;
> 	>>> drage@lucent.com; rohan@cisco.com; 
> Gonzalo.Camarillo@lmf.ericsson.se
> 	>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> 	>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> 	>>> adaptationInternet-Drafts
> 	>>>
> 	>>>
> 	>>>
> 	>>> It seems to me that these filtering drafts concern the
> 	>>> modification of MIME
> 	>>> bodies in SIP messages by intermediaries. This is 
> not exactly an
> 	>>> uncontroversial topic in SIP circles, and therefore I don't
> 	>>> think it is a
> 	>>> foregone conclusion that this is work that some SIP-related
> 	>> WG should
> 	>>> charter. At a high level, these drafts also argue 
> that capability
> 	>>> negotiation should be administered by intermediaries rather
> 	>>> than through an
> 	>>> end-to-end process; this approach may attract some similar
> 	>>> controversy.
> 	>>>
> 	>>> Provided that this is work the community would like 
> to pursue, the
> 	>>> applicability and impact of this mechanism is 
> larger than the
> 	>>> problem of
> 	>>> instant messaging and presence. While clearly, from the
> 	>>> framework, instant
> 	>>> messaging and presence cases are driving this work, it is
> 	>>> applicable to the
> 	>>> general use of SIP events (messaging, I think, is something
> 	>>> of a corner
> 	>>> case). While SIMPLE could certainly spend some time refining
> 	>>> the framework
> 	>>> and requirements related to IM & presence, I imagine that at
> 	>>> a mechanism
> 	>>> stage this work would need to take place in SIPPING.
> 	>>>
> 	>>> Jon Peterson
> 	>>> NeuStar, Inc.
> 	>>>
> 	>>>> -----Original Message-----
> 	>>>> From: Markus.Isomaki@nokia.com 
> [mailto:Markus.Isomaki@nokia.com]
> 	>>>> Sent: Friday, November 08, 2002 3:47 AM
> 	>>>> To: dean.willis@softarmor.com; drage@lucent.com; 
> rohan@cisco.com;
> 	>>>> Gonzalo.Camarillo@lmf.ericsson.se
> 	>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> 	>>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> 	>>>> adaptationInternet-Drafts
> 	>>>>
> 	>>>>
> 	>>>> Hi,
> 	>>>>
> 	>>>> Actually this thread is about two separate things:
> 	>>>> - Event filtering
> 	>>>> - Multimedia message adaptation
> 	>>>>
> 	>>>> Neither of them appears currently on any sippish WG charter
> 	>>>> currently.
> 	>>>>
> 	>>>> Event filtering has been discussed several times and it is
> 	>>>> even mentioned in (but out of scope of) SIP Events RFC. My
> 	>>>> impression has been that people think that it is 
> needed, but
> 	>>>> there has been debate about scope and feasibility. 
> I hope the
> 	>>>> requirements draft will help in that discussion. My own
> 	>>>> opinion is that what is concretely needed in short term is
> 	>>>> some simple filtering definitions for Presence 
> event package.
> 	>>>> More wide-scoped and complex things could be worked upon as
> 	>>>> the understanding accumulates.
> 	>>>>
> 	>>>> Multimedia message adaptation hasn't been yet 
> discussed much.
> 	>>>> I think it is in general a desirable feature, 
> especially for
> 	>>>> relatively small and dumb terminals, which are not easily
> 	>>>> upgradable and may not understand all media formats.
> 	>>>>
> 	>>>> So I propose the WG chairs think where these items would be
> 	>>>> appropriate, and if there is enough interest for 
> them, let's
> 	>>>> put them on the charters.
> 	>>>>
> 	>>>> Markus
> 	>>>>
> 	>>>>> -----Original Message-----
> 	>>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> 	>>>>> Sent: 08 November, 2002 5:11
> 	>>>>> To: Drage, Keith (Keith)
> 	>>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> 	>>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message
> 	>>>>> adaptationInternet-Drafts
> 	>>>>>
> 	>>>>>
> 	>>>>> Well, I'd like to hear opinions from the 
> participants here . . .
> 	>>>>>
> 	>>>>> Clearly they aren't explicitly on the charter for either
> 	>>>>> group. Do we as
> 	>>>>> yet have a consensus that we need to work on these
> 	>>>> problems? If so, we
> 	>>>>> can consider WHERE to work on them. I suspect SIPPING is
> 	>>> closer to a
> 	>>>>> matching scope than is SIMPLE, but the relevant 
> ADs may have
> 	>>>>> suggestions
> 	>>>>> to make there as well.
> 	>>>>>
> 	>>>>> --
> 	>>>>> Dean
> 	>>>>>
> 	>>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> 	>>>>>> I am getting a bit confused as to which group should be
> 	>>>>> discussing these filtering issues.
> 	>>>>>>
> 	>>>>>> Could we have a statement from the WG chairs of 
> SIPPING or
> 	>>>>> SIMPLE as to whether this, and the moran drafts, 
> are part of
> 	>>>>> the scope of SIPPING or SIMPLE.
> 	>>>>>>
> 	>>>>>> And before you say these are both author drafts, 
> I think we
> 	>>>>> do need to charter one of the WGs to do some work in this
> 	>>>>> area - I am just not sure of the exact scope yet.
> 	>>>>>>
> 	>>>>>> Keith
> 	>>>>>>
> 	>>>>>> Keith Drage
> 	>>>>>> Lucent Technologies
> 	>>>>>> Tel: +44 1793 776249
> 	>>>>>> Email: drage@lucent.com
> 	>>>>>>
> 	>>>>>>> -----Original Message-----
> 	>>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> 	>>>>>>> Sent: 06 November 2002 18:24
> 	>>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> 	>>>>>>> Subject: [Simple] Multimedia message adaptation
> 	>>> Internet-Drafts
> 	>>>>>>>
> 	>>>>>>>
> 	>>>>>>>         While these drafts concern event filtering,
> 	>>>> too, the subject was
> 	>>>>>>>         a bit misleading because I lazily just followed
> 	>>>> up Tim's e-mail.
> 	>>>>>>>
> 	>>>>>>>                                         Pekka
> 	>>>>>>>
> 	>>>>>>>
> 	>> 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> 	>>>>>>> ptation-framework-00.txt
> 	>>>>>>>
> 	>>>>>>>
> 	>> 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> 	>>>>>>> ptation-requirements-00.txt
> 	>>>>>>>
> 	>>>>>>> Pekka Pessi  writes:
> 	>>>>>>>> We have submitted two drafts regarding 
> multimedia message
> 	>>>>>>>> adaptation. A multimedia message is typically a message
> 	>>>>>>>> containing images, audio or video clips and their
> 	>>> presentation
> 	>>>>>>>> information, e.g., smil. Also, even 
> XML-formatted text may
> 	>>>>>>>> require adaptation in some cases.
> 	>>>>>>>
> 	>>>>>>>> Our goal is to have a framework using SIP, HTTP
> 	>> and MIME that
> 	>>>>>>>> allows a person sending multimedia message to adapt
> 	>>> the message
> 	>>>>>>>> contents suitable to all the recipients. In 
> some cases the
> 	>>>>>>>> adaptation can be done by the sending terminal, but
> 	>>> we also see
> 	>>>>>>>> that an adaptation service would be very useful in
> 	>>> many cases.
> 	>>>>>>>> Such an adaptation mechanism is used by MMS service
> 	>>> provided by
> 	>>>>>>>> cellular networks nowadays.
> 	>>>>>>>
> 	>>>>>>>> The message adaptation work concerns both SIPPING
> 	>> and SIMPLE,
> 	>>>>>>>> the requirements I-D lists use cases and 
> requirements for
> 	>>>>>>>> multimedia messaging and message adaptation
> 	>> solutions and the
> 	>>>>>>>> framework I-D tries to explore possible solutions.
> 	>>>>>>>
> 	>>>>>>> _______________________________________________
> 	>>>>>>> simple mailing list
> 	>>>>>>> simple@mailman.dynamicsoft.com
> 	>>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>>>>>>
> 	>>>>>> _______________________________________________
> 	>>>>>> Sipping mailing list
> 	>>>> https://www1.ietf.org/mailman/listinfo/sipping
> 	>>>>>> This list is for NEW development of the 
> application of SIP
> 	>>>>>> Use sip-implementors@cs.columbia.edu for questions on
> 	>>> current sip
> 	>>>>>> Use sip@ietf.org for new developments of core SIP
> 	>>>>>>
> 	>>>>>
> 	>>>>> _______________________________________________
> 	>>>>> simple mailing list
> 	>>>>> simple@mailman.dynamicsoft.com
> 	>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>>>>
> 	>>>> _______________________________________________
> 	>>>> simple mailing list
> 	>>>> simple@mailman.dynamicsoft.com
> 	>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>>>
> 	>>> _______________________________________________
> 	>>> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> 	>>> 
> This list is for NEW development of the application of SIP
> 	>>> Use sip-implementors@cs.columbia.edu for questions 
> on current sip
> 	>>> Use sip@ietf.org for new developments of core SIP
> 	>>> _______________________________________________
> 	>>> simple mailing list
> 	>>> simple@mailman.dynamicsoft.com
> 	>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>> _______________________________________________
> 	>>> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> 	>>> 
> This list is for NEW development of the application of SIP
> 	>>> Use sip-implementors@cs.columbia.edu for questions 
> on current sip
> 	>>> Use sip@ietf.org for new developments of core SIP
> 	>>>
> 	>> _______________________________________________
> 	>> simple mailing list
> 	>> simple@mailman.dynamicsoft.com
> 	>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>
> 	> _______________________________________________
> 	> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> 	> This 
> list is for NEW development of the application of SIP
> 	> Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> 	> Use sip@ietf.org for new developments of core SIP
> 	
> 	_______________________________________________
> 	Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> 	This 
> list is for NEW development of the application of SIP
> 	Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> 	Use sip@ietf.org for new developments of core SIP
> 	
> 
> 

------_=_NextPart_001_01C28BEC.A0ADAA16
Content-Type: text/html






RE: [Sipping] Multimedia message adaptationInternet-Drafts




Eric,




Thanks




We have to be careful here, since some of the work would also fit or is being done  in W3C and other bodies. 




abbie






> -----Original Message-----

> From: Eric Burger [mailto:eburger@snowshore.com] 

> Sent: Thursday, November 14, 2002 9:18 AM

> To: Jose.Costa-Requena@nokia.com

> Cc: bindignavile.srinivas@nokia.com; 

> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; 

> Markus.Isomaki@nokia.com; dean.willis@softarmor.com; 

> drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; 

> sipping@ietf.org; Pekka.Pessi@nokia.com; 

> simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM 

> list; um@snowshore.com

> Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts

> 

> 

> 

> I understand the sentiment.  Neither opes nor lemonade are 

> perfect fits for the current proposals.  However, I would 

> offer that the proper home for media adaptation is either 

> opes or lemonade.

>  

> My rationale is simple.  Sipping is a transport area work 

> group.  The experts in the group are transport experts.  The 

> AD's are transport AD's.  Media transformation is an 

> application.  Opes and lemonade are application work groups.  

> The experts in the groups are application experts.  The AD's 

> are application AD's.

>  

> I agree that there may be refinement or conventions that will 

> be needed in SIP to support real-time media transformation.  

> The correct place for that to happen is sipping.  However, 

> the right people with expertise in media transformation are 

> in the opes and lemonade groups.

>  

> From a charter point of view, media transformation (IMHO) is 

> way out of scope for sipping.  We've heard from Abbie that it 

> is sort of out of scope for opes, as opes is focusing on 

> HTTP.  On the other hand, the mechanism being proposed is 

> rather close to the lemonade work.

>  

> I think this work fits into lemonade charter items 1 

> (retrieval protocols) and 5 (translation services). We can 

> refine the language to explicitly contain the real-time 

> adaptation work items, if that would make everyone happy.

>  

> --

> - Eric

>  

>  

>  

>  

> SIPPING is for SIP. OPES and LEMONADE are specifically for 

> media transformation.  Said differently, we have transport 

> experts in SIPPING and application experts in OPES and LEMONADE.

> 

>       -----Original Message----- 

>       From: Rohan Mahy [mailto:rohan@cisco.com] 

>       Sent: Wed 11/13/2002 9:00 PM 

>       To: Jose.Costa-Requena@nokia.com 

>       Cc: bindignavile.srinivas@nokia.com; Eric Burger; 

> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; 

> Markus.Isomaki@nokia.com; dean.willis@softarmor.com; 

> drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; 

> sipping@ietf.org; Pekka.Pessi@nokia.com; 

> simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM list 

>       Subject: Re: [Sipping] RE: [Simple] Multimedia message 

> adaptationInternet-Drafts

>       

>       

> 

>       hello,

>       

>       please cease an desist cross posting when you reply.  

> sipping seems

>       like the default wg, so please send your comments only to

>       sipping@ietf.org.

>       

>       thanks,

>       -rohan

>       

>       On Wednesday, November 13, 2002, at 07:35 AM,

>       Jose.Costa-Requena@nokia.com wrote:

>       

>       > Hi,

>       >

>       > According to LEMONADE requirements, it is considering 

> mainly messaging

>       > systems and I agree that this proposal could fit into 

> that context at

>       > some extent. Nevertheless, the actual proposal deals 

> with content

>       > adaptation based on UA capabilities registered with 

> SIP. Thus, I

>       > consider that it is within SIPPING scope, as well.

>       > Comments?

>       > BR

>       > Jose

>       >

>       > -----Original Message-----

>       > From: Srinivas Bindignavile (NRC/Boston)

>       > Subject: RE: [Sipping] RE: [Simple] Multimedia message

>       > adaptationInternet-Drafts

>       >

>       >

>       > Hi,

>       >

>       > As Eric has indicated, the OPES WG is considering 

> transcoding issues!

>       > However, presently, rather than being 

> protocol-agnostic, it is being

>       > designed for HTTP and RTP only. SIP is not being 

> considered here.

>       >

>       > -Srini

>       >

>       >> -----Original Message-----

>       >> From: ext Eric Burger [mailto:eburger@snowshore.com]

>       >> Subject: RE: [Sipping] RE: [Simple] Multimedia message

>       >> adaptationInternet-Drafts

>       >>

>       >>

>       >>

>       >> There are already TWO work groups that are considering

>       >> EXACTLY these transcoding requirements.

>       >>

>       >> They are OPES and LEMONADE.

>       >>

>       >> I would offer that discussion of these capabilities happen in

>       >> those groups.  If SIP is the appropriate mechanism, then

>       >> those groups will submit the appropriate drafts to SIPPING,

>       >> outlining the requirements.

>       >>

>       >>> -----Original Message----- From: 

> Jose.Costa-Requena@nokia.com

>       >> [snip]

>       >>> Nevertheless, "content adaptation" I-D has a wider scope

>       >>> since it is considering any content-type and it is taking

>       >>> into account the terminal/user preferences. So I would say

>       >>> that  it fits into SIPPING WG while the filtering I-D is

>       >>> mainly dealing with presence and I think it should 

> be handled

>       >>> at SIMPLE WG.

>       >>> BR

>       >>> Jose

>       >>>

>       >>> -----Original Message----- From: Coulombe Stephane 

> (NRC/Dallas)

>       >>>> At a high level, these drafts also argue that capability

>       >>>> negotiation should be administered by intermediaries rather

>       >>> than through an

>       >>>> end-to-end process; this approach may attract some similar

>       >>> controversy.

>       >>>

>       >>> Proposed capability negotiation can be used both 

> ways (end-to-end or

>       >>> administered by intermediaries).

>       >>> 1) end-to-end: Someone who wants to send an Instant Message

>       >>> to another user

>       >>>     can send an OPTION query to learn about its terminal

>       >>> capabilities and

>       >>>     then create a message within its capabilities.

>       >>>    

>       >>>     I guess this is not controversial. However how

>       >>> realistic and usable is it in practice?

>       >>>     When composing a message, would a user really want to

>       >>> take into consideration

>       >>>     the image formats to use, message size limitation, etc?

>       >>>

>       >>>     For instance, you want to send a PNG image to a friend

>       >>> and his terminal only supports

>       >>>     GIF format. What are you supposed to do? Find an image

>       >>> conversion tool to convert to GIF?

>       >>>     This is annoying if you are using a PC, imagine with a

>       >>> mobile phone or handheld?

>       >>>    

>       >>>     For usability reasons, the user wants to send a message

>       >>> without caring "too much" about

>       >>>     what the other end is supporting.

>       >>>

>       >>> 2)administered by intermediaries: this is discussed 

> in detail

>       >>> in one of the drafts.

>       >>>

>       >>>     Performing adaptation in the network is controversial

>       >>> but this is the only way to support

>       >>>     interoperability and good user experience.

>       >>>

>       >>>> the applicability and impact of this mechanism is larger

>       >>> than the problem of

>       >>>> instant messaging and presence. While clearly, from the

>       >>> framework, instant

>       >>>> messaging and presence cases are driving this work, it is

>       >>> applicable to the

>       >>>> general use of SIP events (messaging, I think, is something

>       >>> of a corner case).

>       >>>

>       >>> Yes, applicability and impact is larger than IM and 

> presence.

>       >>> It applies to many other

>       >>> applications including the case of audio/video conferencing

>       >>> (for instance when there is

>       >>> no common audio or video codec between two ends).

>       >>>

>       >>> The drafts use the "corner case" of SIP IM for a 

> few reasons:

>       >>> 1) In SIP IM, there is no concept of capability negotiation

>       >>> (unlike the case of sessions using SDP).

>       >>>     A user sends a message without knowing anything about

>       >>> the recipient's terminal capabilities.

>       >>> 2) In SIP IM, it easier to argue that there will be

>       >>> interoperability problems because of the variety of content

>       >>> types that could be sent (in audio/video session codecs are

>       >>> typically more agreed on). Right now text is mostly used but

>       >>> richer content will soon be used as is the case in 

> Multimedia

>       >>> Messaging Service (MMS). By the way, message adaptation is a

>       >>> serious issue in MMS because of fast product capability

>       >>> evolution. It's hard to keep interoperability while not

>       >>> restricting new phones to send just "low-end" content.

>       >>> 3) It is easier to explain the problem and propose 

> a solution

>       >>> with a smaller well-defined problem.

>       >>>

>       >>> Once we agree that SIP message adaptation is required, the

>       >>> requirements and solutions should be established from global

>       >>> perspective; not just SIP IM. For that reason, 

> SIPPING may be

>       >>> the most appropriate place to initiate this activity.

>       >>>

>       >>> Stephane

>       >>>

>       >>> -----Original Message-----

>       >>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]

>       >>> Sent: Friday, November 08, 2002 6:58 AM

>       >>> To: Isomaki Markus (NRC/Helsinki); 

> dean.willis@softarmor.com;

>       >>> drage@lucent.com; rohan@cisco.com; 

> Gonzalo.Camarillo@lmf.ericsson.se

>       >>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com

>       >>> Subject: RE: [Sipping] RE: [Simple] Multimedia message

>       >>> adaptationInternet-Drafts

>       >>>

>       >>>

>       >>>

>       >>> It seems to me that these filtering drafts concern the

>       >>> modification of MIME

>       >>> bodies in SIP messages by intermediaries. This is 

> not exactly an

>       >>> uncontroversial topic in SIP circles, and therefore I don't

>       >>> think it is a

>       >>> foregone conclusion that this is work that some SIP-related

>       >> WG should

>       >>> charter. At a high level, these drafts also argue 

> that capability

>       >>> negotiation should be administered by intermediaries rather

>       >>> than through an

>       >>> end-to-end process; this approach may attract some similar

>       >>> controversy.

>       >>>

>       >>> Provided that this is work the community would like 

> to pursue, the

>       >>> applicability and impact of this mechanism is 

> larger than the

>       >>> problem of

>       >>> instant messaging and presence. While clearly, from the

>       >>> framework, instant

>       >>> messaging and presence cases are driving this work, it is

>       >>> applicable to the

>       >>> general use of SIP events (messaging, I think, is something

>       >>> of a corner

>       >>> case). While SIMPLE could certainly spend some time refining

>       >>> the framework

>       >>> and requirements related to IM & presence, I imagine that at

>       >>> a mechanism

>       >>> stage this work would need to take place in SIPPING.

>       >>>

>       >>> Jon Peterson

>       >>> NeuStar, Inc.

>       >>>

>       >>>> -----Original Message-----

>       >>>> From: Markus.Isomaki@nokia.com 

> [mailto:Markus.Isomaki@nokia.com]

>       >>>> Sent: Friday, November 08, 2002 3:47 AM

>       >>>> To: dean.willis@softarmor.com; drage@lucent.com; 

> rohan@cisco.com;

>       >>>> Gonzalo.Camarillo@lmf.ericsson.se

>       >>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com

>       >>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message

>       >>>> adaptationInternet-Drafts

>       >>>>

>       >>>>

>       >>>> Hi,

>       >>>>

>       >>>> Actually this thread is about two separate things:

>       >>>> - Event filtering

>       >>>> - Multimedia message adaptation

>       >>>>

>       >>>> Neither of them appears currently on any sippish WG charter

>       >>>> currently.

>       >>>>

>       >>>> Event filtering has been discussed several times and it is

>       >>>> even mentioned in (but out of scope of) SIP Events RFC. My

>       >>>> impression has been that people think that it is 

> needed, but

>       >>>> there has been debate about scope and feasibility. 

> I hope the

>       >>>> requirements draft will help in that discussion. My own

>       >>>> opinion is that what is concretely needed in short term is

>       >>>> some simple filtering definitions for Presence 

> event package.

>       >>>> More wide-scoped and complex things could be worked upon as

>       >>>> the understanding accumulates.

>       >>>>

>       >>>> Multimedia message adaptation hasn't been yet 

> discussed much.

>       >>>> I think it is in general a desirable feature, 

> especially for

>       >>>> relatively small and dumb terminals, which are not easily

>       >>>> upgradable and may not understand all media formats.

>       >>>>

>       >>>> So I propose the WG chairs think where these items would be

>       >>>> appropriate, and if there is enough interest for 

> them, let's

>       >>>> put them on the charters.

>       >>>>

>       >>>> Markus

>       >>>>

>       >>>>> -----Original Message-----

>       >>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com]

>       >>>>> Sent: 08 November, 2002 5:11

>       >>>>> To: Drage, Keith (Keith)

>       >>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com

>       >>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message

>       >>>>> adaptationInternet-Drafts

>       >>>>>

>       >>>>>

>       >>>>> Well, I'd like to hear opinions from the 

> participants here . . .

>       >>>>>

>       >>>>> Clearly they aren't explicitly on the charter for either

>       >>>>> group. Do we as

>       >>>>> yet have a consensus that we need to work on these

>       >>>> problems? If so, we

>       >>>>> can consider WHERE to work on them. I suspect SIPPING is

>       >>> closer to a

>       >>>>> matching scope than is SIMPLE, but the relevant 

> ADs may have

>       >>>>> suggestions

>       >>>>> to make there as well.

>       >>>>>

>       >>>>> --

>       >>>>> Dean

>       >>>>>

>       >>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:

>       >>>>>> I am getting a bit confused as to which group should be

>       >>>>> discussing these filtering issues.

>       >>>>>>

>       >>>>>> Could we have a statement from the WG chairs of 

> SIPPING or

>       >>>>> SIMPLE as to whether this, and the moran drafts, 

> are part of

>       >>>>> the scope of SIPPING or SIMPLE.

>       >>>>>>

>       >>>>>> And before you say these are both author drafts, 

> I think we

>       >>>>> do need to charter one of the WGs to do some work in this

>       >>>>> area - I am just not sure of the exact scope yet.

>       >>>>>>

>       >>>>>> Keith

>       >>>>>>

>       >>>>>> Keith Drage

>       >>>>>> Lucent Technologies

>       >>>>>> Tel: +44 1793 776249

>       >>>>>> Email: drage@lucent.com

>       >>>>>>

>       >>>>>>> -----Original Message-----

>       >>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]

>       >>>>>>> Sent: 06 November 2002 18:24

>       >>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com

>       >>>>>>> Subject: [Simple] Multimedia message adaptation

>       >>> Internet-Drafts

>       >>>>>>>

>       >>>>>>>

>       >>>>>>>         While these drafts concern event filtering,

>       >>>> too, the subject was

>       >>>>>>>         a bit misleading because I lazily just followed

>       >>>> up Tim's e-mail.

>       >>>>>>>

>       >>>>>>>                                         Pekka

>       >>>>>>>

>       >>>>>>>

>       >> 

> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada

>       >>>>>>> ptation-framework-00.txt

>       >>>>>>>

>       >>>>>>>

>       >> 

> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada

>       >>>>>>> ptation-requirements-00.txt

>       >>>>>>>

>       >>>>>>> Pekka Pessi <Pekka.Pessi@nokia.com> writes:

>       >>>>>>>> We have submitted two drafts regarding 

> multimedia message

>       >>>>>>>> adaptation. A multimedia message is typically a message

>       >>>>>>>> containing images, audio or video clips and their

>       >>> presentation

>       >>>>>>>> information, e.g., smil. Also, even 

> XML-formatted text may

>       >>>>>>>> require adaptation in some cases.

>       >>>>>>>

>       >>>>>>>> Our goal is to have a framework using SIP, HTTP

>       >> and MIME that

>       >>>>>>>> allows a person sending multimedia message to adapt

>       >>> the message

>       >>>>>>>> contents suitable to all the recipients. In 

> some cases the

>       >>>>>>>> adaptation can be done by the sending terminal, but

>       >>> we also see

>       >>>>>>>> that an adaptation service would be very useful in

>       >>> many cases.

>       >>>>>>>> Such an adaptation mechanism is used by MMS service

>       >>> provided by

>       >>>>>>>> cellular networks nowadays.

>       >>>>>>>

>       >>>>>>>> The message adaptation work concerns both SIPPING

>       >> and SIMPLE,

>       >>>>>>>> the requirements I-D lists use cases and 

> requirements for

>       >>>>>>>> multimedia messaging and message adaptation

>       >> solutions and the

>       >>>>>>>> framework I-D tries to explore possible solutions.

>       >>>>>>>

>       >>>>>>> _______________________________________________

>       >>>>>>> simple mailing list

>       >>>>>>> simple@mailman.dynamicsoft.com

>       >>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple

>       >>>>>>>

>       >>>>>> _______________________________________________

>       >>>>>> Sipping mailing list

>       >>>> https://www1.ietf.org/mailman/listinfo/sipping

>       >>>>>> This list is for NEW development of the 

> application of SIP

>       >>>>>> Use sip-implementors@cs.columbia.edu for questions on

>       >>> current sip

>       >>>>>> Use sip@ietf.org for new developments of core SIP

>       >>>>>>

>       >>>>>

>       >>>>> _______________________________________________

>       >>>>> simple mailing list

>       >>>>> simple@mailman.dynamicsoft.com

>       >>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple

>       >>>>>

>       >>>> _______________________________________________

>       >>>> simple mailing list

>       >>>> simple@mailman.dynamicsoft.com

>       >>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple

>       >>>>

>       >>> _______________________________________________

>       >>> Sipping mailing list  

> https://www1.ietf.org/mailman/listinfo/sipping

>       >>> 

> This list is for NEW development of the application of SIP

>       >>> Use sip-implementors@cs.columbia.edu for questions 

> on current sip

>       >>> Use sip@ietf.org for new developments of core SIP

>       >>> _______________________________________________

>       >>> simple mailing list

>       >>> simple@mailman.dynamicsoft.com

>       >>> http://mailman.dynamicsoft.com/mailman/listinfo/simple

>       >>> _______________________________________________

>       >>> Sipping mailing list  

> https://www1.ietf.org/mailman/listinfo/sipping

>       >>> 

> This list is for NEW development of the application of SIP

>       >>> Use sip-implementors@cs.columbia.edu for questions 

> on current sip

>       >>> Use sip@ietf.org for new developments of core SIP

>       >>>

>       >> _______________________________________________

>       >> simple mailing list

>       >> simple@mailman.dynamicsoft.com

>       >> http://mailman.dynamicsoft.com/mailman/listinfo/simple

>       >>

>       > _______________________________________________

>       > Sipping mailing list  

> https://www1.ietf.org/mailman/listinfo/sipping

>       > This 

> list is for NEW development of the application of SIP

>       > Use sip-implementors@cs.columbia.edu for questions on 

> current sip

>       > Use sip@ietf.org for new developments of core SIP

>       

>       _______________________________________________

>       Sipping mailing list  

> https://www1.ietf.org/mailman/listinfo/sipping

>       This 

> list is for NEW development of the application of SIP

>       Use sip-implementors@cs.columbia.edu for questions on 

> current sip

>       Use sip@ietf.org for new developments of core SIP

>       

> 

> 





------_=_NextPart_001_01C28BEC.A0ADAA16--

From pkyzivat@cisco.com  Thu Nov 14 09:59:45 2002
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 JAA14317
	for ; Thu, 14 Nov 2002 09:59:44 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAEExv7G003903;
	Thu, 14 Nov 2002 09:59: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 AAU85139;
	Thu, 14 Nov 2002 10:04:30 -0500 (EST)
Message-ID: <3DD3BA57.1BFC0BA0@cisco.com>
Date: Thu, 14 Nov 2002 09:59:35 -0500
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: Ben Campbell 
CC: Jonathan Rosenberg ,
        Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 4528
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: 


Ben Campbell wrote:
> 
> >  > But I'm not sure this is workable even with that limitation. I have a
> >  > hunch there is still a race condition when one end will think there
> >  > is a connection and attempt to reuse it, while the other end has
> >  > decided there is no session using the connection and tries to drop it
> >  > or establish a new one. This is tricky, and probably impossible to
> >  > decide in general except with respect to a precise rule for reuse.
> >  > But here is one case that seems simpler than some others:
> 
> So, what happens if you attempt to resuse a connection that is dropped?
> Won't that fact quickly become apparent? Can't we just reconnect?
> 
> There may be a complication here in that comedia says you can't just
> reconnect, you must renegotiate SDP--but scenario under discussion
> results from an SDP notification, so I am not sure if that requirement
> is constrainint here.

Comedia currently says you start listening for a connection when you need one, and you stop listening when you get one. And after you stop, you can recycle the port on which you were listening for the connection. And the connection you got then isn't dropped until a BYE or reinvite.

This logic doesn't work for intermediaries that are multiplexing connections. They need a different rule for when to reuse a connection and when to create one. This is where the race conditions come in.

> > So, whats the problem? Well, all intermediaries need to maintain a
> > routing table, which tells them what to do with incoming messages. That
> > table tells them that if an IM arrives on some specific connection, with
> > a specific URI/identifier in the outer envelope, to forward to a
> > different connection with a different URI/identifier in the outer
> > envelope. THis means that the intermediary has to associate each
> > connection with a specific dialog used to set it up (since the dialog is
> > used to exchange the SDP that contains the URI/identifiers). How is this
> > association done?
> 
> I am not sure I understand the difficulty here. These intermediaries
> surely must be SIP aware, if they are in the business of re-writing SDP.
> Additionally, it seems to me that they must be dialog stateful devices.
> Why can't they just maintain a table that associates a dialog with a
> session, and the session with a connection, where the association
> between session and connection is many-to-one?
> 
> If we get SDP describing a new _session_, it will contain address, port,
> and direction information. A device can check the connection table to
> determine whether it currently has a connection opened to that
> particular address and port, can't it? If so, why can't it just start
> interleaving messages for the new session onto the existing connection?
> Maybe I am being dense, but I do not understand what problem the
> connection-id mechanism below is trying to solve.

That's ok on the inbound side, multiplexing traffic. But its not sufficient on the outbound side, where the traffic needs to be demultiplexed. On that side, the intermediary needs to have a mapping between something in the multiplexed media stream and the outbound session.

> 
> >
> > Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out
> > by A in your example contains the source IP/port it will make the
> > connection from. So, when I1 receives the connection request, it can
> > determine the source, and then match it to the dialog. The problem is,
> > this doesn't work at all through NAT. If you don't want to use the
> > source to demux, the intermediary can arrange for each connection to
> > occur on a different port, and that means no reuse. So, we have a real
> > problem.
> >
> 
> I will note that comedia says you should _not_ use source address this
> way unless you are certain your network is free of the blight of NATs.
> 
> But since a connection can carry more than one session, it makes no
> sense to try to tie a connection request to a particular dialog. The
> cpim-msgfmt session draft has its own mechanism for identifying the
> session. Why can a participating device not relate that to the dialog
> that set upt he session in the first place?

What you have done is identify the mismatch between the semantics of comedia and the semantics of cpim.

comedia was faced with the need to set up the media stream without any constraint over the content of that stream. It leads to a different solution that isn't ideal here. (In fact, it may not be ideal for anything.)

From hisham.khartabil@nokia.com  Thu Nov 14 10:36:26 2002
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 KAA14525
	for ; Thu, 14 Nov 2002 10:36:26 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAEFZuO13912
	for ; Thu, 14 Nov 2002 17:35:56 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Thu, 14 Nov 2002 17:36:24 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 14 Nov 2002 17:36:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 14 Nov 2002 17:36:25 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FC1@esebe019.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on Data Manipulation Requirements
Thread-Index: AcKL85dqzLy9xVf9RliH26JjKgQMzg==
To: 
X-OriginalArrivalTime: 14 Nov 2002 15:36:26.0092 (UTC) FILETIME=[97DC82C0:01C28BF3]
Content-Length: 1596
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id KAA14525
Subject: [Simple] Comments on Data Manipulation Requirements
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: 

Hi,

Section 5.1
REQ 2: This requirement is talking about rejecting a subscriber not belonging in an "Allowed Watchers" list. Should rejecting only be based on subscribers belonging to "Blocked Watchers". In this case, REQ 2 would be changed to talk about adding that subscriber to a "Pending Watchers" list and accepting the subscription. (Or do we need both REQ 2 as it stands and REQ 2 as I suggest?)

REQ 7.7: This is similar to REQ 7 in section 4, should both requirements carry the same strength (MUST or SHOULD)?

REQ 7.8: should it continue specifying that "If the URI cannot be allocated (because it already exists, for example), it MUST be possible to inform the client of the failure, and the reason for it"? This aligns it with REQ 2 in section 4.

REQ 7.9: This is similar to REQ 3 in section 4, should both requirements carry the same strength (MUST or SHOULD)?
REQ 7.9: should it continue specifying that this happens in case user does not provide one? This aligns it with REQ 3 in section 4.

Section 5.2
REQ 4: I don't quite understand this one. Is it talking about filters in subscribe specifying higher rate that the minimum?

Section 5.3
REQ 3: This can result in a NOTIFY with no tuples. Is that Ok? should the NOTIFY be sent? if so, what does it mean?

REQ 4: Tuples cannot be meaningfully identified. Communication means might be a better choice.

Back to section 3:

It states that a PA can receive a subscription with presence list uri. Are we assuming that a PA is a PLS? Does a PA's definition allow for this? This is irrelevant to this draft anyway.

Regards,
Hisham


From jdrosen@dynamicsoft.com  Thu Nov 14 17:27:56 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16014
	for ; Thu, 14 Nov 2002 17:27:56 -0500 (EST)
Received: from dynamicsoft.com ([63.113.47.242])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAEMRwYH000537;
	Thu, 14 Nov 2002 17:27:58 -0500 (EST)
Message-ID: <3DD4236B.6070600@dynamicsoft.com>
Date: Thu, 14 Nov 2002 17:27:55 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell 
CC: Paul Kyzivat , Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2187
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: 

inline.

Ben Campbell wrote:

>> So, whats the problem? Well, all intermediaries need to maintain a 
>> routing table, which tells them what to do with incoming messages. 
>> That table tells them that if an IM arrives on some specific 
>> connection, with a specific URI/identifier in the outer envelope, to 
>> forward to a different connection with a different URI/identifier in 
>> the outer envelope. THis means that the intermediary has to associate 
>> each connection with a specific dialog used to set it up (since the 
>> dialog is used to exchange the SDP that contains the URI/identifiers). 
>> How is this association done?
> 
> 
> I am not sure I understand the difficulty here. These intermediaries 
> surely must be SIP aware, if they are in the business of re-writing SDP. 
> Additionally, it seems to me that they must be dialog stateful devices. 
> Why can't they just maintain a table that associates a dialog with a 
> session, and the session with a connection, where the association 
> between session and connection is many-to-one?

The issue is identifying the connection.

Lets say A calls B through intermediary I. Consider the SDP in the 200 
OK from I to A. The SDP will indicate to A to open a TCP connection to a 
well known port on the single IP address of the intermediary I. This is 
the same port and IP address handed out to every other client. If A is 
active, and initiates the connection to I, when I receives the 
connection request, how does it know its associated with the call that 
was just made? The destination IP provides no information - its to the 
well known address and port. The source address is useless because of 
NAT. So, how does it know?

It can't, unless it uses a distinct port for each connection, which 
doesnt work with intermediaries. And thus our dilemma.

-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


From jdrosen@dynamicsoft.com  Thu Nov 14 17:28:51 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16031
	for ; Thu, 14 Nov 2002 17:28:51 -0500 (EST)
Received: from dynamicsoft.com ([63.113.47.242])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAEMSrYH000540;
	Thu, 14 Nov 2002 17:28:53 -0500 (EST)
Message-ID: <3DD423A2.9080502@dynamicsoft.com>
Date: Thu, 14 Nov 2002 17:28:50 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Ben Campbell ,
        Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD3BA57.1BFC0BA0@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1310
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: 


Paul Kyzivat wrote:
 >

 >> But since a connection can carry more than one session, it makes no
 >>  sense to try to tie a connection request to a particular dialog.
 >> The cpim-msgfmt session draft has its own mechanism for identifying
 >> the session. Why can a participating device not relate that to the
 >> dialog that set upt he session in the first place?
 >
 >
 > What you have done is identify the mismatch between the semantics of
 > comedia and the semantics of cpim.
 >
 > comedia was faced with the need to set up the media stream without
 > any constraint over the content of that stream. It leads to a
 > different solution that isn't ideal here. (In fact, it may not be
 > ideal for anything.)
 >

Well, thats a problem I think.

I suspect at this point we need to raise these issues in mmusic. At the 
very least, I'd like to be able to EXTEND comedia to meet our 
requirements. Its not even clear to me that we can do that.

-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


From bcampbell@dynamicsoft.com  Thu Nov 14 17:48:07 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16167
	for ; Thu, 14 Nov 2002 17:48:07 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gAEMm0U1052387;
	Thu, 14 Nov 2002 16:48:00 -0600 (CST)
Message-ID: <3DD42816.5020906@dynamicsoft.com>
Date: Thu, 14 Nov 2002 16:47:50 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: Paul Kyzivat , Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD4236B.6070600@dynamicsoft.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2491
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: 

Jonathan Rosenberg wrote:
> inline.
> 
> Ben Campbell wrote:
> 
>>> So, whats the problem? Well, all intermediaries need to maintain a 
>>> routing table, which tells them what to do with incoming messages. 
>>> That table tells them that if an IM arrives on some specific 
>>> connection, with a specific URI/identifier in the outer envelope, to 
>>> forward to a different connection with a different URI/identifier in 
>>> the outer envelope. THis means that the intermediary has to associate 
>>> each connection with a specific dialog used to set it up (since the 
>>> dialog is used to exchange the SDP that contains the 
>>> URI/identifiers). How is this association done?
>>
>>
>>
>> I am not sure I understand the difficulty here. These intermediaries 
>> surely must be SIP aware, if they are in the business of re-writing 
>> SDP. Additionally, it seems to me that they must be dialog stateful 
>> devices. Why can't they just maintain a table that associates a dialog 
>> with a session, and the session with a connection, where the 
>> association between session and connection is many-to-one?
> 
> 
> The issue is identifying the connection.
> 
> Lets say A calls B through intermediary I. Consider the SDP in the 200 
> OK from I to A. The SDP will indicate to A to open a TCP connection to a 
> well known port on the single IP address of the intermediary I. This is 
> the same port and IP address handed out to every other client. If A is 
> active, and initiates the connection to I, when I receives the 
> connection request, how does it know its associated with the call that 
> was just made? The destination IP provides no information - its to the 
> well known address and port. The source address is useless because of 
> NAT. So, how does it know?
> 

At the risk of appearing even more hopelessly dense, why does it need to 
know?

If I understand your proposal correctly, it must read the connection-ID 
from the connection after accepting it, which means it cannot decide 
whether or not to accept the connection based on this information. For 
cpim-msgfmt sessions, it does not need to know what connection a message 
arrived on to associate the message with a session--the To: (or msg-ID, 
or whatever) serves that purpose.

Is this just so it can figure out when to stop listening for new 
connections?

> It can't, unless it uses a distinct port for each connection, which 
> doesnt work with intermediaries. And thus our dilemma.
> 
> -Jonathan R.
> 
> 



From bcampbell@dynamicsoft.com  Thu Nov 14 18:10:39 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16290
	for ; Thu, 14 Nov 2002 18:10:38 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gAENAYU1054059;
	Thu, 14 Nov 2002 17:10:35 -0600 (CST)
Message-ID: <3DD42D60.7050903@dynamicsoft.com>
Date: Thu, 14 Nov 2002 17:10:24 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Jonathan Rosenberg ,
        Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD3BA57.1BFC0BA0@cisco.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 5617
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: 

Paul Kyzivat wrote:
> 
> Ben Campbell wrote:
> 
>>> > But I'm not sure this is workable even with that limitation. I have a
>>> > hunch there is still a race condition when one end will think there
>>> > is a connection and attempt to reuse it, while the other end has
>>> > decided there is no session using the connection and tries to drop it
>>> > or establish a new one. This is tricky, and probably impossible to
>>> > decide in general except with respect to a precise rule for reuse.
>>> > But here is one case that seems simpler than some others:
>>
>>So, what happens if you attempt to resuse a connection that is dropped?
>>Won't that fact quickly become apparent? Can't we just reconnect?
>>
>>There may be a complication here in that comedia says you can't just
>>reconnect, you must renegotiate SDP--but scenario under discussion
>>results from an SDP notification, so I am not sure if that requirement
>>is constrainint here.
> 
> 
> Comedia currently says you start listening for a connection when you need one, and you stop listening when you get one. And after you stop, you can recycle the port on which you were listening for the connection. And the connection you got then isn't dropped until a BYE or reinvite.
> 
> This logic doesn't work for intermediaries that are multiplexing connections. They need a different rule for when to reuse a connection and when to create one. This is where the race conditions come in.

OK, I _may_ be starting to understand--after the server recycles the 
port, the client cannot just assume that port is still valid for the 
same purpose--heck, it could recycle it for a purpose completely 
unrelated to message sessions. That would explain the comedia 
prohibition against reopening closed connections without a new sdp 
negotiation. But I am not sure I understand why this is different for an 
intermediary and an endpoint.

> 
> 
>>>So, whats the problem? Well, all intermediaries need to maintain a
>>>routing table, which tells them what to do with incoming messages. That
>>>table tells them that if an IM arrives on some specific connection, with
>>>a specific URI/identifier in the outer envelope, to forward to a
>>>different connection with a different URI/identifier in the outer
>>>envelope. THis means that the intermediary has to associate each
>>>connection with a specific dialog used to set it up (since the dialog is
>>>used to exchange the SDP that contains the URI/identifiers). How is this
>>>association done?
>>
>>I am not sure I understand the difficulty here. These intermediaries
>>surely must be SIP aware, if they are in the business of re-writing SDP.
>>Additionally, it seems to me that they must be dialog stateful devices.
>>Why can't they just maintain a table that associates a dialog with a
>>session, and the session with a connection, where the association
>>between session and connection is many-to-one?
>>
>>If we get SDP describing a new _session_, it will contain address, port,
>>and direction information. A device can check the connection table to
>>determine whether it currently has a connection opened to that
>>particular address and port, can't it? If so, why can't it just start
>>interleaving messages for the new session onto the existing connection?
>>Maybe I am being dense, but I do not understand what problem the
>>connection-id mechanism below is trying to solve.
> 
> 
> That's ok on the inbound side, multiplexing traffic. But its not sufficient on the outbound side, where the traffic needs to be demultiplexed. On that side, the intermediary needs to have a mapping between something in the multiplexed media stream and the outbound session.

Certainly--and that something is, at least for cpim-msgfmt sessions, the 
To header in the envelope (or a MsgID assuming we change that bit.) That 
header tells us all by itself which session a message is associated 
with. I'm not sure it really matters what connection it arrived over. 
Even if you were to send messages on a given session across more than 
one connection, the receiving intermediary could still demux them based 
on the MsgID. (I am _not_ advocating doing that, btw). That intermediary 
would then need to associate the inbound MsgID with an outbound session, 
with an associated connection.

> 
> 
>>>Right now, its done with the SOURCE ADDRESS. That is, the SDP sent out
>>>by A in your example contains the source IP/port it will make the
>>>connection from. So, when I1 receives the connection request, it can
>>>determine the source, and then match it to the dialog. The problem is,
>>>this doesn't work at all through NAT. If you don't want to use the
>>>source to demux, the intermediary can arrange for each connection to
>>>occur on a different port, and that means no reuse. So, we have a real
>>>problem.
>>>
>>
>>I will note that comedia says you should _not_ use source address this
>>way unless you are certain your network is free of the blight of NATs.
>>
>>But since a connection can carry more than one session, it makes no
>>sense to try to tie a connection request to a particular dialog. The
>>cpim-msgfmt session draft has its own mechanism for identifying the
>>session. Why can a participating device not relate that to the dialog
>>that set upt he session in the first place?
> 
> 
> What you have done is identify the mismatch between the semantics of comedia and the semantics of cpim.
> 
> comedia was faced with the need to set up the media stream without any constraint over the content of that stream. It leads to a different solution that isn't ideal here. (In fact, it may not be ideal for anything.)



From pkyzivat@cisco.com  Thu Nov 14 18:35:32 2002
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 SAA16404
	for ; Thu, 14 Nov 2002 18:35:32 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAENZcbZ013876;
	Thu, 14 Nov 2002 18:35:42 -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 AAU90231;
	Thu, 14 Nov 2002 18:40:11 -0500 (EST)
Message-ID: <3DD43334.E3A90B11@cisco.com>
Date: Thu, 14 Nov 2002 18:35:16 -0500
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: Ben Campbell 
CC: Jonathan Rosenberg ,
        Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD4236B.6070600@dynamicsoft.com> <3DD42816.5020906@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 4991
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: 

Ben,

OK, it has been a long time since the details of this were discussed on the list, so I will try to summarize them. This is just for the general case of comedia, nothing to do with simple.

Assume that we have a server (perhaps a gateway) that is going to terminate a bunch of media sessions using comedia. It will be getting lots of concurrent invites with comedia SDP, and responding in kind. It must decide what to put in the sdp it answers with, so that when the connections are made it will be able to associate the connection with corresponding sdp media line.

Now we presume that this must work independent of the content of the media stream - thats a groundrule here. So what can it use to associate an incoming connection? The only thing that works consistently is to assign a separate listening port for media session. If it does this, when the connection comes in it knows that it must be for the session it was assigned to. 

Another possibility we considered was to use a common port for receiving some or all of the incoming connections. But if that is done then some other characteristic of the incoming connection must be used to distinguish one from another. That is where specifying the source address and port in the sdp come in. If they are specified, and used, and unique, and not messed up by NATs, then they can be used to associate connections with sessions. But this list of conditions is so difficult to achieve that this is not a generally practical solution.

So we are back to assigning a separate listening port for each expected incoming session. Now comes another question: how long must the server keep listening on this port? The simple answer is that it must listen as long as there is any possibility that the other end might attempt to connect to it. A simple answer would be to say that listening should continue on the port until the session is ended via a reinvite or a bye. If a single port could be used to listen for all pending connections then this would be a reasonable thing to do. But in a server with many sessions this is an expensive answer. It consumes twice as many ports, and resources to listen on those ports. In the case of Java servers prior to java 1.4 this requires a thread for each. (Its not so bad in 1.4.)

So to make this tolerable, we arranged the connection setup protocol so that when a server doesn't have a connection it knows whether it must listen for connections, and when it gets a connection it knows it doesn't have to listen for more. On average it has about one port/socket per session - either listening for a connection, or waiting for input on a connection. This also means that the ports themselves can be recycled as soon as they will no longer be needed, reducing the total number of ports needed.

One downside (if you consider it that) is that you can only change the connection status by sending a reinvite. I don't consider this a bad thing.

Another downside, which we are seeing here, is that there is no way to multiplex traffic from two or more sessions over a single connection, even if the protocol being carried has enough data to support that demultiplexing. Doing so would require somehow enhancing the sdp so that connections can be identified globally, and so an intent to use a specific preexisting connection could be negotiated. This is probably possible.

But then there comes the problem of deciding when a shared connection can be shut down. (This has to be done via offer/answer exchanges in sdp, because there is no other avaiable mechanism.) This would be subtle, and probably would require some special endpoint behavior, like reinviting with an unshared connection if the use of a shared connection is refused. But that will only work when the connection is between two endpoints. When the connection involves an intermediary, especially between a pair of intermediaries, it is either going to break entirely or be very complex, because they can't control whether reinvites are sent.

Does that make the problem clearer?

Now if you change the groundrules, and assume that there is data in the media stream that can frame media from different media sessions and also provide data that can be correlated with a media stream description in sdp, you can come up with a connection establishment protocol that is very different.

Maybe we need to talk about this in Atlanta.

	Paul

Ben Campbell wrote:
> 
> At the risk of appearing even more hopelessly dense, why does it need to
> know?
> 
> If I understand your proposal correctly, it must read the connection-ID
> from the connection after accepting it, which means it cannot decide
> whether or not to accept the connection based on this information. For
> cpim-msgfmt sessions, it does not need to know what connection a message
> arrived on to associate the message with a session--the To: (or msg-ID,
> or whatever) serves that purpose.
> 
> Is this just so it can figure out when to stop listening for new
> connections?

From jdrosen@dynamicsoft.com  Fri Nov 15 13:18:45 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19639
	for ; Fri, 15 Nov 2002 13:18:45 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAFIIlYH000946;
	Fri, 15 Nov 2002 13:18:47 -0500 (EST)
Message-ID: <3DD53A84.5090801@dynamicsoft.com>
Date: Fri, 15 Nov 2002 13:18:44 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell 
CC: Paul Kyzivat , Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD3BA57.1BFC0BA0@cisco.com> <3DD42D60.7050903@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3913
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: 


Ben Campbell wrote:

>>
>> Comedia currently says you start listening for a connection when you 
>> need one, and you stop listening when you get one. And after you stop, 
>> you can recycle the port on which you were listening for the 
>> connection. And the connection you got then isn't dropped until a BYE 
>> or reinvite.
>>
>> This logic doesn't work for intermediaries that are multiplexing 
>> connections. They need a different rule for when to reuse a connection 
>> and when to create one. This is where the race conditions come in.
> 
> 
> OK, I _may_ be starting to understand--after the server recycles the 
> port, the client cannot just assume that port is still valid for the 
> same purpose--heck, it could recycle it for a purpose completely 
> unrelated to message sessions. That would explain the comedia 
> prohibition against reopening closed connections without a new sdp 
> negotiation. But I am not sure I understand why this is different for an 
> intermediary and an endpoint.

An intermediary wants to receive multiple media sessions on the same 
port. An endpoint doesn't (or may not).

> 
>>
>>
>>>> So, whats the problem? Well, all intermediaries need to maintain a
>>>> routing table, which tells them what to do with incoming messages. That
>>>> table tells them that if an IM arrives on some specific connection, 
>>>> with
>>>> a specific URI/identifier in the outer envelope, to forward to a
>>>> different connection with a different URI/identifier in the outer
>>>> envelope. THis means that the intermediary has to associate each
>>>> connection with a specific dialog used to set it up (since the 
>>>> dialog is
>>>> used to exchange the SDP that contains the URI/identifiers). How is 
>>>> this
>>>> association done?
>>>
>>>
>>> I am not sure I understand the difficulty here. These intermediaries
>>> surely must be SIP aware, if they are in the business of re-writing SDP.
>>> Additionally, it seems to me that they must be dialog stateful devices.
>>> Why can't they just maintain a table that associates a dialog with a
>>> session, and the session with a connection, where the association
>>> between session and connection is many-to-one?
>>>
>>> If we get SDP describing a new _session_, it will contain address, port,
>>> and direction information. A device can check the connection table to
>>> determine whether it currently has a connection opened to that
>>> particular address and port, can't it? If so, why can't it just start
>>> interleaving messages for the new session onto the existing connection?
>>> Maybe I am being dense, but I do not understand what problem the
>>> connection-id mechanism below is trying to solve.
>>
>>
>>
>> That's ok on the inbound side, multiplexing traffic. But its not 
>> sufficient on the outbound side, where the traffic needs to be 
>> demultiplexed. On that side, the intermediary needs to have a mapping 
>> between something in the multiplexed media stream and the outbound 
>> session.
> 
> 
> Certainly--and that something is, at least for cpim-msgfmt sessions, the 
> To header in the envelope (or a MsgID assuming we change that bit.) That 
> header tells us all by itself which session a message is associated 
> with. I'm not sure it really matters what connection it arrived over. 

It doesn't. But, it matters what connection it goes TO. And thus the 
problem I've been pointing to, which is how a server knows which session 
an incoming TCP connection is associated with. It cares, since it needs 
to send IMs onto the right connections.

-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


From jdrosen@dynamicsoft.com  Fri Nov 15 16:47:56 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20233
	for ; Fri, 15 Nov 2002 16:47:56 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAFLlvYH001056;
	Fri, 15 Nov 2002 16:47:57 -0500 (EST)
Message-ID: <3DD56B8A.50507@dynamicsoft.com>
Date: Fri, 15 Nov 2002 16:47:54 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ryan Chapman 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Presence & SRV - Problem solved?
References: <0FD1B48D522C08408A3CFD737CD35B5512037A@thunder.vancouver.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3246
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: 

I'm not sure this ever got answered. Response inline.

Ryan Chapman wrote:
 > Hello all,
 >
 > I'm writing a SIMPLE-based presence infrastructure, but I'm having
 > some difficulty determining exactly how to deal with a presence URI
 > (e.g., pres:somebody@somewhere.com).
 >
 > In the CPIM draft, we are told to query _im._sip.example.com for
 > im:fred@example.com, and then that the "choice of IM transfer
 > protocol is a local configuration option for each system."

Right. Meaning, the somewhere.com domain decides which SRV entries to 
place into DNS - _im._sip.somewhere.com and _im._apex.somewhere.com. The 
sender gets to choose amongst those as it sees fit.

 > Given
 > this, which SRV RR should my SIP layer query?

If you are always trying to send using SIP, it would be 
_pres._sip.somwehere.com.


 >  If I translate my
 > presence URI to a SIP URI as specified (somewhere!) in the mailing
 > archive

Yes, this is something that needs to be described somewhere. I think it 
belongs in the cpim mapping draft.


 > by simply replacing "pres" with "sip", then what good was my
 > first SRV lookup?  In other words, my SIP layer would simply lookup
 > _sip._udp.example.com, ignoring whatever results my previous query
 > returned.

Well, thats an excellent question.

Clearly, one thing you get from the initial lookup is whether or not the 
terminating system even supports SIP. One approach is that you use the 
initial query just for that purpose, discard the resulting records, 
translate the SIP URI using some local mechanism (swap pres for sip in 
the scheme), and then use SIP mechanisms.

A second approach would have the translation done by the recipient 
domain. To some degree, one might argue that URI translation is 
something that only the server in the relevant domain can do. That is, 
pres:user@domain.com is a URI that only domain.com should ever try to 
translate. In that case, the appropriate approach is this:

1. client looks up _pres._sip.somewhere.com in DNS
2. client takes the resulting records, and sends the request there. The 
r-uri remains a pres URI.
3. the somewhere.com proxy server understands the pres URI, and applies 
some local policy to translate the URI.
4. Its all sip from there

The drawback to this second approach is that the proxy has to understand 
the pres URI. Arguably, it always will, if someone got a hold of a pres 
URI in that domain in the first place...

 > My primary goal is to have my presence server be decoupled from our
 > proxy/registrar, so the presence URI should send the message to a
 > different location than a normal SIP URI would.

Well, that you can always do. Generally a particular large domain will 
have a single proxy server that is the "front line" for requests. Its 
job is to route requests to the appropriate servers. For example, 
proxying a SUBSCRIBE request to a presence server.

-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


From bcampbell@dynamicsoft.com  Fri Nov 15 19:24:02 2002
Received: from magus.nostrum.com (magus.nostrum.com [66.119.225.66])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20775
	for ; Fri, 15 Nov 2002 19:24:01 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gAG0NsU1067699;
	Fri, 15 Nov 2002 18:23:54 -0600 (CST)
Message-ID: <3DD59011.6070206@dynamicsoft.com>
Date: Fri, 15 Nov 2002 18:23:45 -0600
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Jonathan Rosenberg ,
        Simple 
Subject: Re: [Simple] Re: comedia in draft-campbell-simple-*-sessions-00.txt
References: <200210291117.GAA27770@ietf.org> <3DBF2970.22BFCCF9@cisco.com> <3DC41F3C.1010301@dynamicsoft.com> <3DC54ECF.4040507@dynamicsoft.com> <3DC69A4F.245BB284@cisco.com> <3DC94A52.4060505@dynamicsoft.com> <3DD2CCB5.7070703@dynamicsoft.com> <3DD4236B.6070600@dynamicsoft.com> <3DD42816.5020906@dynamicsoft.com> <3DD43334.E3A90B11@cisco.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 5455
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: 

Jonathan/Paul

Apologies for my being extra dense this week. Inspiration came to me 
while trying to explain the controversy to a co-worker. I now understand 
the issue with connection identification. I had missed the issue of 
knowing what connection to send an outgoing message on if the connection 
was opened by the opposite end.

We definitely need to discuss it in Atlanta.

Paul Kyzivat wrote:
> Ben,
> 
> OK, it has been a long time since the details of this were discussed on the list, so I will try to summarize them. This is just for the general case of comedia, nothing to do with simple.
> 
> Assume that we have a server (perhaps a gateway) that is going to terminate a bunch of media sessions using comedia. It will be getting lots of concurrent invites with comedia SDP, and responding in kind. It must decide what to put in the sdp it answers with, so that when the connections are made it will be able to associate the connection with corresponding sdp media line.
> 
> Now we presume that this must work independent of the content of the media stream - thats a groundrule here. So what can it use to associate an incoming connection? The only thing that works consistently is to assign a separate listening port for media session. If it does this, when the connection comes in it knows that it must be for the session it was assigned to. 
> 
> Another possibility we considered was to use a common port for receiving some or all of the incoming connections. But if that is done then some other characteristic of the incoming connection must be used to distinguish one from another. That is where specifying the source address and port in the sdp come in. If they are specified, and used, and unique, and not messed up by NATs, then they can be used to associate connections with sessions. But this list of conditions is so difficult to achieve that this is not a generally practical solution.
> 
> So we are back to assigning a separate listening port for each expected incoming session. Now comes another question: how long must the server keep listening on this port? The simple answer is that it must listen as long as there is any possibility that the other end might attempt to connect to it. A simple answer would be to say that listening should continue on the port until the session is ended via a reinvite or a bye. If a single port could be used to listen for all pending connections then this would be a reasonable thing to do. But in a server with many sessions this is an expensive answer. It consumes twice as many ports, and resources to listen on those ports. In the case of Java servers prior to java 1.4 this requires a thread for each. (Its not so bad in 1.4.)
> 
> So to make this tolerable, we arranged the connection setup protocol so that when a server doesn't have a connection it knows whether it must listen for connections, and when it gets a connection it knows it doesn't have to listen for more. On average it has about one port/socket per session - either listening for a connection, or waiting for input on a connection. This also means that the ports themselves can be recycled as soon as they will no longer be needed, reducing the total number of ports needed.
> 
> One downside (if you consider it that) is that you can only change the connection status by sending a reinvite. I don't consider this a bad thing.
> 
> Another downside, which we are seeing here, is that there is no way to multiplex traffic from two or more sessions over a single connection, even if the protocol being carried has enough data to support that demultiplexing. Doing so would require somehow enhancing the sdp so that connections can be identified globally, and so an intent to use a specific preexisting connection could be negotiated. This is probably possible.
> 
> But then there comes the problem of deciding when a shared connection can be shut down. (This has to be done via offer/answer exchanges in sdp, because there is no other avaiable mechanism.) This would be subtle, and probably would require some special endpoint behavior, like reinviting with an unshared connection if the use of a shared connection is refused. But that will only work when the connection is between two endpoints. When the connection involves an intermediary, especially between a pair of intermediaries, it is either going to break entirely or be very complex, because they can't control whether reinvites are sent.
> 
> Does that make the problem clearer?
> 
> Now if you change the groundrules, and assume that there is data in the media stream that can frame media from different media sessions and also provide data that can be correlated with a media stream description in sdp, you can come up with a connection establishment protocol that is very different.
> 
> Maybe we need to talk about this in Atlanta.
> 
> 	Paul
> 
> Ben Campbell wrote:
> 
>>At the risk of appearing even more hopelessly dense, why does it need to
>>know?
>>
>>If I understand your proposal correctly, it must read the connection-ID
>>from the connection after accepting it, which means it cannot decide
>>whether or not to accept the connection based on this information. For
>>cpim-msgfmt sessions, it does not need to know what connection a message
>>arrived on to associate the message with a session--the To: (or msg-ID,
>>or whatever) serves that purpose.
>>
>>Is this just so it can figure out when to stop listening for new
>>connections?
> 



From jdrosen@dynamicsoft.com  Sat Nov 16 00:14:32 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21560
	for ; Sat, 16 Nov 2002 00:14:32 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAG5EWYH001197;
	Sat, 16 Nov 2002 00:14:33 -0500 (EST)
Message-ID: <3DD5D436.5080800@dynamicsoft.com>
Date: Sat, 16 Nov 2002 00:14:30 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] 3GPP Messaging requirements
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945054@esebe013.ntc.nokia.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 3321
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: 

Aki,

My apologies for not taking a look at this till now.

This is a good collection of requirements. As you know, I think most of 
them are addressed already. A few comments on some of them:

> It MUST be possible to use a single address to identify the recipient
>    or sender of an instant message or a member in a message session,
>    irrespective of the messaging system.

I wasn't sure what to make of this requirement. Is this asking for 
something new from SIP? You can put whatever kind of address you want 
into the From field of a MESSAGE request or an INVITE to set up a session...

>  Additionally, it MUST be possible to send the entire message body, or
>    parts of the body in a way that allows the recipient to choose
>    between receivng the body and ignoring it.

parts of the body? What does that mean? Do you mean I can ask to receive 
the top half of a jpeg only? I hope not.

If you are just talking about receiving parts on a body-by-body basis, 
clearly indirection is the right solution for this.

> 3.3 Data Manipulation and Management Requirements

I suspect all of these will be met by the conference control protocol 
work going on in sipping.

> It MUST be possible to divert or block instant messages as part of a
>    user configurable option.  Such mechanisms MUST support instant
>    message diversion based on sender address, message size, message
>    priority, message subject, message class and message content type.

what is message class?

> It is proposed that the SIMPLE Working Group evaluates the
>    requirements presented in this document and incorporates the relevant
>    ones in its current work items.  Those requirements possibly falling
>    out of the scope of the SIMPLE WG should find a more suitable home,
>    possibly also in other standardization bodies.

As I commented at the last IETF, I would propose that those requirements 
which do belong to SIMPLE get folded into our general work item on 
advanced IM requirements.

-Jonathan R.


aki.niemi@nokia.com wrote:
 > Hi All,
 >
 > Like promised in Yokohama, there is now a document available
 > describing the 3GPP requirements to Instant Messaging. It lists
 > requirements for both pager mode and session mode IM. Here's a link
 > for your convenience:
 >
 > http://www.ietf.org/internet-drafts/draft-niemi-simple-im-wireless-re-
 > qs-00.txt
 >
 > I'd especially like to draw your attention to the requirements for
 > session mode IM, as well as the requirements for data manipulation.
 >
 > Note also, that when 3GPP talks about session based messaging, there
 > is a strong flavor of multiparty sessions to it. The conferencing
 > aspects, and the chat-room type aspects of this document should be
 > considered already in the current message session work.
 >
 > Cheers, Aki
 >
 > _______________________________________________ simple mailing list
 > simple@mailman.dynamicsoft.com
 > http://mailman.dynamicsoft.com/mailman/listinfo/simple
 >

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


From jdrosen@dynamicsoft.com  Sat Nov 16 00:34:39 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21671
	for ; Sat, 16 Nov 2002 00:34:39 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAG5YeYH001201;
	Sat, 16 Nov 2002 00:34:40 -0500 (EST)
Message-ID: <3DD5D8ED.7070704@dynamicsoft.com>
Date: Sat, 16 Nov 2002 00:34:37 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mikko.lonnfors@nokia.com
CC: pkyzivat@cisco.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 6560
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: 

I think the basic idea behind these drafts is a good one. There is clear 
value in knowing, at a watcher, more details on each of the contact 
addresses in the presence document.

There are a bunch of issues here which require further discussion:


1. Assuming the watcher "picks" one of the contact addresses, and 
decides to communicate with it by sending it an INVITE, how should that 
INVITE look? If the URI in the contact element is the AOR of the user, 
does the watcher need to add caller preferences (Require-Contact) in 
order to reach that specific UA instance?

More generally, what is the meaning of these capabilities attributes? 
Does it mean that there exists some UA behind that URI with those 
capabilities? Does it mean that any UA reached with that URI is 
guaranteed to have those capabilities? I think what you want is the 
former. I also think that you are not going to be able to put the actual 
Contact URI into the PIDF doc; it will need to be some kind of AOR, but 
one that routes to a specific UA instance.


2. One of the things I am not particularly fond of in the current caller 
prefs spec is the limitation on the capabilities predicate (conjunctive 
normal form only). That restriction exists because of the syntactic 
limitations of using contact parameters, and of the need for a simple 
matching algorithm in proxies to support routing. I would like to leave 
the door open for much more complex capabilities documents, which can be 
uploaded by a UA and used for other things, NOT call routing 
necessarily. Here is a good example of a use case that does not need to 
suffer the limitations of caller prefs. It would be nice if we can be 
more general.

w3c has done a lot of work in describing capabilities (CC/PP, RDF), all 
of which is XML-based. I wonder if there is a better fit here to use 
that kind of syntax?


-Jonathan R.

mikko.lonnfors@nokia.com wrote:
> Hi,
> 
> inline
> 
> 
>>-----Original Message-----
>>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
>>Sent: 29 October, 2002 17:06
>>To: simple@mailman.dynamicsoft.com
>>Subject: Re: [Simple] FW: I-D
>>ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
>>
>>
>>mikko.lonnfors@nokia.com wrote:
>>
>>>Hi,
>>>
>>>New draft is now available. Basically draft presents a 
>>
>>solution for the requirements presented in 
>>draft-kyzivat-simple-prescaps-reqts-00.txt.
>>
>>>All comments are welcome.
>>
>>Obviously Mikko and I have been cooperating on this. We were 
>>both interested in the subject. I thought it would be helpful 
>>to be clear about the requirements rather than jumping 
>>directly to a proposed solution, so I posted a requirements 
>>draft last week. Since then I have been waiting for Mikko to 
>>submit this in order to have more fodder for discussion.
>>
>>There is already a work item to produce a SIP-specific 
>>profile for PIDF. I consider these drafts to be a *partial* 
>>response to that work item. I realize there is a desire for 
>>some addition generalized status values beyond open/closed, 
>>such as busy. That is a minefield, and we have chosen not to 
>>address it. Instead, we are focusing on some attributes that 
>>should be less controversial because they are drawn from the 
>>callerprefs draft, whose basic concepts have been accepted 
>>for a long time. (I am open to discussion about whether these 
>>specific drafts should be expanded to cover the more general 
>>requirement, or whether that should be left separate.)
>>The assertion of these drafts is that capabilities a UAS can 
>>specify when registering are information that is equally 
>>important in a presence document. I believe Mikko is most 
>>concerned with supported media. I also consider that to be of 
>>major importance, but I also believe all the others are of 
>>potential value in a presence document.
> 
> 
> This topic was first discussed in IMPP mailing list related to PIDF communication means. After some discussion it was concluded that this work might fit better to SIMPLE WG agenda. 
> I would also like to see some comments to the requirements draft. A small problem in writing that was that there were no requirements for callerpreferences and because of that we have tried to put quite a lot motivational and explanative text into requirements. It would be very helpful to hear also other people comments to this. If the overall idea is acceptable then the exact requirements should be quite clear. At least requirements 1, 2, and 3 should be quite self-evident (I hope). Requirement 4 is now marked with SHOULD level and I would like to hear if it would be good idea to move it to MUST level. Also I am not sure we have been able to collect all relevant requirements so if something seems to be missing please let us know.  
> 
> 
>>The callerprefs draft is still itself in a state of flux. The 
>>work here should remain dependent on the outcome of that 
>>work. But I believe it would be helpful to begin progressing 
>>these documents now.
> 
> 
> We have tried to keep this draft as independent of callerprefs as possible but there is of course quite heavy dependency between these two. 
> 
> Here are some open items for solution draft:
> - At a moment draft allows use of extension in two places inside PIDF document (inside  and . Should we specify the exact location where this extension can be used within PIDF document.
> - We went through 2 or 3 different XML schemas before ending up with current one. Obviously there is lot of different options and if someone thinks there exists better alternatives then this can be discussed.
> - We ended up using negated attribute inside  elements to indicate whether value is supporter or not supported. There are also other alternatives to represent this. One alternative would be to replace  with either  or  element.
> 
> - Mikko
> 
> 
>>	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
> 

-- 
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


From jdrosen@dynamicsoft.com  Sat Nov 16 01:19:52 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21851
	for ; Sat, 16 Nov 2002 01:19:51 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAG6JqYH001216;
	Sat, 16 Nov 2002 01:19:53 -0500 (EST)
Message-ID: <3DD5E384.3090103@dynamicsoft.com>
Date: Sat, 16 Nov 2002 01:19:48 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 6130
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: 

This draft is a good start.

I would very much like to do this as generally as possible. Clearly, 
there are a number of different ways to design a protocol to meet the 
requirements in the data-req draft. They range from the totally specific 
to totally general:

* PROTOCOL OPTION 1: We design a protocol that JUST does whats in the 
requirements doc, nothig more, nothing less. Its simple, but it only 
works for buddy lists and authorization policy. It won't work for 
conference policy, for example.

* PROTOCOL OPTION 2: Markus' draft. Generalize option 1 a bit. Focus on 
lists of things, and define a general protocol for creating, modifying 
and managing lists. Works for buddy lists and conferencing too, so long 
as all they do is manage lists.

* PROTOCOL OPTION 3: Generalize Markus' draft further. Assume that 
anything we want to manipulate can be represented in XML. Conference 
policies might be modelled as really complex XML documents. Media 
policies too. A buddy list is an XML document. And so on. The protocol, 
then, is a general tool for remote editing of XML documents. Using 
things like XPath, you can address a particular node, add elements, 
modify them, etc. The underlying application (conferencing, buddy list) 
validates the changes against its schemas, and assignes semantics to the 
documents.


There are probably more sub-options between 2 and 3. For example, we cna 
introduce restrictions on the types of XML documents we can manipulate, 
the types of changes we can make, and so on.

Where do draw the line?

Clearly, we want something simple so that we can be done soon. Simple is 
always good.

However, I would also like a single protocol that can meet the 
requirements here, AND the requirements for conference policy control 
and media policy control that are evolving in SIPPING. Conference policy 
is complex enough that a simple list won't suffice. So, I think we need 
a bit more that what Markus has defined.

Thoughts?

-Jonathan R.

Markus.Isomaki@nokia.com wrote:
 > Hi,
 >
 > The following draft is now available in the I-D directories. It is an
 > initial attempt to specify a list management protocol on an abstract
 > level (only semantics, no syntax). The proposal is made based on the
 > requirements stated in "draft-ietf-simple-data-req-00". The draft is
 > still quite drafty, but the main points should be visible.
 >
 > The main idea is that many applications (for instance presence and
 > conferencing) require lists that should be configurable by a client
 > terminal. It would be useful to define a standard protocol to handle
 > list manipulation (for SIP-applications), so that it could be
 > "plugged in" to any application needing it.
 >
 > I hope comments to the approach and to the actual abstract protocol.
 > If this is a good enough start, it could be used as a basis for a WG
 > document. After that would be reasonably stable, a mapping to some
 > real syntax could be made and that specifation should be in standards
 > track.
 >
 > Markus
 >
 >
 >> -----Original Message----- From: ext Internet-Drafts@ietf.org
 >> [mailto:Internet-Drafts@ietf.org] Sent: 04 November, 2002 17:05
 >> Subject: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt
 >>
 >>
 >> A New Internet-Draft is available from the on-line Internet-Drafts
 >> directories.
 >>
 >>
 >> Title		: Semantic Description of SIMPLE List Manipulation
 >> Operations Author(s)	: M. Isomaki et al. Filename	:
 >> draft-isomaki-simple-list-man-sem-00.txt Pages		: 13 Date		:
 >> 2002-11-1  In SIMPLE based presence and messaging applications, it
 >> is necessary for  the user to be able to configure a number of
 >> pieces of information. One of the most common types of information
 >> is a list of URIs. List management is useful outside the scope of
 >> SIMPLE as well, for instance in conferencing. There are many
 >> reasons why it would be beneficial to manage the lists in a similar
 >> fashion regardless of the application. Before the selection of the
 >> actual protocol(s) to manage the lists there is a need to describe
 >> their semantics on an abstract level. This document proposes the
 >> semantics for SIMPLE list manipulation protocol.
 >>
 >> A URL for this Internet-Draft is:
 >> http://www.ietf.org/internet-drafts/draft-isomaki-simple-list-
 >
 > man-sem-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-isomaki-simple-list-man-sem-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-isomaki-simple-list-man-sem-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.
 >

-- 
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


From jdrosen@dynamicsoft.com  Sat Nov 16 01:48:30 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22017
	for ; Sat, 16 Nov 2002 01:48:29 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.85])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAG6mUYH001239;
	Sat, 16 Nov 2002 01:48:31 -0500 (EST)
Message-ID: <3DD5EA3A.2040702@dynamicsoft.com>
Date: Sat, 16 Nov 2002 01:48:26 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Comments on Data Manipulation Requirements
References: <2038BCC78B1AD641891A0D1AE133DBB7FE6FC1@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3600
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: 

inline.

hisham.khartabil@nokia.com wrote:
 > Hi,
 >
 > Section 5.1 REQ 2: This requirement is talking about rejecting a
 > subscriber not belonging in an "Allowed Watchers" list. Should
 > rejecting only be based on subscribers belonging to "Blocked
 > Watchers". In this case, REQ 2 would be changed to talk about adding
 > that subscriber to a "Pending Watchers" list and accepting the
 > subscription. (Or do we need both REQ 2 as it stands and REQ 2 as I
 > suggest?)

I'm not sure I fully understand the question.

I think you are asking about pending watchers. The current acceptance 
requirements don't talk about pending cases. I would add these as 
separate requirements, something like:

REQ XX: It MUST be possible for the acceptance policy to specify that if 
a user is not on a blocked or allowed list, they are pending, such that 
a watcherinfo notification is used to query authorization.

I don't think it makes sense to have an explicit "pending list".


 >
 > REQ 7.7: This is similar to REQ 7 in section 4, should both
 > requirements carry the same strength (MUST or SHOULD)?

Good catch. Generally, I need to make these more consistent.


 >
 > REQ 7.8: should it continue specifying that "If the URI cannot be
 > allocated (because it already exists, for example), it MUST be
 > possible to inform the client of the failure, and the reason for it"?
 > This aligns it with REQ 2 in section 4.

Yes.

 >
 > REQ 7.9: This is similar to REQ 3 in section 4, should both
 > requirements carry the same strength (MUST or SHOULD)? REQ 7.9:
 > should it continue specifying that this happens in case user does not
 > provide one? This aligns it with REQ 3 in section 4.

Yes.

 >
 > Section 5.2 REQ 4: I don't quite understand this one. Is it talking
 > about filters in subscribe specifying higher rate that the minimum?

Its talking about filters in the sense of:
http://www.ietf.org/internet-drafts/draft-moran-sipping-filter-reqs-00.txt

so, if someone asks to be notified about changes only to my geolocation, 
I can reject that subscription.


 >
 > Section 5.3 REQ 3: This can result in a NOTIFY with no tuples. Is
 > that Ok? should the NOTIFY be sent? if so, what does it mean?

I think thats a level deeper than the requirements need to address. I 
suspect that, if the filtering implied that there was no presence 
document left, the NOTIFY would not be sent.

 >
 > REQ 4: Tuples cannot be meaningfully identified. Communication means
 > might be a better choice.

Well, PIDF doesn't really define communications means either.

This is something that the lonnfors prescaps draft could help us with. 
It would provide a meaningful way to identify tupples. I could specify 
something like "don't report tuples that support voice calls".

 >
 > Back to section 3:
 >
 > It states that a PA can receive a subscription with presence list
 > uri. Are we assuming that a PA is a PLS? Does a PA's definition allow
 > for this? This is irrelevant to this draft anyway.

Its a bit of a stretch of the term PA, since we are applying it to 
something whcih can terminate the presence event package or the 
presence.collection package. Clearly the latter is outside the 
definition provided in the baseline presence spec.

-Jonathan R.

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


From pkyzivat@cisco.com  Sat Nov 16 11:05:26 2002
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 LAA23637
	for ; Sat, 16 Nov 2002 11:05:26 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAGG5eS7008044;
	Sat, 16 Nov 2002 11:05:40 -0500 (EST)
Received: from cisco.com (rtp-vpn2-716.cisco.com [10.82.242.204])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAU99480;
	Sat, 16 Nov 2002 11:10:11 -0500 (EST)
Message-ID: <3DD66CBC.A986100@cisco.com>
Date: Sat, 16 Nov 2002 11:05:16 -0500
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: mikko.lonnfors@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com> <3DD5D8ED.7070704@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3524
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: 


Jonathan Rosenberg wrote:
> 
> I think the basic idea behind these drafts is a good one. There is clear
> value in knowing, at a watcher, more details on each of the contact
> addresses in the presence document.
> 
> There are a bunch of issues here which require further discussion:

Yup. We were expecting discussion.

> 
> 1. Assuming the watcher "picks" one of the contact addresses, and
> decides to communicate with it by sending it an INVITE, how should that
> INVITE look? If the URI in the contact element is the AOR of the user,
> does the watcher need to add caller preferences (Require-Contact) in
> order to reach that specific UA instance?

My assumption has been that if the watcher picks one of the contact addresses, he then just sends the invite to it. It is up to the publisher of presence to arrange things so that does the right thing. The publisher can identify separate tuples each with a particular set of capabilities, and yet provide a single AOR for all of them. In that case it is in effect promising to provide a smart proxy at the AOR that can do the right thing.

Or the publisher can provide an actual individual contact address for each tuple. In that case it is promising that the contact addresses are usable by presence subscribers.

In the end, the publisher is in the driver's seat, and publishing what it willing to expose and what it thinks will be useful to subscribers. There clearly is a tradeoff  between those two things, and the publisher is the one that ought to decide.

Whether the subscriber should put callerprefs on the invite is a good question. If the algorithm the subscriber uses to choose between the contacts can be represented by callerprefs then it probably wouldn't hurt and might help. This needs further discussion.

> 
> More generally, what is the meaning of these capabilities attributes?
> Does it mean that there exists some UA behind that URI with those
> capabilities? Does it mean that any UA reached with that URI is
> guaranteed to have those capabilities? I think what you want is the
> former.

I agree.

> I also think that you are not going to be able to put the actual
> Contact URI into the PIDF doc; it will need to be some kind of AOR, but
> one that routes to a specific UA instance.

As I mention above, this is really the responsibility of the publisher. It would be stupid of the publisher to insert URIs that cannot be used by subscribers. But I don't see any reason to otherwise restrict this.

> 
> 2. One of the things I am not particularly fond of in the current caller
> prefs spec is the limitation on the capabilities predicate (conjunctive
> normal form only). That restriction exists because of the syntactic
> limitations of using contact parameters, and of the need for a simple
> matching algorithm in proxies to support routing. I would like to leave
> the door open for much more complex capabilities documents, which can be
> uploaded by a UA and used for other things, NOT call routing
> necessarily. Here is a good example of a use case that does not need to
> suffer the limitations of caller prefs. It would be nice if we can be
> more general.

Yes!!! Thanks for mentioning this. I was waiting for this to get out for general discussion before bringing it up. I would welcome suggestions for enhancements to the requirements.

> 
> w3c has done a lot of work in describing capabilities (CC/PP, RDF), all
> of which is XML-based. I wonder if there is a better fit here to use
> that kind of syntax?

Could be.

	Paul

From mikko.lonnfors@nokia.com  Sat Nov 16 11:46:47 2002
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 LAA23799
	for ; Sat, 16 Nov 2002 11:46:46 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAGGkFO04349
	for ; Sat, 16 Nov 2002 18:46:15 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Sat, 16 Nov 2002 18:46:43 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sat, 16 Nov 2002 18:46:45 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sat, 16 Nov 2002 18:46:44 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
Date: Sat, 16 Nov 2002 18:46:43 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD53@esebe004.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
Thread-Index: AcKNMdyTvtocwuOhTCuQP8uHI3ToeAAUkU4A
To: 
Cc: , 
X-OriginalArrivalTime: 16 Nov 2002 16:46:44.0656 (UTC) FILETIME=[BF25CB00:01C28D8F]
Content-Length: 8124
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA23799
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: 

Hi,

Thanks for comments. Mine are inline,

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 16 November, 2002 07:35
> To: Lonnfors Mikko (NRC/Helsinki)
> Cc: pkyzivat@cisco.com; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] FW: I-D
> ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
> 
> 
> I think the basic idea behind these drafts is a good one. 
> There is clear 
> value in knowing, at a watcher, more details on each of the contact 
> addresses in the presence document.
> 
> There are a bunch of issues here which require further discussion:
> 
> 
> 1. Assuming the watcher "picks" one of the contact addresses, and 
> decides to communicate with it by sending it an INVITE, how 
> should that 
> INVITE look? If the URI in the contact element is the AOR of 
> the user, 
> does the watcher need to add caller preferences (Require-Contact) in 
> order to reach that specific UA instance?

This is one of the issues which is currently completely unspecified in the draft. I have a bit mixed feeling how we should proceed which this one. As the decision  is based on presence info watchers have quite a lot freedom how they can initiate communication with the presentity. I am not sure if it makes much sense to mandate any strict behavior from UAs but I think we could give recommendations. This topic definitely deserves more discussion.  

> More generally, what is the meaning of these capabilities attributes? 
> Does it mean that there exists some UA behind that URI with those 
> capabilities? Does it mean that any UA reached with that URI is 
> guaranteed to have those capabilities? I think what you want is the 
> former.

Yes, this is probably the case.

>I also think that you are not going to be able to put 
> the actual 
> Contact URI into the PIDF doc; it will need to be some kind 
> of AOR, but 
> one that routes to a specific UA instance.

Yes, this has been my assumption.

> 
> 2. One of the things I am not particularly fond of in the 
> current caller 
> prefs spec is the limitation on the capabilities predicate 
> (conjunctive 
> normal form only). That restriction exists because of the syntactic 
> limitations of using contact parameters, and of the need for a simple 
> matching algorithm in proxies to support routing. I would 
> like to leave 
> the door open for much more complex capabilities documents, 
> which can be 
> uploaded by a UA and used for other things, NOT call routing 
> necessarily. Here is a good example of a use case that does 
> not need to 
> suffer the limitations of caller prefs. It would be nice if we can be 
> more general.

Yes, I definitely agree. The question seems to be if it is sufficient to give current functionality with ability to extend it using XML namespaces or is there need to define addition functionality to support more complex features.

> w3c has done a lot of work in describing capabilities (CC/PP, 
> RDF), all 
> of which is XML-based. I wonder if there is a better fit here to use 
> that kind of syntax?

I am not very familiar with work done in w3c in this area but I will take a look.

- Mikko

> -Jonathan R.
> 
> mikko.lonnfors@nokia.com wrote:
> > Hi,
> > 
> > inline
> > 
> > 
> >>-----Original Message-----
> >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> >>Sent: 29 October, 2002 17:06
> >>To: simple@mailman.dynamicsoft.com
> >>Subject: Re: [Simple] FW: I-D
> >>ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
> >>
> >>
> >>mikko.lonnfors@nokia.com wrote:
> >>
> >>>Hi,
> >>>
> >>>New draft is now available. Basically draft presents a 
> >>
> >>solution for the requirements presented in 
> >>draft-kyzivat-simple-prescaps-reqts-00.txt.
> >>
> >>>All comments are welcome.
> >>
> >>Obviously Mikko and I have been cooperating on this. We were 
> >>both interested in the subject. I thought it would be helpful 
> >>to be clear about the requirements rather than jumping 
> >>directly to a proposed solution, so I posted a requirements 
> >>draft last week. Since then I have been waiting for Mikko to 
> >>submit this in order to have more fodder for discussion.
> >>
> >>There is already a work item to produce a SIP-specific 
> >>profile for PIDF. I consider these drafts to be a *partial* 
> >>response to that work item. I realize there is a desire for 
> >>some addition generalized status values beyond open/closed, 
> >>such as busy. That is a minefield, and we have chosen not to 
> >>address it. Instead, we are focusing on some attributes that 
> >>should be less controversial because they are drawn from the 
> >>callerprefs draft, whose basic concepts have been accepted 
> >>for a long time. (I am open to discussion about whether these 
> >>specific drafts should be expanded to cover the more general 
> >>requirement, or whether that should be left separate.)
> >>The assertion of these drafts is that capabilities a UAS can 
> >>specify when registering are information that is equally 
> >>important in a presence document. I believe Mikko is most 
> >>concerned with supported media. I also consider that to be of 
> >>major importance, but I also believe all the others are of 
> >>potential value in a presence document.
> > 
> > 
> > This topic was first discussed in IMPP mailing list related 
> to PIDF communication means. After some discussion it was 
> concluded that this work might fit better to SIMPLE WG agenda. 
> > I would also like to see some comments to the requirements 
> draft. A small problem in writing that was that there were no 
> requirements for callerpreferences and because of that we 
> have tried to put quite a lot motivational and explanative 
> text into requirements. It would be very helpful to hear also 
> other people comments to this. If the overall idea is 
> acceptable then the exact requirements should be quite clear. 
> At least requirements 1, 2, and 3 should be quite 
> self-evident (I hope). Requirement 4 is now marked with 
> SHOULD level and I would like to hear if it would be good 
> idea to move it to MUST level. Also I am not sure we have 
> been able to collect all relevant requirements so if 
> something seems to be missing please let us know.  
> > 
> > 
> >>The callerprefs draft is still itself in a state of flux. The 
> >>work here should remain dependent on the outcome of that 
> >>work. But I believe it would be helpful to begin progressing 
> >>these documents now.
> > 
> > 
> > We have tried to keep this draft as independent of 
> callerprefs as possible but there is of course quite heavy 
> dependency between these two. 
> > 
> > Here are some open items for solution draft:
> > - At a moment draft allows use of extension in two places 
> inside PIDF document (inside  and . Should we 
> specify the exact location where this extension can be used 
> within PIDF document.
> > - We went through 2 or 3 different XML schemas before 
> ending up with current one. Obviously there is lot of 
> different options and if someone thinks there exists better 
> alternatives then this can be discussed.
> > - We ended up using negated attribute inside  
> elements to indicate whether value is supporter or not 
> supported. There are also other alternatives to represent 
> this. One alternative would be to replace  with either 
>  or  element.
> > 
> > - Mikko
> > 
> > 
> >>	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
> > 
> 
> -- 
> 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
> 
> 

From aki.niemi@nokia.com  Sun Nov 17 13:47:09 2002
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 NAA28219
	for ; Sun, 17 Nov 2002 13:47:08 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAHIkZO29240
	for ; Sun, 17 Nov 2002 20:46:35 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Sun, 17 Nov 2002 20:47:06 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sun, 17 Nov 2002 20:47:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Subject: RE: [Simple] 3GPP Messaging requirements
Date: Sun, 17 Nov 2002 20:47:06 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD07D@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] 3GPP Messaging requirements
Thread-Index: AcKNLw2ZRv0Ud+GgQkSSDcjpfrK6WgBJqf/g
To: 
Cc: 
X-OriginalArrivalTime: 17 Nov 2002 18:47:06.0771 (UTC) FILETIME=[BA46D630:01C28E69]
Content-Length: 3848
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id NAA28219
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: 

Hi Jonathan,

Thanks for your comments. I've got some inline.

[...]
> This is a good collection of requirements. As you know, I 
> think most of 
> them are addressed already. A few comments on some of them:

I agree. I think from the 3GPP point of view, they just like to keep a comprehensive list of their requirements in this I-D. But we definitely should focus on the ones which do not seem to be covered already. 

> > It MUST be possible to use a single address to identify the 
> recipient
> >    or sender of an instant message or a member in a message session,
> >    irrespective of the messaging system.
> 
> I wasn't sure what to make of this requirement. Is this asking for 
> something new from SIP? You can put whatever kind of address you want 
> into the From field of a MESSAGE request or an INVITE to set 
> up a session...

The original requirements were pretty vague, so my interpretation was that this was actually requiring CPIM compliance. The other requirement is for using E.164 numbers. So nothing new there I think. Both are already enabled.
 
> >  Additionally, it MUST be possible to send the entire 
> message body, or
> >    parts of the body in a way that allows the recipient to choose
> >    between receivng the body and ignoring it.
> 
> parts of the body? What does that mean? Do you mean I can ask 
> to receive 
> the top half of a jpeg only? I hope not.

No, simply if there is a MIME multipart body. This is poor wording from my part. It probably should say parts of the payload instead of body.

> If you are just talking about receiving parts on a 
> body-by-body basis, 
> clearly indirection is the right solution for this.

Definitely, CI was what we were also thinking of.

> > 3.3 Data Manipulation and Management Requirements
> 
> I suspect all of these will be met by the conference control protocol 
> work going on in sipping.

Yes, that seems to be the best home for these requirements.

> > It MUST be possible to divert or block instant messages as part of a
> >    user configurable option.  Such mechanisms MUST support instant
> >    message diversion based on sender address, message size, message
> >    priority, message subject, message class and message 
> content type.
> 
> what is message class?

The 3GPP documents define message class as being e.g., advertisement, announcement, personal, and so on. Frankly I had trouble with this as well, since message class is obviously not available currently in SIP, so I was doubtful as to whether this is actually a protocol issue at all. There may actually be a hidden requirement here, something like:

	There MUST be a mechanism available by which the sender of 
	an instant message can set a specific class for the message.
	Possible classes could be 'advertisement', for commercial 
	messages, and 'personal' for messages intended for personal
	consumption.

Either this, or the message diversion could also depend on an implementation specific mechanism for grouping messages to classes.

(I'm well aware of the futility of the message class type mechanisms, and I'm not expecting spammers to actually mark their messages as spam...)

> > It is proposed that the SIMPLE Working Group evaluates the
> >    requirements presented in this document and incorporates 
> the relevant
> >    ones in its current work items.  Those requirements 
> possibly falling
> >    out of the scope of the SIMPLE WG should find a more 
> suitable home,
> >    possibly also in other standardization bodies.
> 
> As I commented at the last IETF, I would propose that those 
> requirements 
> which do belong to SIMPLE get folded into our general work item on 
> advanced IM requirements.

I agree. But just to have the complete list available, I'll keep updating this document. And keep track of the requirements and where they end up.

Cheers,
Aki

From Markus.Isomaki@nokia.com  Sun Nov 17 14:21:59 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28377
	for ; Sun, 17 Nov 2002 14:21:58 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAHJMhB29122
	for ; Sun, 17 Nov 2002 21:22:43 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Sun, 17 Nov 2002 21:21:57 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Sun, 17 Nov 2002 21:21:57 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt
Date: Sun, 17 Nov 2002 21:21:56 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt
Thread-Index: AcKNOHrmlD0m2hVmQu6OThzVec2WkABNA8Fw
To: 
Cc: 
X-OriginalArrivalTime: 17 Nov 2002 19:21:57.0260 (UTC) FILETIME=[984E24C0:01C28E6E]
Content-Length: 7871
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA28377
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: 

Hi,

I would be happy with a more generalized solution than what is being discussed in my draft. I think SIMPLE data manipulation and conference policy control protocol should be solved within the same framework. Using XML schemas for manipulated objects (such as lists) and using XPath etc. to implement generic manipulation operations would be a good candidate. Actually, I think XPath might be a good solution to presence event filtering as well.

The question now is how to go forward. I wrote the list manipulation 'semantics' draft, because people were saying that it is not possible to pick a particular solution, such as XML or SOAP, straight away. Maybe we should first make even some higher level decisions, such as whether to follow PROTOCOL OPTION 1, 2 or 3 from Jonathan's mail. 

I'll try to raise some discussion about this during my presentation in SIMPLE. Also, I'll try to find out how many people are actually willing to allocate some time to work on this, to have a commonly agreed approach within that group. There hasn't been much discussion on the mailing list.

Markus 

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 16 November, 2002 08:20
> To: Isomaki Markus (NRC/Helsinki)
> Cc: simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] FW: I-D
> ACTION:draft-isomaki-simple-list-man-sem-00.txt
> 
> 
> This draft is a good start.
> 
> I would very much like to do this as generally as possible. Clearly, 
> there are a number of different ways to design a protocol to meet the 
> requirements in the data-req draft. They range from the 
> totally specific 
> to totally general:
> 
> * PROTOCOL OPTION 1: We design a protocol that JUST does whats in the 
> requirements doc, nothig more, nothing less. Its simple, but it only 
> works for buddy lists and authorization policy. It won't work for 
> conference policy, for example.
> 
> * PROTOCOL OPTION 2: Markus' draft. Generalize option 1 a 
> bit. Focus on 
> lists of things, and define a general protocol for creating, 
> modifying 
> and managing lists. Works for buddy lists and conferencing 
> too, so long 
> as all they do is manage lists.
> 
> * PROTOCOL OPTION 3: Generalize Markus' draft further. Assume that 
> anything we want to manipulate can be represented in XML. Conference 
> policies might be modelled as really complex XML documents. Media 
> policies too. A buddy list is an XML document. And so on. The 
> protocol, 
> then, is a general tool for remote editing of XML documents. Using 
> things like XPath, you can address a particular node, add elements, 
> modify them, etc. The underlying application (conferencing, 
> buddy list) 
> validates the changes against its schemas, and assignes 
> semantics to the 
> documents.
> 
> 
> There are probably more sub-options between 2 and 3. For 
> example, we cna 
> introduce restrictions on the types of XML documents we can 
> manipulate, 
> the types of changes we can make, and so on.
> 
> Where do draw the line?
> 
> Clearly, we want something simple so that we can be done 
> soon. Simple is 
> always good.
> 
> However, I would also like a single protocol that can meet the 
> requirements here, AND the requirements for conference policy control 
> and media policy control that are evolving in SIPPING. 
> Conference policy 
> is complex enough that a simple list won't suffice. So, I 
> think we need 
> a bit more that what Markus has defined.
> 
> Thoughts?
> 
> -Jonathan R.
> 
> Markus.Isomaki@nokia.com wrote:
>  > Hi,
>  >
>  > The following draft is now available in the I-D 
> directories. It is an
>  > initial attempt to specify a list management protocol on 
> an abstract
>  > level (only semantics, no syntax). The proposal is made 
> based on the
>  > requirements stated in "draft-ietf-simple-data-req-00". 
> The draft is
>  > still quite drafty, but the main points should be visible.
>  >
>  > The main idea is that many applications (for instance presence and
>  > conferencing) require lists that should be configurable by a client
>  > terminal. It would be useful to define a standard protocol 
> to handle
>  > list manipulation (for SIP-applications), so that it could be
>  > "plugged in" to any application needing it.
>  >
>  > I hope comments to the approach and to the actual abstract 
> protocol.
>  > If this is a good enough start, it could be used as a 
> basis for a WG
>  > document. After that would be reasonably stable, a mapping to some
>  > real syntax could be made and that specifation should be 
> in standards
>  > track.
>  >
>  > Markus
>  >
>  >
>  >> -----Original Message----- From: ext Internet-Drafts@ietf.org
>  >> [mailto:Internet-Drafts@ietf.org] Sent: 04 November, 2002 17:05
>  >> Subject: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt
>  >>
>  >>
>  >> A New Internet-Draft is available from the on-line Internet-Drafts
>  >> directories.
>  >>
>  >>
>  >> Title		: Semantic Description of SIMPLE List 
> Manipulation
>  >> Operations Author(s)	: M. Isomaki et al. Filename	:
>  >> draft-isomaki-simple-list-man-sem-00.txt Pages		
> : 13 Date		:
>  >> 2002-11-1  In SIMPLE based presence and messaging applications, it
>  >> is necessary for  the user to be able to configure a number of
>  >> pieces of information. One of the most common types of information
>  >> is a list of URIs. List management is useful outside the scope of
>  >> SIMPLE as well, for instance in conferencing. There are many
>  >> reasons why it would be beneficial to manage the lists in 
> a similar
>  >> fashion regardless of the application. Before the selection of the
>  >> actual protocol(s) to manage the lists there is a need to describe
>  >> their semantics on an abstract level. This document proposes the
>  >> semantics for SIMPLE list manipulation protocol.
>  >>
>  >> A URL for this Internet-Draft is:
>  >> http://www.ietf.org/internet-drafts/draft-isomaki-simple-list-
>  >
>  > man-sem-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-isomaki-simple-list-man-sem-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-isomaki-simple-list-man-sem-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.
>  >
> 
> -- 
> 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
> 
> 

From drage@lucent.com  Sun Nov 17 14:51:36 2002
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28487
	for ; Sun, 17 Nov 2002 14:51:35 -0500 (EST)
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id gAHJpXe02328
	for ; Sun, 17 Nov 2002 14:51:33 -0500 (EST)
Received: by en0060D057.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id ; Sun, 17 Nov 2002 19:51:32 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB006B27C3D@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" 
To: Eric Burger , Jose.Costa-Requena@nokia.com
Cc: bindignavile.srinivas@nokia.com, Stephane.Coulombe@nokia.com,
        jon.peterson@neustar.biz, Markus.Isomaki@nokia.com,
        dean.willis@softarmor.com, drage@lucent.com,
        Gonzalo.Camarillo@lmf.ericsson.se, sipping@ietf.org,
        Pekka.Pessi@nokia.com, simple@mailman.dynamicsoft.com,
        ietf-openproxy@imc.org, UM list , um@snowshore.com
Date: Sun, 17 Nov 2002 19:51:29 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="UTF-8"
Content-Length: 19556
Subject: [Simple] RE: [Sipping] Multimedia message adaptationInternet-Drafts
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: 

SIPPING is in the transport area because SIP is.

SIP is in the transport area because MMUSIC is.

I assume that the transport area allocation was made because of the http like origin of SIP. It would be hard to argue that SIP acts like http today, or indeed is used like http.

I have heard several people who matter argue that if SIP was allocated to an area today it would be in the application area, and certainly much of the aspects of the work are application layer issues, not transport ones.

I therefore see no reason to argue that application level material cannot be discussed in either SIP or SIPPING.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com 

> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com]
> Sent: 14 November 2002 14:18
> To: Jose.Costa-Requena@nokia.com
> Cc: bindignavile.srinivas@nokia.com; Stephane.Coulombe@nokia.com;
> jon.peterson@neustar.biz; Markus.Isomaki@nokia.com;
> dean.willis@softarmor.com; drage@lucent.com;
> Gonzalo.Camarillo@lmf.ericsson.se; sipping@ietf.org;
> Pekka.Pessi@nokia.com; simple@mailman.dynamicsoft.com;
> ietf-openproxy@imc.org; UM list; um@snowshore.com
> Subject: RE: [Sipping] Multimedia message adaptationInternet-Drafts
> 
> 
> I understand the sentiment.  Neither opes nor lemonade are 
> perfect fits for the current proposals.  However, I would 
> offer that the proper home for media adaptation is either 
> opes or lemonade.
>  
> My rationale is simple.  Sipping is a transport area work 
> group.  The experts in the group are transport experts.  The 
> AD's are transport AD's.  Media transformation is an 
> application.  Opes and lemonade are application work groups.  
> The experts in the groups are application experts.  The AD's 
> are application AD's.
>  
> I agree that there may be refinement or conventions that will 
> be needed in SIP to support real-time media transformation.  
> The correct place for that to happen is sipping.  However, 
> the right people with expertise in media transformation are 
> in the opes and lemonade groups.
>  
> From a charter point of view, media transformation (IMHO) is 
> way out of scope for sipping.  We've heard from Abbie that it 
> is sort of out of scope for opes, as opes is focusing on 
> HTTP.  On the other hand, the mechanism being proposed is 
> rather close to the lemonade work.
>  
> I think this work fits into lemonade charter items 1 
> (retrieval protocols) and 5 (translation services). We can 
> refine the language to explicitly contain the real-time 
> adaptation work items, if that would make everyone happy.
>  
> --
> - Eric
>  
>  
>  
>  
> SIPPING is for SIP. OPES and LEMONADE are specifically for 
> media transformation.  Said differently, we have transport 
> experts in SIPPING and application experts in OPES and LEMONADE.
> 
> 	-----Original Message----- 
> 	From: Rohan Mahy [mailto:rohan@cisco.com] 
> 	Sent: Wed 11/13/2002 9:00 PM 
> 	To: Jose.Costa-Requena@nokia.com 
> 	Cc: bindignavile.srinivas@nokia.com; Eric Burger; 
> Stephane.Coulombe@nokia.com; jon.peterson@neustar.biz; 
> Markus.Isomaki@nokia.com; dean.willis@softarmor.com; 
> drage@lucent.com; Gonzalo.Camarillo@lmf.ericsson.se; 
> sipping@ietf.org; Pekka.Pessi@nokia.com; 
> simple@mailman.dynamicsoft.com; ietf-openproxy@imc.org; UM list 
> 	Subject: Re: [Sipping] RE: [Simple] Multimedia message 
> adaptationInternet-Drafts
> 	
> 	
> 
> 	hello,
> 	
> 	please cease an desist cross posting when you reply.  
> sipping seems
> 	like the default wg, so please send your comments only to
> 	sipping@ietf.org.
> 	
> 	thanks,
> 	-rohan
> 	
> 	On Wednesday, November 13, 2002, at 07:35 AM,
> 	Jose.Costa-Requena@nokia.com wrote:
> 	
> 	> Hi,
> 	>
> 	> According to LEMONADE requirements, it is considering 
> mainly messaging
> 	> systems and I agree that this proposal could fit into 
> that context at
> 	> some extent. Nevertheless, the actual proposal deals 
> with content
> 	> adaptation based on UA capabilities registered with 
> SIP. Thus, I
> 	> consider that it is within SIPPING scope, as well.
> 	> Comments?
> 	> BR
> 	> Jose
> 	>
> 	> -----Original Message-----
> 	> From: Srinivas Bindignavile (NRC/Boston)
> 	> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> 	> adaptationInternet-Drafts
> 	>
> 	>
> 	> Hi,
> 	>
> 	> As Eric has indicated, the OPES WG is considering 
> transcoding issues!
> 	> However, presently, rather than being 
> protocol-agnostic, it is being
> 	> designed for HTTP and RTP only. SIP is not being 
> considered here.
> 	>
> 	> -Srini
> 	>
> 	>> -----Original Message-----
> 	>> From: ext Eric Burger [mailto:eburger@snowshore.com]
> 	>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> 	>> adaptationInternet-Drafts
> 	>>
> 	>>
> 	>>
> 	>> There are already TWO work groups that are considering
> 	>> EXACTLY these transcoding requirements.
> 	>>
> 	>> They are OPES and LEMONADE.
> 	>>
> 	>> I would offer that discussion of these capabilities happen in
> 	>> those groups.  If SIP is the appropriate mechanism, then
> 	>> those groups will submit the appropriate drafts to SIPPING,
> 	>> outlining the requirements.
> 	>>
> 	>>> -----Original Message----- From: 
> Jose.Costa-Requena@nokia.com
> 	>> [snip]
> 	>>> Nevertheless, "content adaptation" I-D has a wider scope
> 	>>> since it is considering any content-type and it is taking
> 	>>> into account the terminal/user preferences. So I would say
> 	>>> that  it fits into SIPPING WG while the filtering I-D is
> 	>>> mainly dealing with presence and I think it should 
> be handled
> 	>>> at SIMPLE WG.
> 	>>> BR
> 	>>> Jose
> 	>>>
> 	>>> -----Original Message----- From: Coulombe Stephane 
> (NRC/Dallas)
> 	>>>> At a high level, these drafts also argue that capability
> 	>>>> negotiation should be administered by intermediaries rather
> 	>>> than through an
> 	>>>> end-to-end process; this approach may attract some similar
> 	>>> controversy.
> 	>>>
> 	>>> Proposed capability negotiation can be used both 
> ways (end-to-end or
> 	>>> administered by intermediaries).
> 	>>> 1) end-to-end: Someone who wants to send an Instant Message
> 	>>> to another user
> 	>>>     can send an OPTION query to learn about its terminal
> 	>>> capabilities and
> 	>>>     then create a message within its capabilities.
> 	>>>    
> 	>>>     I guess this is not controversial. However how
> 	>>> realistic and usable is it in practice?
> 	>>>     When composing a message, would a user really want to
> 	>>> take into consideration
> 	>>>     the image formats to use, message size limitation, etc?
> 	>>>
> 	>>>     For instance, you want to send a PNG image to a friend
> 	>>> and his terminal only supports
> 	>>>     GIF format. What are you supposed to do? Find an image
> 	>>> conversion tool to convert to GIF?
> 	>>>     This is annoying if you are using a PC, imagine with a
> 	>>> mobile phone or handheld?
> 	>>>    
> 	>>>     For usability reasons, the user wants to send a message
> 	>>> without caring "too much" about
> 	>>>     what the other end is supporting.
> 	>>>
> 	>>> 2)administered by intermediaries: this is discussed 
> in detail
> 	>>> in one of the drafts.
> 	>>>
> 	>>>     Performing adaptation in the network is controversial
> 	>>> but this is the only way to support
> 	>>>     interoperability and good user experience.
> 	>>>
> 	>>>> the applicability and impact of this mechanism is larger
> 	>>> than the problem of
> 	>>>> instant messaging and presence. While clearly, from the
> 	>>> framework, instant
> 	>>>> messaging and presence cases are driving this work, it is
> 	>>> applicable to the
> 	>>>> general use of SIP events (messaging, I think, is something
> 	>>> of a corner case).
> 	>>>
> 	>>> Yes, applicability and impact is larger than IM and 
> presence.
> 	>>> It applies to many other
> 	>>> applications including the case of audio/video conferencing
> 	>>> (for instance when there is
> 	>>> no common audio or video codec between two ends).
> 	>>>
> 	>>> The drafts use the "corner case" of SIP IM for a 
> few reasons:
> 	>>> 1) In SIP IM, there is no concept of capability negotiation
> 	>>> (unlike the case of sessions using SDP).
> 	>>>     A user sends a message without knowing anything about
> 	>>> the recipient's terminal capabilities.
> 	>>> 2) In SIP IM, it easier to argue that there will be
> 	>>> interoperability problems because of the variety of content
> 	>>> types that could be sent (in audio/video session codecs are
> 	>>> typically more agreed on). Right now text is mostly used but
> 	>>> richer content will soon be used as is the case in 
> Multimedia
> 	>>> Messaging Service (MMS). By the way, message adaptation is a
> 	>>> serious issue in MMS because of fast product capability
> 	>>> evolution. It's hard to keep interoperability while not
> 	>>> restricting new phones to send just "low-end" content.
> 	>>> 3) It is easier to explain the problem and propose 
> a solution
> 	>>> with a smaller well-defined problem.
> 	>>>
> 	>>> Once we agree that SIP message adaptation is required, the
> 	>>> requirements and solutions should be established from global
> 	>>> perspective; not just SIP IM. For that reason, 
> SIPPING may be
> 	>>> the most appropriate place to initiate this activity.
> 	>>>
> 	>>> Stephane
> 	>>>
> 	>>> -----Original Message-----
> 	>>> From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz]
> 	>>> Sent: Friday, November 08, 2002 6:58 AM
> 	>>> To: Isomaki Markus (NRC/Helsinki); 
> dean.willis@softarmor.com;
> 	>>> drage@lucent.com; rohan@cisco.com; 
> Gonzalo.Camarillo@lmf.ericsson.se
> 	>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> 	>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> 	>>> adaptationInternet-Drafts
> 	>>>
> 	>>>
> 	>>>
> 	>>> It seems to me that these filtering drafts concern the
> 	>>> modification of MIME
> 	>>> bodies in SIP messages by intermediaries. This is 
> not exactly an
> 	>>> uncontroversial topic in SIP circles, and therefore I don't
> 	>>> think it is a
> 	>>> foregone conclusion that this is work that some SIP-related
> 	>> WG should
> 	>>> charter. At a high level, these drafts also argue 
> that capability
> 	>>> negotiation should be administered by intermediaries rather
> 	>>> than through an
> 	>>> end-to-end process; this approach may attract some similar
> 	>>> controversy.
> 	>>>
> 	>>> Provided that this is work the community would like 
> to pursue, the
> 	>>> applicability and impact of this mechanism is 
> larger than the
> 	>>> problem of
> 	>>> instant messaging and presence. While clearly, from the
> 	>>> framework, instant
> 	>>> messaging and presence cases are driving this work, it is
> 	>>> applicable to the
> 	>>> general use of SIP events (messaging, I think, is something
> 	>>> of a corner
> 	>>> case). While SIMPLE could certainly spend some time refining
> 	>>> the framework
> 	>>> and requirements related to IM & presence, I imagine that at
> 	>>> a mechanism
> 	>>> stage this work would need to take place in SIPPING.
> 	>>>
> 	>>> Jon Peterson
> 	>>> NeuStar, Inc.
> 	>>>
> 	>>>> -----Original Message-----
> 	>>>> From: Markus.Isomaki@nokia.com 
> [mailto:Markus.Isomaki@nokia.com]
> 	>>>> Sent: Friday, November 08, 2002 3:47 AM
> 	>>>> To: dean.willis@softarmor.com; drage@lucent.com; 
> rohan@cisco.com;
> 	>>>> Gonzalo.Camarillo@lmf.ericsson.se
> 	>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> 	>>>> Subject: RE: [Sipping] RE: [Simple] Multimedia message
> 	>>>> adaptationInternet-Drafts
> 	>>>>
> 	>>>>
> 	>>>> Hi,
> 	>>>>
> 	>>>> Actually this thread is about two separate things:
> 	>>>> - Event filtering
> 	>>>> - Multimedia message adaptation
> 	>>>>
> 	>>>> Neither of them appears currently on any sippish WG charter
> 	>>>> currently.
> 	>>>>
> 	>>>> Event filtering has been discussed several times and it is
> 	>>>> even mentioned in (but out of scope of) SIP Events RFC. My
> 	>>>> impression has been that people think that it is 
> needed, but
> 	>>>> there has been debate about scope and feasibility. 
> I hope the
> 	>>>> requirements draft will help in that discussion. My own
> 	>>>> opinion is that what is concretely needed in short term is
> 	>>>> some simple filtering definitions for Presence 
> event package.
> 	>>>> More wide-scoped and complex things could be worked upon as
> 	>>>> the understanding accumulates.
> 	>>>>
> 	>>>> Multimedia message adaptation hasn't been yet 
> discussed much.
> 	>>>> I think it is in general a desirable feature, 
> especially for
> 	>>>> relatively small and dumb terminals, which are not easily
> 	>>>> upgradable and may not understand all media formats.
> 	>>>>
> 	>>>> So I propose the WG chairs think where these items would be
> 	>>>> appropriate, and if there is enough interest for 
> them, let's
> 	>>>> put them on the charters.
> 	>>>>
> 	>>>> Markus
> 	>>>>
> 	>>>>> -----Original Message-----
> 	>>>>> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> 	>>>>> Sent: 08 November, 2002 5:11
> 	>>>>> To: Drage, Keith (Keith)
> 	>>>>> Cc: sipping@ietf.org; simple@mailman.dynamicsoft.com
> 	>>>>> Subject: Re: [Sipping] RE: [Simple] Multimedia message
> 	>>>>> adaptationInternet-Drafts
> 	>>>>>
> 	>>>>>
> 	>>>>> Well, I'd like to hear opinions from the 
> participants here . . .
> 	>>>>>
> 	>>>>> Clearly they aren't explicitly on the charter for either
> 	>>>>> group. Do we as
> 	>>>>> yet have a consensus that we need to work on these
> 	>>>> problems? If so, we
> 	>>>>> can consider WHERE to work on them. I suspect SIPPING is
> 	>>> closer to a
> 	>>>>> matching scope than is SIMPLE, but the relevant 
> ADs may have
> 	>>>>> suggestions
> 	>>>>> to make there as well.
> 	>>>>>
> 	>>>>> --
> 	>>>>> Dean
> 	>>>>>
> 	>>>>> On Wed, 2002-11-06 at 12:51, Drage, Keith (Keith) wrote:
> 	>>>>>> I am getting a bit confused as to which group should be
> 	>>>>> discussing these filtering issues.
> 	>>>>>>
> 	>>>>>> Could we have a statement from the WG chairs of 
> SIPPING or
> 	>>>>> SIMPLE as to whether this, and the moran drafts, 
> are part of
> 	>>>>> the scope of SIPPING or SIMPLE.
> 	>>>>>>
> 	>>>>>> And before you say these are both author drafts, 
> I think we
> 	>>>>> do need to charter one of the WGs to do some work in this
> 	>>>>> area - I am just not sure of the exact scope yet.
> 	>>>>>>
> 	>>>>>> Keith
> 	>>>>>>
> 	>>>>>> Keith Drage
> 	>>>>>> Lucent Technologies
> 	>>>>>> Tel: +44 1793 776249
> 	>>>>>> Email: drage@lucent.com
> 	>>>>>>
> 	>>>>>>> -----Original Message-----
> 	>>>>>>> From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com]
> 	>>>>>>> Sent: 06 November 2002 18:24
> 	>>>>>>> To: sipping@ietf.org; simple@mailman.dynamicsoft.com
> 	>>>>>>> Subject: [Simple] Multimedia message adaptation
> 	>>> Internet-Drafts
> 	>>>>>>>
> 	>>>>>>>
> 	>>>>>>>         While these drafts concern event filtering,
> 	>>>> too, the subject was
> 	>>>>>>>         a bit misleading because I lazily just followed
> 	>>>> up Tim's e-mail.
> 	>>>>>>>
> 	>>>>>>>                                         Pekka
> 	>>>>>>>
> 	>>>>>>>
> 	>> 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> 	>>>>>>> ptation-framework-00.txt
> 	>>>>>>>
> 	>>>>>>>
> 	>> 
> http://www.ietf.org/internet-drafts/draft-coulombe-message-ada
> 	>>>>>>> ptation-requirements-00.txt
> 	>>>>>>>
> 	>>>>>>> Pekka Pessi  writes:
> 	>>>>>>>> We have submitted two drafts regarding 
> multimedia message
> 	>>>>>>>> adaptation. A multimedia message is typically a message
> 	>>>>>>>> containing images, audio or video clips and their
> 	>>> presentation
> 	>>>>>>>> information, e.g., smil. Also, even 
> XML-formatted text may
> 	>>>>>>>> require adaptation in some cases.
> 	>>>>>>>
> 	>>>>>>>> Our goal is to have a framework using SIP, HTTP
> 	>> and MIME that
> 	>>>>>>>> allows a person sending multimedia message to adapt
> 	>>> the message
> 	>>>>>>>> contents suitable to all the recipients. In 
> some cases the
> 	>>>>>>>> adaptation can be done by the sending terminal, but
> 	>>> we also see
> 	>>>>>>>> that an adaptation service would be very useful in
> 	>>> many cases.
> 	>>>>>>>> Such an adaptation mechanism is used by MMS service
> 	>>> provided by
> 	>>>>>>>> cellular networks nowadays.
> 	>>>>>>>
> 	>>>>>>>> The message adaptation work concerns both SIPPING
> 	>> and SIMPLE,
> 	>>>>>>>> the requirements I-D lists use cases and 
> requirements for
> 	>>>>>>>> multimedia messaging and message adaptation
> 	>> solutions and the
> 	>>>>>>>> framework I-D tries to explore possible solutions.
> 	>>>>>>>
> 	>>>>>>> _______________________________________________
> 	>>>>>>> simple mailing list
> 	>>>>>>> simple@mailman.dynamicsoft.com
> 	>>>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>>>>>>
> 	>>>>>> _______________________________________________
> 	>>>>>> Sipping mailing list
> 	>>>> https://www1.ietf.org/mailman/listinfo/sipping
> 	>>>>>> This list is for NEW development of the 
> application of SIP
> 	>>>>>> Use sip-implementors@cs.columbia.edu for questions on
> 	>>> current sip
> 	>>>>>> Use sip@ietf.org for new developments of core SIP
> 	>>>>>>
> 	>>>>>
> 	>>>>> _______________________________________________
> 	>>>>> simple mailing list
> 	>>>>> simple@mailman.dynamicsoft.com
> 	>>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>>>>
> 	>>>> _______________________________________________
> 	>>>> simple mailing list
> 	>>>> simple@mailman.dynamicsoft.com
> 	>>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>>>
> 	>>> _______________________________________________
> 	>>> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> 	>>> This list is for NEW development of the application of SIP
> 	>>> Use sip-implementors@cs.columbia.edu for questions 
> on current sip
> 	>>> Use sip@ietf.org for new developments of core SIP
> 	>>> _______________________________________________
> 	>>> simple mailing list
> 	>>> simple@mailman.dynamicsoft.com
> 	>>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>> _______________________________________________
> 	>>> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> 	>>> This list is for NEW development of the application of SIP
> 	>>> Use sip-implementors@cs.columbia.edu for questions 
> on current sip
> 	>>> Use sip@ietf.org for new developments of core SIP
> 	>>>
> 	>> _______________________________________________
> 	>> simple mailing list
> 	>> simple@mailman.dynamicsoft.com
> 	>> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 	>>
> 	> _______________________________________________
> 	> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> 	> This list is for NEW development of the application of SIP
> 	> Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> 	> Use sip@ietf.org for new developments of core SIP
> 	
> 	_______________________________________________
> 	Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> 	This list is for NEW development of the application of SIP
> 	Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> 	Use sip@ietf.org for new developments of core SIP
> 	
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP
> 

From jdrosen@dynamicsoft.com  Mon Nov 18 00:16:46 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00183
	for ; Mon, 18 Nov 2002 00:16:46 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5GlYH001969;
	Mon, 18 Nov 2002 00:16:47 -0500 (EST)
Message-ID: <3DD877BC.609@dynamicsoft.com>
Date: Mon, 18 Nov 2002 00:16:44 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: mikko.lonnfors@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Comment to draft-olson-simple-publish-01.txt
References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD02@esebe004.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2376
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: 

Well, we are going to discuss in person tomorrow, but may as well do 
this on the list too.

inline.

mikko.lonnfors@nokia.com wrote:
 > Hi,
 >
 > Thanks for the new version. Here are some concerns/comments:
 >
 > - Sections 1.1.5 and 3.4: Facet header I am bit confused how this is
 > indented to work. If each PUA always publishes full state then how is
 > it really possible to use facet header to indicate to which watcher
 > instances published information is targeted to? As it is currently
 > defined one PUA could only publish all its information to one or
 > multiple facets i.e. it is not possible to give some part of that
 > info so some facets and some other parts to other facet. In current
 > case it is all or nothing. I would see that better approach would be
 > to include this kind of information into published content and to
 > authorization rules but not to publish protocol itself. Also it is
 > completely unspecified what should happen if PA does not support the
 > requested facet. Should it report an error or should there be some
 > default behavior. Building interoperable system in my mind requires
 > that these procedures are defined.

It is actually my preference that we remove the Facet header entirely. I 
would like to keep separate the problems of publication from the policy 
mechanisms described in draft-ietf-simple-data-req. Those mechanisms 
allow a user to specify rules about what information various subscribers 
should receive. This overlaps with what the Facet header is providing, 
by allowing that information to be provided at publication time. Rather 
that having two ways of doing the same thing, we should pick one.

I'd prefer to keep this within the policy mechanism since policy is much 
broader. The policy mechanisms will allow me to specify who sees which 
documents, but also WHEN they will see them, whether they will be 
encrypted, and so on. None of that is possible through the Facet 
mechanism. So, I'd prefer to use a single broader mechanism.

-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


From jdrosen@dynamicsoft.com  Mon Nov 18 00:28:14 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00273
	for ; Mon, 18 Nov 2002 00:28:14 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5SFYH001976;
	Mon, 18 Nov 2002 00:28:15 -0500 (EST)
Message-ID: <3DD87A6C.5030204@dynamicsoft.com>
Date: Mon, 18 Nov 2002 00:28:12 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Sean Olson , Simple 
Subject: Re: [Simple] Re: draft-olson-simple-publish-01.txt
References: <20021028170024.84188.qmail@web20709.mail.yahoo.com> <3DBD8D49.AABAE379@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2574
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: 

inline.

Paul Kyzivat wrote:
 >
 > Sean Olson wrote:
 >
 >> The analogy breaks down in situations that need more persistence of
 >> the stream identifier. If Call-ID where to persist across all
 >> requests, across reboots, and potentially across devices, then it
 >> would be a perfect fit :)
 >
 >
 > Hmm. If that analogy doesn't hold then it would be helpful to have a
 > more complete description of the semantics of a stream. I guess the
 > discussion of section 1.1.4 Publisher Instance is intended to provide
 > this. But it doesn't line up especially well with the definition of
 > Stream in 3.3. Section 3.3 focuses on providing a context within
 > which to process messages in order, while 1.1.4 focuses on distinct
 > publishing instances. From your comments, you suggest that a distinct
 > instance might not always reside on the same device.

Yes. I think the idea is that you might want to, from one device, change 
the state published originally from another. Example would be, you left 
your work PC on, set your status to "working", and when you get home, 
want to change it to "out of the office", but from a different device.

I admit this is going to get complicated with soft-state refreshes, 
since the work PC will presumably continue to refresh the "working" 
status, resulting in an oscillation of the presence state. Thats clearly 
not what you want.

I suppose a better solution would be for the home PC to publish as a 
separate stream, but publish using the same tuple ID that is being used 
by the work PC. The compositor would them somehow know to select the 
tuple from the home PC as higher priority.

In that case, the stream identifier really is playing the same role as 
the call-id in register, or a dialog ID.

So, it seems we have a few options here:

* use a new header, as in the current doc
* use register-like semantics
* have PUBLISH establish a dialog

The current doc dismisses the idea of dialog establishment. But, since 
publications are soft-state, and if you assume a stream is always tied 
to a particular source, a dialog may make a lot of sense. I always 
regretted the "special case" behavior that REGISTER has, and would 
prefer not to propagate 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


From jdrosen@dynamicsoft.com  Mon Nov 18 00:33:02 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00316
	for ; Mon, 18 Nov 2002 00:33:02 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5X3YH001979;
	Mon, 18 Nov 2002 00:33:03 -0500 (EST)
Message-ID: <3DD87B8C.3080104@dynamicsoft.com>
Date: Mon, 18 Nov 2002 00:33:00 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] A omment to draft-olson-simple-publish-01
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194504F@esebe013.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2024
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: 

inline.

aki.niemi@nokia.com wrote:
 > Hi,
 >
 > Thanks for the much improved -01. One comment though:
 >
 > Although the draft says that 489 (Bad Event) should be sent in case
 > the composer doesn't understand the published event state, there is
 > no mention of Allow-Events used in that case. Allow-Events is
 > mandatory in 489 according to RFC 3265. If it is also mandatory for
 > 489 to a PUBLISH, it would seem logical that it is also (optionally)
 > used with OPTIONS (for one). Would then Allow-Events in a 2xx to
 > OPTIONS indicate support for SUBSCRIBE/NOTIFY, or PUBLISH, or both?

Neither. The Allow header indicates whether SUB/NOT and/or PUBLISH are 
supported. Allow-Events indicates the event packages supported. It may 
be that a UA doesn't permit outside elements to PUBLISH for a specific 
event package it supports, but thats really a policy issue, not an issue 
of whether some package or method is implemented.


 >
 > Why not a new pair of headers, which share the event-type (for
 > packages) namespace with Event/Allow-Events, something like what's
 > described in
 >
 > http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framew-
 > ork-00.txt
 >
 > AFAIK, we are not running out of space with header names ;)

No. However, I really don't see the need for defining another entire 
package concept for publications. I would propose that any "publication" 
not tied to events (such as uploading a CPL) is probably not going to 
have the same requirements that event publication has, and probably is a 
better fit for the data manipulations being discussed in the data 
requirements document and Markus's semantics draft.

-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


From jdrosen@dynamicsoft.com  Mon Nov 18 00:47:43 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00410
	for ; Mon, 18 Nov 2002 00:47:43 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5lfYH001995;
	Mon, 18 Nov 2002 00:47:41 -0500 (EST)
Message-ID: <3DD87EFA.5080400@dynamicsoft.com>
Date: Mon, 18 Nov 2002 00:47:38 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Adam Roach 
CC: "'George Foti (LMC)'" ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] collection template
References: <9BF66EBF6BEFD942915B4D4D45C051F3A642B2@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2295
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: 

inline.

Adam Roach wrote:
>>-----Original Message-----
>>From: George Foti (LMC) [mailto:George.Foti@ericsson.ca]
>>
>>is it correct
>>to assume that either of the following is correct:
>>
>>a) The RLS will send *individual* SUBSCRIBE to all members of 
>>all sub-lists
>>included in the main resource list created by the user when 
>>he SUBSCRIBEs to
>>that list.
> 
> 
> That would be valid. Of course, the RLS has to know the membership
> of all of the sublists to do so.
> 
> 
>>b) The RLS can do procedure (a) for 1 or more sub-lists (in 
>>the original
>>list) but can also send a SUBSCRIBE to another RLS for some 
>>sub-lists (in
>>the original list). The later RLS can be responsbile for 
>>maintaining some
>>lists, and in turn will implement procedure (a).   
> 
> 
> That would also be valid. The only revision I would make to your
> assertion is: "can do procedure (a) for _zero_ or more sublists..."

There is a caveat though.

When I subscribe to foo.list, this means that every element in the list 
has to be of the foo event package. The assumption of the template is 
that each element of the list is of the package the template is applied to.

But, that breaks apart when you have a list that contains elements from 
different packages. For example, you can't have this:

sip:mylist@example.com ->

    sip:joe@example.com [presence package]
    sip:myworkcolleagues@example.com [presence.list package]

What event header value would you use for a SUBSCRIBE to 
mylist@example.com? Its not presence.list OR presence.list.list. The 
template approach, right now, requires that IF you have a list that 
points to other lists, the depth of the resulting tree has to be the 
same for each leaf. Practically speaking, that is unrealizable, since 
lists might reside in different domains, and you can't control their 
depth. So, IMHO, the current mechanism, for all intents and purposes, 
rules out recursive lists.

-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


From jdrosen@dynamicsoft.com  Mon Nov 18 00:57:29 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00473
	for ; Mon, 18 Nov 2002 00:57:29 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI5vUYH002002;
	Mon, 18 Nov 2002 00:57:31 -0500 (EST)
Message-ID: <3DD88148.7040107@dynamicsoft.com>
Date: Mon, 18 Nov 2002 00:57:28 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Markus.Isomaki@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] FW: I-D ACTION:draft-isomaki-simple-list-man-sem-00.txt
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1480
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: 


Markus.Isomaki@nokia.com wrote:
 > Hi,
 >
 > I would be happy with a more generalized solution than what is being
 > discussed in my draft. I think SIMPLE data manipulation and
 > conference policy control protocol should be solved within the same
 > framework. Using XML schemas for manipulated objects (such as lists)
 > and using XPath etc. to implement generic manipulation operations
 > would be a good candidate. Actually, I think XPath might be a good
 > solution to presence event filtering as well.
 >
 > The question now is how to go forward. I wrote the list manipulation
 > 'semantics' draft, because people were saying that it is not possible
 > to pick a particular solution, such as XML or SOAP, straight away.
 > Maybe we should first make even some higher level decisions, such as
 > whether to follow PROTOCOL OPTION 1, 2 or 3 from Jonathan's mail.

I think thats a good idea. I don't think we really need to go through a 
formal process of defining a semantics spec, and then choosing a 
protocol. If we can get general agreement on an approach, I think the 
protocol itself falls out of that.

-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


From jdrosen@dynamicsoft.com  Mon Nov 18 01:02:22 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00516
	for ; Mon, 18 Nov 2002 01:02:22 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI62OYH002011;
	Mon, 18 Nov 2002 01:02:24 -0500 (EST)
Message-ID: <3DD8826D.5050203@dynamicsoft.com>
Date: Mon, 18 Nov 2002 01:02:21 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] 3GPP Messaging requirements
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD07D@esebe013.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1922
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: 

inline.

aki.niemi@nokia.com wrote:

 >
 >>> It MUST be possible to divert or block instant messages as part
 >>> of a user configurable option.  Such mechanisms MUST support
 >>> instant message diversion based on sender address, message size,
 >>> message priority, message subject, message class and message
 >>
 >> content type.
 >>
 >> what is message class?
 >
 >
 > The 3GPP documents define message class as being e.g., advertisement,
 > announcement, personal, and so on. Frankly I had trouble with this as
 > well, since message class is obviously not available currently in
 > SIP, so I was doubtful as to whether this is actually a protocol
 > issue at all. There may actually be a hidden requirement here,
 > something like:
 >
 > There MUST be a mechanism available by which the sender of an instant
 > message can set a specific class for the message. Possible classes
 > could be 'advertisement', for commercial messages, and 'personal' for
 > messages intended for personal consumption.
 >
 > Either this, or the message diversion could also depend on an
 > implementation specific mechanism for grouping messages to classes.
 >
 > (I'm well aware of the futility of the message class type mechanisms,
 > and I'm not expecting spammers to actually mark their messages as
 > spam...)

Thats the problem exactly. The Priority header does exist, and plays a 
similar role. But, like class, you can't do much with it beyond 
rendering to the user.

Another problem with class is determining the enumerated set of what 
classes there can be...

-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


From jdrosen@dynamicsoft.com  Mon Nov 18 01:08:45 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00567
	for ; Mon, 18 Nov 2002 01:08:45 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.14])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAI68lYH002017;
	Mon, 18 Nov 2002 01:08:47 -0500 (EST)
Message-ID: <3DD883EC.3070101@dynamicsoft.com>
Date: Mon, 18 Nov 2002 01:08:44 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: mikko.lonnfors@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com> <3DD5D8ED.7070704@dynamicsoft.com> <3DD66CBC.A986100@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 4081
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: 


Paul Kyzivat wrote:
 >
 >
 >> 1. Assuming the watcher "picks" one of the contact addresses, and
 >> decides to communicate with it by sending it an INVITE, how should
 >> that INVITE look? If the URI in the contact element is the AOR of
 >> the user, does the watcher need to add caller preferences
 >> (Require-Contact) in order to reach that specific UA instance?
 >
 >
 > My assumption has been that if the watcher picks one of the contact
 > addresses, he then just sends the invite to it. It is up to the
 > publisher of presence to arrange things so that does the right thing.

Agreed.

 > The publisher can identify separate tuples each with a particular set
 > of capabilities, and yet provide a single AOR for all of them. In
 > that case it is in effect promising to provide a smart proxy at the
 > AOR that can do the right thing.

Well, that won't work. How would the proxy know which tuple was 
intended? The only way it can know is if the caller had placed caller 
preferences in the request. That was my point - how would the caller 
know it needs to do that?

I suppose the right answer is to construct the tuple URI like this:

sip:aor@domain?Require-Contact=

that is, you don't rely on the subscriber to insert the caller prefs. 
The PA does that itself by embedding them in the URI.

 >
 > Or the publisher can provide an actual individual contact address for
 > each tuple. In that case it is promising that the contact addresses
 > are usable by presence subscribers.

This is another instance of what I've been calling the "globally 
routable UA instance problem" - how to construct a SIP URI that routes 
to a specific UA instance when used outside of any existing dialog.

 >
 > In the end, the publisher is in the driver's seat, and publishing
 > what it willing to expose and what it thinks will be useful to
 > subscribers. There clearly is a tradeoff  between those two things,
 > and the publisher is the one that ought to decide.
 >
 > Whether the subscriber should put callerprefs on the invite is a good
 > question. If the algorithm the subscriber uses to choose between the
 > contacts can be represented by callerprefs then it probably wouldn't
 > hurt and might help. This needs further discussion.

I think the semantic needs to be simple. The caller invokes the URI in 
the presence document, period. The server guarnatees that that results 
in a request being routed to a UA described by the information in the 
presence document. Thats the contact.


 >
 >> 2. One of the things I am not particularly fond of in the current
 >> caller prefs spec is the limitation on the capabilities predicate
 >> (conjunctive normal form only). That restriction exists because of
 >> the syntactic limitations of using contact parameters, and of the
 >> need for a simple matching algorithm in proxies to support routing.
 >> I would like to leave the door open for much more complex
 >> capabilities documents, which can be uploaded by a UA and used for
 >> other things, NOT call routing necessarily. Here is a good example
 >> of a use case that does not need to suffer the limitations of
 >> caller prefs. It would be nice if we can be more general.
 >
 >
 > Yes!!! Thanks for mentioning this. I was waiting for this to get out
 > for general discussion before bringing it up. I would welcome
 > suggestions for enhancements to the requirements.
 >
 >
 >> w3c has done a lot of work in describing capabilities (CC/PP, RDF),
 >> all of which is XML-based. I wonder if there is a better fit here
 >> to use that kind of syntax?
 >
 >
 > Could be.

That seems to be the common answer here... someone needs to do a 
detailed study and see how it fits.

-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


From aki.niemi@nokia.com  Mon Nov 18 08:20:45 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00982
	for ; Mon, 18 Nov 2002 08:20:44 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAIDLSB22068
	for ; Mon, 18 Nov 2002 15:21:32 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Mon, 18 Nov 2002 15:19:19 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 18 Nov 2002 15:19:19 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] A comment to draft-olson-simple-publish-01
Date: Mon, 18 Nov 2002 15:19:17 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD080@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] A omment to draft-olson-simple-publish-01
Thread-Index: AcKOw/e8yBv0aP1BTielqm2PecoTQwABKgcw
To: 
Cc: 
X-OriginalArrivalTime: 18 Nov 2002 13:19:19.0135 (UTC) FILETIME=[19DD7EF0:01C28F05]
Content-Length: 2931
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA00982
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: 

Hi,

Comments inline.

[...]
>  > Although the draft says that 489 (Bad Event) should be sent in case
>  > the composer doesn't understand the published event state, there is
>  > no mention of Allow-Events used in that case. Allow-Events is
>  > mandatory in 489 according to RFC 3265. If it is also mandatory for
>  > 489 to a PUBLISH, it would seem logical that it is also 
> (optionally)
>  > used with OPTIONS (for one). Would then Allow-Events in a 2xx to
>  > OPTIONS indicate support for SUBSCRIBE/NOTIFY, or PUBLISH, or both?
> 
> Neither. The Allow header indicates whether SUB/NOT and/or 
> PUBLISH are 
> supported. Allow-Events indicates the event packages 
> supported. It may 
> be that a UA doesn't permit outside elements to PUBLISH for a 
> specific 
> event package it supports, but thats really a policy issue, 
> not an issue 
> of whether some package or method is implemented.

Well, the way RFC3265 reads to me suggests that Allow-Events indicates exactly that the node can process the SUBSCRIBEs and NOTIFYs for that particular event package. For clarity's sake I think we need a similar capability specifically for PUBLISH.

I agree that the authorization policy for a PUBLISH is not in any way related to the contents of Allow-Events, and may in fact be quite similar to an auth policy for a SUBSCRIBE. We might even consider that some sort of publish-winfo could be reused for reactive authorization of publications.

However, this somehow suggests that publish be its own framework, and not an additional part of the events framework.

>  > Why not a new pair of headers, which share the event-type (for
>  > packages) namespace with Event/Allow-Events, something like what's
>  > described in
>  >
>  > 
http://www.ietf.org/internet-drafts/draft-niemi-simple-publish-framew-
 > ork-00.txt
 >
 > AFAIK, we are not running out of space with header names ;)
>
> No. However, I really don't see the need for defining another entire 
> package concept for publications. I would propose that any "publication" 
> not tied to events (such as uploading a CPL) is probably not going to 
> have the same requirements that event publication has, and probably is a 
> better fit for the data manipulations being discussed in the data 
> requirements document and Markus's semantics draft.

I agree that CPL uploads fall well out of the scope. And I also agree that there isn't maybe a huge need for an entire package system. Having a package would be useful if/when we start defining things like default expiration of state for a particular package, publish payloads that are distinct from NOTIFY bodies, etc. But again, this isn't real concrete yet, nor is it a big issue for me if there isn't a package concept, but things are left for composer policy. Either way works.

But there are many degrees to what I'm proposing, and I'll try to bring this into the discussion in the SIMPLE session today.

Cheers,
Aki

From leonardo_rico@hotmail.com  Sun Nov 17 11:53:00 2002
Received: from hotmail.com (f156.sea1.hotmail.com [207.68.163.156])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27912
	for ; Sun, 17 Nov 2002 11:52:59 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sun, 17 Nov 2002 08:52:57 -0800
Received: from 212.143.185.30 by sea1fd.sea1.hotmail.msn.com with HTTP;
	Sun, 17 Nov 2002 16:52:57 GMT
X-Originating-IP: [212.143.185.30]
From: "Leonardo Rico" 
To: sip@ietf.org, simple@mailman.dynamicsoft.com
Date: Sun, 17 Nov 2002 11:52:57 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: 
X-OriginalArrivalTime: 17 Nov 2002 16:52:57.0933 (UTC) FILETIME=[C80D17D0:01C28E59]
Content-Length: 325
Subject: [Simple] Presence with PIDF format
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: 

Hi,

I’m looking for a UA presence application that supports PIDF format.
Preferable an open source or demo I can download.
Any idea?

Thanks,
Leonardo




_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus


From akkasam@hss.hns.com  Mon Nov 18 00:19:16 2002
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00227
	for ; Mon, 18 Nov 2002 00:19:14 -0500 (EST)
From: akkasam@hss.hns.com
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5Iar20345
	for ; Mon, 18 Nov 2002 10:48:36 +0530 (IST)
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5IY820331;
	Mon, 18 Nov 2002 10:48:34 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAI5KDq27892;
	Mon, 18 Nov 2002 10:50:13 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256C75.001CA518 ; Mon, 18 Nov 2002 10:42:52 +0530
X-Lotus-FromDomain: HSSBLR@HSS
To: "Leonardo Rico" 
cc: sip@ietf.org, simple@mailman.dynamicsoft.com
Message-ID: <65256C75.001CA483.00@sandesh.hss.hns.com>
Date: Mon, 18 Nov 2002 10:46:03 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Length: 575
Subject: [Simple] Regarding SIPS
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: 


Hi

According to the RFC 3261,

     If the Request-URI contains a SIPS URI, or the topmost Route header
     field value (after the post processing of bullet 6) contains a
     SIPS URI, the URI placed into the Record-Route header field
     MUST be a SIPS URI. Furthermore, if the request was not
     received over TLS, the proxy MUST insert a Record-Route header
     field


How can this scencario occur.

how can it happen that request uri ( or top most route header) is sips and
request receiving on other than TLS.

Thanks in advance

With Regds
Ajay Kumar Kasam



From akkasam@hss.hns.com  Mon Nov 18 00:39:00 2002
Received: from hindon.hss.co.in ([202.54.26.202])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00360
	for ; Mon, 18 Nov 2002 00:38:59 -0500 (EST)
From: akkasam@hss.hns.com
Received: from hindon.hss.co.in (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5cKr24534
	for ; Mon, 18 Nov 2002 11:08:20 +0530 (IST)
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id gAI5cJ824527;
	Mon, 18 Nov 2002 11:08:20 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id gAI5dwu00046;
	Mon, 18 Nov 2002 11:09:58 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256C75.001E73B2 ; Mon, 18 Nov 2002 11:02:36 +0530
X-Lotus-FromDomain: HSSBLR@HSS
To: akkasam@hss.hns.com
cc: "Leonardo Rico" , sip@ietf.org,
        simple@mailman.dynamicsoft.com
Message-ID: <65256C75.001E6FD5.00@sandesh.hss.hns.com>
Date: Mon, 18 Nov 2002 11:05:38 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Length: 491
Subject: [Simple] Re: [Sip] Regarding SIPS
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: 


Hi

Here is one scenario where we can expect this to occur.

Supposed  sip: atlanta.com , sips: bilboxi.com be pre-configured route-set at
ClientA
and let sip:clientb@bilboxi.com be the request uri.
Now when the request reaches atlanta.com, after processing route header, the top
most route
header will be sips, but is received the request on other than TLS.

but why doubt is why it is MUST for atlanta.com to record-route.

waiting for ur response.

thanks in advance
ajay kumar kasam



From pkyzivat@cisco.com  Mon Nov 18 12:37:06 2002
Received: from atpop.smtp.stsn.com (p105.n-atpop03.stsn.com [12.129.82.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02081
	for ; Mon, 18 Nov 2002 12:37:06 -0500 (EST)
Received: from cisco.com ([10.0.174.235]) by atpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 18 Nov 2002 12:36:17 -0500
Message-ID: <3DD92541.D01F8E1B@cisco.com>
Date: Mon, 18 Nov 2002 12:37:05 -0500
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: mikko.lonnfors@nokia.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD19@esebe004.ntc.nokia.com> <3DD5D8ED.7070704@dynamicsoft.com> <3DD66CBC.A986100@cisco.com> <3DD883EC.3070101@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Nov 2002 17:36:17.0843 (UTC) FILETIME=[0021A030:01C28F29]
Content-Length: 3115
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: 


Jonathan Rosenberg wrote:
>
>  >> 1. Assuming the watcher "picks" one of the contact addresses, and
>  >> decides to communicate with it by sending it an INVITE, how should
>  >> that INVITE look? If the URI in the contact element is the AOR of
>  >> the user, does the watcher need to add caller preferences
>  >> (Require-Contact) in order to reach that specific UA instance?
>  >
>  > The publisher can identify separate tuples each with a particular set
>  > of capabilities, and yet provide a single AOR for all of them. In
>  > that case it is in effect promising to provide a smart proxy at the
>  > AOR that can do the right thing.
> 
> Well, that won't work. How would the proxy know which tuple was
> intended? The only way it can know is if the caller had placed caller
> preferences in the request. That was my point - how would the caller
> know it needs to do that?
> 
> I suppose the right answer is to construct the tuple URI like this:
> 
> sip:aor@domain?Require-Contact=
> 
> that is, you don't rely on the subscriber to insert the caller prefs.
> The PA does that itself by embedding them in the URI.

I think this is a matter of semantics. If I, as publisher, say there are two tuples with different attributes, but associate them both with the same AOR, it might mean that I have two devices registered at the same AOR with differing attributes but don't choose to identify their addresses; or it might mean that I have a single device with two different and interesting sets of attributes I choose to advertise.

The subscriber doesn't know and shouldn't care, as long as it reaches a device with the proper capabilities.

Having a proxy for the AOR simply fork the request may be sufficient if there are two devices and the characteristics that differentiate them can always be discerned from the initial request. This isn't going to be the case very often, but since the publisher is in the driver seat it should be his problem to decide this.

Nevertheless, I agree that in general it would be best for the presence publisher to do as you suggest and embed the callerprefs headers in the contact address. Toward that end, I think we had better specify somewhere that contact addresses in presence may indeed contain embedded headers, since they aren't universally accepted.

> I think the semantic needs to be simple. The caller invokes the URI in
> the presence document, period. The server guarnatees that that results
> in a request being routed to a UA described by the information in the
> presence document. Thats the contact.

Yes, this seems to be the best answer.

>  >> w3c has done a lot of work in describing capabilities (CC/PP, RDF),
>  >> all of which is XML-based. I wonder if there is a better fit here
>  >> to use that kind of syntax?
>  >
>  >
>  > Could be.
> 
> That seems to be the common answer here... someone needs to do a
> detailed study and see how it fits.

I already spoke with Mikko about this. Neither of us are familiar with the W3C work. Will need to figure out who has the time / contacts to do the digging.

	Paul

From adam@dynamicsoft.com  Mon Nov 18 17:04:43 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03044
	for ; Mon, 18 Nov 2002 17:04:42 -0500 (EST)
Received: from TXADAM (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with SMTP id gAIM4h122260
	for ; Mon, 18 Nov 2002 16:04:43 -0600
Message-ID: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com>
From: "Adam Roach" 
To: 
Date: Mon, 18 Nov 2002 16:04:27 -0600
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.2720.3000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Length: 1128
Subject: [Simple] Thoughts on list template
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: 

After giving some thought to the issues raised in today's
meeting, it occurs to me that there may, in fact, be a
compromise. I'm throwing the rough description out on the
list in hope that, if a flaw exists, one of you will
be able to point it out.

Basically, it amounts to this: to give the capabilities
that several people want (e.g. arbitrary depth lists)
without abandoning templates, we could slightly tweak
the meaning of the ".list" template. In particular,
"foo.list" would refer to any arbitrary nesting of
foo objects; e.g., it would cover what is, under the
current draft, called any of foo.list, foo.list.list,
foo.list.list.list, ad infinitum.

I *think* this still works gracefully when you combine
it with other templates (e.g. presence.list.winfo.list).
It *does* impose more of a processing load on aggregators,
but I don't think it's crippling.

So, first: does anyone see anything that would prevent
this working, from a technical perspective?

And, second: does anyone have any philosophical objections
to this approach? (I'll admit that I have my own reservations,
but I want to find a middle ground)

/a


From pkyzivat@cisco.com  Mon Nov 18 19:13:46 2002
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 TAA03428
	for ; Mon, 18 Nov 2002 19:13:45 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJ0DwIL000697;
	Mon, 18 Nov 2002 19:14:02 -0500 (EST)
Received: from cisco.com (rtp-vpn2-678.cisco.com [10.82.242.166])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAV09091;
	Mon, 18 Nov 2002 19:18:29 -0500 (EST)
Message-ID: <3DD9822E.9AA9D9D1@cisco.com>
Date: Mon, 18 Nov 2002 19:13:34 -0500
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 
CC: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Thoughts on list template
References: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1362
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: 


Adam Roach wrote:
> 
> Basically, it amounts to this: to give the capabilities
> that several people want (e.g. arbitrary depth lists)
> without abandoning templates, we could slightly tweak
> the meaning of the ".list" template. In particular,
> "foo.list" would refer to any arbitrary nesting of
> foo objects; e.g., it would cover what is, under the
> current draft, called any of foo.list, foo.list.list,
> foo.list.list.list, ad infinitum.
... 
> So, first: does anyone see anything that would prevent
> this working, from a technical perspective?

I too hope something like this works. I think we need to dig into details a bit to figure out if it is going to work.

1) Does this imply that the server serving an instance of foo.list itself issues the subscriptions to all the leaves of the recursive list expansion? Or is it just responsible for delegating those? Or are both approaches valid? (They may have different authentication implications.) The pure template approach clearly implied delegating the responsibility for the leaf subscriptions.

2) Either way, the server for foo.list is now responsible for determining if a particular list entry is an instance of foo, or of foo.list. Do we have any better way to figure this out than trial and error? Is that acceptable? (An alternative might be to explicitly type the entries in a list.)

	Paul

From hisham.khartabil@nokia.com  Mon Nov 18 19:37:51 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03519
	for ; Mon, 18 Nov 2002 19:37:50 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJ0ccB01068
	for ; Tue, 19 Nov 2002 02:38:38 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 19 Nov 2002 02:35:58 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 19 Nov 2002 02:35:57 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 19 Nov 2002 02:35:56 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Thoughts on list template
Date: Tue, 19 Nov 2002 02:35:56 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FDB@esebe019.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Thoughts on list template
Thread-Index: AcKPUF0dDipanlHDSgeLT1ywT4XWgQAEXErg
To: , 
X-OriginalArrivalTime: 19 Nov 2002 00:35:56.0929 (UTC) FILETIME=[A0093F10:01C28F63]
Content-Length: 2510
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id TAA03519
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: 

That's how I thought it worked in the first place, hence my confusion of what the problem was.

You have a list of buddies, on of the buddies is a list:

adam@dynamicsoft.com
jonathan@dynamicsoft.com
adamfriends@dynamicsoft.com (I have  Adam's list of friends on my buddy list. I can do that, technically)

My terminal will send out 3 SUBSCRIBEs, one for each of the above. Does my terminal need to recognise that adamfriends@dynamicsoft.com is a list? This has nothing to do with the problem we have now with the list package.

Now, I make a list out of the above and call it mybuddies@nokia.com

Instead of my terminal sending out 3 SUBSCRIBEs (one of them to adamfriends@dynamicsoft.com with event: presence), it sends out 1.

The question is: should my PLS recognise that adamfriends@dynamicsoft.com is a list? I say no. Its up to dynamicsoft's domain to decide that, somehow.

This "somehow" solves both problems above.

Regards,
Hisham


> -----Original Message-----
> From: ext Adam Roach [mailto:adam@dynamicsoft.com]
> Sent: Tuesday, November 19, 2002 12:04 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] Thoughts on list template
> 
> 
> After giving some thought to the issues raised in today's
> meeting, it occurs to me that there may, in fact, be a
> compromise. I'm throwing the rough description out on the
> list in hope that, if a flaw exists, one of you will
> be able to point it out.
> 
> Basically, it amounts to this: to give the capabilities
> that several people want (e.g. arbitrary depth lists)
> without abandoning templates, we could slightly tweak
> the meaning of the ".list" template. In particular,
> "foo.list" would refer to any arbitrary nesting of
> foo objects; e.g., it would cover what is, under the
> current draft, called any of foo.list, foo.list.list,
> foo.list.list.list, ad infinitum.
> 
> I *think* this still works gracefully when you combine
> it with other templates (e.g. presence.list.winfo.list).
> It *does* impose more of a processing load on aggregators,
> but I don't think it's crippling.
> 
> So, first: does anyone see anything that would prevent
> this working, from a technical perspective?
> 
> And, second: does anyone have any philosophical objections
> to this approach? (I'll admit that I have my own reservations,
> but I want to find a middle ground)
> 
> /a
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From deepankarb@huawei.com  Mon Nov 18 22:28:40 2002
Received: from mta0 ([61.144.161.10])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04069
	for ; Mon, 18 Nov 2002 22:28:39 -0500 (EST)
Received: from D70286 (mta0 [172.17.1.62])
 by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12
 2002)) with ESMTPA id <0H5T00EVD08UL9@mta0.huawei.com> for
 simple@mailman.dynamicsoft.com; Tue, 19 Nov 2002 11:26:55 +0800 (CST)
Date: Tue, 19 Nov 2002 11:28:18 +0800
From: Deepankar 
To: simple@mailman.dynamicsoft.com
Message-id: <008501c28f7b$b4213620$ac064d0a@D70286>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: multipart/alternative;
 boundary="Boundary_(ID_PLf9RPSIZqp226W79pWLLg)"
X-Priority: 3
X-MSMail-priority: Normal
Content-Length: 929
Subject: [Simple] PAM and SIMPLE
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: 

This is a multi-part message in MIME format.

--Boundary_(ID_PLf9RPSIZqp226W79pWLLg)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Sorry to barge in... but could anybody redirect me to a mailing list for discussion on SIMPLE and PAM API mapping.

/deeps

--Boundary_(ID_PLf9RPSIZqp226W79pWLLg)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT









Sorry to barge in... but could anybody redirect me 
to a mailing list for discussion on SIMPLE and PAM API mapping.


 


/deeps


--Boundary_(ID_PLf9RPSIZqp226W79pWLLg)--

From jdrosen@dynamicsoft.com  Mon Nov 18 23:40:59 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04312
	for ; Mon, 18 Nov 2002 23:40:59 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.71])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAJ4f2YH002975;
	Mon, 18 Nov 2002 23:41:03 -0500 (EST)
Message-ID: <3DD9C0DE.1050008@dynamicsoft.com>
Date: Mon, 18 Nov 2002 23:41:02 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat 
CC: Adam Roach , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Thoughts on list template
References: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com> <3DD9822E.9AA9D9D1@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 4765
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: 

inline.

Paul Kyzivat wrote:
 >
 > Adam Roach wrote:
 >
 >> Basically, it amounts to this: to give the capabilities that
 >> several people want (e.g. arbitrary depth lists) without abandoning
 >> templates, we could slightly tweak the meaning of the ".list"
 >> template. In particular, "foo.list" would refer to any arbitrary
 >> nesting of foo objects; e.g., it would cover what is, under the
 >> current draft, called any of foo.list, foo.list.list,
 >> foo.list.list.list, ad infinitum.
 >
 > ...
 >
 >> So, first: does anyone see anything that would prevent this
 >> working, from a technical perspective?
 >
 >
 > I too hope something like this works. I think we need to dig into
 > details a bit to figure out if it is going to work.
 >
 > 1) Does this imply that the server serving an instance of foo.list
 > itself issues the subscriptions to all the leaves of the recursive
 > list expansion? Or is it just responsible for delegating those? Or
 > are both approaches valid? (They may have different authentication
 > implications.) The pure template approach clearly implied delegating
 > the responsibility for the leaf subscriptions.

I don't see the difference between the two things?

 >
 > 2) Either way, the server for foo.list is now responsible for
 > determining if a particular list entry is an instance of foo, or of
 > foo.list. Do we have any better way to figure this out than trial and
 > error? Is that acceptable? (An alternative might be to explicitly
 > type the entries in a list.)

This is the big issue.

It might help to step back and consider how this would work in an IDEAL 
world of a clean slate, and work backwards. Doing that is what helped us 
figure out how to do loose routing, and as it turns out, I think it 
solves this problem too.

In the ideal world,  there is no presence package. There is only 
the equivalent of "presence.list". That is, we assume at the outset that 
a presence subscription always implies a list, and a valid option is a 
list of one. Thus, I subscribe to my buddylist with package "presence", 
and each of the subscriptions it generates are for the same package, 
"presence". The owner of the URI gets to decide whether its a list of 
multiple elements, or just one.

Now, the problem of course is that all of the list features would need 
to be replicated in each package. So, the ideal solution there IMHO 
would have been to have list processing be central to rfc3265 in the 
first place, so that all packages are list enabled from the outset.

OK, so IF you agree that this is what it ought to have been, how do we 
achieve as close a goal as possible with the constraints that we have?

I would define list processing as an EXTENSION to rfc3265, not a 
template or a new package. How would that work? When a UAC subscribes, 
it includes a Supported header indicated "lists". The Allow header in 
the subscribe also lists multipart as a valid body type thats supported, 
along with the MIME type of this XML list meta-data. So, a buddy list 
subscription looks like:

SUBSCRIBE sip:mylist@domain.com SIP/2.0
Supported: lists
Allow: application/pidf+xml, multipart/mixed, application/elist+xml
Event: presence

The server knows that mylist is a list, but since the client supports 
lists, its OK. The server does a SUBSCRIBE to each participant in the 
list, all of them with the Event: presence header, and all of them with 
the same Supported and Allow headers. Now, should one of those happen to 
be a regular presence server that doesn't support the "lists" extension, 
it works just fine! The server will generate NOTIFYs with plain-old 
PIDF, no multipart or elist+xml. So, there is no trial-and-error; a 
subscription to an element in the list is the same in all cases, and 
doesn't require knowing what it is. If it turns out that its a list, 
multipart comes back. If not, just plain PIDF.

Should a user SUBSCRIBE to a list, and not indicate support for "lists" 
in the Supported header, the server rejects the request with a 420 and 
the appropriate Require header.

As far as I can tell, this solution buys us EVERYTHING we want:

* infinite nesting of lists, without the list server needing to know 
whether an entry is a list or not
* no trial and error
* backwards compatibility
* graceful evolution, if we want, to a revised rfc3265 that includes the 
list processing as a native capability


Comments?

-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


From pkyzivat@cisco.com  Tue Nov 19 00:22:32 2002
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 AAA04489
	for ; Tue, 19 Nov 2002 00:22:32 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJ5MoiU000418;
	Tue, 19 Nov 2002 00:22:51 -0500 (EST)
Received: from cisco.com (sjc-vpn3-983.cisco.com [10.21.67.215])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAV10082;
	Tue, 19 Nov 2002 00:27:20 -0500 (EST)
Message-ID: <3DD9CA91.B5325142@cisco.com>
Date: Tue, 19 Nov 2002 00:22:25 -0500
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: Adam Roach , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Thoughts on list template
References: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com> <3DD9822E.9AA9D9D1@cisco.com> <3DD9C0DE.1050008@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3253
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: 

Jonathan,

I was thinking that getting out of this problem required special casing list. It looks like you have come up with a fine way to do it. At first glance this seems to work just fine as far as I can see, though I reserve the right to change my mind.

	Great idea,
	Paul

Jonathan Rosenberg wrote:
> 
> It might help to step back and consider how this would work in an IDEAL
> world of a clean slate, and work backwards. Doing that is what helped us
> figure out how to do loose routing, and as it turns out, I think it
> solves this problem too.
> 
> In the ideal world,  there is no presence package. There is only
> the equivalent of "presence.list". That is, we assume at the outset that
> a presence subscription always implies a list, and a valid option is a
> list of one. Thus, I subscribe to my buddylist with package "presence",
> and each of the subscriptions it generates are for the same package,
> "presence". The owner of the URI gets to decide whether its a list of
> multiple elements, or just one.
> 
> Now, the problem of course is that all of the list features would need
> to be replicated in each package. So, the ideal solution there IMHO
> would have been to have list processing be central to rfc3265 in the
> first place, so that all packages are list enabled from the outset.
> 
> OK, so IF you agree that this is what it ought to have been, how do we
> achieve as close a goal as possible with the constraints that we have?
> 
> I would define list processing as an EXTENSION to rfc3265, not a
> template or a new package. How would that work? When a UAC subscribes,
> it includes a Supported header indicated "lists". The Allow header in
> the subscribe also lists multipart as a valid body type thats supported,
> along with the MIME type of this XML list meta-data. So, a buddy list
> subscription looks like:
> 
> SUBSCRIBE sip:mylist@domain.com SIP/2.0
> Supported: lists
> Allow: application/pidf+xml, multipart/mixed, application/elist+xml
> Event: presence
> 
> The server knows that mylist is a list, but since the client supports
> lists, its OK. The server does a SUBSCRIBE to each participant in the
> list, all of them with the Event: presence header, and all of them with
> the same Supported and Allow headers. Now, should one of those happen to
> be a regular presence server that doesn't support the "lists" extension,
> it works just fine! The server will generate NOTIFYs with plain-old
> PIDF, no multipart or elist+xml. So, there is no trial-and-error; a
> subscription to an element in the list is the same in all cases, and
> doesn't require knowing what it is. If it turns out that its a list,
> multipart comes back. If not, just plain PIDF.
> 
> Should a user SUBSCRIBE to a list, and not indicate support for "lists"
> in the Supported header, the server rejects the request with a 420 and
> the appropriate Require header.
> 
> As far as I can tell, this solution buys us EVERYTHING we want:
> 
> * infinite nesting of lists, without the list server needing to know
> whether an entry is a list or not
> * no trial and error
> * backwards compatibility
> * graceful evolution, if we want, to a revised rfc3265 that includes the
> list processing as a native capability
> 
> Comments?

From aki.niemi@nokia.com  Tue Nov 19 11:52:03 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06517
	for ; Tue, 19 Nov 2002 11:52:03 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJGqoB24217
	for ; Tue, 19 Nov 2002 18:52:50 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 19 Nov 2002 18:52:02 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 19 Nov 2002 18:52:02 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Thoughts on list template
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Tue, 19 Nov 2002 18:52:02 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194508F@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Thoughts on list template
Thread-Index: AcKPhgGtNVSm6bdoRqKqeOiYh2t4vwAZKu9w
To: , 
Cc: , 
X-OriginalArrivalTime: 19 Nov 2002 16:52:02.0697 (UTC) FILETIME=[FBF43F90:01C28FEB]
Content-Length: 5735
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA06517
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: 

Jonathan,

I think this is a good idea. The problem really was that while we were trying to treat lists as part of the event, they really were not. So separating the list handling from the actual event is a good idea, and I think you nailed it here.

Cheers,
Aki

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, November 19, 2002 6:41 AM
> To: Paul Kyzivat
> Cc: Adam Roach; simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] Thoughts on list template
> 
> 
> inline.
> 
> Paul Kyzivat wrote:
>  >
>  > Adam Roach wrote:
>  >
>  >> Basically, it amounts to this: to give the capabilities that
>  >> several people want (e.g. arbitrary depth lists) without 
> abandoning
>  >> templates, we could slightly tweak the meaning of the ".list"
>  >> template. In particular, "foo.list" would refer to any arbitrary
>  >> nesting of foo objects; e.g., it would cover what is, under the
>  >> current draft, called any of foo.list, foo.list.list,
>  >> foo.list.list.list, ad infinitum.
>  >
>  > ...
>  >
>  >> So, first: does anyone see anything that would prevent this
>  >> working, from a technical perspective?
>  >
>  >
>  > I too hope something like this works. I think we need to dig into
>  > details a bit to figure out if it is going to work.
>  >
>  > 1) Does this imply that the server serving an instance of foo.list
>  > itself issues the subscriptions to all the leaves of the recursive
>  > list expansion? Or is it just responsible for delegating those? Or
>  > are both approaches valid? (They may have different authentication
>  > implications.) The pure template approach clearly implied 
> delegating
>  > the responsibility for the leaf subscriptions.
> 
> I don't see the difference between the two things?
> 
>  >
>  > 2) Either way, the server for foo.list is now responsible for
>  > determining if a particular list entry is an instance of foo, or of
>  > foo.list. Do we have any better way to figure this out 
> than trial and
>  > error? Is that acceptable? (An alternative might be to explicitly
>  > type the entries in a list.)
> 
> This is the big issue.
> 
> It might help to step back and consider how this would work 
> in an IDEAL 
> world of a clean slate, and work backwards. Doing that is 
> what helped us 
> figure out how to do loose routing, and as it turns out, I think it 
> solves this problem too.
> 
> In the ideal world,  there is no presence package. 
> There is only 
> the equivalent of "presence.list". That is, we assume at the 
> outset that 
> a presence subscription always implies a list, and a valid 
> option is a 
> list of one. Thus, I subscribe to my buddylist with package 
> "presence", 
> and each of the subscriptions it generates are for the same package, 
> "presence". The owner of the URI gets to decide whether its a list of 
> multiple elements, or just one.
> 
> Now, the problem of course is that all of the list features 
> would need 
> to be replicated in each package. So, the ideal solution there IMHO 
> would have been to have list processing be central to rfc3265 in the 
> first place, so that all packages are list enabled from the outset.
> 
> OK, so IF you agree that this is what it ought to have been, 
> how do we 
> achieve as close a goal as possible with the constraints that we have?
> 
> I would define list processing as an EXTENSION to rfc3265, not a 
> template or a new package. How would that work? When a UAC 
> subscribes, 
> it includes a Supported header indicated "lists". The Allow header in 
> the subscribe also lists multipart as a valid body type thats 
> supported, 
> along with the MIME type of this XML list meta-data. So, a buddy list 
> subscription looks like:
> 
> SUBSCRIBE sip:mylist@domain.com SIP/2.0
> Supported: lists
> Allow: application/pidf+xml, multipart/mixed, application/elist+xml
> Event: presence
> 
> The server knows that mylist is a list, but since the client supports 
> lists, its OK. The server does a SUBSCRIBE to each participant in the 
> list, all of them with the Event: presence header, and all of 
> them with 
> the same Supported and Allow headers. Now, should one of 
> those happen to 
> be a regular presence server that doesn't support the "lists" 
> extension, 
> it works just fine! The server will generate NOTIFYs with plain-old 
> PIDF, no multipart or elist+xml. So, there is no trial-and-error; a 
> subscription to an element in the list is the same in all cases, and 
> doesn't require knowing what it is. If it turns out that its a list, 
> multipart comes back. If not, just plain PIDF.
> 
> Should a user SUBSCRIBE to a list, and not indicate support 
> for "lists" 
> in the Supported header, the server rejects the request with 
> a 420 and 
> the appropriate Require header.
> 
> As far as I can tell, this solution buys us EVERYTHING we want:
> 
> * infinite nesting of lists, without the list server needing to know 
> whether an entry is a list or not
> * no trial and error
> * backwards compatibility
> * graceful evolution, if we want, to a revised rfc3265 that 
> includes the 
> list processing as a native capability
> 
> 
> Comments?
> 
> -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 mikko.lonnfors@nokia.com  Tue Nov 19 14:02:59 2002
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 OAA07033
	for ; Tue, 19 Nov 2002 14:02:58 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJJ2RO24782
	for ; Tue, 19 Nov 2002 21:02:27 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 19 Nov 2002 21:02:38 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 19 Nov 2002 21:02:37 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C28FFE.394FE73C"
Subject: RE: [Simple] PAM and SIMPLE
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Tue, 19 Nov 2002 21:02:36 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5C@esebe004.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] PAM and SIMPLE
Thread-Index: AcKPfHPWt3e+ifGPRJGAQZxmKVKA+QAa6wBg
To: , 
X-OriginalArrivalTime: 19 Nov 2002 19:02:37.0289 (UTC) FILETIME=[39BC1D90:01C28FFE]
Content-Length: 4517
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: 

This is a multi-part message in MIME format.

------_=_NextPart_001_01C28FFE.394FE73C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
=20
I am not sure what APIs you are referring to but here is one answer. =
SIMPLE and PAM APIs are at least being defined within Java Community =
Processes (JCP). There are separate items for both SIMPLE API and PAM =
API. The work mode in JCP is different compared to IETF and as a result =
API design and discussion is limited to expert group members until work =
becomes public. You can check status from JCP web site or contact the =
expert group lead if you have further questions.
=20
simple:
http://www.jcp.org/en/jsr/detail?id=3D164
http://www.jcp.org/en/jsr/detail?id=3D165
=20
pam:
http://www.jcp.org/en/jsr/detail?id=3D123
=20
BR
- Mikko

-----Original Message-----
From: ext Deepankar [mailto:deepankarb@huawei.com]
Sent: 19 November, 2002 05:28
To: simple@mailman.dynamicsoft.com
Subject: [Simple] PAM and SIMPLE


Sorry to barge in... but could anybody redirect me to a mailing list for =
discussion on SIMPLE and PAM API mapping.
=20
/deeps


------_=_NextPart_001_01C28FFE.394FE73C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I am=20
not sure what APIs you are referring to but here is one answer. SIMPLE =
and PAM=20
APIs are at least being defined within Java Community Processes (JCP). =
There are=20
separate items for both SIMPLE API and PAM API. The work mode in JCP is=20
different compared to IETF and as a result API design and discussion is =
limited=20
to expert group members until work becomes public. You can check =
status=20
from JCP web site or contact the expert group lead if you have further=20
questions.


 


simple:


http://www.jcp.org/en/=
jsr/detail?id=3D164


http://www.jcp.org/en/=
jsr/detail?id=3D165


 


pam:


http://www.jcp.org/en/=
jsr/detail?id=3D123


 


BR


-=20
Mikko



  
-----Original Message-----
From: ext Deepankar=20
  [mailto:deepankarb@huawei.com]
Sent: 19 November, 2002=20
  05:28
To: simple@mailman.dynamicsoft.com
Subject: =
[Simple]=20
  PAM and SIMPLE


  
Sorry to barge in... but could =
anybody redirect=20
  me to a mailing list for discussion on SIMPLE and PAM API=20
mapping.

  
 

  
/deeps


------_=_NextPart_001_01C28FFE.394FE73C--

From Steve.Hanna@sun.com  Mon Nov 18 17:28:19 2002
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03137
	for ; Mon, 18 Nov 2002 17:28:18 -0500 (EST)
Received: from sydney.East.Sun.COM ([129.148.9.16])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11782
	for ; Mon, 18 Nov 2002 14:28:18 -0800 (PST)
Received: from sydney.East.Sun.COM (esun1es-fe-ge0.Holland.Sun.COM [129.159.36.22])
	by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id gAIMSCJ22168;
	Mon, 18 Nov 2002 17:28:13 -0500 (EST)
From: Steve Hanna 
Message-Id: <200211182228.gAIMSCJ22168@sydney.East.Sun.COM>
Date: Mon, 18 Nov 2002 17:28:08 -0500
To: 
Cc: 
Reply-To: 
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Length: 1226
Subject: [Simple] Pointer to standard policy language
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: 

In today's SIMPLE WG session, I promised to send a pointer to the
work going on elsewhere to define a standard access control policy
language.

The language I was referring to is XACML (eXtensible Access Control
Markup Language). It is an XML-based access control policy language
designed to support a wide variety of applications. The spec is
currently in the middle of a 30 day Public Review, so this is a
great time to read it and send your comments. For more info, see
http://www.oasis-open.org/committees/xacml.

There are definite advantages to using a standard language for
expressing access control policies. Developers can reuse existing
code. Users don't need to learn special-purpose languages. Etc.

I would recommend that in defining your protocols, you treat an
access control policy as a blob, allowing users to set or get them
but not defining commands to manipulate the internal contents. This
will allow you to use XACML or any successor language or even to
define your own language if you should decide at some later time
that you want to do so.

I do not subscribe to your WG list, so please cc me on subsequent
discussions of this topic (unless you explicitly want to exclude me!).

Thanks,

Steve Hanna


From mikko.lonnfors@nokia.com  Tue Nov 19 15:17:48 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07419
	for ; Tue, 19 Nov 2002 15:17:47 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJKIZB07632
	for ; Tue, 19 Nov 2002 22:18:36 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 19 Nov 2002 22:17:44 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 19 Nov 2002 22:17:43 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 19 Nov 2002 22:17:42 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Tue, 19 Nov 2002 22:17:42 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5D@esebe004.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
Thread-Index: AcKPKYU0nDXJxM0rRUCdi28v4yvyjgA2bMPw
To: , 
Cc: 
X-OriginalArrivalTime: 19 Nov 2002 20:17:42.0933 (UTC) FILETIME=[B74ED450:01C29008]
Content-Length: 5206
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA07419
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: 

Hi

inline

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: 18 November, 2002 19:37
> To: Jonathan Rosenberg
> Cc: Lonnfors Mikko (NRC/Helsinki); simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] FW: I-D
> ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
> 
> Jonathan Rosenberg wrote:
> >
> >  >> 1. Assuming the watcher "picks" one of the contact 
> addresses, and
> >  >> decides to communicate with it by sending it an INVITE, 
> how should
> >  >> that INVITE look? If the URI in the contact element is 
> the AOR of
> >  >> the user, does the watcher need to add caller preferences
> >  >> (Require-Contact) in order to reach that specific UA instance?
> >  >
> >  > The publisher can identify separate tuples each with a 
> particular set
> >  > of capabilities, and yet provide a single AOR for all of them. In
> >  > that case it is in effect promising to provide a smart 
> proxy at the
> >  > AOR that can do the right thing.
> > 
> > Well, that won't work. How would the proxy know which tuple was
> > intended? The only way it can know is if the caller had 
> placed caller
> > preferences in the request. That was my point - how would the caller
> > know it needs to do that?
> > 
> > I suppose the right answer is to construct the tuple URI like this:
> > 
> > sip:aor@domain?Require-Contact=
> > 
> > that is, you don't rely on the subscriber to insert the 
> caller prefs.
> > The PA does that itself by embedding them in the URI.
> 
> I think this is a matter of semantics. If I, as publisher, 
> say there are two tuples with different attributes, but 
> associate them both with the same AOR, it might mean that I 
> have two devices registered at the same AOR with differing 
> attributes but don't choose to identify their addresses; or 
> it might mean that I have a single device with two different 
> and interesting sets of attributes I choose to advertise.
> 
> The subscriber doesn't know and shouldn't care, as long as it 
> reaches a device with the proper capabilities.
> 
> Having a proxy for the AOR simply fork the request may be 
> sufficient if there are two devices and the characteristics 
> that differentiate them can always be discerned from the 
> initial request. This isn't going to be the case very often, 
> but since the publisher is in the driver seat it should be 
> his problem to decide this.
> 
> Nevertheless, I agree that in general it would be best for 
> the presence publisher to do as you suggest and embed the 
> callerprefs headers in the contact address. Toward that end, 
> I think we had better specify somewhere that contact 
> addresses in presence may indeed contain embedded headers, 
> since they aren't universally accepted.

This may need bit more consideration. Embedding the caller preferences headers into contact address might make sense in a case where publisher has registered using caller preferences. I can also see use cases where presentity wants to embed feature tags into presence info but chooses not to register those to registrar (I want to show support for voice but I don't want my proxy to act differently). Other side of this problem is that this model seems to require callerprefs support from watcher side. How is the watcher expected to behave if it receives a contact URI with all different callerprefs headers it does not understand? This procedure seems also to duplicate the information in the presence document. It is first presented inside XML structures and then second time in contact URI. This may not be a huge problem but it isn't very nice either.

Well, in any case I think Jonathan is right that watcher should have a simple mechanism how to send request to presentity. One option could be that XML structure includes some kind of instructions to watcher how the Request based on presence info should be constructed. This would eliminate the duplication problem and if watcher does not understand callerprefs extension it can just ignore it and behave as callerprefs extension wasn't there in the first place.

> > I think the semantic needs to be simple. The caller invokes 
> the URI in
> > the presence document, period. The server guarnatees that 
> that results
> > in a request being routed to a UA described by the 
> information in the
> > presence document. Thats the contact.
> 
> Yes, this seems to be the best answer.
> 
> >  >> w3c has done a lot of work in describing capabilities 
> (CC/PP, RDF),
> >  >> all of which is XML-based. I wonder if there is a 
> better fit here
> >  >> to use that kind of syntax?
> >  >
> >  >
> >  > Could be.
> > 
> > That seems to be the common answer here... someone needs to do a
> > detailed study and see how it fits.
> 
> I already spoke with Mikko about this. Neither of us are 
> familiar with the W3C work. Will need to figure out who has 
> the time / contacts to do the digging.

If nobody else is going to volunteer for this I can spend some time to figure these things out.

- Mikko

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

From Markus.Isomaki@nokia.com  Tue Nov 19 15:34:24 2002
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 PAA07495
	for ; Tue, 19 Nov 2002 15:34:24 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJKXrO04171
	for ; Tue, 19 Nov 2002 22:33:53 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 19 Nov 2002 22:34:24 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 19 Nov 2002 22:34:24 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] Pointer to standard policy language
Date: Tue, 19 Nov 2002 22:34:24 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Pointer to standard policy language
Thread-Index: AcKQAA7xWLbcfztWQwm6Eljc78kOgwACIBdA
To: , 
X-OriginalArrivalTime: 19 Nov 2002 20:34:24.0855 (UTC) FILETIME=[0C7FFE70:01C2900B]
Content-Length: 2943
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA07495
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: 

Hi Steve,

Thanks for the pointer.

Before getting deeper into the details, I would like to know a couple of basic points about XACML's applicability in this case. In my opinion the standardized protocols to setup presence policy rules are most valuable for wireless terminals with small displays, since using a web browser aside of SIP client is quite clumsy with them.

If we assume the XACML document would be a blob, that the client can just read and replace, would that be feasible over low-bandwidth links (say, <50 kps)? This depends on how big the documents would get, and wheter ALL the information, such as URI lists, would be included in the same blob (document). For instance, if reactive authorization works so that a SIP URI is appended to some list, I don't think it makes sense to send the whole policy doc. to the server. 

In my opinion the protocol should have some light-weigth procedures to do the most common operations, such as adding and deleting URIs (assuming the authorization model in the requirements draft).

Would it still make sense to use XACML, and use some simple XML manipulation operations on it, to achieve this?

I'll do some calculations to see whether this will be critical or not in real-life systems.

Markus  

> -----Original Message-----
> From: ext Steve Hanna [mailto:Steve.Hanna@sun.com]
> Sent: 19 November, 2002 00:28
> To: simple@mailman.dynamicsoft.com
> Cc: steve.hanna@sun.com
> Subject: [Simple] Pointer to standard policy language
> 
> 
> In today's SIMPLE WG session, I promised to send a pointer to the
> work going on elsewhere to define a standard access control policy
> language.
> 
> The language I was referring to is XACML (eXtensible Access Control
> Markup Language). It is an XML-based access control policy language
> designed to support a wide variety of applications. The spec is
> currently in the middle of a 30 day Public Review, so this is a
> great time to read it and send your comments. For more info, see
> http://www.oasis-open.org/committees/xacml.
> 
> There are definite advantages to using a standard language for
> expressing access control policies. Developers can reuse existing
> code. Users don't need to learn special-purpose languages. Etc.
> 
> I would recommend that in defining your protocols, you treat an
> access control policy as a blob, allowing users to set or get them
> but not defining commands to manipulate the internal contents. This
> will allow you to use XACML or any successor language or even to
> define your own language if you should decide at some later time
> that you want to do so.
> 
> I do not subscribe to your WG list, so please cc me on subsequent
> discussions of this topic (unless you explicitly want to exclude me!).
> 
> Thanks,
> 
> Steve Hanna
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From Markus.Isomaki@nokia.com  Tue Nov 19 15:55:40 2002
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 PAA07585
	for ; Tue, 19 Nov 2002 15:55:39 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJKt9O10223
	for ; Tue, 19 Nov 2002 22:55:09 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Tue, 19 Nov 2002 22:55:40 +0200
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Tue, 19 Nov 2002 22:55:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Tue, 19 Nov 2002 22:55:39 +0200
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] Pointer to standard policy language
Thread-Index: AcKQAA7xWLbcfztWQwm6Eljc78kOgwACIBdAAADYQiA=
To: , ,
        
X-OriginalArrivalTime: 19 Nov 2002 20:55:40.0290 (UTC) FILETIME=[04B7EE20:01C2900E]
Content-Length: 666
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA07585
Subject: [Simple] Data manipulation
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: 

Hi,

There hasn't been too much interest or comments on the Data Manipulation in SIMPLE, excluding the authors of the drafts. I would like to find out who is really interested in this, and would be even willing to contribute to the drafts.

So, could all those people send me e-mail saying:
a) I think we should get this standardized, but I don't have time for it right now; or
b) I would be willing to help solving the technical problems

I also propose that we meet briefly after tomorrow's SIPPING session (15:30-17:30) somewhere around the chairs' desk to see who we are. I'm the one who was presenting the list manipulation semantics draft yesterday.

Markus



From rsparks@dynamicsoft.com  Tue Nov 19 16:08:43 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07656
	for ; Tue, 19 Nov 2002 16:08:43 -0500 (EST)
Received: from RjS.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gAJL8i127267
	for ; Tue, 19 Nov 2002 15:08:44 -0600
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 19 Nov 2002 16:08:08 -0500
Message-Id: <1037740088.1253.9.camel@RjS.localdomain>
Mime-Version: 1.0
Content-Length: 275
Subject: [Simple] Notes and slides
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: 

Rough notes and the slides from the IETF55 SIMPLE
meeting are available at
http://www.softarmor.com/simple/meets/ietf55

Please send corrections to the notes to the list.

Send corrections to the slides (or error reports
concerning the SIMPLE weblet) directly to me.

RjS




From pkyzivat@cisco.com  Tue Nov 19 16:51:53 2002
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 QAA07821
	for ; Tue, 19 Nov 2002 16:51:53 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJLqAxQ011588;
	Tue, 19 Nov 2002 16:52:10 -0500 (EST)
Received: from cisco.com (rtp-vpn2-642.cisco.com [10.82.242.130])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAV16766;
	Tue, 19 Nov 2002 16:56:41 -0500 (EST)
Message-ID: <3DDAB270.439918E7@cisco.com>
Date: Tue, 19 Nov 2002 16:51:44 -0500
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: mikko.lonnfors@nokia.com
CC: jdrosen@dynamicsoft.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5D@esebe004.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 3028
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: 


mikko.lonnfors@nokia.com wrote:
> 
> This may need bit more consideration. Embedding the caller preferences headers into contact address might make sense in a case where publisher has registered using caller preferences. I can also see use cases where presentity wants to embed feature tags into presence info but chooses not to register those to registrar (I want to show support for voice but I don't want my proxy to act differently).

Certainly the publisher can do this if it wants to. May make sense in some cases.

> Other side of this problem is that this model seems to require callerprefs support from watcher side. How is the watcher expected to behave if it receives a contact URI with all different callerprefs headers it does not understand?

I don't see this as a problem. As long as watchers understand that the contacts may have embedded headers, and know generically what to do with them. (And 3261 says what to do with them.) The watcher doesn't have to understand or support the headers to insert them in a request.

> This procedure seems also to duplicate the information in the presence document. It is first presented inside XML structures and then second time in contact URI. This may not be a huge problem but it isn't very nice either.

Yes, it is less than desirable. But it seems to show up in many contexts, such as duplication of headers in sipfrags for security purposes. It may be the lesser of evils.

> 
> Well, in any case I think Jonathan is right that watcher should have a simple mechanism how to send request to presentity. One option could be that XML structure includes some kind of instructions to watcher how the Request based on presence info should be constructed. This would eliminate the duplication problem and if watcher does not understand callerprefs extension it can just ignore it and behave as callerprefs extension wasn't there in the first place.

I don't understand this. What form would these "instructions" take? How would they affect the resulting request beyond using the contact address? I don't see what they could achieve that couldn't be achieved by attaching headers to the contact address.

> > >  >> w3c has done a lot of work in describing capabilities
> > (CC/PP, RDF),
> > >  >> all of which is XML-based. I wonder if there is a
> > better fit here
> > >  >> to use that kind of syntax?
...
> > > That seems to be the common answer here... someone needs to do a
> > > detailed study and see how it fits.
...
> If nobody else is going to volunteer for this I can spend some time to figure these things out.

Thanks. I would like to look into this too, but I've got to figure out what is on my plate at home before I commit.

I want to suggest a requirement here: We must ensure that this remains semantically a superset of what is used to represent capabilities in registrations. (callerprefs) This could be an important constraint because many mechanisms are likely to have different namespaces and registration rules for capabilities/attributes.

	Paul

From mikko.lonnfors@nokia.com  Tue Nov 19 18:45:42 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08182
	for ; Tue, 19 Nov 2002 18:45:37 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAJNkSB20668
	for ; Wed, 20 Nov 2002 01:46:28 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 20 Nov 2002 01:45:38 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 20 Nov 2002 01:45:38 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Wed, 20 Nov 2002 01:45:38 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5F@esebe004.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
Thread-Index: AcKQFeQ+OnMvaetsSz22XadhgoXPewAC+98A
To: 
Cc: , 
X-OriginalArrivalTime: 19 Nov 2002 23:45:38.0630 (UTC) FILETIME=[C3671E60:01C29025]
Content-Length: 4532
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id SAA08182
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: 

Hi,

Inline

> mikko.lonnfors@nokia.com wrote:
> > 
> > This may need bit more consideration. Embedding the caller 
> preferences headers into contact address might make sense in 
> a case where publisher has registered using caller 
> preferences. I can also see use cases where presentity wants 
> to embed feature tags into presence info but chooses not to 
> register those to registrar (I want to show support for voice 
> but I don't want my proxy to act differently).
> 
> Certainly the publisher can do this if it wants to. May make 
> sense in some cases.
> 
> > Other side of this problem is that this model seems to 
> require callerprefs support from watcher side. How is the 
> watcher expected to behave if it receives a contact URI with 
> all different callerprefs headers it does not understand?
> 
> I don't see this as a problem. As long as watchers understand 
> that the contacts may have embedded headers, and know 
> generically what to do with them. (And 3261 says what to do 
> with them.) The watcher doesn't have to understand or support 
> the headers to insert them in a request.

ok, then it should be explained somewhere that contact element URIs can contain embedded headers and how those should be processed. I am not sure is this draft the place to do it but on the other hand I cannot figure out any better place either. 
 
> > This procedure seems also to duplicate the information in 
> the presence document. It is first presented inside XML 
> structures and then second time in contact URI. This may not 
> be a huge problem but it isn't very nice either.
> 
> Yes, it is less than desirable. But it seems to show up in 
> many contexts, such as duplication of headers in sipfrags for 
> security purposes. It may be the lesser of evils.

As I said this may not be such a big problem but my view still is that if this can be avoided it should be avoided.

> > 
> > Well, in any case I think Jonathan is right that watcher 
> should have a simple mechanism how to send request to 
> presentity. One option could be that XML structure includes 
> some kind of instructions to watcher how the Request based on 
> presence info should be constructed. This would eliminate the 
> duplication problem and if watcher does not understand 
> callerprefs extension it can just ignore it and behave as 
> callerprefs extension wasn't there in the first place.
> 
> I don't understand this. What form would these "instructions" 
> take? How would they affect the resulting request beyond 
> using the contact address? I don't see what they could 
> achieve that couldn't be achieved by attaching headers to the 
> contact address.

I probably wasn't clear enough. I was thinking to desing something like this:

  ..
  ..
	
	  
		audio
	  
	
	sip:user@domain.com


The  element could have an attribute called 'required' or something similar. When watcher would get this info it would take the contact as Request-URI and then generate Require-Contact based on 'required' attributes. This would solve the duplication problem and also embedded header problem (if it was a problem in the first place). This would put little more responsibility on watcher side as watcher would construct Require-Contact headers based on info found in XML. This was just to show that there might be some alternatives to do this. Hopefully it is now bit clearer.

> > > >  >> w3c has done a lot of work in describing capabilities
> > > (CC/PP, RDF),
> > > >  >> all of which is XML-based. I wonder if there is a
> > > better fit here
> > > >  >> to use that kind of syntax?
> ...
> > > > That seems to be the common answer here... someone needs to do a
> > > > detailed study and see how it fits.
> ...
> > If nobody else is going to volunteer for this I can spend 
> some time to figure these things out.
> 
> Thanks. I would like to look into this too, but I've got to 
> figure out what is on my plate at home before I commit.
> 
> I want to suggest a requirement here: We must ensure that 
> this remains semantically a superset of what is used to 
> represent capabilities in registrations. (callerprefs) This 
> could be an important constraint because many mechanisms are 
> likely to have different namespaces and registration rules 
> for capabilities/attributes.

This sounds like a good idea. Could you still elaborate the last sentence a bit. I am not sure I completely got it.

- Mikko

> 	Paul
> 

From arun.gopalakrishnan@rd.francetelecom.com  Tue Nov 19 19:10:19 2002
Received: from u-mail.rd.francetelecom.com (u-mail.rd.francetelecom.com [208.25.178.63])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08327
	for ; Tue, 19 Nov 2002 19:10:19 -0500 (EST)
Received: by U-MAIL with Internet Mail Service (5.5.2653.19)
	id ; Tue, 19 Nov 2002 16:10:18 -0800
Message-ID: <037E7050631FD611AAFD0002A509146A345E6C@U-MAIL2>
From: GOPALAKRISHNAN Arun / FTR&D US
	 
To: "'Deepankar'" ,
        "'simple@mailman.dynamicsoft.com'" 
Subject: RE: [Simple] PAM and SIMPLE
Date: Tue, 19 Nov 2002 16:12:26 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C29029.81D9F900"
Content-Length: 1714
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: 

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_01C29029.81D9F900
Content-Type: text/plain;
	charset="iso-8859-1"

You may want to check with PAM forum. Apparently there's some activity on
PAM/SIMPLE mapping.



-----Original Message-----
From: Deepankar [mailto:deepankarb@huawei.com]
Sent: Monday, November 18, 2002 7:32 PM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] PAM and SIMPLE


Sorry to barge in... but could anybody redirect me to a mailing list for
discussion on SIMPLE and PAM API mapping.

/deeps

------_=_NextPart_001_01C29029.81D9F900
Content-Type: text/html;
	charset="iso-8859-1"






RE: [Simple] PAM and SIMPLE




You may want to check with PAM forum. Apparently there's some activity on PAM/SIMPLE mapping.








-----Original Message-----

From: Deepankar [mailto:deepankarb@huawei.com]

Sent: Monday, November 18, 2002 7:32 PM

To: simple@mailman.dynamicsoft.com

Subject: [Simple] PAM and SIMPLE






Sorry to barge in... but could anybody redirect me to a mailing list for discussion on SIMPLE and PAM API mapping.




/deeps





------_=_NextPart_001_01C29029.81D9F900--

From pkyzivat@cisco.com  Tue Nov 19 22:12:01 2002
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 WAA08910
	for ; Tue, 19 Nov 2002 22:12:01 -0500 (EST)
Received: from cannon.cisco.com (localhost [127.0.0.1])
	by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAK3CDFT009804;
	Tue, 19 Nov 2002 22:12:18 -0500 (EST)
Received: from cisco.com (rtp-vpn2-694.cisco.com [10.82.242.182])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAV18411;
	Tue, 19 Nov 2002 22:16:36 -0500 (EST)
Message-ID: <3DDAD58C.32881310@cisco.com>
Date: Tue, 19 Nov 2002 19:21:32 -0500
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: mikko.lonnfors@nokia.com
CC: jdrosen@dynamicsoft.com, simple@mailman.dynamicsoft.com
Subject: Re: [Simple] FW: I-D ACTION:draft-lonnfors-simple-prescaps-ext-00.txt
References: <0C1353ABB1DEB74DB067ADFF749C4EEFFFBD5F@esebe004.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1492
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: 


mikko.lonnfors@nokia.com wrote:
> 
> > I want to suggest a requirement here: We must ensure that
> > this remains semantically a superset of what is used to
> > represent capabilities in registrations. (callerprefs) This
> > could be an important constraint because many mechanisms are
> > likely to have different namespaces and registration rules
> > for capabilities/attributes.
> 
> This sounds like a good idea. Could you still elaborate the last sentence a bit. I am not sure I completely got it.

In draft-kyzivat-simple-prescaps-reqts-00 I reference the need to represent any feature tag. The feature tags used in callerprefs are defined by reference in rfc 2506.

It defines the syntax of feature tags, a partitioning into different namespaces, and different registration procedures for the namespaces. 

Callerprefs also uses rfc 2533 to define the semantics of feature sets. But it doesn't support the full range of semantics defined by 2533 - it uses only a subset that can be mapped onto the parameter syntax in a simple way.

So, if some existing specification is used to represent combinations of features/capabilities in PIDF, then it needs to have the capability to use any of the feature tags legal according to 2506, and any of the feature sets that can also be represented by callerprefs. The obvious selection is rfc 2533 itself, mapped into xml. 

This of course assumes that callerprefs doesn't change again. But I think it is important to track callerprefs.

	Paul


From tanglih@cn.ibm.com  Wed Nov 20 01:47:16 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09601
	for ; Wed, 20 Nov 2002 01:47:14 -0500 (EST)
Received: from d23rh901.au.ibm.com (d23rh901.au.ibm.com [9.185.167.100])
	by ausmtp01.au.ibm.com (8.12.1/8.12.1) with ESMTP id gAK6lNoX246558
	for ; Wed, 20 Nov 2002 17:47:23 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.181.2.75])
	by d23rh901.au.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAK6fo4E099578
	for ; Wed, 20 Nov 2002 17:41:51 +1100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Wed, 20 Nov 2002 14:46:09 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.9a |January 7, 2002) at
 20/11/2002 14:46:11
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 341
Subject: [Simple] Confused by collection template vs. list presence event
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: 

Hi,

When I try to implement some application related to group presence, I am
confused to choose the way to handle the presence list subscription. Who
can tell me what's the difference of ideas in
draft-roach-sip-list-template-00.txt vs.
draft-ietf-simple-presencelist-package-00.txt?

Best regards,

Tang Lihua
Email:  tanglih@cn.ibm.com


From hisham.khartabil@nokia.com  Wed Nov 20 09:37:49 2002
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 JAA10993
	for ; Wed, 20 Nov 2002 09:37:48 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKEbGO12409
	for ; Wed, 20 Nov 2002 16:37:16 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Wed, 20 Nov 2002 16:37:41 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 20 Nov 2002 16:37:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 20 Nov 2002 16:37:40 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FE9@esebe019.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: who changes im: pres: to sip:
Thread-Index: AcKQomA5IbUD9/GEQquwCWoDME7+yA==
To: 
X-OriginalArrivalTime: 20 Nov 2002 14:37:40.0513 (UTC) FILETIME=[60EE5910:01C290A2]
Content-Length: 826
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id JAA10993
Subject: [Simple] who changes im: pres: to sip:
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: 

Hi,

Most of us heard the discussion at impp wg meeting about schemes, but there was no consensus on who changes the scheme.

There are 2 suggestions:

1. change it to sip as soon as possible, as instructed by presence-07
2. Leave it to the terminating domain. I.e. the domain responsible.

Which one of the above should we do? If we choose 2, should presence I-D be changed to reflect that?

I'm referring to the text:

"When subscribing to a presentity, the subscription can be addressed
   using the protocol independent form or the SIP or SIPS URI form. In
   the SIP context, "addressed" refers to the Request-URI. It is
   RECOMMENDED that if the entity sending a SUBSCRIBE is capable of
   resolving the protocol independent form to the SIP form, this
   resolution is done before sending the request"

Regards,
Hisham

From bcampbell@dynamicsoft.com  Wed Nov 20 10:37:05 2002
Received: from magus.nostrum.com (gw-ext.nostrum.com [208.21.192.129] (may be forged))
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11237
	for ; Wed, 20 Nov 2002 10:37:04 -0500 (EST)
Received: from dynamicsoft.com (root@magus.nostrum.com [10.10.10.2])
	by magus.nostrum.com (8.12.5/8.12.5) with ESMTP id gAKFanhd013267;
	Wed, 20 Nov 2002 09:36:49 -0600 (CST)
Message-ID: <3DDBAC0E.7020204@dynamicsoft.com>
Date: Wed, 20 Nov 2002 10:36:46 -0500
From: Ben Campbell 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: Paul Kyzivat , Adam Roach ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Thoughts on list template
References: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com> <3DD9822E.9AA9D9D1@cisco.com> <3DD9C0DE.1050008@dynamicsoft.com>
X-Enigmail-Version: 0.65.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 5245
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: 

This certainly seems like an elegant way to allow assymetric hierachies. 
There are a few areas that give me heartburn, but on reflection, I 
realize these issues are with the idea of recursive lists in the first 
place.

1) We talk about the idea that a watcher can infer list contents from an 
initial full state notify. But it is not entirely clear to me what a 
full state notify looks like for a list that contains other lists. Do we 
expect the watcher to be able to infer the full hiearchy?

2) Robert mentioned a scary one to me this morning: What about circular 
references in lists?

Jonathan Rosenberg wrote:
> inline.
> 
> Paul Kyzivat wrote:
>  >
>  > Adam Roach wrote:
>  >
>  >> Basically, it amounts to this: to give the capabilities that
>  >> several people want (e.g. arbitrary depth lists) without abandoning
>  >> templates, we could slightly tweak the meaning of the ".list"
>  >> template. In particular, "foo.list" would refer to any arbitrary
>  >> nesting of foo objects; e.g., it would cover what is, under the
>  >> current draft, called any of foo.list, foo.list.list,
>  >> foo.list.list.list, ad infinitum.
>  >
>  > ...
>  >
>  >> So, first: does anyone see anything that would prevent this
>  >> working, from a technical perspective?
>  >
>  >
>  > I too hope something like this works. I think we need to dig into
>  > details a bit to figure out if it is going to work.
>  >
>  > 1) Does this imply that the server serving an instance of foo.list
>  > itself issues the subscriptions to all the leaves of the recursive
>  > list expansion? Or is it just responsible for delegating those? Or
>  > are both approaches valid? (They may have different authentication
>  > implications.) The pure template approach clearly implied delegating
>  > the responsibility for the leaf subscriptions.
> 
> I don't see the difference between the two things?
> 
>  >
>  > 2) Either way, the server for foo.list is now responsible for
>  > determining if a particular list entry is an instance of foo, or of
>  > foo.list. Do we have any better way to figure this out than trial and
>  > error? Is that acceptable? (An alternative might be to explicitly
>  > type the entries in a list.)
> 
> This is the big issue.
> 
> It might help to step back and consider how this would work in an IDEAL 
> world of a clean slate, and work backwards. Doing that is what helped us 
> figure out how to do loose routing, and as it turns out, I think it 
> solves this problem too.
> 
> In the ideal world,  there is no presence package. There is only 
> the equivalent of "presence.list". That is, we assume at the outset that 
> a presence subscription always implies a list, and a valid option is a 
> list of one. Thus, I subscribe to my buddylist with package "presence", 
> and each of the subscriptions it generates are for the same package, 
> "presence". The owner of the URI gets to decide whether its a list of 
> multiple elements, or just one.
> 
> Now, the problem of course is that all of the list features would need 
> to be replicated in each package. So, the ideal solution there IMHO 
> would have been to have list processing be central to rfc3265 in the 
> first place, so that all packages are list enabled from the outset.
> 
> OK, so IF you agree that this is what it ought to have been, how do we 
> achieve as close a goal as possible with the constraints that we have?
> 
> I would define list processing as an EXTENSION to rfc3265, not a 
> template or a new package. How would that work? When a UAC subscribes, 
> it includes a Supported header indicated "lists". The Allow header in 
> the subscribe also lists multipart as a valid body type thats supported, 
> along with the MIME type of this XML list meta-data. So, a buddy list 
> subscription looks like:
> 
> SUBSCRIBE sip:mylist@domain.com SIP/2.0
> Supported: lists
> Allow: application/pidf+xml, multipart/mixed, application/elist+xml
> Event: presence
> 
> The server knows that mylist is a list, but since the client supports 
> lists, its OK. The server does a SUBSCRIBE to each participant in the 
> list, all of them with the Event: presence header, and all of them with 
> the same Supported and Allow headers. Now, should one of those happen to 
> be a regular presence server that doesn't support the "lists" extension, 
> it works just fine! The server will generate NOTIFYs with plain-old 
> PIDF, no multipart or elist+xml. So, there is no trial-and-error; a 
> subscription to an element in the list is the same in all cases, and 
> doesn't require knowing what it is. If it turns out that its a list, 
> multipart comes back. If not, just plain PIDF.
> 
> Should a user SUBSCRIBE to a list, and not indicate support for "lists" 
> in the Supported header, the server rejects the request with a 420 and 
> the appropriate Require header.
> 
> As far as I can tell, this solution buys us EVERYTHING we want:
> 
> * infinite nesting of lists, without the list server needing to know 
> whether an entry is a list or not
> * no trial and error
> * backwards compatibility
> * graceful evolution, if we want, to a revised rfc3265 that includes the 
> list processing as a native capability
> 
> 
> Comments?
> 
> -Jonathan R.
> 
> 



From seancolson@yahoo.com  Wed Nov 20 10:56:54 2002
Received: from web20703.mail.yahoo.com (web20703.mail.yahoo.com [216.136.226.176])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id KAA11349
	for ; Wed, 20 Nov 2002 10:56:53 -0500 (EST)
Message-ID: <20021120155650.95949.qmail@web20703.mail.yahoo.com>
Received: from [204.42.69.176] by web20703.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 07:56:50 PST
Date: Wed, 20 Nov 2002 07:56:50 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] Thoughts on list template
To: Ben Campbell ,
        Jonathan Rosenberg 
Cc: Paul Kyzivat , Adam Roach ,
        simple@mailman.dynamicsoft.com
In-Reply-To: <3DDBAC0E.7020204@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1459
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: 

--- Ben Campbell  wrote:
> This certainly seems like an elegant way to allow
> assymetric hierachies. 
> There are a few areas that give me heartburn, but on
> reflection, I 
> realize these issues are with the idea of recursive
> lists in the first 
> place.
> 
> 1) We talk about the idea that a watcher can infer
> list contents from an 
> initial full state notify. But it is not entirely
> clear to me what a 
> full state notify looks like for a list that
> contains other lists. Do we 
> expect the watcher to be able to infer the full
> hiearchy?

I don't think this is necessary, but certainly
possible -- if a bit of a pain. The hierarchy of
the MIME plus the tuple ID plus the presentity URI
plus the From: URI in the NOTIFY gives the watcher
enough info to reconstruct this hierarchy if it
really wanted to.... but is this a requirement? 
I'm assuming the watcher has a notion of the
hiearchy of the list it is subscribing to -- even 
though that may be an incomplete view. The watcher
could render the NOTIFYs relative to his own view of
the list, relative to the hierarchy in the NOTIFYs,
or even "flat".

> 
> 2) Robert mentioned a scary one to me this morning:
> What about circular 
> references in lists?

Could a common Call-ID be used to break these loops? 
/sean


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

From seancolson@yahoo.com  Wed Nov 20 11:02:52 2002
Received: from web20705.mail.yahoo.com (web20705.mail.yahoo.com [216.136.226.178])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id LAA11394
	for ; Wed, 20 Nov 2002 11:02:51 -0500 (EST)
Message-ID: <20021120160252.34308.qmail@web20705.mail.yahoo.com>
Received: from [204.42.69.176] by web20705.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 08:02:52 PST
Date: Wed, 20 Nov 2002 08:02:52 -0800 (PST)
From: Sean Olson 
Subject: Re: [Simple] who changes im: pres: to sip:
To: hisham.khartabil@nokia.com, simple@mailman.dynamicsoft.com
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE6FE9@esebe019.ntc.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 1785
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: 

It sounds like the text you reference answers 
the question. Do it as soon as possible, 
preferably before you send the request. Different
environments and clients may do this at different
times depending on your view of "as soon as possible".
I think (1) is the right answer, though that might
be identical to (2) is some rare cases.

The SRV resolution that was discussion in IMPP
solves the next hop problem. It did not directly
address translation of an im: *URI* to a sip: *URI*.
Shouldn't this be left to local policy/implementation?

/sean

--- hisham.khartabil@nokia.com wrote:
> Hi,
> 
> Most of us heard the discussion at impp wg meeting
> about schemes, but there was no consensus on who
> changes the scheme.
> 
> There are 2 suggestions:
> 
> 1. change it to sip as soon as possible, as
> instructed by presence-07
> 2. Leave it to the terminating domain. I.e. the
> domain responsible.
> 
> Which one of the above should we do? If we choose 2,
> should presence I-D be changed to reflect that?
> 
> I'm referring to the text:
> 
> "When subscribing to a presentity, the subscription
> can be addressed
>    using the protocol independent form or the SIP or
> SIPS URI form. In
>    the SIP context, "addressed" refers to the
> Request-URI. It is
>    RECOMMENDED that if the entity sending a
> SUBSCRIBE is capable of
>    resolving the protocol independent form to the
> SIP form, this
>    resolution is done before sending the request"
> 
> Regards,
> Hisham
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

From AVSHALOM@il.ibm.com  Wed Nov 20 12:08:07 2002
Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11675
	for ; Wed, 20 Nov 2002 12:08:04 -0500 (EST)
Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22])
	by d12lmsgate-5.de.ibm.com (8.12.3/8.12.3) with ESMTP id gAKH80kL048894
	for ; Wed, 20 Nov 2002 18:08:00 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAKH7wda088770
	for ; Wed, 20 Nov 2002 18:07:59 +0100
In-Reply-To: 
To: "Li Hua Tang" 
Cc: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Confused by collection template vs. list presence event
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
Message-ID: 
From: "Avshalom Houri" 
Date: Wed, 20 Nov 2002 19:07:57 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 20/11/2002 19:07:59,
	Serialize complete at 20/11/2002 19:07:59
Content-Type: multipart/alternative; boundary="=_alternative 005E1B76C2256C77_="
Content-Length: 2859
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: 

This is a multipart message in MIME format.
--=_alternative 005E1B76C2256C77_=
Content-Type: text/plain; charset="US-ASCII"

draft-roach-sip-list-template-00.txt it replaces the presencelist package.
Note however that there might be changes due to recursive application of 
the template.

Avshalom




Li Hua Tang/China/IBM@IBMCN 
Sent by: simple-admin@mailman.dynamicsoft.com
20/11/2002 08:46

To
simple@mailman.dynamicsoft.com
cc

Subject
[Simple] Confused by collection template vs. list presence event







Hi,

When I try to implement some application related to group presence, I am
confused to choose the way to handle the presence list subscription. Who
can tell me what's the difference of ideas in
draft-roach-sip-list-template-00.txt vs.
draft-ietf-simple-presencelist-package-00.txt?

Best regards,

Tang Lihua
Email:  tanglih@cn.ibm.com

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


--=_alternative 005E1B76C2256C77_=
Content-Type: text/html; charset="US-ASCII"



draft-roach-sip-list-template-00.txt it replaces the
presencelist package.

Note however that there might be changes due to recursive
application of the template.



Avshalom












Li Hua Tang/China/IBM@IBMCN


Sent by: simple-admin@mailman.dynamicsoft.com

20/11/2002 08:46








To

simple@mailman.dynamicsoft.com




cc






Subject

[Simple] Confused by collection
template vs. list presence event



















Hi,



When I try to implement some application related to group presence, I am

confused to choose the way to handle the presence list subscription. Who

can tell me what's the difference of ideas in

draft-roach-sip-list-template-00.txt vs.

draft-ietf-simple-presencelist-package-00.txt?



Best regards,



Tang Lihua

Email:  tanglih@cn.ibm.com



_______________________________________________

simple mailing list

simple@mailman.dynamicsoft.com

http://mailman.dynamicsoft.com/mailman/listinfo/simple




--=_alternative 005E1B76C2256C77_=--

From hisham.khartabil@nokia.com  Wed Nov 20 14:27:18 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12134
	for ; Wed, 20 Nov 2002 14:27:17 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKJS6B10443
	for ; Wed, 20 Nov 2002 21:28:06 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 20 Nov 2002 21:27:16 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 20 Nov 2002 21:27:16 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] who changes im: pres: to sip:
Date: Wed, 20 Nov 2002 21:27:15 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FEA@esebe019.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] who changes im: pres: to sip:
Thread-Index: AcKQrk1h+6tOCMggTHevDxTmUzQqVwAG24fw
To: , 
X-OriginalArrivalTime: 20 Nov 2002 19:27:16.0489 (UTC) FILETIME=[D5D1DF90:01C290CA]
Content-Length: 2992
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id OAA12134
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: 

It was mentioned in the discussion at the impp meeting.

What I was trying to ask is if the text in presence-07 is out of date now.

Compare the two:

From presence-07:
"It is RECOMMENDED that if the entity sending a SUBSCRIBE is capable of resolving the protocol independent form to the SIP form, this resolution is done before sending the request"

From Jonathan on a different thread:

> 1. client looks up _pres._sip.somewhere.com in DNS
> 2. client takes the resulting records, and sends the request there. The 
> r-uri remains a pres URI.
> 3. the somewhere.com proxy server understands the pres URI, and applies 
> some local policy to translate the URI.
> 4. Its all sip from there

These are contradicting, in some cases. Do I change the scheme before I send? or do I leave the scheme as is and send?

Regards,
Hisham


> -----Original Message-----
> From: ext Sean Olson [mailto:seancolson@yahoo.com]
> Sent: Wednesday, November 20, 2002 6:03 PM
> To: Khartabil Hisham (NMP/Helsinki); simple@mailman.dynamicsoft.com
> Subject: Re: [Simple] who changes im: pres: to sip:
> 
> 
> It sounds like the text you reference answers 
> the question. Do it as soon as possible, 
> preferably before you send the request. Different
> environments and clients may do this at different
> times depending on your view of "as soon as possible".
> I think (1) is the right answer, though that might
> be identical to (2) is some rare cases.
> 
> The SRV resolution that was discussion in IMPP
> solves the next hop problem. It did not directly
> address translation of an im: *URI* to a sip: *URI*.
> Shouldn't this be left to local policy/implementation?
> 
> /sean
> 
> --- hisham.khartabil@nokia.com wrote:
> > Hi,
> > 
> > Most of us heard the discussion at impp wg meeting
> > about schemes, but there was no consensus on who
> > changes the scheme.
> > 
> > There are 2 suggestions:
> > 
> > 1. change it to sip as soon as possible, as
> > instructed by presence-07
> > 2. Leave it to the terminating domain. I.e. the
> > domain responsible.
> > 
> > Which one of the above should we do? If we choose 2,
> > should presence I-D be changed to reflect that?
> > 
> > I'm referring to the text:
> > 
> > "When subscribing to a presentity, the subscription
> > can be addressed
> >    using the protocol independent form or the SIP or
> > SIPS URI form. In
> >    the SIP context, "addressed" refers to the
> > Request-URI. It is
> >    RECOMMENDED that if the entity sending a
> > SUBSCRIBE is capable of
> >    resolving the protocol independent form to the
> > SIP form, this
> >    resolution is done before sending the request"
> > 
> > Regards,
> > Hisham
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - Let the expert host your site
> http://webhosting.yahoo.com
> 

From jdrosen@dynamicsoft.com  Wed Nov 20 14:49:50 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12222
	for ; Wed, 20 Nov 2002 14:49:50 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.78])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAKJnjYH005056;
	Wed, 20 Nov 2002 14:49:47 -0500 (EST)
Message-ID: <3DDBE758.1090108@dynamicsoft.com>
Date: Wed, 20 Nov 2002 14:49:44 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Avshalom Houri 
CC: Li Hua Tang , simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Confused by collection template vs. list presence event
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1607
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: 

In particular, the most recent discussions on the list suggest that its 
NOT a template, but a sip events extension using the regular presence 
package. So, this will probably change again, but I think we have 
finally found the right solution...

-Jonathan R.

Avshalom Houri wrote:
> 
> draft-roach-sip-list-template-00.txt it replaces the presencelist package.
> Note however that there might be changes due to recursive application of 
> the template.
> 
> Avshalom
> 
> 
> 
> *Li Hua Tang/China/IBM@IBMCN*
> Sent by: simple-admin@mailman.dynamicsoft.com
> 
> 20/11/2002 08:46
> 
> To
> simple@mailman.dynamicsoft.com
> cc
> Subject
> [Simple] Confused by collection template vs. list presence event
> 
> 
> 
> 
> 
> 
> 
> Hi,
> 
> When I try to implement some application related to group presence, I am
> confused to choose the way to handle the presence list subscription. Who
> can tell me what's the difference of ideas in
> draft-roach-sip-list-template-00.txt vs.
> draft-ietf-simple-presencelist-package-00.txt?
> 
> Best regards,
> 
> Tang Lihua
> Email:  tanglih@cn.ibm.com
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

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


From aki.niemi@nokia.com  Wed Nov 20 15:18:54 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12329
	for ; Wed, 20 Nov 2002 15:18:53 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKKJhB02245
	for ; Wed, 20 Nov 2002 22:19:43 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Wed, 20 Nov 2002 22:18:52 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 20 Nov 2002 22:18:51 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 20 Nov 2002 22:18:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] who changes im: pres: to sip:
Date: Wed, 20 Nov 2002 22:18:51 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945096@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] who changes im: pres: to sip:
Thread-Index: AcKQrnT6GDNfUvfxReWSNUG75nr4IgAIJ4eQ
To: , ,
        
X-OriginalArrivalTime: 20 Nov 2002 20:18:51.0635 (UTC) FILETIME=[0AABAC30:01C290D2]
Content-Length: 3203
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA12329
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: 

Hi,

inline.

> It sounds like the text you reference answers 
> the question. Do it as soon as possible, 
> preferably before you send the request. Different
> environments and clients may do this at different
> times depending on your view of "as soon as possible".
> I think (1) is the right answer, though that might
> be identical to (2) is some rare cases.

Well, I would argue that the translation can *never* happen before the request is sent. We can't mandate a direct translation from an IM URI to a SIP URI, and any other translation would be local policy to the GW.

So the Request-URI would always need to have the original im: URI in it. This of course causes problems for proxies that don't recognize the im URI scheme.

My proposal is that the client uses a translation similar to when translating tel URIs. Namely, the im URI is translated into a SIP URI by simply replacing the scheme. Additionally, the URI parameter 'user' is populated with the original scheme which in this case is 'im'.

If I need to contact 'im:foo@bar.com', I resolve the next hop using SRV, and in the request line have the following: 

	MESSAGE sip:foo@bar.com;user=im SIP/2.0

This will enable both cases (1 and 2 below) since a GW can fall back to the direct translation by ignoring the user param. If the local policy dictates some other translation, the user parameter gives enough information to also do that at the GW.

> The SRV resolution that was discussion in IMPP
> solves the next hop problem. It did not directly
> address translation of an im: *URI* to a sip: *URI*.
> Shouldn't this be left to local policy/implementation?

I think the above translation would solve this problem.

Thoughts?

Cheers,
Aki

> --- hisham.khartabil@nokia.com wrote:
> > Hi,
> > 
> > Most of us heard the discussion at impp wg meeting
> > about schemes, but there was no consensus on who
> > changes the scheme.
> > 
> > There are 2 suggestions:
> > 
> > 1. change it to sip as soon as possible, as
> > instructed by presence-07
> > 2. Leave it to the terminating domain. I.e. the
> > domain responsible.
> > 
> > Which one of the above should we do? If we choose 2,
> > should presence I-D be changed to reflect that?
> > 
> > I'm referring to the text:
> > 
> > "When subscribing to a presentity, the subscription
> > can be addressed
> >    using the protocol independent form or the SIP or
> > SIPS URI form. In
> >    the SIP context, "addressed" refers to the
> > Request-URI. It is
> >    RECOMMENDED that if the entity sending a
> > SUBSCRIBE is capable of
> >    resolving the protocol independent form to the
> > SIP form, this
> >    resolution is done before sending the request"
> > 
> > Regards,
> > Hisham
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - Let the expert host your site
> http://webhosting.yahoo.com
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From seancolson@yahoo.com  Wed Nov 20 16:30:30 2002
Received: from web20701.mail.yahoo.com (web20701.mail.yahoo.com [216.136.226.174])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id QAA12570
	for ; Wed, 20 Nov 2002 16:30:29 -0500 (EST)
Message-ID: <20021120213030.52417.qmail@web20701.mail.yahoo.com>
Received: from [204.42.69.176] by web20701.mail.yahoo.com via HTTP; Wed, 20 Nov 2002 13:30:30 PST
Date: Wed, 20 Nov 2002 13:30:30 -0800 (PST)
From: Sean Olson 
Subject: RE: [Simple] who changes im: pres: to sip:
To: aki.niemi@nokia.com, hisham.khartabil@nokia.com,
        simple@mailman.dynamicsoft.com
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945096@esebe013.ntc.nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 4032
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: 

To take your analogy for tel: URIs to completion,
wouldn't we want to represent the entire im: URI in
the user portion of the sip: URI and tack on a
"user=im" parameter?

This seems like an interesting approach but I'm
concerned that the user=im parameter would *have*
to be interpreted by the proxies to do the right
thing. In that case, we would be better off with
sticking with an im: URI in the Request-URI. 

/sean

--- aki.niemi@nokia.com wrote:
> Hi,
> 
> inline.
> 
> > It sounds like the text you reference answers 
> > the question. Do it as soon as possible, 
> > preferably before you send the request. Different
> > environments and clients may do this at different
> > times depending on your view of "as soon as
> possible".
> > I think (1) is the right answer, though that might
> > be identical to (2) is some rare cases.
> 
> Well, I would argue that the translation can *never*
> happen before the request is sent. We can't mandate
> a direct translation from an IM URI to a SIP URI,
> and any other translation would be local policy to
> the GW.
> 
> So the Request-URI would always need to have the
> original im: URI in it. This of course causes
> problems for proxies that don't recognize the im URI
> scheme.
> 
> My proposal is that the client uses a translation
> similar to when translating tel URIs. Namely, the im
> URI is translated into a SIP URI by simply replacing
> the scheme. Additionally, the URI parameter 'user'
> is populated with the original scheme which in this
> case is 'im'.
> 
> If I need to contact 'im:foo@bar.com', I resolve the
> next hop using SRV, and in the request line have the
> following: 
> 
> 	MESSAGE sip:foo@bar.com;user=im SIP/2.0
> 
> This will enable both cases (1 and 2 below) since a
> GW can fall back to the direct translation by
> ignoring the user param. If the local policy
> dictates some other translation, the user parameter
> gives enough information to also do that at the GW.
> 
> > The SRV resolution that was discussion in IMPP
> > solves the next hop problem. It did not directly
> > address translation of an im: *URI* to a sip:
> *URI*.
> > Shouldn't this be left to local
> policy/implementation?
> 
> I think the above translation would solve this
> problem.
> 
> Thoughts?
> 
> Cheers,
> Aki
> 
> > --- hisham.khartabil@nokia.com wrote:
> > > Hi,
> > > 
> > > Most of us heard the discussion at impp wg
> meeting
> > > about schemes, but there was no consensus on who
> > > changes the scheme.
> > > 
> > > There are 2 suggestions:
> > > 
> > > 1. change it to sip as soon as possible, as
> > > instructed by presence-07
> > > 2. Leave it to the terminating domain. I.e. the
> > > domain responsible.
> > > 
> > > Which one of the above should we do? If we
> choose 2,
> > > should presence I-D be changed to reflect that?
> > > 
> > > I'm referring to the text:
> > > 
> > > "When subscribing to a presentity, the
> subscription
> > > can be addressed
> > >    using the protocol independent form or the
> SIP or
> > > SIPS URI form. In
> > >    the SIP context, "addressed" refers to the
> > > Request-URI. It is
> > >    RECOMMENDED that if the entity sending a
> > > SUBSCRIBE is capable of
> > >    resolving the protocol independent form to
> the
> > > SIP form, this
> > >    resolution is done before sending the
> request"
> > > 
> > > Regards,
> > > Hisham
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > >
> >
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Web Hosting - Let the expert host your site
> > http://webhosting.yahoo.com
> > _______________________________________________
> > simple mailing list
> > simple@mailman.dynamicsoft.com
> >
>
http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > 


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

From aki.niemi@nokia.com  Wed Nov 20 17:02:38 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12713
	for ; Wed, 20 Nov 2002 17:02:37 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKM3RR08401
	for ; Thu, 21 Nov 2002 00:03:28 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 21 Nov 2002 00:02:38 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 21 Nov 2002 00:02:37 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] who changes im: pres: to sip:
Date: Thu, 21 Nov 2002 00:02:37 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945097@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] who changes im: pres: to sip:
Thread-Index: AcKQ3A7uYoFFjqAmR6WE/pGyJEF6jQAAWelw
To: , ,
        
X-OriginalArrivalTime: 20 Nov 2002 22:02:37.0765 (UTC) FILETIME=[89BBB750:01C290E0]
Content-Length: 5369
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA12713
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: 

Hi,

> To take your analogy for tel: URIs to completion,
> wouldn't we want to represent the entire im: URI in
> the user portion of the sip: URI and tack on a
> "user=im" parameter?

I'm not sure we'd have to follow the tel URI conventions all the way. The im and SIP URI schemes seem to be pretty similar anyway. And unlike tel, the im URI can't include any URI parameters (I think...) However, if we did follow the tel URI way, we'd run into the problem you describe below. 

> This seems like an interesting approach but I'm
> concerned that the user=im parameter would *have*
> to be interpreted by the proxies to do the right
> thing. In that case, we would be better off with
> sticking with an im: URI in the Request-URI. 

I think having the im URI in the Request-URI is even worse. It would mean that all the proxies in the path of this request would have to support the im URI scheme to be able to route the message at all. With the user-parameter, at least these intermediary proxies would still be able to route the request normally to the owner domain.

The owner proxy of the Request-URI would then have to interpret the user-parameter to do the right thing, at least if the tel URI conventions were applied as they are right now.

However, my preference would be to specify the translation such that the right thing could be done even when ignoring the user-parameter. This would require a translation which doesn't include the escaped im URI in the user part of the SIP URI.

Cheers,
Aki 

> --- aki.niemi@nokia.com wrote:
> > Hi,
> > 
> > inline.
> > 
> > > It sounds like the text you reference answers 
> > > the question. Do it as soon as possible, 
> > > preferably before you send the request. Different
> > > environments and clients may do this at different
> > > times depending on your view of "as soon as
> > possible".
> > > I think (1) is the right answer, though that might
> > > be identical to (2) is some rare cases.
> > 
> > Well, I would argue that the translation can *never*
> > happen before the request is sent. We can't mandate
> > a direct translation from an IM URI to a SIP URI,
> > and any other translation would be local policy to
> > the GW.
> > 
> > So the Request-URI would always need to have the
> > original im: URI in it. This of course causes
> > problems for proxies that don't recognize the im URI
> > scheme.
> > 
> > My proposal is that the client uses a translation
> > similar to when translating tel URIs. Namely, the im
> > URI is translated into a SIP URI by simply replacing
> > the scheme. Additionally, the URI parameter 'user'
> > is populated with the original scheme which in this
> > case is 'im'.
> > 
> > If I need to contact 'im:foo@bar.com', I resolve the
> > next hop using SRV, and in the request line have the
> > following: 
> > 
> > 	MESSAGE sip:foo@bar.com;user=im SIP/2.0
> > 
> > This will enable both cases (1 and 2 below) since a
> > GW can fall back to the direct translation by
> > ignoring the user param. If the local policy
> > dictates some other translation, the user parameter
> > gives enough information to also do that at the GW.
> > 
> > > The SRV resolution that was discussion in IMPP
> > > solves the next hop problem. It did not directly
> > > address translation of an im: *URI* to a sip:
> > *URI*.
> > > Shouldn't this be left to local
> > policy/implementation?
> > 
> > I think the above translation would solve this
> > problem.
> > 
> > Thoughts?
> > 
> > Cheers,
> > Aki
> > 
> > > --- hisham.khartabil@nokia.com wrote:
> > > > Hi,
> > > > 
> > > > Most of us heard the discussion at impp wg
> > meeting
> > > > about schemes, but there was no consensus on who
> > > > changes the scheme.
> > > > 
> > > > There are 2 suggestions:
> > > > 
> > > > 1. change it to sip as soon as possible, as
> > > > instructed by presence-07
> > > > 2. Leave it to the terminating domain. I.e. the
> > > > domain responsible.
> > > > 
> > > > Which one of the above should we do? If we
> > choose 2,
> > > > should presence I-D be changed to reflect that?
> > > > 
> > > > I'm referring to the text:
> > > > 
> > > > "When subscribing to a presentity, the
> > subscription
> > > > can be addressed
> > > >    using the protocol independent form or the
> > SIP or
> > > > SIPS URI form. In
> > > >    the SIP context, "addressed" refers to the
> > > > Request-URI. It is
> > > >    RECOMMENDED that if the entity sending a
> > > > SUBSCRIBE is capable of
> > > >    resolving the protocol independent form to
> > the
> > > > SIP form, this
> > > >    resolution is done before sending the
> > request"
> > > > 
> > > > Regards,
> > > > Hisham
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > >
> > >
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> > > 
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Web Hosting - Let the expert host your site
> > > http://webhosting.yahoo.com
> > > _______________________________________________
> > > simple mailing list
> > > simple@mailman.dynamicsoft.com
> > >
> >
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Web Hosting - Let the expert host your site
> http://webhosting.yahoo.com
> 

From hisham.khartabil@nokia.com  Wed Nov 20 17:31:20 2002
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 RAA12825
	for ; Wed, 20 Nov 2002 17:31:20 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKMUlT28209
	for ; Thu, 21 Nov 2002 00:30:47 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 21 Nov 2002 00:31:20 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 21 Nov 2002 00:31:18 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] who changes im: pres: to sip:
Date: Thu, 21 Nov 2002 00:31:18 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FEB@esebe019.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] who changes im: pres: to sip:
Thread-Index: AcKQ3A7uYoFFjqAmR6WE/pGyJEF6jQAAWelwAAFppoA=
To: , ,
        
X-OriginalArrivalTime: 20 Nov 2002 22:31:18.0950 (UTC) FILETIME=[8BA3B460:01C290E4]
Content-Length: 6224
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA12825
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: 


> -----Original Message-----
> From: Niemi Aki (NET/Espoo) 
> Sent: Thursday, November 21, 2002 12:03 AM
> To: 'ext Sean Olson'; Khartabil Hisham (NMP/Helsinki);
> simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] who changes im: pres: to sip:
> 
> 
> Hi,
> 
> > To take your analogy for tel: URIs to completion,
> > wouldn't we want to represent the entire im: URI in
> > the user portion of the sip: URI and tack on a
> > "user=im" parameter?
> 
> I'm not sure we'd have to follow the tel URI conventions all 
> the way. The im and SIP URI schemes seem to be pretty similar 
> anyway. And unlike tel, the im URI can't include any URI 
> parameters (I think...) However, if we did follow the tel URI 
> way, we'd run into the problem you describe below. 
> 
> > This seems like an interesting approach but I'm
> > concerned that the user=im parameter would *have*
> > to be interpreted by the proxies to do the right
> > thing. In that case, we would be better off with
> > sticking with an im: URI in the Request-URI. 
> 
> I think having the im URI in the Request-URI is even worse. 
> It would mean that all the proxies in the path of this 
> request would have to support the im URI scheme to be able to 
> route the message at all. With the user-parameter, at least 
> these intermediary proxies would still be able to route the 
> request normally to the owner domain.

When you do an SRV query on _im._sip.bar.com, you would expect the address returned to be for an entity that understands im scheme. So leaving the scheme as im is probably better. Or are there any scenarios where that is not the case?

Regards,
Hisham


> 
> The owner proxy of the Request-URI would then have to 
> interpret the user-parameter to do the right thing, at least 
> if the tel URI conventions were applied as they are right now.
> 
> However, my preference would be to specify the translation 
> such that the right thing could be done even when ignoring 
> the user-parameter. This would require a translation which 
> doesn't include the escaped im URI in the user part of the SIP URI.
> 
> Cheers,
> Aki 
> 
> > --- aki.niemi@nokia.com wrote:
> > > Hi,
> > > 
> > > inline.
> > > 
> > > > It sounds like the text you reference answers 
> > > > the question. Do it as soon as possible, 
> > > > preferably before you send the request. Different
> > > > environments and clients may do this at different
> > > > times depending on your view of "as soon as
> > > possible".
> > > > I think (1) is the right answer, though that might
> > > > be identical to (2) is some rare cases.
> > > 
> > > Well, I would argue that the translation can *never*
> > > happen before the request is sent. We can't mandate
> > > a direct translation from an IM URI to a SIP URI,
> > > and any other translation would be local policy to
> > > the GW.
> > > 
> > > So the Request-URI would always need to have the
> > > original im: URI in it. This of course causes
> > > problems for proxies that don't recognize the im URI
> > > scheme.
> > > 
> > > My proposal is that the client uses a translation
> > > similar to when translating tel URIs. Namely, the im
> > > URI is translated into a SIP URI by simply replacing
> > > the scheme. Additionally, the URI parameter 'user'
> > > is populated with the original scheme which in this
> > > case is 'im'.
> > > 
> > > If I need to contact 'im:foo@bar.com', I resolve the
> > > next hop using SRV, and in the request line have the
> > > following: 
> > > 
> > > 	MESSAGE sip:foo@bar.com;user=im SIP/2.0
> > > 
> > > This will enable both cases (1 and 2 below) since a
> > > GW can fall back to the direct translation by
> > > ignoring the user param. If the local policy
> > > dictates some other translation, the user parameter
> > > gives enough information to also do that at the GW.
> > > 
> > > > The SRV resolution that was discussion in IMPP
> > > > solves the next hop problem. It did not directly
> > > > address translation of an im: *URI* to a sip:
> > > *URI*.
> > > > Shouldn't this be left to local
> > > policy/implementation?
> > > 
> > > I think the above translation would solve this
> > > problem.
> > > 
> > > Thoughts?
> > > 
> > > Cheers,
> > > Aki
> > > 
> > > > --- hisham.khartabil@nokia.com wrote:
> > > > > Hi,
> > > > > 
> > > > > Most of us heard the discussion at impp wg
> > > meeting
> > > > > about schemes, but there was no consensus on who
> > > > > changes the scheme.
> > > > > 
> > > > > There are 2 suggestions:
> > > > > 
> > > > > 1. change it to sip as soon as possible, as
> > > > > instructed by presence-07
> > > > > 2. Leave it to the terminating domain. I.e. the
> > > > > domain responsible.
> > > > > 
> > > > > Which one of the above should we do? If we
> > > choose 2,
> > > > > should presence I-D be changed to reflect that?
> > > > > 
> > > > > I'm referring to the text:
> > > > > 
> > > > > "When subscribing to a presentity, the
> > > subscription
> > > > > can be addressed
> > > > >    using the protocol independent form or the
> > > SIP or
> > > > > SIPS URI form. In
> > > > >    the SIP context, "addressed" refers to the
> > > > > Request-URI. It is
> > > > >    RECOMMENDED that if the entity sending a
> > > > > SUBSCRIBE is capable of
> > > > >    resolving the protocol independent form to
> > > the
> > > > > SIP form, this
> > > > >    resolution is done before sending the
> > > request"
> > > > > 
> > > > > Regards,
> > > > > Hisham
> > > > > _______________________________________________
> > > > > simple mailing list
> > > > > simple@mailman.dynamicsoft.com
> > > > >
> > > >
> > >
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > > > 
> > > > __________________________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Web Hosting - Let the expert host your site
> > > > http://webhosting.yahoo.com
> > > > _______________________________________________
> > > > simple mailing list
> > > > simple@mailman.dynamicsoft.com
> > > >
> > >
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> > > > 
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Web Hosting - Let the expert host your site
> > http://webhosting.yahoo.com
> > 
> 

From hisham.khartabil@nokia.com  Wed Nov 20 17:36:22 2002
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12895
	for ; Wed, 20 Nov 2002 17:36:21 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKMbBR19835
	for ; Thu, 21 Nov 2002 00:37:12 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id  for ;
 Thu, 21 Nov 2002 00:35:45 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 21 Nov 2002 00:35:46 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: FW: [Simple] who changes im: pres: to sip:
Date: Thu, 21 Nov 2002 00:35:46 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE6FEC@esebe019.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] who changes im: pres: to sip:
Thread-Index: AcKQrk1h+6tOCMggTHevDxTmUzQqVwAG24fwAAZDo2AAAImDsA==
To: 
X-OriginalArrivalTime: 20 Nov 2002 22:35:46.0727 (UTC) FILETIME=[2B3F3B70:01C290E5]
Content-Length: 1908
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA12895
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: 

Looks like Ryan pressed the "Reply" button instead of "Reply to All".


> -----Original Message-----
> From: ext Ryan Chapman [mailto:Rchapman@seancesoft.com]
> Sent: Thursday, November 21, 2002 12:25 AM
> To: Khartabil Hisham (NMP/Helsinki)
> Subject: RE: [Simple] who changes im: pres: to sip:
> 
> 
> Because the snippet from Jonathan below was prompted by a 
> question I raised on the issue, I thought I'd wade in to the 
> discussion...
> 
> It seems that a fairly logical approach is to use recursive 
> SRV lookups to translate the URI.  The first lookup would 
> determine the domain associated with the particular URI.  So, 
> for example, im:somebody@somewhere.com would result in a query for:
> 
> _im._sip.somewhere.com
> 
> Which would give me a new domain associated with IM/SIP at 
> somewhere.com.  Assuming the result was something like 
> "im.somewhere.com", the SIP URI that would result would be:
> 
> sip:im.somewhere.com
> 
> ...at which point I proceed with normal SIP.  If the lookup 
> failed, I would just replace "im" with "sip".
> 
> Using this approach, nothing needs to be configured save for 
> the application itself and the name server of the appropriate 
> organization.  Proxies need never concern themselves with any 
> sort of translation.
> 
> I'm not an SRV pro, so the above may not be feasible, but it 
> has the benefit of being logical and clean.  It also allows 
> one to build arbitrarily complex protocols on top of SIP 
> (e.g., xyz -> abc -> im -> sip...).
> 
> Ryan
> 
> > 
> > From Jonathan on a different thread:
> > 
> > > 1. client looks up _pres._sip.somewhere.com in DNS
> > > 2. client takes the resulting records, and sends the 
> > request there. The 
> > > r-uri remains a pres URI.
> > > 3. the somewhere.com proxy server understands the pres URI, 
> > and applies 
> > > some local policy to translate the URI.
> > > 4. Its all sip from there
> 

From aki.niemi@nokia.com  Wed Nov 20 17:46:49 2002
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 RAA12970
	for ; Wed, 20 Nov 2002 17:46:47 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAKMkET04062
	for ; Thu, 21 Nov 2002 00:46:14 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 21 Nov 2002 00:46:46 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 21 Nov 2002 00:46:46 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] who changes im: pres: to sip:
Date: Thu, 21 Nov 2002 00:46:46 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD095@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] who changes im: pres: to sip:
Thread-Index: AcKQ3A7uYoFFjqAmR6WE/pGyJEF6jQAAWelwAAFppoAAANSlwA==
To: , ,
        
X-OriginalArrivalTime: 20 Nov 2002 22:46:46.0904 (UTC) FILETIME=[B4BE3F80:01C290E6]
Content-Length: 769
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id RAA12970
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: 

Hi Hisham,

[...]
> > I think having the im URI in the Request-URI is even worse. 
> > It would mean that all the proxies in the path of this 
> > request would have to support the im URI scheme to be able to 
> > route the message at all. With the user-parameter, at least 
> > these intermediary proxies would still be able to route the 
> > request normally to the owner domain.
> 
> When you do an SRV query on _im._sip.bar.com, you would 
> expect the address returned to be for an entity that 
> understands im scheme. So leaving the scheme as im is 
> probably better. Or are there any scenarios where that is not 
> the case?

Yeah, that actually defeats the whole purpose of the translation. I agree, im URI in the Request-URI will do the trick.

Cheers,
Aki 

From aki.niemi@nokia.com  Wed Nov 20 19:08:31 2002
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 TAA13218
	for ; Wed, 20 Nov 2002 19:08:29 -0500 (EST)
From: aki.niemi@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id gAL07tT02795
	for ; Thu, 21 Nov 2002 02:07:56 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id ;
 Thu, 21 Nov 2002 02:08:28 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Thu, 21 Nov 2002 02:08:28 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Simple] who changes im: pres: to sip:
Date: Thu, 21 Nov 2002 02:08:27 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945098@esebe013.ntc.nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Simple] who changes im: pres: to sip:
Thread-Index: AcKQ3A7uYoFFjqAmR6WE/pGyJEF6jQAAWelwAAFppoAAANSlwAABKnNg
To: , ,
        
X-OriginalArrivalTime: 21 Nov 2002 00:08:28.0128 (UTC) FILETIME=[1E19AE00:01C290F2]
Content-Length: 2180
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id TAA13218
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: 

Hi,

Apologies for flooding the list by thinking aloud here. ;)

However, after thinking about this a little more, I did come up with a scenario for which the im/pres URI in the Request-URI would not work.

It's when a UA sits behind an outbound proxy that knows nothing about im/pres URIs. Then the UA itself will have to do tricks with the im URI so that the request can be routed by this outbound proxy.

I see two choices: 

1) Use a translation very much like a tel URI to SIP URI translation. The entire im URI would go into the user part of the SIP URI, and the target domain received in the SRV query would go into the hostport part. And again, the ';user=im' or ';user=pres' would indicate that such a translation was done.

2) Keep things as they are, and in most cases use the abstract im or pres URI in the Request-URI (if not in all cases). Use SRV normally, and if the UA doesn't send the request directly to the target server, the UA needs to use loose routing to guide it there.

Option 1 would force the target proxy to interpret the user-parameter to process the request correctly. Option 2 doesn't seem to require anything new, so it looks much better to me.

Thoughts?

Cheers,
Aki

> Hi Hisham,
> 
> [...]
> > > I think having the im URI in the Request-URI is even worse. 
> > > It would mean that all the proxies in the path of this 
> > > request would have to support the im URI scheme to be able to 
> > > route the message at all. With the user-parameter, at least 
> > > these intermediary proxies would still be able to route the 
> > > request normally to the owner domain.
> > 
> > When you do an SRV query on _im._sip.bar.com, you would 
> > expect the address returned to be for an entity that 
> > understands im scheme. So leaving the scheme as im is 
> > probably better. Or are there any scenarios where that is not 
> > the case?
> 
> Yeah, that actually defeats the whole purpose of the 
> translation. I agree, im URI in the Request-URI will do the trick.
> 
> Cheers,
> Aki 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 

From jdrosen@dynamicsoft.com  Thu Nov 21 02:49:18 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14593
	for ; Thu, 21 Nov 2002 02:49:18 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.58])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL7nKYH005515;
	Thu, 21 Nov 2002 02:49:20 -0500 (EST)
Message-ID: <3DDC8FFE.1040909@dynamicsoft.com>
Date: Thu, 21 Nov 2002 02:49:18 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: seancolson@yahoo.com, hisham.khartabil@nokia.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] who changes im: pres: to sip:
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945097@esebe013.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2844
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: 

inline.

aki.niemi@nokia.com wrote:
 > Hi,
 >
 >
 >> To take your analogy for tel: URIs to completion, wouldn't we want
 >> to represent the entire im: URI in the user portion of the sip: URI
 >> and tack on a "user=im" parameter?
 >
 >
 > I'm not sure we'd have to follow the tel URI conventions all the way.
 > The im and SIP URI schemes seem to be pretty similar anyway. And
 > unlike tel, the im URI can't include any URI parameters (I think...)
 > However, if we did follow the tel URI way, we'd run into the problem
 > you describe below.

Careful!!!

There is a HUGE difference between the im and tel URIs. Thats the 
presence of the domain part. The domain part says something terribly 
important. It says that the user part has an interpretation that can 
ONLY be done by an entity in that domain. Nothing outside of that domain 
can use it. A tel URI doesn't have that property. THe "user part" is 
well defiend everywhere.

Translating a URI cannot be done if you cannot understand the resource 
that URI points to. In the case of the IM URI, only the server in that 
domain can understand, and thus, translate it. Not so for tel URI.

As an example, a valid translation is:

im:jonathan.rosenberg@dynamicsoft.com -> sip:jdrosen@dynamicsoft.com

only dynamicsoft.com can do that.

 >
 >
 >> This seems like an interesting approach but I'm concerned that the
 >> user=im parameter would *have* to be interpreted by the proxies to
 >> do the right thing. In that case, we would be better off with
 >> sticking with an im: URI in the Request-URI.
 >
 >
 > I think having the im URI in the Request-URI is even worse. It would
 > mean that all the proxies in the path of this request would have to
 > support the im URI scheme to be able to route the message at all.
 > With the user-parameter, at least these intermediary proxies would
 > still be able to route the request normally to the owner domain.

Not so. Remember that you are looking up the IM URI in DNS, and sending 
it there. Thus, the domain which needs to interpret it is the one on the 
RHS of the IM URI. Since its the one that created that URI in the first 
place, it clearly means it can understand and process it.

Now, there is this issue of the outbound proxy you raise in another 
note, which I'll respond to there. Not an easy issue.

THe net/net, however, is that the text in the presence spec as written 
is probably wrong, and needs to be updated to reflect the current 
thinking on the pres URI.

-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


From jdrosen@dynamicsoft.com  Thu Nov 21 02:54:48 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14642
	for ; Thu, 21 Nov 2002 02:54:48 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.58])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL7soYH005518;
	Thu, 21 Nov 2002 02:54:51 -0500 (EST)
Message-ID: <3DDC9148.4030407@dynamicsoft.com>
Date: Thu, 21 Nov 2002 02:54:48 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: hisham.khartabil@nokia.com, seancolson@yahoo.com,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] who changes im: pres: to sip:
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945098@esebe013.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 2171
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: 

inline.

aki.niemi@nokia.com wrote:
 > It's when a UA sits behind an outbound proxy that knows nothing about
 > im/pres URIs. Then the UA itself will have to do tricks with the im
 > URI so that the request can be routed by this outbound proxy.

Yes, this is definitely the problematic case.

 >
 > I see two choices:
 >
 > 1) Use a translation very much like a tel URI to SIP URI translation.
 > The entire im URI would go into the user part of the SIP URI, and the
 > target domain received in the SRV query would go into the hostport
 > part. And again, the ';user=im' or ';user=pres' would indicate that
 > such a translation was done.

Yuck.


 >
 > 2) Keep things as they are, and in most cases use the abstract im or
 > pres URI in the Request-URI (if not in all cases). Use SRV normally,
 > and if the UA doesn't send the request directly to the target server,
 > the UA needs to use loose routing to guide it there.

This is better, but it requires the UA to know that its outbound proxy 
doesn't support the im or pres URI.

 >
 > Option 1 would force the target proxy to interpret the user-parameter
 > to process the request correctly. Option 2 doesn't seem to require
 > anything new, so it looks much better to me.

There is a third option, which is do nothing. In this case, the proxy 
will fail the request. That is exactly what we do today for tel URI. If 
a UAC sends a request with a tel URI in the request URI to an outbound 
proxy (a common operation in sip networks), if the outbound proxy 
doesn't understand the tel URI, the request fails. Same with sips.

So, I don't believe we should be special casing the IM/Pres URIs. 
Generally speaking, the price you pay for using outbound proxies is that 
it knows how to process your request, new URIs, proxy-requires, and 
anything else.

-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


From jdrosen@dynamicsoft.com  Thu Nov 21 03:18:10 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14745
	for ; Thu, 21 Nov 2002 03:18:10 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.58])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gAL8IDYH005531;
	Thu, 21 Nov 2002 03:18:13 -0500 (EST)
Message-ID: <3DDC96C2.4060800@dynamicsoft.com>
Date: Thu, 21 Nov 2002 03:18:10 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell 
CC: Paul Kyzivat , Adam Roach ,
        simple@mailman.dynamicsoft.com
Subject: Re: [Simple] Thoughts on list template
References: <001c01c28f4e$76d5cf60$80452acc@dynamicsoft.com> <3DD9822E.9AA9D9D1@cisco.com> <3DD9C0DE.1050008@dynamicsoft.com> <3DDBAC0E.7020204@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3006
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: 

inline.

Ben Campbell wrote:
> This certainly seems like an elegant way to allow assymetric hierachies. 

Thanks. I definitely think this is right.

> There are a few areas that give me heartburn, but on reflection, I 
> realize these issues are with the idea of recursive lists in the first 
> place.
> 
> 1) We talk about the idea that a watcher can infer list contents from an 
> initial full state notify. But it is not entirely clear to me what a 
> full state notify looks like for a list that contains other lists. Do we 
> expect the watcher to be able to infer the full hiearchy?

I thought that the presence list server (or whatever we are calling it 
these days) would subscribe to each element, and when it gets the 
notifies, will know whether each element is a single URI or itself a 
list. It then reports its own result as a list, where elements are 
either a single URI, or another list, based on its downstream 
subscribes. The result is that the hierarchy would be constructed and 
placed in the full state notify.

Now, the bigger issue is full-state notifies for big lists. They quickly 
become unwieldy. If we apply the current semantic - which is that 
NOTIFY's triggered from SUBSCRIBE contain full state, you end up with 
this huge NOTIFY after every refresh, probably not what you want.

If you assume that the list structure itself (ie., the set of 
presentities in any list), rather than the state of the presentities, is 
synchronized separately, you don't really have a strong need for full 
state updates. Instead, you can send a bunch of partial updates (state 
for a single presentity) that are then used by the subscriber to fill in 
the state of the individual leaves of the tree. Its probably OK for 
those partial notifies to be sent to the subscriber over some window of 
time after the subscribe (i.e, it takes 2 seconds for the state of all 
leaves to be transferred).

We could also define a parameter in the SUBSCRIBE somewhere that 
explicitly tells the server to send a full state in a NOTIFY. The 
deafult operation is to never send full state, only when requested.

> 
> 2) Robert mentioned a scary one to me this morning: What about circular 
> references in lists?

Yikes!!

We can either do a "hop counter" - every time a server triggers a 
subscription to get state for an incoming subscription it decrements a 
counter, or we can detect the loop through a persistent identifer as 
sean suggests. I think that there is no real meaning of "spiral" here, 
which would immensely complicate such an approach.

One way or another, we have to worry about this case if we accept 
recursive lists.

-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


From rsparks@dynamicsoft.com  Mon Nov 25 12:13:03 2002
Received: from dyn-tx-app-007.dfw.dynamicsoft.com (dyn-tx-app-007.dfw.dynamicsoft.com [63.110.3.105])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01515
	for ; Mon, 25 Nov 2002 12:13:03 -0500 (EST)
Received: from RjS.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-app-007.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gAPHD2127509;
	Mon, 25 Nov 2002 11:13:02 -0600
Subject: Re: [Simple] Notes and slides
From: Robert Sparks 
To: Robert Sparks 
Cc: simple@mailman.dynamicsoft.com
In-Reply-To: <1037740088.1253.9.camel@RjS.localdomain>
References: <1037740088.1253.9.camel@RjS.localdomain>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 25 Nov 2002 12:12:09 -0500
Message-Id: <1038244330.915.24.camel@RjS.localdomain>
Mime-Version: 1.0
Content-Length: 984
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: 

I've received no comments so far.

I will submit these (modulo minor spelling
corrections in the notes) for the proceedings
at the end of the week. If you haven't already
done so, please take a few minutes to look them
over. Send a note even if you find no corrections
are needed so I know they've been reviewed.

I would also appreciate a note from the presenters
when they have verified that the correct copy
of their slides appears at the link below.

Thanks!

RjS

On Tue, 2002-11-19 at 16:08, Robert Sparks wrote:
> Rough notes and the slides from the IETF55 SIMPLE
> meeting are available at
> http://www.softarmor.com/simple/meets/ietf55
> 
> Please send corrections to the notes to the list.
> 
> Send corrections to the slides (or error reports
> concerning the SIMPLE weblet) directly to me.
> 
> RjS
> 
> 
> 
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple



From tanglih@cn.ibm.com  Thu Nov 28 03:43:02 2002
Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12610
	for ; Thu, 28 Nov 2002 03:43:01 -0500 (EST)
Received: from d23rh901.au.ibm.com (d23rh901.au.ibm.com [9.185.167.100])
	by ausmtp01.au.ibm.com (8.12.1/8.12.1) with ESMTP id gAS8hBUr353704
	for ; Thu, 28 Nov 2002 19:43:11 +1100
Received: from d23m0018.cn.ibm.com (d23m0018.cn.ibm.com [9.181.2.75])
	by d23rh901.au.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gAS8bb7L108918
	for ; Thu, 28 Nov 2002 19:37:39 +1100
To: simple@mailman.dynamicsoft.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: 
From: "Li Hua Tang" 
Date: Thu, 28 Nov 2002 16:41:17 +0800
X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.9a |January 7, 2002) at
 28/11/2002 16:42:12
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Length: 381
Subject: [Simple] any SIP progress in devices?
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: 

Hi, all

I'd like to know how about SIP work on sessions involving in multiple
devices and server resources. My interesting points includes how to
exchange the events among devices, how to control Prompt Players, Text to
Speech, and Speech Recognition Engines.

Thanks very much for your information.

Best regards,

Tang Lihua
IBM China Research Lab.
Email:  tanglih@cn.ibm.com


From AVSHALOM@il.ibm.com  Thu Nov 28 05:07:47 2002
Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12954
	for ; Thu, 28 Nov 2002 05:07:47 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id gASA7cAL060304
	for ; Thu, 28 Nov 2002 11:07:44 +0100
Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gASA7TFt098236
	for ; Thu, 28 Nov 2002 11:07:31 +0100
To: simple@mailman.dynamicsoft.com
Subject: Re: [Simple] any SIP progress in devices?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
Message-ID: 
From: "Avshalom Houri" 
Date: Thu, 28 Nov 2002 12:07:21 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 28/11/2002 12:07:30,
	Serialize complete at 28/11/2002 12:07:30
Content-Type: multipart/alternative; boundary="=_alternative 003796A4C2256C7F_="
Content-Length: 3850
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: 

This is a multipart message in MIME format.
--=_alternative 003796A4C2256C7F_=
Content-Type: text/plain; charset="US-ASCII"

Tang Li Hua wrote:

> I'd like to know how about SIP work on sessions involving in multiple
> devices and server resources. My interesting points includes how to
> exchange the events among devices, how to control Prompt Players, Text 
to
> Speech, and Speech Recognition Engines.

Following information sent by Henry Sinnreich  
may be of interest:

Avshalom Houri
Lotus Sametime, IBM

-------------------------------------------------------

As discussed during the IETF, here is the I-D on 

SIP Telephony Device Requirements, Configuration and Data

   This informational I-D describes the requirements for SIP Telephony 
   devices, based on the deployment experience of large numbers of SIP 
   phones and PC clients using different implementations. The document 
   reviews the generic requirements for SIP telephony devices, the 
   automatic device configuration process, the device configuration data

   and examples for XML configuration data formats.

The I-D will be published in the IETF archive and can also be found at 

http://www.sipforum.org/ietfdrafts/draft-somefolks-sipdevices-req-00.txt

Send an email to sipdevices-request@sipforum.org with the word
"subscribe" in the body to subscribe to the list or use this link.

After you have subscribe to the SIP Forum Devices Work Group mailing
list, you can access the SIP Devices WG email archives by visiting
http://www.freelists.org/archives/sipdevices/. 

The authors would really appeciate your comments. Please feel free to
share with anyone interested in the company.



--=_alternative 003796A4C2256C7F_=
Content-Type: text/html; charset="US-ASCII"



Tang Li Hua wrote:



> I'd like to know how about SIP work on sessions
involving in multiple

> devices and server resources. My interesting points includes how to

> exchange the events among devices, how to control Prompt Players,
Text to

> Speech, and Speech Recognition Engines.



Following information sent by
Henry Sinnreich <Henry.Sinnreich@wcom.com> may be of interest:



Avshalom Houri

Lotus Sametime, IBM



-------------------------------------------------------



As discussed during the IETF, here is the I-D on 



SIP Telephony Device Requirements, Configuration and Data



   This informational I-D describes the requirements for SIP Telephony


   devices, based on the deployment experience of large numbers of
SIP 

   phones and PC clients using different implementations. The document


   reviews the generic requirements for SIP telephony devices, the


   automatic device configuration process, the device configuration
data



   and examples for XML configuration data formats.



The I-D will be published in the IETF archive and can also be found at




http://www.sipforum.org/ietfdrafts/draft-somefolks-sipdevices-req-00.txt



Send an email to sipdevices-request@sipforum.org with the word

"subscribe" in the body to subscribe to the list or use this
link.



After you have subscribe to the SIP Forum Devices Work Group mailing

list, you can access the SIP Devices WG email archives by visiting

http://www.freelists.org/archives/sipdevices/. 



The authors would really appeciate your comments. Please feel free to

share with anyone interested in the company.






--=_alternative 003796A4C2256C7F_=--

From rsparks@dynamicsoft.com  Tue Dec  3 10:20:29 2002
Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05428
	for ; Tue, 3 Dec 2002 10:20:29 -0500 (EST)
Received: from RjS.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gB3FKVI02442
	for ; Tue, 3 Dec 2002 09:20:31 -0600
From: Robert Sparks 
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 03 Dec 2002 09:19:49 -0600
Message-Id: <1038928789.944.30.camel@RjS.localdomain>
Mime-Version: 1.0
Content-Length: 381
Subject: [Simple] SIPIT 12 registration is open
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: 

The 12th SIPit will be hosted by Hotsip in Stockholm
February 24-28, 2003.

Please see
http://www.hotsip.com/sipit12/
for details and registration.

There were several SIMPLE implementations at the
last SIPIT. I expect more at this one (drop me
a note if you're planning to attend). We will have
a multiparty session testing SIMPLE interoperability
at this event.

Thanks,

RjS




From jdrosen@dynamicsoft.com  Tue Dec  3 15:22:31 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06440
	for ; Tue, 3 Dec 2002 15:22:31 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.55])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB3KMZYH011415
	for ; Tue, 3 Dec 2002 15:22:35 -0500 (EST)
Message-ID: <3DED1284.9020207@dynamicsoft.com>
Date: Tue, 03 Dec 2002 15:22:28 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 5235
Subject: [Simple] Updated presence specs
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: 

Folks,

I've just submitted an update to all three core presence specs 
(presence, watcherinfo package, watcherinfo format) based on comments 
received during last call, including those from our AD. Until they 
appear in the archives, you can pick them up at:


http://www.jdrosen.net/papers/draft-ietf-simple-presence-08.txt
http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-03.txt
http://www.jdrosen.net/papers/draft-ietf-simple-winfo-format-03.txt

THe changes are mostly minor. Below you will find a summary.

PRESENCE
--------
* reduced the author list to one, as I have been the primary author
and editor for some time. This was at the request of Patrik, and is
consistent with RFC-editor policy on author lists. The remainder of
the author list was moved to a contributor section.

* Section 4, overview of operation, reported that a SUBSCRIBE with
Expires: 0, used for fetch, was identical to processing of a SUBSCRIBE
with a non-zero Expires, in that both result in an immediate
NOTIFY. This isn't true. An immediate NOTIFY is only sent, in all
cases, when the SUBSCRIBE is either pending or authorized. Clarified
that.

* Reworked the section on replay prevention. Added a few paragraphs
describing why replay was bad. Remvoed the text which talked about
including Call-ID, CSeq and Date headers in the signature; that
requires the use of message/sip signed bodies and was not the
intent. Rather, the signature is just over the PIDF document. PIDF
provides its own timestamp for replay prevention; the spec now
mandates its usage. I also added some verbiage on how and when http
digest can be used to provide replay protection.

* The section on DoS attack prevention described a check that the UA
could make. If the From field domain and the Contact domain didn't
match, inform the user. However, this is really useless, since
frequently the Contact header field will contain an IP address. This
attack is better prevented by authentication and authorization, and if
it does happen, timeouts and NOTIFY rejections remove a subscription
anyway. Thus, it is adequately handled without this text. The text was
therefore removed.

* Split the DoS protection section into two - one section addressing
attacks against third parties (the text that was there before), and a
new subsection on attacks against the server itself. In that section,
added a brief discussion on standard sip techniques for dealing with
such attacks.

* Made section heading capitalizations consistent.

* More formal terminology alignment with rfc 2778 in the introduction.

* Updated references

* Change CPIM references to CPP, based on the document split in IMPP.

* Updated the usage of presence URIs to reflect current consensus on
this issue in IMPP.

* Removed the text in 6.6 about generating a 403 if the PA doesn't
want to accept forwarded subscribe requests. This text pre-dated the
inclusion of equivalent text in RFC 3261. Since the text is now in RFC
3261, there is no need to repeat it here.

* Removed text in section 6.6.1 about obtaining subscriber identity in
networks of transitive trust. This paragraph predates the now
extensive work on network asserted identity for sip. The paragraph
merely states that identity establishment through transitive trust is
one approach in inter-domain networks, and cites the relevant I-Ds on
the subject as non-normative approaches. This includes the P-NAI
header and the more recent identity work using authenticated identity
bodies.

* aligned with latest caller preferences spec. In particular, it is
now a SHOULD for a PUA that can support PA function to indicate
support for both SUBSCRIBE method and the presence event package.

* fixed up the presentation of the section on migration and state
agents. In particular, the text is more explicit in meeting the
requirements outlined in RFC 3265 for this section, in that it now
talks about authentication and authorization. The migration text was
streamlined a bit, removing some of the redundant definitions.

* There was never a normative strength associated with implementing
the watcherinfo package in presence servers. Since authorization in
state agents must be considered by any event package, support for
that package was made a SHOULD.

* general improvements in wording, attempting to be more brief and
switch from passive to active tense (I have a habit of writing in
passive tense).

* Updated the text on creating presence documents from registrations -
terminology fixes and clarifications. Also state that the means by
which registrations are turned into presence documents is a matter of
policy.


WINFO PACKAGE
--------------

* changed title to reflect SIP guidelines

* fixed Via header in example NOTIFY request in Section 3.1

* updated references

WINFO FORMAT
------------

* updated references

* indicate that version numbers dont wrap.

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


From scoya@cnri.reston.va.us  Thu Dec  5 09:25:03 2002
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 JAA13860
	for ; Thu, 5 Dec 2002 09:25:02 -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 JAA12641;
	Thu, 5 Dec 2002 09:22:11 -0500 (EST)
Message-Id: <200212051422.JAA12641@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
Date: Thu, 05 Dec 2002 09:22:11 -0500
Content-Length: 3070
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-08.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: A Presence Event Package for the Session Initiation 
                          Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-presence-08.txt
	Pages		: 26
	Date		: 2002-12-4
	
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications of presence. Presence is
defined as the willingness and ability of a user to communicate with
other users on the network. Historically, presence has been limited
to 'on-line' and 'off-line' indicators; the notion of presence here
is broader. Subscriptions and notifications of presence are supported
by defining an event package within the general SIP event
notification framework. This protocol is also compliant with the
Common Presence Profile (CPP) framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-presence-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-presence-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-12-4093321.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-12-4093321.I-D@ietf.org>

--OtherAccess--

--NextPart--



From scoya@cnri.reston.va.us  Thu Dec  5 09:28:43 2002
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 JAA13885
	for ; Thu, 5 Dec 2002 09:28:43 -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 JAA12847;
	Thu, 5 Dec 2002 09:25:52 -0500 (EST)
Message-Id: <200212051425.JAA12847@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
Date: Thu, 05 Dec 2002 09:25:52 -0500
Content-Length: 3049
Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-package-03.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: A Watcher Information Event Template-Package for the 
                          Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-winfo-package-03.txt
	Pages		: 19
	Date		: 2002-12-4
	
This document defines the watcher information template-package for
the SIP event framework. Watcher information refers to the set of
users subscribed to a particular resource within a particular event
package. Watcher information changes dynamically as users subscribe,
unsubscribe, are approved, or are rejected. A user can subscribe to
this information, and therefore learn about changes to it. This event
package is a template-package because it can be applied to any event
package, including itself.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-winfo-package-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-winfo-package-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-12-4093332.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-winfo-package-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-winfo-package-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-12-4093332.I-D@ietf.org>

--OtherAccess--

--NextPart--



From scoya@cnri.reston.va.us  Thu Dec  5 09:28:49 2002
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 JAA13890
	for ; Thu, 5 Dec 2002 09:28:49 -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 JAA12864;
	Thu, 5 Dec 2002 09:25:58 -0500 (EST)
Message-Id: <200212051425.JAA12864@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
Date: Thu, 05 Dec 2002 09:25:58 -0500
Content-Length: 3148
Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-format-03.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: An Extensible Markup Language (XML) Based Format for 
                          Watcher Information
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-winfo-format-03.txt
	Pages		: 14
	Date		: 2002-12-4
	
Watchers are defined as entities that request (i.e., subscribe to)
information about a resource. There is fairly complex state
associated with these subscriptions. The union of the state for all
subscriptions to a particular resource is called the watcher
information for that resource. This state is dynamic, changing as
subscribers come and go. As a result, it is possible, and indeed
useful, to subscribe to the watcher information for a particular
resource. In order to enable this, a format is needed to describe the
state of watchers on a resource. This specification describes an XML
document format for such state.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-format-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-winfo-format-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-winfo-format-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2002-12-4093341.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-winfo-format-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-winfo-format-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-12-4093341.I-D@ietf.org>

--OtherAccess--

--NextPart--



From jdrosen@dynamicsoft.com  Fri Dec  6 02:57:23 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17027
	for ; Fri, 6 Dec 2002 02:57:23 -0500 (EST)
Received: from dynamicsoft.com ([63.113.46.83])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB67vQYH012960
	for ; Fri, 6 Dec 2002 02:57:26 -0500 (EST)
Message-ID: <3DF05863.8000103@dynamicsoft.com>
Date: Fri, 06 Dec 2002 02:57:23 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@mailman.dynamicsoft.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1786
Subject: [Simple] minor updates to presence spec and watcherinfo spec
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: 

Folks,

I've just submitted another update to the presence spec and the 
watcherinfo changes. The updates are minor and address further iesg 
comments. Until they appear in the archives, you can grab them from:


http://www.jdrosen.net/papers/draft-ietf-simple-winfo-package-04.txt
http://www.jdrosen.net/papers/draft-ietf-simple-presence-09.txt

The changes are summarized below.

PRESENCE
--------
* in the pres URI discussion, it says that SIP URI is preferred when its
known. Fixed to say SIP or SIPS URI, instead of just SIP URI.

* removed references to p-header network asserted ID drafts as a means
to establish identity. Text now reads:

In inter-domain scenarios, establishing an authenticated identity of
the subscriber is harder. It is anticipated that authentication will
often be established through transitive trust. SIP mechanisms
for network asserted identity can be applied to establish the identity
of the subscriber \citenonnorm{draft-ietf-sip-identity}.

* removed text which said that you can send notifications faster than
once every 5 seconds if an extension explicitly says its OK.

* explicit mention of rfc2779 as an influence on security
considerations.

* mention the possibility of e2e encryption using smime shared secrets
(rfc3211).

* changed examples to tcp

WINFO-PACKAGE
--------------

* Added JDR contact information to template package registration in
IANA considerations section.


-Jonathan R.

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


From sudipta.ghosh@scicmp.com  Fri Dec  6 05:33:35 2002
Received: from himalaya.scicmp.com ([203.200.79.36])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA17486
	for ; Fri, 6 Dec 2002 05:26:07 -0500 (EST)
Received: from mx1.scicmp.com ([10.130.0.5])
 by himalaya.scicmp.com (NAVGW 2.5.2.12) with SMTP id M2002120615562530354
 for ; Fri, 06 Dec 2002 15:56:25 +0530
Received: from scicmp.com (kanchenjunga [10.140.13.178])
	by mx1.scicmp.com (8.9.3/8.8.7) with ESMTP id QAA31898
	for ; Fri, 6 Dec 2002 16:03:21 +0530
Message-ID: <3DF07BF8.3AFF5BBE@scicmp.com>
Date: Fri, 06 Dec 2002 15:59:12 +0530
From: Sudipta Ghosh 
Organization: Scicom Infotech Pvt. Ltd. (Scicom)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: simple 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1708
Subject: [Simple] Event
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: 

Hi,
When IM Client is sending a SUBSCRIPTION request( to a offline user )
for presence notification to proxy,proxy sends response with 200 OK but
adds a event header.

Whats the meaning of it.

In REGISTER request there is also a Event header.
I am sending the packets.(got from MSN Messenger communication service)

SUBSCRIBE sip:sudipta@10.140.13.149 SIP/2.0
Via: SIP/2.0/TCP 10.140.13.178:9172
From: "i" ;tag=5a9e885b-5af7-45b4-ad41-33eb48ae6a99

To: 
Call-ID: 382d3998-db28-409d-b692-fedf56a685fe@10.140.13.178
CSeq: 1 SUBSCRIBE
Contact: 
User-Agent: Windows RTC/1.0
Expires: 1800
Content-Length: 0



SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.140.13.178:9172;received-port=5060
To: sip:sudipta@10.140.13.149;tag=UKXBY32U8GYZBRWM
CSeq: 1 SUBSCRIBE
From: "i" ;tag=5a9e885b-5af7-45b4-ad41-33eb48ae6a99

Call-ID: 382d3998-db28-409d-b692-fedf56a685fe@10.140.13.178
Event: presence
Expires: 1800
Content-Length: 0

REGISTER sip:10.140.13.149 SIP/2.0
Via: SIP/2.0/TCP 10.140.13.178:9172
From: ;tag=de061b7a-5964-43d5-a297-099e5d6e9796
To: 
Call-ID: b1737741-048e-4dab-9a03-4e910754f618@10.140.13.178
CSeq: 1 REGISTER
Contact: ;methods="INVITE,
MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK"
User-Agent: Windows RTC/1.0
Expires: 1200
Event: registration
Allow-Events: presence
Content-Length: 0
--
***********************************************
System Executive
Mobile and Communication Tech.
Scicom Infotech Pvt. Ltd. (Scicom)
A - 67, Sector - 57
Noida - 201 301
UP
**********************************************



From sudipta.ghosh@scicmp.com  Fri Dec  6 05:36:41 2002
Received: from himalaya.scicmp.com ([203.200.79.36])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA17546
	for ; Fri, 6 Dec 2002 05:36:40 -0500 (EST)
Received: from mx1.scicmp.com ([10.130.0.5])
 by himalaya.scicmp.com (NAVGW 2.5.2.12) with SMTP id M2002120615562530354
 for ; Fri, 06 Dec 2002 15:56:25 +0530
Received: from scicmp.com (kanchenjunga [10.140.13.178])
	by mx1.scicmp.com (8.9.3/8.8.7) with ESMTP id QAA31898
	for ; Fri, 6 Dec 2002 16:03:21 +0530
Message-ID: <3DF07BF8.3AFF5BBE@scicmp.com>
Date: Fri, 06 Dec 2002 15:59:12 +0530
From: Sudipta Ghosh 
Organization: Scicom Infotech Pvt. Ltd. (Scicom)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: simple 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1708
Subject: [Simple] Event
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: 

Hi,
When IM Client is sending a SUBSCRIPTION request( to a offline user )
for presence notification to proxy,proxy sends response with 200 OK but
adds a event header.

Whats the meaning of it.

In REGISTER request there is also a Event header.
I am sending the packets.(got from MSN Messenger communication service)

SUBSCRIBE sip:sudipta@10.140.13.149 SIP/2.0
Via: SIP/2.0/TCP 10.140.13.178:9172
From: "i" ;tag=5a9e885b-5af7-45b4-ad41-33eb48ae6a99

To: 
Call-ID: 382d3998-db28-409d-b692-fedf56a685fe@10.140.13.178
CSeq: 1 SUBSCRIBE
Contact: 
User-Agent: Windows RTC/1.0
Expires: 1800
Content-Length: 0



SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.140.13.178:9172;received-port=5060
To: sip:sudipta@10.140.13.149;tag=UKXBY32U8GYZBRWM
CSeq: 1 SUBSCRIBE
From: "i" ;tag=5a9e885b-5af7-45b4-ad41-33eb48ae6a99

Call-ID: 382d3998-db28-409d-b692-fedf56a685fe@10.140.13.178
Event: presence
Expires: 1800
Content-Length: 0

REGISTER sip:10.140.13.149 SIP/2.0
Via: SIP/2.0/TCP 10.140.13.178:9172
From: ;tag=de061b7a-5964-43d5-a297-099e5d6e9796
To: 
Call-ID: b1737741-048e-4dab-9a03-4e910754f618@10.140.13.178
CSeq: 1 REGISTER
Contact: ;methods="INVITE,
MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK"
User-Agent: Windows RTC/1.0
Expires: 1200
Event: registration
Allow-Events: presence
Content-Length: 0
--
***********************************************
System Executive
Mobile and Communication Tech.
Scicom Infotech Pvt. Ltd. (Scicom)
A - 67, Sector - 57
Noida - 201 301
UP
**********************************************



From sudipta.ghosh@scicmp.com  Fri Dec  6 09:56:53 2002
Received: from himalaya.scicmp.com ([203.200.79.36])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA18299
	for ; Fri, 6 Dec 2002 09:56:51 -0500 (EST)
Received: from mx1.scicmp.com ([10.130.0.5])
 by himalaya.scicmp.com (NAVGW 2.5.2.12) with SMTP id M2002120620270101991
 ; Fri, 06 Dec 2002 20:27:01 +0530
Received: from scicmp.com (kanchenjunga [10.140.13.178])
	by mx1.scicmp.com (8.9.3/8.8.7) with ESMTP id UAA03796;
	Fri, 6 Dec 2002 20:33:57 +0530
Message-ID: <3DF0BB65.1E041866@scicmp.com>
Date: Fri, 06 Dec 2002 20:29:49 +0530
From: Sudipta Ghosh 
Organization: Scicom Infotech Pvt. Ltd. (Scicom)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: simple ,
        sipforum 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 315
Subject: [Simple] info
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: 

hi,
is there any free/demo sip/simple server available so we can login
through MSN Messenger
communication server.
sudipta

--
***********************************************
System Executive
Scicom Infotech Pvt. Ltd. (Scicom)
A - 67, Sector - 57
Noida - 201 301
UP
**********************************************



From jdrosen@dynamicsoft.com  Fri Dec  6 11:11:22 2002
Received: from mail3.dynamicsoft.com (mail3.dynamicsoft.com [63.113.44.69])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18733
	for ; Fri, 6 Dec 2002 11:11:22 -0500 (EST)
Received: from dynamicsoft.com ([63.113.47.242])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id gB6GBMYH013130;
	Fri, 6 Dec 2002 11:11:25 -0500 (EST)
Message-ID: <3DF0CC27.60907@dynamicsoft.com>
Date: Fri, 06 Dec 2002 11:11:19 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sudipta Ghosh 
CC: simple 
Subject: Re: [Simple] Event
References: <3DF07BF8.3AFF5BBE@scicmp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 1460
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: 

answers inline.

Sudipta Ghosh wrote:
> Hi,
> When IM Client is sending a SUBSCRIPTION request( to a offline user )

The request method is SUBSCRIBE, not SUBSCRIPTION.

> for presence notification to proxy,proxy sends response with 200 OK but
> adds a event header.

The SUBSCRIBE request contains the Event header. It is not placed in the 
200 OK response. It is, however, placed in the NOTIFY request generated 
by the presence server.

> 
> Whats the meaning of it.

SIP has a general events framework (RFC 3265). A particular resource, 
such as sip:jdrosen@dynamicsoft.com, can support multiple types of 
events, including presence, message waiting indicators, dialog events, 
etc. The Event header disambiguates the event types being requested of 
the resource. See RFC 3265 for a complete discussion.

> 
> In REGISTER request there is also a Event header.

No, there is no Event header in REGISTER.

> I am sending the packets.(got from MSN Messenger communication service)

This, to my knowledge, is an error in their implementation. It would be 
ignored by any SIP compliant registrar.

-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


From fluffy@cisco.com  Sun Dec  8 12:42:23 2002
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27260
	for ; Sun, 8 Dec 2002 12:42:23 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB8HfujS001743
	for ; Sun, 8 Dec 2002 09:41:56 -0800 (PST)
Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with SMTP id EKF00105;
	Sun, 8 Dec 2002 09:42:38 -0800 (PST)
From: "Cullen Jennings" 
To: 
Date: Sun, 8 Dec 2002 09:43:32 -0800
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)
In-Reply-To: <200212051422.JAA12641@ietf.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 3024
Subject: [Simple] RE: I-D ACTION:draft-ietf-simple-presence-08.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: 

I'm confused - is it version 8 or 9?  all I can find is 
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-09.txt


> -----Original Message-----
> From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf
> Of Internet-Drafts@ietf.org
> Sent: Thursday, December 05, 2002 6:22 AM
> To: IETF-Announce:
> Cc: simple@mailman.dynamicsoft.com
> Subject: I-D ACTION:draft-ietf-simple-presence-08.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the SIP for Instant Messaging and 
> Presence Leveraging Extensions Working Group of the IETF.
> 
> 	Title		: A Presence Event Package for the Session 
> Initiation 
>                           Protocol (SIP)
> 	Author(s)	: J. Rosenberg
> 	Filename	: draft-ietf-simple-presence-08.txt
> 	Pages		: 26
> 	Date		: 2002-12-4
> 	
> This document describes the usage of the Session Initiation Protocol
> (SIP) for subscriptions and notifications of presence. Presence is
> defined as the willingness and ability of a user to communicate with
> other users on the network. Historically, presence has been limited
> to 'on-line' and 'off-line' indicators; the notion of presence here
> is broader. Subscriptions and notifications of presence are supported
> by defining an event package within the general SIP event
> notification framework. This protocol is also compliant with the
> Common Presence Profile (CPP) framework.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-08.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of 
> the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with 
> the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-simple-presence-08.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-simple-presence-08.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

From fluffy@cisco.com  Sun Dec  8 16:43:31 2002
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27903
	for ; Sun, 8 Dec 2002 16:43:30 -0500 (EST)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gB8LhUFp001176
	for ; Sun, 8 Dec 2002 13:43:30 -0800 (PST)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA)
	with SMTP id EKR00122;
	Sun, 8 Dec 2002 13:43:52 -0800 (PST)
From: "Cullen Jennings" 
To: 
Subject: RE: [Simple] RE: I-D ACTION:draft-ietf-simple-presence-08.txt
Date: Sun, 8 Dec 2002 13:46:31 -0800
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)
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Length: 3732
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: 

Sorry for the post without reading all the list - I see they were updated to
a new version after this announcement.

> -----Original Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Cullen
> Jennings
> Sent: Sunday, December 08, 2002 9:44 AM
> To: simple@mailman.dynamicsoft.com
> Subject: [Simple] RE: I-D ACTION:draft-ietf-simple-presence-08.txt
>
>
>
> I'm confused - is it version 8 or 9?  all I can find is
> http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-09.txt
>
>
> > -----Original Message-----
> > From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf
> > Of Internet-Drafts@ietf.org
> > Sent: Thursday, December 05, 2002 6:22 AM
> > To: IETF-Announce:
> > Cc: simple@mailman.dynamicsoft.com
> > Subject: I-D ACTION:draft-ietf-simple-presence-08.txt
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> > This draft is a work item of the SIP for Instant Messaging and
> > Presence Leveraging Extensions Working Group of the IETF.
> >
> > 	Title		: A Presence Event Package for the Session
> > Initiation
> >                           Protocol (SIP)
> > 	Author(s)	: J. Rosenberg
> > 	Filename	: draft-ietf-simple-presence-08.txt
> > 	Pages		: 26
> > 	Date		: 2002-12-4
> >
> > This document describes the usage of the Session Initiation Protocol
> > (SIP) for subscriptions and notifications of presence. Presence is
> > defined as the willingness and ability of a user to communicate with
> > other users on the network. Historically, presence has been limited
> > to 'on-line' and 'off-line' indicators; the notion of presence here
> > is broader. Subscriptions and notifications of presence are supported
> > by defining an event package within the general SIP event
> > notification framework. This protocol is also compliant with the
> > Common Presence Profile (CPP) framework.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-08.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of
> > the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with
> > the username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-ietf-simple-presence-08.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > 	mailserv@ietf.org.
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-simple-presence-08.txt".
> >
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>


From sudipta.ghosh@scicmp.com  Mon Dec  9 01:28:22 2002
Received: from himalaya.scicmp.com ([203.200.79.36])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id BAA29474
	for ; Mon, 9 Dec 2002 01:28:17 -0500 (EST)
Received: from mx1.scicmp.com ([10.130.0.5])
 by himalaya.scicmp.com (NAVGW 2.5.2.12) with SMTP id M2002120911582706393
 ; Mon, 09 Dec 2002 11:58:27 +0530
Received: from scicmp.com (kanchenjunga [10.140.13.178])
	by mx1.scicmp.com (8.9.3/8.8.7) with ESMTP id MAA02766;
	Mon, 9 Dec 2002 12:05:10 +0530
Message-ID: <3DF438AC.9F077C05@scicmp.com>
Date: Mon, 09 Dec 2002 12:01:09 +0530
From: Sudipta Ghosh 
Organization: Scicom Infotech Pvt. Ltd. (Scicom)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: simple ,
        sipforum 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1058
Subject: [Simple] msgr
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: 

Hi,
MSN Messenger uses "msgr" tag in MESSAGE Request.
What is that?
sudipta

Example


MESSAGE sip:10.140.13.149:5060 SIP/2.0
Via: SIP/2.0/TCP 10.140.13.149:5060
Record-Route: 

Via: SIP/2.0/TCP 10.140.13.96:11138
From: "Client_A"
;tag=65056eff-f536-43dc-a795-947be959f714
To:
;tag=f6dfc966-ad80-4cea-b8bd-ce3de259b79a
Call-ID: 89ef0faf-574f-4241-8a0f-9a3e4490a075@10.140.13.96
CSeq: 4 MESSAGE
Route: 
Contact: 
User-Agent: Windows RTC/1.0
Content-Type: text/plain;
charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIAMABTAGgAZQBsAGwAJQAyADAARABsAGcAOwAgAEUARgA9ADsAIABDAE8APQAwADsAIABDAFMAPQAwADsAIABQAEYAPQAwAA0ACgANAAoA

Content-Length: 18


--
***********************************************
System Executive
Scicom Infotech Pvt. Ltd. (Scicom)
A - 67, Sector - 57
Noida - 201 301
UP
**********************************************



From hkumar@spgsolutions.com  Mon Dec  9 02:17:39 2002
Received: from computer.mywwwserver.com ([66.78.35.28])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29631
	for ; Mon, 9 Dec 2002 02:17:39 -0500 (EST)
Received: from ptil-146-95-del.primus-india.net ([210.7.95.146] helo=spgwin1)
	by computer.mywwwserver.com with smtp (Exim 3.36 #1)
	id 18LIAZ-0000nE-00; Mon, 09 Dec 2002 02:17:35 -0500
Message-ID: <002801c29f53$23777b10$925f07d2@spgwin1>
From: "Hemant Kumar" 
To: "Sudipta Ghosh" ,
        "simple" ,
        "sipforum" 
References: <3DF438AC.9F077C05@scicmp.com>
Subject: Re: [Simple] msgr
Date: Mon, 9 Dec 2002 12:48:10 +0530
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.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - computer.mywwwserver.com
X-AntiAbuse: Original Domain - mailman.dynamicsoft.com
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0]
X-AntiAbuse: Sender Address Domain - spgsolutions.com
Content-Length: 2157
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: 

If you'll look at the value of this tag in different messages, you'll find
out the value is

"WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIA
MABTAGgAZQBsAGwAJQAyADAARABsAGcAOwAgAEUARgA9ADsAIABDAE8APQAwADsA
IABDAFMAPQAwADsAIABQAEYAPQAwAA0ACgANAAoA"

and it is same always (well atleast all the messages I saw, it was same).

So, I think it is Unique String in charset, just make sure that this message
is from MSN Messenger.

rgds,
/hem

--
Hemant Kumar,
Project Manager,
SPG Solutions,LLC
B-372, Meera Bagh,
Paschim Vihar,
New Delhi - 110063,
Phone:+91.11.25271704
Fax:+91.11.25286949
Email:hkumar@spgsolutions.com


----- Original Message -----
From: "Sudipta Ghosh" 
To: "simple" ; "sipforum"

Sent: Monday, December 09, 2002 12:01 PM
Subject: [Simple] msgr


> Hi,
> MSN Messenger uses "msgr" tag in MESSAGE Request.
> What is that?
> sudipta
>
> Example
>
>
> MESSAGE sip:10.140.13.149:5060 SIP/2.0
> Via: SIP/2.0/TCP 10.140.13.149:5060
> Record-Route: 
>
> Via: SIP/2.0/TCP 10.140.13.96:11138
> From: "Client_A"
> ;tag=65056eff-f536-43dc-a795-947be959f714
> To:
> ;tag=f6dfc966-ad80-4cea-b8bd-ce3de259b79a
> Call-ID: 89ef0faf-574f-4241-8a0f-9a3e4490a075@10.140.13.96
> CSeq: 4 MESSAGE
> Route: 
> Contact: 
> User-Agent: Windows RTC/1.0
> Content-Type: text/plain;
>
charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AU
wAlADIAMABTAGgAZQBsAGwAJQAyADAARABsAGcAOwAgAEUARgA9ADsAIABDAE8APQAwADsAIABDA
FMAPQAwADsAIABQAEYAPQAwAA0ACgANAAoA
>
> Content-Length: 18
>
>
> --
> ***********************************************
> System Executive
> Scicom Infotech Pvt. Ltd. (Scicom)
> A - 67, Sector - 57
> Noida - 201 301
> UP
> **********************************************
>
>
> _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>
>


From nsyracus@cnri.reston.va.us  Mon Dec  9 08:05:47 2002
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 IAA00835
	for ; Mon, 9 Dec 2002 08:05:47 -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 IAA07223;
	Mon, 9 Dec 2002 08:02:53 -0500 (EST)
Message-Id: <200212091302.IAA07223@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
Date: Mon, 09 Dec 2002 08:02:52 -0500
Content-Length: 3070
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-09.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: A Presence Event Package for the Session Initiation 
                          Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-presence-09.txt
	Pages		: 26
	Date		: 2002-12-6
	
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications of presence. Presence is
defined as the willingness and ability of a user to communicate with
other users on the network. Historically, presence has been limited
to 'on-line' and 'off-line' indicators; the notion of presence here
is broader. Subscriptions and notifications of presence are supported
by defining an event package within the general SIP event
notification framework. This protocol is also compliant with the
Common Presence Profile (CPP) framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-09.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-presence-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-presence-09.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:	<2002-12-6140324.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-12-6140324.I-D@ietf.org>

--OtherAccess--

--NextPart--



From nsyracus@cnri.reston.va.us  Mon Dec  9 08:05:53 2002
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 IAA00840
	for ; Mon, 9 Dec 2002 08:05:52 -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 IAA07242;
	Mon, 9 Dec 2002 08:02:59 -0500 (EST)
Message-Id: <200212091302.IAA07242@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
Date: Mon, 09 Dec 2002 08:02:58 -0500
Content-Length: 3049
Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-package-04.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: 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF.

	Title		: A Watcher Information Event Template-Package for the 
                          Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-winfo-package-04.txt
	Pages		: 19
	Date		: 2002-12-6
	
This document defines the watcher information template-package for
the SIP event framework. Watcher information refers to the set of
users subscribed to a particular resource within a particular event
package. Watcher information changes dynamically as users subscribe,
unsubscribe, are approved, or are rejected. A user can subscribe to
this information, and therefore learn about changes to it. This event
package is a template-package because it can be applied to any event
package, including itself.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-simple-winfo-package-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-simple-winfo-package-04.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:	<2002-12-6140333.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-winfo-package-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-winfo-package-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2002-12-6140333.I-D@ietf.org>

--OtherAccess--

--NextPart--



From skadiyala@unboundtech.com  Mon Dec  9 09:06:38 2002
Received: from mail.unboundtech.com (tetsuo.unboundtech.com [66.150.129.229])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01132
	for ; Mon, 9 Dec 2002 09:06:38 -0500 (EST)
Received: from Peace (ool-18bd1a09.dyn.optonline.net [24.189.26.9])
	by mail.unboundtech.com (Postfix) with ESMTP
	id 6644088B88; Mon,  9 Dec 2002 08:06:38 -0600 (CST)
From: "shanti" 
To: "simple" ,
        "sipforum" 
Date: Mon, 9 Dec 2002 09:06:37 -0500
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.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <002801c29f53$23777b10$925f07d2@spgwin1>
Importance: Normal
Content-Length: 982
Subject: [Simple] SIP MESSAGE with MSN
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: 

hi,

When I send a SIP MESSAGE request to MSN client, it responds with 200 ok but
doesnot display the message .

Following is the message am sending, and the response received from the MSN
client.


MESSAGE sip:kviswa@abc.com SIP/2.0
CSeq: 1 MESSAGE
Call-Id: 1039218960404
From: ;tag=1093
To: 
Via: SIP/2.0/UDP 192.168.123.159:2000
Content-Type: application/text-plain
Contact: 
Content-Length: 18

Hello

Thread-5:----------------------------------------
Thread-5:from = 127.0.0.1:3883
 to = 192.168.123.159:2000
 message = SIP/2.0 200 OK
Via: SIP/2.0/UDP
192.168.123.159:2000;branch=z9hG4bKad3693a4af1fd0c172f5a3cd2da61f43
From: ;tag=1093
To: ;tag=156b140c-b8bc-431c-8416-467ef5b4c6f8
Call-Id: 1039218960404
CSeq: 1 MESSAGE
Contact: 
User-Agent: Windows RTC/1.0
Content-Length: 0


Your help on this is much appreciated.

thanks,
shanti



From tsearle@indigosw.com  Mon Dec  9 09:30:38 2002
Received: from m3001.hostcentric.net (m3001.hostcentric.net [216.157.79.237])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA01232
	for ; Mon, 9 Dec 2002 09:30:38 -0500 (EST)
Received: (qmail 29690 invoked by alias); 9 Dec 2002 14:30:40 -0000
Received: from unknown (HELO indigosw.com) (217.136.220.14)
  by 0 with SMTP; 9 Dec 2002 14:30:40 -0000
Message-ID: <3DF4A856.5000203@indigosw.com>
Date: Mon, 09 Dec 2002 15:27:34 +0100
From: Torrey Searle 
Organization: Indigo Software, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.0.0) Gecko/20020529
X-Accept-Language: en-us
MIME-Version: 1.0
To: shanti 
CC: simple ,
        sipforum
 
Subject: Re: [Simple] SIP MESSAGE with MSN
References: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Content-Length: 1395
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: 

When MSN doesn't understand the content type, responds 200 OK w/o 
displaying the message.

Try sending a content type of Content-Type: text/plain instead

Torrey Searle
Indigo Software

shanti a écrit:

>hi,
>
>When I send a SIP MESSAGE request to MSN client, it responds with 200 ok but
>doesnot display the message .
>
>Following is the message am sending, and the response received from the MSN
>client.
>
>
>MESSAGE sip:kviswa@abc.com SIP/2.0
>CSeq: 1 MESSAGE
>Call-Id: 1039218960404
>From: ;tag=1093
>To: 
>Via: SIP/2.0/UDP 192.168.123.159:2000
>Content-Type: application/text-plain
>Contact: 
>Content-Length: 18
>
>Hello
>
>Thread-5:----------------------------------------
>Thread-5:from = 127.0.0.1:3883
> to = 192.168.123.159:2000
> message = SIP/2.0 200 OK
>Via: SIP/2.0/UDP
>192.168.123.159:2000;branch=z9hG4bKad3693a4af1fd0c172f5a3cd2da61f43
>From: ;tag=1093
>To: ;tag=156b140c-b8bc-431c-8416-467ef5b4c6f8
>Call-Id: 1039218960404
>CSeq: 1 MESSAGE
>Contact: 
>User-Agent: Windows RTC/1.0
>Content-Length: 0
>
>
>Your help on this is much appreciated.
>
>thanks,
>shanti
>
>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>  
>




From peter.lewis@upperside.fr  Mon Dec  9 11:14:14 2002
Received: from relay2.clb.oleane.net (relay2.clb.oleane.net [213.56.31.22])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01593
	for ; Mon, 9 Dec 2002 11:14:14 -0500 (EST)
Received: from oleane (upper-side.rain.fr [194.250.212.114]) 
	by relay2.clb.oleane.net with SMTP id gB9GEBPw028530
	for ; Mon, 9 Dec 2002 17:14:15 +0100
Message-ID: <026b01c29f9f$0a8e2760$0601a8c0@oleane.com>
From: "Peter Lewis" 
To: 
Date: Mon, 9 Dec 2002 17:21:30 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0268_01C29FA7.69DDE5E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Length: 2434
Subject: [Simple] International SIP Conference
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: 

This is a multi-part message in MIME format.

------=_NextPart_000_0268_01C29FA7.69DDE5E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

A Free SIP Server in the International SIP Conference Registration =
Package=20

Each participant to the International SIP'03 conference will be given =
iptel.org's SIP server in his registration package. It is a free SIP =
server recently released to the community. It will be in a form of a =
credit-card-size CD with an enclosed description.=20

iptel.org is a non-profit knowledge-advancement company under umbrella =
of FhG (Germany's reasearch network, non-profit too). All other outcomes =
(currently, on-line knowledge base and the SIP server) are freely =
available to the community at no cost. Please get more details at: =
http://www.iptel.org=20

Get all informations on the International SIP event at: =
http://www.upperside.fr/intersip03/sip03intro.htm=20


------=_NextPart_000_0268_01C29FA7.69DDE5E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









A Free SIP =
Server in the=20
International SIP Conference Registration Package =


Each=20
participant to the International SIP'03 conference will be given =
iptel.org's SIP=20
server in his registration package. It is a free SIP server recently =
released to=20
the community. It will be in a form of a credit-card-size CD with an =
enclosed=20
description. 

iptel.org is a non-profit =
knowledge-advancement=20
company under umbrella of FhG (Germany's reasearch network, non-profit =
too). All=20
other outcomes (currently, on-line knowledge base and the SIP server) =
are freely=20
available to the community at no cost. Please get more details at: http://www.iptel.org 

Get all=20
informations on the International SIP event at: http://www.upp=
erside.fr/intersip03/sip03intro.htm=20



------=_NextPart_000_0268_01C29FA7.69DDE5E0--


From AVSHALOM@il.ibm.com  Mon Dec  9 14:09:07 2002
Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02186
	for ; Mon, 9 Dec 2002 14:09:06 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23])
	by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gB9J97C3086616
	for ; Mon, 9 Dec 2002 20:09:07 +0100
Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55])
	by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gB9J96cO055290;
	Mon, 9 Dec 2002 20:09:07 +0100
To: 
Cc: Tony Hansen 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.0 September 26, 2002
Message-ID: 
From: "Avshalom Houri" 
Date: Mon, 9 Dec 2002 21:08:55 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at
 09/12/2002 21:09:07,
	Serialize complete at 09/12/2002 21:09:07
Content-Type: multipart/alternative; boundary="=_alternative 00692688C2256C8A_="
Content-Length: 1886
Subject: [Simple] SIMPLE system architecture draft
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: 

This is a multipart message in MIME format.
--=_alternative 00692688C2256C8A_=
Content-Type: text/plain; charset="US-ASCII"

We are starting to work on an architecture document for SIMPLE. The 
architecture document will specify how a complete presence and IM system 
can be built, based on SIMPLE and other IETF technologies. It will put 
everything together, discussing the servers involved, the security 
mechanisms, the call flows, etc.

The idea is that someone who is not an expert in the IETF protocols can 
read this document and understand how the IETF protocols can be used for
building a complete system and how it should work.

We would appreciate any suggestions for items to be included in the 
outline of the document. We would like to post the outline before the 
holiday breaks begin.

Thanks
                 Tony Hansen & Avshalom Houri

--=_alternative 00692688C2256C8A_=
Content-Type: text/html; charset="US-ASCII"



We are starting to work on an architecture document
for SIMPLE. The 

architecture document will specify how a complete presence and IM system


can be built, based on SIMPLE and other IETF technologies. It will put


everything together, discussing the servers involved, the security 

mechanisms, the call flows, etc.



The idea is that someone who is not an expert in the IETF protocols can


read this document and understand how the IETF protocols can be used for

building a complete system and how it should work.



We would appreciate any suggestions for items to be included in the 

outline of the document. We would like to post the outline before the 

holiday breaks begin.



Thanks

                
Tony Hansen & Avshalom Houri


--=_alternative 00692688C2256C8A_=--

From sudipta.ghosh@scicmp.com  Tue Dec 10 07:46:18 2002
Received: from himalaya.scicmp.com ([203.200.79.36])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id HAA05210
	for ; Tue, 10 Dec 2002 07:46:16 -0500 (EST)
Received: from mx1.scicmp.com ([10.130.0.5])
 by himalaya.scicmp.com (NAVGW 2.5.2.12) with SMTP id M2002121018163915051
 for ; Tue, 10 Dec 2002 18:16:39 +0530
Received: from scicmp.com (kanchenjunga [10.140.13.178])
	by mx1.scicmp.com (8.9.3/8.8.7) with ESMTP id SAA03109
	for ; Tue, 10 Dec 2002 18:23:24 +0530
Message-ID: <3DF5E2D4.E158291E@scicmp.com>
Date: Tue, 10 Dec 2002 18:19:25 +0530
From: Sudipta Ghosh 
Organization: Scicom Infotech Pvt. Ltd. (Scicom)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: simple 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 263
Subject: [Simple] client
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: 

hi,
what r the sip/simple enabled client available now a days.
sudipta

--
***********************************************
System Executive
Scicom Infotech Pvt. Ltd. (Scicom)
A - 67, Sector - 57
Noida - 201 301
UP
**********************************************



From rsparks@dynamicsoft.com  Tue Dec 10 10:09:44 2002
Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (dyn-tx-arch-crash.dfw.dynamicsoft.com [63.110.3.64])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05699
	for ; Tue, 10 Dec 2002 10:09:44 -0500 (EST)
Received: from RjS.localdomain (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id gBAF9kI19239
	for ; Tue, 10 Dec 2002 09:09:46 -0600
From: Robert Sparks 
To: simple 
In-Reply-To: <3DF5E2D4.E158291E@scicmp.com>
References: <3DF5E2D4.E158291E@scicmp.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) 
Date: 10 Dec 2002 09:08:11 -0600
Message-Id: <1039532891.943.26.camel@RjS.localdomain>
Mime-Version: 1.0
Content-Length: 647
Subject: [Simple] Please take implementation questions to sip-implementors
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: 

Folks -

There's a list specifically set up to discuss SIP and SIMPLE
implementation questions like how to work with a particular 
vendor's product or to canvas who has implemented a particular 
feature.

The list is sip-implementors@cs.columbia.edu. Per the instructions
at http://www.cs.columbia.edu/~hgs/sip/list.html, you can subscribe
by sending email to
sip-implementors-request@cs.columbia.edu
with "subscribe sip-implementors" in the body or using the
web interface at
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Please take the implementation questions there and refrain
from posting them to this list.

Thanks,

RjS


From sudipta.ghosh@scicmp.com  Tue Dec 10 03:41:14 2002
Received: from himalaya.scicmp.com ([203.200.79.36])
	by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id DAA04526
	for ; Tue, 10 Dec 2002 03:41:08 -0500 (EST)
Received: from mx1.scicmp.com ([10.130.0.5])
 by himalaya.scicmp.com (NAVGW 2.5.2.12) with SMTP id M2002121014111306096
 ; Tue, 10 Dec 2002 14:11:13 +0530
Received: from scicmp.com (kanchenjunga [10.140.13.178])
	by mx1.scicmp.com (8.9.3/8.8.7) with ESMTP id OAA28442;
	Tue, 10 Dec 2002 14:17:52 +0530
Message-ID: <3DF5A949.82BBFD7@scicmp.com>
Date: Tue, 10 Dec 2002 14:13:53 +0530
From: Sudipta Ghosh 
Organization: Scicom Infotech Pvt. Ltd. (Scicom)
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Jonathan Rosenberg ,
        sipforum ,
        simple 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 918
Subject: [Simple] 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: 

Hi,
I have a query.
Suppose UAC AA is sending a SUBSCRIBE request for some event to another
UAC BB via proxy server.
At that BB was not online( I mean no yet registered ) so proxy server
sent the 20o OK resonse to AA.

After some time, when BB registered, I have noticed that proxy server is
sending the SUBSCRIBE request, that AA has sent before.
No everythinh is OK. AA gets event notification from BB.

Now BB goes offline and close the dialog with AA for event for some time
and then again registered.
My query is how AA will again subscribe for event notification since AA
does not have no info if BB is registerd or not..
Or proxy server will send SUBSCRIBE request?

Where I will get documentation about this.

sudipta

--
***********************************************
System Executive
Scicom Infotech Pvt. Ltd. (Scicom)
A - 67, Sector - 57
Noida - 201 301
UP
**********************************************